From casado2 at llnl.gov  Mon Jul  1 18:14:42 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Mon, 1 Jul 2002 09:14:42 -0700
Subject: [C++-sig] high level overview of boost.python implementation
In-Reply-To: <3D1DF544.8050405@gmx.co.uk>
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <093401c21f93$c2d2be80$6501a8c0@boostconsulting.com> <3D1DF544.8050405@gmx.co.uk>
Message-ID: <02070109144212.02424@avalanche.llnl.gov>

On Saturday 29 June 2002 10:58, you wrote:
> David Abrahams wrote:
> >Sounds great. I will try to throw you all a clue now and again also.
> >

I've found the most conceptually challenging aspects of Boost deal with 
handeling the conversion between PyObjects and C++ arguments.  In light
of this, I sat down and wrote a really rough overview of how things
seemed to work.  I don't vouch for the correctness of this (it is most likely
wrong), but at the very least it might provide a basis for discussion.  I am
really keen on getting a good set of overview documentation so... any 
feedback,
additions, etc. would be greatly appreciated....

            ~~m


File:   HandlingArgumentsInBpl.txt
===============================================================================
 
Suggested Background Readings
 
boost::function documentation: http://www.boost.org/libs/function/index.html
boost::bind documentation:     http://www.boost.org/libs/bind/bind.html
 
===============================================================================
                    How Arguments From Python Are Handled
===============================================================================
 
It is perhaps easiest to start the discussion by describing the mechanism
used by BPL to convert python objects used as arguments from within python to
C++ objects for passing into wrapped functions.
 
  The main mechanism to handle the conversions is the struct
 
  template <typename T> struct arg_from_python
 
  arg_from_python is a class template which is used to convert
  a PyObject* to a type T.  arg_from_python has the following
  members.
 
      arg_from_python(PyObject*) // constructor
      bool convertible();
      T operator()(PyObject*) const;
 
   convertible(..) returns true if BPL knows how to convert T
   operator() handles the mechanics of the conversion.  You could
   use arg_from_python as follows to attempt to convert an arbitrary
   PyObject into an object of type std::vector<int>
 
   std::vector<int> foo(PyObject* obj)
   {
     arg_from_python<std::vector<int> > from_py(obj);
     if(from_py.convertible())
     {
        return from_py(obj);
     }
   }


   This is simple enough, right? Unfortunately the implementation
   of arg_from_python is not exactly straight-forward (for us
   C++ weenies that is).  Taking a peak at the declaration..
   found in boost/python/arg_from_python.hpp
 
        template <class T>
        struct arg_from_python
            : converter::select_arg_from_python<T>::type
        {
            typedef typename converter::select_arg_from_python<T>::type base;
            arg_from_python(PyObject*);
        };
 
   we see that the actual implementations of convertible() and operator() are
   dependant on some wiz-bang static mechanism for determining the correct
   type via the class select_arg_from_python.  The selection mechanism and
   all implementations can be found in 
boost/python/converter/arg_from_python.hpp.
 
   *** Note: discussion of registry here ?!?!
       (I have a notion that the non specialized arg_from_python uses the 
registry
        to determine how to do the conversion using the registry)
 
===============================================================================
             How functions are called from python
             (warning this is an incomplete and most
             likely inaccurate description of the process)
===============================================================================
 
   The last section discussed how, given an argument parameter such as
std::vector<int>, BPL handles the conversion, namely from creating an object 
of
type arg_from_python<std::vector<int> > and using a specialized conversion
mechanism or using the default. (which probably uses the registry)  However,
there has been no mention of how BPL actually gets access to the arguments of
the wrapped C++ method.  The best start for a foray into this complex world is
to take a peak at boost/python/make_function.hpp.  BPL functions are at the
highest level encapsulated in objects::function
(boost/python/objects/function.hpp) which handles overloading and ensuring
argument count is correct (and other things I don't know about).
 
   The creation of a default objects::function object as shown in
make_function.hpp is as follows:

  return new objects::function(
           objects::py_function(
                       ::boost::bind<PyObject*>(detail::caller(), f, _1, _2,
                       default_call_policies())),
                       detail::arg_tuple_size<F>::value);
 
   A function is created by a py_function object  (which is really just a
   typedef of boost:function2<PyObject*,PyObject*,PyObject*>) and an unisgned
   int representing the minimum number of arguments accepted into the 
function.
   The minimum number of arguments is discovered through some static mechanism
   I'm not even going to begin to pretend to understand.
 
   The py_function object is simply boost::function created from a bound
   functor (detail::caller), which when called is passed f (the function
   we are wrapping), the first two default arguments and a call policy
   (in the case of the example it is passed the default call policy).  Next
   obvious next question is, "what does detail::caller do when called?"
 
   detail::caller's () operator actually invokes a static method in 
detail::returning
   (boost/python/detail/returning.hpp) as you can see in the following code
   from boost/python/detail/caller.hpp.
 
    PyObject* operator()(
        BOOST_PYTHON_FN(*f,0,args_)
      , PyObject* args, PyObject* keywords
      , P const& policies
      ) const
    {
        return returning<R>::call(f, args, keywords,&policies);
    }


    returning<>::call does all sorts of fancy whizbang  preprocessing and
    metaprogramming tricks (feel free to browse the code to get a feel for 
what I'm
    talking about), which in essence boils down to the following.. (I think)
 
    - For the 0th item in the tuple (self) check to see if it is convertible
      to the correct type the method is being called on.
 
        /* check that each of the arguments is convertible */
        /* self argument is special */
        arg_from_python<A0&> c0(PyTuple_GET_ITEM(args_, 0));
        if (!c0.convertible()) return 0;
 
    - For each item in the tuple (not including the self argument) check to 
see
      if that item is convertible to its respective argument in the C++
      argument list.
 
       /* Unroll a loop for the rest of them */
       BOOST_PP_REPEAT_FROM_TO(1,args,BOOST_PYTHON_ARG_CONVERTIBLE,nil)
 
     Where, BOOST_PYTHON_ARG_CONVERTIBLE is defined as ..
 
    # define BOOST_PYTHON_ARG_CONVERTIBLE(index,ignored)
        arg_from_python<BOOST_PP_CAT(A,index)>
        BOOST_PP_CAT(c,index)(PyTuple_GET_ITEM(args_, index));
        if (!BOOST_PP_CAT(c,index).convertible()) return 0;

    As the source code demonstrates, the mechanism for checking the 
conversions
    is instantiating an arg_from_python<arg> where arg is the argument type
    and calling convertible() on that object.
 
    After the arguments are checked, the return value is checked to see if it
    can be converted to a python object (a process not discussed in this text)
    via the lines...
 
        /* find the result converter */
        typedef typename P::result_converter result_converter;
        typename mpl::apply1<result_converter,R>::type cr;
        if (!cr.convertible()) return 0;
 
    The call policy's precall() method is then called, the method is called 
with the
    converted arguments and finally the call policy's postcall method  is 
called and
    the result is returned.
 
      if (!policies->precall(args_)) return 0;
 
       PyObject* result = cr(
            ((BOOST_PYTHON_GET_ARG(0,nil)).*pmf)(
                BOOST_PP_ENUM_SHIFTED(args,BOOST_PYTHON_GET_ARG,nil))
            );
 
      return policies->postcall(args_, result);
 
   Of course for completeness it is worth discussing the actuall call to the 
method.

  Aka: ((BOOST_PYTHON_GET_ARG(0,nil)).*pmf)(
                BOOST_PP_ENUM_SHIFTED(args,BOOST_PYTHON_GET_ARG,nil))
 
   If the function pointer in question (aka pmf) is a pointer to a member 
function, it is
   bound to the first argument converted to the correct c++ type via 
BOOST_PYTHON_GET_ARG.
   This function is then called with the correct arguments which are 
converted also via
   BOOST_PYTHON_GET_ARG.  What does BOOST_PYTHON_GET_ARG do?  It calls the () 
operator
   on the arg_from_python type passing in, as an argument, python object from 
the argument
   tuple that is to be converted.
 
    # define BOOST_PYTHON_GET_ARG(index,ignored)
            BOOST_PP_CAT(c,index)(PyTuple_GET_ITEM(args_, index))
 
   Note, that there have been a number of things left out in this discussion.
   In reality pointers to member functions and pointers to non member 
functions
   are handled differently.  In the latter case, the object is passed in as 
the
   first argument to the function.  Also the content on the actual mechanics 
of
   the meta-programming has been virtually nil, mainly because I don't
   understand how it works :-P




From david.abrahams at rcn.com  Mon Jul  1 22:30:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Jul 2002 16:30:56 -0400
Subject: [C++-sig] high level overview of boost.python implementation
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <093401c21f93$c2d2be80$6501a8c0@boostconsulting.com> <3D1DF544.8050405@gmx.co.uk> <02070109144212.02424@avalanche.llnl.gov>
Message-ID: <100201c2213e$36c563f0$6501a8c0@boostconsulting.com>

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


> On Saturday 29 June 2002 10:58, you wrote:
> > David Abrahams wrote:
> > >Sounds great. I will try to throw you all a clue now and again also.
> > >
>
> I've found the most conceptually challenging aspects of Boost deal with
> handeling the conversion between PyObjects and C++ arguments.  In light
> of this, I sat down and wrote a really rough overview of how things
> seemed to work.  I don't vouch for the correctness of this (it is most
likely
> wrong), but at the very least it might provide a basis for discussion.  I
am
> really keen on getting a good set of overview documentation so... any
> feedback,
> additions, etc. would be greatly appreciated....
>

This is great, Martin! Comments to follow...

> File:   HandlingArgumentsInBpl.txt
>
===========================================================================
====
>
> Suggested Background Readings
>
> boost::function documentation:
http://www.boost.org/libs/function/index.html
> boost::bind documentation:     http://www.boost.org/libs/bind/bind.html
>
>
===========================================================================
====
>                     How Arguments From Python Are Handled
>
===========================================================================
====
>
> It is perhaps easiest to start the discussion by describing the mechanism
> used by BPL to convert python objects used as arguments from within
python to
> C++ objects for passing into wrapped functions.
>
>   The main mechanism to handle the conversions is the struct
>
>   template <typename T> struct arg_from_python
>
>   arg_from_python is a class template which is used to convert
>   a PyObject* to a type T.  arg_from_python has the following
>   members.
>
>       arg_from_python(PyObject*) // constructor
>       bool convertible();
>       T operator()(PyObject*) const;
>
>    convertible(..) returns true if BPL knows how to convert T
>    operator() handles the mechanics of the conversion.  You could
>    use arg_from_python as follows to attempt to convert an arbitrary
>    PyObject into an object of type std::vector<int>
>
>    std::vector<int> foo(PyObject* obj)
>    {
>      arg_from_python<std::vector<int> > from_py(obj);
>      if(from_py.convertible())
>      {
>         return from_py(obj);
>      }
>    }

...except that there's no return for the else case, and more-importantly,
arg_from_python really shouldn't ever be touched by users. If they have to
get their hands on a from_python converter, it should be
converter::return_from_python<T>. The semantics for handling arguments and
return types really are different, and return_from_python/arg_to_python
match the users' needs and expectations much better than
arg_from_python/to_python_value do.

>    This is simple enough, right? Unfortunately the implementation
>    of arg_from_python is not exactly straight-forward (for us
>    C++ weenies that is).  Taking a peak at the declaration..
>    found in boost/python/arg_from_python.hpp
>
>         template <class T>
>         struct arg_from_python
>             : converter::select_arg_from_python<T>::type
>         {
>             typedef typename converter::select_arg_from_python<T>::type
base;
>             arg_from_python(PyObject*);
>         };
>
>    we see that the actual implementations of convertible() and operator()
are
>    dependant on some wiz-bang static mechanism for determining the
correct
>    type via the class select_arg_from_python.  The selection mechanism
and
>    all implementations can be found in
> boost/python/converter/arg_from_python.hpp.
>
>    *** Note: discussion of registry here ?!?!
>        (I have a notion that the non specialized arg_from_python uses the
> registry
>         to determine how to do the conversion using the registry)

Yes, the non-specialized version uses converter functions which have been
registered.

>
===========================================================================
====
>              How functions are called from python
>              (warning this is an incomplete and most
>              likely inaccurate description of the process)
>
===========================================================================
====
>
>    The last section discussed how, given an argument parameter such as
> std::vector<int>, BPL handles the conversion, namely from creating an
object
> of
> type arg_from_python<std::vector<int> > and using a specialized
conversion
> mechanism or using the default. (which probably uses the registry)
However,
> there has been no mention of how BPL actually gets access to the
arguments of
> the wrapped C++ method.  The best start for a foray into this complex
world is
> to take a peak at boost/python/make_function.hpp.  BPL functions are at
the
> highest level encapsulated in objects::function
> (boost/python/objects/function.hpp) which handles overloading and
ensuring
> argument count is correct (and other things I don't know about).

Actually that's about it. Well, there's method binding - so that when you
access the function through a class instance it binds the function and a
reference to the instance into a callable method object.

>
>    The creation of a default objects::function object as shown in
> make_function.hpp is as follows:
>
>   return new objects::function(
>            objects::py_function(
>                        ::boost::bind<PyObject*>(detail::caller(), f, _1,
_2,
>                        default_call_policies())),
>                        detail::arg_tuple_size<F>::value);
>
>    A function is created by a py_function object  (which is really just a
>    typedef of boost:function2<PyObject*,PyObject*,PyObject*>) and an
unisgned
>    int representing the minimum number of arguments accepted into the
> function.
>    The minimum number of arguments is discovered through some static
mechanism

Right.

>    I'm not even going to begin to pretend to understand.

Suit yerself. It's pretty simple <.0001 wink>

>    The py_function object is simply boost::function created from a bound
>    functor (detail::caller), which when called is passed f (the function
>    we are wrapping), the first two default arguments and a call policy
>    (in the case of the example it is passed the default call policy).
Next
>    obvious next question is, "what does detail::caller do when called?"
>
>    detail::caller's () operator actually invokes a static method in
> detail::returning
>    (boost/python/detail/returning.hpp) as you can see in the following
code
>    from boost/python/detail/caller.hpp.
>
>     PyObject* operator()(
>         BOOST_PYTHON_FN(*f,0,args_)
>       , PyObject* args, PyObject* keywords
>       , P const& policies
>       ) const
>     {
>         return returning<R>::call(f, args, keywords,&policies);
>     }
>
>
>     returning<>::call does all sorts of fancy whizbang  preprocessing and
>     metaprogramming tricks (feel free to browse the code to get a feel
for
> what I'm
>     talking about), which in essence boils down to the following.. (I
think)
>
>     - For the 0th item in the tuple (self) check to see if it is
convertible
>       to the correct type the method is being called on.

That is of course different when the function pointer being wrapped is a
regular function, instead of a member function.

>         /* check that each of the arguments is convertible */
>         /* self argument is special */
>         arg_from_python<A0&> c0(PyTuple_GET_ITEM(args_, 0));
>         if (!c0.convertible()) return 0;
>
>     - For each item in the tuple (not including the self argument) check
to
> see
>       if that item is convertible to its respective argument in the C++
>       argument list.
>
>        /* Unroll a loop for the rest of them */
>        BOOST_PP_REPEAT_FROM_TO(1,args,BOOST_PYTHON_ARG_CONVERTIBLE,nil)
>
>      Where, BOOST_PYTHON_ARG_CONVERTIBLE is defined as ..
>
>     # define BOOST_PYTHON_ARG_CONVERTIBLE(index,ignored)
>         arg_from_python<BOOST_PP_CAT(A,index)>
>         BOOST_PP_CAT(c,index)(PyTuple_GET_ITEM(args_, index));
>         if (!BOOST_PP_CAT(c,index).convertible()) return 0;

It might be easier to look at
boost/python/preprocessed/returning_non_void.hpp|returning_void.hpp, which
have the preprocessor stuff completely expanded.

>     As the source code demonstrates, the mechanism for checking the
> conversions
>     is instantiating an arg_from_python<arg> where arg is the argument
type
>     and calling convertible() on that object.
>
>     After the arguments are checked, the return value is checked to see
if it
>     can be converted to a python object (a process not discussed in this
text)
>     via the lines...
>
>         /* find the result converter */
>         typedef typename P::result_converter result_converter;
>         typename mpl::apply1<result_converter,R>::type cr;
>         if (!cr.convertible()) return 0;

Yes. Note that the availability of a result converter currently affects
overload resolution. That's probably a (small) mistake.

Nice work,
Dave






From hugo at adept.co.za  Mon Jul  1 22:46:03 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Mon, 1 Jul 2002 22:46:03 +0200
Subject: [C++-sig] static methods, and -ftemplate-depth observations
Message-ID: <20020701204603.GA1899@vervet.localnet>

Observation:

When I wrap an 11 parameter constructor, I have to set
-ftemplate-depth-35 - 34 is too small. If I remove the 11 parameter
constructor, I can get away with 23 ...

I get heaps of error messages if I have it too small. The first being
(for the case of 20, without the 11 parameter constructor):

/home/hugo/Programming/boost/boost/mpl/list/traits.hpp:43: template instantiation depth exceeds maximum of 20
/home/hugo/Programming/boost/boost/mpl/list/traits.hpp:43:  (use -ftemplate-depth-NN to increase the maximum)

This is g++ 2.95.4, David mentioned it's unsupported. With g++ 3.0.4, 35
is also too small, I have to push it up to 36.

I'm leaving the 17 parameter constructor until I get round to dealing
with const float* and const Uint8* (I think this is trivial, it was in
V1?), I don't need this beast in a rush. (I'll also deal with my arity
issues then, if there indeed *are* issues. Must still investigate
thoroughly.)

What I'm trying to deal with next, is wrapping "static Settings*
GetInstance" returning the single, always existing, global instance of
the Settings class for the library. The way I interpreted the examples
and docs (which isn't too good, I haven't got a proper understanding of
all the Call Policy things yet), I did:

    boost::python::module foo("foo");
    foo
	.add(
	    boost::python::class_<Settings>("Settings")
	    .def("GetInstance", &Settings::GetInstance,
		 return_value_policy<reference_existing_object>())
        );

Is that the right policy? As the instance always exists, I want Python
to use the pointer directly.

This doesn't give me a proper "static method" though, it's still
expecting a "self" parameter too. Wrapping this in V1 was trivial, it
seemed to do the right thing. I expect it just left out the "self"
parameter? This is how I did "static methods" in 2.1.

I did notice Python 2.2 has "proper" static methods. (What's the
significance, just that you can then also call these on instances of the
class, whereas with the "old" approach you have to specifically call it
on the class itself?)

So does V2 do static methods yet?

Thanks,
Hugo van der Merwe

(docstrings some time in the future... ?)




From casado2 at llnl.gov  Mon Jul  1 23:34:53 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Mon, 1 Jul 2002 14:34:53 -0700
Subject: [C++-sig] high level overview of boost.python implementation
In-Reply-To: <100201c2213e$36c563f0$6501a8c0@boostconsulting.com>
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <02070109144212.02424@avalanche.llnl.gov> <100201c2213e$36c563f0$6501a8c0@boostconsulting.com>
Message-ID: <02070114345315.02424@avalanche.llnl.gov>

 Thanks for the comments Dave,

   I'm going to redo some of the parts you commented on to clear things
   up and resubmit.
   
                            ~~m

> From: "Martin Casado" <casado2 at llnl.gov>
>
> > On Saturday 29 June 2002 10:58, you wrote:
> > > David Abrahams wrote:
> > > >Sounds great. I will try to throw you all a clue now and again also.
> >
> > I've found the most conceptually challenging aspects of Boost deal with
> > handeling the conversion between PyObjects and C++ arguments.  In light
> > of this, I sat down and wrote a really rough overview of how things
> > seemed to work.  I don't vouch for the correctness of this (it is most
>
> likely
>
> > wrong), but at the very least it might provide a basis for discussion.  I
>
> am
>
> > really keen on getting a good set of overview documentation so... any
> > feedback,
> > additions, etc. would be greatly appreciated....
>
> This is great, Martin! Comments to follow...
>
> > File:   HandlingArgumentsInBpl.txt
>
> ===========================================================================
> ====
>
> > Suggested Background Readings
> >
> > boost::function documentation:
>
> http://www.boost.org/libs/function/index.html
>
> > boost::bind documentation:     http://www.boost.org/libs/bind/bind.html
>
> ===========================================================================
> ====
>
> >                     How Arguments From Python Are Handled
>
> ===========================================================================
> ====
>
> > It is perhaps easiest to start the discussion by describing the mechanism
> > used by BPL to convert python objects used as arguments from within
>
> python to
>
> > C++ objects for passing into wrapped functions.
> >
> >   The main mechanism to handle the conversions is the struct
> >
> >   template <typename T> struct arg_from_python
> >
> >   arg_from_python is a class template which is used to convert
> >   a PyObject* to a type T.  arg_from_python has the following
> >   members.
> >
> >       arg_from_python(PyObject*) // constructor
> >       bool convertible();
> >       T operator()(PyObject*) const;
> >
> >    convertible(..) returns true if BPL knows how to convert T
> >    operator() handles the mechanics of the conversion.  You could
> >    use arg_from_python as follows to attempt to convert an arbitrary
> >    PyObject into an object of type std::vector<int>
> >
> >    std::vector<int> foo(PyObject* obj)
> >    {
> >      arg_from_python<std::vector<int> > from_py(obj);
> >      if(from_py.convertible())
> >      {
> >         return from_py(obj);
> >      }
> >    }
>
> ...except that there's no return for the else case, and more-importantly,
> arg_from_python really shouldn't ever be touched by users. If they have to
> get their hands on a from_python converter, it should be
> converter::return_from_python<T>. The semantics for handling arguments and
> return types really are different, and return_from_python/arg_to_python
> match the users' needs and expectations much better than
> arg_from_python/to_python_value do.
>
> >    This is simple enough, right? Unfortunately the implementation
> >    of arg_from_python is not exactly straight-forward (for us
> >    C++ weenies that is).  Taking a peak at the declaration..
> >    found in boost/python/arg_from_python.hpp
> >
> >         template <class T>
> >         struct arg_from_python
> >
> >             : converter::select_arg_from_python<T>::type
> >
> >         {
> >             typedef typename converter::select_arg_from_python<T>::type
>
> base;
>
> >             arg_from_python(PyObject*);
> >         };
> >
> >    we see that the actual implementations of convertible() and operator()
>
> are
>
> >    dependant on some wiz-bang static mechanism for determining the
>
> correct
>
> >    type via the class select_arg_from_python.  The selection mechanism
>
> and
>
> >    all implementations can be found in
> > boost/python/converter/arg_from_python.hpp.
> >
> >    *** Note: discussion of registry here ?!?!
> >        (I have a notion that the non specialized arg_from_python uses the
> > registry
> >         to determine how to do the conversion using the registry)
>
> Yes, the non-specialized version uses converter functions which have been
> registered.
>
>
> ===========================================================================
> ====
>
> >              How functions are called from python
> >              (warning this is an incomplete and most
> >              likely inaccurate description of the process)
>
> ===========================================================================
> ====
>
> >    The last section discussed how, given an argument parameter such as
> > std::vector<int>, BPL handles the conversion, namely from creating an
>
> object
>
> > of
> > type arg_from_python<std::vector<int> > and using a specialized
>
> conversion
>
> > mechanism or using the default. (which probably uses the registry)
>
> However,
>
> > there has been no mention of how BPL actually gets access to the
>
> arguments of
>
> > the wrapped C++ method.  The best start for a foray into this complex
>
> world is
>
> > to take a peak at boost/python/make_function.hpp.  BPL functions are at
>
> the
>
> > highest level encapsulated in objects::function
> > (boost/python/objects/function.hpp) which handles overloading and
>
> ensuring
>
> > argument count is correct (and other things I don't know about).
>
> Actually that's about it. Well, there's method binding - so that when you
> access the function through a class instance it binds the function and a
> reference to the instance into a callable method object.
>
> >    The creation of a default objects::function object as shown in
> > make_function.hpp is as follows:
> >
> >   return new objects::function(
> >            objects::py_function(
> >
> >                        ::boost::bind<PyObject*>(detail::caller(), f, _1,
>
> _2,
>
> >                        default_call_policies())),
> >                        detail::arg_tuple_size<F>::value);
> >
> >    A function is created by a py_function object  (which is really just a
> >    typedef of boost:function2<PyObject*,PyObject*,PyObject*>) and an
>
> unisgned
>
> >    int representing the minimum number of arguments accepted into the
> > function.
> >    The minimum number of arguments is discovered through some static
>
> mechanism
>
> Right.
>
> >    I'm not even going to begin to pretend to understand.
>
> Suit yerself. It's pretty simple <.0001 wink>
>
> >    The py_function object is simply boost::function created from a bound
> >    functor (detail::caller), which when called is passed f (the function
> >    we are wrapping), the first two default arguments and a call policy
> >    (in the case of the example it is passed the default call policy).
>
> Next
>
> >    obvious next question is, "what does detail::caller do when called?"
> >
> >    detail::caller's () operator actually invokes a static method in
> > detail::returning
> >    (boost/python/detail/returning.hpp) as you can see in the following
>
> code
>
> >    from boost/python/detail/caller.hpp.
> >
> >     PyObject* operator()(
> >         BOOST_PYTHON_FN(*f,0,args_)
> >       , PyObject* args, PyObject* keywords
> >       , P const& policies
> >       ) const
> >     {
> >         return returning<R>::call(f, args, keywords,&policies);
> >     }
> >
> >
> >     returning<>::call does all sorts of fancy whizbang  preprocessing and
> >     metaprogramming tricks (feel free to browse the code to get a feel
>
> for
>
> > what I'm
> >     talking about), which in essence boils down to the following.. (I
>
> think)
>
> >     - For the 0th item in the tuple (self) check to see if it is
>
> convertible
>
> >       to the correct type the method is being called on.
>
> That is of course different when the function pointer being wrapped is a
> regular function, instead of a member function.
>
> >         /* check that each of the arguments is convertible */
> >         /* self argument is special */
> >         arg_from_python<A0&> c0(PyTuple_GET_ITEM(args_, 0));
> >         if (!c0.convertible()) return 0;
> >
> >     - For each item in the tuple (not including the self argument) check
>
> to
>
> > see
> >       if that item is convertible to its respective argument in the C++
> >       argument list.
> >
> >        /* Unroll a loop for the rest of them */
> >        BOOST_PP_REPEAT_FROM_TO(1,args,BOOST_PYTHON_ARG_CONVERTIBLE,nil)
> >
> >      Where, BOOST_PYTHON_ARG_CONVERTIBLE is defined as ..
> >
> >     # define BOOST_PYTHON_ARG_CONVERTIBLE(index,ignored)
> >         arg_from_python<BOOST_PP_CAT(A,index)>
> >         BOOST_PP_CAT(c,index)(PyTuple_GET_ITEM(args_, index));
> >         if (!BOOST_PP_CAT(c,index).convertible()) return 0;
>
> It might be easier to look at
> boost/python/preprocessed/returning_non_void.hpp|returning_void.hpp, which
> have the preprocessor stuff completely expanded.
>
> >     As the source code demonstrates, the mechanism for checking the
> > conversions
> >     is instantiating an arg_from_python<arg> where arg is the argument
>
> type
>
> >     and calling convertible() on that object.
> >
> >     After the arguments are checked, the return value is checked to see
>
> if it
>
> >     can be converted to a python object (a process not discussed in this
>
> text)
>
> >     via the lines...
> >
> >         /* find the result converter */
> >         typedef typename P::result_converter result_converter;
> >         typename mpl::apply1<result_converter,R>::type cr;
> >         if (!cr.convertible()) return 0;
>
> Yes. Note that the availability of a result converter currently affects
> overload resolution. That's probably a (small) mistake.
>
> Nice work,
> Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From david.abrahams at rcn.com  Mon Jul  1 23:54:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Jul 2002 17:54:36 -0400
Subject: [C++-sig] low-hanging fruit
Message-ID: <106601c2214a$23badae0$6501a8c0@boostconsulting.com>

There are no non-special methods listed in

>>> help(long)

so I went ahead and implemented the Python long wrapper. Tests in
libs/python/test/long.[cpp/py]

It should be similarly easy for someone to write the Python int wrapper

hint-hint-ly y'rs,
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  Tue Jul  2 00:08:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Jul 2002 18:08:32 -0400
Subject: [C++-sig] static methods, and -ftemplate-depth observations
References: <20020701204603.GA1899@vervet.localnet>
Message-ID: <107101c2214c$02fd9700$6501a8c0@boostconsulting.com>

From: "Hugo van der Merwe" <hugo at adept.co.za>


> Observation:
>
> When I wrap an 11 parameter constructor, I have to set
> -ftemplate-depth-35 - 34 is too small. If I remove the 11 parameter
> constructor, I can get away with 23 ...
>
> I get heaps of error messages if I have it too small. The first being
> (for the case of 20, without the 11 parameter constructor):
>
> /home/hugo/Programming/boost/boost/mpl/list/traits.hpp:43: template
instantiation depth exceeds maximum of 20
> /home/hugo/Programming/boost/boost/mpl/list/traits.hpp:43:
 (use -ftemplate-depth-NN to increase the maximum)
>
> This is g++ 2.95.4, David mentioned it's unsupported. With g++ 3.0.4, 35
> is also too small, I have to push it up to 36.

OK, that's not too unexpected. I think that switching to the mpl_v2 branch
of MPL will fix some of the instantiation-depth issues, and there will
probably be a massive improvement once Aleksey implements the optimizations
he's been promising are imminent. However, I am waiting for Paul Mensonides
to get finished with his changes to the way Boost.Python uses the
preprocessor library before attempting the port to mpl_v2 again (I tried it
once, but there were a few problems so I had to go back).

> I'm leaving the 17 parameter constructor until I get round to dealing
> with const float* and const Uint8* (I think this is trivial, it was in
> V1?),

What are you trying to do with these types, exactly?

> I don't need this beast in a rush. (I'll also deal with my arity
> issues then, if there indeed *are* issues. Must still investigate
> thoroughly.)
>
> What I'm trying to deal with next, is wrapping "static Settings*
> GetInstance" returning the single, always existing, global instance of
> the Settings class for the library. The way I interpreted the examples
> and docs (which isn't too good, I haven't got a proper understanding of
> all the Call Policy things yet), I did:
>
>     boost::python::module foo("foo");
>     foo
> .add(
>     boost::python::class_<Settings>("Settings")
>     .def("GetInstance", &Settings::GetInstance,
> return_value_policy<reference_existing_object>())
>         );
>
> Is that the right policy? As the instance always exists, I want Python
> to use the pointer directly.

Yep, that should be OK.

>
> This doesn't give me a proper "static method" though, it's still
> expecting a "self" parameter too. Wrapping this in V1 was trivial, it
> seemed to do the right thing. I expect it just left out the "self"
> parameter? This is how I did "static methods" in 2.1.
>
> I did notice Python 2.2 has "proper" static methods.

Right. We just need to implement support for those.

> (What's the
> significance, just that you can then also call these on instances of the
> class, whereas with the "old" approach you have to specifically call it
> on the class itself?)

Yep, I think so.

> So does V2 do static methods yet?

Nope, but this is a good manageable project to take on, if you want to see
it done. Take a look at libs/python/src/objects/function.cpp and
PyStaticMethod_New(). This might be as easy as passing the
boost::python::object::function* to PyStaticMethod_New().


> Thanks,
> Hugo van der Merwe
>
> (docstrings some time in the future... ?)

Yep. Easy enough to do; we just need to add them...

-Dave





From achim.domma at syynx.de  Tue Jul  2 11:04:47 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Tue, 2 Jul 2002 11:04:47 +0200
Subject: [C++-sig] low-hanging fruit
In-Reply-To: <106601c2214a$23badae0$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEDHDIAA.achim.domma@syynx.de>

I have looked at the code of 'list', and I think I should be able to do the
same for dict,str,... but it may take until end of week to do it. If that's
fast enough, I will try my best.

Achim

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Monday, July 01, 2002 23:55
> To: pysig
> Subject: [C++-sig] low-hanging fruit
>
>
> There are no non-special methods listed in
>
> >>> help(long)
>
> so I went ahead and implemented the Python long wrapper. Tests in
> libs/python/test/long.[cpp/py]
>
> It should be similarly easy for someone to write the Python int wrapper
>
> hint-hint-ly y'rs,
> 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
> +---------------------------------------------------------------+
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>






From david.abrahams at rcn.com  Tue Jul  2 11:13:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 05:13:28 -0400
Subject: [C++-sig] low-hanging fruit
References: <FCEMIEFBFOIDAOJDEPIAIEDHDIAA.achim.domma@syynx.de>
Message-ID: <125601c221a9$19cbc710$6501a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>


> I have looked at the code of 'list', and I think I should be able to do
the
> same for dict,str,... but it may take until end of week to do it. If
that's
> fast enough, I will try my best.

Oh, that would be just wonderful, thank you!

-Dave






From david.abrahams at rcn.com  Tue Jul  2 11:27:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 05:27:04 -0400
Subject: [C++-sig] low-hanging fruit
References: <FCEMIEFBFOIDAOJDEPIAIEDHDIAA.achim.domma@syynx.de> <125601c221a9$19cbc710$6501a8c0@boostconsulting.com>
Message-ID: <126601c221aa$a2a16bc0$6501a8c0@boostconsulting.com>

From: "David Abrahams" <david.abrahams at rcn.com>


> From: "Achim Domma" <achim.domma at syynx.de>
>
>
> > I have looked at the code of 'list', and I think I should be able to do
> the
> > same for dict,str,... but it may take until end of week to do it. If
> that's
> > fast enough, I will try my best.
>
> Oh, that would be just wonderful, thank you!

BTW, be warned: most of the labor goes into writing the tests (and
documentation, for which I don't have any examples yet).





From rwgk at yahoo.com  Tue Jul  2 15:05:12 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 06:05:12 -0700 (PDT)
Subject: [C++-sig] status of auto-builds
Message-ID: <20020702130512.52385.qmail@web20205.mail.yahoo.com>

The last successful Tru64 build is from Sat Jun 29 8am PDT. Ever since then two
of the tests are failing.

The same is true for the IRIX build. This suggests a problem with the EDG
front-end.

There also seems to be some weird problem with VC60 and VC70: at the same time
when the EDG builds started failing the VC build logs stop at the
test_builtin_converters.py test!?

For full detail check http://cci.lbl.gov/boost/

Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Tue Jul  2 16:21:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 10:21:34 -0400
Subject: [C++-sig] status of auto-builds
References: <20020702130512.52385.qmail@web20205.mail.yahoo.com>
Message-ID: <13b701c221d4$5cdc73d0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Tuesday, July 02, 2002 9:05 AM
Subject: [C++-sig] status of auto-builds


> The last successful Tru64 build is from Sat Jun 29 8am PDT. Ever since
then two
> of the tests are failing.
>
> The same is true for the IRIX build. This suggests a problem with the EDG
> front-end.

The problem with test_builtin_converters is a known issue (see
http://aspn.activestate.com/ASPN/Mail/Message/boost/1263134). Martin has
been looking into it but you might be able to do better from your end...

------
it's a simple matter of the boost/config/suffix.hpp file detecting
the value for BOOST_HAS_LONG_LONG differently in two different translation
units. In libs/python/src/builtin_converters.cpp the test is coming up
negative, while in libs/python/test/test_builtin_converters.cpp it's coming
up positive. If you can find out which file is defining any of the
following symbols

    ULLONG_MAX
    ULONG_LONG_MAX
    ULONGLONG_MAX

then we will be close to having the problem solved. I've been approaching
it by taking the command-line which builds test_builtin_converters.o (get
that from bjam... -n -a test_builtin_converters.o) and
adding -DULLONG_MAX -DULONG_LONG_MAX -DULONGLONG_MAX so it would tell me
where the conflicting definition is.
------

I'm not sure what the problem with the iterators test is; it appears
there's a linker problem that prevents list<T>::insert from being properly
found.

> There also seems to be some weird problem with VC60 and VC70: at the same
time
> when the EDG builds started failing the VC build logs stop at the
> test_builtin_converters.py test!?

That's pretty weird. Works for me... I suggest looking at your testing
framework.

-Dave





From david.abrahams at rcn.com  Tue Jul  2 19:13:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 13:13:51 -0400
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
Message-ID: <147501c221eb$d76b9ba0$6501a8c0@boostconsulting.com>

As usual, how best to provide this is a more interesting problem than it
first appears to be.

I think the basic interface should be:

    extract<T>(obj)

where obj is an instance of class object.

I am still trying to decide whether extract should be a class with an
operator T() or operator T const&() conversion, or a function.

A function is easy-to-implement, but has several drawbacks:

    1. Less-efficient for rvalue conversions, since a stored
       T will need to be copied upon return.

    2. No way to find out if the conversion can succeed without
       throwing an exception. If we use a class we can give it a
       .convertible() member function.

A using a class template also has some disadvantages:

    a. Slightly more complicated to implement

    b. extract<T>(obj) might have unexpected results
       if passed to a function template.

    c. conversions are still allowed to throw exceptions if
       convertible() returns false.

I don't consider b. to be a serious problem, but maybe someone will
disagree with me. In the spirit of "it's always easier to give than to take
away" (thanks, Dave Hawkes -- I'm learning!) I think I want to write the
function version.

------

We also need the lvalue_ptr<> class mentioned in
http://aspn.activestate.com/ASPN/Mail/Message/1237812.

There is some question about whether it can act as a full replacement for
back_reference<>, though. The difference is that back_referece<> is capable
of doing rvalue conversions - so it can hold a C++ object which isn't
actually contained within the corresponding Python object. For example, if
you have a vector<double> argument and a converter from Python tuples to
vector<double>, you might use a back_reference<vector<double> > as a
wrapped function parameter instead. Then you'd still be able to find out
what the source object was. It's also worth asking whether this
functionality is actually important.

I also have some problems with any name xxxx_ptr<> for this beast. For one
thing, we discussed the idea that this thing should derive from object.
That means it will never be nil - it will always refer to some Python
object. It will also inherit lots of nice interface to the underlying
Python object such as the ability to be indexed, sliced, etc. That just
takes it a bit too far away from being a pointer for my tastes.

I thought of wrapper<T>, but that's a little semantically strange. It *is*
a wrapper for T, but it is chiefly used to /un/wrap T objects. Furthermore,
it *will* supply at least unary operator* and operator-> to get access at
the held T object. I'm open to suggestions for naming here. So far,
wrapper<T> is the winner, but it's a little too generic for my tastes.

-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 daveh at cadlink.com  Tue Jul  2 19:31:35 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 2 Jul 2002 13:31:35 -0400
Subject: [C++-sig] object lifecycle
Message-ID: <afso0q$n42$1@main.gmane.org>

I was just reviewing some of the recent changes to the structure of object
and noticed that it now holds a PyObject* directly, rather than a handle<>.
However I'm not sure how an object gets cleaned up after it is destroyed as
no destructor is defined. I'm sure I must be missing something obvious here,
but I can't see how the reference count of the controlled PyObject* is
managed?

Thanks
Dave Hawkes









From david.abrahams at rcn.com  Tue Jul  2 19:45:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 13:45:41 -0400
Subject: [C++-sig] object lifecycle
References: <afso0q$n42$1@main.gmane.org>
Message-ID: <14a501c221f0$d0508240$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Tuesday, July 02, 2002 1:31 PM
Subject: [C++-sig] object lifecycle


> I was just reviewing some of the recent changes to the structure of
object
> and noticed that it now holds a PyObject* directly, rather than a
handle<>.
> However I'm not sure how an object gets cleaned up after it is destroyed
as
> no destructor is defined. I'm sure I must be missing something obvious
here,
> but I can't see how the reference count of the controlled PyObject* is
> managed?

No, you're not missing anything -- you're the man!
Thanks for checking my work.

I'll check in a fix forthwith.

-Dave






From rwgk at yahoo.com  Tue Jul  2 20:15:49 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 11:15:49 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
In-Reply-To: <147501c221eb$d76b9ba0$6501a8c0@boostconsulting.com>
Message-ID: <20020702181549.8101.qmail@web20205.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> I don't consider b. to be a serious problem, but maybe someone will
> disagree with me. In the spirit of "it's always easier to give than to take
> away" (thanks, Dave Hawkes -- I'm learning!) I think I want to write the
> function version.

Would I want to use extract<T>() in a revision of struct
register_container_from_python_sequence posted earlier?
Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Tue Jul  2 20:41:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 14:41:53 -0400
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
References: <20020702181549.8101.qmail@web20205.mail.yahoo.com>
Message-ID: <14df01c221f8$88d176b0$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > I don't consider b. to be a serious problem, but maybe someone will
> > disagree with me. In the spirit of "it's always easier to give than to
take
> > away" (thanks, Dave Hawkes -- I'm learning!) I think I want to write
the
> > function version.
>
> Would I want to use extract<T>() in a revision of struct
> register_container_from_python_sequence posted earlier?

I don't think so; consider: what T would you extract?

-Dave





From rwgk at yahoo.com  Tue Jul  2 22:58:41 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 13:58:41 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
In-Reply-To: <14df01c221f8$88d176b0$6501a8c0@boostconsulting.com>
Message-ID: <20020702205841.20066.qmail@web20201.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > Would I want to use extract<T>() in a revision of struct
> > register_container_from_python_sequence posted earlier?
> 
> I don't think so; consider: what T would you extract?

T = container_element_type const& or container_element_type:

    static void* convertible(PyObject* obj_ptr)
    {
      //...
      for(std::size_t i=0;i<seq.size();i++) {
        handle<> seq_i = seq[i]; // VC6 requires step-by-step expressions
>>>>    arg_from_python<container_element_type const&> from_py(seq_i.get());
        if (!from_py.convertible()) return 0;
      }
      return obj_ptr;
    }

    static void construct(
      PyObject* obj_ptr, boost::python::converter::rvalue_stage1_data* data)
    {
      //...
      for(std::size_t i=0;i<seq.size();i++) {
        ContainerAdaptor::set_value(result, i,
>>>>    extractor<container_element_type>::get(seq[i]));
      }
    }
  };


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Tue Jul  2 23:08:15 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 17:08:15 -0400
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
References: <20020702205841.20066.qmail@web20201.mail.yahoo.com>
Message-ID: <15a501c2220c$b7f6c530$6501a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > Would I want to use extract<T>() in a revision of struct
> > > register_container_from_python_sequence posted earlier?
> >
> > I don't think so; consider: what T would you extract?
>
> T = container_element_type const& or container_element_type:
>
>     static void* convertible(PyObject* obj_ptr)
>     {
>       //...
>       for(std::size_t i=0;i<seq.size();i++) {
>         handle<> seq_i = seq[i]; // VC6 requires step-by-step expressions
> >>>>    arg_from_python<container_element_type const&>
from_py(seq_i.get());
>         if (!from_py.convertible()) return 0;
>       }
>       return obj_ptr;
>     }
>
>     static void construct(
>       PyObject* obj_ptr, boost::python::converter::rvalue_stage1_data*
data)
>     {
>       //...
>       for(std::size_t i=0;i<seq.size();i++) {
>         ContainerAdaptor::set_value(result, i,
> >>>>    extractor<container_element_type>::get(seq[i]));
>       }
>     }
>   };
>

Oh, I see.
Well the problem with that is that extract<> is going to throw an exception
if it fails to find the right type, and your convertible() function should
not throw.

-Dave





From rwgk at yahoo.com  Tue Jul  2 23:26:37 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 14:26:37 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
In-Reply-To: <15a501c2220c$b7f6c530$6501a8c0@boostconsulting.com>
Message-ID: <20020702212637.40378.qmail@web20205.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Oh, I see.
> Well the problem with that is that extract<> is going to throw an exception
> if it fails to find the right type, and your convertible() function should
> not throw.

That leads me to believe that I should cast my vote (if I have one) for the
class-based extract<> implementation.
Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From hugo at adept.co.za  Tue Jul  2 18:25:56 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Tue, 2 Jul 2002 18:25:56 +0200
Subject: [C++-sig] static methods, and -ftemplate-depth observations
In-Reply-To: <107101c2214c$02fd9700$6501a8c0@boostconsulting.com>
References: <20020701204603.GA1899@vervet.localnet> <107101c2214c$02fd9700$6501a8c0@boostconsulting.com>
Message-ID: <20020702162556.GA11505@vervet.localnet>

> > This is g++ 2.95.4, David mentioned it's unsupported. With g++ 3.0.4, 35
> > is also too small, I have to push it up to 36.
> 
> OK, that's not too unexpected. I think that switching to the mpl_v2 branch
> of MPL will fix some of the instantiation-depth issues, and there will
<snip>

Thanks.

> > I'm leaving the 17 parameter constructor until I get round to dealing
> > with const float* and const Uint8* (I think this is trivial, it was in
> > V1?),
> 
> What are you trying to do with these types, exactly?

Just passing pointers to memory buffers containing two dimentional data,
such as textures. I'll get to these later. (They were trivial in V1, I'm
sure they still are quite.)

> > So does V2 do static methods yet?
> 
> Nope, but this is a good manageable project to take on, if you want to see
> it done. Take a look at libs/python/src/objects/function.cpp and
> PyStaticMethod_New(). This might be as easy as passing the
> boost::python::object::function* to PyStaticMethod_New().

Hehe. I will look at it, when I have time, I doubt today, hopefully
tomorrow though. Not being a very experienced C++ user yet, what's
"manageable" for me is probably less than for some others on the list.
But as I said, I'll take a look, if it is indeed manageable, I'm eager
to contribute. (I'll also look at that int thing if someone else hasn't
by the time I get to it - I cannot promise it'll be tomorrow... - int
sounds simple too ;)

Thanks,
Hugo




From rwgk at yahoo.com  Tue Jul  2 23:57:16 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 14:57:16 -0700 (PDT)
Subject: [C++-sig] status of auto-builds
In-Reply-To: <13b701c221d4$5cdc73d0$6501a8c0@boostconsulting.com>
Message-ID: <20020702215716.41625.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> it's a simple matter of the boost/config/suffix.hpp file detecting
> the value for BOOST_HAS_LONG_LONG differently in two different translation
> units. In libs/python/src/builtin_converters.cpp the test is coming up
> negative, while in libs/python/test/test_builtin_converters.cpp it's coming
> up positive. If you can find out which file is defining any of the
> following symbols
> 
>     ULLONG_MAX
>     ULONG_LONG_MAX
>     ULONGLONG_MAX
> 
> then we will be close to having the problem solved. I've been approaching
> it by taking the command-line which builds test_builtin_converters.o (get
> that from bjam... -n -a test_builtin_converters.o) and
> adding -DULLONG_MAX -DULONG_LONG_MAX -DULONGLONG_MAX so it would tell me
> where the conflicting definition is.

Done. The cxx 6.5 compiler does not seem to mind at all what these defines are
(I tried -DULLONG_MAX=jibberjabber -DULONG_LONG_MAX=dingdong
-DULONGLONG_MAX=klickklack). But the runtime errors are still there.
This is with the CVS state from less than an hour ago.
Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From rwgk at yahoo.com  Wed Jul  3 00:13:25 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 15:13:25 -0700 (PDT)
Subject: [C++-sig] len(list())?
Message-ID: <20020702221325.30564.qmail@web20201.mail.yahoo.com>

The V1 boost::python::list has a member function size() that does not seem to
exist anymore for the V2 list. How would I spell len(list()) in C++?
Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Wed Jul  3 00:45:18 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 18:45:18 -0400
Subject: [C++-sig] len(list())?
References: <20020702221325.30564.qmail@web20201.mail.yahoo.com>
Message-ID: <163b01c2221a$6b345100$6501a8c0@boostconsulting.com>

Using the len() function that David Hawkes is going to write, of course!

...or you could take on that simple part of the job.

-Dave
----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Tuesday, July 02, 2002 6:13 PM
Subject: [C++-sig] len(list())?


> The V1 boost::python::list has a member function size() that does not
seem to
> exist anymore for the V2 list. How would I spell len(list()) in C++?
> Thanks,
>         Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Wed Jul  3 00:37:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 18:37:47 -0400
Subject: [C++-sig] status of auto-builds
References: <20020702215716.41625.qmail@web20202.mail.yahoo.com>
Message-ID: <162601c22219$b6f4ab90$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Tuesday, July 02, 2002 5:57 PM
Subject: Re: [C++-sig] status of auto-builds


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > it's a simple matter of the boost/config/suffix.hpp file detecting
> > the value for BOOST_HAS_LONG_LONG differently in two different
translation
> > units. In libs/python/src/builtin_converters.cpp the test is coming up
> > negative, while in libs/python/test/test_builtin_converters.cpp it's
coming
> > up positive. If you can find out which file is defining any of the
> > following symbols
> >
> >     ULLONG_MAX
> >     ULONG_LONG_MAX
> >     ULONGLONG_MAX
> >
> > then we will be close to having the problem solved. I've been
approaching
> > it by taking the command-line which builds test_builtin_converters.o
(get
> > that from bjam... -n -a test_builtin_converters.o) and
> > adding -DULLONG_MAX -DULONG_LONG_MAX -DULONGLONG_MAX so it would tell
me
> > where the conflicting definition is.
>
> Done. The cxx 6.5 compiler does not seem to mind at all what these
defines are
> (I tried -DULLONG_MAX=jibberjabber -DULONG_LONG_MAX=dingdong
> -DULONGLONG_MAX=klickklack). But the runtime errors are still there.
> This is with the CVS state from less than an hour ago.
> Ralf

You compiled both translation units specified above with these defined?

It must be something else, then. Time to break out the debugger, Ralf (I
know how you love to hear that)!





From david.abrahams at rcn.com  Wed Jul  3 01:44:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 19:44:04 -0400
Subject: [C++-sig] object lifecycle
References: <afso0q$n42$1@main.gmane.org>
Message-ID: <16a801c22222$5e3095b0$6501a8c0@boostconsulting.com>

Unfortunately, fixing this bug took all day, because of the wonderful
codegen bugs in VC6 and 7. To their credit, the alpha compiler I've been
testing from Microsoft is wonderful, and doesn't have these problems.

-Dave

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Tuesday, July 02, 2002 1:31 PM
Subject: [C++-sig] object lifecycle


> I was just reviewing some of the recent changes to the structure of
object
> and noticed that it now holds a PyObject* directly, rather than a
handle<>.
> However I'm not sure how an object gets cleaned up after it is destroyed
as
> no destructor is defined. I'm sure I must be missing something obvious
here,
> but I can't see how the reference count of the controlled PyObject* is
> managed?
>
> Thanks
> Dave Hawkes
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From daveh at cadlink.com  Wed Jul  3 02:33:20 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 2 Jul 2002 20:33:20 -0400
Subject: [C++-sig] Re: object lifecycle
References: <afso0q$n42$1@main.gmane.org> <16a801c22222$5e3095b0$6501a8c0@boostconsulting.com>
Message-ID: <aftgn5$drq$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:16a801c22222$5e3095b0$6501a8c0 at boostconsulting.com...
> Unfortunately, fixing this bug took all day, because of the wonderful
> codegen bugs in VC6 and 7. To their credit, the alpha compiler I've been
> testing from Microsoft is wonderful, and doesn't have these problems.
>

Sorry to 'make your day', but I suppose these things are better fixed sooner
than later.

I'm sure the complexity of boost is beyond what many c++ implimentors
originally envisioned (especially the mpl) and there's probably not many
current compilers that can build the whole library 'clean' on any platform.
If the new MS compiler really is this good I'm hoping MS will distribute a
version of it that is library compatible with VC6 as well as VC7 for those
of us who cannot easily move their (large MFC) projects to .NET.

Dave Hawkes









From rwgk at yahoo.com  Wed Jul  3 03:12:32 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 2 Jul 2002 18:12:32 -0700 (PDT)
Subject: [C++-sig] len(list())?
In-Reply-To: <163b01c2221a$6b345100$6501a8c0@boostconsulting.com>
Message-ID: <20020703011232.52337.qmail@web20201.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Using the len() function that David Hawkes is going to write, of course!
> 
> ...or you could take on that simple part of the job.

I sure can give it a try, hang on...

Here!

int len(object const& o) { return PySequence_Size(o.ptr()); }

But now I am stuck here:

        // restore the object's __dict__
        dictionary odict(mydict);
        dictionary pdict(state_[0]);
        list pkeys(pdict.keys());
        for(std::size_t i=0;i<len(pkeys);i++) {
>>>>      //handle<> k =
>>>>      pkeys[i];
          //odict[k] = pdict.get_item(k);
        }

pkeys[i] returns an object_item, which is a typedef of proxy<> instantiated
with some policy... How do I make that a handle<>?

Thanks,
        Ralf

P.S.: IMHO the Python len() builtin function is a language wart. I find myself
spending hours/year going back and forth in the editor because I first want to
type someinstance.somemember.size(), aehm, backspace, backspace, backspace...


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Wed Jul  3 03:37:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 21:37:37 -0400
Subject: [C++-sig] len(list())?
References: <20020703011232.52337.qmail@web20201.mail.yahoo.com>
Message-ID: <16e501c22232$3a344b10$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > Using the len() function that David Hawkes is going to write, of
course!
> >
> > ...or you could take on that simple part of the job.
>
> I sure can give it a try, hang on...
>
> Here!
>
> int len(object const& o) { return PySequence_Size(o.ptr()); }
>
> But now I am stuck here:
>
>         // restore the object's __dict__
>         dictionary odict(mydict);
>         dictionary pdict(state_[0]);
>         list pkeys(pdict.keys());
>         for(std::size_t i=0;i<len(pkeys);i++) {
> >>>>      //handle<> k =
> >>>>      pkeys[i];
>           //odict[k] = pdict.get_item(k);
>         }
>
> pkeys[i] returns an object_item, which is a typedef of proxy<>
instantiated
> with some policy... How do I make that a handle<>?

It's convertible to object. Forget about handle<>.

Can you substitute object for dictionary? Then you can write:

    odict[pkeys[i]] = pdict[pkeys[i]];

> P.S.: IMHO the Python len() builtin function is a language wart. I find
myself
> spending hours/year going back and forth in the editor because I first
want to
> type someinstance.somemember.size(), aehm, backspace, backspace,
backspace...

So, len() rubs your C++ instincts the wrong way?

Free functions are nice, generically speaking, because they decouple you
from having to have a particular member function interface.

-Dave






From david.abrahams at rcn.com  Wed Jul  3 05:18:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Jul 2002 23:18:56 -0400
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
References: <20020702212637.40378.qmail@web20205.mail.yahoo.com>
Message-ID: <176301c22240$624007d0$6501a8c0@boostconsulting.com>

The thing is, you still need a try/catch block for your application,
because even though the convertible() function won't throw, the function
which does the actual conversion might throw.

So in your case you can gain some efficiency in overload resolution when
conversion fails, by detecting that conversion will fail without using a
C++ exception, but you'll still need the code to handle one. Does that
change your vote?

BTW, I'm now inclined to go your way on this ;-)

-Dave

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > Oh, I see.
> > Well the problem with that is that extract<> is going to throw an
exception
> > if it fails to find the right type, and your convertible() function
should
> > not throw.
>
> That leads me to believe that I should cast my vote (if I have one) for
the
> class-based extract<> implementation.
> Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From greghawkins at blueyonder.co.uk  Wed Jul  3 13:24:57 2002
From: greghawkins at blueyonder.co.uk (greghawkins at blueyonder.co.uk)
Date: Wed, 3 Jul 2002 12:24:57 +0100
Subject: [C++-sig] v2, gcc and stlport 4.5.3
Message-ID: <3409101c22284$43123790$7735bcc3@blueyonder.net>

Just a quick note...

Having just switched to the gcc-stlport toolset, I had change the following two lines of my boost/tools/build/gcc-stlport-tools.jam file to get the python v2 test executables to build. (gcc 3.0.4, stlport 4.5.3, mandrake 8.2 - v2 itself and other boost libs build fine).

from:

flags gcc-stlport FINDLIBS <runtime-link>dynamic/<runtime-build>debug    : stlport_$(GCC_STLPORT_LIB_ID)_stldebug ;
flags gcc-stlport FINDLIBS <runtime-link>dynamic/<runtime-build>release  : stlport_$(GCC_STLPORT_LIB_ID) ;

to

flags gcc-stlport FINDLIBS <runtime-link>dynamic/<runtime-build>debug    : stlport_$(GCC_STLPORT_LIB_ID)_stldebug pthread ;
flags gcc-stlport FINDLIBS <runtime-link>dynamic/<runtime-build>release  : stlport_$(GCC_STLPORT_LIB_ID) pthread ;

Otherwise the executables failed to build with 'libstlport_gcc_[stldebug].so: undefined reference to pthread_XXX' type errors.

I guess the tools file is probably the wrong place to hack this in? Is there something better I should be doing?

best,
Greg




From rwgk at yahoo.com  Wed Jul  3 14:05:37 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 3 Jul 2002 05:05:37 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
In-Reply-To: <176301c22240$624007d0$6501a8c0@boostconsulting.com>
Message-ID: <20020703120537.3424.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> So in your case you can gain some efficiency in overload resolution when
> conversion fails, by detecting that conversion will fail without using a
> C++ exception, but you'll still need the code to handle one. Does that
> change your vote?

It is not only efficiency: as we all know exception handling is unreliable on
some platforms. If we can get overload resolution to work without exception
handling "under normal circumstances" it can make a big difference in the real
world. I might be able to tolerate a crash (due to buggy exception handling) if
there is a "true" error/problem. However, if the application relys on exception
handling as a trick for dealing with "normal" situations (i.e. V1 overload
resolution) I might have to say that a certain platform cannot be used at all.
Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From rwgk at yahoo.com  Wed Jul  3 14:19:47 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 3 Jul 2002 05:19:47 -0700 (PDT)
Subject: [C++-sig] status of auto-builds
In-Reply-To: <162601c22219$b6f4ab90$6501a8c0@boostconsulting.com>
Message-ID: <20020703121947.5695.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> You compiled both translation units specified above with these defined?

No, sorry, I missed that. I was just looking at test_builtin_converters.cpp.
Attached is the result for builtin_converters.cpp. Is this what you exected?
Thanks,
        Ralf

cxx -DULLONG_MAX -DULONG_LONG_MAX -DULONGLONG_MAX -ptr
"/net/redbelly/scratch1/rwgk/bjam/libs/python/bin/libbpl.so/tru64cxx65/debug"
-c -std strict_ansi -msg_display_number -msg_disable 186,450,1115
-DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE -g -O0
-inline none -I"/net/redbelly/scratch1/rwgk/bjam/libs/python"
-I"../../../libs/python" -I"/usr/local_cci/Python-2.2.1/include/python2.2"
-I"/tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas" -o
"/net/redbelly/scratch1/rwgk/bjam/libs/python/bin/libbpl.so/tru64cxx65/debug/builtin_converters.o"
"../../../libs/python/src/converter/builtin_converters.cpp"

cxx: Error: /tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/cast.hpp, line
303: #94 
          the size of an array must be greater than zero
          detected during instantiation of "Target
                    boost::numeric_cast<Target,Source>(Source) [with
                    Target=long long, Source=double]" at line 138 of
                    "../../../libs/python/src/converter/builtin_converters.cpp"
        typedef bool result_must_be_numeric[result_traits::is_specialized];
--------------------------------------------^
cxx: Error: /tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/cast.hpp, line
303: #94 
          the size of an array must be greater than zero
          detected during instantiation of "Target
                    boost::numeric_cast<Target,Source>(Source) [with
                    Target=unsigned long long, Source=long]" at line 158 of
                    "../../../libs/python/src/converter/builtin_converters.cpp"
        typedef bool result_must_be_numeric[result_traits::is_specialized];
--------------------------------------------^
cxx: Error: /tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/cast.hpp, line
303: #94 
          the size of an array must be greater than zero
          detected during instantiation of "Target
                    boost::numeric_cast<Target,Source>(Source) [with
                    Target=unsigned long long, Source=double]" at line 162 of
                    "../../../libs/python/src/converter/builtin_converters.cpp"
        typedef bool result_must_be_numeric[result_traits::is_specialized];
--------------------------------------------^
cxx: Info: 3 errors detected in the compilation of
"../../../libs/python/src/converter/builtin_converters.cpp".


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Wed Jul  3 14:43:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 08:43:37 -0400
Subject: [C++-sig] Boost.Python v2: user-accessible from_python conversions
References: <20020703120537.3424.qmail@web20209.mail.yahoo.com>
Message-ID: <185901c2228f$cf550b00$6501a8c0@boostconsulting.com>

OK, a class it shall be!

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, July 03, 2002 8:05 AM
Subject: Re: [C++-sig] Boost.Python v2: user-accessible from_python
conversions


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > So in your case you can gain some efficiency in overload resolution
when
> > conversion fails, by detecting that conversion will fail without using
a
> > C++ exception, but you'll still need the code to handle one. Does that
> > change your vote?
>
> It is not only efficiency: as we all know exception handling is
unreliable on
> some platforms. If we can get overload resolution to work without
exception
> handling "under normal circumstances" it can make a big difference in the
real
> world. I might be able to tolerate a crash (due to buggy exception
handling) if
> there is a "true" error/problem. However, if the application relys on
exception
> handling as a trick for dealing with "normal" situations (i.e. V1
overload
> resolution) I might have to say that a certain platform cannot be used at
all.
> Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Wed Jul  3 14:44:59 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 08:44:59 -0400
Subject: [C++-sig] status of auto-builds
References: <20020703121947.5695.qmail@web20209.mail.yahoo.com>
Message-ID: <185a01c2228f$cf738f80$6501a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> > You compiled both translation units specified above with these defined?
>
> No, sorry, I missed that. I was just looking at
test_builtin_converters.cpp.
> Attached is the result for builtin_converters.cpp. Is this what you
exected?

Nope, I'm confused by that, for sure.

-Dave






From rwgk at yahoo.com  Wed Jul  3 14:52:18 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 3 Jul 2002 05:52:18 -0700 (PDT)
Subject: [C++-sig] len(list())?
In-Reply-To: <16e501c22232$3a344b10$6501a8c0@boostconsulting.com>
Message-ID: <20020703125218.37460.qmail@web20201.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> It's convertible to object. Forget about handle<>.
>
> Can you substitute object for dictionary? Then you can write:
>
>     odict[pkeys[i]] = pdict[pkeys[i]];

This doesn't work at the moment. FYI the error message is attached.
I realize that the offending code is meant to be replaced.

Right now, this is what I am using:

        for(std::size_t i=0;i<len(pkeys);i++) {
          handle<> k(borrowed(object(pkeys[i]).ptr()));
          odict[k] = pdict.get_item(k);
        }

> So, len() rubs your C++ instincts the wrong way?

It looks like "old style" to me. But maybe I am just not yet
emancipated from my Fortran past.

> Free functions are nice, generically speaking, because they decouple you
> from having to have a particular member function interface.

Hm. Is this really true in the context of Python? __len__
is a member function (well, method, in Python speak).

Anyhow, here is what I really want to say: please give us both
.size() and len(). (This will be the one and only time that
you see me arguing for this.)

Ralf

cxx: Error:
/tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/python/objects2.hpp, line
215: #20 
          identifier "make_ref" is undefined
          detected during instantiation of "boost::python::dictionary::proxy
                    boost::python::dictionary::operator[](const Key &) [with
                    Key=boost::python::api::object]" at line 108 of
                    "pickle3.cpp"
        { return this->operator[](make_ref(key)); }
----------------------------------^


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Wed Jul  3 15:07:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 09:07:44 -0400
Subject: [C++-sig] len(list())?
References: <20020703125218.37460.qmail@web20201.mail.yahoo.com>
Message-ID: <189501c22292$aa9e35e0$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > It's convertible to object. Forget about handle<>.
> >
> > Can you substitute object for dictionary? Then you can write:
> >
> >     odict[pkeys[i]] = pdict[pkeys[i]];
>
> This doesn't work at the moment.

It works if you substitute "object" for "dictionary", as I suggested.

> > Free functions are nice, generically speaking, because they decouple
you
> > from having to have a particular member function interface.
>
> Hm. Is this really true in the context of Python?

Maybe not. It really gets interesting when there are multiple arguments...
but Python doesn't have multimethods, yet.

> __len__
> is a member function (well, method, in Python speak).
>
> Anyhow, here is what I really want to say: please give us both
> .size() and len(). (This will be the one and only time that
> you see me arguing for this.)

Can you live with x.attr("__len__")() <wink>?

-Dave






From david.abrahams at rcn.com  Wed Jul  3 15:15:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 09:15:57 -0400
Subject: [C++-sig] v2, gcc and stlport 4.5.3
References: <3409101c22284$43123790$7735bcc3@blueyonder.net>
Message-ID: <18a101c22293$c566c9e0$6501a8c0@boostconsulting.com>


From rwgk at yahoo.com  Wed Jul  3 15:34:04 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 3 Jul 2002 06:34:04 -0700 (PDT)
Subject: [C++-sig] len(list())?
In-Reply-To: <189501c22292$aa9e35e0$6501a8c0@boostconsulting.com>
Message-ID: <20020703133404.45349.qmail@web20201.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> It works if you substitute "object" for "dictionary", as I suggested.

Yes, indeed. Thanks.

The context:

        // restore the object's __dict__
        object odict(mydict);
        object pdict(state_[0]);
        list pkeys(dictionary(mydict).keys());
        for(std::size_t i=0;i<len(pkeys);i++) {
          odict[pkeys[i]] = pdict[pkeys[i]];
        }

What can be said about

odict[pkeys[i]] = pdict[pkeys[i]];

versus

object k(pkeys[i]);
odict[k] = pdict[k];

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Wed Jul  3 15:42:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 09:42:37 -0400
Subject: [C++-sig] len(list())?
References: <20020703133404.45349.qmail@web20201.mail.yahoo.com>
Message-ID: <18fd01c22297$7ecd3920$6501a8c0@boostconsulting.com>

----- Original Message ----- 
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, July 03, 2002 9:34 AM
Subject: Re: [C++-sig] len(list())?


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > It works if you substitute "object" for "dictionary", as I suggested.
> 
> Yes, indeed. Thanks.
> 
> The context:
> 
>         // restore the object's __dict__
>         object odict(mydict);
>         object pdict(state_[0]);
>         list pkeys(dictionary(mydict).keys());
>         for(std::size_t i=0;i<len(pkeys);i++) {
>           odict[pkeys[i]] = pdict[pkeys[i]];
>         }
> 
> What can be said about
> 
> odict[pkeys[i]] = pdict[pkeys[i]];
> 
> versus
> 
> object k(pkeys[i]);
> odict[k] = pdict[k];

Not much. Mostly that the latter is more-efficient.
But why don't you rewrite the whole thing:

    odict.attr("update")(pdict);

When we have a dict class you'll be able to write

    odict.update(pdict)

Isn't it nice to be able to write Python in C++ <.002 wink>?

-Dave







From rwgk at yahoo.com  Wed Jul  3 18:46:23 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 3 Jul 2002 09:46:23 -0700 (PDT)
Subject: [C++-sig] len(list())?
In-Reply-To: <18fd01c22297$7ecd3920$6501a8c0@boostconsulting.com>
Message-ID: <20020703164623.8750.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
>     odict.attr("update")(pdict);
> 
> When we have a dict class you'll be able to write
> 
>     odict.update(pdict)
> 
> Isn't it nice to be able to write Python in C++ <.002 wink>?

It sure is cool, but the number of times where this pays off in our environment
is minute. I am still longing for a feature that will have a *much* bigger
payoff for us: a mechanism for easing the burden of writing thin wrappers.
E.g.:

namespace {

int my_function(int i=0, int j=1, int k=2);

BOOST_PYTHON_WRAPPER_STUBS(my_function)

}

Later:

.def(my_function_stubs, args<int>())
.def(my_function_stubs, args<int, int>())
.def(my_function_stubs, args<int, int, int>())

Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Wed Jul  3 19:34:25 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 13:34:25 -0400
Subject: [C++-sig] len(list())?
References: <20020703164623.8750.qmail@web20202.mail.yahoo.com>
Message-ID: <1a5d01c222b8$00696830$6501a8c0@boostconsulting.com>

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


>  I am still longing for a feature that will have a *much* bigger
> payoff for us: a mechanism for easing the burden of writing thin
wrappers.
> E.g.:
>
> namespace {
>
> int my_function(int i=0, int j=1, int k=2);
>
> BOOST_PYTHON_WRAPPER_STUBS(my_function)
>
> }
>
> Later:
>
> .def(my_function_stubs, args<int>())
> .def(my_function_stubs, args<int, int>())
> .def(my_function_stubs, args<int, int, int>())

That might be possible. Sounds like a meta-lot of fun to implement ;-)

-Dave






From david.abrahams at rcn.com  Wed Jul  3 20:01:33 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 14:01:33 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
Message-ID: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com>

I am really anxious to release v2 of Boost.Python to the world; it was
supposed to happen one month ago, but it looks like we're running a bit
behind on that schedule.

Here is a list of things I think need to be handled before the v2 release.
All new implementation of course implicitly involves testing and
documentation. I have labelled jobs which other people have volunteered
for; please let me know if I got something wrong, or if I've missed
anything crucial:

-----

Pickling support (thanks, Ralf!)

-----

Replacements for objects.hpp contents (thanks, Achim!)
This means: str, dict, tuple
Other types like: type, int_, slice, etc. are optional for the v2 release,
since they weren't covered in v1.

------

At least some of the builtin functions need to be implemented. For example,
len(). So far I have Dave Hawkes as having volunteered for this job. Dave,
please confirm.

------

Replace handle<> by object in as many public interfaces as possible.

It may not be possible, but I hope to be able to avoid documenting
handle<>, upcast<>, downcast<>, base_type_traits<>, borrowed, allow_null,
refcount. for the v2 release this way. The less documentation needed, the
sooner v2 can be released and the less confusing everything will be.

------

Some publicly-accessible facility for from_python conversion. See
http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1265634

I guess we are leaning towards using an extractor<> class at this point.

-----

Re-work the module interface using the work of Dave Hawkes so no module
objects need to be declared unless you're creating a submodule.

I would put this off, but it's a major change to the interface and can
actually result in a substantial usability improvement. I'd rather release
v2 with the change.

-----

File and namespace shuffling:
contents of boost::python::api to an api/ subdirectory
boost::python::arg_from_python and

-----
Documentation for already-implemented components:

    object.hpp
    list.hpp
    long.hpp
    pointee.hpp
    Overview (Tutorial)
    Configuration (Building)
    Rationale (?)
    FAQ
    Bibliography
    Acknowledgements
    (optional) Overview of internals (Thanks Martin and Joel!)

+---------------------------------------------------------------+
                  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 daveh at cadlink.com  Wed Jul  3 20:23:57 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 3 Jul 2002 14:23:57 -0400
Subject: [C++-sig] Re: Boost.Python V2: list implementation
References: <09b301c21fa3$6f700da0$6501a8c0@boostconsulting.com>
Message-ID: <afvff9$2q2$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:09b301c21fa3$6f700da0$6501a8c0 at boostconsulting.com...
> I have just checked in the implementation of the Python list class
wrapper!
> Tests in libs/python/test/list.[cpp/py].
>
> This opens up the possibility of implementing the other built-in types:
> tuple, dict, str, int_, long_, et. al.

What about the other built-in types that are already implemented such as
modules and functions, should those now be re-written in terms of object?

Dave Hawkes









From daveh at cadlink.com  Wed Jul  3 20:34:41 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 3 Jul 2002 14:34:41 -0400
Subject: [C++-sig] Re: Outstanding Jobs for v2 release
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com>
Message-ID: <afvg38$45h$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1a7901c222bb$c82bfd30$6501a8c0 at boostconsulting.com...
>
> At least some of the builtin functions need to be implemented. For
example,
> len(). So far I have Dave Hawkes as having volunteered for this job. Dave,
> please confirm.
>

I'll try and get this completed over the next couple of weeks, together with
some of the other items I've been working on.

> ------
>
> Replace handle<> by object in as many public interfaces as possible.
>
> It may not be possible, but I hope to be able to avoid documenting
> handle<>, upcast<>, downcast<>, base_type_traits<>, borrowed, allow_null,
> refcount. for the v2 release this way. The less documentation needed, the
> sooner v2 can be released and the less confusing everything will be.
>

Currently there is no direct way to create a handle<> from an object, should
this be implemented?

> ------
>
> Some publicly-accessible facility for from_python conversion. See
> http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1265634
>
> I guess we are leaning towards using an extractor<> class at this point.
>
> -----
>
> Re-work the module interface using the work of Dave Hawkes so no module
> objects need to be declared unless you're creating a submodule.

I've been using this code for a while now, and merging with successive
changes (that's why I noticed the object problem). If the basic structure is
now stable I'll do a final tidy up and submit what I have.

> Documentation for already-implemented components:
>
>     object.hpp
>     list.hpp
>     long.hpp
>     pointee.hpp
>     Overview (Tutorial)
>     Configuration (Building)
>     Rationale (?)
>     FAQ
>     Bibliography
>     Acknowledgements
>     (optional) Overview of internals (Thanks Martin and Joel!)
>

I have a small embedding example that I've been working on occasionally
which provides solutions for some of the (embedding) implementation
questions that often arise, such as how to self import, multiple built-in
boost modules in one executable, etc.

Dave Hawkes









From david.abrahams at rcn.com  Wed Jul  3 20:48:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 14:48:41 -0400
Subject: [C++-sig] Re: Boost.Python V2: list implementation
References: <09b301c21fa3$6f700da0$6501a8c0@boostconsulting.com> <afvff9$2q2$1@main.gmane.org>
Message-ID: <1ab001c222c2$464f30f0$6501a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>


> What about the other built-in types that are already implemented such as
> modules and functions, should those now be re-written in terms of object?

I think we're safe <wink>:

>>> function
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'function' is not defined


OTOH, I would like to have an object derived class called 'callable'.

>>> module
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'module' is not defined>


Seriously, though, when we adopt your module interface changes, your idea
of making an object-derived class for module might be a good one.

-Dave






From david.abrahams at rcn.com  Wed Jul  3 20:52:19 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Jul 2002 14:52:19 -0400
Subject: [C++-sig] Re: Outstanding Jobs for v2 release
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com> <afvg38$45h$1@main.gmane.org>
Message-ID: <1ab801c222c2$fa43c3a0$6501a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> >
> > At least some of the builtin functions need to be implemented. For
> example,
> > len(). So far I have Dave Hawkes as having volunteered for this job.
Dave,
> > please confirm.
> >
>
> I'll try and get this completed over the next couple of weeks, together
with
> some of the other items I've been working on.

Thanks. It would be great if we could coordinate so that I know what
progress you're making during this period.

> > ------
> >
> > Replace handle<> by object in as many public interfaces as possible.
> >
> > It may not be possible, but I hope to be able to avoid documenting
> > handle<>, upcast<>, downcast<>, base_type_traits<>, borrowed,
allow_null,
> > refcount. for the v2 release this way. The less documentation needed,
the
> > sooner v2 can be released and the less confusing everything will be.
> >
>
> Currently there is no direct way to create a handle<> from an object,
should
> this be implemented?

Not if we can avoid it. Part of my strategy is to avoid exposing handle<>
to users, at least for the time being.

> > -----
> >
> > Re-work the module interface using the work of Dave Hawkes so no module
> > objects need to be declared unless you're creating a submodule.
>
> I've been using this code for a while now, and merging with successive
> changes (that's why I noticed the object problem). If the basic structure
is
> now stable I'll do a final tidy up and submit what I have.

I think it is.

> > Documentation for already-implemented components:
> >
> >     object.hpp
> >     list.hpp
> >     long.hpp
> >     pointee.hpp
> >     Overview (Tutorial)
> >     Configuration (Building)
> >     Rationale (?)
> >     FAQ
> >     Bibliography
> >     Acknowledgements
> >     (optional) Overview of internals (Thanks Martin and Joel!)
> >
>
> I have a small embedding example that I've been working on occasionally
> which provides solutions for some of the (embedding) implementation
> questions that often arise, such as how to self import, multiple built-in
> boost modules in one executable, etc.

Absolutely, embedding is really important. I'm looking forward to getting
this into the docs.

-Dave






From hoel at germanlloyd.org  Fri Jul  5 14:31:36 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 05 Jul 2002 14:31:36 +0200
Subject: [C++-sig] Embedding example anyone?
Message-ID: <sewusaicev.fsf@pc970145.GermanLloyd.de>

Hello,

Can anyone provide with an example of embedding Python in my on
application using boost? I'm especially interested in wrapping Python
classes for use in C++. Is the any support for something like this in
boost?

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From okuda1 at llnl.gov  Sat Jul  6 00:16:36 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Fri, 05 Jul 2002 15:16:36 -0700
Subject: [C++-sig] static function returning integer problem
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com> <afvg38$45h$1@main.gmane.org> <1ab801c222c2$fa43c3a0$6501a8c0@boostconsulting.com>
Message-ID: <3D261AC4.E9ADEA12@llnl.gov>

I have problem making the following code work:

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

struct Num {
   Num() {}
   ~Num() {}
   static int getDims() {return 3;}
   int dims() {return 5;}
};

BOOST_PYTHON_MODULE_INIT(numTest)
{
   using namespace boost::python;
   module numTestMod("numTest");
   numTestMod
      .add
      ( class_<Num>("Num")
        .def_init()
        .def("getDims",&Num::getDims)
        .def("dims", &Num::dims)
        )
      ;
}

dims returns 5 but getDims cause "TypeError: bad argument type for
built-in operation".

Is there a way to return 3 instead of TypeError?
Thank you
Chuzo




From david.abrahams at rcn.com  Sat Jul  6 00:21:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 5 Jul 2002 18:21:27 -0400
Subject: [C++-sig] static function returning integer problem
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com> <afvg38$45h$1@main.gmane.org> <1ab801c222c2$fa43c3a0$6501a8c0@boostconsulting.com> <3D261AC4.E9ADEA12@llnl.gov>
Message-ID: <1f6801c22472$6030d580$6501a8c0@boostconsulting.com>

We don't have a way to make true static methods yet.
getDims will work fine if you access it through the class like this:

    Nums.getDims()

but not if you access it through the instance
    
    n = Nums()
    n.getDims() # error

-Dave


----- Original Message ----- 
From: "chuzo okuda" <okuda1 at llnl.gov>
To: <c++-sig at python.org>
Sent: Friday, July 05, 2002 6:16 PM
Subject: [C++-sig] static function returning integer problem


> I have problem making the following code work:
> 
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> 
> struct Num {
>    Num() {}
>    ~Num() {}
>    static int getDims() {return 3;}
>    int dims() {return 5;}
> };
> 
> BOOST_PYTHON_MODULE_INIT(numTest)
> {
>    using namespace boost::python;
>    module numTestMod("numTest");
>    numTestMod
>       .add
>       ( class_<Num>("Num")
>         .def_init()
>         .def("getDims",&Num::getDims)
>         .def("dims", &Num::dims)
>         )
>       ;
> }
> 
> dims returns 5 but getDims cause "TypeError: bad argument type for
> built-in operation".
> 
> Is there a way to return 3 instead of TypeError?
> Thank you
> Chuzo
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From achim.domma at syynx.de  Sun Jul  7 22:18:53 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 7 Jul 2002 22:18:53 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAAEHMDIAA.achim.domma@syynx.de>

Hi Dave,

> Replacements for objects.hpp contents (thanks, Achim!)
> This means: str, dict, tuple
> Other types like: type, int_, slice, etc. are optional for the v2 release,
> since they weren't covered in v1.

I have str, dict and tuple compiled into bpl, but had no time to test at
all. I lost some days, due to a major problem with our provider (I was not
able to send/recive email for 2 days).  I think I will have a version with
test in the next 2-3 days. I still have some questions, but I think they are
only cosmetic ones and are better discussed (or explained) if you have
looked at my code.
If my code is ok for you, I would also implement the optional classes.

Achim






From daveh at cadlink.com  Mon Jul  8 01:37:38 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 7 Jul 2002 19:37:38 -0400
Subject: [C++-sig] Re: Outstanding Jobs for v2 release
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com> <FCEMIEFBFOIDAOJDEPIAAEHMDIAA.achim.domma@syynx.de>
Message-ID: <agajam$47f$1@main.gmane.org>

Hi Achim,

Have you decided on a definitive list of what native python types you will
be supporting? I'm curious to know as it has a slight impact on some of the
work I'm doing to support the python API. For example, are you likely to be
able to support the lesser used types such as unicode?

Thanks,
Dave Hawkes


"Achim Domma" <achim.domma at syynx.de> wrote in message
news:FCEMIEFBFOIDAOJDEPIAAEHMDIAA.achim.domma at syynx.de...
> Hi Dave,
>
> > Replacements for objects.hpp contents (thanks, Achim!)
> > This means: str, dict, tuple
> > Other types like: type, int_, slice, etc. are optional for the v2
release,
> > since they weren't covered in v1.
>
> I have str, dict and tuple compiled into bpl, but had no time to test at
> all. I lost some days, due to a major problem with our provider (I was not
> able to send/recive email for 2 days).  I think I will have a version with
> test in the next 2-3 days. I still have some questions, but I think they
are
> only cosmetic ones and are better discussed (or explained) if you have
> looked at my code.
> If my code is ok for you, I would also implement the optional classes.
>
> Achim








From david.abrahams at rcn.com  Mon Jul  8 02:25:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 7 Jul 2002 20:25:02 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAAEHMDIAA.achim.domma@syynx.de>
Message-ID: <01f101c22615$e7d37980$6601a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>


> Hi Dave,
>
> > Replacements for objects.hpp contents (thanks, Achim!)
> > This means: str, dict, tuple
> > Other types like: type, int_, slice, etc. are optional for the v2
release,
> > since they weren't covered in v1.
>
> I have str, dict and tuple compiled into bpl

Super!

> , but had no time to test at all.

As I indicated previously, the implementation is the easy part ;-).

> I lost some days, due to a major problem with our provider (I was not
> able to send/recive email for 2 days).

That's always disorienting, but also good for my productivity <wink>.

> I think I will have a version with
> test in the next 2-3 days. I still have some questions, but I think they
are
> only cosmetic ones and are better discussed (or explained) if you have
> looked at my code.
> If my code is ok for you, I would also implement the optional classes.

That would be great. Please try to discuss this a bit on the list with Dave
Hawkes, since some things fall in a gray area, e.g. xtime().

Thanks again,
Dave






From daveh at cadlink.com  Mon Jul  8 17:10:07 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 8 Jul 2002 11:10:07 -0400
Subject: [C++-sig] Re: Outstanding Jobs for v2 release
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com> <FCEMIEFBFOIDAOJDEPIAAEHMDIAA.achim.domma@syynx.de> <agajam$47f$1@main.gmane.org>
Message-ID: <agc9v6$oa5$1@main.gmane.org>

Just to get the ball rolling I've compiled an initial list of primary
built-in types that could be supported (possibly incomplete as yet). I'm not
saying that all these should be supported, just that there is agreement as
to what ones will be supported. Any comments?


Type                          Status
====                          =======

buffer                        ?
builtin_function_or_method    ?
class                         ?
code                          ?
complex                       ?
dict                          ?
dict-proxy                    ?
ellipsis                      ?
file                          ?
float                         ?
frame                         ?
function                      ?
generator                     ?
instance                      ?
int                           ?
iterator                      ?
lambda                        ?
list                          ?
long                          ?
method_descriptor             ?
module                        ?
none                          ?
object                        ?
slice                         ?
string                        ?
traceback                     ?
tuple                         ?
type                          ?
unboundmethod                 ?
unicode                       ?
weakproxy                     ?
weakref                       ?
wrapper_descriptor            ?
xrange                        ?



Dave Hawkes








From david.abrahams at rcn.com  Mon Jul  8 17:19:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 11:19:46 -0400
Subject: [C++-sig] Re: Outstanding Jobs for v2 release
References: <1a7901c222bb$c82bfd30$6501a8c0@boostconsulting.com> <FCEMIEFBFOIDAOJDEPIAAEHMDIAA.achim.domma@syynx.de> <agajam$47f$1@main.gmane.org> <agc9v6$oa5$1@main.gmane.org>
Message-ID: <045001c22692$e60bd110$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>


> Just to get the ball rolling I've compiled an initial list of primary
> built-in types that could be supported (possibly incomplete as yet). I'm
not
> saying that all these should be supported, just that there is agreement
as
> to what ones will be supported. Any comments?

I've rated them as to their perceived importance (to me, of course):

> Type                          Status
> ====                          =======
>
> buffer                        ? -1
> builtin_function_or_method    ? -1
> class                         ? 0
> code                          ? -1
> complex                       ? +1
> dict                          ? +1
> dict-proxy                    ? 0
> ellipsis                      ? -1
> file                          ? 0
> float                         ? +1
> frame                         ? -1
> function                      ? -1
> generator                     ? 0
> instance                      ? 0
> int                           ? +1
> iterator                      ? +1
> lambda                        ? -1
> list                          ? +1
> long                          ? +1
> method_descriptor             ? -1
> module                        ? +1
> none                          ? +1
> object                        ? clashes with existing object class
> slice                         ? +1
> string                        ? +1
> traceback                     ? 0
> tuple                         ? +1
> type                          ? +1
> unboundmethod                 ? -1
> unicode                       ? +1
> weakproxy                     ? 0
> weakref                       ? +1
> wrapper_descriptor            ? 0
> xrange                        ? +1

-Dave





From marimont at nxpdata.com  Mon Jul  8 19:20:04 2002
From: marimont at nxpdata.com (David Marimont)
Date: Mon, 08 Jul 2002 10:20:04 -0700
Subject: [C++-sig] choosing a python-c++ interface: a few questions
Message-ID: <3D29C9C4.9050608@nxpdata.com>

I'm shopping around for an interface from python to C++.  I'll
eventually have to deliver code entirely in C++, but I'd like to use
python as much as possible in the development process.  My strategy
will be to use python for testing new data structures, algorithms
etc., and then once I'm confident they work, "push them down" into
C++, write python on top of that, push that down into C++, etc.  So my
initial take is that I need to call python from C++, but not having
developed this way before, I probably shouldn't be too sure about
that.

I should add that I'm not an experienced C++ programmer.  I plan to
keep the C++ I write simple and do as much as I can with existing
libraries.

The software I'll be writing involves image processing and analysis,
and both numerical and combinatorial optimization.  I anticipate heavy
use of the STL, as well as something like the template numerical
toolkit, which is "a successor to the Lapack++, Sparselib++, IML++,
and MV++ packages" (according to its website at
http://math.nist.gov/tnt/).  There are some other C++ libraries for
computer vision and image processing I'll be using also.

My general question is whether boost is the right choice for creating
the interfaces I need.  But I have a few specific questions as well:

1. Are interfaces to the C++ standard library are part of the existing
Boost Python Library?

2. Can interfaces be generated automatically from C++ source code?

3. If the answer to either of these questions is no, will that change
in version 2?

I've only been reading this list for a week or so now, so I'm not sure
I'm addressing these questions to the right people.  Any help you
could give me, including pointers to other places to get these
questions answered, is much appreciated!

   David Marimont
   http://www.nxpdata.com












From david.abrahams at rcn.com  Mon Jul  8 21:37:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 15:37:32 -0400
Subject: [C++-sig] Supporting container conversions
Message-ID: <055f01c226b7$5fb20c90$6601a8c0@boostconsulting.com>

I've been massageing some of the from_python converter code in order to
prepare to make the extract<> class, and was thinking about trying to
support Ralf's code which converts arbitrary Python iterable objects to C++
containers. Ralf wants to make a single pass over the Python sequence in
order to determine convertibility. For some sequences, this might in fact
be crucial, since it might not be possible to make multiple passes over the
sequence (e.g. input streams). The plan up to now has been to allow the
converter to optionally construct the result rvalue during the
"convertible()" check instead of during the "construct()" function. To do
that, it would have to have access to the rvalue_from_python_data<> object
which stores the result of the conversion, so that the result can
eventually be destroyed.

The problem is that this presents a kind of fundamental conflict with the
conversion mechanism, in two ways:

1. Efficiency: when overload resolution comes into play, the intention is
to quickly resolve convertibility before any actual conversion work gets
done. However, in this case most of the work of a relatively expensive
conversion operation might have to complete before we can determine that
conversion will fail. It seems to me that things could get quite bad. For
example, a series of N overloaded functions which accept a
std::vector<double> as a first argument might do N-1 complete conversions
before matching the second argument successfully. Avoiding this problem
would at best be non-trivial.

2. Structure: when client code requests a possible rvalue conversion,
lvalue converters are also eligible to participate (see comments in
boost/python/rvalue_from_python_data.hpp). Right now, the convertible()
functions registered for lvalue and rvalue converters use the same
protocol. As stated earlier, the plan under discussion requires giving the
converter access to the rvalue_from_python_data<> object. However, when the
client code requests an lvalue conversion (e.g. wrapping a C++ function
taking a T* argument), no rvalue_from_python_data object exists. In order
to keep the convertible protocol uniform, we would need to conjure up a
NULL rvalue_from_python_data* to pass to lvalue converters, even though
they could never make use of it. This also imposes the cost of passing an
extra pointer to every convertible check (a small cost).

This whole scheme seems to go against the grain of the system, and I'm
wondering:

a. Is it worth it?
b. Is there a simpler answer?

-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 daveh at cadlink.com  Mon Jul  8 22:27:44 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 8 Jul 2002 16:27:44 -0400
Subject: [C++-sig] Re: Supporting container conversions
References: <055f01c226b7$5fb20c90$6601a8c0@boostconsulting.com>
Message-ID: <agcsim$7f9$1@main.gmane.org>

Dave,

Are there any pending updates to libs/python/src to match the header changes
as the CVS build appears broken?

Thanks
Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:055f01c226b7$5fb20c90$6601a8c0 at boostconsulting.com...
> I've been massageing some of the from_python converter code in order to
> prepare to make the extract<> class, and was thinking about trying to
> support Ralf's code which converts arbitrary Python iterable objects to
C++
> containers. Ralf wants to make a single pass over the Python sequence in
> order to determine convertibility. For some sequences, this might in fact
> be crucial, since it might not be possible to make multiple passes over
the









From rwgk at yahoo.com  Mon Jul  8 23:13:01 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 8 Jul 2002 14:13:01 -0700 (PDT)
Subject: [C++-sig] Supporting container conversions
In-Reply-To: <055f01c226b7$5fb20c90$6601a8c0@boostconsulting.com>
Message-ID: <20020708211301.35674.qmail@web20210.mail.yahoo.com>

> a. Is it worth it?

I could live with the current framework.

It seems unlikely to me that people pass huge Python sequences to C++
on a regular basis. We are using the Python sequence -> container
conversions only for passing tiny arrays. Therefore efficiency is
a very minor concern.

> b. Is there a simpler answer?

As I see it, the main problem are sequences that absolutely have to be
converted in one pass. A simple solution would be to use a function
taking a boost::python::object. In this way overload resolution and
conversion are decoupled. Thinking about it, this is exactly how
people emulate overload resolution in Python (evaluate the type(s) of
the argument(s) inside the function).

The only general solution I can think of is to support an exception-
handling-based protocol for overload resolution. I.e., if construct()
throws an exception of a certain type overload resolution continues as
if the corresponding convertible() test had failed. Wouldn't that be
easy to implement?

Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Mon Jul  8 23:36:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 17:36:37 -0400
Subject: [C++-sig] Re: Supporting container conversions
References: <055f01c226b7$5fb20c90$6601a8c0@boostconsulting.com> <agcsim$7f9$1@main.gmane.org>
Message-ID: <059801c226c7$deae7dc0$6601a8c0@boostconsulting.com>

Whoops. Fixed, I think.

Sorry for the inconvenience,
Dave

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Monday, July 08, 2002 4:27 PM
Subject: [C++-sig] Re: Supporting container conversions


> Dave,
>
> Are there any pending updates to libs/python/src to match the header
changes
> as the CVS build appears broken?
>
> Thanks
> Dave Hawkes
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:055f01c226b7$5fb20c90$6601a8c0 at boostconsulting.com...
> > I've been massageing some of the from_python converter code in order to
> > prepare to make the extract<> class, and was thinking about trying to
> > support Ralf's code which converts arbitrary Python iterable objects to
> C++
> > containers. Ralf wants to make a single pass over the Python sequence
in
> > order to determine convertibility. For some sequences, this might in
fact
> > be crucial, since it might not be possible to make multiple passes over
> the
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Mon Jul  8 23:57:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 17:57:40 -0400
Subject: [C++-sig] Supporting container conversions
References: <20020708211301.35674.qmail@web20210.mail.yahoo.com>
Message-ID: <05bb01c226ca$aeaeb650$6601a8c0@boostconsulting.com>

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

> As I see it, the main problem are sequences that absolutely have to be
> converted in one pass. A simple solution would be to use a function
> taking a boost::python::object. In this way overload resolution and
> conversion are decoupled. Thinking about it, this is exactly how
> people emulate overload resolution in Python (evaluate the type(s) of
> the argument(s) inside the function).
> 
> The only general solution I can think of is to support an exception-
> handling-based protocol for overload resolution. I.e., if construct()
> throws an exception of a certain type overload resolution continues as
> if the corresponding convertible() test had failed. Wouldn't that be
> easy to implement?

Sure, but I don't see how it would help anything.

-Dave





From rwgk at yahoo.com  Tue Jul  9 00:26:45 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 8 Jul 2002 15:26:45 -0700 (PDT)
Subject: [C++-sig] Supporting container conversions
In-Reply-To: <05bb01c226ca$aeaeb650$6601a8c0@boostconsulting.com>
Message-ID: <20020708222645.47881.qmail@web20208.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Sure, but I don't see how it would help anything.

Let's see: convertible() only checks if the PyObject is a sequence, but does
not attempt to convert any of the elements. construct() goes ahead and actually
traverses the sequence. If any of the elements is not convertible, an exception
is thrown.

Oh, this does not help indeed if the sequence must only be traversed once.
Any other potential overload would miss the elements that were converted
already.

So what do you think about the boost::python::object idea?

Ralf


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com




From david.abrahams at rcn.com  Tue Jul  9 00:40:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 18:40:47 -0400
Subject: [C++-sig] Supporting container conversions
References: <20020708222645.47881.qmail@web20208.mail.yahoo.com>
Message-ID: <05f501c226d0$81953e90$6601a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
>
> Oh, this does not help indeed if the sequence must only be traversed
once.
> Any other potential overload would miss the elements that were converted
> already.
>
> So what do you think about the boost::python::object idea?

I think it would be much nicer to have boost::python::sequence which is
derived from object and which only matches arguments that are sequences.

-Dave






From daveh at cadlink.com  Tue Jul  9 01:14:36 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 8 Jul 2002 19:14:36 -0400
Subject: [C++-sig] list / dictionary problems in V2
Message-ID: <agd6b7$s1j$1@main.gmane.org>

I was experimenting with list and dictionary support and get a number of
errors such as:

boost\python\objects2.hpp(215) : error C2065: 'make_ref' : undeclared
identifier

It would appear that make_ref is only defined in reference.hpp, but that is
now an obsolete header in V2.

Where is make_ref now defined now?

Thanks

Dave Hawkes









From hupp at cs.wisc.edu  Tue Jul  9 01:14:40 2002
From: hupp at cs.wisc.edu (Adam Hupp)
Date: Mon, 8 Jul 2002 18:14:40 -0500
Subject: [C++-sig] Wrapping extern C libraries
Message-ID: <20020708231440.GA10551@upl.cs.wisc.edu>

I am attempting to wrap a C library (Intel IPL) with BPL v2 and have a
problem with differing calling conventions.  The library's functions are
declared like:

extern "C" {

extern void __stdcall iplOpen(...);
....
}

When I .def the function I get:

error C2664: 'struct boost::python::detail::char_array<3> __cdecl
boost::python::detail::arg_tuple_size_helper(void (__cdecl *)(struct
_IplImage *,struct _IplImage *,int))' : can not convert parameter 1 from
'void (__stdcall *)(struct _IplImage *,struct _IplImage *,int)' to 'void
(__cdecl *)(struct _IplImage *,struct _IplImage *,int)' This conversion
requires a reinterpret_cast, a C-style cast or function-style cast

If I cast the function to __cdecl it builds but python dies with an
error about eax not being restored after the call (quite impressive
checking in the debug build, BTW).

I can make a wrapper for each function, which works fine but is of
course not an ideal solution.  I also tried using the boost::function
library as an intermediary but was unsucessful.

So, is this something that can be dealt with in BPL or am I stuck with
writing many little wrappers?   


-Adam





From david.abrahams at rcn.com  Tue Jul  9 01:31:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 19:31:29 -0400
Subject: [C++-sig] list / dictionary problems in V2
References: <agd6b7$s1j$1@main.gmane.org>
Message-ID: <064001c226d7$fc661d90$6601a8c0@boostconsulting.com>

It's now spelled object(x).

The automatic conversion facilities of objects.hpp have never worked with
v2. objects.hpp will be retired completely when Achim is done implementing
the types it contains.

-Dave

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Monday, July 08, 2002 7:14 PM
Subject: [C++-sig] list / dictionary problems in V2


> I was experimenting with list and dictionary support and get a number of
> errors such as:
>
> boost\python\objects2.hpp(215) : error C2065: 'make_ref' : undeclared
> identifier
>
> It would appear that make_ref is only defined in reference.hpp, but that
is
> now an obsolete header in V2.
>
> Where is make_ref now defined now?
>
> Thanks
>
> Dave Hawkes
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Tue Jul  9 01:43:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 8 Jul 2002 19:43:06 -0400
Subject: [C++-sig] choosing a python-c++ interface: a few questions
References: <3D29C9C4.9050608@nxpdata.com>
Message-ID: <064f01c226d9$64d90c60$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "David Marimont" <marimont at nxpdata.com>

> 1. Are interfaces to the C++ standard library are part of the existing
> Boost Python Library?

Not directly. Remember, the parts of the C++ standard library you're
speaking of are mostly class and function /templates/, not actual classes
and functions. You can only bind actual classes and functions to Python
i.e. a particular instantiation of a class or function template. Lots of
people have done that successfully, though.

> 2. Can interfaces be generated automatically from C++ source code?

Not with Boost.Python. It is a feature of Boost.Python that it uses the C++
compiler to do its work rather than attempting to parse and understand your
C++ source. All systems which try to do that eventually break down, because
the source code doesn't contain enough information to do the whole job. At
that point, you end up having to modify the generated interface
descriptions or hand-wrap code. Of course, such systems also have an
upside, which is often a lower barrier-to-entry.

> 3. If the answer to either of these questions is no, will that change
> in version 2?

Version 2 will have some direct support for passing Python sequences such
as lists and tuples to wrapped C++ functions which expect STL-style C++
sequences as parameters. This work has already been done by Ralf
Grosse-Kunstleve, and several people are currently using it.

We don't have plans to add automatic interface generation right away. I
think it would be a good feature to add eventually, but for now we're
trying to relieve most of the tedium of wrapping using just the C++
language.

> I've only been reading this list for a week or so now, so I'm not sure
> I'm addressing these questions to the right people.  Any help you
> could give me, including pointers to other places to get these
> questions answered, is much appreciated!

I hope this has been helpful,
Dave





From david.abrahams at rcn.com  Tue Jul  9 21:49:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 9 Jul 2002 15:49:50 -0400
Subject: [C++-sig] New preprocessor methodology
Message-ID: <099201c22781$ccf66740$6601a8c0@boostconsulting.com>

I've just finished integrating Paul Mensonides' file iteration support into
Boost.Python v2 --thanks, Paul!

I'm very pleased to announce that I was able to eliminate the
pre-preprocessed files in boost/python/preprocessed, and that the time
required for building all tests has dropped to 60% of its former value with
Intel C++ 6.0! Intel's EDG-based compiler has a slow preprocessor -- you
should see similar speedups on other EDG-based platforms.

I expect to see a similar compilation speed bump when we switch to the
upcoming review version of MPL, which also uses Paul's file iteration
technique.

Another nice effect is that support for arbitrary numbers of arguments is
as simple as #defining the preprocessor symbol BOOST_PYTHON_MAX_ARITY to
the number of arguments you need (currently defaults to 15). Until the MPL
transition can be made, you may also need to set
BOOST_MPL_LIST_PARAMETERS_NUMBER to the same value.


-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 achim.domma at syynx.de  Wed Jul 10 10:49:48 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 10 Jul 2002 10:49:48 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <01f101c22615$e7d37980$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEKMDIAA.achim.domma@syynx.de>

Hi Dave,

I'm sorry to tell you, that I failed. I attached the files I produced so
far, but trying to write tests with it I got lots of errors which I don't
managed to solve. Tuple seems to be used already in the creation of classes.
Trying to replace it with my tuple class, I got lots of problems converting
between handle, object and so on.
I hope the files will be of some help anyway, but I think until I improve my
knowledge of boost.python someone else should overtake this task.
If I understand boost.python somewhat better I would be glad to give it
another try, but at the moment I think I'm not good enough.

greetings
Achim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: types.zip
Type: application/x-zip-compressed
Size: 7329 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020710/149b7a64/attachment.bin>

From david.abrahams at rcn.com  Wed Jul 10 13:55:00 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 07:55:00 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAEEKMDIAA.achim.domma@syynx.de>
Message-ID: <0c9e01c22809$081732f0$6601a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>


> Hi Dave,
>
> I'm sorry to tell you, that I failed. I attached the files I produced so
> far, but trying to write tests with it I got lots of errors which I don't
> managed to solve.

Don't give up now; just ask some questions (unless you're out of time)!

> Tuple seems to be used already in the creation of classes.
> Trying to replace it with my tuple class, I got lots of problems
converting
> between handle, object and so on.

You mean in class_base::class_base?
That usage could be replaced by handle<> bases(PyTuple_New(...)) and
regular calls to the Python 'C' API.

> I hope the files will be of some help anyway,

They mostly look pretty good to me.

> but I think until I improve my
> knowledge of boost.python someone else should overtake this task.
> If I understand boost.python somewhat better I would be glad to give it
> another try, but at the moment I think I'm not good enough.

Well, I don't think it should be too difficult. I should have given you the
following recommendations which would make it easier:

1. Try to replace and test just a single type at a time. Start with dict,
for example. Trying to replace large portions of a codebase tends to
destabilize it and make testing more difficult.

2. The v1 tuple interface has these multi-argument constructors which are
intended to allow you to create tuples on-the-fly. Forget about those.
They're not symmetric anyway, since passing a single argument /converts/ it
to a tuple, rather than wrapping it in a tuple. I'm going to write a
generalized make_tuple() function which builds the appropriate tuple
object.

-Dave






From david.abrahams at rcn.com  Wed Jul 10 16:25:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 10:25:41 -0400
Subject: [C++-sig] Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com>
Message-ID: <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com>

cc:'d to C++-sig - this conversation should be moved there.

[discussing how to release objects which are currently made immortal by the
library before PyFinalize is called -- needed for Python embedding]

From: "Dave Hawkes" <daveh at cadlink.com>
> From: "David Abrahams" <david.abrahams at rcn.com>
> > > We must assume that atexit can not always be imported (may not be
> > possible
> > > in some applications).
> >
> > Really? Example, please?
> >
> If python is statically bound to an embedded application it may not have
> access to external libraries or access may be through a modified
__import__
> and we may not know the point in execution where it is configured.
>
>
> > > If the import fails it should not be fatal and we
> > > will have to let the user manually call the termination function.
> >
> > I guess that's OK, but I'm not convinced it's needed yet.
> >
> as above
> > > Maybe the user has to call an init function suppress the import?
> >
> > That sounds like an unneccessary complication to me.
> >
> Maybe, but it's probably not a lot of additional code over and above what
> would be required anyway.

Hmm, I'm beginning to think that since an embeddor needs to explicitly call
Py_Finalize(), it's not too much to ask him to call our finalizer first.
That would make the atexit question moot, and individual developers who
need that functionality could implement it. It would also obviate the need
for a special init() function which suppresses the atexit stuff. Much
simpler.

[discussing what I'll call "Dave Hawkes' replacement for Python's eval()"]

> > > where a0,a1,a2 etc are succesive placeholders for the args.
> >
> > ;-) cute.
> > Well, you should use _1, _2, ... _9 for consistency with Boost.Bind and
> > Boost.Lambda.
>
> That can easily be done.
>
> > And you should templatize it so you can write:
> >
> >     call_statement("_1 += _2", o1, "freedom");
> >
>
> It already is!

cool!

> > > Any value
> > > assigned to rtn will be the return object (None otherwise). Multiline
> > > statements are supported.
> >
> > WHy not just return the result of the last line in the statement,
rather
> > than reserving a special variable name?
> >
>
> The return value could come from different code paths ie(trivial
example):
>
> if test:
>     rtn = 1
> else:
>     rtn = 2

How about wrapping all the code in a function body, so you can write
"return"?

> > If you must reserve a variable name, it should probably be _0.
> >
> Again, easily changed.

I'd prefer "return" to "_0 =" if possible.

> > If it's small and convenient I'll be happy to have it. However,
remember
> > that every new feature has to be documented, tested, and maintained.
You'd
> > have to be willing to do at least the first two for this one. If you
still
> > wonder whether it's appropriate, you might raise the question on the
> > c++-sig.
>
> I think its really useful to users embedding python as it make getting
small
> pieces of functionality implemented in python code almost trivial.

I totally agree. Just look at the number of tools out there which are
already trying to do something like this. This could be a major win for
interoperability!

> Documentation should be straightforward with the addition of a summary
and a
> good example. There are some plans in the works for testing, I'll email
> separately on that.

Thanks for all your work and new ideas!

-Dave






From daveh at cadlink.com  Wed Jul 10 17:40:23 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 10 Jul 2002 11:40:23 -0400
Subject: [C++-sig] Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com>
Message-ID: <aghkg2$7p1$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0d9d01c2281d$e9de2e50$6601a8c0 at boostconsulting.com...
> cc:'d to C++-sig - this conversation should be moved there.
>
> [discussing how to release objects which are currently made immortal by
the
> library before PyFinalize is called -- needed for Python embedding]
>
> > Maybe, but it's probably not a lot of additional code over and above
what
> > would be required anyway.
>
> Hmm, I'm beginning to think that since an embeddor needs to explicitly
call
> Py_Finalize(), it's not too much to ask him to call our finalizer first.
> That would make the atexit question moot, and individual developers who
> need that functionality could implement it. It would also obviate the need
> for a special init() function which suppresses the atexit stuff. Much
> simpler.
>
I think that is acceptable, the user could even use the atexit module
themselves to achieve this end.
(a simple call_statement use maybe!)

> [discussing what I'll call "Dave Hawkes' replacement for Python's eval()"]
>
> >
> > if test:
> >     rtn = 1
> > else:
> >     rtn = 2
>
> How about wrapping all the code in a function body, so you can write
> "return"?
>
The idea was to give the user more room to manouver than eval/exec provides,
while still enabling the python code to be kept as simple as possible. This
just seems to be giving the user additional restrictions on how the code is
structured. If we have a fixed set of variable names going in as arguments
it doesn't seem to be that illogical to have a fixed variable name for the
return value as well.

Also wrapping in a function body will incur additional overhead as I think
the only way I can get a variable back from exec is through the local
dictionary anyway.

Additionally I am probably going to have to provide an additional argument
to call_statement to specify whether the python global namespace should be
polluted by the call or not.

> > > If you must reserve a variable name, it should probably be _0.
> > >
> > Again, easily changed.
>
> I'd prefer "return" to "_0 =" if possible.
>
As above. I think we should stick to a return variable, whatever it is
called.

Dave Hawkes









From david.abrahams at rcn.com  Wed Jul 10 17:53:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 11:53:40 -0400
Subject: [C++-sig] Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org>
Message-ID: <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0d9d01c2281d$e9de2e50$6601a8c0 at boostconsulting.com...
> > Hmm, I'm beginning to think that since an embeddor needs to explicitly
> call
> > Py_Finalize(), it's not too much to ask him to call our finalizer
first.
> > That would make the atexit question moot, and individual developers who
> > need that functionality could implement it. It would also obviate the
need
> > for a special init() function which suppresses the atexit stuff. Much
> > simpler.
> >
> I think that is acceptable, the user could even use the atexit module
> themselves to achieve this end.

That's what I meant by "developers who need that functionality could
implement it".

> (a simple call_statement use maybe!)

Yes!

> > [discussing what I'll call "Dave Hawkes' replacement for Python's
eval()"]
> >
> > >
> > > if test:
> > >     rtn = 1
> > > else:
> > >     rtn = 2
> >
> > How about wrapping all the code in a function body, so you can write
> > "return"?
> >
> The idea was to give the user more room to manouver than eval/exec
provides,
> while still enabling the python code to be kept as simple as possible.
This
> just seems to be giving the user additional restrictions on how the code
is
> structured.

I don't see how. The user is free to bind local variables, including one
called 'rtn'. If he wants a value back, he just writes "return rtn", or if
he doesn't want to use a local variable he can just write "return
<expression>". Simple and pythonic.

> If we have a fixed set of variable names going in as arguments
> it doesn't seem to be that illogical to have a fixed variable name for
the
> return value as well.

It's not illogical in principle, but it's not Pythonic (more Pascal-ish).

> Also wrapping in a function body will incur additional overhead as I
think
> the only way I can get a variable back from exec is through the local
> dictionary anyway.

    "def f__:\n" + body + "ret = f__()\n"

> Additionally I am probably going to have to provide an additional
argument
> to call_statement to specify whether the python global namespace should
be
> polluted by the call or not.

Hmm. I don't see how that changes the question of "return", though.

> As above. I think we should stick to a return variable, whatever it is
> called.

It rubs all my stylistic hairs in the wrong direction. If it's really hard
to do anything else, I'll acquiesce, but I'm not convinced yet.

-Dave






From daveh at cadlink.com  Wed Jul 10 19:22:45 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 10 Jul 2002 13:22:45 -0400
Subject: [C++-sig] Re: Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org> <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com>
Message-ID: <aghqg0$p8o$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0e5c01c22829$f66a3180$6601a8c0 at boostconsulting.com...
> This
> > just seems to be giving the user additional restrictions on how the code
> is
> > structured.
>
> I don't see how. The user is free to bind local variables, including one
> called 'rtn'. If he wants a value back, he just writes "return rtn", or if
> he doesn't want to use a local variable he can just write "return
> <expression>". Simple and pythonic.
>


> > If we have a fixed set of variable names going in as arguments
> > it doesn't seem to be that illogical to have a fixed variable name for
> the
> > return value as well.
>
> It's not illogical in principle, but it's not Pythonic (more Pascal-ish).
>
> > Also wrapping in a function body will incur additional overhead as I
> think
> > the only way I can get a variable back from exec is through the local
> > dictionary anyway.
>
>     "def f__:\n" + body + "ret = f__()\n"
>
But what if the user wants to add functions or classes to the global
namespace, if the user defines a function/class in "body" then they will be
defined within f__ namespace. Not what the user intended. I know the user
could write code to get at the global namespace, but then that's not
particularly simplistic.

>
> > Additionally I am probably going to have to provide an additional
> argument
> > to call_statement to specify whether the python global namespace should
> be
> > polluted by the call or not.
>
> Hmm. I don't see how that changes the question of "return", though.
>
Not directly apart from when the user wants to modify the global namespace
and the function wrapper gets in the way, as above.

>
> > As above. I think we should stick to a return variable, whatever it is
> > called.
>
> It rubs all my stylistic hairs in the wrong direction. If it's really hard
> to do anything else, I'll acquiesce, but I'm not convinced yet.
>
Maybe, but in the long run I think it will make things harder for the user
for the sake of purity.

Dave Hawkes









From achim.domma at syynx.de  Wed Jul 10 20:05:46 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 10 Jul 2002 20:05:46 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <0c9e01c22809$081732f0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIELLDIAA.achim.domma@syynx.de>

Ok, tomorrow I will give it another try and will let you know if I make
progress.

Achim

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Wednesday, July 10, 2002 13:55
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Outstanding Jobs for v2 release
>
>
> From: "Achim Domma" <achim.domma at syynx.de>
>
>
> > Hi Dave,
> >
> > I'm sorry to tell you, that I failed. I attached the files I produced so
> > far, but trying to write tests with it I got lots of errors
> which I don't
> > managed to solve.
>
> Don't give up now; just ask some questions (unless you're out of time)!
>
> > Tuple seems to be used already in the creation of classes.
> > Trying to replace it with my tuple class, I got lots of problems
> converting
> > between handle, object and so on.
>
> You mean in class_base::class_base?
> That usage could be replaced by handle<> bases(PyTuple_New(...)) and
> regular calls to the Python 'C' API.
>
> > I hope the files will be of some help anyway,
>
> They mostly look pretty good to me.
>
> > but I think until I improve my
> > knowledge of boost.python someone else should overtake this task.
> > If I understand boost.python somewhat better I would be glad to give it
> > another try, but at the moment I think I'm not good enough.
>
> Well, I don't think it should be too difficult. I should have
> given you the
> following recommendations which would make it easier:
>
> 1. Try to replace and test just a single type at a time. Start with dict,
> for example. Trying to replace large portions of a codebase tends to
> destabilize it and make testing more difficult.
>
> 2. The v1 tuple interface has these multi-argument constructors which are
> intended to allow you to create tuples on-the-fly. Forget about those.
> They're not symmetric anyway, since passing a single argument
> /converts/ it
> to a tuple, rather than wrapping it in a tuple. I'm going to write a
> generalized make_tuple() function which builds the appropriate tuple
> object.
>
> -Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>






From david.abrahams at rcn.com  Wed Jul 10 20:03:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 14:03:44 -0400
Subject: [C++-sig] Re: Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org> <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com> <aghqg0$p8o$1@main.gmane.org>
Message-ID: <0f0a01c2283c$4555b9b0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>

> But what if the user wants to add functions or classes to the global
> namespace, if the user defines a function/class in "body" then they will
be
> defined within f__ namespace. Not what the user intended. I know the user
> could write code to get at the global namespace, but then that's not
> particularly simplistic.

OK, I'm convinced now.

-Dave






From david.abrahams at rcn.com  Wed Jul 10 20:07:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 14:07:38 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAIELLDIAA.achim.domma@syynx.de>
Message-ID: <0f2d01c2283c$b3243ac0$6601a8c0@boostconsulting.com>

I could remove dependencies on tuple from class_base, if that helps...

-Dave

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Wednesday, July 10, 2002 2:05 PM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> Ok, tomorrow I will give it another try and will let you know if I make
> progress.
>
> Achim
>
> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > Sent: Wednesday, July 10, 2002 13:55
> > To: c++-sig at python.org
> > Subject: Re: [C++-sig] Outstanding Jobs for v2 release
> >
> >
> > From: "Achim Domma" <achim.domma at syynx.de>
> >
> >
> > > Hi Dave,
> > >
> > > I'm sorry to tell you, that I failed. I attached the files I produced
so
> > > far, but trying to write tests with it I got lots of errors
> > which I don't
> > > managed to solve.
> >
> > Don't give up now; just ask some questions (unless you're out of time)!
> >
> > > Tuple seems to be used already in the creation of classes.
> > > Trying to replace it with my tuple class, I got lots of problems
> > converting
> > > between handle, object and so on.
> >
> > You mean in class_base::class_base?
> > That usage could be replaced by handle<> bases(PyTuple_New(...)) and
> > regular calls to the Python 'C' API.
> >
> > > I hope the files will be of some help anyway,
> >
> > They mostly look pretty good to me.
> >
> > > but I think until I improve my
> > > knowledge of boost.python someone else should overtake this task.
> > > If I understand boost.python somewhat better I would be glad to give
it
> > > another try, but at the moment I think I'm not good enough.
> >
> > Well, I don't think it should be too difficult. I should have
> > given you the
> > following recommendations which would make it easier:
> >
> > 1. Try to replace and test just a single type at a time. Start with
dict,
> > for example. Trying to replace large portions of a codebase tends to
> > destabilize it and make testing more difficult.
> >
> > 2. The v1 tuple interface has these multi-argument constructors which
are
> > intended to allow you to create tuples on-the-fly. Forget about those.
> > They're not symmetric anyway, since passing a single argument
> > /converts/ it
> > to a tuple, rather than wrapping it in a tuple. I'm going to write a
> > generalized make_tuple() function which builds the appropriate tuple
> > object.
> >
> > -Dave
> >
> >
> >
> >
> > _______________________________________________
> > 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 vawjr at rudbek.com  Wed Jul 10 20:42:26 2002
From: vawjr at rudbek.com (Victor A. Wagner, Jr.)
Date: Wed, 10 Jul 2002 11:42:26 -0700
Subject: [C++-sig] Apparent bug
Message-ID: <4.3.1.2.20020710114123.04e4bc10@mail.rudbek.com>

Using the commented out signature (the one with  .............., const 
std::size_t key,............)
causes errors compiling on VC++.NET
It's not clear why declaring the key const should (in the philosophical 
sense) cause any difficulties.  following the actual thread
of errors was beyond our abilities at the time.  Of course, the original 
"error" didn't mention const anywhere, which didn't make finding the 
problem any easier.

<rant>I sure wish the .NET compiler would give the "called from" trace back 
on all of it's errors/warnings to facilitate finding the perceived 
problems(like VC++6 did).  This one we chased for over  an hour</rant>

TimeStamps is equivalent to std::vector<double>
The error does NOT occur until        time_stamp.def(set_ts_item, 
"__setitem__");       is added to the source.  That is, if the line is 
removed, there is no error, but of course, we can't access set_ts_item either.
========================================================

// Sets the item corresponding to key in the map.
//void set_ts_item( TimeStamps& self, const std::size_t key, const double& 
value)
void set_ts_item( TimeStamps& self, std::size_t key, const double& value)
{
self.at(key) = value;
}

#include <boost/python/class_builder.hpp>
namespace python = boost::python;
BOOST_PYTHON_MODULE_INIT(PythonTest)
{
// Create an object representing this extension module.
python::module_builder this_module("PythonTest");
// TimeStamps
python::class_builder<TimeStamps> time_stamp(this_module, "TimeStamps");
time_stamp.def(boost::python::constructor<>());
time_stamp.def(&TimeStamps::size, "__len__");
time_stamp.def(get_ts_item, "__getitem__");
time_stamp.def(set_ts_item, "__setitem__");
}
Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"





From achim.domma at syynx.de  Wed Jul 10 22:00:09 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 10 Jul 2002 22:00:09 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <0f2d01c2283c$b3243ac0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAAELODIAA.achim.domma@syynx.de>

> I could remove dependencies on tuple from class_base, if that helps...

Yes, I think that would help a lot !

Achim





From david.abrahams at rcn.com  Wed Jul 10 22:54:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 16:54:57 -0400
Subject: [C++-sig] Apparent bug
References: <4.3.1.2.20020710114123.04e4bc10@mail.rudbek.com>
Message-ID: <0f6b01c22854$873bc3c0$6601a8c0@boostconsulting.com>

Re-posting the same report doesn't make it any clearer what your problem
is. Also note that your tabs are stripped so that there's no indentation.
Is there a bug in the library?

Oh... after re-reading about 5 times I see what you're talking about. This
is a VC++ compiler bug, not a library bug. VC++ incorrectly propagates the
constness of declared argument types into the type of the function
signature. Nothing you can do about it, sorry (other than declaring the
function initially with a prototype using a non-const argument -- you can
still make the function definition use a const argument).

-Dave



----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr at rudbek.com>
To: <c++-sig at python.org>
Sent: Wednesday, July 10, 2002 2:42 PM
Subject: [C++-sig] Apparent bug


> Using the commented out signature (the one with  .............., const
> std::size_t key,............)
> causes errors compiling on VC++.NET
> It's not clear why declaring the key const should (in the philosophical
> sense) cause any difficulties.  following the actual thread
> of errors was beyond our abilities at the time.  Of course, the original
> "error" didn't mention const anywhere, which didn't make finding the
> problem any easier.
>
> <rant>I sure wish the .NET compiler would give the "called from" trace
back
> on all of it's errors/warnings to facilitate finding the perceived
> problems(like VC++6 did).  This one we chased for over  an hour</rant>
>
> TimeStamps is equivalent to std::vector<double>
> The error does NOT occur until        time_stamp.def(set_ts_item,
> "__setitem__");       is added to the source.  That is, if the line is
> removed, there is no error, but of course, we can't access set_ts_item
either.
> ========================================================
>
> // Sets the item corresponding to key in the map.
> //void set_ts_item( TimeStamps& self, const std::size_t key, const
double&
> value)
> void set_ts_item( TimeStamps& self, std::size_t key, const double& value)
> {
> self.at(key) = value;
> }
>
> #include <boost/python/class_builder.hpp>
> namespace python = boost::python;
> BOOST_PYTHON_MODULE_INIT(PythonTest)
> {
> // Create an object representing this extension module.
> python::module_builder this_module("PythonTest");
> // TimeStamps
> python::class_builder<TimeStamps> time_stamp(this_module, "TimeStamps");
> time_stamp.def(boost::python::constructor<>());
> time_stamp.def(&TimeStamps::size, "__len__");
> time_stamp.def(get_ts_item, "__getitem__");
> time_stamp.def(set_ts_item, "__setitem__");
> }
> Victor A. Wagner Jr.      http://rudbek.com
> PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
> PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
> The five most dangerous words in the English language:
>                "There oughta be a law"
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Wed Jul 10 23:29:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 17:29:49 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAAELODIAA.achim.domma@syynx.de>
Message-ID: <0f9901c22859$7014ffe0$6601a8c0@boostconsulting.com>

OK, no problem.

----- Original Message ----- 
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Wednesday, July 10, 2002 4:00 PM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> > I could remove dependencies on tuple from class_base, if that helps...
> 
> Yes, I think that would help a lot !
> 
> Achim
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Wed Jul 10 23:42:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 17:42:55 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAAELODIAA.achim.domma@syynx.de>
Message-ID: <0fa101c2285a$c68e7df0$6601a8c0@boostconsulting.com>

Done.
----- Original Message ----- 
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Wednesday, July 10, 2002 4:00 PM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> > I could remove dependencies on tuple from class_base, if that helps...
> 
> Yes, I think that would help a lot !
> 
> Achim
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Thu Jul 11 01:06:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Jul 2002 19:06:06 -0400
Subject: [C++-sig] Embedding example anyone?
References: <sewusaicev.fsf@pc970145.GermanLloyd.de>
Message-ID: <103501c22866$60df3010$6601a8c0@boostconsulting.com>

Sorry I haven't responded before -- your message got lost in the shuffle.

Yes, people have done this, but unfortunately we don't have an example in
the distribution. I've heard it said that it's just like extending Python
with Boost.Python -- you just need to call your module's init() function
explicitly to load the module. Maybe someone else on this list can help you
out. I know Dave Hawkes is planning to contribute some embedding examples
for Boost.Python v2.

-Dave
----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>
To: <c++-sig at python.org>
Sent: Friday, July 05, 2002 8:31 AM
Subject: [C++-sig] Embedding example anyone?


Hello,

Can anyone provide with an example of embedding Python in my on
application using boost? I'm especially interested in wrapping Python
classes for use in C++. Is the any support for something like this in
boost?

Thanks

Berthold
--
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email.

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc.


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





From daveh at cadlink.com  Thu Jul 11 03:31:56 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 10 Jul 2002 21:31:56 -0400
Subject: [C++-sig] Re: Embedding example anyone?
References: <sewusaicev.fsf@pc970145.GermanLloyd.de> <103501c22866$60df3010$6601a8c0@boostconsulting.com>
Message-ID: <agin4d$upn$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:103501c22866$60df3010$6601a8c0 at boostconsulting.com...
> Sorry I haven't responded before -- your message got lost in the shuffle.
>
> Yes, people have done this, but unfortunately we don't have an example in
> the distribution. I've heard it said that it's just like extending Python
> with Boost.Python -- you just need to call your module's init() function
> explicitly to load the module. Maybe someone else on this list can help
you
> out. I know Dave Hawkes is planning to contribute some embedding examples
> for Boost.Python v2.
>
Unfortunately the example I have created so far, although functional, is for
a version of Boost.Python that's not currently in CVS :(
However I can say that embedding using V2 should be particularly
straightforward in most cases.

The best way of tying python and your own code together to make your program
a built-in module using something like this in c++:

PyImport_AppendInittab("MyProgram", initMyProgram);
Py_Initialize();
...

where initMyProgram is your init function.

Then in python:

import MyProgram


MyProgram will then behave as a built-in module. Of course there is nothing
to prevent you having multiple init functions in the same program and
initialising each with PyImport_AppendInittab. That way you can have
multiple modules for different aspects of the program.


It is also possible to create c++ classes which have some member functions
overloaded in python, which my example should also demonstrate when
complete.


Dave Hawkes









From hoel at germanlloyd.org  Thu Jul 11 11:19:37 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 11 Jul 2002 11:19:37 +0200
Subject: [C++-sig] Re: Embedding example anyone?
In-Reply-To: <agin4d$upn$1@main.gmane.org>
References: <sewusaicev.fsf@pc970145.GermanLloyd.de><103501c22866$60df3010$6601a8c0@boostconsulting.com><agin4d$upn$1@main.gmane.org>
Message-ID: <sehej6d3km.fsf@pc970145.GermanLloyd.de>

"Dave Hawkes" <daveh at cadlink.com> writes:

> However I can say that embedding using V2 should be particularly
> straightforward in most cases.
> 
> The best way of tying python and your own code together to make your
program
> a built-in module using something like this in c++:
> 
> PyImport_AppendInittab("MyProgram", initMyProgram);
> Py_Initialize();
> ...
> 
> where initMyProgram is your init function.
> 
> Then in python:
> 
> import MyProgram
> 
> 
> MyProgram will then behave as a built-in module. Of course there is
nothing
> to prevent you having multiple init functions in the same program and
> initialising each with PyImport_AppendInittab. That way you can have
> multiple modules for different aspects of the program.
> 
> 
> It is also possible to create c++ classes which have some member
functions
> overloaded in python, which my example should also demonstrate when
> complete.

I'm looking for a somehow different approach. We have to provide some
functionality for a C++ Program. The functions are already almost
written, but in Python. So we are looking for a easy/convenient way to
access Python code/classes/methods from C++. Is there anything
available to help us there.

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From david.abrahams at rcn.com  Thu Jul 11 13:31:31 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 11 Jul 2002 07:31:31 -0400
Subject: [C++-sig] Re: Embedding example anyone?
References: <sewusaicev.fsf@pc970145.GermanLloyd.de><103501c22866$60df3010$6601a8c0@boostconsulting.com><agin4d$upn$1@main.gmane.org> <sehej6d3km.fsf@pc970145.GermanLloyd.de>
Message-ID: <11cc01c228ce$dea7ad20$6601a8c0@boostconsulting.com>

From: "Berthold H?llmann" <hoel at germanlloyd.org>

<<I'm looking for a somehow different approach. We have to provide some
functionality for a C++ Program. The functions are already almost
written, but in Python. So we are looking for a easy/convenient way to
access Python code/classes/methods from C++. Is there anything
available to help us there.>>

Boost.Python v2 contains a class called "object" which lets you access
Python objects (including classes and methods) in C++ in almost the same
way you'd do it from Python. The only major syntactic differences are:

    Python        C++

    x.foo         x.attr("foo")
    x[1:-2]       x.slice(1,-2)
    x[:-4]        x.slice(_,-4)

Some of python's special syntax quirks are also not supported, i.e.

    x < y < z

means:

    (x < y) < z

not:

    x < y and y < z

as it does in Python.

HTH,
Dave






From daveh at cadlink.com  Thu Jul 11 18:53:34 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 11 Jul 2002 12:53:34 -0400
Subject: [C++-sig] Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org> <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com> <aghqg0$p8o$1@main.gmane.org> <0f0a01c2283c$4555b9b0$6601a8c0@boostconsulting.com>
Message-ID: <agkd5j$ai8$1@main.gmane.org>

Here is the latest version of the API generator. There's still a few issues
left.

I haven't culled all redundant (or potentially redundant) functionality yet
such as dict() etc.

call_statement has been revised as discussed.

I had to keep the get_args code for those functions that can take a large
number of templated arguments (such as print) as the args could be any
mixture of types.

Specialisations provided on many templated functions.

Many more functions could probably be included from the python API.

Some support for python execution frames may be required when embedding and
directly calling functions (that's why globals() can't be called directly).
I will investigate this further.

Other fixes and adjustments.

Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0f0a01c2283c$4555b9b0$6601a8c0 at boostconsulting.com...
>
> ----- Original Message -----
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > But what if the user wants to add functions or classes to the global
> > namespace, if the user defines a function/class in "body" then they will
> be
> > defined within f__ namespace. Not what the user intended. I know the
user
> > could write code to get at the global namespace, but then that's not
> > particularly simplistic.
>
> OK, I'm convinced now.
>
> -Dave


begin 666 py_api_gen.py
M(R!#;W!Y<FEG:'0 at 1&%V:60 at 2&%W:V5S(#(P,#(N#0HC(%!E<FUI<W-I;VX@
M:7,@:&5R96)Y(&=R86YT960@=&\@8V]P>2P@=7-E(&%N9"!M;V1I9GD@=&AI
M<R!S;V9T=V%R90T*(R!F;W(@86YY('!U<G!O<V4L(&EN8VQU9&EN9R!C;VUM
M97)C:6%L(&1I<W1R:6)U=&EO;BP@<')O=FED960@=&AI<PT*(R!C;W!Y<FEG
M:'0@;F]T:6-E(&ES(&YO="!R96UO=F5D+B!.;R!W87)R86YT>2!72$%44T]%
M5D52(&ES('!R;W9I9&5D('=I=&@@=&AI<PT*(R!S;V9T=V%R92X at 06YY('5S
M97(H<RD at 86-C97!T<R!T:&ES('-O9G1W87)E(")A<R!I<R(@86YD(&%S('-U
M8V@@=&AE>2!W:6QL(&YO= T*(R!B:6YD('1H92!A=71H;W(H<RD@=&\@86YY
M(&-L86EM(&]F('-U:71A8FEL='D at 9F]R(&%N>2!P=7)P;W-E+ at T*#0HC($)U
M:6QD('!Y=&AO;B!!4$D@=W)A<'!E<G, at 9F]R(&)O;W-T('!Y=&AO;@T*#0II
M;7!O<G0@<F4-"@T*05!)7TQI<W0@/2!;#0HG4'E/8FIE8W0J>VYE=WT at 86)S
M>V1I<F5C='TH:6YT>W1E;7!L871E?2DG+ T*)U!Y3V)J96-T*GMN97=](&%B
M<WMD:7)E8W1]*%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&%B<WMD
M:7)E8W1]*'-H;W)T*2<L#0HG4'E/8FIE8W0J>VYE=WT at 86)S>V1I<F5C='TH
M:6YT*2<L#0HG4'E/8FIE8W0J>VYE=WT at 86)S>V1I<F5C='TH;&]N9RDG+ T*
M)U!Y3V)J96-T*GMN97=](&%B<WMD:7)E8W1]*&1O=6)L92!C;VYS=" F*2<L
M#0HG4'E/8FIE8W0J>VYE=RQE<G(]3E5,3'T at 4'E/8FIE8W1?0V%L;$]B:F5C
M='MD96-L/6%P<&QY?2A0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG4'E/8FIE
M8W0J>VYE=RQE<G(]3E5,3'T at 4'E/8FIE8W1?0V%L;'MD96-L/6%P<&QY?2A0
M>4]B:F5C="HL4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)V)O;VP at 4'E#86QL
M86)L95]#:&5C:WMD96-L/6-A;&QA8FQE?2A0>4]B:F5C="HI)RP-"B=0>4]B
M:F5C="I[;F5W?2!C:')[9&ER96-T?2AI;G1[=&5M<&QA=&5]*2<L#0HG4'E/
M8FIE8W0J>VYE=WT at 8VAR>V1I<F5C='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE
M8W0J>VYE=WT at 8VAR>V1I<F5C='TH<VAO<G0I)RP-"B=0>4]B:F5C="I[;F5W
M?2!C:')[9&ER96-T?2AI;G0I)RP-"B=0>4]B:F5C="I[;F5W?2!C:')[9&ER
M96-T?2AL;VYG*2<L#0HG:6YT>V5R<CTM,7T at 4'E/8FIE8W1?0VUP>V1E8VP]
M8VUP?2A0>4]B:F5C="I[=&5M<&QA=&5]+%!Y3V)J96-T*GMT96UP;&%T97TL
M:6YT>W)E<W5L='TI)RP-"B=I;G1[97)R/2TQ?2!0>4]B:F5C=%]#;7![9&5C
M;#UC;7!]*%!Y3V)J96-T*BQ0>4]B:F5C="HL:6YT>W)E<W5L='TI)RP-"B=0
M>4]B:F5C="I[;F5W?2!C;V5R8V5[9&ER96-T?2A0>4]B:F5C="HL4'E/8FIE
M8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT at 8V]M<&EL97MD:7)E8W1]*%!Y3V)J
M96-T*BQ0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@
M8V]M<&EL97MD:7)E8W1]*&-O;G-T(&-H87(J+&-O;G-T(&-H87(J+&-O;G-T
M(&-H87(J*2<L#0HG4'E/8FIE8W0J>VYE=WT at 8V]M<&EL97MD:7)E8W1]*%!Y
M3V)J96-T*BQ0>4]B:F5C="HL4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y
M3V)J96-T*GMN97=](&-O;7!I;&5[9&ER96-T?2AC;VYS="!C:&%R*BQC;VYS
M="!C:&%R*BQC;VYS="!C:&%R*BQI;G0I)RP-"B=0>4]B:F5C="I[;F5W?2!C
M;VUP:6QE>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BQ0>4]B:F5C="HL
M4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&-O;7!I
M;&5[9&ER96-T?2AC;VYS="!C:&%R*BQC;VYS="!C:&%R*BQC;VYS="!C:&%R
M*BQI;G0L:6YT*2<L#0HG4'E/8FIE8W0J>VYE=WT at 8V]M<&QE>'MD:7)E8W1]
M*&EN='MT96UP;&%T97TI)RP-"B=0>4]B:F5C="I[;F5W?2!C;VUP;&5X>V1I
M<F5C='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT at 8V]M<&QE>'MD
M:7)E8W1]*&1O=6)L92!C;VYS="8I)RP-"B=0>4]B:F5C="I[;F5W?2!C;VUP
M;&5X>V1I<F5C='TH:6YT>W1E;7!L871E?2QI;G1[=&5M<&QA=&5]*2<L#0HG
M4'E/8FIE8W0J>VYE=WT at 8V]M<&QE>'MD:7)E8W1]*%!Y3V)J96-T*BQ0>4]B
M:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!C;VUP;&5X>V1I<F5C='TH9&]U
M8FQE(&-O;G-T)BQD;W5B;&4 at 8V]N<W0F*2<L#0HG4'E/8FIE8W0J>VYE=WT@
M9&EC='MD:7)E8W1]*"DG+ T*)U!Y3V)J96-T*GMN97=](&1I8W1[9&ER96-T
M?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!0>4]B:F5C=%]$:7)[
M9&5C;#UD:7)]*%!Y3V)J96-T*GMV86QU93U.54Q,?2DG+ T*)U!Y3V)J96-T
M*GMN97=](%!Y3V)J96-T7T1I<GMD96-L/61I<GTH4'E/8FIE8W0J*2<L#0HG
M4'E/8FIE8W0J>VYE=WT at 9&EV;6]D>V1I<F5C='TH:6YT>W1E;7!L871E?2QI
M;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE8W0J>VYE=WT at 9&EV;6]D>V1I<F5C
M='TH4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&1I
M=FUO9'MD:7)E8W1]*&EN="QI;G0I)RP-"B=0>4]B:F5C="I[;F5W?2!D:79M
M;V1[9&ER96-T?2AL;VYG+&QO;F<I)RP-"B=0>4]B:F5C="I[;F5W?2!D:79M
M;V1[9&ER96-T?2AD;W5B;&4 at 8V]N<W0F+&1O=6)L92!C;VYS="8I)RP-"B=0
M>4]B:F5C="I[;F5W?2!0>5)U;E]3=')I;F=[9&5C;#UE=F%L?2AC:&%R*GMC
M;VYS='TL:6YT>W9A;'5E/5!Y7V5V86Q?:6YP=71]+%!Y3V)J96-T*GMV86QU
M93UG;&]B86QS*"DN<'1R*"E]+%!Y3V)J96-T*GMV86QU93UG;&]B86QS*"DN
M<'1R*"E]*2<L#0HG4'E/8FIE8W0J>VYE=WT at 4'E2=6Y?4W1R:6YG>V1E8VP]
M979A;'TH8VAA<BI[8V]N<W1]+&EN='MV86QU93U0>5]E=F%L7VEN<'5T?2Q0
M>4]B:F5C="HL4'E/8FIE8W0J>W9A;'5E/6=L;V)A;',H*2YP='(H*7TI)RP-
M"B=0>4]B:F5C="I[;F5W?2!0>5)U;E]3=')I;F=[9&5C;#UE=F%L?2AC:&%R
M*GMC;VYS='TL:6YT>W9A;'5E/5!Y7V5V86Q?:6YP=71]+%!Y3V)J96-T*BQ0
M>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!0>5)U;E]3=')I;F=[9&5C
M;#UE>&5C?2AC:&%R*GMC;VYS='TL:6YT>W9A;'5E/5!Y7V9I;&5?:6YP=71]
M+%!Y3V)J96-T*GMV86QU93UG;&]B86QS*"DN<'1R*"E]+%!Y3V)J96-T*GMV
M86QU93UG;&]B86QS*"DN<'1R*"E]*2<L#0HG4'E/8FIE8W0J>VYE=WT at 4'E2
M=6Y?4W1R:6YG>V1E8VP]97AE8WTH8VAA<BI[8V]N<W1]+&EN='MV86QU93U0
M>5]F:6QE7VEN<'5T?2Q0>4]B:F5C="HL4'E/8FIE8W0J>W9A;'5E/6=L;V)A
M;',H*2YP='(H*7TI)RP-"B=0>4]B:F5C="I[;F5W?2!0>5)U;E]3=')I;F=[
M9&5C;#UE>&5C?2AC:&%R*GMC;VYS='TL:6YT>W9A;'5E/5!Y7V9I;&5?:6YP
M=71]+%!Y3V)J96-T*BQ0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!E
M>&5C9FEL97MD:7)E8W1]*%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=]
M(&5X96-F:6QE>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y
M3V)J96-T*GMN97=](&5X96-F:6QE>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J
M96-T*BQ0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!F:6QE>V1I<F5C
M='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT at 9FEL97MD:7)E8W1]
M*&-O;G-T(&-H87(J*2<L#0HG4'E/8FIE8W0J>VYE=WT at 9FEL97MD:7)E8W1]
M*%!Y3V)J96-T*BQ0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!F:6QE
M>V1I<F5C='TH8V]N<W0 at 8VAA<BHL8V]N<W0 at 8VAA<BHI)RP-"B=0>4]B:F5C
M="I[;F5W?2!F:6QE>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BQ0>4]B
M:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!F:6QE>V1I<F5C='TH8V]N<W0@
M8VAA<BHL8V]N<W0 at 8VAA<BHL:6YT*2<L#0HG4'E/8FIE8W0J>VYE=WT at 9FEL
M=&5R>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T
M*GMN97=](&9L;V%T>V1I<F5C="QD96-L/69L;V%T7WTH4'E/8FIE8W0J*2<L
M#0HG4'E/8FIE8W0J>VYE=WT at 9FQO871[9&ER96-T+&1E8VP]9FQO871??2AC
M;VYS="!C:&%R*BDG+ T*)U!Y3V)J96-T*GMN97=](&9L;V%T>V1I<F5C="QD
M96-L/69L;V%T7WTH9&]U8FQE(&-O;G-T)BDG+ T*)U!Y3V)J96-T*GMN97=]
M(&=E=&%T=')[9&ER96-T?2A0>4]B:F5C="HL4'E/8FIE8W0J+%!Y3V)J96-T
M*BDG+ T*)U!Y3V)J96-T*GMN97=](&=E=&%T=')[9&ER96-T?2A0>4]B:F5C
M="HL8V]N<W0 at 8VAA<B J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMB;W)R
M;W=E9"QE<G(]3E5,3'T at 4'E-;V1U;&5?1V5T1&EC='MD96-L/6=L;V)A;'-]
M*%!Y3V)J96-T*GMV86QU93U0>4EM<&]R=%]!9&1-;V1U;&4H(E]?;6%I;E]?
M(BE]*2<L#0HG8F]O;"!0>4]B:F5C=%](87-!='1R>V1E8VP]:&%S871T<GTH
M4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)V)O;VP at 4'E/8FIE8W1?2&%S071T
M<E-T<FEN9WMD96-L/6AA<V%T=')]*%!Y3V)J96-T*BQC:&%R*GMC;VYS='TI
M)RP-"B=L;VYG>V5R<CTM,7T at 4'E/8FIE8W1?2&%S:'MD96-L/6AA<VA]*%!Y
M3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&AE>'MD:7)E8W1]*&EN='MT
M96UP;&%T97TI)RP-"B=0>4]B:F5C="I[;F5W?2!H97A[9&ER96-T?2A0>4]B
M:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!H97A[9&ER96-T?2AC:&%R*2<L
M#0HG4'E/8FIE8W0J>VYE=WT@:&5X>V1I<F5C='TH<VAO<G0I)RP-"B=0>4]B
M:F5C="I[;F5W?2!H97A[9&ER96-T?2AI;G0I)RP-"B=0>4]B:F5C="I[;F5W
M?2!H97A[9&ER96-T?2AL;VYG*2<L#0HG;&]N9R!I9'MD:7)E8W1]*%!Y3V)J
M96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&EN<'5T>V1I<F5C='TH*2<L#0HG
M4'E/8FIE8W0J>VYE=WT@:6YP=71[9&ER96-T?2A0>4]B:F5C="HI)RP-"B=0
M>4]B:F5C="I[;F5W?2!I;G!U='MD:7)E8W1]*&-O;G-T(&-H87(J*2<L#0HG
M4'E/8FIE8W0J>VYE=WT@:6YT>V1I<F5C="QD96-L/6EN=%]]*%!Y3V)J96-T
M*BDG+ T*)U!Y3V)J96-T*GMN97=](&EN='MD:7)E8W0L9&5C;#UI;G1??2AL
M;VYG*2<L#0HG4'E/8FIE8W0J>VYE=WT@:6YT>V1I<F5C="QD96-L/6EN=%]]
M*&-O;G-T(&-H87(J*2<L#0HG4'E/8FIE8W0J>VYE=WT@:6YT97)N>V1I<F5C
M='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@:6YT97)N>V1I<F5C
M='TH8V]N<W0 at 8VAA<BHI)RP-"B=B;V]L(%!Y3V)J96-T7TES26YS=&%N8V5[
M9&5C;#UI<VEN<W1A;F-E?2A0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG8F]O
M;"!0>4]B:F5C=%])<U-U8F-L87-S>V1E8VP]:7-S=6)C;&%S<WTH4'E/8FIE
M8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](%!Y3V)J96-T7T=E
M=$ET97)[9&5C;#UI=&5R?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W
M?2!I=&5R>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)VQO;F=[
M97)R/2TQ?2!0>4]B:F5C=%],96YG=&A[9&5C;#UL96Y]*%!Y3V)J96-T*BDG
M+ T*)U!Y3V)J96-T*GMN97=](&QI<W1[9&ER96-T?2 at I)RP-"B=0>4]B:F5C
M="I[;F5W?2!L:7-T>V1I<F5C='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J
M>VYE=WT@;&]C86QS>V1I<F5C="QS=&%T96UE;G0]7S ];&]C86QS*"E]*"DG
M+ T*)U!Y3V)J96-T*GMN97=](&QO;F=[9&ER96-T+&1E8VP];&]N9U]]*%!Y
M3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&QO;F=[9&ER96-T+&1E8VP]
M;&]N9U]]*&QO;F<I)RP-"B=0>4]B:F5C="I[;F5W?2!L;VYG>V1I<F5C="QD
M96-L/6QO;F=??2AC;VYS="!C:&%R*BDG+ T*)U!Y3V)J96-T*GMN97=](&UA
M<'MD:7)E8W0L87)G<F5P96%T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[
M;F5W?2!M87A[9&ER96-T+&%R9W)E<&5A='TH4'E/8FIE8W0J>W1E;7!L871E
M?2DG+ T*)U!Y3V)J96-T*GMN97=](&UA>'MD:7)E8W0L87)G<F5P96%T?2A0
M>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!M:6Y[9&ER96-T+&%R9W)E
M<&5A='TH4'E/8FIE8W0J>W1E;7!L871E?2DG+ T*)U!Y3V)J96-T*GMN97=]
M(&UI;GMD:7)E8W0L87)G<F5P96%T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C
M="I[;F5W?2!O8W1[9&ER96-T?2AI;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE
M8W0J>VYE=WT@;V-T>V1I<F5C='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J
M>VYE=WT@;V-T>V1I<F5C='TH8VAA<BDG+ T*)U!Y3V)J96-T*GMN97=](&]C
M='MD:7)E8W1]*'-H;W)T*2<L#0HG4'E/8FIE8W0J>VYE=WT@;V-T>V1I<F5C
M='TH:6YT*2<L#0HG4'E/8FIE8W0J>VYE=WT@;V-T>V1I<F5C='TH;&]N9RDG
M+ T*)U!Y3V)J96-T*GMN97=](&]P96Y[9&ER96-T?2A0>4]B:F5C="HI)RP-
M"B=0>4]B:F5C="I[;F5W?2!O<&5N>V1I<F5C='TH8V]N<W0 at 8VAA<BHI)RP-
M"B=0>4]B:F5C="I[;F5W?2!O<&5N>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J
M96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](&]P96Y[9&ER96-T?2AC;VYS="!C
M:&%R*BQC;VYS="!C:&%R*BDG+ T*)U!Y3V)J96-T*GMN97=](&]P96Y[9&ER
M96-T?2A0>4]B:F5C="HL4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J
M96-T*GMN97=](&]P96Y[9&ER96-T?2AC;VYS="!C:&%R*BQC;VYS="!C:&%R
M*BQI;G0I)RP-"B=L;VYG(&]R9'MD:7)E8W1]*%!Y3V)J96-T*BDG+ T*)VQO
M;F<@;W)D>V1I<F5C='TH8V]N<W0 at 8VAA<BHI)RP-"B=0>4]B:F5C="I[;F5W
M?2!P;W=[9&ER96-T?2AI;G1[=&5M<&QA=&5]+&EN='MT96UP;&%T97TI)RP-
M"B=0>4]B:F5C="I[;F5W?2!P;W=[9&ER96-T?2A0>4]B:F5C="HL4'E/8FIE
M8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@<&]W>V1I<F5C='TH9&]U8FQE(&-O
M;G-T)BQD;W5B;&4 at 8V]N<W0F*2<L#0HG4'E/8FIE8W0J>VYE=WT@<&]W>V1I
M<F5C='TH9&]U8FQE(&-O;G-T)BQD;W5B;&4 at 8V]N<W0F+&1O=6)L92!C;VYS
M="8I)RP-"B=0>4]B:F5C="I[;F5W?2!P<FEN='MD:7)E8W0L<W1A=&5M96YT
M/7!R:6YT(%\Q+&%R9W)E<&5A='TH:6YT>W1E;7!L871E?2DG+ T*)U!Y3V)J
M96-T*GMN97=]('!R:6YT>V1I<F5C="QS=&%T96UE;G0]<')I;G0 at 7S$L87)G
M<F5P96%T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!P<FEN='MD
M96-L/7!R:6YT7V9I;&4L9&ER96-T+'-T871E;65N=#TB<')I;G0@/CY?,2P@
M7S(B+&%R9W)E<&5A='TH4'E/8FIE8W0J+&EN='MT96UP;&%T97TI)RP-"B=0
M>4]B:F5C="I[;F5W?2!P<FEN='MD96-L/7!R:6YT7V9I;&4L9&ER96-T+'-T
M871E;65N=#TB<')I;G0@/CY?,2P at 7S(B+&%R9W)E<&5A='TH4'E/8FIE8W0J
M+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=](')A;F=E>V1I<F5C='TH
M:6YT>W1E;7!L871E?2DG+ T*)U!Y3V)J96-T*GMN97=](')A;F=E>V1I<F5C
M='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@<F%N9V5[9&ER96-T
M?2AI;G0I)RP-"B=0>4]B:F5C="I[;F5W?2!R86YG97MD:7)E8W1]*&EN='MT
M96UP;&%T97TL:6YT>W1E;7!L871E?2DG+ T*)U!Y3V)J96-T*GMN97=](')A
M;F=E>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T
M*GMN97=](')A;F=E>V1I<F5C='TH:6YT+&EN="DG+ T*)U!Y3V)J96-T*GMN
M97=](')A;F=E>V1I<F5C='TH:6YT>W1E;7!L871E?2QI;G1[=&5M<&QA=&5]
M+&EN='MT96UP;&%T97TI)RP-"B=0>4]B:F5C="I[;F5W?2!R86YG97MD:7)E
M8W1]*%!Y3V)J96-T*BQ0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG4'E/8FIE
M8W0J>VYE=WT@<F%N9V5[9&ER96-T?2AI;G0L:6YT+&EN="DG+ T*)U!Y3V)J
M96-T*GMN97=](')A=U]I;G!U='MD:7)E8W1]*"DG+ T*)U!Y3V)J96-T*GMN
M97=](')A=U]I;G!U='MD:7)E8W1]*%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T
M*GMN97=](')A=U]I;G!U='MD:7)E8W1]*&-O;G-T(&-H87(J*2<L#0HG4'E/
M8FIE8W0J>VYE=WT@<F5D=6-E>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T
M*BDG+ T*)U!Y3V)J96-T*GMN97=](')E9'5C97MD:7)E8W1]*%!Y3V)J96-T
M*BQ0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=RQE<G(]
M3E5,3'T at 4'E);7!O<G1?4F5L;V%D36]D=6QE>V1E8VP]<F5L;V%D?2A0>4]B
M:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!0>4]B:F5C=%]297!R>V1E8VP]
M<F5P<GTH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@<F]U;F1[9&ER
M96-T?2AI;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE8W0J>VYE=WT@<F]U;F1[
M9&ER96-T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!R;W5N9'MD
M:7)E8W1]*&1O=6)L92!C;VYS="8I)RP-"B=0>4]B:F5C="I[;F5W?2!R;W5N
M9'MD:7)E8W1]*&EN='MT96UP;&%T97TL:6YT>W1E;7!L871E?2DG+ T*)U!Y
M3V)J96-T*GMN97=](')O=6YD>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T
M*BDG+ T*)U!Y3V)J96-T*GMN97=](')O=6YD>V1I<F5C='TH9&]U8FQE(&-O
M;G-T)BQD;W5B;&4 at 8V]N<W0F*2<L#0HG4'E/8FIE8W0J>VYE=WT@<VQI8V5[
M9&ER96-T?2AI;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE8W0J>VYE=WT@<VQI
M8V5[9&ER96-T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!S;&EC
M97MD:7)E8W1]*&EN="DG+ T*)U!Y3V)J96-T*GMN97=]('-L:6-E>V1I<F5C
M='TH:6YT>W1E;7!L871E?2QI;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE8W0J
M>VYE=WT@<VQI8V5[9&ER96-T?2A0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG
M4'E/8FIE8W0J>VYE=WT@<VQI8V5[9&ER96-T?2AI;G0L:6YT*2<L#0HG4'E/
M8FIE8W0J>VYE=WT@<VQI8V5[9&ER96-T?2AI;G1[=&5M<&QA=&5]+&EN='MT
M96UP;&%T97TL:6YT>W1E;7!L871E?2DG+ T*)U!Y3V)J96-T*GMN97=]('-L
M:6-E>V1I<F5C='TH4'E/8FIE8W0J+%!Y3V)J96-T*BQ0>4]B:F5C="HI)RP-
M"B=0>4]B:F5C="I[;F5W?2!S;&EC97MD:7)E8W1]*&EN="QI;G0L:6YT*2<L
M#0HG4'E/8FIE8W0J>VYE=WT at 4'E/8FIE8W1?4W1R>V1E8VP]<W1R?2A0>4]B
M:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!T=7!L97MD:7)E8W1]*"DG+ T*
M)U!Y3V)J96-T*GMN97=]('1U<&QE>V1I<F5C='TH4'E/8FIE8W0J*2<L#0HG
M4'E/8FIE8W0J>VYE=RQE<G(]3E5,3'T at 4'E/8FIE8W1?5'EP97MD96-L/71Y
M<&5??2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!U;FEC:')[9&ER
M96-T?2AI;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE8W0J>VYE=WT@=6YI8VAR
M>V1I<F5C='TH4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@=6YI8VAR
M>V1I<F5C='TH<VAO<G0I)RP-"B=0>4]B:F5C="I[;F5W?2!U;FEC:')[9&ER
M96-T?2AI;G0I)RP-"B=0>4]B:F5C="I[;F5W?2!U;FEC:')[9&ER96-T?2AL
M;VYG*2<L#0HG4'E/8FIE8W0J>VYE=WT at 4'E/8FIE8W1?56YI8V]D97MD96-L
M/75N:6-O9&5]*%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=]('5N:6-O
M9&5[9&ER96-T?2A0>4]B:F5C="HL4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J
M>VYE=WT@=6YI8V]D97MD:7)E8W1]*%!Y3V)J96-T*BQC;VYS="!C:&%R*BDG
M+ T*)U!Y3V)J96-T*GMN97=]('5N:6-O9&5[9&ER96-T?2A0>4]B:F5C="HL
M4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMN97=]('5N:6-O
M9&5[9&ER96-T?2A0>4]B:F5C="HL8V]N<W0 at 8VAA<BHL8V]N<W0 at 8VAA<BHI
M)RP-"B=0>4]B:F5C="I[;F5W?2!V87)S>V1I<F5C='TH*2<L#0HG4'E/8FIE
M8W0J>VYE=WT@=F%R<WMD:7)E8W1]*%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T
M*GMN97=]('AR86YG97MD:7)E8W1]*&EN='MT96UP;&%T97TI)RP-"B=0>4]B
M:F5C="I[;F5W?2!X<F%N9V5[9&ER96-T?2A0>4]B:F5C="HI)RP-"B=0>4]B
M:F5C="I[;F5W?2!X<F%N9V5[9&ER96-T?2AI;G0I)RP-"B=0>4]B:F5C="I[
M;F5W?2!X<F%N9V5[9&ER96-T?2AI;G1[=&5M<&QA=&5]+&EN='MT96UP;&%T
M97TI)RP-"B=0>4]B:F5C="I[;F5W?2!X<F%N9V5[9&ER96-T?2A0>4]B:F5C
M="HL4'E/8FIE8W0J*2<L#0HG4'E/8FIE8W0J>VYE=WT@>')A;F=E>V1I<F5C
M='TH:6YT+&EN="DG+ T*)U!Y3V)J96-T*GMN97=]('AR86YG97MD:7)E8W1]
M*&EN='MT96UP;&%T97TL:6YT>W1E;7!L871E?2QI;G1[=&5M<&QA=&5]*2<L
M#0HG4'E/8FIE8W0J>VYE=WT@>')A;F=E>V1I<F5C='TH4'E/8FIE8W0J+%!Y
M3V)J96-T*BQ0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!X<F%N9V5[
M9&ER96-T?2AI;G0L:6YT+&EN="DG+ T*)U!Y3V)J96-T*GMN97=]('II<'MD
M:7)E8W0L87)G<F5P96%T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W
M+&5R<CU.54Q,?2!0>5]#;VUP:6QE4W1R:6YG>V1E8VP]8V]M<&EL95]S=')I
M;F=]*&-H87(J>V-O;G-T?2QC:&%R*GMC;VYS='TL:6YT*2<L#0HG:6YT>V5R
M<CTM,7T at 4'E);7!O<G1?07!P96YD26YI='1A8GMD96-L/6EM<&]R=%]A<'!E
M;F1?:6YI='1A8GTH8VAA<BI[8V]N<W1]+'9O:60H*F%R9RDH=F]I9"DI)RP-
M"B=0>4]B:F5C="I[8F]R<F]W960L97)R/4Y53$Q](%!Y26UP;W)T7T%D9$UO
M9'5L97MD96-L/6EM<&]R=%]A9&1?;6]D=6QE?2AC:&%R*GMC;VYS='TI)RP-
M"B=0>4]B:F5C="I[8F]R<F]W960L97)R/4Y53$Q](%!Y26UP;W)T7T=E=$UO
M9'5L941I8W1[9&5C;#UI;7!O<G1?9V5T7VUO9'5L95]D:6-T?2 at I)RP-"B=0
M>4]B:F5C="I[;F5W+&5R<CU.54Q,?2!0>4EM<&]R=%]);7!O<G1[9&5C;#UI
M;7!O<G1?:6UP;W)T?2A0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W+&5R
M<CU.54Q,?2!0>4EM<&]R=%]);7!O<G1[9&5C;#UI;7!O<G1?:6UP;W)T?2AC
M;VYS="!C:&%R*GMO8FIE8W1]*2<L#0HG4'E/8FIE8W0J>VYE=RQE<G(]3E5,
M3'T at 4'E);7!O<G1?26UP;W)T36]D=6QE>V1E8VP]:6UP;W)T7VEM<&]R=%]M
M;V1U;&5]*&-H87(J>V-O;G-T?2DG+ T*)U!Y3V)J96-T*GMN97<L97)R/4Y5
M3$Q](%!Y26UP;W)T7TEM<&]R=$UO9'5L945X>V1E8VP]:6UP;W)T7VEM<&]R
M=%]M;V1U;&5?97A]*&-H87(J>V-O;G-T?2Q0>4]B:F5C="HL4'E/8FIE8W0J
M+%!Y3V)J96-T*BDG+ T*)U!Y3V)J96-T*GMB;W)R;W=E9"QE<G(]3E5,3'T@
M4'E-;V1U;&5?1V5T1&EC='MD96-L/6UO9'5L95]G971?9&EC='TH4'E/8FIE
M8W0J*2<L#0HG:6YT>V5R<CTM,7T at 4'E/8FIE8W1?4')I;G1[9&5C;#UO8FIE
M8W1?<')I;G1]*%!Y3V)J96-T*BQ&24Q%*BQI;G0I)RP-"B=0>4]B:F5C="I[
M;F5W+&5R<CU.54Q,?2!0>5)U;E]&:6QE>V1E8VP]<G5N7V9I;&5]*$9)3$4J
M+&-H87(J>V-O;G-T?2QI;G0L4'E/8FIE8W0J+%!Y3V)J96-T*BDG+ T*)VEN
M='ME<G(]+3%](%!Y4G5N7U-I;7!L949I;&5[9&5C;#UR=6Y?<VEM<&QE7V9I
M;&5]*$9)3$4J+&-H87(J>V-O;G-T?2DG+ T*)VEN='ME<G(]+3%](%!Y4G5N
M7U-I;7!L95-T<FEN9WMD96-L/7)U;E]S:6UP;&5?<W1R:6YG?2AC:&%R*GMC
M;VYS='TI)RP-"B=0>4]B:F5C="I[;F5W+&5R<CU.54Q,?2!0>5)U;E]3=')I
M;F=[9&5C;#UR=6Y?<W1R:6YG?2AC:&%R*GMC;VYS='TL:6YT+%!Y3V)J96-T
M*BQ0>4]B:F5C="HI)RP-"B=0>4]B:F5C="I[;F5W?2!C86QL7W-T871E;65N
M='MS=&%T96UE;G0L9&ER96-T?2AC;VYS="!C:&%R*GMS=&%T96UE;G1]+&)O
M;VQ[=7-E7V=D?2DG+ T*)U!Y3V)J96-T*GMN97=](&-A;&Q?<W1A=&5M96YT
M>V%R9W)E<&5A="QS=&%T96UE;G0L9&ER96-T?2AC;VYS="!C:&%R*GMS=&%T
M96UE;G1]+&)O;VQ[=7-E7V=D?2QI;G1[=&5M<&QA=&5]*2<L#0HG4'E/8FIE
M8W0J>VYE=WT at 8V%L;%]S=&%T96UE;G1[87)G<F5P96%T+'-T871E;65N="QD
M:7)E8W1]*&-O;G-T(&-H87(J>W-T871E;65N='TL8F]O;'MU<V5?9V1]+%!Y
M3V)J96-T*BDG+ T*70T*#0I$96-L1FEL92 ]("=P>5]I;G1E<F9A8V4N:'!P
M)PT*26UP;$9I;&4@/2 G<'E?:6YT97)F86-E+F-P<"<-"@T*1&5C;$9I;&5(
M96%D97(@/2 G)R=<#0HO+R!!=71O;6%T:6-A;&QY(&=E;F5R871E9"!F<F]M
M('!Y7V%P:5]G96XN<'D-"B-I9FYD968 at 4%E?24Y415)&04-%7TA04 T*(V1E
M9FEN92!065])3E1%4D9!0T5?2%!0#0H-"B-I;F-L=61E(#QB;V]S="]P>71H
M;VXO;V)J96-T+FAP<#X*(VEN8VQU9&4@/&)O;W-T+W!Y=&AO;B]A<F=?9G)O
M;5]P>71H;VXN:'!P/@T*#0IN86UE<W!A8V4 at 8F]O<W0@>R!N86UE<W!A8V4@
M<'ET:&]N('L@;F%M97-P86-E(&%P:2![#0H-"FYA;65S<&%C92!A<&E?9&5T
M86EL('L-"@T*0D]/4U1?4%E42$].7T1%0TP@;V)J96-T(&=E=%]F=6YC*&-O
M;G-T(&-H87(J(&YA;64I.PT*0D]/4U1?4%E42$].7T1%0TP@;V)J96-T(&-A
M;&Q?<W1A=&5M96YT*&-O;G-T(&-H87(@*G-T;70L(&)O;VP@=7-E7V=L;V)A
M;%]D:6-T*3L-"D)/3U-47U!95$A/3E]$14-,(&]B:F5C="!C86QL7W-T871E
M;65N="AC;VYS="!C:&%R("IS=&UT+"!B;V]L('5S95]G;&]B86Q?9&EC="P@
M:6YT(&XL(&]B:F5C="!C;VYS="H at 7S$L("XN+BD[#0H-"G1E;7!L871E/&-L
M87-S($$^#0IS=')U8W0 at 9V5T7V%R9PT*>PT*(" @(&=E=%]A<F<H02!C;VYS
M=" F82D at .B!H*&$I('M]#0H@(" @;V)J96-T(&@[#0H@(" @;W!E<F%T;W(@
M;V)J96-T(&-O;G-T)B H*2![(')E='5R;B!H.R!]#0H@(" @;W!E<F%T;W(@
M;V)J96-T(&-O;G-T*B H*2![(')E='5R;B F:#L@?0T*?3L-"@T*=&5M<&QA
M=&4\/@T*<W1R=6-T(&=E=%]A<F<\;V)J96-T/@T*>PT*(" @(&=E=%]A<F<H
M;V)J96-T(&-O;G-T("9A*2 Z(&@H82D@>WT-"B @("!O8FIE8W0 at 8V]N<W0@
M)F@[#0H@(" @;W!E<F%T;W(@;V)J96-T(&-O;G-T)B H*2![(')E='5R;B!H
M.R!]#0H@(" @;W!E<F%T;W(@;V)J96-T(&-O;G-T*B H*2![(')E='5R;B F
M:#L@?0T*?3L-"@T*=&5M<&QA=&4\/@T*<W1R=6-T(&=E=%]A<F<\4'E/8FIE
M8W0J/@T*>PT*(" @(&=E=%]A<F<H4'E/8FIE8W0J(&$I(#H@:"AP>71H;VXZ
M.F1E=&%I;#HZ8F]R<F]W961?<F5F97)E;F-E*&$I*2![?0T*(" @(&]B:F5C
M="!H.PT*(" @(&]P97)A=&]R(&]B:F5C="!C;VYS="8@*"D@>R!R971U<FX@
M:#L@?0T*(" @(&]P97)A=&]R(&]B:F5C="!C;VYS="H@*"D@>R!R971U<FX@
M)F@[('T-"GT[#0H-"GT-"@T*)R<G#0H-"D1E8VQ&:6QE5')A:6QE<B ]("<G
M)UP-"GU]?0T*#0HC96YD:68 at +R\@4%E?24Y415)&04-%7TA04 T*)R<G#0H-
M"DEM<&Q&:6QE2&5A9&5R(#T@)R<G7 T*+R\@075T;VUA=&EC86QL>2!G96YE
M<F%T960 at 9G)O;2!P>5]A<&E?9V5N+G!Y#0H-"B-I;F-L=61E(")P>5]I;G1E
M<F9A8V4N:'!P(@H-"FYA;65S<&%C92!B;V]S="![(&YA;65S<&%C92!P>71H
M;VX@>R!N86UE<W!A8V4 at 87!I('L-"@T*;F%M97-P86-E(&%P:5]D971A:6P@
M>PT*#0I"3T]35%]0651(3TY?1$5#3"!O8FIE8W0 at 9V5T7V9U;F,H8V]N<W0@
M8VAA<BH@;F%M92D@>PT*(" @(&]B:F5C="!?7V)U:6QT:6Y?7RAP>71H;VXZ
M.F1E=&%I;#HZ8F]R<F]W961?<F5F97)E;F-E*#HZ4'E);7!O<G1?061D36]D
M=6QE*&-O;G-T7V-A<W0\8VAA<B J/B at B7U]B=6EL=&EN7U\B*2DI*3L-"B @
M("!R971U<FX@;V)J96-T*%]?8G5I;'1I;E]?+F%T='(H;F%M92DI.PT*?0T*
M#0I"3T]35%]0651(3TY?1$5#3"!O8FIE8W0 at 8V%L;%]S=&%T96UE;G0H8V]N
M<W0 at 8VAA<B J<W1M="P at 8F]O;"!U<V5?9VQO8F%L7V1I8W0I#0I[#0H@(" @
M;V)J96-T(&0H87!I.CID:6-T*"DI.PT*(" @(&]B:F5C="!G9"AA<&DZ.F=L
M;V)A;',H*2D[#0H@(" @:68H(75S95]G;&]B86Q?9&EC="D@>PT*(" @(" @
M("!D6R)?7V)U:6QT:6YS7U\B72 ](&=D6R)?7V)U:6QT:6YS7U\B73L-"B @
M(" @(" @9V0@/2!D.PT*(" @('T-"B @("!D6R)?,")=(#T@;V)J96-T*'!Y
M=&AO;CHZ9&5T86EL.CIB;W)R;W=E9%]R969E<F5N8V4H4'E?3F]N92DI.PT*
M(" @(&%P:3HZ<G5N7W-T<FEN9RAS=&UT+"!0>5]F:6QE7VEN<'5T+"!G9"P@
M9"D[#0H@(" @<F5T=7)N(&]B:F5C="AD6R)?,")=*3L-"GT-"@T*0D]/4U1?
M4%E42$].7T1%0TP@;V)J96-T(&-A;&Q?<W1A=&5M96YT*&-O;G-T(&-H87(@
M*G-T;70L(&)O;VP@=7-E7V=L;V)A;%]D:6-T+"!I;G0@;BP@;V)J96-T(&-O
M;G-T*B!?,2P at +BXN*0T*>PT*(" @('-T871I8R!C;VYS="!C:&%R("HH:61X
M6UTI(#T@>R B7S$B+" B7S(B+" B7S,B+" B7S0B+" B7S4B+" B7S8B+" B
M7S<B+" B7S at B+" B7SDB+" B7S$P(B!].PT*(" @('9A7VQI<W0@;6L[#0H@
M(" @;V)J96-T(&0H87!I.CID:6-T*"DI.PT*(" @(&]B:F5C="!G9"AA<&DZ
M.F=L;V)A;',H*2D[#0H@(" @:68H(75S95]G;&]B86Q?9&EC="D@>PT*(" @
M(" @("!D6R)?7V)U:6QT:6YS7U\B72 ](&=D6R)?7V)U:6QT:6YS7U\B73L-
M"B @(" @(" @9V0@/2!D.PT*(" @('T-"B @("!D6R)?,")=(#T@;V)J96-T
M*'!Y=&AO;CHZ9&5T86EL.CIB;W)R;W=E9%]R969E<F5N8V4H4'E?3F]N92DI
M.PT*(" @('9A7W-T87)T*&UK+"!?,2D[#0H@(" @;V)J96-T(&-O;G-T*B!P
M7V%R9R ](%\Q.PT*(" @(&9O<BAI;G0@:2 ](# [(&D@/"!N.R K*VDI#0H@
M(" @>PT*(" @(" @("!O8FIE8W0 at 8V]N<W0F(&%R9R ]("IP7V%R9SL-"B @
M(" @(" @:68H:2 \('-I>F5O9BAI9'@I("\@<VEZ96]F*&ED>%LP72DI#0H@
M(" @(" @(" @("!D6VED>%MI75T@/2!A<F<[#0H@(" @(" @(&5L<V4@>PT*
M(" @(" @(" @(" @9%MO8FIE8W0H(E\B*2 K(&]B:F5C="AP>71H;VXZ.F1E
M=&%I;#HZ;F5W7W)E9F5R96YC92A0>4]B:F5C=%]3='(H;V)J96-T*&D@*R Q
M*2YP='(H*2DI*5T@/2!A<F<[#0H@(" @(" @('T-"B @(" @(" @<%]A<F<@
M/2!V85]A<F<H;6LL(&]B:F5C="!C;VYS="HI.PT*(" @('T-"B @("!V85]E
M;F0H;6LI.PT*(" @(&%P:3HZ<G5N7W-T<FEN9RAS=&UT+"!0>5]F:6QE7VEN
M<'5T+"!G9"P at 9"D[#0H@(" @<F5T=7)N(&]B:F5C="AD6R)?,")=*3L-"GT-
M"@T*?0T*#0HG)R<-"@T*26UP;$9I;&54<F%I;&5R(#T@)R<G7 T*?7U]#0HG
M)R<-"@T*9&5F(%-P;&ET3W5T3&ES="AL*3H-"B @("!V86QS7VQI<W0@/2!;
M70T*(" @(&EF(&P@/3T at 3F]N93H-"B @(" @(" @<F5T=7)N('9A;'-?;&ES
M= T*(" @('9A;'-?;&ES=" ](')E+F9I;F1A;&PH<B<H*#\Z6UXL>WU=?"@_
M.GM;7GM]72I]*2DK*2P_7',J)RP@;"D-"B @("!R971U<FX@=F%L<U]L:7-T
M#0H-"F1E9B!3<&QI=$]U=$QI<W1$:6-T*&PI. at T*(" @('9A;'-?9&EC=" ]
M('M]#0H@(" @:68@;" ]/2!.;VYE. at T*(" @(" @("!R971U<FX@=F%L<U]D
M:6-T#0H@(" @=F%L<R ](')E+F9I;F1A;&PH<B<H*#\Z(EM>(ETK(GQ;7BPB
M72LI*RE<<RHL/R<L(&PI#0H@(" @9F]R('9A;"!I;B!V86QS. at T*(" @(" @
M("!M(#T@<F4N;6%T8V at H<B<H/U \86YA;64^6UY<<SU=*RE<<RHH/5QS*B at _
M4#QQ=#XB/RDH/U \879A;#XN*RDH/U ]<70I*3\G+"!V86PI+F=R;W5P9&EC
M="@I#0H@(" @(" @('9A;'-?9&EC=%MM6R=A;F%M92==72 ](&U;)V%V86PG
M70T*(" @(')E='5R;B!V86QS7V1I8W0-"@T*9&5F(%-P;&ET3W5T071T<G,H
M82DZ#0H@(" @<V]A(#T@>WT-"B @("!M(#T@<F4N;6%T8V at H<B<H/U \;F%M
M93Y;7GM=*RDH>R at _4#QA='1R<SY;7GU=*RE]*3\G+"!A*2YG<F]U<&1I8W0H
M*0T*(" @('-O85LG;F%M92==(#T@;5LG;F%M92==#0H@(" @<V]A+G5P9&%T
M92A3<&QI=$]U=$QI<W1$:6-T*&U;)V%T=')S)UTI*0T*(" @(')E='5R;B!S
M;V$-"@T*9&5F(&ES7V]B:F5C="AN86UE*3H-"B @("!I9B!R92YM871C:"AR
M)U!Y3V)J96-T7',J7"HG+"!N86UE6R=N86UE)UTI. at T*(" @(" @("!R971U
M<FX@,0T*(" @(')E='5R;B P#0H-"F1E9B!I<U]A<F=?<F5A;&QY7V-O;G-T
M*&%R9RDZ#0H@(" @<F5T=7)N(&%R9RYH87-?:V5Y*"=C;VYS="<I#0H-"F1E
M9B!G971?86-T=6%L7W)T;E]T>7!E*')T;BP at 87)G<RDZ#0H@(" @:2 ](# -
M"B @("!F;W(@82!I;B!A<F=S. at T*(" @(" @("!I9B!A+FAA<U]K97DH)W)E
M<W5L="<I. at T*(" @(" @(" @(" @=')U95]R=&X@/2!D:6-T*')T;BD-"B @
M(" @(" @(" @('1R=65?<G1N6R=N86UE)UT@/2!A6R=N86UE)UT-"B @(" @
M(" @(" @('1R=65?<G1N6R=A<F=?;G5M8F5R)UT@/2!I#0H@(" @(" @(" @
M("!R971U<FX@=')U95]R=&X-"B @(" @(" @:2 K/2 Q#0H@(" @<F5T=7)N
M(')T;@T*#0ID968@:7-?=&5M<&QA=&4H;F%M92DZ#0H@(" @<F5T=7)N(&YA
M;64N:&%S7VME>2 at G=&5M<&QA=&4G*0T*#0ID968 at 9&5C;%]F=6YC7V%R9RAA
M<F<L(' I. at T*(" @(&EF(&%R9RYH87-?:V5Y*"=V86QU92<I. at T*(" @(" @
M("!R971U<FX@)R<-"B @("!E;&EF(&%R9RYH87-?:V5Y*"=R97-U;'0G*3H-
M"B @(" @(" @<F5T=7)N("<G#0H@(" @96QI9B!I<U]O8FIE8W0H87)G*3H-
M"B @(" @(" @:68@:7-?=&5M<&QA=&4H87)G*3H-"B @(" @(" @(" @('-N
M(#T@<W1R*' I#0H@(" @(" @(" @("!R971U<FX@)T$G("L@<VX@*R<@8V]N
M<W0F(&$G("L@<VX-"B @(" @(" @96QS93H-"B @(" @(" @(" @(')E='5R
M;B G;V)J96-T(&-O;G-T)B!A)R K('-T<BAP*0T*(" @(&5L:68@:7-?87)G
M7W)E86QL>5]C;VYS="AA<F<I. at T*(" @(" @("!R971U<FX@)V-O;G-T("<@
M*R!A<F=;)VYA;64G72 K("<@82<@*R!S='(H<"D-"B @("!E;&EF(')E+G-E
M87)C:"AR)V%R9R<L(&%R9ULG;F%M92==*3H-"B @(" @(" @<F5T=7)N(')E
M+G-U8BAR)V%R9R<L("=A)R K('-T<BAP*2P at 87)G6R=N86UE)UTI#0H@(" @
M96QS93H-"B @(" @(" @:68@:7-?=&5M<&QA=&4H87)G*3H-"B @(" @(" @
M(" @('-N(#T@<W1R*' I#0H@(" @(" @(" @("!R971U<FX@)T$G("L@<VX@
M*R<@8V]N<W0F(&$G("L@<VX-"B @(" @(" @96QS93H-"B @(" @(" @(" @
M(')E='5R;B!A<F=;)VYA;64G72 K("<@82<@*R!S='(H<"D-"@T*9&5F(&1E
M8VQ?9G5N8U]A<F=S*&YA;64L(&%R9W,I. at T*(" @(&EF(&YO="!L96XH87)G
M<RDZ#0H@(" @(" @(')E='5R;B G)PT*(" @(&1?87)G<R ](')E9'5C92AL
M86UB9&$@>"QY(#H@>" K("AY(&%N9" H)RP@)R K('DI(&]R("<G*2P@;6%P
M*&1E8VQ?9G5N8U]A<F<L(&%R9W,L('AR86YG92AL96XH87)G<RDI*2D-"B @
M("!R971U<FX at 9%]A<F=S#0H-"F1E9B!C86QL7V9U;F-?87)G*&%R9RP@<"DZ
M#0H@(" @:68 at 87)G+FAA<U]K97DH)W9A;'5E)RDZ#0H@(" @(" @(')E='5R
M;B!A<F=;)W9A;'5E)UT-"B @("!E;&EF(&%R9RYH87-?:V5Y*"=R97-U;'0G
M*3H-"B @(" @(" @<F5T=7)N("<F<G-L="<-"B @("!E;&EF(&%R9RYH87-?
M:V5Y*"=T96UP;&%T92<I. at T*(" @(" @("!S;B ]('-T<BAP*0T*(" @(" @
M("!R971U<FX@)V%P:5]D971A:6PZ.F=E=%]A<F<\025S/BAA)7,I)R E("AS
M;BP@<VXI#0H@(" @96QI9B!A<F<N:&%S7VME>2 at G;V)J96-T)RDZ#0H@(" @
M(" @(')E='5R;B G;V)J96-T*&$E<RDN<'1R*"DG("4@<W1R*' I#0H@(" @
M96QI9B!I<U]O8FIE8W0H87)G*3H-"B @(" @(" @<F5T=7)N("=A)R K('-T
M<BAP*2 K("<N<'1R*"DG#0H@(" @96QI9B!I<U]A<F=?<F5A;&QY7V-O;G-T
M*&%R9RDZ#0H@(" @(" @(')E='5R;B G8V]N<W1?8V%S=#PE<SXH)7,I)R E
M("AA<F=;)VYA;64G72P@)V$G("L@<W1R*' I*0T*(" @(&5L<V4Z#0H@(" @
M(" @(')E='5R;B G82<@*R!S='(H<"D-"@T*9&5F(&-A;&Q?9G5N8U]A<F=S
M*&%R9W,I. at T*(" @(&EF(&YO="!L96XH87)G<RDZ#0H@(" @(" @(')E='5R
M;B G)PT*(" @(&1?87)G<R ](')E9'5C92AL86UB9&$@>"QY(#H@>" K("AY
M(&%N9" H*'@@86YD("<L("<@;W(@)R<I("L@>2D@;W(@)R<I+"!M87 H8V%L
M;%]F=6YC7V%R9RP at 87)G<RP@>')A;F=E*&QE;BAA<F=S*2DI*0T*(" @(')E
M='5R;B!D7V%R9W,-"@T*9&5F(&-A;&Q?9G5N8RAN86UE+"!A<F=S*3H-"B @
M("!R971U<FX@)SHZ)7,H)7,I)R E("AN86UE6R=N86UE)UTL(&-A;&Q?9G5N
M8U]A<F=S*&%R9W,I*0T*#0ID968 at 8V%L;%]F=6YC7V1I<F5C=%]A<F<H87)G
M+"!P*3H-"B @("!I9B!A<F<N:&%S7VME>2 at G=7-E7V=D)RDZ#0H@(" @(" @
M(')E='5R;B G)PT*(" @(&5L:68 at 87)G+FAA<U]K97DH)W-T871E;65N="<I
M. at T*(" @(" @("!R971U<FX@)R<-"B @("!E;&EF(&%R9RYH87-?:V5Y*"=V
M86QU92<I. at T*(" @(" @("!R971U<FX at 87)G6R=V86QU92==#0H@(" @96QI
M9B!A<F<N:&%S7VME>2 at G=&5M<&QA=&4G*3H-"B @(" @(" @<VX@/2!S='(H
M<"D-"B @(" @(" @:68 at 87)G+FAA<U]K97DH)V%D9'(G*3H-"B @(" @(" @
M(" @(')E='5R;B G*&]B:F5C="!C;VYS="HI87!I7V1E=&%I;#HZ9V5T7V%R
M9SQ!)7,^*&$E<RDG("4@*'-N+"!S;BD-"B @(" @(" @96QS93H-"B @(" @
M(" @(" @(')E='5R;B G87!I7V1E=&%I;#HZ9V5T7V%R9SQ!)7,^*&$E<RDG
M("4@*'-N+"!S;BD-"B @("!E;&EF(&ES7V]B:F5C="AA<F<I. at T*(" @(" @
M("!I9B!A<F<N:&%S7VME>2 at G861D<B<I. at T*(" @(" @(" @(" @<F5T=7)N
M("<F82<@*R!S='(H<"D-"B @(" @(" @96QS93H-"B @(" @(" @(" @(')E
M='5R;B G82<@*R!S='(H<"D-"B @("!E;'-E. at T*(" @(" @("!I9B!A<F<N
M:&%S7VME>2 at G861D<B<I. at T*(" @(" @(" @(" @<F5T=7)N("<F;V)J96-T
M*&$E<RDG("4@<W1R*' I#0H@(" @(" @(&5L<V4Z#0H@(" @(" @(" @("!R
M971U<FX@)V]B:F5C="AA)7,I)R E('-T<BAP*0T*(" @( T*9&5F(&-A;&Q?
M9G5N8U]D:7)E8W1?87)G<RAA<F=S*3H-"B @("!I9B!N;W0@;&5N*&%R9W,I
M. at T*(" @(" @("!R971U<FX@)R<-"B @("!D7V%R9W,@/2!R961U8V4H;&%M
M8F1A('@L>2 Z('@@*R H>2!A;F0@*"AX(&%N9" G+" G(&]R("<G*2 K('DI
M(&]R("<G*2P@;6%P*&-A;&Q?9G5N8U]D:7)E8W1?87)G+"!A<F=S+"!X<F%N
M9V4H;&5N*&%R9W,I*2DI#0H@(" @<F5T=7)N(&1?87)G<PT*#0ID968 at 9V5T
M7W-T871E;65N=%]A<F<H87)G<RDZ#0H@(" @:2 ](# -"B @("!F;W(@87)G
M(&EN(&%R9W,Z#0H@(" @(" @(&EF(&%R9RYH87-?:V5Y*"=S=&%T96UE;G0G
M*3H-"B @(" @(" @(" @(')E='5R;B!I#0H@(" @(" @(&D@/2!I("L@,0T*
M(" @(')E='5R;B M,0T*#0ID968 at 9V5T7W5S95]G9%]A<F<H87)G<RDZ#0H@
M(" @:2 ](# -"B @("!F;W(@87)G(&EN(&%R9W,Z#0H@(" @(" @(&EF(&%R
M9RYH87-?:V5Y*"=U<V5?9V0G*3H-"B @(" @(" @(" @(')E='5R;B!I#0H@
M(" @(" @(&D@/2!I("L@,0T*(" @(')E='5R;B M,0T*#0ID968 at 8V%L;%]F
M=6YC7V1I<F5C="AN86UE+"!A<F=S*3H-"B @("!I9B!N86UE+FAA<U]K97DH
M)W-T871E;65N="<I. at T*(" @(" @("!N82 ](&QE;BAA<F=S*0T*(" @(" @
M("!U9V0@/2!G971?=7-E7V=D7V%R9RAA<F=S*0T*(" @(" @("!I9B!U9V0@
M/CT@,#H-"B @(" @(" @(" @('5G9" ]("=A)R K('-T<BAU9V0I#0H@(" @
M(" @(" @("!N82 ](&YA("T@,0T*(" @(" @("!E;'-E. at T*(" @(" @(" @
M(" @=6=D(#T@)W1R=64G#0H@(" @(" @('-A(#T at 9V5T7W-T871E;65N=%]A
M<F<H87)G<RD-"B @(" @(" @:68@<V$@/CT@,#H-"B @(" @(" @(" @(&YA
M(#T@;F$@+2 Q#0H@(" @(" @(" @("!I9B!N82 ^(# Z#0H@(" @(" @(" @
M(" @(" @<F5T=7)N("=A<&E?9&5T86EL.CIC86QL7W-T871E;65N="@E<RP@
M)7,L("5S+" E<RDG("4@*"=A)R K('-T<BAS82DL('5G9"P@;F$L(&-A;&Q?
M9G5N8U]D:7)E8W1?87)G<RAA<F=S*2D-"B @(" @(" @(" @(&5L<V4Z#0H@
M(" @(" @(" @(" @(" @<F5T=7)N("=A<&E?9&5T86EL.CIC86QL7W-T871E
M;65N="@E<RP@)7,I)R E("@G82<@*R!S='(H<V$I+"!U9V0I#0H@(" @(" @
M(&5L<V4Z#0H@(" @(" @(" @("!I9B!N82 ^(# Z#0H@(" @(" @(" @(" @
M(" @<F5T=7)N("=A<&E?9&5T86EL.CIC86QL7W-T871E;65N="@B)7,B+" E
M<RP@)7,L("5S*2<@)2 H;F%M95LG<W1A=&5M96YT)UTL('5G9"P@;F$L(&-A
M;&Q?9G5N8U]D:7)E8W1?87)G<RAA<F=S*2D-"B @(" @(" @(" @(&5L<V4Z
M#0H@(" @(" @(" @(" @(" @<F5T=7)N("=A<&E?9&5T86EL.CIC86QL7W-T
M871E;65N="@B)7,B+" E<RDG("4@*&YA;65;)W-T871E;65N="==+"!U9V0I
M#0H@(" @96QS93H-"B @(" @(" @<F5T=7)N("=A<&E?9&5T86EL.CIG971?
M9G5N8R at B)7,B*2 at E<RDG("4@*&YA;65;)VYA;64G72P at 8V%L;%]F=6YC7V1I
M<F5C=%]A<F=S*&%R9W,I*0T*#0ID968 at 9&5C;%]T96UP;&%T95]A<F<H87)G
M+"!P*3H-"B @("!I9B!A<F<N:&%S7VME>2 at G=F%L=64G*3H-"B @(" @(" @
M<F5T=7)N("<G#0H@(" @96QI9B!A<F<N:&%S7VME>2 at G<F5S=6QT)RDZ#0H@
M(" @(" @(')E='5R;B G)PT*(" @(&5L:68@:7-?=&5M<&QA=&4H87)G*3H-
M"B @(" @(" @<F5T=7)N("=C;&%S<R!!)R K('-T<BAP*0T*(" @(&5L<V4Z
M#0H@(" @(" @(')E='5R;B G)PT*#0ID968 at 9&5C;%]T96UP;&%T95]A<F=S
M*&%R9W,I. at T*(" @(&EF(&YO="!L96XH87)G<RDZ#0H@(" @(" @(')E='5R
M;B G)PT*(" @(&1?87)G<R ](')E9'5C92AL86UB9&$@>"QY(#H@>" K("AY
M(&%N9" H*'@@86YD("<L("<@;W(@)R<I("L@>2D@;W(@)R<I+"!M87 H9&5C
M;%]T96UP;&%T95]A<F<L(&%R9W,L('AR86YG92AL96XH87)G<RDI*2D-"B @
M("!R971U<FX at 9%]A<F=S#0H-"F1E9B!I<U]R=&Y?8F]R<F]W961?;V)J96-T
M*')T;BDZ#0H@(" @:68@:7-?;V)J96-T*')T;BDZ#0H@(" @(" @(')E='5R
M;B!R=&XN:&%S7VME>2 at G8F]R<F]W960G*0T*(" @(&5L<V4Z#0H@(" @(" @
M(')E='5R;B P#0H-"F1E9B!I<U]R=&Y?;F5W7V]B:F5C="AR=&XI. at T*(" @
M(&EF(&ES7V]B:F5C="AR=&XI. at T*(" @(" @("!R971U<FX@;F]T(')T;BYH
M87-?:V5Y*"=B;W)R;W=E9"<I#0H@(" @96QS93H-"B @(" @(" @<F5T=7)N
M(# -"@T*9&5F(&ES7V9U;F-?9&ER96-T*&YA;64I. at T*(" @(')E='5R;B!N
M86UE+FAA<U]K97DH)V1I<F5C="<I#0H-"F1E9B!R=&Y?8V%L;%]F=6YC7V1I
M<F5C="AR=&XL(&YA;64L(&%R9W,I. at T*(" @(&EF(')T;ELG;F%M92==(#T]
M("=V;VED)SH-"B @(" @(" @9&ER96-T7V-O9&4@/2 G(" @("5S.R<@)2!C
M86QL7V9U;F-?9&ER96-T*&YA;64L(&%R9W,I#0H@(" @96QI9B!I<U]O8FIE
M8W0H<G1N*3H-"B @(" @(" @9&ER96-T7V-O9&4@/2 G(" @(')E='5R;B E
M<SLG("4 at 8V%L;%]F=6YC7V1I<F5C="AN86UE+"!A<F=S*0T*(" @(&5L<V4Z
M#0H@(" @(" @('(@/2 G)R=<#0H@(" @;V)J96-T('(H)7,I.PT*(" @(')E
M='5R;B!B;V]S=#HZ<'ET:&]N.CIA<F=?9G)O;5]P>71H;VX\)7,^*'(N<'1R
M*"DI*'(N<'1R*"DI.R<G)PT*(" @(" @("!D:7)E8W1?8V]D92 ]('(@)2 H
M8V%L;%]F=6YC7V1I<F5C="AN86UE+"!A<F=S*2P@<G1N6R=N86UE)UTI#0H@
M(" @<F5T=7)N(&1I<F5C=%]C;V1E#0H-"F1E9B!R=&Y?8V%L;%]F=6YC*')T
M;BP@;F%M92P at 87)G<RDZ#0H@(" @:68@:7-?9G5N8U]D:7)E8W0H;F%M92DZ
M#0H@(" @(" @(')E='5R;B!R=&Y?8V%L;%]F=6YC7V1I<F5C="AR=&XL(&YA
M;64L(&%R9W,I#0H@(" @=')U95]R=&X@/2!G971?86-T=6%L7W)T;E]T>7!E
M*')T;BP at 87)G<RD-"B @("!E<G(@/2!T<G5E7W)T;BYG970H)V5R<B<I#0H@
M(" @87)G7VYU;6)E<B ]('1R=65?<G1N+F=E="@G87)G7VYU;6)E<B<I#0H@
M(" @:68@<G1N6R=N86UE)UT@/3T@)W9O:60G. at T*(" @(" @("!R971U<FX@
M)R @(" E<SLG("4 at 8V%L;%]F=6YC*&YA;64L(&%R9W,I#0H@(" @96QI9B!I
M<U]R=&Y?;F5W7V]B:F5C="AR=&XI. at T*(" @(" @("!I9B!E<G(@86YD("AE
M<G(@(3T@)TY53$PG*3H-"B @(" @(" @(" @('(@/2 G)R=<#0H@(" @4'E/
M8FIE8W0J('(@/2 E<SL-"B @("!I9BAR(#T]("5S*0T*(" @(" @("!T:')O
M=U]E<G)O<E]A;')E861Y7W-E="@I.PT*(" @(')E='5R;B!O8FIE8W0H<'ET
M:&]N.CID971A:6PZ.FYE=U]R969E<F5N8V4H<BDI.R<G)PT*(" @(" @(" @
M(" @<F5T=7)N('(@)2 H8V%L;%]F=6YC*&YA;64L(&%R9W,I+"!E<G(I#0H@
M(" @(" @(&5L<V4Z#0H@(" @(" @(" @("!R971U<FX@)R @("!R971U<FX@
M;V)J96-T*'!Y=&AO;CHZ9&5T86EL.CIN97=?<F5F97)E;F-E*"5S*2D[)R E
M(&-A;&Q?9G5N8RAN86UE+"!A<F=S*0T*(" @(&5L:68@:7-?<G1N7V)O<G)O
M=V5D7V]B:F5C="AR=&XI. at T*(" @(" @("!I9B!E<G(@86YD("AE<G(@(3T@
M)TY53$PG*3H-"B @(" @(" @(" @('(@/2 G)R=<#0H@(" @4'E/8FIE8W0J
M('(@/2 E<SL-"B @("!I9BAR(#T]("5S*0T*(" @(" @("!T:')O=U]E<G)O
M<E]A;')E861Y7W-E="@I.PT*(" @(')E='5R;B!O8FIE8W0H<'ET:&]N.CID
M971A:6PZ.F)O<G)O=V5D7W)E9F5R96YC92AR*2D[)R<G#0H@(" @(" @(" @
M("!R971U<FX@<B E("AC86QL7V9U;F,H;F%M92P at 87)G<RDL(&5R<BD-"B @
M(" @(" @96QS93H-"B @(" @(" @(" @(')E='5R;B G(" @(')E='5R;B!O
M8FIE8W0H<'ET:&]N.CID971A:6PZ.F)O<G)O=V5D7W)E9F5R96YC92 at E<RDI
M.R<@)2!C86QL7V9U;F,H;F%M92P at 87)G<RD-"B @("!E;'-E. at T*(" @(" @
M("!I9B!E<G(Z#0H@(" @(" @(" @("!I9B!A<F=?;G5M8F5R(#T]($YO;F4Z
M#0H@(" @(" @(" @(" @(" @<B ]("<G)UP-"B @(" E<R!R(#T@)7,[#0H@
M(" @:68H<B ]/2 E<RD-"B @(" @(" @=&AR;W=?97)R;W)?86QR96%D>5]S
M970H*3L-"B @("!R971U<FX@<CLG)R<-"B @(" @(" @(" @(" @("!R971U
M<FX@<B E("AR=&Y;)VYA;64G72P at 8V%L;%]F=6YC*&YA;64L(&%R9W,I+"!E
M<G(I#0H@(" @(" @(" @("!E;'-E. at T*(" @(" @(" @(" @(" @('(@/2 G
M)R=<#0H@(" @)7,@<G-L=#L-"B @(" E<R!R(#T@)7,[#0H@(" @:68H<B ]
M/2 E<RD-"B @(" @(" @=&AR;W=?97)R;W)?86QR96%D>5]S970H*3L-"B @
M("!R971U<FX@<G-L=#LG)R<-"B @(" @(" @(" @(" @("!R971U<FX@<B E
M("AT<G5E7W)T;ELG;F%M92==+"!R=&Y;)VYA;64G72P at 8V%L;%]F=6YC*&YA
M;64L(&%R9W,I+"!E<G(I#0H@(" @(" @(&5L<V4Z#0H@(" @(" @(" @("!R
M971U<FX@)R @("!R971U<FX@)7,[)R E(&-A;&Q?9G5N8RAN86UE+"!A<F=S
M*0T*#0ID968 at 9&5C;%]F=6YC*&YA;64L(&%R9W,I. at T*(" @(')E='5R;B G
M)7,H)7,I)R E("AN86UE+F=E="@G9&5C;"<L(&YA;65;)VYA;64G72DL(&1E
M8VQ?9G5N8U]A<F=S*&YA;64L(&%R9W,I*0T*#0ID968@<G1N7V1E8VQ?9G5N
M8RAR=&XL(&YA;64L(&%R9W,I. at T*(" @('1R=65?<G1N(#T at 9V5T7V%C='5A
M;%]R=&Y?='EP92AR=&XL(&%R9W,I#0H@(" @=&$@/2!D96-L7W1E;7!L871E
M7V%R9W,H87)G<RD-"B @("!I9B!T83H-"B @(" @(" @9&5C;" ]("=T96UP
M;&%T93PE<SY<;B<@)2!T80T*(" @(&5L<V4Z#0H@(" @(" @(&1E8VP@/2 G
M0D]/4U1?4%E42$].7T1%0TP@)PT*(" @(&EF(&ES7V]B:F5C="AT<G5E7W)T
M;BDZ#0H@(" @(" @(')E='5R;B!D96-L("L@)V]B:F5C=" E<R<@)2!D96-L
M7V9U;F,H;F%M92P at 87)G<RD-"B @("!E;'-E. at T*(" @(" @("!R971U<FX@
M9&5C;" K("<E<R E<R<@)2 H=')U95]R=&Y;)VYA;64G72P at 9&5C;%]F=6YC
M*&YA;64L(&%R9W,I*0T*#0ID968@:7-?:6YF;U]T96UP;&%T92AF;E]I;F9O
M*3H-"B @("!F;W(@87)G(&EN(&9N7VEN9F];)V%R9W,G73H-"B @(" @(" @
M:68@:7-?=&5M<&QA=&4H87)G*3H-"B @(" @(" @(" @(')E='5R;B Q#0H@
M(" @<F5T=7)N(# -"@T*9&5F('!A<G-E7V9U;F,H9G5N8RDZ#0H@(" @9FY?
M:6YF;R ]('M]#0H@(" @9FYM(#T@<F4N;6%T8V at H<B<H/U \<G1N/EQ3*RE<
M<RLH/U \9FYA;64^6UY<<UPH7"E[?5TK*'M;7GM]72I]*3\I7',J7"@H/U \
M87)G<SXH*'M;7GM]72I]*2M\*%PH6UY<*%PI72I<*2DK?%M>7"A<*5TK*2HI
M7"DG+"!F=6YC*2YG<F]U<&1I8W0H*0T*(" @(&9N7VEN9F];)V9N86UE)UT@
M/2!3<&QI=$]U=$%T=')S*&9N;5LG9FYA;64G72D-"B @("!F;E]I;F9O6R=R
M=&XG72 ](%-P;&ET3W5T071T<G,H9FYM6R=R=&XG72D-"B @("!F;E]I;F9O
M6R=A<F=S)UT@/2!M87 H4W!L:71/=71!='1R<RP at 4W!L:71/=71,:7-T*&9N
M;5LG87)G<R==*2D-"B @("!I9B!F;E]I;F9O6R=F;F%M92==+FAA<U]K97DH
M)W-T871E;65N="<I. at T*(" @(" @("!I9B!I<U]I;F9O7W1E;7!L871E*&9N
M7VEN9F\I. at T*(" @(" @(" @(" @9F]R(&%R9R!I;B!F;E]I;F9O6R=A<F=S
M)UTZ#0H@(" @(" @(" @(" @(" @:68@:7-?=&5M<&QA=&4H87)G*3H-"B @
M(" @(" @(" @(" @(" @(" @87)G6R=A9&1R)UT@/2!.;VYE#0H@(" @(" @
M(&5L<V4Z#0H@(" @(" @(" @("!F;W(@87)G(&EN(&9N7VEN9F];)V%R9W,G
M73H-"B @(" @(" @(" @(" @("!I9B!I<U]O8FIE8W0H87)G*3H-"B @(" @
M(" @(" @(" @(" @(" @87)G6R=A9&1R)UT@/2!.;VYE#0H@(" @<F5T=7)N
M(&9N7VEN9F\-"@T*9&5F(&=E=%]A<F=R97!E870H9FY?:6YF;RDZ#0H@(" @
M:68 at 9FY?:6YF;ULG9FYA;64G72YH87-?:V5Y*"=A<F=R97!E870G*3H-"B @
M(" @(" @87)G<F5P96%T(#T at 9FY?:6YF;ULG9FYA;64G75LG87)G<F5P96%T
M)UT-"B @(" @(" @:68 at 87)G<F5P96%T(#T]($YO;F4Z#0H@(" @(" @(" @
M("!A<F=R97!E870@/2 Q, T*(" @(&5L<V4Z#0H@(" @(" @(&%R9W)E<&5A
M=" ](#$-"B @("!R971U<FX at 87)G<F5P96%T#0H-"F1E9B!D;U]A<F=?<F5P
M96%T*&9N7VEN9F\I. at T*(" @(&9N7VEN9F];)V%R9W,G72 ](&9N7VEN9F];
M)V%R9W,G72 K(%MF;E]I;F9O6R=A<F=S)UU;;&5N*&9N7VEN9F];)V%R9W,G
M72D at +2 Q72Q=#0H@(" @:68 at 9FY?:6YF;ULG9FYA;64G72YH87-?:V5Y*"=S
M=&%T96UE;G0G*3H-"B @(" @(" @<W1M=" ](&9N7VEN9F];)V9N86UE)UU;
M)W-T871E;65N="==#0H@(" @(" @(&EF('-T;70Z#0H@(" @(" @(" @("!S
M7V%R9W,@/2!R92YF:6YD86QL*'(G6UQS+%PH72 at _.E\H6S M.5TK*2DH/STD
M?%M<<RQ<*5TI)RP@<W1M="D-"B @(" @(" @(" @(&EF('-?87)G<SH-"B @
M(" @(" @(" @(" @("!M>" ](')E9'5C92AM87 at L(&UA<"AI;G0L('-?87)G
M<RDL(# I#0H@(" @(" @(" @(" @(" @;7A?87)G(#T@)U\G("L@<W1R*&UX
M*0T*(" @(" @(" @(" @(" @(&YE>'1?87)G(#T@)U\G("L@<W1R*&UX("L@
M,2D-"B @(" @(" @(" @(" @("!S=&UT(#T@<F4N<W5B*'(G*#\\/5M<<RQ<
M*%TI)R K(&UX7V%R9R K("<H/STD?%M<<RQ<*5TI)RP@;7A?87)G("L@)RP@
M)R K(&YE>'1?87)G+"!S=&UT+" Q*0T*(" @(" @(" @(" @(" @(&9N7VEN
M9F];)V9N86UE)UU;)W-T871E;65N="==(#T@<W1M= T*(" @( T*9&5F(&1E
M8VQ?9G5N8W,H9FY?;&ES="DZ#0H@(" @9FY?9&5F<R ]("<G#0H@(" @9F]R
M(&9N(&EN(&9N7VQI<W0Z#0H@(" @(" @(&9N7VEN9F\@/2!P87)S95]F=6YC
M*&9N*0T*(" @(" @("!A<F=R97!E870@/2!G971?87)G<F5P96%T*&9N7VEN
M9F\I#0H@(" @(" @(&9O<B!A<B!I;B!X<F%N9V4H87)G<F5P96%T*3H-"B @
M(" @(" @(" @(&9N7V1E9G,@*ST@<G1N7V1E8VQ?9G5N8RAF;E]I;F9O6R=R
M=&XG72P at 9FY?:6YF;ULG9FYA;64G72P at 9FY?:6YF;ULG87)G<R==*0T*(" @
M(" @(" @(" @:68@:7-?:6YF;U]T96UP;&%T92AF;E]I;F9O*3H-"B @(" @
M(" @(" @(" @("!F;E]D969S("L]("=<;GM<;B<@*R!R=&Y?8V%L;%]F=6YC
M*&9N7VEN9F];)W)T;B==+"!F;E]I;F9O6R=F;F%M92==+"!F;E]I;F9O6R=A
M<F=S)UTI("L@)UQN?5QN)PT*(" @(" @(" @(" @96QS93H-"B @(" @(" @
M(" @(" @("!F;E]D969S("L]("<[7&XG#0H@(" @(" @(" @("!I9B!A<B A
M/2 H87)G<F5P96%T("T@,2DZ#0H@(" @(" @(" @(" @(" @9&]?87)G7W)E
M<&5A="AF;E]I;F9O*0T*(" @(')E='5R;B!F;E]D969S#0H@(" @#0ID968@
M:6UP;%]F=6YC<RAF;E]L:7-T*3H-"B @("!F;E]D969S(#T@)R<-"B @("!F
M;W(@9FX@:6X at 9FY?;&ES=#H-"B @(" @(" @9FY?:6YF;R ]('!A<G-E7V9U
M;F,H9FXI#0H@(" @(" @(&EF(&ES7VEN9F]?=&5M<&QA=&4H9FY?:6YF;RDZ
M#0H@(" @(" @(" @("!C;VYT:6YU90T*(" @(" @("!A<F=R97!E870@/2!G
M971?87)G<F5P96%T*&9N7VEN9F\I#0H@(" @(" @(&9O<B!A<B!I;B!X<F%N
M9V4H87)G<F5P96%T*3H-"B @(" @(" @(" @(&9N7V1E9G,@*ST@<G1N7V1E
M8VQ?9G5N8RAF;E]I;F9O6R=R=&XG72P at 9FY?:6YF;ULG9FYA;64G72P at 9FY?
M:6YF;ULG87)G<R==*2 K("<@>UQN)PT*(" @(" @(" @(" @9FY?9&5F<R K
M/2!R=&Y?8V%L;%]F=6YC*&9N7VEN9F];)W)T;B==+"!F;E]I;F9O6R=F;F%M
M92==+"!F;E]I;F9O6R=A<F=S)UTI("L@)UQN?5QN7&XG#0H@(" @(" @(" @
M("!I9B!A<B A/2 H87)G<F5P96%T("T@,2DZ#0H@(" @(" @(" @(" @(" @
M9&]?87)G7W)E<&5A="AF;E]I;F9O*0T*(" @(')E='5R;B!F;E]D969S#0H-
M"F8@/2!F:6QE*$1E8VQ&:6QE+" G=R<I#0IP<FEN=" ^/F8L($1E8VQ&:6QE
M2&5A9&5R#0IP<FEN=" ^/F8L(&1E8VQ?9G5N8W,H05!)7TQI<W0I#0IP<FEN
M=" ^/F8L($1E8VQ&:6QE5')A:6QE<@T*9BYC;&]S92 at I#0H-"F8@/2!F:6QE
M*$EM<&Q&:6QE+" G=R<I#0IP<FEN=" ^/F8L($EM<&Q&:6QE2&5A9&5R#0IP
M<FEN=" ^/F8L(&EM<&Q?9G5N8W,H05!)7TQI<W0I#0IP<FEN=" ^/F8L($EM
:<&Q&:6QE5')A:6QE<@T*9BYC;&]S92 at I#0H`
`
end







From david.abrahams at rcn.com  Thu Jul 11 22:15:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 11 Jul 2002 16:15:16 -0400
Subject: [C++-sig] Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org> <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com> <aghqg0$p8o$1@main.gmane.org> <0f0a01c2283c$4555b9b0$6601a8c0@boostconsulting.com> <agkd5j$ai8$1@main.gmane.org>
Message-ID: <13c301c22917$b9ca1350$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>

> I had to keep the get_args code for those functions that can take a large
> number of templated arguments (such as print) as the args could be any
> mixture of types.

Please explain what you mean.
The arguments can be any mixture of types in getslice(), for example, and
it all works with a single template and one non-templated version.
I can see no justification for your claim.

> Specialisations provided on many templated functions.
>
> Many more functions could probably be included from the python API.
>
> Some support for python execution frames may be required when embedding
and
> directly calling functions (that's why globals() can't be called
directly).
> I will investigate this further.
>
> Other fixes and adjustments.

I'll look further once you respond to my get_arg challenge.

Thanks,
Dave





From daveh at cadlink.com  Fri Jul 12 03:34:02 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 11 Jul 2002 21:34:02 -0400
Subject: [C++-sig] Re: Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org> <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com> <aghqg0$p8o$1@main.gmane.org> <0f0a01c2283c$4555b9b0$6601a8c0@boostconsulting.com> <agkd5j$ai8$1@main.gmane.org> <13c301c22917$b9ca1350$6601a8c0@boostconsulting.com>
Message-ID: <aglbkp$idh$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:13c301c22917$b9ca1350$6601a8c0 at boostconsulting.com...
>
> ----- Original Message -----
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > I had to keep the get_args code for those functions that can take a
large
> > number of templated arguments (such as print) as the args could be any
> > mixture of types.
>
> Please explain what you mean.
> The arguments can be any mixture of types in getslice(), for example, and
> it all works with a single template and one non-templated version.
> I can see no justification for your claim.
>
There are still two versions, one that takes templated arguments and one
that takes all object arguments. The get_arg is not essential it is just
there to try and reduce the extra temporary objects if just one argument is
required to be templated and all the others are objects.

Dave Hawkes









From david.abrahams at rcn.com  Fri Jul 12 04:23:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 11 Jul 2002 22:23:43 -0400
Subject: [C++-sig] Re: Re: boost::python::api
References: <10eb01c22159$5214b550$6501a8c0@boostconsulting.com> <001501c225c8$b3dbf960$3e08a8c0@davehh> <012f01c225d4$31117f80$6601a8c0@boostconsulting.com> <000e01c225f2$bc4c5e30$3e08a8c0@davehh> <01ca01c225f6$30fc0340$6601a8c0@boostconsulting.com> <000801c2260e$6c4da260$3e08a8c0@davehh> <01e301c22615$01d39f50$6601a8c0@boostconsulting.com> <003c01c2261a$39ce45e0$3e08a8c0@davehh> <026101c2261a$eb1c97c0$6601a8c0@boostconsulting.com> <004501c22621$113530b0$3e08a8c0@davehh> <0bad01c227a9$08ba7970$6601a8c0@boostconsulting.com> <003801c227be$3bb5e0c0$3e08a8c0@davehh> <0c3c01c22804$d44cfa30$6601a8c0@boostconsulting.com> <001901c22818$1f8262c0$4110a8c0@ottawa.cadlink.com> <0d9d01c2281d$e9de2e50$6601a8c0@boostconsulting.com> <aghkg2$7p1$1@main.gmane.org> <0e5c01c22829$f66a3180$6601a8c0@boostconsulting.com> <aghqg0$p8o$1@main.gmane.org> <0f0a01c2283c$4555b9b0$6601a8c0@boostconsulting.com> <agkd5j$ai8$1@main.gmane.org> <13c301c22917$b9ca1350$6601a8c0@boostconsulting.com> <aglbkp$idh$1@main.gmane.org>
Message-ID: <148501c2294b$7b7a64e0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > > I had to keep the get_args code for those functions that can take a
> large
> > > number of templated arguments (such as print) as the args could be
any
> > > mixture of types.
> >
> > Please explain what you mean.
> > The arguments can be any mixture of types in getslice(), for example,
and
> > it all works with a single template and one non-templated version.
> > I can see no justification for your claim.
> >
> There are still two versions, one that takes templated arguments and one
> that takes all object arguments. The get_arg is not essential it is just
> there to try and reduce the extra temporary objects if just one argument
is
> required to be templated and all the others are objects.

Are you sure that it actually does that?
Are you sure that it's worth the complication?


profile-first-optimize-later-ly y'rs,
Dave





From daveh at cadlink.com  Fri Jul 12 17:34:38 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 12 Jul 2002 11:34:38 -0400
Subject: [C++-sig] to_python_converter and object
Message-ID: <agmstr$ckf$1@main.gmane.org>

I was about to do some testing that involved using to_python_converter and
noticed that there does not appear to be direct support for a convert
function that returns an object instead of a PyObject*, is this something
that is likely to be changed?

Thanks
Dave Hawkes









From achim.domma at syynx.de  Sat Jul 13 12:10:43 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 13 Jul 2002 12:10:43 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <0fa101c2285a$c68e7df0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAKEOLDIAA.achim.domma@syynx.de>

Thanks for your help, simple tests for str, dict and tuple are running now.
What kind of documentation do you expect? Are there any templates I can use?

Achim

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Wednesday, July 10, 2002 23:43
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Outstanding Jobs for v2 release
>
>
> Done.
> ----- Original Message -----
> From: "Achim Domma" <achim.domma at syynx.de>
> To: <c++-sig at python.org>
> Sent: Wednesday, July 10, 2002 4:00 PM
> Subject: RE: [C++-sig] Outstanding Jobs for v2 release
>
>
> > > I could remove dependencies on tuple from class_base, if that helps...
> >
> > Yes, I think that would help a lot !
> >
> > Achim
> >
> >
> >
> > _______________________________________________
> > 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  Sat Jul 13 13:14:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 07:14:09 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAKEOLDIAA.achim.domma@syynx.de>
Message-ID: <19b401c22a5e$834e14a0$6601a8c0@boostconsulting.com>

Hi Achim,

That's great! Please send me the source for your tests so I can integrate
them while you work on the docs. For the docs you can look at the contents
of libs/python/doc/v2/reference.html and its links for example pages. One
per header file that appears in the public interface, please.

Regards,
Dave


----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Saturday, July 13, 2002 6:10 AM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> Thanks for your help, simple tests for str, dict and tuple are running
now.
> What kind of documentation do you expect? Are there any templates I can
use?
>
> Achim
>
> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > Sent: Wednesday, July 10, 2002 23:43
> > To: c++-sig at python.org
> > Subject: Re: [C++-sig] Outstanding Jobs for v2 release
> >
> >
> > Done.
> > ----- Original Message -----
> > From: "Achim Domma" <achim.domma at syynx.de>
> > To: <c++-sig at python.org>
> > Sent: Wednesday, July 10, 2002 4:00 PM
> > Subject: RE: [C++-sig] Outstanding Jobs for v2 release
> >
> >
> > > > I could remove dependencies on tuple from class_base, if that
helps...
> > >
> > > Yes, I think that would help a lot !
> > >
> > > Achim
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From achim.domma at syynx.de  Sat Jul 13 14:44:59 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 13 Jul 2002 14:44:59 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <19b401c22a5e$834e14a0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAKEONDIAA.achim.domma@syynx.de>

one more question:

I just looked over the str interface again and at some points I'm not sure
wether to provide functions with 'fixed' parameter types or template
functions. For example see 'ljust':

BOOST_PYTHON_DECL str ljust(int width) const;
BOOST_PYTHON_DECL str ljust(object_cref width) const;

This way one could not pass long_ to ljust so I would change it to:

BOOST_PYTHON_DECL str ljust(object_cref width) const;
template <class T>
str ljust(T const& width) const
{
    return this->ljust(object(width));
}

Is that the right solution? I would apply this to all functions with indexes
(index,rindes,...)

Achim

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Saturday, July 13, 2002 13:14
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Outstanding Jobs for v2 release
>
>
> Hi Achim,
>
> That's great! Please send me the source for your tests so I can integrate
> them while you work on the docs. For the docs you can look at the contents
> of libs/python/doc/v2/reference.html and its links for example pages. One
> per header file that appears in the public interface, please.
>
> Regards,
> Dave
>
>
> ----- Original Message -----
> From: "Achim Domma" <achim.domma at syynx.de>
> To: <c++-sig at python.org>
> Sent: Saturday, July 13, 2002 6:10 AM
> Subject: RE: [C++-sig] Outstanding Jobs for v2 release
>
>
> > Thanks for your help, simple tests for str, dict and tuple are running
> now.
> > What kind of documentation do you expect? Are there any templates I can
> use?
> >
> > Achim
> >
> > > -----Original Message-----
> > > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > > Behalf Of David Abrahams
> > > Sent: Wednesday, July 10, 2002 23:43
> > > To: c++-sig at python.org
> > > Subject: Re: [C++-sig] Outstanding Jobs for v2 release
> > >
> > >
> > > Done.
> > > ----- Original Message -----
> > > From: "Achim Domma" <achim.domma at syynx.de>
> > > To: <c++-sig at python.org>
> > > Sent: Wednesday, July 10, 2002 4:00 PM
> > > Subject: RE: [C++-sig] Outstanding Jobs for v2 release
> > >
> > >
> > > > > I could remove dependencies on tuple from class_base, if that
> helps...
> > > >
> > > > Yes, I think that would help a lot !
> > > >
> > > > Achim
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> >
> >
> >
> >
> > _______________________________________________
> > 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  Sat Jul 13 14:54:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 08:54:43 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAKEONDIAA.achim.domma@syynx.de>
Message-ID: <1a5901c22a6c$776d94e0$6601a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>


> one more question:
>
> I just looked over the str interface again and at some points I'm not
sure
> wether to provide functions with 'fixed' parameter types or template
> functions. For example see 'ljust':
>
> BOOST_PYTHON_DECL str ljust(int width) const;
> BOOST_PYTHON_DECL str ljust(object_cref width) const;
>
> This way one could not pass long_ to ljust

Ah, but isn't long_ derived from object <wink>?

> so I would change it to:
>
> BOOST_PYTHON_DECL str ljust(object_cref width) const;
> template <class T>
> str ljust(T const& width) const
> {
>     return this->ljust(object(width));
> }
>
> Is that the right solution? I would apply this to all functions with
indexes
> (index,rindes,...)

It's always safe to use the second approach, but more-efficient to use the
first approach in case you know that Python supplies an underlying 'C' API
of the Python function which really takes a particular C++ type as its
parameter. If you look at list::insert() for example, you can see it's
implemented in terms of PyList_Insert, which takes an integer index as its
parameter. So it's more-efficient to call that directly with an int than to
conjure up a Python object. If you look at the implementation of
PyList_Insert, you can see that it never builds a Python object around that
int. On the other hand, there doesn't appear to be a corresponding
PyString_LJust() function which takes an int, so there's no point in
providing that overload -- the object will get created anyway. I would go
with the second approach.

Hmm, now that I think of it, the second approach is probably the /only/
right one for types which can be subclassed. Again, if you look at
PyList_Insert(), it doesn't give derived classes of list any chance to
intervene and use their own overrides of insert(). So I'll probably have to
go back and change the way list() works. Stick with the second approach
unless implementing an un-subclassable Python type.

-Dave






From achim.domma at syynx.de  Sat Jul 13 17:24:47 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 13 Jul 2002 17:24:47 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <19b401c22a5e$834e14a0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEOPDIAA.achim.domma@syynx.de>

Hi Dave,

here are my sources. I had to comment out tuple from object2.hpp and
object2.cpp. The tests work for me, but I'm not a python language lawyer. So
if you see a point where more extensive testing is required, I will try to
do it, but you have to point me in the right direction.
It's also not clear to me, what the status of slicing and operator
overloading currently is. Is it already handled by 'object'? Should I write
tests for it?

Achim

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Saturday, July 13, 2002 13:14
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Outstanding Jobs for v2 release
>
>
> Hi Achim,
>
> That's great! Please send me the source for your tests so I can integrate
> them while you work on the docs. For the docs you can look at the contents
> of libs/python/doc/v2/reference.html and its links for example pages. One
> per header file that appears in the public interface, please.
>
> Regards,
> Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: str_dict_tuple.zip
Type: application/x-zip-compressed
Size: 8676 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020713/4026058a/attachment.bin>

From david.abrahams at rcn.com  Sat Jul 13 17:21:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 11:21:17 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAMEOPDIAA.achim.domma@syynx.de>
Message-ID: <1af901c22a81$19392b40$6601a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>


> Hi Dave,
>
> here are my sources. I had to comment out tuple from object2.hpp and
> object2.cpp. The tests work for me, but I'm not a python language lawyer.
So
> if you see a point where more extensive testing is required, I will try
to
> do it, but you have to point me in the right direction.

I'll take a look, thanks!

> It's also not clear to me, what the status of slicing and operator
> overloading currently is. Is it already handled by 'object'?

Yep.

> Should I write tests for it?

No specific tests are needed. Take a look at libs/python/test/list.cpp. A
few of the tests exercise some of the operators, but only as a way of
testing the list-specific parts of the implementation.

Regards,
Dave






From david.abrahams at rcn.com  Sat Jul 13 17:27:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 11:27:10 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAMEOPDIAA.achim.domma@syynx.de>
Message-ID: <1aff01c22a81$ccea4c50$6601a8c0@boostconsulting.com>

Coupla quick issues:

1. Why is this commented out?

/*BOOST_PYTHON_DECL dict::dict(object_cref data)
    : object(dict::call(data))
{}*/

2. I think you made a mistake here:

template <>
struct arg_from_python<dict>
    : converter::pytype_wrapper_value_arg_from_python<dict, &PyDict_Type>
{
    typedef converter::pytype_wrapper_value_arg_from_python<dict,
&PyDict_Type> base;
    typedef list result_type;
            ^^^^

-Dave

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Saturday, July 13, 2002 11:24 AM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> Hi Dave,
>
> here are my sources. I had to comment out tuple from object2.hpp and
> object2.cpp. The tests work for me, but I'm not a python language lawyer.
So
> if you see a point where more extensive testing is required, I will try
to
> do it, but you have to point me in the right direction.
> It's also not clear to me, what the status of slicing and operator
> overloading currently is. Is it already handled by 'object'? Should I
write
> tests for it?
>
> Achim
>
> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > Sent: Saturday, July 13, 2002 13:14
> > To: c++-sig at python.org
> > Subject: Re: [C++-sig] Outstanding Jobs for v2 release
> >
> >
> > Hi Achim,
> >
> > That's great! Please send me the source for your tests so I can
integrate
> > them while you work on the docs. For the docs you can look at the
contents
> > of libs/python/doc/v2/reference.html and its links for example pages.
One
> > per header file that appears in the public interface, please.
> >
> > Regards,
> > Dave
>
>





From achim.domma at syynx.de  Sat Jul 13 17:52:24 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 13 Jul 2002 17:52:24 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <1aff01c22a81$ccea4c50$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEPBDIAA.achim.domma@syynx.de>

your right of course in both cases: there is no reason to comment the code
out and the result type has to be dict ... it seems that I should write some
more tests ...

Achim

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Saturday, July 13, 2002 17:27
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Outstanding Jobs for v2 release
>
>
> Coupla quick issues:
>
> 1. Why is this commented out?
>
> /*BOOST_PYTHON_DECL dict::dict(object_cref data)
>     : object(dict::call(data))
> {}*/
>
> 2. I think you made a mistake here:
>
> template <>
> struct arg_from_python<dict>
>     : converter::pytype_wrapper_value_arg_from_python<dict, &PyDict_Type>
> {
>     typedef converter::pytype_wrapper_value_arg_from_python<dict,
> &PyDict_Type> base;
>     typedef list result_type;
>             ^^^^
>
> -Dave
>
> ----- Original Message -----
> From: "Achim Domma" <achim.domma at syynx.de>
> To: <c++-sig at python.org>
> Sent: Saturday, July 13, 2002 11:24 AM
> Subject: RE: [C++-sig] Outstanding Jobs for v2 release
>
>
> > Hi Dave,
> >
> > here are my sources. I had to comment out tuple from object2.hpp and
> > object2.cpp. The tests work for me, but I'm not a python
> language lawyer.
> So
> > if you see a point where more extensive testing is required, I will try
> to
> > do it, but you have to point me in the right direction.
> > It's also not clear to me, what the status of slicing and operator
> > overloading currently is. Is it already handled by 'object'? Should I
> write
> > tests for it?
> >
> > Achim
> >
> > > -----Original Message-----
> > > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > > Behalf Of David Abrahams
> > > Sent: Saturday, July 13, 2002 13:14
> > > To: c++-sig at python.org
> > > Subject: Re: [C++-sig] Outstanding Jobs for v2 release
> > >
> > >
> > > Hi Achim,
> > >
> > > That's great! Please send me the source for your tests so I can
> integrate
> > > them while you work on the docs. For the docs you can look at the
> contents
> > > of libs/python/doc/v2/reference.html and its links for example pages.
> One
> > > per header file that appears in the public interface, please.
> > >
> > > Regards,
> > > Dave
> >
> >
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>






From achim.domma at syynx.de  Sat Jul 13 17:53:45 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 13 Jul 2002 17:53:45 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <1af901c22a81$19392b40$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAGEPBDIAA.achim.domma@syynx.de>

> > It's also not clear to me, what the status of slicing and operator
> > overloading currently is. Is it already handled by 'object'?
>
> Yep.

Is slicing also working already? I remember a discussion in the list how the
syntax should be. Is there an example?

> > Should I write tests for it?
>
> No specific tests are needed. Take a look at libs/python/test/list.cpp. A
> few of the tests exercise some of the operators, but only as a way of
> testing the list-specific parts of the implementation.

I will write some more tests. Is there a reason not to use unittest? Do you
prefer doctest?

Achim






From david.abrahams at rcn.com  Sat Jul 13 18:01:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 12:01:26 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAGEPBDIAA.achim.domma@syynx.de>
Message-ID: <1b3401c22a86$8e4bed00$6601a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>


> > > It's also not clear to me, what the status of slicing and operator
> > > overloading currently is. Is it already handled by 'object'?
> >
> > Yep.
>
> Is slicing also working already? I remember a discussion in the list how
the
> syntax should be. Is there an example?

libs/python/test/object.cpp says:

bool check_string_slice()
{
    object s("hello, world");

    if (s.slice(_,-3) != "hello, wo")
        return false;

    if (s.slice(-3,_) != "rld")
        return false;

    if (", " != s.slice(5,7))
        return false;

    return s.slice(2,-1).slice(1,-1)  == "lo, wor";
}

> I will write some more tests. Is there a reason not to use unittest? Do
you
> prefer doctest?

I know doctest, and I don't know unittest. doctest works well for this job.
Is there a good reason to use unittest? If you want to use unittest, be my
guest, but you might have to explain what you've done to me.

-Dave





From david.abrahams at rcn.com  Sat Jul 13 18:08:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 12:08:56 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIAGEPBDIAA.achim.domma@syynx.de>
Message-ID: <1b4d01c22a87$a99b1620$6601a8c0@boostconsulting.com>

From: "Achim Domma" <achim.domma at syynx.de>

> I will write some more tests. Is there a reason not to use unittest? Do
you
> prefer doctest?

The way you've currently written the tests, there's a lot of printing to
std::cout
and via Python print statements without any result checking. If there's a
problem with the result, I'll never know it. That's a good reason to use
doctest instead.

[I told you writing good tests would be the hard part -- except for
documentation, of course, which is the really hard part ;-)]

Another issue: functions such as str::startswith() should return bool
despite the fact that the Python versions return int.

-Dave







From achim.domma at syynx.de  Sat Jul 13 20:47:06 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 13 Jul 2002 20:47:06 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <1b4d01c22a87$a99b1620$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIACEPEDIAA.achim.domma@syynx.de>

> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> The way you've currently written the tests, there's a lot of printing to
> std::cout
> and via Python print statements without any result checking. If there's a
> problem with the result, I'll never know it. That's a good reason to use
> doctest instead.

Could you have a look at the attached unittest example for dict? If it's ok
for you, I would do the same for str. I'm not used to use python in
interactive mode and you have to set pathes or move files around to get the
test running. So doctest feels not very comfortable to me - but I might be
missing something.

BTW: It seems that the python test scripts are executed twice. Why? Has it
something to do with doctest?

> [I told you writing good tests would be the hard part -- except for
> documentation, of course, which is the really hard part ;-)]

Yes, but I'm here to learn. I know that writing tests is not easy, but I'm
just experiencing how long it could take. ;-)

> Another issue: functions such as str::startswith() should return bool
> despite the fact that the Python versions return int.

I will fix it.

Achim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dict_test.zip
Type: application/x-zip-compressed
Size: 1266 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020713/5f42874c/attachment.bin>

From david.abrahams at rcn.com  Sat Jul 13 20:57:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 14:57:02 -0400
Subject: [C++-sig] Outstanding Jobs for v2 release
References: <FCEMIEFBFOIDAOJDEPIACEPEDIAA.achim.domma@syynx.de>
Message-ID: <1c0901c22a9f$3e60c090$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Saturday, July 13, 2002 2:47 PM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > The way you've currently written the tests, there's a lot of printing
to
> > std::cout
> > and via Python print statements without any result checking. If there's
a
> > problem with the result, I'll never know it. That's a good reason to
use
> > doctest instead.
>
> Could you have a look at the attached unittest example for dict? If it's
ok
> for you,

I can't really tell. It doesn't seem to test very much, but I could be
wrong -- as I said I'm not familiar with unittest. It certainly seems to
come with a lot more syntactic baggage than doctests do, which makes it
harder to see what the test is doing.

BTW, the point of the exercise() function in the list test is mostly to
check that the templated list member functions interact properly with types
other than python::object.

> I would do the same for str. I'm not used to use python in
> interactive mode and you have to set pathes or move files around to get
the
> test running. So doctest feels not very comfortable to me - but I might
be
> missing something.

No, all you have to do is plug it into the libs/python/test/Jamfile in the
same way as the other tests. "bjam test" runs all tests and "bjam
<test-name>.run" runs your specific test.

> BTW: It seems that the python test scripts are executed twice. Why? Has
it
> something to do with doctest?

No, just that the Jam testing rules for Python are a little unsophisticated
and it hasn't been worth my time to fix them. It's actually building the
".run" and ".test" targets. The ".test" target is supposed to build only
when out-of-date, but the ".run" target builds (i.e. runs the test)
whenever you request it.

> > [I told you writing good tests would be the hard part -- except for
> > documentation, of course, which is the really hard part ;-)]
>
> Yes, but I'm here to learn. I know that writing tests is not easy, but
I'm
> just experiencing how long it could take. ;-)

Please try doctests; it's really quite easy if you use the build system.





From daveh at cadlink.com  Sun Jul 14 01:04:04 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 13 Jul 2002 19:04:04 -0400
Subject: [C++-sig] Compile failure with object in V2
Message-ID: <agqbjh$b3d$1@main.gmane.org>

I was working on some tests for the the boost components I've been working
on and came across this issue.

If an object is initialised with a class that is a sub class of another a
compiler error results, though I'm not sure if this is a specific problem
with VC6:

ie

#include ...

class c1 {
public:
    c1() {}
    class c2 {
    public:
        c2() {}
    };
    c2 t;
};

...

int main(int argc, char* argv[])
{
    c1 x;
    object o(x.t);
    return 0;
}

will result in:

boost\python\object_core.hpp(220) : error C2275: 'c1::c2' : illegal use of
this type as an expression
        test.cpp : see reference to function template instantiation
'__thiscall boost::python::api::object::boost::python::api::object(const
class c1::c2 &)' being compiled

Line 220 is the object constructor, but I'm not sure what part of it the
compiler is objecting to.

Dave Hawkes









From david.abrahams at rcn.com  Sun Jul 14 02:07:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Jul 2002 20:07:02 -0400
Subject: [C++-sig] Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org>
Message-ID: <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>


> I was working on some tests for the the boost components I've been
working
> on and came across this issue.
>
> If an object is initialised with a class that is a sub class of another a
> compiler error results, though I'm not sure if this is a specific problem
> with VC6:

Why don't you find out? MinGW and Cygwin are free...

-Dave






From daveh at cadlink.com  Sun Jul 14 05:18:59 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 13 Jul 2002 23:18:59 -0400
Subject: [C++-sig] Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com>
Message-ID: <agqql7$ump$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1c5501c22aca$7aa85dd0$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> > I was working on some tests for the the boost components I've been
> working
> > on and came across this issue.
> >
> > If an object is initialised with a class that is a sub class of another
a
> > compiler error results, though I'm not sure if this is a specific
problem
> > with VC6:
>
> Why don't you find out? MinGW and Cygwin are free...
>
As I suspected it looks like a VC6 problem as it compiles fine with gcc.
Looking at the MS docs for error C2275 I can't see how it would apply in
this situation either.
Have you come across this issue before? If not or there's no known
workaround, I'm not sure if it's worth attempting any code rearrangements to
work around this as not many people will probably come across it.

Dave Hawkes









From david.abrahams at rcn.com  Sun Jul 14 13:28:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 07:28:51 -0400
Subject: [C++-sig] Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org>
Message-ID: <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1c5501c22aca$7aa85dd0$6601a8c0 at boostconsulting.com...
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> >
> > > I was working on some tests for the the boost components I've been
> > working
> > > on and came across this issue.
> > >
> > > If an object is initialised with a class that is a sub class of
another
> a
> > > compiler error results, though I'm not sure if this is a specific
> problem
> > > with VC6:
> >
> > Why don't you find out? MinGW and Cygwin are free...
> >
> As I suspected it looks like a VC6 problem as it compiles fine with gcc.
> Looking at the MS docs for error C2275 I can't see how it would apply in
> this situation either.
> Have you come across this issue before?

Not this particular one, but I've worked around many similar mysterious
problems in the past.

> If not or there's no known
> workaround, I'm not sure if it's worth attempting any code rearrangements
to
> work around this as not many people will probably come across it.

If you want to try something, try doing a search/replace which turns all
instances of "c##" in boost/python/detail/returning.hpp into "zyx##".

I've seen VC6 get confused about which entities a name should refer to when
there's more than one possibility before.

-Dave






From daveh at cadlink.com  Sun Jul 14 17:16:52 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 14 Jul 2002 11:16:52 -0400
Subject: [C++-sig] Re: Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com>
Message-ID: <ags4je$gvr$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1cd801c22b2a$0b843630$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> >

> If you want to try something, try doing a search/replace which turns all
> instances of "c##" in boost/python/detail/returning.hpp into "zyx##".
>
> I've seen VC6 get confused about which entities a name should refer to
when
> there's more than one possibility before.
>

This made no difference :(

However by testing components of the constructor individually it would
appear that the compiler is objecting to passing the reference "x" to the
object_initializer::get function. This can be worked around by passing a
pointer instead, which I don't think has any ultimate effect on effficiency.
You can see the small change I made to the code fragment below.

Dave Hawkes


  class object : public object_base
  {
   public:
      // default constructor creates a None object
      object();
      // explicit conversion from any C++ object to Python
      template <class T>
      explicit object(T const& x)
          : object_base(object_initializer<is_proxy<T>::value>::get(
                      &x, detail::convertible<object const*>::check(&x)))
      {
      }

      // Throw error_already_set() if the handle is null.
      explicit object(handle<> const&);

   public: // implementation detail -- for internal use only
      explicit object(detail::borrowed_reference);
      explicit object(detail::new_reference);
  };

  //
  // object_initializer -- get the handle to construct the object with,
  // based on whether T is a proxy or derived from object
  //
  template <bool is_proxy = false>
  struct object_initializer
  {
      static PyObject*
      get(object const* x, detail::yes_convertible)
      {
          return python::incref(x->ptr());
      }

      template <class T>
      static PyObject*
      get(T const* x, detail::no_convertible)
      {
          return python::incref(converter::arg_to_python<T>(*x).get());
      }
  };

  template <>
  struct object_initializer<true>
  {
      template <class Policies>
      static PyObject*
      get(proxy<Policies> const* x, detail::no_convertible)
      {
          return python::incref(x->operator object().ptr());
      }
  };
}









From david.abrahams at rcn.com  Sun Jul 14 18:26:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 12:26:34 -0400
Subject: [C++-sig] Re: Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org>
Message-ID: <1db401c22b53$42a03230$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>

>
> This made no difference :(
>
> However by testing components of the constructor individually it would
> appear that the compiler is objecting to passing the reference "x" to the
> object_initializer::get function. This can be worked around by passing a
> pointer instead, which I don't think has any ultimate effect on
effficiency.
> You can see the small change I made to the code fragment below.

It seems like a fine patch; I'm checking it in!
BTW, I notice you slipped in the default None constructor; I'm adding that
also.

-Dave






From daveh at cadlink.com  Sun Jul 14 18:30:43 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 14 Jul 2002 12:30:43 -0400
Subject: [C++-sig] Re: Re: Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org> <1db401c22b53$42a03230$6601a8c0@boostconsulting.com>
Message-ID: <ags8tt$nr3$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1db401c22b53$42a03230$6601a8c0 at boostconsulting.com...
>
>
> It seems like a fine patch; I'm checking it in!
> BTW, I notice you slipped in the default None constructor; I'm adding that
> also.
>
I forgot that was there...
I assume you guessed the missing part:

inline object::object()
    : object_base(incref(Py_None))
{}

Dave Hawkes









From david.abrahams at rcn.com  Sun Jul 14 18:35:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 12:35:36 -0400
Subject: [C++-sig] Re: Re: Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org> <1db401c22b53$42a03230$6601a8c0@boostconsulting.com> <ags8tt$nr3$1@main.gmane.org>
Message-ID: <1dce01c22b54$7d4423a0$6601a8c0@boostconsulting.com>

Check the CVS and see for yourself ;-)

BTW, shall I give you CVS access? I think it would be much better if you
were making incremental progress on the CVS state than if you save
everything and dump a big patch on me later...

-Dave


----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Sunday, July 14, 2002 12:30 PM
Subject: [C++-sig] Re: Re: Re: Compile failure with object in V2


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1db401c22b53$42a03230$6601a8c0 at boostconsulting.com...
> >
> >
> > It seems like a fine patch; I'm checking it in!
> > BTW, I notice you slipped in the default None constructor; I'm adding
that
> > also.
> >
> I forgot that was there...
> I assume you guessed the missing part:
>
> inline object::object()
>     : object_base(incref(Py_None))
> {}
>
> Dave Hawkes
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From daveh at cadlink.com  Sun Jul 14 18:53:01 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 14 Jul 2002 12:53:01 -0400
Subject: [C++-sig] Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org> <1db401c22b53$42a03230$6601a8c0@boostconsulting.com> <ags8tt$nr3$1@main.gmane.org> <1dce01c22b54$7d4423a0$6601a8c0@boostconsulting.com>
Message-ID: <agsa7p$pt7$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1dce01c22b54$7d4423a0$6601a8c0 at boostconsulting.com...
> Check the CVS and see for yourself ;-)
>
> BTW, shall I give you CVS access? I think it would be much better if you
> were making incremental progress on the CVS state than if you save
> everything and dump a big patch on me later...
>
I do have a number of pending items which I am frequently synchronizing to
CVS which appear quite stable now. If you give me access I can check these
in over the next week after some final testing. I can also check in the
initial work on the embedding testing/sample work shortly as they may be
useful for others working on embedding. Currently it tests the
sub-module/sub-class code and eventually the API code.

Dave Hawkes









From david.abrahams at rcn.com  Sun Jul 14 19:31:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 13:31:01 -0400
Subject: [C++-sig] Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org> <1db401c22b53$42a03230$6601a8c0@boostconsulting.com> <ags8tt$nr3$1@main.gmane.org> <1dce01c22b54$7d4423a0$6601a8c0@boostconsulting.com> <agsa7p$pt7$1@main.gmane.org>
Message-ID: <1dec01c22b5c$3a077cb0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>

> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1dce01c22b54$7d4423a0$6601a8c0 at boostconsulting.com...
> > Check the CVS and see for yourself ;-)
> >
> > BTW, shall I give you CVS access? I think it would be much better if
you
> > were making incremental progress on the CVS state than if you save
> > everything and dump a big patch on me later...
> >
> I do have a number of pending items which I am frequently synchronizing
to
> CVS which appear quite stable now.

What are they?

> If you give me access I can check these
> in over the next week after some final testing.

OK, I'll need your SourceForge username.

> I can also check in the
> initial work on the embedding testing/sample work shortly as they may be
> useful for others working on embedding. Currently it tests the
> sub-module/sub-class code and eventually the API code.

Great!

It's important to have docs for whatever you check in. What's your status
with respect to documentation of these components?

-Dave






From daveh at cadlink.com  Sun Jul 14 22:28:06 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 14 Jul 2002 16:28:06 -0400
Subject: [C++-sig] Re: Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org> <1db401c22b53$42a03230$6601a8c0@boostconsulting.com> <ags8tt$nr3$1@main.gmane.org> <1dce01c22b54$7d4423a0$6601a8c0@boostconsulting.com> <agsa7p$pt7$1@main.gmane.org> <1dec01c22b5c$3a077cb0$6601a8c0@boostconsulting.com>
Message-ID: <agsmrc$est$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1dec01c22b5c$3a077cb0$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> OK, I'll need your SourceForge username.
>
hevad57

>
> It's important to have docs for whatever you check in. What's your status
> with respect to documentation of these components?
>
For some of the work like the pre-created main module I will need to modify
your existing docs. The API interface will require new docs. I have not got
much further than reviewing the current V2 docs in CVS and thinking about an
approach. I have got some test code from which I can cull sample code.

I assume the templates you have in place for much of the V2 docs. in CVS are
in the style that will accompany the release?

Dave Hawkes









From david.abrahams at rcn.com  Sun Jul 14 23:04:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 17:04:30 -0400
Subject: [C++-sig] Re: Re: Compile failure with object in V2
References: <agqbjh$b3d$1@main.gmane.org> <1c5501c22aca$7aa85dd0$6601a8c0@boostconsulting.com> <agqql7$ump$1@main.gmane.org> <1cd801c22b2a$0b843630$6601a8c0@boostconsulting.com> <ags4je$gvr$1@main.gmane.org> <1db401c22b53$42a03230$6601a8c0@boostconsulting.com> <ags8tt$nr3$1@main.gmane.org> <1dce01c22b54$7d4423a0$6601a8c0@boostconsulting.com> <agsa7p$pt7$1@main.gmane.org> <1dec01c22b5c$3a077cb0$6601a8c0@boostconsulting.com> <agsmrc$est$1@main.gmane.org>
Message-ID: <1f0701c22b7a$629dabe0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1dec01c22b5c$3a077cb0$6601a8c0 at boostconsulting.com...
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> >
> > OK, I'll need your SourceForge username.
> >
> hevad57

OK, you're all set.

Remember that you won't be able to check things in from any CVS tree you've
got checked out as anonymous.

> > It's important to have docs for whatever you check in. What's your
status
> > with respect to documentation of these components?
> >
> For some of the work like the pre-created main module I will need to
modify
> your existing docs. The API interface will require new docs. I have not
got
> much further than reviewing the current V2 docs in CVS and thinking about
an
> approach. I have got some test code from which I can cull sample code.
>
> I assume the templates you have in place for much of the V2 docs. in CVS
are
> in the style that will accompany the release?

Yep. There's also going to be a more narrative tutorial section, but the
reference docs are the hard ones.

-Dave






From david.abrahams at rcn.com  Mon Jul 15 03:47:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 21:47:03 -0400
Subject: [C++-sig] Building on Windows from CVS
Message-ID: <1fdc01c22ba1$8642a9c0$6601a8c0@boostconsulting.com>

If you're using the current CVS state on Windows, please check out version
1.64 of tools/build/boost-base.jam until further notice.

    cvs update -r1.64 tools/build/boost-base.jam

Something is broken in 1.65 which prevents Boost.Python builds from
working. I'll let you know when it's cleared up.

Sorry for the inconvenience,
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  Mon Jul 15 04:58:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 14 Jul 2002 22:58:28 -0400
Subject: [C++-sig] Building on Windows from CVS
References: <1fdc01c22ba1$8642a9c0$6601a8c0@boostconsulting.com>
Message-ID: <200601c22bab$8016b910$6601a8c0@boostconsulting.com>

OK, this appears to be fixed now.
Thanks for waiting an hour ;-)
Thanks for fixing it, Rene!

-Dave


From: "David Abrahams" <david.abrahams at rcn.com>


> If you're using the current CVS state on Windows, please check out
version
> 1.64 of tools/build/boost-base.jam until further notice.
>
>     cvs update -r1.64 tools/build/boost-base.jam
>
> Something is broken in 1.65 which prevents Boost.Python builds from
> working. I'll let you know when it's cleared up.
>
> Sorry for the inconvenience,
> Dave






From daveh at cadlink.com  Mon Jul 15 05:00:14 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 14 Jul 2002 23:00:14 -0400
Subject: [C++-sig] Re: Building on Windows from CVS
References: <1fdc01c22ba1$8642a9c0$6601a8c0@boostconsulting.com>
Message-ID: <agtds3$h85$1@main.gmane.org>

Dave,

I'm currently getting another build problem on my test files in
to_python_converter.hpp:

at line 33 ie:

    if(converter::registry::get_to_python_function(type_id<T>()) !=0)
        return;

I've searched the includes and can't find where get_to_python_function is
defined (the compiler complains its undefined).

Dave Hawkes


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1fdc01c22ba1$8642a9c0$6601a8c0 at boostconsulting.com...
> If you're using the current CVS state on Windows, please check out version
> 1.64 of tools/build/boost-base.jam until further notice.
>
>     cvs update -r1.64 tools/build/boost-base.jam
>
> Something is broken in 1.65 which prevents Boost.Python builds from
> working. I'll let you know when it's cleared up.
>
> Sorry for the inconvenience,
> 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  Mon Jul 15 06:15:13 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 00:15:13 -0400
Subject: [C++-sig] Re: Building on Windows from CVS
References: <1fdc01c22ba1$8642a9c0$6601a8c0@boostconsulting.com> <agtds3$h85$1@main.gmane.org>
Message-ID: <202d01c22bb6$3b0aa1f0$6601a8c0@boostconsulting.com>

You must be out-of-date, and a little confused. I can't find
get_to_python_function mentioned anywhere in my CVS tree now, and it was
never mentioned in boost/python/to_python_converter.hpp. Try a clean
checkout?

-Dave

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>


> Dave,
>
> I'm currently getting another build problem on my test files in
> to_python_converter.hpp:
>
> at line 33 ie:
>
>     if(converter::registry::get_to_python_function(type_id<T>()) !=0)
>         return;
>
> I've searched the includes and can't find where get_to_python_function is
> defined (the compiler complains its undefined).
>
> Dave Hawkes
>
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1fdc01c22ba1$8642a9c0$6601a8c0 at boostconsulting.com...
> > If you're using the current CVS state on Windows, please check out
version
> > 1.64 of tools/build/boost-base.jam until further notice.
> >
> >     cvs update -r1.64 tools/build/boost-base.jam
> >
> > Something is broken in 1.65 which prevents Boost.Python builds from
> > working. I'll let you know when it's cleared up.
> >
> > Sorry for the inconvenience,
> > 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
> > +---------------------------------------------------------------+
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig






From david.abrahams at rcn.com  Mon Jul 15 09:52:59 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 03:52:59 -0400
Subject: [C++-sig] extractors
Message-ID: <20d001c22bd4$a563afb0$6601a8c0@boostconsulting.com>

Having just got finished with some massive code massage to the Python<->C++
converter interface, I am finally ready to embark on implementing the
extractor interface which can be used to extract C++ types from Python
objects.

We have discussed two main use cases for extractions

1. In user code which needs to retrieve C++ objects from their
corresponding Python objects:

  a.
    void f(object x)
    {
        int y = extract<int>(x); // retrieve an int from x
    }

  b. Users may also want to explicitly check for convertibility:

    int g(object x)
    {
        extractor<int> get_int(x);
        if (get_int)
            return get_int();
        else
            return 0;
    }

2. In the implementation of sequence from_python converters (e.g. Python
tuple/list -> std::vector), as in Ralf's example at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bp
l_utils.h?rev=1.2.2.14&content-type=text/vnd.viewcvs-markup. These are
still a messy phenomenon, and I'm not sure that it makes sense to lump them
into the same facility. First we need to review the requirements. As I
understand it:

    a. We decided it would be acceptable to support only overload
resolution on "sequence-ness" and not on the types of sequence elements. In
other words, if I wrap two functions:

    void f(std::vector<int>);
    void f(std::list<char*>);

 and I register the Python iterable -> C++ sequence converters for both
argument types, I can write:

    >>> f([1, 2, 3])

 but it's an equally good match for both functions. Of course, if I wrap
std::vector<int> as a Python class int_vec, then:

    >>> f(int_vec(1, 2, 3))

matches the first overload exactly.

    b. That means we can detect iterables via the presence of an __iter__
or a __getitem__ attribute... and we don't have to follow the practice used
in Ralf's example of traversing the sequence twice in order to detect the
overload. As far as I can tell after raising the issue on Python-dev
(http://mail.python.org/pipermail/python-dev/2002-July/026200.html), this
is the more-natural fit to Guido's idea of Python iterables as a
single-pass concept.

    c. It also looks to me like any other approach would destroy the
information in a single-pass iterable (e.g. a file) while deciding to
reject an overload -- we'd have to touch all the elements but the next
argument might not match. That seems unacceptable to me.

    d. Ultimately, that means that if the overload succeds, but the
iterable contains the wrong kind of elements, the selected function itself
will appear (from the Python side) to throw an exception immediately. That
seems acceptable to me.

To fulfill the requirements above, we only need to supply the form used in
1a.

However, return value converters present a minor problem. Recall that when
returning a pointer or reference type from a Python function, e.g.:

    call<Foo*>(py_func, arg1, arg2...)

The Foo object must be contained within the Python result object. Since the
Python result object will have its reference count decremented after
py_func returns, we must throw an exception instead of returning if the
result object has a reference count <= 1, to keep from returning a dangling
pointer.

Now consider:

    call<std::vector<Foo*> >(py_func, arg1, arg2...)
         ^^^^^^^^^^^^^^^^^

If py_func returns an list of wrapped Foo objects, we have a similar
problem. However, now it goes one level deeper: if the list has only one
reference and any element has only one reference, we should throw an
exception. Worse, you can't really tell whether the pointer will dangle; if
the returned iterable is really a list iterator, the list itself may well
have enough references to keep it alive through the return process.

Because return_from_python (c.f. above) and the arg_from_python (for
unwrapping C++ wrapped function arguments) converters use the same
registered conversion mechanism, they are subject to the same constraints
at the inner level. We have two choices:

1. Provide no protection against dangling pointer sequence elements
2. Prohibit this mechanism from converting sequences of raw pointers (and
references, if such a thing is possible)

Taking Dave Hawkes' excellent advice to not give away the store, I'm
inclined to do #2 first and see how it plays out. Note that means our
iterable converter would have to use a different mechanism than the
user-level extract<> call after all, since I don't want to prohibit people
from writing

    Foo* p = extract<Foo*>(o);

Thoughts?
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  Mon Jul 15 10:00:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 04:00:14 -0400
Subject: [C++-sig] to_python_converter and object
References: <agmstr$ckf$1@main.gmane.org>
Message-ID: <20e401c22bd5$a76d9400$6601a8c0@boostconsulting.com>

Sorry I never answered this one. The low-level conversion mechanisms are
likely to continue to traffic in raw PyObject*s, at least for a while. I'm
trying to avoid imposing unneccessary overheads (mostly in code size), but
since I've never measured it I'd be willing to entertain a change...

-Dave


----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Friday, July 12, 2002 11:34 AM
Subject: [C++-sig] to_python_converter and object


> I was about to do some testing that involved using to_python_converter
and
> noticed that there does not appear to be direct support for a convert
> function that returns an object instead of a PyObject*, is this something
> that is likely to be changed?
>
> Thanks
> Dave Hawkes
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From hoel at germanlloyd.org  Mon Jul 15 12:00:58 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 15 Jul 2002 12:00:58 +0200
Subject: [C++-sig] boost build problem
Message-ID: <seele5paxx.fsf@pc970145.GermanLloyd.de>

Hello,

I have Problems building boost on Solaris 2.7. With my non standard
gcc and my non standard python installation I get lots of

/usr/local/fitools/include/g++-v3/iosfwd:83: template with C linkage

lines. These problems disappear when I edit "gcc-tools.jam" and
replace the occurences of

-isystem$(SPACE)

by

-I

Why does boost use -isystem instad of -I for the include paths?

Is there a better place for me to change the jam macros?

Thanks for your help

Greetings

Bertold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From hoel at germanlloyd.org  Mon Jul 15 14:54:42 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 15 Jul 2002 14:54:42 +0200
Subject: [C++-sig] Checking out current CVS version
Message-ID: <se1ya5p2wd.fsf@pc970145.GermanLloyd.de>

Hello,

Our firewall prevents me from checking out the CVS repository
directly. I managed to get a CVS version ob boost using a too named
cvsgrab which uses the ViewCVS webpages to checkout a CVS
repository. But cvsgrab is unable to get the "mpl mpl-development"
part of the repository, so I'm left with a boost python part that can
be build, but not be used. So my question is, is there a snapshot of
boost python v2 with the neccessary boost library I can download
anywhere?

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From david.abrahams at rcn.com  Mon Jul 15 15:03:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 09:03:42 -0400
Subject: [C++-sig] boost build problem
References: <seele5paxx.fsf@pc970145.GermanLloyd.de>
Message-ID: <216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com>

From: "Berthold H?llmann" <hoel at germanlloyd.org>

<<
I have Problems building boost on Solaris 2.7. With my non standard
gcc and my non standard python installation I get lots of

/usr/local/fitools/include/g++-v3/iosfwd:83: template with C linkage

lines. These problems disappear when I edit "gcc-tools.jam" and
replace the occurences of

-isystem$(SPACE)

by

-I

Why does boost use -isystem instad of -I for the include paths?
>>

[dwa] Because that's the prescribed way way to find #include <...> files.

<<Is there a better place for me to change the jam macros?>>

If you're using a non-standard gcc, you could copy the toolset file into
your own gcc-tools.jam and stick it in a directory you place in
BOOST_BUILD_PATH... or you can keep doing what you're doing now.

-Dave






From david.abrahams at rcn.com  Mon Jul 15 15:08:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 09:08:46 -0400
Subject: [C++-sig] Checking out current CVS version
References: <se1ya5p2wd.fsf@pc970145.GermanLloyd.de>
Message-ID: <217401c22c01$852e2ae0$6601a8c0@boostconsulting.com>

See http://groups.yahoo.com/group/boost/files/mpl-development.zip

HTH,
Dave

----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>
To: <c++-sig at python.org>
Sent: Monday, July 15, 2002 8:54 AM
Subject: [C++-sig] Checking out current CVS version


Hello,

Our firewall prevents me from checking out the CVS repository
directly. I managed to get a CVS version ob boost using a too named
cvsgrab which uses the ViewCVS webpages to checkout a CVS
repository. But cvsgrab is unable to get the "mpl mpl-development"
part of the repository, so I'm left with a boost python part that can
be build, but not be used. So my question is, is there a snapshot of
boost python v2 with the neccessary boost library I can download
anywhere?

Thanks

Berthold






From daveh at cadlink.com  Mon Jul 15 15:26:54 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 15 Jul 2002 09:26:54 -0400
Subject: [C++-sig] Re: Re: Building on Windows from CVS
References: <1fdc01c22ba1$8642a9c0$6601a8c0@boostconsulting.com> <agtds3$h85$1@main.gmane.org> <202d01c22bb6$3b0aa1f0$6601a8c0@boostconsulting.com>
Message-ID: <aguikt$j5d$1@main.gmane.org>

Yes, Found it, the danger of too many merges...

Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:202d01c22bb6$3b0aa1f0$6601a8c0 at boostconsulting.com...
> You must be out-of-date, and a little confused. I can't find
> get_to_python_function mentioned anywhere in my CVS tree now, and it was
> never mentioned in boost/python/to_python_converter.hpp. Try a clean
> checkout?
>
> -Dave
>
> ----- Original Message -----
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> > Dave,
> >
> > I'm currently getting another build problem on my test files in
> > to_python_converter.hpp:
> >
> > at line 33 ie:
> >
> >     if(converter::registry::get_to_python_function(type_id<T>()) !=0)
> >         return;
> >
> > I've searched the includes and can't find where get_to_python_function
is
> > defined (the compiler complains its undefined).
> >
> > Dave Hawkes
> >
> >
> > "David Abrahams" <david.abrahams at rcn.com> wrote in message
> > news:1fdc01c22ba1$8642a9c0$6601a8c0 at boostconsulting.com...
> > > If you're using the current CVS state on Windows, please check out
> version
> > > 1.64 of tools/build/boost-base.jam until further notice.
> > >
> > >     cvs update -r1.64 tools/build/boost-base.jam
> > >
> > > Something is broken in 1.65 which prevents Boost.Python builds from
> > > working. I'll let you know when it's cleared up.
> > >
> > > Sorry for the inconvenience,
> > > 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
> > > +---------------------------------------------------------------+
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig








From hoel at germanlloyd.org  Mon Jul 15 16:12:38 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 15 Jul 2002 16:12:38 +0200
Subject: [C++-sig] Re: boost build problem
In-Reply-To: <216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com>
References: <seele5paxx.fsf@pc970145.GermanLloyd.de><216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com>
Message-ID: <sewurxnkq1.fsf@pc970145.GermanLloyd.de>

"David Abrahams" <david.abrahams at rcn.com> writes:

> From: "Berthold Hllmann" <hoel at germanlloyd.org>
> 
> <<
> I have Problems building boost on Solaris 2.7. With my non standard
> gcc and my non standard python installation I get lots of
> 
> /usr/local/fitools/include/g++-v3/iosfwd:83: template with C linkage
> 
> lines. These problems disappear when I edit "gcc-tools.jam" and
> replace the occurences of
> 
> -isystem$(SPACE)
> 
> by
> 
> -I
> 
> Why does boost use -isystem instad of -I for the include paths?
> >>
> 
> [dwa] Because that's the prescribed way way to find #include <...>
files.
> 
> <<Is there a better place for me to change the jam macros?>>
> 
> If you're using a non-standard gcc, you could copy the toolset file
into
> your own gcc-tools.jam and stick it in a directory you place in
> BOOST_BUILD_PATH... or you can keep doing what you're doing now.

Ok, maybe this is a gcc bug. My gcc is nonstandard only because I uses
different pathes for --prefix and --exec-prefix on installation. So I
will continue with the changed gcc-tools.jam.

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From david.abrahams at rcn.com  Mon Jul 15 16:26:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 10:26:41 -0400
Subject: [C++-sig] Re: boost build problem
References: <seele5paxx.fsf@pc970145.GermanLloyd.de><216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com> <sewurxnkq1.fsf@pc970145.GermanLloyd.de>
Message-ID: <21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com>

From: "Berthold H?llmann" <hoel at germanlloyd.org>

> > If you're using a non-standard gcc, you could copy the toolset file
> into
> > your own gcc-tools.jam and stick it in a directory you place in
> > BOOST_BUILD_PATH... or you can keep doing what you're doing now.
>
> Ok, maybe this is a gcc bug. My gcc is nonstandard only because I uses
> different pathes for --prefix and --exec-prefix on installation. So I
> will continue with the changed gcc-tools.jam.

Oh, that's not nonstandard!

Which version of GCC is this? I have heard of this problem before. Maybe we
should patch the gcc toolset for your platform.

-Dave





From hoel at germanlloyd.org  Mon Jul 15 17:38:12 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 15 Jul 2002 17:38:12 +0200
Subject: [C++-sig] Re: boost build problem
In-Reply-To: <21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com>
References: <seele5paxx.fsf@pc970145.GermanLloyd.de><216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com><sewurxnkq1.fsf@pc970145.GermanLloyd.de><21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com>
Message-ID: <ser8i5ngrf.fsf@pc970145.GermanLloyd.de>

"David Abrahams" <david.abrahams at rcn.com> writes:

> From: "Berthold Hllmann" <hoel at germanlloyd.org>
> 
> > > If you're using a non-standard gcc, you could copy the toolset
file
> > into
> > > your own gcc-tools.jam and stick it in a directory you place in
> > > BOOST_BUILD_PATH... or you can keep doing what you're doing now.
> >
> > Ok, maybe this is a gcc bug. My gcc is nonstandard only because I
uses
> > different pathes for --prefix and --exec-prefix on installation. So
I
> > will continue with the changed gcc-tools.jam.
> 
> Oh, that's not nonstandard!
> 
> Which version of GCC is this? I have heard of this problem before.
Maybe we
> should patch the gcc toolset for your platform.

its

>gcc --version;gcc -dumpmachine;uname -sr
gcc (GCC) 3.1
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

sparc-sun-solaris2.7
SunOS 5.7

The same setup works on

>gcc --version;gcc -dumpmachine;uname -sr
gcc (GCC) 3.1
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

i686-pc-linux-gnu
Linux 2.4.10-4GB


Greetings

Berthold
-- 
Dipl.-Ing. Berthold H llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From hoel at germanlloyd.org  Mon Jul 15 17:55:17 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 15 Jul 2002 17:55:17 +0200
Subject: [C++-sig] Next problem with boost python
Message-ID: <sen0stnfyy.fsf@pc970145.GermanLloyd.de>

Hello,

I just tried the example from 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/li
bs/python/doc/v2/module.html

#include <boost/python/module.hpp>

using namespace boost::python;

char const* greet()
{
    return "hello, Boost.Python!";
}

BOOST_PYTHON_MODULE_INIT(boost_greet)
{
  boost::python::module("boost_greet")
    .def("greet", greet);
}

I got it to compile and linked it against libboost_python from

.../boost/libs/python/build/bin/libboost_python.so/gcc/release/inlining-
on/runtime-link-dynamic/shared-linkable-true

but when I try to import the new generated module I get 

    import boost_greet
ImportError: ld.so.1: python: fatal: relocation error: file
./boost_greet.so: symbol
_ZN5boost6python7objects8functionC1ENS_9function2IP7_objectS5_S5_NS_21em
pty_function_policyENS_20empty_function_mixinESaINS_13function_baseEEEEj
j: referenced symbol not found

>c++filt
_ZN5boost6python7objects8functionC1ENS_9function2IP7_objectS5_S5_NS_21em
pty_function_policyENS_20empty_function_mixinESaINS_13function_baseEEEEj
j
boost::python::objects::function::function[in-charge](boost::function2<_
object*, _object*, _object*, boost::empty_function_policy,
boost::empty_function_mixin, std::allocator<boost::function_base> >,
unsigned, unsigned)

with Solaris and 

    import boost_greet
ImportError: ./boost_greet.so: undefined symbol:
_ZN5boost6python9converter19do_return_to_pythonEPKc

>c++filt _ZN5boost6python9converter19do_return_to_pythonEPKc
boost::python::converter::do_return_to_python(char const*)

What am I missing here?

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From rwgk at yahoo.com  Mon Jul 15 18:14:39 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 15 Jul 2002 09:14:39 -0700 (PDT)
Subject: [C++-sig] extractors
In-Reply-To: <20d001c22bd4$a563afb0$6601a8c0@boostconsulting.com>
Message-ID: <20020715161439.43464.qmail@web20207.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
>     d. Ultimately, that means that if the overload succeds, but the
> iterable contains the wrong kind of elements, the selected function itself
> will appear (from the Python side) to throw an exception immediately. That
> seems acceptable to me.

The tests that go with my prototype implementation of the sequence -> container
converter include a test for these overloads:

  int boost_array_3(boost::array<double, 3> const& a);
  int boost_array_4(boost::array<double, 4> const& a);

    .def("boost_array", boost_array_3)
    .def("boost_array", boost_array_4)

For this to work as expected the convertible() test has to know the number of
elements in the sequence. Is this possible if the input sequence can only be
traversed once?

Ideas:

a. I could simply limit the boost::array converters to lists and tuples. In our
environment this would be fully sufficient.

b. Or, if the input Python object is a list or tuple I check the length.
Otherwise convertible() returns true and construct() throws an exception if the
sequence length is not compatible.

c. Extending the idea: if the input Python object is a list or tuple I check
both the length and the convertibility of each element. For any other sequence
convertible() returns true and construct() throws an exception if there is a
problem.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Mon Jul 15 18:14:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 12:14:39 -0400
Subject: [C++-sig] Next problem with boost python
References: <sen0stnfyy.fsf@pc970145.GermanLloyd.de>
Message-ID: <229001c22c1a$ec26c1d0$6601a8c0@boostconsulting.com>

It looks like perhaps bpl.so is not in your LD_LIBRARY_PATH. I recommend
testing through bjam since it will handle all of this for you. See
http://mail.python.org/pipermail/c++-sig/2002-May/001100.html.

-Dave

----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>


Hello,

I just tried the example from

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/li
bs/python/doc/v2/module.html

#include <boost/python/module.hpp>

using namespace boost::python;

char const* greet()
{
    return "hello, Boost.Python!";
}

BOOST_PYTHON_MODULE_INIT(boost_greet)
{
  boost::python::module("boost_greet")
    .def("greet", greet);
}

I got it to compile and linked it against libboost_python from

.../boost/libs/python/build/bin/libboost_python.so/gcc/release/inlining-
on/runtime-link-dynamic/shared-linkable-true

but when I try to import the new generated module I get

    import boost_greet
ImportError: ld.so.1: python: fatal: relocation error: file
./boost_greet.so: symbol
_ZN5boost6python7objects8functionC1ENS_9function2IP7_objectS5_S5_NS_21em
pty_function_policyENS_20empty_function_mixinESaINS_13function_baseEEEEj
j: referenced symbol not found

>c++filt
_ZN5boost6python7objects8functionC1ENS_9function2IP7_objectS5_S5_NS_21em
pty_function_policyENS_20empty_function_mixinESaINS_13function_baseEEEEj
j
boost::python::objects::function::function[in-charge](boost::function2<_
object*, _object*, _object*, boost::empty_function_policy,
boost::empty_function_mixin, std::allocator<boost::function_base> >,
unsigned, unsigned)

with Solaris and

    import boost_greet
ImportError: ./boost_greet.so: undefined symbol:
_ZN5boost6python9converter19do_return_to_pythonEPKc

>c++filt _ZN5boost6python9converter19do_return_to_pythonEPKc
boost::python::converter::do_return_to_python(char const*)

What am I missing here?

Thanks






From david.abrahams at rcn.com  Mon Jul 15 22:24:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 16:24:08 -0400
Subject: [C++-sig] Re: boost build problem
References: <seele5paxx.fsf@pc970145.GermanLloyd.de><216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com><sewurxnkq1.fsf@pc970145.GermanLloyd.de><21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com> <ser8i5ngrf.fsf@pc970145.GermanLloyd.de>
Message-ID: <232f01c22c3d$d10247d0$6601a8c0@boostconsulting.com>

From: "Berthold H?llmann" <hoel at germanlloyd.org>


> "David Abrahams" <david.abrahams at rcn.com> writes:
>

> > Which version of GCC is this? I have heard of this problem before.
> Maybe we
> > should patch the gcc toolset for your platform.
>
> its
>
> >gcc --version;gcc -dumpmachine;uname -sr
> gcc (GCC) 3.1
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> sparc-sun-solaris2.7
> SunOS 5.7

OK. If you can reproduce this problem with a small testcase and report it
to http://gcc.gnu.org/cgi-bin/gnatsweb.pl, I will be happy to apply a patch
to the toolset to work around the problem.

Deal?





From david.abrahams at rcn.com  Mon Jul 15 22:49:33 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 16:49:33 -0400
Subject: [C++-sig] extractors
References: <20020715161439.43464.qmail@web20207.mail.yahoo.com>
Message-ID: <236c01c22c41$3404a050$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 15, 2002 12:14 PM
Subject: Re: [C++-sig] extractors


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> >     d. Ultimately, that means that if the overload succeds, but the
> > iterable contains the wrong kind of elements, the selected function
itself
> > will appear (from the Python side) to throw an exception immediately.
That
> > seems acceptable to me.
>
> The tests that go with my prototype implementation of the sequence ->
container
> converter include a test for these overloads:
>
>   int boost_array_3(boost::array<double, 3> const& a);
>   int boost_array_4(boost::array<double, 4> const& a);
>
>     .def("boost_array", boost_array_3)
>     .def("boost_array", boost_array_4)
>
> For this to work as expected the convertible() test has to know the
number of
> elements in the sequence. Is this possible if the input sequence can only
be
> traversed once?

If it exposes a __len__ method, I think the answer is yes ;-)

> Ideas:
>
> a. I could simply limit the boost::array converters to lists and tuples.
In our
> environment this would be fully sufficient.

I think it would be fine to limit them to iterables with __len__ methods.
List and tuple both fall into this category.

> b. Or, if the input Python object is a list or tuple I check the length.
> Otherwise convertible() returns true and construct() throws an exception
if the
> sequence length is not compatible.

Whether or not this is acceptable/appropriate really depends on the users'
needs. Since you guys are the users, I guess I have no comment.

> c. Extending the idea: if the input Python object is a list or tuple I
check
> both the length and the convertibility of each element. For any other
sequence
> convertible() returns true and construct() throws an exception if there
is a
> problem.

I think the real, deep answers to this lie somewhere in PEP 246:

http://www.python.org/peps/pep-0246.html


-Dave





From cb9001 at hotmail.com  Mon Jul 15 23:14:28 2002
From: cb9001 at hotmail.com (Chris Booth)
Date: Mon, 15 Jul 2002 16:14:28 -0500
Subject: [C++-sig] boosting a tuple
Message-ID: <F239M3oryKFRJrzdDW60000c7ac@hotmail.com>

Hi all,

I am trying to export a C++ class to python using the boost package
(www.boost.org).  I want my C++ functions to return a tuple:

#include "boost/tuple/tuple.hpp"

class TestClass
{
   public:
      TestClass();
      ~TestClass();
      void setXYZ(float x,float y, float z);
      boost::tuples::tuple<float,float,float> getXYZ();
};


And i wrap the class up as follows...

#include <boost/python/class_builder.hpp>

BOOST_PYTHON_MODULE_INIT(Test)
{
   boost::python::module_builder TestClass_Module("Test");
   boost::python::class_builder<TestClass> pyTestClass(TestClass_Module, 
"TestClass");
   pyTestClass.def(boost::python::constructor<>());
   pyTestClass.def(TestClass::getXYZ, "getXYZ");  // <-- Line #1
   pyTestClass.def(TestClass::setXYZ,"setXYZ");
}


if i comment out Line #1, the code compliles to a library that i can import 
in python.  If i leave this line in, then i get the following error message. 
  My system is a WindowsXP, MSVC 6.0, boost 1.27.0.  Any suggestions would 
be really appreciated...

chris

-------------
j:\chrisb\boost_1_27_0\boost\python\detail\extension_class.hpp(393) :
error C2664: 'py_extension_class_converters' : cannot convert
parameter 1 from 'struct boost::python::type<class
boost::tuples::tuple<float,float,float,struct boost::tuples::null_
type,struct boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type,struct
boost::tuples::null_type> >' to 'struct boost::python::type<class
FasTEMComm>'
        No constructor could take the source type, or constructor
overload resolution was ambiguous
        j:\chrisb\boost_1_27_0\boost\python\caller.hpp(33) : see
reference to function template instantiation 'struct _object *__cdecl
boost::python::to_python(const class
boost::tuples::tuple<float,float,float,struct
boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type> &)' being
compiled
j:\chrisb\boost_1_27_0\boost\python\detail\extension_class.hpp(393) :
error C2228: left of '.to_python' must have class/struct/union type
        j:\chrisb\boost_1_27_0\boost\python\caller.hpp(33) : see
reference to function template instantiation 'struct _object *__cdecl
boost::python::to_python(const class
boost::tuples::tuple<float,float,float,struct
boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type,struct
boost::tuples::null_type,struct boost::tuples::null_type> &)' being
compiled
Error executing cl.exe.
--------------------



_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx





From rwgk at yahoo.com  Tue Jul 16 00:14:10 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 15 Jul 2002 15:14:10 -0700 (PDT)
Subject: [C++-sig] boosting a tuple
In-Reply-To: <F239M3oryKFRJrzdDW60000c7ac@hotmail.com>
Message-ID: <20020715221410.77601.qmail@web20203.mail.yahoo.com>

--- Chris Booth <cb9001 at hotmail.com> wrote:
> Hi all,
> 
> I am trying to export a C++ class to python using the boost package
> (www.boost.org).  I want my C++ functions to return a tuple:
> 
> #include "boost/tuple/tuple.hpp"
> 
> class TestClass
> {
>    public:
>       TestClass();
>       ~TestClass();
>       void setXYZ(float x,float y, float z);
>       boost::tuples::tuple<float,float,float> getXYZ();
> };
> 
> 
> And i wrap the class up as follows...
> 
> #include <boost/python/class_builder.hpp>
> 
> BOOST_PYTHON_MODULE_INIT(Test)
> {
>    boost::python::module_builder TestClass_Module("Test");
>    boost::python::class_builder<TestClass> pyTestClass(TestClass_Module, 
> "TestClass");
>    pyTestClass.def(boost::python::constructor<>());
>    pyTestClass.def(TestClass::getXYZ, "getXYZ");  // <-- Line #1
>    pyTestClass.def(TestClass::setXYZ,"setXYZ");
> }

You have to use class_builder<boost::tuples::tuple<float,float,float> > before
you can return your tuple from a function. Alternatively you can look at
libs/python/example/do_it_yourself_convts.cpp to see learn you can map to
boost::tuple to a Python tuple.

Anyway, if you have three numbers, I think you should consistently be using
boost::array<> (both in getXYZ and setXYZ). Then you will find it even easier
to adapt the example.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Tue Jul 16 03:01:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Jul 2002 21:01:51 -0400
Subject: [C++-sig] extractors
Message-ID: <24bc01c22c64$5fef8680$6601a8c0@boostconsulting.com>

From: "David Abrahams" <david.abrahams at rcn.com>

> > c. Extending the idea: if the input Python object is a list or tuple I
> check
> > both the length and the convertibility of each element. For any other
> sequence
> > convertible() returns true and construct() throws an exception if there
> is a
> > problem.
>
> I think the real, deep answers to this lie somewhere in PEP 246:
>
> http://www.python.org/peps/pep-0246.html

But to give a more concrete (less-glib) answer, I think we need to look at
some real cases.

Lists/Tuples - Let me assign a concept name. These are
measurable-sequences. A measurable-sequence has a __len__ and a __getitem__
function. I'm making this distinction because Ralf wants to do overload
resolution based on the length of a sequence for matching boost::array<>
instantiations.

This begs the question "what is a (Python) sequence?"

Near as I can divine from the iter() documentation and experiments, a
sequence is an object with a __getitem__ method which accepts int arguments
and raises IndexError when the sequence is exhausted.

Finally, we have iterables. An iterable is a sequence or an object with an
__iter__ method.

It seems to me that Boost.Python ought to provide a way for the user to
specify which of these concepts he wants to be converted to his C++
sequence type. Furthermore, we might want a way for the user to specify
that a measurable-sequence should be checked for the convertibility of each
element before overload resolution succeeds.

-Dave





From hoel at germanlloyd.org  Tue Jul 16 17:38:17 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 16 Jul 2002 17:38:17 +0200
Subject: [C++-sig] Re: boost build problem
In-Reply-To: <232f01c22c3d$d10247d0$6601a8c0@boostconsulting.com>
References: <seele5paxx.fsf@pc970145.GermanLloyd.de><216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com><sewurxnkq1.fsf@pc970145.GermanLloyd.de><21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com><ser8i5ngrf.fsf@pc970145.GermanLloyd.de><232f01c22c3d$d10247d0$6601a8c0@boostconsulting.com>
Message-ID: <seznwrel92.fsf@pc970145.GermanLloyd.de>

"David Abrahams" <david.abrahams at rcn.com> writes:

> From: "Berthold Hllmann" <hoel at germanlloyd.org>
> 
> 
> > "David Abrahams" <david.abrahams at rcn.com> writes:
> >
> 
> OK. If you can reproduce this problem with a small testcase and report
it
> to http://gcc.gnu.org/cgi-bin/gnatsweb.pl, I will be happy to apply a
patch
> to the toolset to work around the problem.
> 
> Deal?


OK, it's Problem Report 7327 on
http://gcc.gnu.org/cgi-bin/gnatsweb.pl, but because the lines


#include <boost/any.hpp>

int main(void) {
  return 0;
}

expand to a whole lot of stuff in the preprocessor, the bug report
became quite big.

Cheers

Berthold
-- 
Dipl.-Ing. Berthold H llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From david.abrahams at rcn.com  Tue Jul 16 18:19:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 16 Jul 2002 12:19:10 -0400
Subject: [C++-sig] Re: boost build problem
References: <seele5paxx.fsf@pc970145.GermanLloyd.de><216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com><sewurxnkq1.fsf@pc970145.GermanLloyd.de><21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com><ser8i5ngrf.fsf@pc970145.GermanLloyd.de><232f01c22c3d$d10247d0$6601a8c0@boostconsulting.com> <seznwrel92.fsf@pc970145.GermanLloyd.de>
Message-ID: <001501c22ce4$b972f680$6501a8c0@boostconsulting.com>

From: "Berthold H?llmann" <hoel at germanlloyd.org>


> "David Abrahams" <david.abrahams at rcn.com> writes:
>
> > From: "Berthold Hllmann" <hoel at germanlloyd.org>
> >
> >
> > > "David Abrahams" <david.abrahams at rcn.com> writes:
> > >
> >
> > OK. If you can reproduce this problem with a small testcase and report
> it
> > to http://gcc.gnu.org/cgi-bin/gnatsweb.pl, I will be happy to apply a
> patch
> > to the toolset to work around the problem.
> >
> > Deal?
>
>
> OK, it's Problem Report 7327 on
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl, but because the lines
>
>
> #include <boost/any.hpp>
>
> int main(void) {
>   return 0;
> }
>
> expand to a whole lot of stuff in the preprocessor, the bug report
> became quite big.

Well, that's hardly a "small testcase" is it? Couldn't you reduce it to a
simple example?

-Dave






From daveh at cadlink.com  Tue Jul 16 18:50:45 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 16 Jul 2002 12:50:45 -0400
Subject: [C++-sig] Build errors with VC6
Message-ID: <ah1ivd$rtq$1@main.gmane.org>

I'm currently getting build errors (clean source from CVS!) with VC6 in a
number of places ie:

h:\projects\boost2\libs\python\src\converter\from_python.cpp(225) : error
C2955: 'type' : use of class template requires template argument list
        h:\projects\boost2\boost\type.hpp(15) : see declaration of 'type'

This appears to be due to the declaration.


BOOST_PYTHON_DECL python::detail::new_reference
pytype_result_from_python(PyTypeObject* type, PyObject* source)

getting the type identifier from.

namespace boost {

  // Just a simple "type envelope". Useful in various contexts, mostly to
work
  // around some MSVC deficiencies.
  template <class T>
  struct type {};

}

Though I don't know why as the namespaces should prevent it.

Dave Hawkes









From david.abrahams at rcn.com  Tue Jul 16 19:13:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 16 Jul 2002 13:13:46 -0400
Subject: [C++-sig] Build errors with VC6
References: <ah1ivd$rtq$1@main.gmane.org>
Message-ID: <017001c22cec$615e28e0$6501a8c0@boostconsulting.com>

Thanks, fixed.
It's just a stupid VC6-ism.

-Dave

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Tuesday, July 16, 2002 12:50 PM
Subject: [C++-sig] Build errors with VC6


> I'm currently getting build errors (clean source from CVS!) with VC6 in a
> number of places ie:
>
> h:\projects\boost2\libs\python\src\converter\from_python.cpp(225) : error
> C2955: 'type' : use of class template requires template argument list
>         h:\projects\boost2\boost\type.hpp(15) : see declaration of 'type'
>
> This appears to be due to the declaration.
>
>
> BOOST_PYTHON_DECL python::detail::new_reference
> pytype_result_from_python(PyTypeObject* type, PyObject* source)
>
> getting the type identifier from.
>
> namespace boost {
>
>   // Just a simple "type envelope". Useful in various contexts, mostly to
> work
>   // around some MSVC deficiencies.
>   template <class T>
>   struct type {};
>
> }
>
> Though I don't know why as the namespaces should prevent it.
>
> Dave Hawkes
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From bhoel at web.de  Tue Jul 16 20:04:11 2002
From: bhoel at web.de (Berthold =?iso-8859-1?q?H=F6llmann?=)
Date: 16 Jul 2002 20:04:11 +0200
Subject: [C++-sig] Re: boost build problem
In-Reply-To: <001501c22ce4$b972f680$6501a8c0@boostconsulting.com>
References: <seele5paxx.fsf@pc970145.GermanLloyd.de>
	<216801c22c00$b5eceaa0$6601a8c0@boostconsulting.com>
	<sewurxnkq1.fsf@pc970145.GermanLloyd.de>
	<21f201c22c0b$cbc2aa30$6601a8c0@boostconsulting.com>
	<ser8i5ngrf.fsf@pc970145.GermanLloyd.de>
	<232f01c22c3d$d10247d0$6601a8c0@boostconsulting.com>
	<seznwrel92.fsf@pc970145.GermanLloyd.de>
	<001501c22ce4$b972f680$6501a8c0@boostconsulting.com>
Message-ID: <m28z4bv9b8.fsf@pchoel.privat.uni-hamburg.de>

"David Abrahams" <david.abrahams at rcn.com> writes:

> From: "Berthold H?llmann" <hoel at germanlloyd.org>
> 
> 

> >
> >
> > OK, it's Problem Report 7327 on
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl, but because the lines
> >
> >
> > #include <boost/any.hpp>
> >
> > int main(void) {
> >   return 0;
> > }
> >
> > expand to a whole lot of stuff in the preprocessor, the bug report
> > became quite big.
> 
> Well, that's hardly a "small testcase" is it? Couldn't you reduce it to a
> simple example?

I was lost in scanning the header files for some suspicious lines but
could not find one. Comparing the preprocessor output of the "-I" and
"-isystem" call did not lead to any significant difference, all the
same header files. There were only small differences in the lines
indicating include files. I'm not shure what the number after the
include files path are saying, but they are the only entries in the
files that differ. But a simple "#include <utility>" did not show the
bug. So I could not find a smaller example, sorry.

Greetings

Berthold
-- 
bhoel at web.de / http://starship.python.net/crew/bhoel/
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.




From daveh at cadlink.com  Tue Jul 16 21:36:30 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 16 Jul 2002 15:36:30 -0400
Subject: [C++-sig] Re: Build errors with VC6
References: <ah1ivd$rtq$1@main.gmane.org> <017001c22cec$615e28e0$6501a8c0@boostconsulting.com>
Message-ID: <ah1sm8$qft$1@main.gmane.org>

Is it in CVS as I'm still geting the same failures?

Thanks
Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:017001c22cec$615e28e0$6501a8c0 at boostconsulting.com...
> Thanks, fixed.
> It's just a stupid VC6-ism.
>
> -Dave
>
> ----- Original Message -----
> From: "Dave Hawkes" <daveh at cadlink.com>
> Newsgroups: gmane.comp.python.c++
> To: <c++-sig at python.org>
> Sent: Tuesday, July 16, 2002 12:50 PM
> Subject: [C++-sig] Build errors with VC6
>
>
> > I'm currently getting build errors (clean source from CVS!) with VC6 in
a
> > number of places ie:
> >
> > h:\projects\boost2\libs\python\src\converter\from_python.cpp(225) :
error
> > C2955: 'type' : use of class template requires template argument list
> >         h:\projects\boost2\boost\type.hpp(15) : see declaration of
'type'
> >
> > This appears to be due to the declaration.
> >
> >
> > BOOST_PYTHON_DECL python::detail::new_reference
> > pytype_result_from_python(PyTypeObject* type, PyObject* source)
> >
> > getting the type identifier from.
> >
> > namespace boost {
> >
> >   // Just a simple "type envelope". Useful in various contexts, mostly
to
> > work
> >   // around some MSVC deficiencies.
> >   template <class T>
> >   struct type {};
> >
> > }
> >
> > Though I don't know why as the namespaces should prevent it.
> >
> > Dave Hawkes
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >








From david.abrahams at rcn.com  Tue Jul 16 21:59:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 16 Jul 2002 15:59:03 -0400
Subject: [C++-sig] Re: Build errors with VC6
References: <ah1ivd$rtq$1@main.gmane.org> <017001c22cec$615e28e0$6501a8c0@boostconsulting.com> <ah1sm8$qft$1@main.gmane.org>
Message-ID: <01a101c22d03$a874e4a0$6501a8c0@boostconsulting.com>

It is now...

From: "Dave Hawkes" <daveh at cadlink.com>


> Is it in CVS as I'm still geting the same failures?
> 
> Thanks
> Dave Hawkes






From bmccandl at llnl.gov  Tue Jul 16 23:27:29 2002
From: bmccandl at llnl.gov (Brian McCandless)
Date: Tue, 16 Jul 2002 14:27:29 -0700
Subject: [C++-sig] Support for In/Out arguments?
Message-ID: <3D348FC1.60F1CFC7@llnl.gov>


Hello,

I am attempting to wrap a 3rd party library with BPL v2. This library uses it
own non-standard linked lists.  I have written a function that convert a python
sequence to one of these lists and registered it with registry::insert.  I have
also written a to_python_converter to handle the return values.   Both of these
work find, But I am stuck when the 3rd party library uses one of their lists as
an in/out argument:

class ThirdPartyClass {
public:

  // ...
  virtual void appendToList(ThirdPartList& foo);
};

The method appendToList modifies the input argument foo by adding elements to
the list.  There are many functions that follow this pattern, so I am looking
for a general solution.

How might I handle this situation in BPL?

Thanks,
Brian

--
 Brian McCandless     bmccandl at llnl.gov     925/424-2690


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020716/e851cd50/attachment.htm>

From david.abrahams at rcn.com  Tue Jul 16 23:47:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 16 Jul 2002 17:47:02 -0400
Subject: [C++-sig] Support for In/Out arguments?
References: <3D348FC1.60F1CFC7@llnl.gov>
Message-ID: <020001c22d12$5c3d55e0$6501a8c0@boostconsulting.com>

From: "Brian McCandless" <bmccandl at llnl.gov>


> Hello,
>
> I am attempting to wrap a 3rd party library with BPL v2. This library
uses it
> own non-standard linked lists.  I have written a function that convert a
python
> sequence to one of these lists and registered it with registry::insert.
I have
> also written a to_python_converter to handle the return values.   Both of
these
> work find, But I am stuck when the 3rd party library uses one of their
lists as
> an in/out argument:
>
> class ThirdPartyClass {
> public:
>
>   // ...
>   virtual void appendToList(ThirdPartList& foo);
> };
>
> The method appendToList modifies the input argument foo by adding
elements to
> the list.  There are many functions that follow this pattern, so I am
looking
> for a general solution.
>
> How might I handle this situation in BPL?

Suggestion: don't touch the low-level undocumented interfaces (i.e.
registry::insert). Instead, use class_<ThirdPartyList> to wrap the linked
lists. Everything will just work.

Is there some good reason you didn't take the straightforward approach?

-Dave






From bmccandl at llnl.gov  Wed Jul 17 00:52:20 2002
From: bmccandl at llnl.gov (Brian McCandless)
Date: Tue, 16 Jul 2002 15:52:20 -0700
Subject: [C++-sig] Support for In/Out arguments?
Message-ID: <3D34A3A4.EC4BF167@llnl.gov>


> Suggestion: don't touch the low-level undocumented interfaces (i.e.
> registry::insert). Instead, use class_<ThirdPartyList> to wrap the linked
> lists. Everything will just work.
>
> Is there some good reason you didn't take the straightforward approach?
>
> -Dave


Dave,

I am trying to provide a python interface that hides the ThirdPartyList,
and uses regular python lists when interfacing to the Third Party Library.
That is why I chose not to wrap the ThirdPartyList.

In C++, If I have:

class ThirdPartyClass {
public:

  // ...
  virtual void appendToList(ThirdPartList& foo);
};

I would like the python to look like this:

>>> plist = [1,2,3]
>>> tpc = ThirdPartClass()
>>> tpc.appendToList(plist)

Where plist has been modified.

I would like the python list converted to a temporary ThirdPartList,
which is passed into the method appendToList.  Then have the original python
list modified to reflect the new values in the temporary ThirdPartyList.
Copy in Copy out.

Is this sort of thing possible?

Brian


> Suggestion: don't touch the low-level undocumented interfaces (i.e.
> registry::insert). Instead, use class_<ThirdPartyList> to wrap the linked
> lists. Everything will just work.
>
> Is there some good reason you didn't take the straightforward approach?
>
> -Dave


--
 Brian McCandless     bmccandl at llnl.gov     925/424-2690


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020716/f78f5331/attachment.htm>

From david.abrahams at rcn.com  Wed Jul 17 02:00:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 16 Jul 2002 20:00:34 -0400
Subject: [C++-sig] Support for In/Out arguments?
References: <3D34A3A4.EC4BF167@llnl.gov>
Message-ID: <026e01c22d25$026b9500$6501a8c0@boostconsulting.com>

From: "Brian McCandless" <bmccandl at llnl.gov>

> > Suggestion: don't touch the low-level undocumented interfaces (i.e.
> > registry::insert). Instead, use class_<ThirdPartyList> to wrap the
linked
> > lists. Everything will just work.
> >
> > Is there some good reason you didn't take the straightforward approach?
> >
> > -Dave
>
>
> Dave,
>
> I am trying to provide a python interface that hides the ThirdPartyList,
> and uses regular python lists when interfacing to the Third Party
Library.
> That is why I chose not to wrap the ThirdPartyList.
>
> In C++, If I have:
>
> class ThirdPartyClass {
> public:
>
>   // ...
>   virtual void appendToList(ThirdPartList& foo);
> };
>
> I would like the python to look like this:
>
> >>> plist = [1,2,3]
> >>> tpc = ThirdPartClass()
> >>> tpc.appendToList(plist)
>
> Where plist has been modified.
>
> I would like the python list converted to a temporary ThirdPartList,
> which is passed into the method appendToList.  Then have the original
python
> list modified to reflect the new values in the temporary ThirdPartyList.
> Copy in Copy out.
>
> Is this sort of thing possible?

Sheesh. I understand your problem now.

Yes, it's possible. A simple solution is to use "thin wrapper" functions
which accept boost::python::list arguments. The convert() functions will be
a little cumbersome now, since we're waiting on Dave Hawkes' api work:

void foo_wrapper(python::list& l)
{
    ThirdPartList l2;
    convert(l, l2);
    foo(l2);               // call the real function
    convert(l2, l);
}

Then you wrap foo_wrapper as "foo".

However, I recognize that's none too convenient if you have to do a lot of
these. If you can guarantee that every module wrapping a function which
manipulates ThirdPartList will see it, you can do this with an explicit
specialization of arg_from_python<ThirdPartList&>. It's still kinda ugly,
for two reasons:

1. This becomes the one-and-only way to convert Python objects to
ThirdPartList&. For example if someone wraps a class derived from
ThirdPartList, you won't be able to pass it to a wrapped function accepting
ThirdPartList&. That may not matter to you, though.

2. The specialization would have to do the work of putting the data back in
the Python list in the arg_from_python<> destructor, which could
theoretically fail. I guess we could consider adding a postcall() function
to arg_from_python converters, but I'm reluctant. We'd be forced to make a
choice between:

  a. making it functional for arg_from_python converters which use the
registry, with a corresponding efficiency cost for every single argument of
a wrapped function.

  b. making it functional only for specialized arg_from_python converters
which decide to implement it as more than just an empty function, which
leaves the mechanism somewhat crippled.

I hope that none of this is really neccessary, but if we really need
something like this, I'm inclined to move in the direction of (a). We've
already seen some tension in this direction from Ralf's desire to store a
temporary sequence in an arg_from_python converter. However, I think I've
cured him of that desire for the time being <wink>.

Another thought might be to extend the role of CallPolicies to deal with
arguments.

-Dave






From achim.domma at syynx.de  Wed Jul 17 14:36:25 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 17 Jul 2002 14:36:25 +0200
Subject: [C++-sig] Outstanding Jobs for v2 release
In-Reply-To: <1c0901c22a9f$3e60c090$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAOECJDJAA.achim.domma@syynx.de>

> Please try doctests; it's really quite easy if you use the build system.

Where it makes sense, I changed the return values from long to bool. Then I
wrote some tests using doctest, but have some problems:

- the test for 'str' fails. the output of 'Expected' and 'Got' seem equal to
me, but doctest says they are not. I searched for differences in tabs and
spaces but did not find anything.

- slice and operator[] do not work. slice does not work at all and
operator[] could only be used for writing. here is an example for 'dict':


    dict tmp;
    tmp[1] = "a test string";
    print(tmp.get(1));
    print(tmp[1]);


The last line fails with the following error:

TypeError: No to_python (by-value) converter found for C++ type: class
boost::python::api::proxy<struct boost::python::api::item_policies>

Is this my fault? what's going wrong here?

Achim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: str-dict-tuple.zip
Type: application/x-zip-compressed
Size: 9559 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020717/1e819862/attachment.bin>

From david.abrahams at rcn.com  Wed Jul 17 14:53:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 08:53:57 -0400
Subject: [C++-sig] Questions/Comments about new stuff
Message-ID: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com>

Hi Dave,

Thanks for checking in the new stuff. It's wicked cool! There are some
things I want to tweak, and some others that I have questions about.

. What's the point of this module_info class? It looks like it should be a
namespace. Not everything should be an object...

. You have put get_module_info/set_module_info in the public interface of
module_base, and thus in the public interface of module. Why? If it's right
(I hope it's not), then you need to move module_info out of the detail
namespace...

. get_prior_module really gets the current module, doesn't it? shouldn't it
be called module::current()?

.  PRE_INIT_FUNC must be BOOST_PYTHON_PRE_INIT_FUNC, and it should be
#undef'd when you're done with it. We also need to get our generated
init_module_#xxx stuff into the unnamed namespace.

. What is "get_class_context_object()"? I'm not fond of that name. I think
in Python that's called a name space. I would prefer renaming that function
"name_space()". If the handle<> can never be NULL, it should return object
instead.

. submod_subclass_api.cpp should be renamed, since a subclass is not the
same as a nested class ;-), and putting "api" in the name of a library test
is sorta redundant. How about "nested.cpp"?

. It contains a comment which says it's called embed_test.cpp

. It contains lots of macro definitions which are never used. These should
all be stripped out, as they harm readability. In this particular case, the
macros that do get used don't save any more text than the definition of the
macro cost, so they should be removed also.

. I'm not happy with the name 'call_statement'. After all, you can pass it
more than one statement, and you're not calling anything. I'm not sure I
have a better name for it yet, but what about eval()? I realize Python has
a different eval(), but I think it's got equivalent applications.

. call_statement_du should be renamed to simply "call_statement".
Overloading should work; if it doesn't we have a problem. In any case,
abbrevs sch as du shld be avoid.

. You kept get_arg<>, despite my challenges... OK, but you didn't respond
to my questions about it either. I hope you understand, I have to either be
satisfied that it's the right choice, or rip it out. I guess the point is
that you're saving an Py_INCREF()/Py_DECREF() pair for each object passed?
I'm still unconvinced it's worth it. Have you done any measurements? Note
that the way you've written it, it won't work for classes such as list
which are derived from object. I also don't understand why there's an
object const* converter. I'm still very uncomfortable with this.

. py_interface.hpp might be too big, IMO. People like to be able to select
how much stuff gets dragged into each translation unit by using
high-granularity headers.

. It's still using get_func("...") in function templates, which will
generate too much code in extension modules. For example,

BOOST_PYTHON_DECL object slice(object const& a0, object const& a1);
BOOST_PYTHON_DECL object slice(int a0, int a1);
template<class A0, class A1, class A2>
object slice(A0 const& a0, A1 const& a1, A2 const& a2)
{
    return api_detail::get_func("slice")(api_detail::get_arg<A0>(a0),
api_detail::get_arg<A1>(a1), api_detail::get_arg<A2>(a2));
}


That should be rewritten:

BOOST_PYTHON_DECL object slice(object const& a0, object const& a1);
BOOST_PYTHON_DECL object slice(int a0, int a1);
template<class A0, class A1, class A2>
object slice(A0 const& a0, A1 const& a1, A2 const& a2)
{
    return slice(api_detail::get_arg<A0>(a0).operator object const&()
        , api_detail::get_arg<A1>(a1).operator object const&()
        , api_detail::get_arg<A2>(a2).operator object const&());
}

. I don't like this change:

-    class_();
+     class_(base const& parent_class = empty_class_base());
-    class_(char const* name);
+    class_(char const* name, base const& parent_class =
empty_class_base());

a. Default arguments generally create more code than using overloads
b. A class with no parent class doesn't have an empty class as its parent
c. Parent is the wrong name -- should be "enclosing"

. I don't like this change:

+    // add to module
+    self& add(module &m)
+    {
+        // redundant
+        // m.add(*this);
+        return *this;
+    }
+

Calling a.add(b) looks like it adds b to a, not the other way around.
Should these add() functions really appear in the public interface of
class_<>?


. Likewise for the rest of the changes to class.hpp

. This change really worries me:

     module& add(class_<T1,T2,T3,T4> const& c)
     {
-        this->add_class(c.object());
+        // redundant
+        // this->add_class(c.object());
         return *this;
     }

You can't just comment stuff out and expect it to work... Perhaps you're
just leaving this function in so that existing code will keep compiling in
the short term? I could understand that.

. Your code generators use large swaths of C++ code which gets stuffed into
source and header files, e.g. DeclFileHeader. Couldn't these just be
written as C++ files which get #included in the result? Better yet, have an
outer file which #includes the generated and non-generated components.

. What is your naming convention for the Python code? You have an odd
combination of MixedCase and all_lower_case. There is a Python style guide
somewhere...

-Dave






From hoel at germanlloyd.org  Wed Jul 17 15:26:10 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 17 Jul 2002 15:26:10 +0200
Subject: [C++-sig] Hnadling Python exceptions in C++
Message-ID: <seit3efpu5.fsf@pc970145.GermanLloyd.de>

Hello,

Is there any code for handling Python exceptions in C++? I only found
report_ignored_exception in classes.cpp, but it's in anonymous
namespace and though inaccessable in my code.

Greetings

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From david.abrahams at rcn.com  Wed Jul 17 15:43:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 09:43:39 -0400
Subject: [C++-sig] Hnadling Python exceptions in C++
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de>
Message-ID: <03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com>

In Boost.Python v1, there's no special facility. You can use the regular
Python 'C' API, of course. We are planning some support in Boost.Python v2.
I'd like to try to serve your needs; what kind of facilities did you have
in mind?

Thanks,
Dave

----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>
Hello,

Is there any code for handling Python exceptions in C++? I only found
report_ignored_exception in classes.cpp, but it's in anonymous
namespace and though inaccessable in my code.

Greetings

Berthold





From david.abrahams at rcn.com  Wed Jul 17 16:02:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 10:02:50 -0400
Subject: [C++-sig] Bug
Message-ID: <041901c22d9b$135c44b0$6501a8c0@boostconsulting.com>

Hi Dave,

Did you run all tests before checking in? Your recent checkins introduced a
crash in the iterator test. I'm testing against a debug-python build for
the extra checks...

-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 daveh at cadlink.com  Wed Jul 17 16:33:40 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 17 Jul 2002 10:33:40 -0400
Subject: [C++-sig] Re: Bug
References: <041901c22d9b$135c44b0$6501a8c0@boostconsulting.com>
Message-ID: <ah3vam$888$1@main.gmane.org>

Yes I tested with gcc 3.1 / cygwin. I'll check out from CVS and retest.

Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:041901c22d9b$135c44b0$6501a8c0 at boostconsulting.com...
> Hi Dave,
>
> Did you run all tests before checking in? Your recent checkins introduced
a
> crash in the iterator test. I'm testing against a debug-python build for
> the extra checks...
>
> -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  Wed Jul 17 16:34:00 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 10:34:00 -0400
Subject: [C++-sig] Re: Bug
References: <041901c22d9b$135c44b0$6501a8c0@boostconsulting.com> <ah3vam$888$1@main.gmane.org>
Message-ID: <048401c22d9f$8169f4d0$6501a8c0@boostconsulting.com>

When I did that test using a Python configured --with-pydebug, I saw the
crash.

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>


> Yes I tested with gcc 3.1 / cygwin. I'll check out from CVS and retest.
>
> Dave Hawkes
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:041901c22d9b$135c44b0$6501a8c0 at boostconsulting.com...
> > Hi Dave,
> >
> > Did you run all tests before checking in? Your recent checkins
introduced
> a
> > crash in the iterator test. I'm testing against a debug-python build
for
> > the extra checks...
> >
> > -Dave






From daveh at cadlink.com  Wed Jul 17 17:03:02 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 17 Jul 2002 11:03:02 -0400
Subject: [C++-sig] Re: Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com>
Message-ID: <001f01c22da3$0e4a6170$4110a8c0@ottawa.cadlink.com>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: "Dave Hawkes" <daveh at cadlink.com>
Cc: "pysig" <c++-sig at python.org>
Sent: Wednesday, July 17, 2002 8:53 AM
Subject: Questions/Comments about new stuff


> . What's the point of this module_info class? It looks like it should be a
> namespace. Not everything should be an object...
>
It holds the running information about the module being created, so that
objects can be added to the previously declared module. I'm not sure that a
namespace would be correct for this.

> . You have put get_module_info/set_module_info in the public interface of
> module_base, and thus in the public interface of module. Why? If it's
right
> (I hope it's not), then you need to move module_info out of the detail
> namespace...
>
I had some issues with it being private and building with gcc, though it was
OK with VC6 and I quickly moved it yesterday as a quick workaround.
Basically the issue for get_module_info is that it is used in the class
initialiser list for module_base and gcc complains. This can be worked
around using friends and then made private again.

set_module_info is another matter this needs to be accessed from with hte
module_init code I can make it private using either friends or an
intermediate class.

> . get_prior_module really gets the current module, doesn't it? shouldn't
it
> be called module::current()?
>
I was looking at it as the previously declared module as it is used in the
construction of current module declaration. But you could think in terms of
the current module and next module declaration.

> .  PRE_INIT_FUNC must be BOOST_PYTHON_PRE_INIT_FUNC, and it should be
> #undef'd when you're done with it. We also need to get our generated
> init_module_#xxx stuff into the unnamed namespace.
>
I can tidy that up fairly easily.

> . What is "get_class_context_object()"? I'm not fond of that name. I think
> in Python that's called a name space. I would prefer renaming that
function
> "name_space()". If the handle<> can never be NULL, it should return object
> instead.
>
It get the nested class context in which to add the current class
information. I didn't call it a namespace as that may imply its a generic
namespace where in fact it only applies to class definitions. It can legally
return NULL so I had to use handle() for the return.

> . submod_subclass_api.cpp should be renamed, since a subclass is not the
> same as a nested class ;-), and putting "api" in the name of a library
test
> is sorta redundant. How about "nested.cpp"?
>
It's not complete yet as it will also test the api module when it's
complete. Also it will eventually accept an argument that will select the
test to perform so it can installed as 3 separate tests. In fact it could be
extendible to additional suites of tests at which point the name in fact is
inapropriate.
> . It contains a comment which says it's called embed_test.cpp
>
Missed that in the clean up...
> . It contains lots of macro definitions which are never used. These should
> all be stripped out, as they harm readability. In this particular case,
the
> macros that do get used don't save any more text than the definition of
the
> macro cost, so they should be removed also.
>
This was boiler plate that came from something larger. I was planning on
adding more tests so the macros would be more useful but that hasn't happend
yet. I can certainly remove them for now.

> . I'm not happy with the name 'call_statement'. After all, you can pass it
> more than one statement, and you're not calling anything. I'm not sure I
> have a better name for it yet, but what about eval()? I realize Python has
> a different eval(), but I think it's got equivalent applications.
>
eval is already implemented to emulate what eval does. Remember eval returns
the result of an expression. In fact its closer to exec in functionality,
but that's already defined as well...
I couldn't think of a better name either and unfortunately its stuck with
the first one that came in to my head.

> . call_statement_du should be renamed to simply "call_statement".
> Overloading should work; if it doesn't we have a problem. In any case,
> abbrevs sch as du shld be avoid.
>
It was call_statement until yesterday when I though I was having some issues
with gcc 3.1, so I changed it just in case until I could do some more
testing. This is meant to be a private interface so the user should not use
it.

> . You kept get_arg<>, despite my challenges... OK, but you didn't respond
> to my questions about it either. I hope you understand, I have to either
be
> satisfied that it's the right choice, or rip it out. I guess the point is
> that you're saving an Py_INCREF()/Py_DECREF() pair for each object passed?
> I'm still unconvinced it's worth it. Have you done any measurements? Note
> that the way you've written it, it won't work for classes such as list
> which are derived from object. I also don't understand why there's an
> object const* converter. I'm still very uncomfortable with this.
>
I was trying to save the additional object constructution/destruction. If
you feel it's not worth it I can certainly take it out. Yes it would need to
be adjusted for the addional object derivatives. So maybe its not worth it
from a maintenace point of view. I'll take it out for now.

> . py_interface.hpp might be too big, IMO. People like to be able to select
> how much stuff gets dragged into each translation unit by using
> high-granularity headers.
>
As I started adding to it I did wonder about this myself. Currently tt's not
excessively large and it doesn't need much preprocessing so it should be
fast to compile. However it's probably worth thinking about some API groups
that it may be split along later. I was thinking about having a header that
included all the API headers for those that want everything and then the
individual headers with API groups for those that wish to fine tune.

> . It's still using get_func("...") in function templates, which will
> generate too much code in extension modules. For example,
>
> BOOST_PYTHON_DECL object slice(object const& a0, object const& a1);
> BOOST_PYTHON_DECL object slice(int a0, int a1);
> template<class A0, class A1, class A2>
> object slice(A0 const& a0, A1 const& a1, A2 const& a2)
> {
>     return api_detail::get_func("slice")(api_detail::get_arg<A0>(a0),
> api_detail::get_arg<A1>(a1), api_detail::get_arg<A2>(a2));
> }
>
>
> That should be rewritten:
>
> BOOST_PYTHON_DECL object slice(object const& a0, object const& a1);
> BOOST_PYTHON_DECL object slice(int a0, int a1);
> template<class A0, class A1, class A2>
> object slice(A0 const& a0, A1 const& a1, A2 const& a2)
> {
>     return slice(api_detail::get_arg<A0>(a0).operator object const&()
>         , api_detail::get_arg<A1>(a1).operator object const&()
>         , api_detail::get_arg<A2>(a2).operator object const&());
> }
>
I'll get rid of the get_arg and rework these anyway.

> . I don't like this change:
>
> -    class_();
> +     class_(base const& parent_class = empty_class_base());
> -    class_(char const* name);
> +    class_(char const* name, base const& parent_class =
> empty_class_base());
>
> a. Default arguments generally create more code than using overloads
> b. A class with no parent class doesn't have an empty class as its parent
> c. Parent is the wrong name -- should be "enclosing"
>
I can change these to get rid of the defaults. I'ts not likely the same
template pattern would be used with a different parent_class argument so I
suppose 2 different inline constructors should not be instantiated. Maybe
I'll pull some common code out of the constructors anyway as we are going to
have 4 versions.

> . I don't like this change:
>
> +    // add to module
> +    self& add(module &m)
> +    {
> +        // redundant
> +        // m.add(*this);
> +        return *this;
> +    }
> +
>
> Calling a.add(b) looks like it adds b to a, not the other way around.
> Should these add() functions really appear in the public interface of
> class_<>?
>
>
The act of instantiating a new module automatically adds itself (in the
constructor). I left this in accidently as it was there to support my own
old code! I'll remove it in the next batch of fixes.

> . Likewise for the rest of the changes to class.hpp
>
> . This change really worries me:
>
>      module& add(class_<T1,T2,T3,T4> const& c)
>      {
> -        this->add_class(c.object());
> +        // redundant
> +        // this->add_class(c.object());
>          return *this;
>      }
>
> You can't just comment stuff out and expect it to work... Perhaps you're
> just leaving this function in so that existing code will keep compiling in
> the short term? I could understand that.
>
Classes are automatically added (in the constructor) to the last module that
was declared, therefore this code is left in so as not to break existing
code (which could have only one module anyway).

> . Your code generators use large swaths of C++ code which gets stuffed
into
> source and header files, e.g. DeclFileHeader. Couldn't these just be
> written as C++ files which get #included in the result? Better yet, have
an
> outer file which #includes the generated and non-generated components.
>
Yes I know, initially there was only a line or two and then it grew...
I'll be removing the get_arg stuff which should cut it back a little.

> . What is your naming convention for the Python code? You have an odd
> combination of MixedCase and all_lower_case. There is a Python style guide
> somewhere...
>
I plan to tidy it up now it's basically functional. The origins of some of
the code were borrowed from something else I was working on, hence the mixed
style. I'm going to get rid of the capitalized items shortly.

Dave Hawkes






From pbienst at MIT.EDU  Wed Jul 17 17:03:29 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 17 Jul 2002 11:03:29 -0400
Subject: [C++-sig] from_python
Message-ID: <1026918209.17167.2.camel@hunsmac.mit.edu>

Hi,

I'm trying to upgrade a piece of code from a prehistoric version of BPL
V2 to the current CVS version:


namespace boost { namespace python { namespace converter { namespace {

struct cVector_from_python
{
  static unaryfunc* get_slot(PyObject* o)
  {
    return &py_object_identity;
  }
    
  static cVector extract(PyObject* o)
  {
    PyArrayObject* a 
      = (PyArrayObject*) PyArray_Cast((PyArrayObject*)o,
PyArray_CDOUBLE);

    if ( (a->nd != 1) || (a->dimensions[0] != int(global.N)) )
    {
      PyErr_SetString(PyExc_ValueError, "array has wrong dimensions.");
      throw boost::python::argument_error();
    }
  
    return cVector((Complex*) a->data,global.N,
                   blitz::neverDeleteData,fortranArray);
  }
};

}}}} // namespace boost::python::converter



After reading through the mailing lists and the docs
(boost/libs/python/doc/v2/from_python.html) I tried something like this:

#include <boost/python/from_python.hpp>

struct boost::python::from_python<cVector>
{

  from_python(PyObject*) {}

  bool convertible() const {return true;}
    
  cVector operator()(PyObject* o) const
  {
    PyArrayObject* a 
      = (PyArrayObject*) PyArray_Cast((PyArrayObject*)o,
PyArray_CDOUBLE);

    if ( (a->nd != 1) || (a->dimensions[0] != int(global.N)) )
    {
      PyErr_SetString(PyExc_ValueError, "array has wrong dimensions.");
      throw boost::python::argument_error();
    }
  
    return cVector((Complex*) a->data,global.N,
                   blitz::neverDeleteData,fortranArray);
  }

};


This doesn't even want to compile, because from_python.hpp doesn't seem
to exist.

Or should I wait a couple of days until extractors are implemented and
the dust has settled?

Cheers,

Peter







From david.abrahams at rcn.com  Wed Jul 17 17:07:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 11:07:28 -0400
Subject: [C++-sig] Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com>
Message-ID: <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com>

A few more points:

. Coding conventions - please try to follow the coding conventions
established throughout the rest of the codebase.
class_base::get_context_object() is an example of a function which does all
kinds of things differently. IOW, not this:

    if(expr) {
        ...
    }

but this, please:

    if (expr)
    {
        ...
    }

Also, this function is much too big, dense, and deeply-nested. Comment
lines should in general be preceded by a blank line. Many lines are too
long. I wouldn't make such a big deal about this one, but I know I
mentioned it as early as
http://aspn.activestate.com/ASPN/Mail/Message/1230478.

. What is going on with transfer_attributes()? I don't understand why it's
there, yet. Why didn't you make it accept type_handle arguments instead of
object? That would have made the code far simpler...

. Variable names like "r" for a type_handle don't say enough about its
purpose to help the reader.

I'm still reformatting and massageing this get_context_object() thing so I
can get a feel for what it's doing...

-Dave

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: "Dave Hawkes" <daveh at cadlink.com>
Cc: "pysig" <c++-sig at python.org>
Sent: Wednesday, July 17, 2002 8:53 AM
Subject: [C++-sig] Questions/Comments about new stuff


> Hi Dave,
>
> Thanks for checking in the new stuff. It's wicked cool! There are some
> things I want to tweak, and some others that I have questions about.
>
> . What's the point of this module_info class? It looks like it should be
a
> namespace. Not everything should be an object...
>
> . You have put get_module_info/set_module_info in the public interface of
> module_base, and thus in the public interface of module. Why? If it's
right
> (I hope it's not), then you need to move module_info out of the detail
> namespace...
>
> . get_prior_module really gets the current module, doesn't it? shouldn't
it
> be called module::current()?
>
> .  PRE_INIT_FUNC must be BOOST_PYTHON_PRE_INIT_FUNC, and it should be
> #undef'd when you're done with it. We also need to get our generated
> init_module_#xxx stuff into the unnamed namespace.
>
> . What is "get_class_context_object()"? I'm not fond of that name. I
think
> in Python that's called a name space. I would prefer renaming that
function
> "name_space()". If the handle<> can never be NULL, it should return
object
> instead.
>
> . submod_subclass_api.cpp should be renamed, since a subclass is not the
> same as a nested class ;-), and putting "api" in the name of a library
test
> is sorta redundant. How about "nested.cpp"?
>
> . It contains a comment which says it's called embed_test.cpp
>
> . It contains lots of macro definitions which are never used. These
should
> all be stripped out, as they harm readability. In this particular case,
the
> macros that do get used don't save any more text than the definition of
the
> macro cost, so they should be removed also.
>
> . I'm not happy with the name 'call_statement'. After all, you can pass
it
> more than one statement, and you're not calling anything. I'm not sure I
> have a better name for it yet, but what about eval()? I realize Python
has
> a different eval(), but I think it's got equivalent applications.
>
> . call_statement_du should be renamed to simply "call_statement".
> Overloading should work; if it doesn't we have a problem. In any case,
> abbrevs sch as du shld be avoid.
>
> . You kept get_arg<>, despite my challenges... OK, but you didn't respond
> to my questions about it either. I hope you understand, I have to either
be
> satisfied that it's the right choice, or rip it out. I guess the point is
> that you're saving an Py_INCREF()/Py_DECREF() pair for each object
passed?
> I'm still unconvinced it's worth it. Have you done any measurements? Note
> that the way you've written it, it won't work for classes such as list
> which are derived from object. I also don't understand why there's an
> object const* converter. I'm still very uncomfortable with this.
>
> . py_interface.hpp might be too big, IMO. People like to be able to
select
> how much stuff gets dragged into each translation unit by using
> high-granularity headers.
>
> . It's still using get_func("...") in function templates, which will
> generate too much code in extension modules. For example,
>
> BOOST_PYTHON_DECL object slice(object const& a0, object const& a1);
> BOOST_PYTHON_DECL object slice(int a0, int a1);
> template<class A0, class A1, class A2>
> object slice(A0 const& a0, A1 const& a1, A2 const& a2)
> {
>     return api_detail::get_func("slice")(api_detail::get_arg<A0>(a0),
> api_detail::get_arg<A1>(a1), api_detail::get_arg<A2>(a2));
> }
>
>
> That should be rewritten:
>
> BOOST_PYTHON_DECL object slice(object const& a0, object const& a1);
> BOOST_PYTHON_DECL object slice(int a0, int a1);
> template<class A0, class A1, class A2>
> object slice(A0 const& a0, A1 const& a1, A2 const& a2)
> {
>     return slice(api_detail::get_arg<A0>(a0).operator object const&()
>         , api_detail::get_arg<A1>(a1).operator object const&()
>         , api_detail::get_arg<A2>(a2).operator object const&());
> }
>
> . I don't like this change:
>
> -    class_();
> +     class_(base const& parent_class = empty_class_base());
> -    class_(char const* name);
> +    class_(char const* name, base const& parent_class =
> empty_class_base());
>
> a. Default arguments generally create more code than using overloads
> b. A class with no parent class doesn't have an empty class as its parent
> c. Parent is the wrong name -- should be "enclosing"
>
> . I don't like this change:
>
> +    // add to module
> +    self& add(module &m)
> +    {
> +        // redundant
> +        // m.add(*this);
> +        return *this;
> +    }
> +
>
> Calling a.add(b) looks like it adds b to a, not the other way around.
> Should these add() functions really appear in the public interface of
> class_<>?
>
>
> . Likewise for the rest of the changes to class.hpp
>
> . This change really worries me:
>
>      module& add(class_<T1,T2,T3,T4> const& c)
>      {
> -        this->add_class(c.object());
> +        // redundant
> +        // this->add_class(c.object());
>          return *this;
>      }
>
> You can't just comment stuff out and expect it to work... Perhaps you're
> just leaving this function in so that existing code will keep compiling
in
> the short term? I could understand that.
>
> . Your code generators use large swaths of C++ code which gets stuffed
into
> source and header files, e.g. DeclFileHeader. Couldn't these just be
> written as C++ files which get #included in the result? Better yet, have
an
> outer file which #includes the generated and non-generated components.
>
> . What is your naming convention for the Python code? You have an odd
> combination of MixedCase and all_lower_case. There is a Python style
guide
> somewhere...
>
> -Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From daveh at cadlink.com  Wed Jul 17 17:40:04 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 17 Jul 2002 11:40:04 -0400
Subject: [C++-sig] Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com>
Message-ID: <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: <c++-sig at python.org>; "Dave Hawkes" <daveh at cadlink.com>
Cc: "pysig" <c++-sig at python.org>
Sent: Wednesday, July 17, 2002 11:07 AM
Subject: Re: [C++-sig] Questions/Comments about new stuff


> A few more points:
>
> . Coding conventions - please try to follow the coding conventions
> established throughout the rest of the codebase.
> class_base::get_context_object() is an example of a function which does
all
> kinds of things differently. IOW, not this:
>
>     if(expr) {
>         ...
>     }
>
> but this, please:
>
>     if (expr)
>     {
>         ...
>     }
>
> Also, this function is much too big, dense, and deeply-nested. Comment
> lines should in general be preceded by a blank line. Many lines are too
> long. I wouldn't make such a big deal about this one, but I know I
> mentioned it as early as
> http://aspn.activestate.com/ASPN/Mail/Message/1230478.
>
Now that the API is in place I plan to revise this code as I should be able
to make it a little more compact. I'll tidy the style up at the same time. I
did revist the code since that discussion but it was difficult to pull out
many helper functions that would use the overall code apart from maybe a few
thing that would replicate what was being handle in the python API code.

> . What is going on with transfer_attributes()? I don't understand why it's
> there, yet. Why didn't you make it accept type_handle arguments instead of
> object? That would have made the code far simpler...
>
Again this can be reworked using the API code. This code is here so the
nesting order of classes doesn't impact their order of instantiation in the
module initialization.

> . Variable names like "r" for a type_handle don't say enough about its
> purpose to help the reader.
>
I think that one slipped through when I was changing a few other variable
names.

> I'm still reformatting and massageing this get_context_object() thing so I
> can get a feel for what it's doing...
>
It's still only around 30 lines of code excluding the comments and I may be
able to par it down further using the API code.

Dave Hawkes






From david.abrahams at rcn.com  Wed Jul 17 17:54:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 11:54:50 -0400
Subject: [C++-sig] Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com> <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com>
Message-ID: <04ca01c22daa$4de4dd90$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>

> > Also, this function is much too big, dense, and deeply-nested. Comment
> > lines should in general be preceded by a blank line. Many lines are too
> > long. I wouldn't make such a big deal about this one, but I know I
> > mentioned it as early as
> > http://aspn.activestate.com/ASPN/Mail/Message/1230478.
> >
> Now that the API is in place I plan to revise this code as I should be
able
> to make it a little more compact. I'll tidy the style up at the same
time. I
> did revist the code since that discussion but it was difficult to pull
out
> many helper functions that would use the overall code apart from maybe a
few
> thing that would replicate what was being handle in the python API code.
>
> > . What is going on with transfer_attributes()? I don't understand why
it's
> > there, yet. Why didn't you make it accept type_handle arguments instead
of
> > object? That would have made the code far simpler...
> >
> Again this can be reworked using the API code. This code is here so the
> nesting order of classes doesn't impact their order of instantiation in
the
> module initialization.

Well, I'm not even sure it works - witness the iterator crash I'm seeing.
Certainly this seems completely broken:

     current_object =
python::object(handle<>(boost::python::class_<empty_class>(full_name.c_str(
)).object()));

All instances of class_<T> refer to the same object for a given T. What
happens when you have multiple levels of nesting (c1.c2.c3...)?


> > . Variable names like "r" for a type_handle don't say enough about its
> > purpose to help the reader.
> >
> I think that one slipped through when I was changing a few other variable
> names.
>
> > I'm still reformatting and massageing this get_context_object() thing
so I
> > can get a feel for what it's doing...
> >
> It's still only around 30 lines of code excluding the comments and I may
be
> able to par it down further using the API code.

Don't touch anything for the time being. I'm going to fix it up to show you
how it should be done. Adding stuff like this (and especially
init_sub_module) to the codebase, even as a temporary measure to be cleaned
up later, is really unacceptable because it means that I can't maintain it
until it's cleaned up. Note that I don't even think you're able to maintain
code written in this style. If the code were less-dense, you would have not
missed "r", for example. Code has to go into the codebase with a tidy style
to start with, as much as possible.

-Dave






From daveh at cadlink.com  Wed Jul 17 18:51:52 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 17 Jul 2002 12:51:52 -0400
Subject: [C++-sig] Re: Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com> <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com> <04ca01c22daa$4de4dd90$6501a8c0@boostconsulting.com>
Message-ID: <ah47dq$28g$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:04ca01c22daa$4de4dd90$6501a8c0 at boostconsulting.com...
>
> Well, I'm not even sure it works - witness the iterator crash I'm seeing.
> Certainly this seems completely broken:
>
>      current_object =
>
python::object(handle<>(boost::python::class_<empty_class>(full_name.c_str(
> )).object()));
>

There is a dependancy in the current code that requires the module_info
outside of the scope of module initialization when a new class is created
later. At the time the code was written I didn't appreciate that a class was
going to be dynamically created. I can fix this if you wish?


> All instances of class_<T> refer to the same object for a given T. What
> happens when you have multiple levels of nesting (c1.c2.c3...)?
>

That's correct. The type_info should uniquely identify the c++ class
c1::c2::c3 from c3. The assumption I make is that someone won't take a
definition of c1:c2:c3 and define it simultaneously as both c1.c2.c3 and c3
in python.

>
> > able to par it down further using the API code.
>
> Don't touch anything for the time being. I'm going to fix it up to show
you
> how it should be done. Adding stuff like this (and especially
> init_sub_module) to the codebase, even as a temporary measure to be
cleaned
> up later, is really unacceptable because it means that I can't maintain it
> until it's cleaned up. Note that I don't even think you're able to
maintain
> code written in this style. If the code were less-dense, you would have
not
> missed "r", for example. Code has to go into the codebase with a tidy
style
> to start with, as much as possible.
>
I think there's only a couple of major areas that need cleaning up.
Unfortunately the init_sub_module and class_context stuff was written before
the API code, I knew these could probably be simplified when that was
completed.

Dave Hawkes









From david.abrahams at rcn.com  Wed Jul 17 19:32:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 13:32:20 -0400
Subject: [C++-sig] Re: Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com> <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com> <04ca01c22daa$4de4dd90$6501a8c0@boostconsulting.com> <ah47dq$28g$1@main.gmane.org>
Message-ID: <050301c22db7$f012e370$6501a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:04ca01c22daa$4de4dd90$6501a8c0 at boostconsulting.com...
> >
> > Well, I'm not even sure it works - witness the iterator crash I'm
seeing.
> > Certainly this seems completely broken:
> >
> >      current_object =
> >
>
python::object(handle<>(boost::python::class_<empty_class>(full_name.c_str(
> > )).object()));
> >
>
> There is a dependancy in the current code that requires the module_info
> outside of the scope of module initialization when a new class is created
> later. At the time the code was written I didn't appreciate that a class
was
> going to be dynamically created. I can fix this if you wish?

This is not a trivial problem.

> > All instances of class_<T> refer to the same object for a given T. What
> > happens when you have multiple levels of nesting (c1.c2.c3...)?
> >
>
> That's correct. The type_info should uniquely identify the c++ class
> c1::c2::c3 from c3. The assumption I make is that someone won't take a
> definition of c1:c2:c3 and define it simultaneously as both c1.c2.c3 and
c3
> in python.

You're misunderstanding the nature of the problem. Each time you mention
class_<empty_class> it accesses the very same Python object. It doesn't
matter what name you pass. I don't believe it's particularly useful to
allow nested classes to be registered before their enclosures are
registered, and I'm pretty sure it's not possible without a major
architecture change.

> >
> > > able to par it down further using the API code.
> >
> > Don't touch anything for the time being. I'm going to fix it up to show
> you
> > how it should be done. Adding stuff like this (and especially
> > init_sub_module) to the codebase, even as a temporary measure to be
> cleaned
> > up later, is really unacceptable because it means that I can't maintain
it
> > until it's cleaned up. Note that I don't even think you're able to
> maintain
> > code written in this style. If the code were less-dense, you would have
> not
> > missed "r", for example. Code has to go into the codebase with a tidy
> style
> > to start with, as much as possible.
>
> I think there's only a couple of major areas that need cleaning up.

I disagree. I've spent all morning deciphering, massageing, and debugging
this code. The iterator test is still broken, and things have become quite
tangled. Unfortunately, I can't afford to have the codebase in this
condition while you clean things up -- it impacts the other users, too. I'm
going to roll back your changes, but I hope that you'll add it again on a
branch, so that we can work together to merge it into the main trunk in a
controlled way.

-Dave






From david.abrahams at rcn.com  Wed Jul 17 21:09:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 15:09:01 -0400
Subject: [C++-sig] Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com> <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com>
Message-ID: <05fb01c22dc5$fbd0fd60$6501a8c0@boostconsulting.com>

Some further hints about this piece of code:

1. I'm reluctant to include too much use of std::string since we have
direct access to Python strings in this library.

2. std::strchr() et. al are great for iterating through a dotted name

3. Pulling the real work out of the loop and using "am I at the last name"
as a termination condition helps a lot

4. Tests like:

    if (XXX)
    {
        if (YYY)
        {
            if (ZZZ)
            {
                ...
            }
        }
    }

are easier to read as:

    if (XXX
        && YYY
        && ZZZ
    )
    {
        ...
    }

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>

> > A few more points:
> >
> > . Coding conventions - please try to follow the coding conventions
> > established throughout the rest of the codebase.
> > class_base::get_context_object() is an example of a function which does
> all
> > kinds of things differently. IOW, not this:
> >
> >     if(expr) {
> >         ...
> >     }
> >
> > but this, please:
> >
> >     if (expr)
> >     {
> >         ...
> >     }
> >
> > Also, this function is much too big, dense, and deeply-nested. Comment
> > lines should in general be preceded by a blank line. Many lines are too
> > long. I wouldn't make such a big deal about this one, but I know I
> > mentioned it as early as
> > http://aspn.activestate.com/ASPN/Mail/Message/1230478.
> >
> Now that the API is in place I plan to revise this code as I should be
able
> to make it a little more compact. I'll tidy the style up at the same
time. I
> did revist the code since that discussion but it was difficult to pull
out
> many helper functions that would use the overall code apart from maybe a
few
> thing that would replicate what was being handle in the python API code.

> > . Variable names like "r" for a type_handle don't say enough about its
> > purpose to help the reader.
> >
> I think that one slipped through when I was changing a few other variable
> names.
>
> > I'm still reformatting and massageing this get_context_object() thing
so I
> > can get a feel for what it's doing...
> >
> It's still only around 30 lines of code excluding the comments and I may
be
> able to par it down further using the API code.







From daveh at cadlink.com  Wed Jul 17 22:11:01 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 17 Jul 2002 16:11:01 -0400
Subject: [C++-sig] Re: Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com> <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com> <04ca01c22daa$4de4dd90$6501a8c0@boostconsulting.com> <ah47dq$28g$1@main.gmane.org> <050301c22db7$f012e370$6501a8c0@boostconsulting.com>
Message-ID: <007701c22dce$19d02720$4110a8c0@ottawa.cadlink.com>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: <c++-sig at python.org>
Cc: "Dave Hawkes" <daveh at cadlink.com>
Sent: Wednesday, July 17, 2002 1:32 PM
Subject: Re: [C++-sig] Re: Questions/Comments about new stuff


> was
> > going to be dynamically created. I can fix this if you wish?
>
> This is not a trivial problem.
>
It shouldn't be too much of a problem as it doesn't actually need access at
this point. In fact changing the class_ constructors as mentioned in a
recent post will be the easiest way of fixing the problem!

> > > All instances of class_<T> refer to the same object for a given T.
What
> > > happens when you have multiple levels of nesting (c1.c2.c3...)?
> > >
> >
> > That's correct. The type_info should uniquely identify the c++ class
> > c1::c2::c3 from c3. The assumption I make is that someone won't take a
> > definition of c1:c2:c3 and define it simultaneously as both c1.c2.c3 and
> c3
> > in python.
>
> You're misunderstanding the nature of the problem. Each time you mention
> class_<empty_class> it accesses the very same Python object. It doesn't
> matter what name you pass. I don't believe it's particularly useful to
> allow nested classes to be registered before their enclosures are
> registered, and I'm pretty sure it's not possible without a major
> architecture change.
>
That's how it's meant to work! The part your missing is that when the real
c++ class is defined the the empty class is ripped out and replaced with it.
What this means is that all undefined classes are the same empty place
holder until the real class is registered.

> >
> > I think there's only a couple of major areas that need cleaning up.
>
> I disagree. I've spent all morning deciphering, massageing, and debugging
> this code. The iterator test is still broken, and things have become quite
> tangled. Unfortunately, I can't afford to have the codebase in this
> condition while you clean things up -- it impacts the other users, too.
I'm
> going to roll back your changes, but I hope that you'll add it again on a
> branch, so that we can work together to merge it into the main trunk in a
> controlled way.
>
The iterator is easily fixed. I think the major problem is that I should of
perhaps provided more details about how it works before posting the code so
that you would have more confidence in it.

Dave Hawkes






From daveh at cadlink.com  Thu Jul 18 03:11:31 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 17 Jul 2002 21:11:31 -0400
Subject: [C++-sig] Questions/Comments about new stuff
References: <03b601c22d91$06f9b090$6501a8c0@boostconsulting.com> <04b101c22da3$e5be5350$6501a8c0@boostconsulting.com> <004a01c22da8$3f466990$4110a8c0@ottawa.cadlink.com> <05fb01c22dc5$fbd0fd60$6501a8c0@boostconsulting.com>
Message-ID: <005a01c22df8$0d9568b0$3e08a8c0@davehh>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: "Dave Hawkes" <daveh at cadlink.com>; "pysig" <c++-sig at python.org>
Sent: Wednesday, July 17, 2002 3:09 PM
Subject: Re: [C++-sig] Questions/Comments about new stuff


> Some further hints about this piece of code:
>
> 1. I'm reluctant to include too much use of std::string since we have
> direct access to Python strings in this library.
>
At the time I don't think I could use all the string methods I needed such
as searching.

> 2. std::strchr() et. al are great for iterating through a dotted name
>
> 3. Pulling the real work out of the loop and using "am I at the last name"
> as a termination condition helps a lot
>
> 4. Tests like:
>
>     if (XXX)
>     {
>         if (YYY)
>         {
>             if (ZZZ)
>             {
>                 ...
>             }
>         }
>     }
>
> are easier to read as:
>
>     if (XXX
>         && YYY
>         && ZZZ
>     )
>     {
>         ...
>     }
>
I'll take a look at how I can use any of these when I rework it.

Dave Hawkes






From david.abrahams at rcn.com  Thu Jul 18 18:01:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Jul 2002 12:01:57 -0400
Subject: [C++-sig] str, dict, tuple
Message-ID: <09fe01c22e74$7b1e69f0$6501a8c0@boostconsulting.com>

I have integrated Achim's str, dict, and tuple support into Boost.Python
v2. Thanks, Achim!

A few things had to change:

1. You were relying on implicit conversion from, e.g., object->list.
However, since list's templated constructor is explicit, that didn't
compile on many compilers.

2. Writing converter specializations for these types is much simpler now;
you just need to specialize object_manager_traits<>, so lots of code went
away.

3. return types of some str functions (encode, decode, count) were wrong.
It would be a good idea to enhance your regression tests so that they would
fail with the old code but succeed with the new code.

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 gideon at computer.org  Thu Jul 18 16:46:30 2002
From: gideon at computer.org (gideon may)
Date: Thu, 18 Jul 2002 10:46:30 -0400
Subject: [C++-sig] Question regarding protected destructor
Message-ID: <2776993.1026989190@[172.20.247.181]>

Hi,

I have a class in a library with a protected destructor which
would like to wrap. Basically it looks like :

class Test {
    public:
        Test() {}
    protected:
        ~Test() {}
};

When I try to create  a python module with the following :

    boost::python::module pyOSG("pyOSG");
    pyOSG.add(class_<Test>("Test").def_init(args<>()));


I get the following error with VC7:

C:\cvs_rep\boost\boost\boost\python\object\value_holder.hpp(41) : warning 
C4624: 'boost::python::objects::value_holder<Held>' :
destructor could not be generated because a base class destructor is 
inaccessible

Is there any way to solve this ?

thanks,

gideon




From david.abrahams at rcn.com  Thu Jul 18 17:11:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Jul 2002 11:11:57 -0400
Subject: [C++-sig] from_python (repost)
References: <1026918209.17167.2.camel@hunsmac.mit.edu>
Message-ID: <09ad01c22e6d$7865ddd0$6501a8c0@boostconsulting.com>

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

> I'm trying to upgrade a piece of code from a prehistoric version of BPL
> V2 to the current CVS version:
>
> namespace boost { namespace python { namespace converter { namespace {

Hmm, you probably shouldn't have been adding anything to the boost
namespace...

> struct cVector_from_python
> {
>   static unaryfunc* get_slot(PyObject* o)
>   {
>     return &py_object_identity;
>   }
>
>   static cVector extract(PyObject* o)
>   {
>     PyArrayObject* a
>       = (PyArrayObject*) PyArray_Cast((PyArrayObject*)o,
> PyArray_CDOUBLE);
>
>     if ( (a->nd != 1) || (a->dimensions[0] != int(global.N)) )
>     {
>       PyErr_SetString(PyExc_ValueError, "array has wrong dimensions.");
>       throw boost::python::argument_error();
>     }
>
>     return cVector((Complex*) a->data,global.N,
>                    blitz::neverDeleteData,fortranArray);
>   }
> };


This looks like an attempt to use the internal slot_rvalue_from_python
converter generator. That's usually not worth it for types where the
get_slot function returns the identity function. That means you're
basically willing to accept anything for overload resolution.

I suggest you back up and look at this thread:
http://aspn.activestate.com/ASPN/Mail/Message/1227504

The basic challenge of building a new rvalue from_python converter is to
come up with two functions with the following signatures:

// Used in overload resolution. A return value of 0 indicates that
conversion
// failed and overload resolution should proceed with other functions and
argument
// converters.
void* convertible(PyObject* source);

// Used once overload resolution has selected this converter; builds the
C++ value.
// On entry, data.convertible will be the result of calling convertible(),
above.
// This function is expected to build a new value of the C++ target type T
in
// ((rvalue_from_python_data<T>*)data)->storage.bytes using placement new.
If
// successful, it should set data->convertible to point at the
newly-constructed
// object.
void constructor(PyObject* source, rvalue_from_python_stage1_data* data);

These need to be registered with:

    python::converter::registry::insert(convertible, constructor,
type_id<T>())

Also see the comment at the top of
boost/python/converter/rvalue_from_python_data.hpp for more details.

Your convertible function should be checking that the source object can be
converted to a cVector(preferably without creating a new Python object),
and your construct function should build it.

Note that used as an argument converter for functions of more than 1
argument, the fact that convertible returns non-zero doesn't mean that
construct() will be called, since overload resolution can still fail for
other arguments. Thus, convertible() cannot allocate memory to be reclaimed
by construct(). Note also that your code leaks a PyArrayObject.

> After reading through the mailing lists and the docs
> (boost/libs/python/doc/v2/from_python.html) I tried something like this:

That part of the doc is obsolete and will be fixed up soon. That header is
called arg_from_python.hpp now, but it shouldn't even be exposed to users
IMO since it's not the right place for user customizations nor is it the
best mechanism to use for extraction. A specialization of arg_from_python
could work for argument conversions if you can guarantee that all needed
wrapping code "sees" your specialization, but it won't work for, e.g.,
extract<>, or call<>(...), which use a different set of templates to
convert results from python.

> Or should I wait a couple of days until extractors are implemented and
> the dust has settled?

I don't think extractors can help you here, since they *use* the registered
converters which I discussed above.

HTH,
Dave







From david.abrahams at rcn.com  Thu Jul 18 15:14:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Jul 2002 09:14:32 -0400
Subject: [C++-sig] from_python
References: <1026918209.17167.2.camel@hunsmac.mit.edu>
Message-ID: <093701c22e5d$5387cc40$6501a8c0@boostconsulting.com>

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

> I'm trying to upgrade a piece of code from a prehistoric version of BPL
> V2 to the current CVS version:
>
> namespace boost { namespace python { namespace converter { namespace {

Hmm, you probably shouldn't have been adding anything to the boost
namespace...

> struct cVector_from_python
> {
>   static unaryfunc* get_slot(PyObject* o)
>   {
>     return &py_object_identity;
>   }
>
>   static cVector extract(PyObject* o)
>   {
>     PyArrayObject* a
>       = (PyArrayObject*) PyArray_Cast((PyArrayObject*)o,
> PyArray_CDOUBLE);
>
>     if ( (a->nd != 1) || (a->dimensions[0] != int(global.N)) )
>     {
>       PyErr_SetString(PyExc_ValueError, "array has wrong dimensions.");
>       throw boost::python::argument_error();
>     }
>
>     return cVector((Complex*) a->data,global.N,
>                    blitz::neverDeleteData,fortranArray);
>   }
> };


This looks like an attempt to use the internal slot_rvalue_from_python
converter generator. That's usually not worth it for types where the
get_slot function returns the identity function. That means you're
basically willing to accept anything for overload resolution.

I suggest you back up and look at this thread:
http://aspn.activestate.com/ASPN/Mail/Message/1227504

The basic challenge of building a new rvalue from_python converter is to
come up with two functions with the following signatures:

// Used in overload resolution. A return value of 0 indicates that
conversion
// failed and overload resolution should proceed with other functions and
argument
// converters.
void* convertible(PyObject* source);

// Used once overload resolution has selected this converter; builds the
C++ value.
// On entry, data.convertible will be the result of calling convertible(),
above.
// This function is expected to build a new value of the C++ target type T
in
// ((rvalue_from_python_data<T>*)data)->storage.bytes using placement new.
If
// successful, it should set data->convertible to point at the
newly-constructed
// object.
void constructor(PyObject* source, rvalue_from_python_stage1_data* data);

These need to be registered with:

    python::converter::registry::insert(convertible, constructor,
type_id<T>())

Also see the comment at the top of
boost/python/converter/rvalue_from_python_data.hpp for more details.

Your convertible function should be checking that the source object can be
converted to a cVector(preferably without creating a new Python object),
and your construct function should build it.

Note that used as an argument converter for functions of more than 1
argument, the fact that convertible returns non-zero doesn't mean that
construct() will be called, since overload resolution can still fail for
other arguments. Thus, convertible() cannot allocate memory to be reclaimed
by construct(). Note also that your code leaks a PyArrayObject.

> After reading through the mailing lists and the docs
> (boost/libs/python/doc/v2/from_python.html) I tried something like this:

That part of the doc is obsolete and will be fixed up soon. That header is
called arg_from_python.hpp now, but it shouldn't even be exposed to users
IMO since it's not the right place for user customizations nor is it the
best mechanism to use for extraction. A specialization of arg_from_python
could work for argument conversions if you can guarantee that all needed
wrapping code "sees" your specialization, but it won't work for, e.g.,
extract<>, or call<>(...), which use a different set of templates to
convert results from python.

> Or should I wait a couple of days until extractors are implemented and
> the dust has settled?

I don't think extractors can help you here, since they *use* the registered
converters which I discussed above.

HTH,
Dave






From david.abrahams at rcn.com  Thu Jul 18 04:50:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Jul 2002 22:50:40 -0400
Subject: [C++-sig] Fw: Achim's posting
Message-ID: <07c701c22e05$e7c7f270$6501a8c0@boostconsulting.com>

Hi Achim,

Ralf very kindly nudged me about your contribution. I'm just swamped at the
moment and intend to look at it ASAP (tomorrow). Sorry for the delay,

Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at cci.lbl.gov>
To: <david.abrahams at rcn.com>
Cc: <rwgk at boa.lbl.gov>
Sent: Wednesday, July 17, 2002 9:26 PM
Subject: Achim's posting


> Hi David, just in case this got lost in the turmoil generated by David
> Hawkes: I noticed that you did not respond to Achim's posting, which he
> might find discouraging.
> Ralf
> http://mail.python.org/pipermail/c++-sig/2002-July/001735.html
>





From david.abrahams at rcn.com  Thu Jul 18 07:10:52 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Jul 2002 01:10:52 -0400
Subject: [C++-sig] Finally!
Message-ID: <083a01c22e19$7eceb010$6501a8c0@boostconsulting.com>

Extract support is implemented. Please see
libs/python/test/extract.[cpp/py] for example usage.

-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  Thu Jul 18 20:23:50 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 18 Jul 2002 14:23:50 -0400
Subject: [C++-sig] from_python
In-Reply-To: <093701c22e5d$5387cc40$6501a8c0@boostconsulting.com>
References: <1026918209.17167.2.camel@hunsmac.mit.edu> 
	<093701c22e5d$5387cc40$6501a8c0@boostconsulting.com>
Message-ID: <1027016630.18163.11.camel@hunsmac.mit.edu>

> Note that used as an argument converter for functions of more than 1
> argument, the fact that convertible returns non-zero doesn't mean that
> construct() will be called, since overload resolution can still fail
for
> other arguments. Thus, convertible() cannot allocate memory to be
reclaimed
> by construct(). Note also that your code leaks a PyArrayObject.

OK, now I'm doing the following. This seems to work and also gets rid of
the leak, I think.

I did however have to modify converter::rvalue_base_data to
converter::rvalue_from_python_storage to get it to compile.

Thanks!

Peter

struct register_cVector_from_python
{

  register_cVector_from_python()
  {
    boost::python::converter::registry::insert
      (&convertible, &construct, boost::python::type_id<cVector>());
  }

  static void* convertible(PyObject* o)
  {
    if (!PyArray_Check(o))
      return NULL;

    PyArrayObject* a = (PyArrayObject*)(o);
    if ( (a->nd != 1) || (a->dimensions[0] != int(global.N)) )
      return NULL;

    return o;
  }
    
    
  static void construct
    (PyObject* o,
boost::python::converter::rvalue_from_python_stage1_data* 
     data)
  {
    PyArrayObject* a 
      = (PyArrayObject*) PyArray_Cast((PyArrayObject*)o,
PyArray_CDOUBLE);

    cVector c((Complex*)
a->data,global.N,blitz::duplicateData,fortranArray);

    void* storage = ((
     
boost::python::converter::rvalue_from_python_storage<cVector>*)data)
        ->storage.bytes;

    new (storage) cVector((Complex*) a->data, global.N, 
                          blitz::duplicateData, fortranArray);

    data->convertible = storage;

    delete a;
  }

};






From John.Zubeck at pci-cc.com  Thu Jul 18 21:43:29 2002
From: John.Zubeck at pci-cc.com (John Zubeck)
Date: Thu, 18 Jul 2002 15:43:29 -0400
Subject: [C++-sig] RE:Why develop in Python
Message-ID: <E8EF025FDC85D511A8140060083175415B120A@private.crosslink.net>


Hi!

I'm new to the Python environment and I wondered
if someone answer some questions about Python's mission.

(1) Is Python's main goal to provide a clearer
    and simpler subset of C?
(2) Does Python eliminate programming with pointers?
(3) Does Python do OO?
(4) C and C++ are supposed to be platform portable,
    but, of course, shifting platforms does take some
    work ... is Python really platform independent?

John Zubeck
Planning Consultants Inc.
Sr. Software Architect
703-416-8387 x278


-----Original Message-----
From: David Abrahams [mailto:david.abrahams at rcn.com]
Sent: Thursday, July 18, 2002 1:11 AM
To: pysig
Subject: [C++-sig] Finally!


Extract support is implemented. Please see
libs/python/test/extract.[cpp/py] for example usage.

-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
+---------------------------------------------------------------+



_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020718/abdce5a7/attachment.htm>

From david.abrahams at rcn.com  Thu Jul 18 23:42:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Jul 2002 17:42:05 -0400
Subject: [C++-sig] Question regarding protected destructor
References: <2776993.1026989190@[172.20.247.181]>
Message-ID: <0b3801c22ea3$f839f510$6501a8c0@boostconsulting.com>

From: "gideon may" <gideon at computer.org>


> Hi,
>
> I have a class in a library with a protected destructor which
> would like to wrap. Basically it looks like :
>
> class Test {
>     public:
>         Test() {}
>     protected:
>         ~Test() {}
> };
>
> When I try to create  a python module with the following :
>
>     boost::python::module pyOSG("pyOSG");
>     pyOSG.add(class_<Test>("Test").def_init(args<>()));
>
>
> I get the following error with VC7:
>
> C:\cvs_rep\boost\boost\boost\python\object\value_holder.hpp(41) : warning
> C4624: 'boost::python::objects::value_holder<Held>' :
> destructor could not be generated because a base class destructor is
> inaccessible
>
> Is there any way to solve this ?

There are all kinds of ways. You could change the library source code, for
example.
However, the presence of a protected destructor is a sure sign that the
author of the class didn't want you to create instances of Test directly.
If you want to expose Test to Python as an abstract base class, you could
try exposing a class derived from Test using the HeldType parameter
described at www.boost.org/libs/python/doc/v2/class.html#class_-spec...

HTH,
-Dave






From gideon at computer.org  Fri Jul 19 00:02:11 2002
From: gideon at computer.org (gideon may)
Date: Thu, 18 Jul 2002 18:02:11 -0400
Subject: [C++-sig] Question regarding protected destructor
In-Reply-To: <0b3801c22ea3$f839f510$6501a8c0@boostconsulting.com>
References: <0b3801c22ea3$f839f510$6501a8c0@boostconsulting.com>
Message-ID: <24059525.1027015330@[172.20.247.181]>

Hi Dave,


>> Hi,
>>
>> I have a class in a library with a protected destructor which
>> would like to wrap. Basically it looks like :
>>
>> class Test {
>>     public:
>>         Test() {}
>>     protected:
>>         ~Test() {}
>> };
>>
>> When I try to create  a python module with the following :
>>
>>     boost::python::module pyOSG("pyOSG");
>>     pyOSG.add(class_<Test>("Test").def_init(args<>()));
>>
>>
>> I get the following error with VC7:
>>
>> C:\cvs_rep\boost\boost\boost\python\object\value_holder.hpp(41) : warning
>> C4624: 'boost::python::objects::value_holder<Held>' :
>> destructor could not be generated because a base class destructor is
>> inaccessible
>>
>> Is there any way to solve this ?
>
> There are all kinds of ways. You could change the library source code, for
> example.
> However, the presence of a protected destructor is a sure sign that the
> author of the class didn't want you to create instances of Test directly.
> If you want to expose Test to Python as an abstract base class, you could
> try exposing a class derived from Test using the HeldType parameter
> described at www.boost.org/libs/python/doc/v2/class.html#class_-spec...
>

Unfortunately I'm unable to change the code, it's a library which is in 
constant
flux. All the class(es) destructors are protected since it has it's own 
reference
counting and memory management. I looked into the HeldType but I'm not sure 
it
is of any help to me. The classes I would like to use with boost are part 
of
a large class hierarchy, each of them derived from a base class with the
protected destructor. The library which I am trying to wrap is the
OpenSceneGraph (http://www.openscenegraph.org/).

ciao,

gideon





From david.abrahams at rcn.com  Fri Jul 19 00:17:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Jul 2002 18:17:27 -0400
Subject: [C++-sig] Question regarding protected destructor
References: <0b3801c22ea3$f839f510$6501a8c0@boostconsulting.com> <24059525.1027015330@[172.20.247.181]>
Message-ID: <0b6d01c22ea8$e8493350$6501a8c0@boostconsulting.com>

From: "gideon may" <gideon at computer.org>

> Unfortunately I'm unable to change the code, it's a library which is in
> constant
> flux. All the class(es) destructors are protected since it has it's own
> reference
> counting and memory management.

Oh! in that case...

> I looked into the HeldType but I'm not sure
> it is of any help to me.

Yes, it should be! You need to make a smart pointer class (template) which
you can use as HeldType.

> The classes I would like to use with boost are part
> of
> a large class hierarchy, each of them derived from a base class with the
> protected destructor. The library which I am trying to wrap is the
> OpenSceneGraph (http://www.openscenegraph.org/).

If you supply a smart pointer template, say, "scene_graph_ptr<T>", which
does the reference-counting, you can pass that as HeldType. The only other
requirement is that you supply a nested typedef in your smart pointer:

    typedef T element_type;

so that pointee<T> knows what type it's pointing at.

Now you can wrap functions which accept T cv*, T cv&, and
scene_graph_ptr<T> arguments.

HTH,
Dave






From vraghavan at cnmnetwork.com  Fri Jul 19 04:14:55 2002
From: vraghavan at cnmnetwork.com (Srivatsan Raghavan)
Date: Thu, 18 Jul 2002 19:14:55 -0700
Subject: [C++-sig] usable state of boost::python v2 ?
Message-ID: <3D37761F.90702@cnmnetwork.com>

hello everyone..
i've just started a project at work using boost::python v1 (i've posted 
a few questions on
this on the boost-users list)
and i was wondering about the status of v2 and it's usability?
i've only just started the project so i've not yet written much code so 
if v2 is near completion, or has significant feature changes, or would 
make my job easier i'd be willing to convert now ..
but the docs i've found are obviously sparse currently..
--vat






From david.abrahams at rcn.com  Fri Jul 19 14:47:52 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 08:47:52 -0400
Subject: [C++-sig] usable state of boost::python v2 ?
References: <3D37761F.90702@cnmnetwork.com>
Message-ID: <0cc701c22f22$acccc650$6501a8c0@boostconsulting.com>

From: "Srivatsan Raghavan" <vraghavan at cnmnetwork.com>


> hello everyone..
> i've just started a project at work using boost::python v1 (i've posted
> a few questions on
> this on the boost-users list)
> and i was wondering about the status of v2 and it's usability?

A number of people are already using it in significant projects. It's very
close to being released, in fact.

> i've only just started the project so i've not yet written much code so
> if v2 is near completion, or has significant feature changes,

Both of those are true.

> or would
> make my job easier i'd be willing to convert now ..

I would recommend it.

> but the docs i've found are obviously sparse currently..

That's one of the things that needs to be handled before v2 can be
released. We have lots of reference documentation (though it's not complete
yet), but no tutorial docs.

Getting started instructions are at:
http://mail.python.org/pipermail/c++-sig/2002-May/001100.html

HTH,
Dave






From david.abrahams at rcn.com  Fri Jul 19 15:14:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 09:14:55 -0400
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <3D0D8C36.8030704@vintech.bg> <001701c215e2$6606a960$6601a8c0@boostconsulting.com> <3D0DB4F5.6000901@vintech.bg>
Message-ID: <0cd601c22f26$4a3f2470$6501a8c0@boostconsulting.com>

Hi,

Now that I'm revisiting this issue for my June monthly report, I'm not sure
that using the name for an inline member function "_" with one argument
would actually cause any problems in real code. AFAICT, the result would be
that the member function would be silently renamed "gettext" in the common
case... and all uses of the function will also be silently renamed to call
x.gettext(...). Yes, technically this gives an ODR violation if the file is
included with and without the macro defined, but I know of no real
compilers which will care about that.

Am I missing something here?

-Dave

----- Original Message -----
From: "Niki Spahiev" <niki at vintech.bg>
To: <c++-sig at python.org>
Sent: Monday, June 17, 2002 6:07 AM
Subject: Re: [C++-sig] Boost.Python v2: beginning of generalized object
support


> David Abrahams wrote:
> > From: "Niki Spahiev" <niki at vintech.bg>
> >
> >
> >>David Abrahams wrote:
> >>
> >>>object attribute access is available through the "_" member function:
> >>>
> >>>C++                    Python
> >>>
> >>>x._("foo") = 1;        x.foo = 1
> >>>y = x._("foo");        y = x.foo
> >>
> >>This will go into GNU gettext translation dictionary.
> >
> >
> > What is that?
>
> http://www.gnu.org/software/gettext/gettext.html
>
> >>_("...") is  default marker for gettext. Can boost.python use something
> >
> > other?
> >
> > I'm not sure. What problems could this cause?
>
> All attribute names will go to translatable strings (for UI).
>
> Why not:
>
> x.a("foo") = 1
> y = x.a("foo")
>
> or any other letter?
>
> regards,
> Niki Spahiev
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From niki at vintech.bg  Fri Jul 19 15:39:44 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Fri, 19 Jul 2002 16:39:44 +0300
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <3D0D8C36.8030704@vintech.bg> <001701c215e2$6606a960$6601a8c0@boostconsulting.com> <3D0DB4F5.6000901@vintech.bg> <0cd601c22f26$4a3f2470$6501a8c0@boostconsulting.com>
Message-ID: <3D3816A0.2030201@vintech.bg>

David Abrahams wrote:
> Hi,
> 
> Now that I'm revisiting this issue for my June monthly report, I'm not sure
> that using the name for an inline member function "_" with one argument
> would actually cause any problems in real code. AFAICT, the result would be
> that the member function would be silently renamed "gettext" in the common
> case... and all uses of the function will also be silently renamed to call
> x.gettext(...). Yes, technically this gives an ODR violation if the file is
> included with and without the macro defined, but I know of no real
> compilers which will care about that.
> 
> Am I missing something here?


obj._("test") will include string "test" for translation (i18n)

Niki Spahiev





From david.abrahams at rcn.com  Fri Jul 19 15:41:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 09:41:02 -0400
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <3D0D8C36.8030704@vintech.bg> <001701c215e2$6606a960$6601a8c0@boostconsulting.com> <3D0DB4F5.6000901@vintech.bg> <0cd601c22f26$4a3f2470$6501a8c0@boostconsulting.com> <3D3816A0.2030201@vintech.bg>
Message-ID: <0d0001c22f29$ed10eff0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Niki Spahiev" <niki at vintech.bg>
To: <c++-sig at python.org>
Sent: Friday, July 19, 2002 9:39 AM
Subject: Re: [C++-sig] Boost.Python v2: beginning of generalized object
support


> David Abrahams wrote:
> > Hi,
> >
> > Now that I'm revisiting this issue for my June monthly report, I'm not
sure
> > that using the name for an inline member function "_" with one argument
> > would actually cause any problems in real code. AFAICT, the result
would be
> > that the member function would be silently renamed "gettext" in the
common
> > case... and all uses of the function will also be silently renamed to
call
> > x.gettext(...). Yes, technically this gives an ODR violation if the
file is
> > included with and without the macro defined, but I know of no real
> > compilers which will care about that.
> >
> > Am I missing something here?
>
>
> obj._("test") will include string "test" for translation (i18n)

How? What is the mechanism that causes it to happen?
I don't see how

    #define _(x) gettext(x)

can cause it.

-Dave





From pbienst at MIT.EDU  Fri Jul 19 16:33:19 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 19 Jul 2002 10:33:19 -0400
Subject: [C++-sig] V2: wrapping globals?
Message-ID: <1027089199.19917.4.camel@hunsmac.mit.edu>

Hi,

Is there already functionality equivalent to the V1 make_ref in V2 to
wrap global variables and constants?

Incidentally, this would also be a nice workaround for the current lack
of enum support...

Cheers,

Peter






From hoel at germanlloyd.org  Fri Jul 19 16:43:50 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 19 Jul 2002 16:43:50 +0200
Subject: [C++-sig] Re: Hnadling Python exceptions in C++
In-Reply-To: <03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com>
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de><03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com>
Message-ID: <septxj22xl.fsf@pc970145.GermanLloyd.de>

"David Abrahams" <david.abrahams at rcn.com> writes:

> In Boost.Python v1, there's no special facility. You can use the
regular
> Python 'C' API, of course. We are planning some support in
Boost.Python v2.
> I'd like to try to serve your needs; what kind of facilities did you
have
> in mind?
> 
> Thanks,
> Dave
> 
> > ----- Original Message -----
> > From: "Berthold Hllmann" <hoel at germanlloyd.org>
> > Hello,
> > 
> > Is there any code for handling Python exceptions in C++? I only
found
> > report_ignored_exception in classes.cpp, but it's in anonymous
> > namespace and though inaccessable in my code.
> > 
> > Greetings
> > 
> > Berthold

OK, after thinking a bit about such a facility here is my idea. It
would be nice to have a C++ exception class that reads out PyErr_Fetch
when instantiated and can be converted back into a Python exception if
needed. I tried to start an implementation. The attached code is
untested, it is just posted to share the idea.

except.hpp:
--8<------------------------schnipp------------------------->8---
#ifndef EXCEPT_BH20020719_H_
#define EXCEPT_BH20020719_H_

#include <Python.h>
#include <string>

namespace boost {
  namespace python {
    namespace Error {
      class PyErrHandler {
      public:
	PyErrHandler();
	virtual void printOn(std::ostream&) const;
      private:
	PyObject *stype, *svalue, *straceback;
      };
      std::ostream& operator<<(std::ostream& os,
			       const PyErrHandler& el);
    }
  }
}

#endif // EXCEPT_BH20020719_H_
--8<------------------------schnapp------------------------->8---

and except.cpp
--8<------------------------schnipp------------------------->8---
#include <iostream>
#include "except.hpp"

boost::python::Error::PyErrHandler::PyErrHandler()
{
  PyObject *t, *v, *tb;
  PyErr_Fetch(&t, &v, &tb);
  if (t != NULL)
    stype = PyObject_Str(t);
  else
    stype = PyString_FromString("");

  if (v != NULL)
    svalue = PyObject_Str(v);
  else
    svalue = PyString_FromString("");

  if (tb != NULL)
    straceback = PyObject_Repr(tb);
  else
    straceback = PyString_FromString("");

  Py_XDECREF(t);
  Py_XDECREF(v);
  Py_XDECREF(tb);
}

void boost::python::Error::PyErrHandler::printOn(std::ostream& strm)
const
{
  strm << std::string(PyString_AsString(stype)) << "\n"
       << std::string(PyString_AsString(svalue)) << "\n"
       << std::string(PyString_AsString(straceback));
}

PyObject *boost::python::Error::PyErrHandler::operator() ()
{
  PyErr_Restore(t, v, tb)
  return NULL;
}

std::ostream&
boost::python::Error::operator<<(std::ostream& os,
	   const boost::python::Error::PyErrHandler& el)
{
  el.printOn(os);
  return os;
}
--8<------------------------schnapp------------------------->8---

Greetings

Berthold
-- 
Dipl.-Ing. Berthold H llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From david.abrahams at rcn.com  Fri Jul 19 16:44:24 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 10:44:24 -0400
Subject: [C++-sig] V2: wrapping globals?
References: <1027089199.19917.4.camel@hunsmac.mit.edu>
Message-ID: <0d6801c22f33$24e944a0$6501a8c0@boostconsulting.com>

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


> Hi,
>
> Is there already functionality equivalent to the V1 make_ref in V2

Yes, it's spelled "object".

object(1)
object("foo")
object(whatever)

> to
> wrap global variables and constants?
>
> Incidentally, this would also be a nice workaround for the current lack
> of enum support...

Hmm, there's no easy way to bind objects into module and class namespaces.
I'd be willing to consider a patch if you'd like to contribute one. Dave
Hawkes might have some ideas also, as he's been working in this area.

-Dave






From david.abrahams at rcn.com  Fri Jul 19 16:54:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 10:54:09 -0400
Subject: [C++-sig] Re: Hnadling Python exceptions in C++
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de><03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com> <septxj22xl.fsf@pc970145.GermanLloyd.de>
Message-ID: <0d8401c22f34$342e2740$6501a8c0@boostconsulting.com>

From: "Berthold H?llmann" <hoel at germanlloyd.org>


> OK, after thinking a bit about such a facility here is my idea. It
> would be nice to have a C++ exception class that reads out PyErr_Fetch
> when instantiated and can be converted back into a Python exception if
> needed. I tried to start an implementation.

Hi Berthold,

Before posting an implementation, could you please explain the use-case
you're trying to cover, show the interface, and how it would be used?

> The attached code is
> untested, it is just posted to share the idea.

Please don't use tabs when posting code; as you can see they disappear.

schnipp-schnapp-to-you-too-ly y'rs,
dave

> except.hpp:
> --8<------------------------schnipp------------------------->8---
> #ifndef EXCEPT_BH20020719_H_
> #define EXCEPT_BH20020719_H_
>
> #include <Python.h>
> #include <string>
>
> namespace boost {
>   namespace python {
>     namespace Error {
>       class PyErrHandler {
>       public:
> PyErrHandler();
> virtual void printOn(std::ostream&) const;
>       private:
> PyObject *stype, *svalue, *straceback;
>       };
>       std::ostream& operator<<(std::ostream& os,
>        const PyErrHandler& el);
>     }
>   }
> }
>
> #endif // EXCEPT_BH20020719_H_
> --8<------------------------schnapp------------------------->8---







From david.abrahams at rcn.com  Fri Jul 19 17:12:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 11:12:05 -0400
Subject: [C++-sig] One more thought on attribute access
Message-ID: <0d9601c22f36$b8c89dd0$6501a8c0@boostconsulting.com>

One more syntax possibility for attribute access: in lieu of

    x.attr("name")

we could write:

    (x,"name")

I'm not sure it's an improvement, and since the precedence of operator,()
is low the parens are required. I'm thinking about usages like the
following:

    x.func(1, 3)

which become:

    x.attr("func")(1, 3);

in C++. With the change, it would be:

    (x,"func")(1, 3);

Another possibility that could improve readability would be to rename
"attr" to "dot":

    x.dot("func")(1, 3)

...although numericists might not like it.

-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 hoel at germanlloyd.org  Fri Jul 19 17:49:31 2002
From: hoel at germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=)
Date: 19 Jul 2002 17:49:31 +0200
Subject: [C++-sig] Re: Hnadling Python exceptions in C++
In-Reply-To: <0d8401c22f34$342e2740$6501a8c0@boostconsulting.com>
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de><03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com><septxj22xl.fsf@pc970145.GermanLloyd.de><0d8401c22f34$342e2740$6501a8c0@boostconsulting.com>
Message-ID: <selm871zw4.fsf@pc970145.GermanLloyd.de>

"David Abrahams" <david.abrahams at rcn.com> writes:

> From: "Berthold Hllmann" <hoel at germanlloyd.org>
> 
> 
> > OK, after thinking a bit about such a facility here is my idea. It
> > would be nice to have a C++ exception class that reads out
PyErr_Fetch
> > when instantiated and can be converted back into a Python exception
if
> > needed. I tried to start an implementation.
> 
> Hi Berthold,
> 
> Before posting an implementation, could you please explain the
use-case
> you're trying to cover, show the interface, and how it would be used?
> 
> > The attached code is
> > untested, it is just posted to share the idea.
> 
> Please don't use tabs when posting code; as you can see they
disappear.
> 

OK, I dove a little more into the boost python sources. One thing I
did not understand was the purpose of the function
"throw_error_already_set()". Why this indirection instead of calling
"throw error_already_set()"? But anyway, it would be nice to have a
facility to extract the error ocured when error_already_set was
thrown. Some access to the reason a command failed. This is where the
proposed class "error_handler " comes into play. It reads the Python
error state. It has a method "get_type" to get access to the python
exception thrown and it has an operator to put the exception
informations onto a stream. Calling the () operator will set back the
exception status and returns NULL, ready to be returned to Python:

try {
  boost::python::api::object
     fails(boost::python::api::import_import("does.not.exist");
} catch (error_already_set) {
  boost::python::error::error_handler err;
  std::cerr<<err;
  return err();
}

My proposed first interface would look like this:

--8<------------------------schnipp------------------------->8---
#include <Python.h>
namespace boost { namespace python { namespace Error {
  class error_handler {
  public:
    error_handler();
    ~error_handler();
    object get_type();
    PyObject *error_handler::operator() (); // always returns NULL
    virtual void printOn(std::ostream&) const;
  private:
    PyObject *type, *value, *traceback;
  };
  std::ostream& operator<<(std::ostream& os,
                           const error_handler& el);
} } }
--8<------------------------schnapp------------------------->8---

It's time for weekend now

Greetings

Berthold
-- 
Dipl.-Ing. Berthold H llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 




From niki at vintech.bg  Fri Jul 19 18:51:15 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Fri, 19 Jul 2002 19:51:15 +0300
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <3D0D8C36.8030704@vintech.bg> <001701c215e2$6606a960$6601a8c0@boostconsulting.com> <3D0DB4F5.6000901@vintech.bg> <0cd601c22f26$4a3f2470$6501a8c0@boostconsulting.com> <3D3816A0.2030201@vintech.bg> <0d0001c22f29$ed10eff0$6501a8c0@boostconsulting.com>
Message-ID: <3D384383.1000300@vintech.bg>

David Abrahams wrote:
>>>Am I missing something here?
>>
>>obj._("test") will include string "test" for translation (i18n)
> 
> 
> How? What is the mechanism that causes it to happen?

Special parser which looks for string in form _("...")

> I don't see how
> 
>     #define _(x) gettext(x)
> 
> can cause it.

It's not #define but usage. Parser will get it even without #define.

regards,
Niki Spahiev





From david.abrahams at rcn.com  Fri Jul 19 20:08:00 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 14:08:00 -0400
Subject: [C++-sig] June 2002 Progress Report
Message-ID: <0e6901c22f4f$39184950$6501a8c0@boostconsulting.com>

The much belated June 2002 progress report is now available in CVS, or at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/Jun2002.html

I've also added a Progress Reports index page to the documentation, so they
can be more-easily browsed:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/progress_reports.html

-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 rwgk at yahoo.com  Fri Jul 19 20:19:15 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 11:19:15 -0700 (PDT)
Subject: [C++-sig] regarding recent IRIX CC build problem
Message-ID: <20020719181915.83628.qmail@web20209.mail.yahoo.com>

Currently the IRIX CC auto build of Boost.Python V2 (cci.lbl.gov/boost) is
failing because /usr/include/ctype.h on this platform #defines isalnum etc. I
believe this must be due to an oversight on SGI's part because the header file
does also contain the proper ANSI function prototypes. The Boost.Python V2
build is fully successful if -D_LINT is added to the CC command line. Therefore
I'd suggest that this define is added to mipspro-tools.jam.
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Fri Jul 19 20:32:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 14:32:40 -0400
Subject: [C++-sig] regarding recent IRIX CC build problem
References: <20020719181915.83628.qmail@web20209.mail.yahoo.com>
Message-ID: <0ead01c22f52$aae6ee80$6501a8c0@boostconsulting.com>

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


> Currently the IRIX CC auto build of Boost.Python V2 (cci.lbl.gov/boost)
is
> failing because /usr/include/ctype.h on this platform #defines isalnum
etc.

I actually saw this problem recently with another 3rd-party tool based on
gcc-2.95.3. Another possibility is that we could add #undef isalnum (et.
al) to str.hpp.

> I
> believe this must be due to an oversight on SGI's part because the header
file
> does also contain the proper ANSI function prototypes.

It might well be what they think of as an optimization.

> The Boost.Python V2
> build is fully successful if -D_LINT is added to the CC command line.
Therefore
> I'd suggest that this define is added to mipspro-tools.jam.

I'm not sure. Maybe we should rename these (really!)
I don't remember what the standard says about this, but I know that in
practice it's very common for C++ stdlib implementors to have no control
over the underlying 'C' library headers, so it may be that such macros are
unavoidable for many platforms.

I'm curious: does irix cc supply <locale>? If so, how does it get around
this problem?

-Dave






From rwgk at yahoo.com  Fri Jul 19 20:33:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 11:33:48 -0700 (PDT)
Subject: [C++-sig] June 2002 Progress Report
In-Reply-To: <0e6901c22f4f$39184950$6501a8c0@boostconsulting.com>
Message-ID: <20020719183348.82400.qmail@web20203.mail.yahoo.com>


From rwgk at yahoo.com  Fri Jul 19 20:45:22 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 11:45:22 -0700 (PDT)
Subject: [C++-sig] regarding recent IRIX CC build problem
In-Reply-To: <0ead01c22f52$aae6ee80$6501a8c0@boostconsulting.com>
Message-ID: <20020719184522.25186.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> I'm not sure. Maybe we should rename these (really!)

Succumb to broken implementations? Surely You're Joking, Mr. Abrahams.

> I'm curious: does irix cc supply <locale>?

Yes.

> If so, how does it get around this problem?

Not clear to me. You can investigate on rattler.lbl.gov (/usr/include).

Ralf

P.S.: In the meantime I will use -D_LINT in our custom toolset for the
auto-builds.


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From rwgk at yahoo.com  Fri Jul 19 20:55:49 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 11:55:49 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
In-Reply-To: <0cd601c22f26$4a3f2470$6501a8c0@boostconsulting.com>
Message-ID: <20020719185549.90652.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Now that I'm revisiting this issue for my June monthly report, I'm not sure
> that using the name for an inline member function "_" with one argument
> would actually cause any problems in real code. AFAICT, the result would be
> that the member function would be silently renamed "gettext" in the common
> case... and all uses of the function will also be silently renamed to call
> x.gettext(...). Yes, technically this gives an ODR violation if the file is
> included with and without the macro defined, but I know of no real
> compilers which will care about that.

I am sure David will butcher me again for this, but I don't understand why it
is important to save a few characters at the expense of understandability. My
reaction to

x._("foo") = 1
y = x._("foo")

would be "What's that?", while

x.attr("foo") = 1

would make much more sense to my mind if it were untainted.

But hey, David, if you could make it

x.foo = 1

(in C++!) I'd be on your side.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Fri Jul 19 21:03:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 15:03:27 -0400
Subject: [C++-sig] June 2002 Progress Report
References: <20020719183348.82400.qmail@web20203.mail.yahoo.com>
Message-ID: <0ece01c22f56$fa528480$6501a8c0@boostconsulting.com>

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

> From the June progress report:
> 
> Python     C++  
> y = x.foo  y = x.attr("foo");  
> ...
> x and y    x and y  
>              ^^^
> 
> Should this be &&, or is there something in C++ that I don't know about?

Try it and find out ;-)

-Dave





From david.abrahams at rcn.com  Fri Jul 19 21:06:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 15:06:14 -0400
Subject: [C++-sig] regarding recent IRIX CC build problem
References: <20020719184522.25186.qmail@web20204.mail.yahoo.com>
Message-ID: <0ede01c22f57$addbf950$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> > I'm not sure. Maybe we should rename these (really!)
> 
> Succumb to broken implementations? Surely You're Joking, Mr. Abrahams.

??I don't play the bongos??

> > I'm curious: does irix cc supply <locale>?
> 
> Yes.
> 
> > If so, how does it get around this problem?
> 
> Not clear to me. You can investigate on rattler.lbl.gov (/usr/include).

I might take a poke at it.

> Ralf
> 
> P.S.: In the meantime I will use -D_LINT in our custom toolset for the
> auto-builds.

Fine.





From david.abrahams at rcn.com  Fri Jul 19 21:17:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 15:17:39 -0400
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <20020719185549.90652.qmail@web20209.mail.yahoo.com>
Message-ID: <0ef801c22f59$152164a0$6501a8c0@boostconsulting.com>

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

> I am sure David will butcher me again for this,

I love the way you always frame every issue with such understatement...

> but I don't understand why it
> is important to save a few characters at the expense of
understandability. My
> reaction to
>
> x._("foo") = 1
> y = x._("foo")
>
> would be "What's that?", while
>
> x.attr("foo") = 1
>
> would make much more sense to my mind if it were untainted.

If you look at how it plays out in larger expressions (especially method
calls), it's not so pretty:

    x.attr("foo")(bar, baz)

I'm just exploring ways to make that a little more digestible.

    x._("foo")(bar, baz)

isn't much better, though.

> But hey, David, if you could make it
>
> x.foo = 1
>
> (in C++!) I'd be on your side.

Love to! No can do, though.

-Dave





From david.abrahams at rcn.com  Fri Jul 19 21:23:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 15:23:50 -0400
Subject: [C++-sig] regarding recent IRIX CC build problem
References: <20020719184522.25186.qmail@web20204.mail.yahoo.com> <0ede01c22f57$addbf950$6501a8c0@boostconsulting.com>
Message-ID: <0f1601c22f5a$182b53d0$6501a8c0@boostconsulting.com>

From: "David Abrahams" <david.abrahams at rcn.com>

> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
>
>
> > --- David Abrahams <david.abrahams at rcn.com> wrote:
>
> > > I'm curious: does irix cc supply <locale>?
> >
> > Yes.
> >
> > > If so, how does it get around this problem?
> >
> > Not clear to me. You can investigate on rattler.lbl.gov (/usr/include).
>
> I might take a poke at it.

Hmm, you might have just opened the file and looked for me so I didn't have
to ssh in...
See line 45 of /usr/include/CC/locale. I guess #undef is our friend.

I guess it really should be done unconditionally in str.hpp. Will you make
the patch?

-Dave





From rwgk at yahoo.com  Fri Jul 19 21:41:03 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 12:41:03 -0700 (PDT)
Subject: [C++-sig] regarding recent IRIX CC build problem
In-Reply-To: <0f1601c22f5a$182b53d0$6501a8c0@boostconsulting.com>
Message-ID: <20020719194103.52220.qmail@web20207.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Hmm, you might have just opened the file and looked for me so I didn't have
> to ssh in...

Yes I might have, but I doubt that I could have made a judgement with the same
competence.

> See line 45 of /usr/include/CC/locale. I guess #undef is our friend.
> 
> I guess it really should be done unconditionally in str.hpp. Will you make
> the patch?

You mean like this:

Index: str.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/str.hpp,v
retrieving revision 1.2
diff -r1.2 str.hpp
7a8,14
> // disable defines in <cctype> provided by some system libraries
> #undef isspace
> #undef islower
> #undef isalpha
> #undef isdigit
> #undef isalnum
> 

Commit?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Fri Jul 19 21:55:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 15:55:38 -0400
Subject: [C++-sig] regarding recent IRIX CC build problem
References: <20020719194103.52220.qmail@web20207.mail.yahoo.com>
Message-ID: <0f3801c22f5e$426e9590$6501a8c0@boostconsulting.com>

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

> Commit?

You go, girlfriend!

-Dave

(I hear men don't like to commit)





From rwgk at yahoo.com  Fri Jul 19 22:13:33 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 13:13:33 -0700 (PDT)
Subject: [C++-sig] make_tuple()?
Message-ID: <20020719201333.89395.qmail@web20202.mail.yahoo.com>

Given two handle<>, how do I turn them into a tuple?
handle<> a;
handle<> b;
tuple(a, b); // does not work
make_tuple(a, b); // does not work
Looking at test/tuple.cpp wasn't particularly informative.
Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Fri Jul 19 22:26:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 16:26:08 -0400
Subject: [C++-sig] make_tuple()?
References: <20020719201333.89395.qmail@web20202.mail.yahoo.com>
Message-ID: <0f6601c22f62$856e3d10$6501a8c0@boostconsulting.com>

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


> Given two handle<>, how do I turn them into a tuple?
> handle<> a;
> handle<> b;
> tuple(a, b); // does not work
> make_tuple(a, b); // does not work
> Looking at test/tuple.cpp wasn't particularly informative.

We need a family of boost::python::make_tuple() functions. Are you ready to
learn about the preprocessor library? The pattern used by
object_core/object_call.hpp provides useful boilerplate.

-Dave






From rwgk at yahoo.com  Sat Jul 20 02:19:56 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 17:19:56 -0700 (PDT)
Subject: [C++-sig] make_tuple()?
In-Reply-To: <0f6601c22f62$856e3d10$6501a8c0@boostconsulting.com>
Message-ID: <20020720001956.23888.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> We need a family of boost::python::make_tuple() functions. Are you ready to
> learn about the preprocessor library? The pattern used by
> object_core/object_call.hpp provides useful boilerplate.

The algorithms come out nicer if I do it like this:

list result;
...
result.append(...); // a few times
...
return handle<>(borrowed(tuple(result).ptr())).release();

I know eventually it will be possible to avoid returning a bare PyObject* in
most situations. But I figure this will not always be the case, e.g. if I set
out to write C++ bindings for the Numarray 'C' API. Can we somehow talk you
into giving us:

return tuple(result).hdl().release();

Consider that you don't have to ask for a patch. It is attached and tested!

I am also wondering about this asymmetry:

PyObject* object::ptr() const;
T* handle<T>::get() const;

Is this the reference<> heritage shining through? The following seems more
self-consistent:

T* handle<T>::ptr() const;

This begs another question: why isn't object derived from handle<>? I am
thinking "an object is just like a handle<>, with the additional guarantee that
the contained PyObject* is not 0." Where am I going wrong?

Ralf

Index: object_core.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/object_core.hpp,v
retrieving revision 1.17
diff -r1.17 object_core.hpp
205a206,208
> 
>       // new handle<> for underlying object
>       handle<> hdl() const { return handle<>(borrowed(m_ptr)); }


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Sat Jul 20 02:36:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 20:36:44 -0400
Subject: [C++-sig] make_tuple()?
References: <20020720001956.23888.qmail@web20202.mail.yahoo.com>
Message-ID: <10a101c22f85$875d4df0$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > We need a family of boost::python::make_tuple() functions. Are you
ready to
> > learn about the preprocessor library? The pattern used by
> > object_core/object_call.hpp provides useful boilerplate.
>
> The algorithms come out nicer if I do it like this:
>
> list result;
> ...
> result.append(...); // a few times
> ...
> return handle<>(borrowed(tuple(result).ptr())).release();

Really? That's better than make_tuple(a, b, c)?

> I know eventually it will be possible to avoid returning a bare PyObject*
in
> most situations. But I figure this will not always be the case, e.g. if I
set
> out to write C++ bindings for the Numarray 'C' API.

I think it will still be possible to hide most of the PyObject*
manipulations in the library.

> Can we somehow talk you
> into giving us:
>
> return tuple(result).hdl().release();

You can always do:

    incref(tuple(result).ptr())

Doesn't that suit?

> Consider that you don't have to ask for a patch. It is attached and
tested!
>
> I am also wondering about this asymmetry:
>
> PyObject* object::ptr() const;
> T* handle<T>::get() const;

object is not a smart pointer, but an object wrapper. handle<> is modeled
on the auto_ptr/shared_ptr interface. I hope that nearly all uses of
handle<> will soon disappear.

> Is this the reference<> heritage shining through? The following seems
more
> self-consistent:
>
> T* handle<T>::ptr() const;

Understood, but I'm not really sure I want to make them look the same.

> This begs another question: why isn't object derived from handle<>?

Lots of reasons.

> I am
> thinking "an object is just like a handle<>, with the additional
guarantee that
> the contained PyObject* is not 0." Where am I going wrong?

An object has a very different intended role from a handle<>.

That added guarantee is part of the reason they don't have an inheritance
relationship. Look at handle<>'s copy constructor for example. If object
were derived from handle<>, every refcounting operation would be checking
for NULL. Because it's not, we never have to check for NULL when
manipulating object.

Another reason is that object doesn't support operator->() and unary
operator*(), and I really don't want it to.

Think of handle<> as a tool for managing the lifetime of and getting access
to raw Python object data like PyObject, PyStringObject, PyTypeObject, and
NumArrayObject (sp?).

Think of object as a high-level wrapper for a Python object.

-Dave






From rwgk at yahoo.com  Sat Jul 20 03:37:06 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 18:37:06 -0700 (PDT)
Subject: [C++-sig] make_tuple()?
In-Reply-To: <10a101c22f85$875d4df0$6501a8c0@boostconsulting.com>
Message-ID: <20020720013706.1445.qmail@web20207.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > return handle<>(borrowed(tuple(result).ptr())).release();
> 
> Really? That's better than make_tuple(a, b, c)?

Yes, because I had to make tuples three times. The append() solution really is
better in my context.
(But you are right in your suspicion that my first motivation to start looking
for alternative solutions was being scared by the prospect of having to deal
with the preprocessor library.)

> You can always do:
> 
>     incref(tuple(result).ptr())
> 
> Doesn't that suit?

Yes, thanks! I will put my patch in the attic for the time being. (But I must
add that this solution is even more low level than the hdl() approach; I was
hoping that I can completely forget about incref and decref.)

> > T* handle<T>::ptr() const;
> 
> Understood, but I'm not really sure I want to make them look the same.

Sigh.

On to the next question. I am wondering about the error handling approaches.
How does

  object state;
  tuple(state);

behave if state is not a tuple?

How do you envision api function such as len(object()) to behave if a Python
exception is raised? Should it be more like

    int len(object const& obj)
    {
        return PyObject_Length(obj.ptr());
    }

or

    int len(object const& obj)
    {
        int result = PyObject_Length(obj.ptr());
        if (PyErr_Occurred()) boost::python::throw_error_already_set();
        return result;
    }

Is there a firm plan already?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com




From david.abrahams at rcn.com  Sat Jul 20 03:52:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 21:52:51 -0400
Subject: [C++-sig] make_tuple()?
References: <20020720013706.1445.qmail@web20207.mail.yahoo.com>
Message-ID: <10d101c22f90$2ae78fd0$6501a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> > > return handle<>(borrowed(tuple(result).ptr())).release();
> >
> > Really? That's better than make_tuple(a, b, c)?
>
> Yes, because I had to make tuples three times. The append() solution
really is
> better in my context.

I don't get why the number of times you have to make a tuple has any
bearing.

> (But you are right in your suspicion that my first motivation to start
looking
> for alternative solutions was being scared by the prospect of having to
deal
> with the preprocessor library.)

It's kind of nice, actually.

> > You can always do:
> >
> >     incref(tuple(result).ptr())
> >
> > Doesn't that suit?
>
> Yes, thanks! I will put my patch in the attic for the time being. (But I
must
> add that this solution is even more low level than the hdl() approach; I
was
> hoping that I can completely forget about incref and decref.)

Once you start touching raw PyObject*s, I think incref makes a lot more
sense than handle<>.release()

> > Understood, but I'm not really sure I want to make them look the same.
>
> Sigh.

It's tough living with other peoples' opinions, isn't it?

> On to the next question. I am wondering about the error handling
approaches.
> How does
>
>   object state;
>   tuple(state);
>
> behave if state is not a tuple?

Just like in Python.

> How do you envision api function such as len(object()) to behave if a
Python
> exception is raised? Should it be more like
>
>     int len(object const& obj)
>     {
>         return PyObject_Length(obj.ptr());
>     }
>
> or
>
>     int len(object const& obj)
>     {
>         int result = PyObject_Length(obj.ptr());
>         if (PyErr_Occurred()) boost::python::throw_error_already_set();
>         return result;
>     }

The latter.

> Is there a firm plan already?

Did you look at Dave Hawkes' stuff? I believe it's still in CVS. See
py_interface.[ch]pp

-Dave






From rwgk at yahoo.com  Sat Jul 20 04:24:33 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 19:24:33 -0700 (PDT)
Subject: [C++-sig] make_tuple()?
In-Reply-To: <10d101c22f90$2ae78fd0$6501a8c0@boostconsulting.com>
Message-ID: <20020720022433.43746.qmail@web20208.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > > Understood, but I'm not really sure I want to make them look the same.
> >
> > Sigh.
> 
> It's tough living with other peoples' opinions, isn't it?

Only if you are not the boss.

Yet another (unopinionated) question: What is better (in your opinion)?

    static
    object
    getstate(back_reference<world const&> x)
    {
      world const& w = x.get();
    }

or

    static
    object
    getstate(object const& x)
    {
      // use extractor<world const&>
    }

Is back_reference<> obsolete?

Thanks,
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Sat Jul 20 04:49:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 19 Jul 2002 22:49:27 -0400
Subject: [C++-sig] make_tuple()?
References: <20020720022433.43746.qmail@web20208.mail.yahoo.com>
Message-ID: <10eb01c22f98$1160b480$6501a8c0@boostconsulting.com>

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

> Yet another (unopinionated) question: What is better (in your opinion)?
>
>     static
>     object
>     getstate(back_reference<world const&> x)
>     {
>       world const& w = x.get();
>     }
>
> or
>
>     static
>     object
>     getstate(object const& x)
>     {
>       // use extractor<world const&>
>     }

It depends how you want it to interact with overloading.

> Is back_reference<> obsolete?

No, object will match anything but back_reference<T> matches only arguments
convertible to T.

HTH,
Dave






From rwgk at yahoo.com  Sat Jul 20 05:01:43 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 20:01:43 -0700 (PDT)
Subject: [C++-sig] make_tuple()?
In-Reply-To: <10eb01c22f98$1160b480$6501a8c0@boostconsulting.com>
Message-ID: <20020720030143.57261.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> It depends how you want it to interact with overloading.

In the context of pickle support there are no overloads.

> > Is back_reference<> obsolete?
> 
> No, object will match anything but back_reference<T> matches only arguments
> convertible to T.

OK. I was just afraid of using a feature that might be removed a some time.

So, which approach would you prefer given that there is only one definition for
each pickle support function and given that these functions are .def'ed as
member functions (so the first argument can only be of the given wrapped type).
Does it matter at all?

Thanks,
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Sat Jul 20 05:54:50 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 20:54:50 -0700 (PDT)
Subject: [C++-sig] dict surprise
Message-ID: <20020720035450.54529.qmail@web20208.mail.yahoo.com>

I was surprised to find that

dict(w_obj.attr("__dict__")).update(some_tuple[0]);

only updates the temporary created by dict(), but not the original __dict__.
Eventually I got the desired behavior by using

w_obj.attr("__dict__").attr("update")(object(some_tuple[0]));

I convinced myself that the first statement works just the way Python works, so
fine. However, this is a bit of a trap for the novice and a specific warning in
the documentation ("don't use dict(obj1).update(obj2)") would probably be very
helpful.

Ralf

P.S.: I love the new extract<T> .


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Sat Jul 20 08:02:39 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 19 Jul 2002 23:02:39 -0700 (PDT)
Subject: [C++-sig] object().attr_allow_null()
Message-ID: <20020720060239.31640.qmail@web20207.mail.yahoo.com>

How could I turn the following into presentable code?

      handle<> getinitargs(allow_null(PyObject_GetAttrString(obj.ptr(),
        const_cast<char*>("__getinitargs__"))));
      PyErr_Clear();

Attempts to construct a handle<> from the result of obj.attr() were
unsuccessful. Constructing an object from the result of obj.attr() leads to a
Python exception if the attribute does not exist. Therefore I am tempted to
implement

      handle<> getinitargs(obj.attr_allow_null("__getinitargs__"));
      if (getinitargs.get())
      {
        // do something.
      }
      // do something else.
      if (getinitargs.get())
      {
        // do some more stuff.
      }

where attr_allow_null() is essentially equivalent to the three lines above.

I see one weak point: handle<> is more prominently exposed than David might
want to tolerate.

Let's see what could be achieved with hasattr() (once available) and without
exposing handle<> (and without relying on C++ exception handling!):

      object getinitargs;
      if (hasattr(obj, "__getinitargs__"))
      {
        getinitargs = obj.attr("__getinitargs__");
      }
      if (getinitargs.ptr() == Py_None)
      {
        // do something.
      }
      // do something else.
      if (getinitargs.ptr() == Py_None)
      {
        // do some more stuff.
      }

I see three weak points: 1. duplication of the attribute name
("__getinitargs__"), 2. attribute lookup is performed twice, 3. people have to
mess with ptr() and Py_None.

Now lets apply the Fundamental Axioms of Programming (TM):

Let ">" mean "is worse than":

redundancy > performance hit > violating encapsulation

Clearly, attr_allow_null() comes out first!

David?

But wait, obj.attr("non-existing-key") only fails if actually used to construct
an object! So couldn't

handle<>(obj.attr())

be made to do exactly what I want?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Sat Jul 20 13:33:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 20 Jul 2002 07:33:47 -0400
Subject: [C++-sig] make_tuple()?
References: <20020720030143.57261.qmail@web20209.mail.yahoo.com>
Message-ID: <110a01c22fe1$88dc6f10$6501a8c0@boostconsulting.com>

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

> OK. I was just afraid of using a feature that might be removed a some
time.

It won't be removed, but I might well change the interface to remove the
use of handle<>, for example.

> So, which approach would you prefer given that there is only one
definition for
> each pickle support function and given that these functions are .def'ed
as
> member functions (so the first argument can only be of the given wrapped
type).
> Does it matter at all?

Only inasmuch as you care about perversity like:

class Y:
    __getinitargs__ = X.__getinitargs__

-Dave






From david.abrahams at rcn.com  Sat Jul 20 13:39:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 20 Jul 2002 07:39:20 -0400
Subject: [C++-sig] dict surprise
References: <20020720035450.54529.qmail@web20208.mail.yahoo.com>
Message-ID: <111401c22fe2$3c4a6ca0$6501a8c0@boostconsulting.com>

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


> I was surprised to find that
>
> dict(w_obj.attr("__dict__")).update(some_tuple[0]);
>
> only updates the temporary created by dict(), but not the original
__dict__.
> Eventually I got the desired behavior by using
>
> w_obj.attr("__dict__").attr("update")(object(some_tuple[0]));
>
> I convinced myself that the first statement works just the way Python
works, so
> fine. However, this is a bit of a trap for the novice and a specific
warning in
> the documentation ("don't use dict(obj1).update(obj2)") would probably be
very
> helpful.

We'd have to warn about list, too, and probably a whole host of others. Is
it worth it?
This seems like a corner case to me.

> Ralf
>
> P.S.: I love the new extract<T> .

I'm glad!
I hope you're using it with T = U& to avoid copies when appropriate...

-Dave






From david.abrahams at rcn.com  Sat Jul 20 15:06:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 20 Jul 2002 09:06:05 -0400
Subject: [C++-sig] object().attr_allow_null()
References: <20020720060239.31640.qmail@web20207.mail.yahoo.com>
Message-ID: <117a01c22fee$5c65e9e0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Saturday, July 20, 2002 2:02 AM
Subject: [C++-sig] object().attr_allow_null()


> How could I turn the following into presentable code?
>
>       handle<> getinitargs(allow_null(PyObject_GetAttrString(obj.ptr(),
>         const_cast<char*>("__getinitargs__"))));
>       PyErr_Clear();

How would you do it in Python?

    getinitargs = getattr(obj, '__getinitargs__', None)

in C++:

    object getinitargs = getattr(obj, "__getinitargs__", object());

> Attempts to construct a handle<> from the result of obj.attr() were
> unsuccessful. Constructing an object from the result of obj.attr() leads
to a
> Python exception if the attribute does not exist. Therefore I am tempted
to
> implement
>
>       handle<> getinitargs(obj.attr_allow_null("__getinitargs__"));
>       if (getinitargs.get())
>       {
>         // do something.
>       }
>       // do something else.
>       if (getinitargs.get())
>       {
>         // do some more stuff.
>       }
>
> where attr_allow_null() is essentially equivalent to the three lines
above.
>
> I see one weak point: handle<> is more prominently exposed than David
might
> want to tolerate.

yep.

> Let's see what could be achieved with hasattr() (once available) and
without
> exposing handle<> (and without relying on C++ exception handling!):
>
>       object getinitargs;
>       if (hasattr(obj, "__getinitargs__"))
>       {
>         getinitargs = obj.attr("__getinitargs__");
>       }
>       if (getinitargs.ptr() == Py_None)
>       {
>         // do something.
>       }
>       // do something else.
>       if (getinitargs.ptr() == Py_None)
>       {
>         // do some more stuff.
>       }
>
> I see three weak points: 1. duplication of the attribute name
> ("__getinitargs__"), 2. attribute lookup is performed twice, 3. people
have to
> mess with ptr() and Py_None.

      object getinitargs;
      if (hasattr(obj, "__getinitargs__"))
      {
        getinitargs = obj.attr("__getinitargs__");
      }
      if (!getinitargs) // for most cases you care about, this is OK
      {
        // do something.
      }
      // do something else.
      if (is(getinitargs,object())) // otherwise...
      {
        // do some more stuff.
      }


> Now lets apply the Fundamental Axioms of Programming (TM):
>
> Let ">" mean "is worse than":
>
> redundancy > performance hit > violating encapsulation
>
> Clearly, attr_allow_null() comes out first!
>
> David?
>
> But wait, obj.attr("non-existing-key") only fails if actually used to
construct
> an object!
>
> So couldn't
>
> handle<>(obj.attr())
>
> be made to do exactly what I want?

That's cute, but probably not worth the complexity. Getting the object
conversions to work right wasn't easy. I'll consider a patch, though.

-Dave






From rwgk at yahoo.com  Sat Jul 20 20:56:00 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 20 Jul 2002 11:56:00 -0700 (PDT)
Subject: [C++-sig] object().attr_allow_null()
In-Reply-To: <117a01c22fee$5c65e9e0$6501a8c0@boostconsulting.com>
Message-ID: <20020720185600.18908.qmail@web20206.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> How would you do it in Python?
> 
>     getinitargs = getattr(obj, '__getinitargs__', None)
> 
> in C++:
> 
>     object getinitargs = getattr(obj, "__getinitargs__", object());

Oh, I didn't know that getattr() can take three arguments. That's great!
 
> > So couldn't
> >
> > handle<>(obj.attr())
> >
> > be made to do exactly what I want?
> 
> That's cute, but probably not worth the complexity. Getting the object
> conversions to work right wasn't easy. I'll consider a patch, though.

I'll take the B for effort and use getattr().

>      if (!getinitargs) // for most cases you care about, this is OK

I was thinking "most" is not good enough for you.
This does not distinguish between None and and an empty tuple or dict,
does it?

>      if (is(getinitargs,object())) // otherwise...

Isn't this expensive, both in terms of code generated and performance wise?
And it doesn't look like Python!
This leads me to

       if (!getinitargs.is_none())

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From achim.domma at syynx.de  Sun Jul 21 10:09:57 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 21 Jul 2002 10:09:57 +0200
Subject: [C++-sig] errors after cvs update
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEGFDJAA.achim.domma@syynx.de>

E:\cvsroot\boost\boost/function/function_template.hpp(344) : error C2572:
'set' : redefinition of default parameter : parameter 2
        E:\cvsroot\boost\boost/function/function_template.hpp(342) : see
declaration of 'set'
        E:\cvsroot\boost\boost/function/function_template.hpp(504) : see
reference to class template instantiation
'boost::function0<R,Policy,Mixin,Allocator>' being compiled

After executing a cvs update I got lots of these errors, if I try to build
bpl. Any hint what's wrong?

Achim







From rwgk at yahoo.com  Sun Jul 21 10:05:55 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 21 Jul 2002 01:05:55 -0700 (PDT)
Subject: [C++-sig] additional files for pickle support
Message-ID: <20020721080555.30270.qmail@web20203.mail.yahoo.com>

I have just checked in additional files for V2 pickle support. At this point I
have not checked in my patches for the existing files. I.e. my changes to the
cvs tree will not have any (good or bad) effect on other developers.

The new files have been tested with gcc 3.0.4, cxx 6.5 (tru64) and VC6. I am
about to experiment with an idea for hiding the entire implementation except
for the one new member function of class_<> (.pickle_support(); not currently
in cvs). Having the current, functional implementation in cvs will allow me to
work most efficiently (I can easily back up or look at diffs if necessary).

Ralf

P.S.: I have already eliminated all uses of bare PyObject* and all but one uses
of handle<>.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Sun Jul 21 11:50:14 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 21 Jul 2002 02:50:14 -0700 (PDT)
Subject: [C++-sig] errors after cvs update
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAIEGFDJAA.achim.domma@syynx.de>
Message-ID: <20020721095014.36217.qmail@web20209.mail.yahoo.com>

These errors started popping up yesterday, and only for VC6 & VC7. If you have
another compiler you should be able to use the latest cvs until the VC problems
are resolved.
Ralf
P.S.: Your cvs update life insurance is available at:
http://cci.lbl.gov/boost

--- Achim Domma <achim.domma at syynx.de> wrote:
> E:\cvsroot\boost\boost/function/function_template.hpp(344) : error C2572:
> 'set' : redefinition of default parameter : parameter 2
>         E:\cvsroot\boost\boost/function/function_template.hpp(342) : see
> declaration of 'set'
>         E:\cvsroot\boost\boost/function/function_template.hpp(504) : see
> reference to class template instantiation
> 'boost::function0<R,Policy,Mixin,Allocator>' being compiled
> 
> After executing a cvs update I got lots of these errors, if I try to build
> bpl. Any hint what's wrong?
> 
> Achim
> 
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Sun Jul 21 12:13:02 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 21 Jul 2002 03:13:02 -0700 (PDT)
Subject: [C++-sig] additional files for pickle support
In-Reply-To: <20020721080555.30270.qmail@web20203.mail.yahoo.com>
Message-ID: <20020721101302.38364.qmail@web20209.mail.yahoo.com>

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> The new files have been tested with gcc 3.0.4, cxx 6.5 (tru64) and VC6. I am
> about to experiment with an idea for hiding the entire implementation except
> for the one new member function of class_<> (.pickle_support(); not currently
> in cvs). Having the current, functional implementation in cvs will allow me
> to
> work most efficiently (I can easily back up or look at diffs if necessary).

OK, done experimenting. David, now would be a good time to criticize the new
files. Three additional patches are attached for your reference. The only other
changes are trivial additions to the Jamfiles.

Locally I am currently working with
#include <boost/python/detail/api_placeholder.hpp>
This file implements len() and getattr(). I don't think you want this in cvs.
So before I can check in the patches that complete the integration of the
pickle support there need to be replacements for my len() and getattr().

Ralf

P.S.: I noticed that class_::setattr() still deals with handle<> .
Is this going to change?


Index: class.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/class.hpp,v
retrieving revision 1.27
diff -r1.27 class.hpp
27a28
> # include <boost/python/object/pickle_support.hpp>
196a198,210
> 
>     // Pickle support
>     template <typename PickleSupport>
>     self& pickle_support(PickleSupport)
>     {
>       detail::pickle_support_finalize<PickleSupport>::register_(
>         *this,
>         &PickleSupport::getinitargs,
>         &PickleSupport::getstate,
>         &PickleSupport::setstate,
>         PickleSupport::getstate_manages_dict());
>       return *this;
>     }


Index: object/class.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/object/class.hpp,v
retrieving revision 1.22
diff -r1.22 class.hpp
41a42
>     void enable_pickle_support(bool getstate_manages_dict);


Index: src/object/class.cpp
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/src/object/class.cpp,v
retrieving revision 1.31
diff -r1.31 class.cpp
8a9
> #include <boost/python/object/pickle_support.hpp>
304a306,315
>   }
> 
>   void class_base::enable_pickle_support(bool getstate_manages_dict)
>   {
>       setattr("__reduce__", make_instance_reduce_function());
>       handle<> one(PyInt_FromLong(1));
>       setattr("__safe_for_unpickling__", one);
>       if (getstate_manages_dict) {
>         setattr("__getstate_manages_dict__", one);
>       }


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Sun Jul 21 13:08:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 21 Jul 2002 07:08:01 -0400
Subject: [C++-sig] Re: [boost] function/function_template.hpp
References: <4.3.1.2.20020720115838.05eb7da8@mail.rudbek.com> <4.3.1.2.20020720115838.05eb7da8@mail.rudbek.com> <4.3.1.2.20020721003141.071432c8@mail.rudbek.com>
Message-ID: <12cc01c230a7$4164ec40$6501a8c0@boostconsulting.com>

BTW, this wasn't a vc7-specific error. I don't know how anyone missed
seeing it with msvc6; maybe it only get stimulated by the Python library.

In any case, I've checked in this patch as a workaround until Doug can look
at it more closely:

*** function_template.hpp.~1.41.~ Sun Jul 21 00:48:07 2002
--- function_template.hpp Sun Jul 21 06:59:15 2002
***************
*** 339,347 ****
      }

      // Assignment from another BOOST_FUNCTION_FUNCTION
!     void set(const BOOST_FUNCTION_FUNCTION& f,
!              int deprecated = 0)
      {
        if (&f == this)
          return;

--- 339,347 ----
      }

      // Assignment from another BOOST_FUNCTION_FUNCTION
!     void set(const BOOST_FUNCTION_FUNCTION& f)
      {
+       int deprecated;
        if (&f == this)
          return;


-Dave

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr at rudbek.com>
To: <boost at lists.boost.org>
Sent: Sunday, July 21, 2002 3:34 AM
Subject: Re: [boost] function/function_template.hpp


> Sorry it took so long... I'd forgotten that *nix is case sensitive and
> couldn't figure out why
> bjam -s"tools=VC7"
> kept trying to use all the compilers instead of just VC7
> at any rate when I finally typed
> bjam -s"TOOLS=VC7" it built regex, then started getting errors on
python...
> here's one of the errors
>
>
>      CALL "C:\Program Files\Microsoft Visual Studio
> .NET\Vc7\bin\VCVARS32.BAT" >nul
>      "C:\Program Files\Microsoft Visual Studio .NET\Vc7\bin\cl"  /Zm400
> -nologo -GX -c  -DBOOST_PYTHON_DYNAMIC_LIB  /Z7 /Od /Ob0 /GX /GR
> /MDd   -I"libs\python\bu
> ild"  -I"C:\Boost Releases\boost"
> -I"c:\Python22\include"
> -Fo"libs\python\build\bin\boost_python.dll\VC7\debug\runtime-link-dynamic
\extension_class.obj"
> -Tp"
> libs\python\build\../src\extension_class.cpp"
>
> ...failed vc-C++
>
libs\python\build\bin\boost_python.dll\VC7\debug\runtime-link-dynamic\exten
sion_class.obj...
> vc-C++
>
libs\python\build\bin\boost_python.dll\VC7\debug\runtime-link-dynamic\funct
ions.obj
> functions.cpp
> C:\Boost Releases\boost\boost\function\function_template.hpp(344) : error
> C2572: 'boost::function0<R,Policy,Mixin,Allocator>::set' : redefinition
of
> default par
> ameter : parameter 2
>          with
>          [
>              R=void,
>              Policy=boost::empty_function_policy,
>              Mixin=boost::empty_function_mixin,
>              Allocator=int
>          ]
>          C:\Boost
Releases\boost\boost\function\function_template.hpp(342)
> : see declaration of 'boost::function0<R,Policy,Mixin,Allocator>::set'
>          with
>          [
>              R=void,
>              Policy=boost::empty_function_policy,
>              Mixin=boost::empty_function_mixin,
>              Allocator=int
>          ]
>          C:\Boost Releases\boost\boost\python\errors.hpp(23) : see
> reference to class template instantiation
> 'boost::function0<R,Policy,Mixin,Allocator>' being c
> ompiled
>          with
>          [
>              R=void,
>              Policy=boost::empty_function_policy,
>              Mixin=boost::empty_function_mixin,
>              Allocator=int
>          ]
>
>
>
> At Saturday 2002/07/20 15:40, you wrote:
> >On Saturday 20 July 2002 03:05 pm, Victor A. Wagner, Jr. wrote:
> > > Last evening (PST) I updated all the boost files from CVS and
attempted to
> > > rebuild (VC7) the libraries.
> > > I got errors in function/function_template.hpp when building the
python
> > > library.
> > >
> > > J:\Common\boost_from_CVS\boost\function>cvs update -D07/19/2002
> > > sufficed to "roll back" function_template.hpp
> > > and the build then worked properly
> >
> >I've been making some changes to function/function_template.hpp and for
a
> >short while (maybe 1/2 hour) it was broken on MSVC. Everything is
working
> >properly now on MSVC 6.0sp5, but I can't test MSVC 7.0 locally. Would
someone
> >check if the current CVS version of function works properly with MSVC 7?
> >
> >         Doug
> >_______________________________________________
> >Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
> Victor A. Wagner Jr.      http://rudbek.com
> PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
> PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
> The five most dangerous words in the English language:
>                "There oughta be a law"
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>





From david.abrahams at rcn.com  Sun Jul 21 13:23:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 21 Jul 2002 07:23:22 -0400
Subject: [C++-sig] Re: [Boost-python-cvs] CVS: boost/libs/python/test pickle1.cpp,NONE,1.1 pickle1.py,NONE,1.1 pickle2.cpp,NONE,1.1 pickle2.py,NONE,1.1 pickle3.cpp,NONE,1.1 pickle3.py,NONE,1.1
References: <E17WBRi-0008E0-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <12ec01c230a9$9eb69f90$6501a8c0@boostconsulting.com>

Hi Ralf,

This is cool!

Can we discuss different names for "pickle_support_base" please?
I'm in favor of "pickler". Thus, world_pickle_support is-a
boost::python::pickler. I realize it's also an unpickler, so if you don't
like that I'd like to at least find a way to drop "_base" from any public
names.

-Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at users.sourceforge.net>
To: <boost-python-cvs at lists.sourceforge.net>
Sent: Sunday, July 21, 2002 3:48 AM
Subject: [Boost-python-cvs] CVS: boost/libs/python/test
pickle1.cpp,NONE,1.1 pickle1.py,NONE,1.1 pickle2.cpp,NONE,1.1
pickle2.py,NONE,1.1 pickle3.cpp,NONE,1.1 pickle3.py,NONE,1.1


> Update of /cvsroot/boost/boost/libs/python/test
> In directory usw-pr-cvs1:/tmp/cvs-serv31578/test
>
> Added Files:
> pickle1.cpp pickle1.py pickle2.cpp pickle2.py pickle3.cpp
> pickle3.py
> Log Message:
> additional files for pickle support; no modification of any existing
files
>
> --- NEW FILE: pickle1.cpp ---
> // Example by Ralf W. Grosse-Kunstleve
>
> /*
>     This example shows how to make an Extension Class "pickleable".
>
>     The world class below can be fully restored by passing the
>     appropriate argument to the constructor. Therefore it is sufficient
>     to define the pickle interface method __getinitargs__.
>
>     For more information refer to boost/libs/python/doc/pickle.html.
>  */
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/list.hpp>
> #include <boost/python/tuple.hpp>
>
> #include <string>
>
> namespace {
>
>   // A friendly class.
>   class world
>   {
>     private:
>       std::string country;
>     public:
>       world(const std::string& country) {
>         this->country = country;
>       }
>       std::string greet() const { return "Hello from " + country + "!"; }
>       std::string get_country() const { return country; }
>   };
>
>   struct world_pickle_support : boost::python::pickle_support_base
>   {
>     static
>     boost::python::tuple
>     getinitargs(const world& w)
>     {
>         using namespace boost::python;
>         list result;
>         result.append(object(w.get_country()));
>         return tuple(result);
>     }
>   };
>
> }
>
> BOOST_PYTHON_MODULE_INIT(pickle1_ext)
> {
>   using namespace boost::python;
>   module("pickle1_ext")
>     .add(class_<world>("world")
>       .def_init(args<const std::string&>())
>       .def("greet", &world::greet)
>       .pickle_support(world_pickle_support())
>     )
>   ;
> }
>
> --- NEW FILE: pickle1.py ---
> r'''>>> import pickle1_ext
>     >>> import pickle
>     >>> pickle1_ext.world.__module__
>     'pickle1_ext'
>     >>> pickle1_ext.world.__safe_for_unpickling__
>     1
>     >>> pickle1_ext.world.__name__
>     'world'
>     >>> pickle1_ext.world('Hello').__reduce__()
>     (<class 'pickle1_ext.world'>, ('Hello',))
>     >>> wd = pickle1_ext.world('California')
>     >>> pstr = pickle.dumps(wd)
>     >>> wl = pickle.loads(pstr)
>     >>> print wd.greet()
>     Hello from California!
>     >>> print wl.greet()
>     Hello from California!
> '''
>
> def run(args = None):
>     if args is not None:
>         import sys
>         sys.argv = args
>     import doctest, pickle1
>     return doctest.testmod(pickle1)
>
> if __name__ == '__main__':
>     import sys
>     sys.exit(run()[0])
>
>
> --- NEW FILE: pickle2.cpp ---
> // Example by Ralf W. Grosse-Kunstleve
>
> /*
>     This example shows how to make an Extension Class "pickleable".
>
>     The world class below contains member data (secret_number) that
>     cannot be restored by any of the constructors. Therefore it is
>     necessary to provide the __getstate__/__setstate__ pair of pickle
>     interface methods.
>
>     For simplicity, the __dict__ is not included in the result of
>     __getstate__. This is not generally recommended, but a valid
>     approach if it is anticipated that the object's __dict__ will
>     always be empty. Note that safety guards are provided to catch
>     the cases where this assumption is not true.
>
>     pickle3.cpp shows how to include the object's __dict__ in the
>     result of __getstate__.
>
>     For more information refer to boost/libs/python/doc/pickle.html.
>  */
>
> #include <string>
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/list.hpp>
> #include <boost/python/tuple.hpp>
> #include <boost/python/extract.hpp>
> #include <boost/python/detail/api_placeholder.hpp>
>
> namespace { // Avoid cluttering the global namespace.
>
>   // A friendly class.
>   class world
>   {
>     public:
>       world(const std::string& country) : secret_number(0) {
>         this->country = country;
>       }
>       std::string greet() const { return "Hello from " + country + "!"; }
>       std::string get_country() const { return country; }
>       void set_secret_number(int number) { secret_number = number; }
>       int get_secret_number() const { return secret_number; }
>     private:
>       std::string country;
>       int secret_number;
>   };
>
>   struct world_pickle_support : boost::python::pickle_support_base
>   {
>     static
>     boost::python::tuple
>     getinitargs(const world& w)
>     {
>         using namespace boost::python;
>         list result;
>         result.append(object(w.get_country()));
>         return tuple(result);
>     }
>
>     static
>     boost::python::tuple
>     getstate(const world& w)
>     {
>         using namespace boost::python;
>         list result;
>         result.append(object(w.get_secret_number()));
>         return tuple(result);
>     }
>
>     static
>     void
>     setstate(world& w, boost::python::object state)
>     {
>         using namespace boost::python;
>         extract<tuple> state_proxy(state);
>         if (!state_proxy.check() || len(state_proxy()) != 1) {
>           PyErr_SetString(PyExc_ValueError,
>             "Unexpected argument in call to __setstate__.");
>           throw_error_already_set();
>         }
>         long number = extract<long>(state_proxy()[0])();
>         if (number != 42) w.set_secret_number(number);
>     }
>   };
>
> }
>
> BOOST_PYTHON_MODULE_INIT(pickle2_ext)
> {
>   boost::python::module("pickle2_ext")
>     .add(boost::python::class_<world>("world")
>       .def_init(boost::python::args<const std::string&>())
>       .def("greet", &world::greet)
>       .def("get_secret_number", &world::get_secret_number)
>       .def("set_secret_number", &world::set_secret_number)
>       .pickle_support(world_pickle_support())
>     )
>   ;
> }
>
> --- NEW FILE: pickle2.py ---
> r'''>>> import pickle2_ext
>     >>> import pickle
>     >>> pickle2_ext.world.__module__
>     'pickle2_ext'
>     >>> pickle2_ext.world.__safe_for_unpickling__
>     1
>     >>> pickle2_ext.world.__name__
>     'world'
>     >>> pickle2_ext.world('Hello').__reduce__()
>     (<class 'pickle2_ext.world'>, ('Hello',), (0,))
>     >>> for number in (24, 42):
>     ...   wd = pickle2_ext.world('California')
>     ...   wd.set_secret_number(number)
>     ...   pstr = pickle.dumps(wd)
>     ...   wl = pickle.loads(pstr)
>     ...   print wd.greet(), wd.get_secret_number()
>     ...   print wl.greet(), wl.get_secret_number()
>     Hello from California! 24
>     Hello from California! 24
>     Hello from California! 42
>     Hello from California! 0
>
> # Now show that the __dict__ is not taken care of.
>     >>> wd = pickle2_ext.world('California')
>     >>> wd.x = 1
>     >>> wd.__dict__
>     {'x': 1}
>     >>> try: pstr = pickle.dumps(wd)
>     ... except RuntimeError, err: print err[0]
>     ...
>     Incomplete pickle support (__getstate_manages_dict__ not set)
> '''
>
> def run(args = None):
>     if args is not None:
>         import sys
>         sys.argv = args
>     import doctest, pickle2
>     return doctest.testmod(pickle2)
>
> if __name__ == '__main__':
>     import sys
>     sys.exit(run()[0])
>
>
> --- NEW FILE: pickle3.cpp ---
> // Example by Ralf W. Grosse-Kunstleve
>
> /*
>     This example shows how to make an Extension Class "pickleable".
>
>     The world class below contains member data (secret_number) that
>     cannot be restored by any of the constructors. Therefore it is
>     necessary to provide the __getstate__/__setstate__ pair of pickle
>     interface methods.
>
>     The object's __dict__ is included in the result of __getstate__.
>     This requires more code (compare with pickle2.cpp), but is
>     unavoidable if the object's __dict__ is not always empty.
>
>     For more information refer to boost/libs/python/doc/pickle.html.
>  */
>
> #include <string>
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/list.hpp>
> #include <boost/python/tuple.hpp>
> #include <boost/python/dict.hpp>
> #include <boost/python/extract.hpp>
> #include <boost/python/detail/api_placeholder.hpp>
>
> namespace { // Avoid cluttering the global namespace.
>
>   // A friendly class.
>   class world
>   {
>     public:
>       world(const std::string& country) : secret_number(0) {
>         this->country = country;
>       }
>       std::string greet() const { return "Hello from " + country + "!"; }
>       std::string get_country() const { return country; }
>       void set_secret_number(int number) { secret_number = number; }
>       int get_secret_number() const { return secret_number; }
>     private:
>       std::string country;
>       int secret_number;
>   };
>
>   struct world_pickle_support : boost::python::pickle_support_base
>   {
>     static
>     boost::python::tuple
>     getinitargs(const world& w)
>     {
>         using namespace boost::python;
>         list result;
>         result.append(object(w.get_country()));
>         return tuple(result);
>     }
>
>     static
>     boost::python::tuple
>     getstate(boost::python::object w_obj)
>     {
>         using namespace boost::python;
>         world const& w = extract<world const&>(w_obj)();
>         list result;
>         // store the object's __dict__
>         result.append(w_obj.attr("__dict__"));
>         // store the internal state of the C++ object
>         result.append(object(w.get_secret_number()));
>         return tuple(result);
>     }
>
>     static
>     void
>     setstate(boost::python::object w_obj, boost::python::object state)
>     {
>         using namespace boost::python;
>         world& w = extract<world&>(w_obj)();
>         extract<tuple> state_proxy(state);
>         if (!state_proxy.check() || len(state_proxy()) != 2) {
>           PyErr_SetString(PyExc_ValueError,
>             "Unexpected argument in call to __setstate__.");
>           throw_error_already_set();
>         }
>         // restore the object's __dict__
>         w_obj.attr("__dict__").attr("update")(object(state_proxy()[0]));
>         // restore the internal state of the C++ object
>         long number = extract<long>(state_proxy()[1])();
>         if (number != 42) w.set_secret_number(number);
>     }
>
>     static bool getstate_manages_dict() { return true; }
>   };
>
> }
>
> BOOST_PYTHON_MODULE_INIT(pickle3_ext)
> {
>   boost::python::module("pickle3_ext")
>     .add(boost::python::class_<world>("world")
>       .def_init(boost::python::args<const std::string&>())
>       .def("greet", &world::greet)
>       .def("get_secret_number", &world::get_secret_number)
>       .def("set_secret_number", &world::set_secret_number)
>       .pickle_support(world_pickle_support())
>     )
>   ;
> }
>
> --- NEW FILE: pickle3.py ---
> r'''>>> import pickle3_ext
>     >>> import pickle
>     >>> pickle3_ext.world.__module__
>     'pickle3_ext'
>     >>> pickle3_ext.world.__safe_for_unpickling__
>     1
>     >>> pickle3_ext.world.__getstate_manages_dict__
>     1
>     >>> pickle3_ext.world.__name__
>     'world'
>     >>> pickle3_ext.world('Hello').__reduce__()
>     (<class 'pickle3_ext.world'>, ('Hello',), ({}, 0))
>     >>> for number in (24, 42):
>     ...   wd = pickle3_ext.world('California')
>     ...   wd.set_secret_number(number)
>     ...   wd.x = 2 * number
>     ...   wd.y = 'y' * number
>     ...   wd.z = 3. * number
>     ...   pstr = pickle.dumps(wd)
>     ...   wl = pickle.loads(pstr)
>     ...   print wd.greet(), wd.get_secret_number(), wd.x, wd.y, wd.z
>     ...   print wl.greet(), wl.get_secret_number(), wl.x, wl.y, wl.z
>     Hello from California! 24 48 yyyyyyyyyyyyyyyyyyyyyyyy 72.0
>     Hello from California! 24 48 yyyyyyyyyyyyyyyyyyyyyyyy 72.0
>     Hello from California! 42 84
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy 126.0
>     Hello from California! 0 84
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy 126.0
> '''
>
> def run(args = None):
>     if args is not None:
>         import sys
>         sys.argv = args
>     import doctest, pickle3
>     return doctest.testmod(pickle3)
>
> if __name__ == '__main__':
>     import sys
>     sys.exit(run()[0])
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Boost-python-cvs mailing list
> Boost-python-cvs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/boost-python-cvs





From david.abrahams at rcn.com  Sun Jul 21 13:42:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 21 Jul 2002 07:42:09 -0400
Subject: [C++-sig] Re: [Boost-python-cvs] CVS: boost/boost/python/object pickle_support.hpp,NONE,1.1
References: <E17WBSg-0008G9-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <12f101c230ab$b9253740$6501a8c0@boostconsulting.com>

More questions...

1. I don't see how your error message thing is going to cause a message to
appear under any circumstance (?)

2. Are users expected to call this "register_" function?
It would be nice to avoid that.

3. How about a "curiously recursive template" formulation,
roughly:

template <class Derived>
struct pickle_support
{
    typedef char undefined;
    undefined getintitargs;
    undefined getstate;
    undefined setstate;
    undefined getstate_manages_dict;

    // I'm not attached to using the constructor here.
    template <class Class_>
    pickle_support(Class_ c)
    {
        // Guarantees derivation of Derived.
        Derived* self = static_cast<Derived*>(this);
        register_(c,
            &Derived::getinitargs, &Derived::getstate,
            &Derived::setstate, &Derived::getstate_manages_dict);
    }
 private:
    // Definitions of appropriate register_ functions left as an exercise
};

Used as:

struct pickle_world : pickle_support<pickle_world>
{
    ...
};

???

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at users.sourceforge.net>
To: <boost-python-cvs at lists.sourceforge.net>
Sent: Sunday, July 21, 2002 3:49 AM
Subject: [Boost-python-cvs] CVS: boost/boost/python/object
pickle_support.hpp,NONE,1.1


> Update of /cvsroot/boost/boost/boost/python/object
> In directory usw-pr-cvs1:/tmp/cvs-serv31721/object
>
> Added Files:
> pickle_support.hpp
> Log Message:
> additional files for pickle support; no modification of any existing
files
>
> --- NEW FILE: pickle_support.hpp ---
> //  (C) Copyright R.W. Grosse-Kunstleve 2002.
> //  Permission to copy, use, modify, sell and distribute this software
> //  is granted provided this copyright notice appears in all copies. This
> //  software is provided "as is" without express or implied warranty, and
> //  with no claim as to its suitability for any purpose.
> #ifndef BOOST_PYTHON_OBJECT_PICKLE_SUPPORT_RWGK20020603_HPP
> #define BOOST_PYTHON_OBJECT_PICKLE_SUPPORT_RWGK20020603_HPP
>
> #include <boost/python/object/class.hpp>
> #include <boost/python/tuple.hpp>
>
> namespace boost { namespace python {
>
> handle<> make_instance_reduce_function();
>
> namespace error_messages {
>
>   template <class T>
>   struct missing_pickle_support_function_or_incorrect_signature {};
>
> }
>
> class pickle_support_base
> {
>   private:
>     struct dummy_return_type_ {};
>
>   public:
>     template <class Class_, class Tgetinitargs>
>     static
>     void
>     register_(
>       Class_& cl,
>       tuple (*getinitargs_fn)(Tgetinitargs),
>       dummy_return_type_* (*getstate_fn)(),
>       dummy_return_type_* (*setstate_fn)(),
>       bool)
>     {
>       cl.enable_pickle_support(false);
>       cl.def("__getinitargs__", getinitargs_fn);
>     }
>
>     template <class Class_, class Tgetstate, class Tsetstate>
>     static
>     void
>     register_(
>       Class_& cl,
>       dummy_return_type_* (*getinitargs_fn)(),
>       tuple (*getstate_fn)(Tgetstate),
>       void (*setstate_fn)(Tsetstate, object),
>       bool getstate_manages_dict)
>     {
>       cl.enable_pickle_support(getstate_manages_dict);
>       cl.def("__getstate__", getstate_fn);
>       cl.def("__setstate__", setstate_fn);
>     }
>
>     template <class Class_,
>               class Tgetinitargs, class Tgetstate, class Tsetstate>
>     static
>     void
>     register_(
>       Class_& cl,
>       tuple (*getinitargs_fn)(Tgetinitargs),
>       tuple (*getstate_fn)(Tgetstate),
>       void (*setstate_fn)(Tsetstate, object),
>       bool getstate_manages_dict)
>     {
>       cl.enable_pickle_support(getstate_manages_dict);
>       cl.def("__getinitargs__", getinitargs_fn);
>       cl.def("__getstate__", getstate_fn);
>       cl.def("__setstate__", setstate_fn);
>     }
>
>     template <class Class_>
>     static
>     void
>     register_(
>       Class_&,
>       ...)
>     {
>       typedef typename
>
error_messages::missing_pickle_support_function_or_incorrect_signature<
>           Class_>::error_type error_type;
>     }
>
>     static dummy_return_type_* getinitargs() { return 0; }
>     static dummy_return_type_* getstate() { return 0; }
>     static dummy_return_type_* setstate() { return 0; }
>
>     static bool getstate_manages_dict() { return false; }
> };
>
> }} // namespace boost::python
>
> #endif // BOOST_PYTHON_OBJECT_PICKLE_SUPPORT_RWGK20020603_HPP
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Boost-python-cvs mailing list
> Boost-python-cvs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/boost-python-cvs





From david.abrahams at rcn.com  Sun Jul 21 13:45:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 21 Jul 2002 07:45:49 -0400
Subject: [C++-sig] additional files for pickle support
References: <20020721101302.38364.qmail@web20209.mail.yahoo.com>
Message-ID: <130d01c230ac$6c591200$6501a8c0@boostconsulting.com>

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


> --- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> > The new files have been tested with gcc 3.0.4, cxx 6.5 (tru64) and VC6.
I am
> > about to experiment with an idea for hiding the entire implementation
except
> > for the one new member function of class_<> (.pickle_support(); not
currently
> > in cvs). Having the current, functional implementation in cvs will
allow me
> > to
> > work most efficiently (I can easily back up or look at diffs if
necessary).
>
> OK, done experimenting. David, now would be a good time to criticize the
new
> files.

Whoops, I criticized too soon! I'll look.

> Three additional patches are attached for your reference. The only other
> changes are trivial additions to the Jamfiles.

OK, thanks.

> Locally I am currently working with
> #include <boost/python/detail/api_placeholder.hpp>
> This file implements len() and getattr(). I don't think you want this in
cvs.
> So before I can check in the patches that complete the integration of the
> pickle support there need to be replacements for my len() and getattr().
>
> Ralf






From david.abrahams at rcn.com  Sun Jul 21 14:57:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 21 Jul 2002 08:57:56 -0400
Subject: [C++-sig] additional files for pickle support
References: <20020721101302.38364.qmail@web20209.mail.yahoo.com>
Message-ID: <134801c230b6$3df7b420$6501a8c0@boostconsulting.com>

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

> OK, done experimenting. David, now would be a good time to criticize the
new
> files.

Nice!

Question: Why not just have this function accept a tuple argument instead
of doing your own error checking?

    static
    void
    setstate(world& w, boost::python::object state)
    {
        using namespace boost::python;
        extract<tuple> state_proxy(state);
        if (!state_proxy.check() || len(state_proxy()) != 1) {
          PyErr_SetString(PyExc_ValueError,
            "Unexpected argument in call to __setstate__.");
          throw_error_already_set();
        }


> Three additional patches are attached for your reference. The only other
> changes are trivial additions to the Jamfiles.
>
> Locally I am currently working with
> #include <boost/python/detail/api_placeholder.hpp>
> This file implements len() and getattr(). I don't think you want this in
cvs.

I guess not in the long run, but as a temporary measure it's fine.

> So before I can check in the patches that complete the integration of the
> pickle support there need to be replacements for my len() and getattr().

I'm not sure what's happening with Dave H. at the moment, but it will be
easy enough to replace your versions when his are ready.

> P.S.: I noticed that class_::setattr() still deals with handle<> .
> Is this going to change?

I hope so. I'm going to try making class_<> into a class derived from
object, to see how that goes. Then it would be:

    .attr("foo") = ... ;

Hmm, you can't just dump setattr, because the above won't chain. We could
adopt a Phoenix-like construct:

    class_<X>("X")
    [
        attr("foo") = 33,
        def("bar", &bar),
        ...
    ];


But I'm still nervous about that; I think it would put a huge burden on
many compilers.

> Index: class.hpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/boost/python/class.hpp,v
> retrieving revision 1.27
> diff -r1.27 class.hpp
> 27a28
> > # include <boost/python/object/pickle_support.hpp>
> 196a198,210
> >
> >     // Pickle support
> >     template <typename PickleSupport>
> >     self& pickle_support(PickleSupport)
> >     {
> >       detail::pickle_support_finalize<PickleSupport>::register_(
> >         *this,
> >         &PickleSupport::getinitargs,
> >         &PickleSupport::getstate,
> >         &PickleSupport::setstate,
> >         PickleSupport::getstate_manages_dict());
> >       return *this;
> >     }


I know you'll be impatient with me about this, but I would love to find a
better name than "pickle_support". Let's explore a little.

    .pickle_via(world_pickling())
    .def_pickle(world_pickle())

Hmm, I'm out of ideas :(

Well, here's another one, which I'm sure you'll really love <wink>: used a
named parameter interface like that used in Boost.Graph
http://www.boost.org/libs/graph/doc/bgl_named_params.html

class<X>("X")
    .def_pickle(getinitargs(&world_getinitargs)
                .getstate(&world_getstate)
                .setstate(&world_setstate))
    ...
    ;


> Index: object/class.hpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/boost/python/object/class.hpp,v
> retrieving revision 1.22
> diff -r1.22 class.hpp
> 41a42
> >     void enable_pickle_support(bool getstate_manages_dict);
>
>
> Index: src/object/class.cpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/libs/python/src/object/class.cpp,v
> retrieving revision 1.31
> diff -r1.31 class.cpp
> 8a9
> > #include <boost/python/object/pickle_support.hpp>
> 304a306,315
> >   }
> >
> >   void class_base::enable_pickle_support(bool getstate_manages_dict)
> >   {
> >       setattr("__reduce__", make_instance_reduce_function());
> >       handle<> one(PyInt_FromLong(1));
> >       setattr("__safe_for_unpickling__", one);
> >       if (getstate_manages_dict) {
> >         setattr("__getstate_manages_dict__", one);
> >       }

Looks fine to me. I guess I'd go with def_pickle() and pickle as
substitutes for pickle_support() and pickle_support_base. At least, those
are my current favorite ideas.

-Dave






From rwgk at yahoo.com  Mon Jul 22 08:01:09 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 21 Jul 2002 23:01:09 -0700 (PDT)
Subject: [C++-sig] additional files for pickle support
In-Reply-To: <134801c230b6$3df7b420$6501a8c0@boostconsulting.com>
Message-ID: <20020722060109.64663.qmail@web20210.mail.yahoo.com>

> Can we discuss different names for "pickle_support_base" please?
> I'm in favor of "pickler". Thus, world_pickle_support is-a
> boost::python::pickler. I realize it's also an unpickler, so if you don't
> like that I'd like to at least find a way to drop "_base" from any public
> names.

pickle_support_base -> pickle_group
.pickle_support() -> .def_pickle()

> 1. I don't see how your error message thing is going to cause a message to
> appear under any circumstance (?)

After renaming setstate to xxsetstate:

tru64cxx65-C++-action
/net/redbelly/scratch1/rwgk/bjam/libs/python/test/bin/pickle3_ext.so/tru64cxx65/debug/pickle3.o
cxx: Error:
/tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/python/object/pickle_support.hpp,
line 98: #135 
          class
          "boost::python::error_messages::missing_pickle_group_function_or_inco
          rrect_signature<boost::python::class_<<unnamed>::world,
          boost::python::detail::not_specified,
          ...

BTW: I think it would be nice if all compile-time error messages
were in namespace boost::python::error_messages .

> 2. Are users expected to call this "register_" function?
> It would be nice to avoid that.

The register_ function is now hidden in namespace detail. I could
not simply make it private because some compilers do not support
template friends.

> 3. How about a "curiously recursive template" formulation,
> ...
> struct pickle_world : pickle_support<pickle_world>

Cool trick! However, the user interface is more complicated than
it is in my current implementation:

struct world_pickle_group : pickle_group

> Question: Why not just have this function accept a tuple argument instead
> of doing your own error checking?
> 
>     static
>     void
>     setstate(world& w, boost::python::object state)
>     {
>         using namespace boost::python;
>         extract<tuple> state_proxy(state);
>         if (!state_proxy.check() || len(state_proxy()) != 1) {
>           PyErr_SetString(PyExc_ValueError,
>             "Unexpected argument in call to __setstate__.");
>           throw_error_already_set();
>         }

I chose object over tuple because I want my error message to appear
under as many circumstances as possible.

> > Locally I am currently working with
> > #include <boost/python/detail/api_placeholder.hpp>
> > This file implements len() and getattr(). I don't think you want this in
> cvs.
> 
> I guess not in the long run, but as a temporary measure it's fine.

OK, I am working towards checking in the complete set of patches.
(Then you can convince yourself that the compile-time error messages
really work.)

> I hope so. I'm going to try making class_<> into a class derived from
> object, to see how that goes. Then it would be:
> 
>     .attr("foo") = ... ;
> 
> Hmm, you can't just dump setattr, because the above won't chain. We could
> adopt a Phoenix-like construct:
> 
> ...
> 
> But I'm still nervous about that; I think it would put a huge burden on
> many compilers.

I am /very/ nervous about these ideas. It is highly important to us
that V2 will be stable enough for routine use as soon as possible.
Collaborators keep asking about V2 and is getting more and more
difficult to keep them interested. Maybe it is time to start a list
of potential V3 projects.
BTW: what is the status of the mpl1 -> mpl2 transition, and how
much instability will this generate for how long?

> Well, here's another one, which I'm sure you'll really love <wink>: used a
> named parameter interface like that used in Boost.Graph
> http://www.boost.org/libs/graph/doc/bgl_named_params.html

Cool trick again! However, the prime motivations behind the pickle_group
design are 1. to establish a formal grouping of the pickle/unpickle
functions and 2. to fully relieve the user from thinking about
the individual functions at the point of binding them via .def_pickle().
In addition we have the compile-time consistency checks (which is
the only reason for the requirement that the user pickle group must
inherit from boost::python::pickle_group).

> >   void class_base::enable_pickle_support(bool getstate_manages_dict)
> >   {
> >       setattr("__reduce__", make_instance_reduce_function());
> >       handle<> one(PyInt_FromLong(1));
> >       setattr("__safe_for_unpickling__", one);
> >       if (getstate_manages_dict) {
> >         setattr("__getstate_manages_dict__", one);
> >       }

BTW: I will change this to work with object as soon as setattr()
is modified accordingly.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Mon Jul 22 08:51:35 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 21 Jul 2002 23:51:35 -0700 (PDT)
Subject: [C++-sig] VC6 extract.cpp warning
Message-ID: <20020722065135.65106.qmail@web20209.mail.yahoo.com>

By chance I noticed this VC6 warning:

extrac.cpp(50) : warning C4172: returning address of local variable or
temporary

Is this something to worry about?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Mon Jul 22 09:26:09 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 00:26:09 -0700 (PDT)
Subject: [C++-sig] pickle support patches checked in
Message-ID: <20020722072609.55851.qmail@web20202.mail.yahoo.com>

I have just checked in the patches that complete the pickle support.
This is tested with VC6, CodeWarrior 7.2, cxx 6.5 and gcc 3.0.4.
If the 8-platform auto-build in a few minutes shows any problems I will
address them tomorrow morning.

Regarding documentation: there is one additional class_<> member
function: def_pickle(). I am uncertain how to document pickle_group.
The public static functions are of no value to the user. They are just
there to enable the compile-time error messages(**). Would it be best
to just document a "pickle_group concept?"

Ralf

(**) It would help in my case if C++ had smarter rules for resolving:

struct base { static void foo(); }
struct user { static void foo(); }
struct merge : user, base
{
};

merge::foo(); // according to the current standard "ambiguous"

I also tried:

struct base { static void foo(); }
struct user { static void foo(); }
struct intermediate : base {}; // to create "a larger distance"
struct merge : user, intermediate
{
};

merge::foo(); // still "ambiguous"

Isn't that a real obstacle to meta-programming?


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 13:40:35 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 07:40:35 -0400
Subject: [C++-sig] VC6 extract.cpp warning
References: <20020722065135.65106.qmail@web20209.mail.yahoo.com>
Message-ID: <151301c23175$06eee790$6501a8c0@boostconsulting.com>

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


> By chance I noticed this VC6 warning:
> 
> extrac.cpp(50) : warning C4172: returning address of local variable or
> temporary
> 
> Is this something to worry about?

Not in this case. The compiler is lying :(

-Dave






From david.abrahams at rcn.com  Mon Jul 22 14:09:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 08:09:34 -0400
Subject: [C++-sig] additional files for pickle support
References: <20020722060109.64663.qmail@web20210.mail.yahoo.com>
Message-ID: <152e01c23179$3c634de0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 22, 2002 2:01 AM
Subject: Re: [C++-sig] additional files for pickle support


> > Can we discuss different names for "pickle_support_base" please?
> > I'm in favor of "pickler". Thus, world_pickle_support is-a
> > boost::python::pickler. I realize it's also an unpickler, so if you
don't
> > like that I'd like to at least find a way to drop "_base" from any
public
> > names.
>
> pickle_support_base -> pickle_group

Hmm, what about just "pickle_functions"?

> .pickle_support() -> .def_pickle()
>
> > 1. I don't see how your error message thing is going to cause a message
to
> > appear under any circumstance (?)
>
> After renaming setstate to xxsetstate:
>
> tru64cxx65-C++-action
>
/net/redbelly/scratch1/rwgk/bjam/libs/python/test/bin/pickle3_ext.so/tru64c
xx65/debug/pickle3.o
> cxx: Error:
>
/tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/python/object/pickle_supp
ort.hpp,
> line 98: #135
>           class
>
"boost::python::error_messages::missing_pickle_group_function_or_inco
>           rrect_signature<boost::python::class_<<unnamed>::world,
>           boost::python::detail::not_specified,
>           ...

I'll look again.

> BTW: I think it would be nice if all compile-time error messages
> were in namespace boost::python::error_messages .

I agree, something like that would be nice.

> > 2. Are users expected to call this "register_" function?
> > It would be nice to avoid that.
>
> The register_ function is now hidden in namespace detail. I could
> not simply make it private because some compilers do not support
> template friends.

That's fine.

> > 3. How about a "curiously recursive template" formulation,
> > ...
> > struct pickle_world : pickle_support<pickle_world>
>
> Cool trick! However, the user interface is more complicated than
> it is in my current implementation:
>
> struct world_pickle_group : pickle_group

Yep.

> > Question: Why not just have this function accept a tuple argument
instead
> > of doing your own error checking?
> >
> >     static
> >     void
> >     setstate(world& w, boost::python::object state)
> >     {
> >         using namespace boost::python;
> >         extract<tuple> state_proxy(state);
> >         if (!state_proxy.check() || len(state_proxy()) != 1) {
> >           PyErr_SetString(PyExc_ValueError,
> >             "Unexpected argument in call to __setstate__.");
> >           throw_error_already_set();
> >         }
>
> I chose object over tuple because I want my error message to appear
> under as many circumstances as possible.

Hmm, I'm very doubtful it's worth the complexity and extra code this costs.
"Unexpected argument..." is not nearly as helpful as "expected a tuple of
length 1, got ... instead", nor as helpful as the message the overloading
mechanism will eventually give to describe failed argument matching.


> > I hope so. I'm going to try making class_<> into a class derived from
> > object, to see how that goes. Then it would be:
> >
> >     .attr("foo") = ... ;
> >
> > Hmm, you can't just dump setattr, because the above won't chain. We
could
> > adopt a Phoenix-like construct:
> >
> > ...
> >
> > But I'm still nervous about that; I think it would put a huge burden on
> > many compilers.
>
> I am /very/ nervous about these ideas.

Which ideas? Don't worry, I'm not doing the Phoenix-syntax thing anytime
soon.

> It is highly important to us
> that V2 will be stable enough for routine use as soon as possible.

I agree.

> Collaborators keep asking about V2 and is getting more and more
> difficult to keep them interested. Maybe it is time to start a list
> of potential V3 projects.

V3? No, it's not time for that. For V2.01 et al. I already have a list.

> BTW: what is the status of the mpl1 -> mpl2 transition, and how
> much instability will this generate for how long?

I've asked Joel de Guzman to look into it, and I'm waiting for him to get
back to me about it. It should not cause any instability or changes to the
public interface.

> > Well, here's another one, which I'm sure you'll really love <wink>:
used a
> > named parameter interface like that used in Boost.Graph
> > http://www.boost.org/libs/graph/doc/bgl_named_params.html
>
> Cool trick again! However, the prime motivations behind the pickle_group
> design are 1. to establish a formal grouping of the pickle/unpickle
> functions and 2. to fully relieve the user from thinking about
> the individual functions at the point of binding them via .def_pickle().
> In addition we have the compile-time consistency checks (which is
> the only reason for the requirement that the user pickle group must
> inherit from boost::python::pickle_group).

Actually, the named parameter interface also allows you to do the
consistency checks. Each method call in the chain builds a new type which
includes the information about which of them has been called.

The pickle group design is fine, though.

> > >   void class_base::enable_pickle_support(bool getstate_manages_dict)
> > >   {
> > >       setattr("__reduce__", make_instance_reduce_function());
> > >       handle<> one(PyInt_FromLong(1));
> > >       setattr("__safe_for_unpickling__", one);
> > >       if (getstate_manages_dict) {
> > >         setattr("__getstate_manages_dict__", one);
> > >       }
>
> BTW: I will change this to work with object as soon as setattr()
> is modified accordingly.

What modification were you expecting?

-Dave






From david.abrahams at rcn.com  Mon Jul 22 14:25:25 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 08:25:25 -0400
Subject: [C++-sig] pickle support patches checked in
References: <20020722072609.55851.qmail@web20202.mail.yahoo.com>
Message-ID: <153701c2317a$dcb18db0$6501a8c0@boostconsulting.com>

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


> I have just checked in the patches that complete the pickle support.
> This is tested with VC6, CodeWarrior 7.2, cxx 6.5 and gcc 3.0.4.
> If the 8-platform auto-build in a few minutes shows any problems I will
> address them tomorrow morning.
>
> Regarding documentation: there is one additional class_<> member
> function: def_pickle(). I am uncertain how to document pickle_group.
> The public static functions are of no value to the user. They are just
> there to enable the compile-time error messages(**). Would it be best
> to just document a "pickle_group concept?"

Probably not, because everyone will want to use your base class; there's no
disadvantage.
However, it would be nice if you'd enforce that they used your base class
by attempting to convert to a pickle_fucntions*.

> (**) It would help in my case if C++ had smarter rules for resolving:
>
> struct base { static void foo(); }
> struct user { static void foo(); }
> struct merge : user, base
> {
> };
>
> merge::foo(); // according to the current standard "ambiguous"
>
> I also tried:
>
> struct base { static void foo(); }
> struct user { static void foo(); }
> struct intermediate : base {}; // to create "a larger distance"
> struct merge : user, intermediate
> {
> };
>
> merge::foo(); // still "ambiguous"
>
> Isn't that a real obstacle to meta-programming?

Not really. You just want to detect the presence of a member, and
conforming compilers will already do that. However, most of your compilers
don't conform.


template <int> struct sz {};

// overload resolution fails if no some_member member
template <class T>
char has_some_member_helper(sz<sizeof(T::some_member)>*);

// This one gets selected instead
template <class T> char(& has_some_member_helper(...) )[4];

// Here's the user-friendly template
template <class T>
struct has_some_member
{
    static bool const value = (
        sizeof(has_some_member_helper<T>(0)) == sizeof(char));
};

-Davew





From david.abrahams at rcn.com  Mon Jul 22 18:05:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 12:05:22 -0400
Subject: [C++-sig] object().attr_allow_null()
References: <20020720185600.18908.qmail@web20206.mail.yahoo.com>
Message-ID: <168601c23199$cc9ec630$6501a8c0@boostconsulting.com>

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

>
> >      if (is(getinitargs,object())) // otherwise...
>
> Isn't this expensive, both in terms of code generated and performance
wise?
> And it doesn't look like Python!
> This leads me to
>
>        if (!getinitargs.is_none())

What about:

    if (!getinitargs.is(None))

?

An "is" member function for object doesn't seem like complete nonsense to
me.

In the meantime, if you're worried about cycles:

    if (getinitargs.ptr() != Py_None)

-Dave





From rwgk at yahoo.com  Mon Jul 22 19:04:05 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 10:04:05 -0700 (PDT)
Subject: [C++-sig] object().attr_allow_null()
In-Reply-To: <168601c23199$cc9ec630$6501a8c0@boostconsulting.com>
Message-ID: <20020722170405.50939.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> >
> > >      if (is(getinitargs,object())) // otherwise...
> >
> > Isn't this expensive, both in terms of code generated and performance
> wise?
> > And it doesn't look like Python!
> > This leads me to
> >
> >        if (!getinitargs.is_none())
> 
> What about:
> 
>     if (!getinitargs.is(None))
> 
> ?
> 
> An "is" member function for object doesn't seem like complete nonsense to
> me.

I very much like this idea. But let me ask anyway:
If is() were a free function, what signature(s) would it have?
Just one overload: is(object a0, object a1)?

> In the meantime, if you're worried about cycles:
> 
>     if (getinitargs.ptr() != Py_None)


From david.abrahams at rcn.com  Mon Jul 22 19:08:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 13:08:14 -0400
Subject: [C++-sig] object().attr_allow_null()
References: <20020722170405.50939.qmail@web20202.mail.yahoo.com>
Message-ID: <16d701c231a2$972d8140$6501a8c0@boostconsulting.com>

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

> I very much like this idea. But let me ask anyway:
> If is() were a free function, what signature(s) would it have?
> Just one overload: is(object a0, object a1)?

    is(object const&, object const&); // for efficiency

No point in checking the object identity of non-objects ;-)
Hmmn, I take it back; you ought to be able to pass, e.g. NumPyArray* here.
Anyway, the single signature above will do for the time being.

> > In the meantime, if you're worried about cycles:
> > 
> >     if (getinitargs.ptr() != Py_None)
> 
> From src/object/pickle_support.cpp:
> 
> object none;
> ...
> if (getinitargs.ptr() != none.ptr())
> 
> Is your None above the same is my none here?

Yeah, 'xcept it would be provided by the library.

-Dave






From rwgk at yahoo.com  Mon Jul 22 19:51:57 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 10:51:57 -0700 (PDT)
Subject: [C++-sig] additional files for pickle support
In-Reply-To: <152e01c23179$3c634de0$6501a8c0@boostconsulting.com>
Message-ID: <20020722175157.12918.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > pickle_support_base -> pickle_group
> 
> Hmm, what about just "pickle_functions"?

I am trying to emphasize that the collection of pickle support functions for
one type form one entity. IMO "group" (singular) does this better than
"functions" (plural).
Anyway, if you have strong opinions about this please feel free to make the
changes you'd like to see.

> "boost::python::error_messages::missing_pickle_group_function_or_inco
> >           rrect_signature<boost::python::class_<<unnamed>::world,
> >           boost::python::detail::not_specified,
> >           ...
> 
> I'll look again.

Is there a framework for having tests that are supposed to fail at
compile-time? Then I could make a few pickle1_fail.cpp, pickle2_fail.cpp etc.
files.

> > I am /very/ nervous about these ideas.
> 
> Which ideas? Don't worry, I'm not doing the Phoenix-syntax thing anytime
> soon.

Phew. It would help if you could more often indicate what is brain-storming and
what is in fact planned for the nearer future.
 
> > Collaborators keep asking about V2 and is getting more and more
> > difficult to keep them interested. Maybe it is time to start a list
> > of potential V3 projects.
> 
> V3? No, it's not time for that. For V2.01 et al. I already have a list.

What I mean is that I hope to see radical changes such as adoption of the
Phoenix syntax on the V3 list rather than any 2.x list.
 
> > BTW: what is the status of the mpl1 -> mpl2 transition, and how
> > much instability will this generate for how long?
> 
> I've asked Joel de Guzman to look into it, and I'm waiting for him to get
> back to me about it. It should not cause any instability or changes to the
> public interface.

I am anxious to get past that transition. Mainly to make sure our collaborators
(non-computer scientists!) will not have to deal with "road construction ahead"
signs.
 
> Actually, the named parameter interface also allows you to do the
> consistency checks. Each method call in the chain builds a new type which
> includes the information about which of them has been called.
> 
> The pickle group design is fine, though.

Phew. (The alloted time to beat on the pickle support is up anyway.)

> > > >   void class_base::enable_pickle_support(bool getstate_manages_dict)
> > > >   {
> > > >       setattr("__reduce__", make_instance_reduce_function());
> > > >       handle<> one(PyInt_FromLong(1));
> > > >       setattr("__safe_for_unpickling__", one);
> > > >       if (getstate_manages_dict) {
> > > >         setattr("__getstate_manages_dict__", one);
> > > >       }
> >
> > BTW: I will change this to work with object as soon as setattr()
> > is modified accordingly.
> 
> What modification were you expecting?

self& setattr(char const* name, object);

or

self& setattr(char const* name, object const&);

BTW: since the only data member in object is a pointer, does it make sense to
pass a const& (i.e. a pointer to the contained pointer) instead of just a copy
of object (i.e. the contained pointer itself)?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 20:02:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 14:02:12 -0400
Subject: [C++-sig] additional files for pickle support
References: <20020722175157.12918.qmail@web20204.mail.yahoo.com>
Message-ID: <172101c231a9$f79e0e80$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 22, 2002 1:51 PM
Subject: Re: [C++-sig] additional files for pickle support


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > pickle_support_base -> pickle_group
> >
> > Hmm, what about just "pickle_functions"?
>
> I am trying to emphasize that the collection of pickle support functions
for
> one type form one entity. IMO "group" (singular) does this better than
> "functions" (plural).
> Anyway, if you have strong opinions about this please feel free to make
the
> changes you'd like to see.

No, I just want to experiment with naming before things get too solid. A
really good name improves the feel of a library immensely.

So, what about "pickle_suite" (not to be confused with sweet_pickle)?
Or more whimsically, "vinegar_and_spices" <wink>.

Seriously, I like "suite" a little better than "group" because it has more
of the right connotations.

> Is there a framework for having tests that are supposed to fail at
> compile-time? Then I could make a few pickle1_fail.cpp, pickle2_fail.cpp
etc.
> files.

Yep, see the end of the test Jamfile. Those tests are normally off but you
can enable them from the command-line with -sTEST_EXPECTED_FAILURES=1

> > Which ideas? Don't worry, I'm not doing the Phoenix-syntax thing
anytime
> > soon.
>
> Phew. It would help if you could more often indicate what is
brain-storming and
> what is in fact planned for the nearer future.

When I say "we could do X, but I'm not confident about it" you can trust
that I'm not about to take action on it.

> > V3? No, it's not time for that. For V2.01 et al. I already have a list.
>
> What I mean is that I hope to see radical changes such as adoption of the
> Phoenix syntax on the V3 list rather than any 2.x list.

Agreed. At least, I wouldn't deprecate existing syntaxes.

> > > BTW: what is the status of the mpl1 -> mpl2 transition, and how
> > > much instability will this generate for how long?
> >
> > I've asked Joel de Guzman to look into it, and I'm waiting for him to
get
> > back to me about it. It should not cause any instability or changes to
the
> > public interface.
>
> I am anxious to get past that transition. Mainly to make sure our
collaborators
> (non-computer scientists!) will not have to deal with "road construction
ahead"
> signs.

Yep. I think that'll take a few days at most, and Joel has agreed to start
tomorrow.

> > The pickle group design is fine, though.
>
> Phew. (The alloted time to beat on the pickle support is up anyway.)

Good.

> > > BTW: I will change this to work with object as soon as setattr()
> > > is modified accordingly.
> >
> > What modification were you expecting?
>
> self& setattr(char const* name, object);
>
> or
>
> self& setattr(char const* name, object const&);

Ah, of course.

> BTW: since the only data member in object is a pointer, does it make
sense to
> pass a const& (i.e. a pointer to the contained pointer) instead of just a
copy
> of object (i.e. the contained pointer itself)?

Yep, it saves code generation for incref and most especially decref, which
also generates code to destroy the object in case ob_refcnt == 0.

-Dave






From rwgk at yahoo.com  Mon Jul 22 20:09:24 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 11:09:24 -0700 (PDT)
Subject: [C++-sig] pickle support patches checked in
In-Reply-To: <153701c2317a$dcb18db0$6501a8c0@boostconsulting.com>
Message-ID: <20020722180924.17913.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> However, it would be nice if you'd enforce that they used your base class
> by attempting to convert to a pickle_fucntions*.

This additional check seemed highly redundant to me. Yes, if someone correctly
supplies all four static functions in the pickle group it will work without the
derivation, but then the compile-time check is not needed. If any signature is
wrong or any of the four functions is missing there will be a "controlled"
compile-time error anyway.
Hm, maybe it would be nice to generate a different compile-time error
"must_inherit_from_pickle_group" just to give a better clue. Could this be
done?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Mon Jul 22 20:18:45 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 11:18:45 -0700 (PDT)
Subject: [C++-sig] strange auto-build problem
Message-ID: <20020722181845.84405.qmail@web20210.mail.yahoo.com>

The Codewarrior 8 under Windows200 auto-build is failing with messages that I
have not seen before. The CW72 auto-build works fine, and when I run the bjam
command for CW80 at the prompt everything works just fine. David, could you
please have a quick look at http://cci.lbl.gov/boost ? Maybe you have a clue
right away?
One difference between auto-build/manual bjam that comes to mind is that the
pathnames in the auto-build environment are longer. Could this be the problem?
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 20:19:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 14:19:07 -0400
Subject: [C++-sig] pickle support patches checked in
References: <20020722180924.17913.qmail@web20204.mail.yahoo.com>
Message-ID: <173b01c231ac$45d7c620$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > However, it would be nice if you'd enforce that they used your base
class
> > by attempting to convert to a pickle_fucntions*.
>
> This additional check seemed highly redundant to me. Yes, if someone
correctly
> supplies all four static functions in the pickle group it will work
without the
> derivation, but then the compile-time check is not needed. If any
signature is
> wrong or any of the four functions is missing there will be a
"controlled"
> compile-time error anyway.

I see.

> Hm, maybe it would be nice to generate a different compile-time error
> "must_inherit_from_pickle_group" just to give a better clue. Could this
be
> done?

Just pass a pointer to the group to a function accepting pickle_group const
volatile*

-D





From rwgk at yahoo.com  Mon Jul 22 20:25:16 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 11:25:16 -0700 (PDT)
Subject: [C++-sig] object().attr_allow_null()
In-Reply-To: <16d701c231a2$972d8140$6501a8c0@boostconsulting.com>
Message-ID: <20020722182516.47333.qmail@web20207.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > I very much like this idea. But let me ask anyway:
> > If is() were a free function, what signature(s) would it have?
> > Just one overload: is(object a0, object a1)?
> 
>     is(object const&, object const&); // for efficiency
> 
> No point in checking the object identity of non-objects ;-)
> Hmmn, I take it back; you ought to be able to pass, e.g. NumPyArray* here.
> Anyway, the single signature above will do for the time being.

Hm. Don't you want is() to be symmetric?

is(a,b)
is(b,a)

Now, if is() is a member function of object, but b may not be of type object,
you break the symmetry.

Then is(getinitargs, None) would seem to be the better solution.

BTW: how could it be None (upper case) in a boost library? Isn't that bending
the (your!?) rules?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 20:26:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 14:26:08 -0400
Subject: [C++-sig] strange auto-build problem
References: <20020722181845.84405.qmail@web20210.mail.yahoo.com>
Message-ID: <174701c231ad$adb2e1c0$6501a8c0@boostconsulting.com>

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


> The Codewarrior 8 under Windows200

That's your problem right there. We don't support Win2C <wink>.

> auto-build is failing with messages that I
> have not seen before. The CW72 auto-build works fine, and when I run the
bjam
> command for CW80 at the prompt everything works just fine. David, could
you
> please have a quick look at http://cci.lbl.gov/boost ? Maybe you have a
clue
> right away?
> One difference between auto-build/manual bjam that comes to mind is that
the
> pathnames in the auto-build environment are longer. Could this be the
problem?

It's possible. Hmm, doesn't seem likely. The longest line in your output is
~436 characers.
What happens if you put -ofoo.bat in the auto-build command-line and then
invoke foo.bat?






From rwgk at yahoo.com  Mon Jul 22 20:34:25 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 11:34:25 -0700 (PDT)
Subject: [C++-sig] additional files for pickle support
In-Reply-To: <172101c231a9$f79e0e80$6501a8c0@boostconsulting.com>
Message-ID: <20020722183425.77548.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > I am trying to emphasize that the collection of pickle support functions
> for
> > one type form one entity. IMO "group" (singular) does this better than
> > "functions" (plural).
> > Anyway, if you have strong opinions about this please feel free to make
> the
> > changes you'd like to see.
> 
> No, I just want to experiment with naming before things get too solid. A
> really good name improves the feel of a library immensely.
> 
> So, what about "pickle_suite" (not to be confused with sweet_pickle)?
> Or more whimsically, "vinegar_and_spices" <wink>.
> 
> Seriously, I like "suite" a little better than "group" because it has more
> of the right connotations.

OK, pickle_suite it shall be. Hang on for the patches. (And with this I will
close the chapter on naming.)

> Yep, see the end of the test Jamfile. Those tests are normally off but you
> can enable them from the command-line with -sTEST_EXPECTED_FAILURES=1

I will give it a try.

> > I am anxious to get past that transition. Mainly to make sure our
> collaborators
> > (non-computer scientists!) will not have to deal with "road construction
> ahead"
> > signs.
> 
> Yep. I think that'll take a few days at most, and Joel has agreed to start
> tomorrow.

Cool. If we could have a stable V2 (i.e. a release) before the middle of
September that would be a tremendous benefit for us.

> Yep, it saves code generation for incref and most especially decref, which
> also generates code to destroy the object in case ob_refcnt == 0.

Thanks for the explanation!

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 20:35:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 14:35:04 -0400
Subject: [C++-sig] object().attr_allow_null()
References: <20020722182516.47333.qmail@web20207.mail.yahoo.com>
Message-ID: <176a01c231af$161a85f0$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> >
> > > I very much like this idea. But let me ask anyway:
> > > If is() were a free function, what signature(s) would it have?
> > > Just one overload: is(object a0, object a1)?
> >
> >     is(object const&, object const&); // for efficiency
> >
> > No point in checking the object identity of non-objects ;-)
> > Hmmn, I take it back; you ought to be able to pass, e.g. NumPyArray*
here.
> > Anyway, the single signature above will do for the time being.
>
> Hm. Don't you want is() to be symmetric?
>
> is(a,b)
> is(b,a)
>
> Now, if is() is a member function of object, but b may not be of type
object,
> you break the symmetry.

I don't really care all that  much, but:

    object(x).is(y) looks OK to me.

> Then is(getinitargs, None) would seem to be the better solution.
>
> BTW: how could it be None (upper case) in a boost library? Isn't that
bending
> the (your!?) rules?

Yep. Ain't life grand?

-Dave





From david.abrahams at rcn.com  Mon Jul 22 20:50:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 14:50:40 -0400
Subject: [C++-sig] additional files for pickle support
References: <20020722183425.77548.qmail@web20209.mail.yahoo.com>
Message-ID: <177201c231b0$aec1b250$6501a8c0@boostconsulting.com>

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

> Cool. If we could have a stable V2 (i.e. a release) before the middle of
> September that would be a tremendous benefit for us.

I think we're extremely close. I'd guarantee Aug 15th, but I'm going on
vacation in the beginning of August.

-Dave







From rwgk at yahoo.com  Mon Jul 22 21:02:26 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 12:02:26 -0700 (PDT)
Subject: [C++-sig] object().attr_allow_null()
In-Reply-To: <176a01c231af$161a85f0$6501a8c0@boostconsulting.com>
Message-ID: <20020722190226.29324.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > > Hmmn, I take it back; you ought to be able to pass, e.g. NumPyArray*
> I don't really care all that  much, but:

...
 
>     object(x).is(y) looks OK to me.

I am with you.
Please allow another question for my edification: if x is a NumPyArray* (a
pointer to a PyObject) what will object(x) do? How does it know that
NumPyArray* is already a PyObject? Is it this?
lvalue_from_pytype<extract_identity<NumPyArray>,&NumPyArray>();
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 21:27:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 15:27:12 -0400
Subject: [C++-sig] object().attr_allow_null()
References: <20020722190226.29324.qmail@web20204.mail.yahoo.com>
Message-ID: <17cb01c231b6$52ccfd50$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > > Hmmn, I take it back; you ought to be able to pass, e.g.
NumPyArray*
> > I don't really care all that  much, but:
>
> ...
>
> >     object(x).is(y) looks OK to me.
>
> I am with you.
> Please allow another question for my edification: if x is a NumPyArray*
(a
> pointer to a PyObject) what will object(x) do? How does it know that
> NumPyArray* is already a PyObject?

It doesn't, actually (my mistake).

> Is it this?
> lvalue_from_pytype<extract_identity<NumPyArray>,&NumPyArray>();

No, that's a /from/ python converter thing.
object(x) is a to python converter thing.

It would have to be something like object(borrowed(x)).is(y) because we
don't just convert pointers to-python willy-nill.

I'm not going to try to solve this problem today, though ;-)

-Dave






From rwgk at yahoo.com  Mon Jul 22 22:48:00 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 13:48:00 -0700 (PDT)
Subject: [C++-sig] pickle support patches checked in
In-Reply-To: <173b01c231ac$45d7c620$6501a8c0@boostconsulting.com>
Message-ID: <20020722204800.8886.qmail@web20203.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > Hm, maybe it would be nice to generate a different compile-time error
> > "must_inherit_from_pickle_group" just to give a better clue. Could this
> be
> > done?
> 
> Just pass a pointer to the group to a function accepting pickle_group const
> volatile*

Here is what I did:

Index: boost/python/object/pickle_support.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/object/pickle_support.hpp,v
retrieving revision 1.4
diff -r1.4 pickle_support.hpp
15a16,17
> struct pickle_suite;
>
20a23
>   inline void must_be_derived_from_pickle_suite(pickle_suite const&) {}

Index: boost/python/class.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/class.hpp,v
retrieving revision 1.29
diff -r1.29 class.hpp
202a203
>       error_messages::must_be_derived_from_pickle_suite(PickleSuiteType());

With EDG this comes out great:

cxx: Error: /tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/python/class.hpp,
line 203: #312 
          no suitable user-defined conversion from
          "<unnamed>::world_pickle_suite" to
          "const boost::python::pickle_suite" exists
          detected during instantiation of "boost::python::class_<T, X1, X2,
                    X3>::self &boost::python::class_<T, X1, X2,
                    X3>::def_pickle(PickleSuiteType) [with T=<unnamed>::world,
                    X1=boost::python::detail::not_specified,
                    X2=boost::python::detail::not_specified,
                    X3=boost::python::detail::not_specified,
                    PickleSuiteType=<unnamed>::world_pickle_suite]" at line 58
                    of "pickle1.cpp"
      error_messages::must_be_derived_from_pickle_suite(PickleSuiteType());
--------------------------------------------------------^

You suggested "volatile const*" as opposed to the "const&" that I am using. Is
the "volatile" essential?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Mon Jul 22 22:58:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 16:58:56 -0400
Subject: [C++-sig] pickle support patches checked in
References: <20020722204800.8886.qmail@web20203.mail.yahoo.com>
Message-ID: <182801c231c2$ce89f7c0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 22, 2002 4:48 PM
Subject: Re: [C++-sig] pickle support patches checked in


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > Hm, maybe it would be nice to generate a different compile-time error
> > > "must_inherit_from_pickle_group" just to give a better clue. Could
this
> > be
> > > done?
> >
> > Just pass a pointer to the group to a function accepting pickle_group
const
> > volatile*
>
> Here is what I did:
>
> Index: boost/python/object/pickle_support.hpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/boost/python/object/pickle_support.hpp,v
> retrieving revision 1.4
> diff -r1.4 pickle_support.hpp
> 15a16,17
> > struct pickle_suite;
> >
> 20a23
> >   inline void must_be_derived_from_pickle_suite(pickle_suite const&) {}
>
> Index: boost/python/class.hpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/boost/python/class.hpp,v
> retrieving revision 1.29
> diff -r1.29 class.hpp
> 202a203
> >
error_messages::must_be_derived_from_pickle_suite(PickleSuiteType());
>
> With EDG this comes out great:
>
> cxx: Error:
/tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/python/class.hpp,
> line 203: #312
>           no suitable user-defined conversion from
>           "<unnamed>::world_pickle_suite" to
>           "const boost::python::pickle_suite" exists
>           detected during instantiation of "boost::python::class_<T, X1,
X2,
>                     X3>::self &boost::python::class_<T, X1, X2,
>                     X3>::def_pickle(PickleSuiteType) [with
T=<unnamed>::world,
>                     X1=boost::python::detail::not_specified,
>                     X2=boost::python::detail::not_specified,
>                     X3=boost::python::detail::not_specified,
>                     PickleSuiteType=<unnamed>::world_pickle_suite]" at
line 58
>                     of "pickle1.cpp"
>
error_messages::must_be_derived_from_pickle_suite(PickleSuiteType());
> --------------------------------------------------------^
>
> You suggested "volatile const*" as opposed to the "const&" that I am
using. Is
> the "volatile" essential?

No more so than the const is.
However, I also suggested *, and I think volatile references bind
differently.

-Dave





From david.abrahams at rcn.com  Mon Jul 22 23:14:54 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 17:14:54 -0400
Subject: [C++-sig] New module and class interface
Message-ID: <182d01c231c4$d6035990$6501a8c0@boostconsulting.com>

This represents, in part, an attempt to get my head around what Dave
Hawkes' has been doing so that I'll have something more intelligent to say
about it than "this is confusing".

One problem I've been having with it is that I never fully-understood the
use cases; maybe if I did I'd have an easier time understanding the need
for certain implementation choices. So, based on what I've seen of Dave's
work, I'm going to describe what I think would be desirable. I hope Dave
will chime in and tell me if I'm missing something important.

The most important contribution of Dave's stuff, IMO, is that you don't
need to declare a module object in the usual case:

  BOOST_PYTHON_INIT_MODULE(my_module)
  {
    def("f", f);
    def("g", g);

    class<X>("X")
        .def("h", &X::f)
        ;
  }

It also means we don't need to worry about the lack of sequence points in
chained calls to .add() classes with an inheritance relationship:


  // current interface
  module("m")
    .add(class<Base>("Base")
            ...
        )
    // possible runtime error -- this class<> might get created first!
    .add(class<Derived>("Derived", bases<Base>())
            ...
        )
    ;


  // new interface
  class<Base>("Base")
    ...
    ;
  // sequence point - no construction order problem!
  class <Derived>("Derived", bases<Base>())
    ...
    ;

        ======= THE LINE [ see below ] =======

I'll also observe that so far, there's really no need for a module object
at all. The name "module" is free to be used for any purpose we see fit.

Okay, this is pretty great so far, however, Dave went even further to
enable nested module and class definitions. On the syntax of this part, I'm
still a little unclear. Dave's example uses:

    // define a submodule
    boost::python::module(".sm");      // my_module.sm
    // define a 2nd submodule
    boost::python::module(".sm.sm2");  // my_module.sm.sm2


From rwgk at yahoo.com  Tue Jul 23 00:05:54 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 15:05:54 -0700 (PDT)
Subject: [C++-sig] strange auto-build problem
In-Reply-To: <174701c231ad$adb2e1c0$6501a8c0@boostconsulting.com>
Message-ID: <20020722220554.23588.qmail@web20203.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> It's possible. Hmm, doesn't seem likely. The longest line in your output is
> ~436 characers.
> What happens if you put -ofoo.bat in the auto-build command-line and then
> invoke foo.bat?

When I run foo.bat the output ends with:

T:\sauter\boostbuild\1027373501\boost\libs\python\test>call "C:\Program
Files\Met
rowerks\Codewarrior8\Other Metrowerks Tools\Command Line Tools\cwenv.bat"
-quiet

The input line is too long.
:noquotes
 was unexpected at this time.


":noquotes" is a label in cwenv.bat .
Before running foo.bat PATH is short. Afterwards PATH is very long: the
CodeWarrior path components are added over and over again. See here:

http://cci.lbl.gov/~rwgk/tmp/auto_build_problem

The cwenv.bat file has not been modified in a while.

You may view foo.bat here:

http://cci.lbl.gov/~rwgk/tmp/auto_build_cw80_bat

And indeed, cwenv.bat is called before each mwcc command. Is this new?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Tue Jul 23 00:16:09 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 15:16:09 -0700 (PDT)
Subject: [C++-sig] pickle support patches checked in
In-Reply-To: <182801c231c2$ce89f7c0$6501a8c0@boostconsulting.com>
Message-ID: <20020722221609.11779.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> error_messages::must_be_derived_from_pickle_suite(PickleSuiteType());
> > --------------------------------------------------------^
> >
> > You suggested "volatile const*" as opposed to the "const&" that I am
> using. Is
> > the "volatile" essential?
> 
> No more so than the const is.
> However, I also suggested *, and I think volatile references bind
> differently.

My core question is: is my code acceptable, may I check it in?

I tried volatile const* first in combination with &PickleSuiteType() . Then gcc
was warning about taking the address of a temporary. However, I want to use
"PickleSuiteType()" in that very place because the error message comes out
best. volatile const& didn't work for some reason, so I just dropped the
"volatile" and gcc, cxx and vc6 seem to be entirely happy. The "const" is
essential because I am taking a reference to a temporary.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From david.abrahams at rcn.com  Tue Jul 23 01:08:13 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 19:08:13 -0400
Subject: [C++-sig] strange auto-build problem
References: <20020722220554.23588.qmail@web20203.mail.yahoo.com>
Message-ID: <188901c231d5$19cb3ca0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 22, 2002 6:05 PM
Subject: Re: [C++-sig] strange auto-build problem


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > It's possible. Hmm, doesn't seem likely. The longest line in your
output is
> > ~436 characers.
> > What happens if you put -ofoo.bat in the auto-build command-line and
then
> > invoke foo.bat?
>
> When I run foo.bat the output ends with:
>
> T:\sauter\boostbuild\1027373501\boost\libs\python\test>call "C:\Program
> Files\Met
> rowerks\Codewarrior8\Other Metrowerks Tools\Command Line Tools\cwenv.bat"
> -quiet
>
> The input line is too long.
> :noquotes
>  was unexpected at this time.
>
>
> ":noquotes" is a label in cwenv.bat .
> Before running foo.bat PATH is short. Afterwards PATH is very long: the
> CodeWarrior path components are added over and over again. See here:
>
> http://cci.lbl.gov/~rwgk/tmp/auto_build_problem
>
> The cwenv.bat file has not been modified in a while.
>
> You may view foo.bat here:
>
> http://cci.lbl.gov/~rwgk/tmp/auto_build_cw80_bat
>
> And indeed, cwenv.bat is called before each mwcc command. Is this new?

No. Normally when jam runs, each of these cwenv.bat...mwcc pairs goes into
a separate .bat file, so it doesn't matter at all that these things run
over and over. You've explained why foo.bat fails, but I still have no clue
why your regular build should be failing.

Suppose you strip all the cwenv.bat invocations other than the first one
out of foo.bat and try again?

-Dave






From david.abrahams at rcn.com  Tue Jul 23 01:09:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Jul 2002 19:09:43 -0400
Subject: [C++-sig] pickle support patches checked in
References: <20020722221609.11779.qmail@web20202.mail.yahoo.com>
Message-ID: <188a01c231d5$19e86190$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 22, 2002 6:16 PM
Subject: Re: [C++-sig] pickle support patches checked in


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > error_messages::must_be_derived_from_pickle_suite(PickleSuiteType());
> > > --------------------------------------------------------^
> > >
> > > You suggested "volatile const*" as opposed to the "const&" that I am
> > using. Is
> > > the "volatile" essential?
> >
> > No more so than the const is.
> > However, I also suggested *, and I think volatile references bind
> > differently.
>
> My core question is: is my code acceptable, may I check it in?
>
> I tried volatile const* first in combination with &PickleSuiteType() .
Then gcc
> was warning about taking the address of a temporary. However, I want to
use
> "PickleSuiteType()" in that very place because the error message comes
out
> best. volatile const& didn't work for some reason, so I just dropped the
> "volatile" and gcc, cxx and vc6 seem to be entirely happy. The "const" is
> essential because I am taking a reference to a temporary.

Ah. If you control the input object, then you may drop the volatile.
Your code is fine; check it in, please.





From rwgk at yahoo.com  Tue Jul 23 01:13:53 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 16:13:53 -0700 (PDT)
Subject: [C++-sig] strange auto-build problem
In-Reply-To: <20020722220554.23588.qmail@web20203.mail.yahoo.com>
Message-ID: <20020722231353.38909.qmail@web20210.mail.yahoo.com>

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> And indeed, cwenv.bat is called before each mwcc command. Is this new?

I take that question back. This clearly isn't new.
bjam and the tools file haven't changed.
The setup of our Windows2k box hasn't changed.
The auto-build setup hasn't changed. 
When I run bjam from the command line in the very same directory where the
auto-build runs bjam there is no problem. So the problem with the batch file
seems to be a debugging-artifact.
I will dig some more...
Ralf



__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From rwgk at yahoo.com  Tue Jul 23 02:10:23 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Jul 2002 17:10:23 -0700 (PDT)
Subject: [C++-sig] strange auto-build problem
In-Reply-To: <20020722231353.38909.qmail@web20210.mail.yahoo.com>
Message-ID: <20020723001023.68917.qmail@web20206.mail.yahoo.com>

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> bjam and the tools file haven't changed.
> The setup of our Windows2k box hasn't changed.
> The auto-build setup hasn't changed. 
> When I run bjam from the command line in the very same directory where the
> auto-build runs bjam there is no problem. So the problem with the batch file
> seems to be a debugging-artifact.
> I will dig some more...

Starting bjam with a Python os.system() command also works. I am at a loss --
and out of time for now. Will get back to this at some other time. In the
meantime, ignore the cw80 auto-build results.
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com




From okuda1 at llnl.gov  Tue Jul 23 18:16:18 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Tue, 23 Jul 2002 09:16:18 -0700
Subject: [C++-sig] June 2002 Progress Report
References: <0e6901c22f4f$39184950$6501a8c0@boostconsulting.com>
Message-ID: <3D3D8152.A30CCA4D@llnl.gov>

I read and copied code in ...libs/python/doc/v2/call_mehtod.html with
some modification so as to compile.
It compiled, but could not import... Please advise me how to fix? 
Thank you...


gps02(490) python
Adding parser accelerators ...
Done.
Python 2.2 (#1, Jan 22 2002, 14:39:03) [C] on osf1V5
Type "help", "copyright", "credits" or "license" for more information.
>>> import my_module
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dlopen: ./my_module.so: symbol "__T_4Base" unresolved
[8615 refs]
>>>

Modified source code:

#include <boost/python/call_method.hpp>
#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/utility.hpp>
#include <cstring>
#include <boost/ref.hpp>

// class to be wrapped
class Base {
public:
   virtual char const* class_name() const { return "Base"; }
   virtual ~Base();
};

bool is_base(Base* b) {
   return !std::strcmp(b->class_name(), "Base");
}

// Wrapper code begins here
using namespace boost::python;

// Callback class
class Base_callback : public Base {
public:
   Base_callback(PyObject* self) : m_self(self) {}

   char const* class_name() const {
      return call_method<char const*>(m_self, "class_name");
   }
   char const* Base_name() const { return Base::class_name(); }
private:
   PyObject* m_self;
};

using namespace boost::python;
BOOST_PYTHON_MODULE_INIT(my_module)
{
   module("my_module")
      .def("is_base", is_base)
      .add(
           class_<Base,Base_callback, boost::noncopyable>("Base")
           .def("class_name", Base_callback::Base_name)
           )
      ;
}




From david.abrahams at rcn.com  Tue Jul 23 18:35:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 23 Jul 2002 12:35:46 -0400
Subject: [C++-sig] June 2002 Progress Report
References: <0e6901c22f4f$39184950$6501a8c0@boostconsulting.com> <3D3D8152.A30CCA4D@llnl.gov>
Message-ID: <1bf401c23267$a8b66060$6501a8c0@boostconsulting.com>

It looks like you're missing a destructor definition for your class
"Base"...

HTH,
Dave

----- Original Message -----
From: "chuzo okuda" <okuda1 at llnl.gov>
To: <c++-sig at python.org>
Sent: Tuesday, July 23, 2002 12:16 PM
Subject: Re: [C++-sig] June 2002 Progress Report


> I read and copied code in ...libs/python/doc/v2/call_mehtod.html with
> some modification so as to compile.
> It compiled, but could not import... Please advise me how to fix?
> Thank you...
>
>
> gps02(490) python
> Adding parser accelerators ...
> Done.
> Python 2.2 (#1, Jan 22 2002, 14:39:03) [C] on osf1V5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import my_module
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dlopen: ./my_module.so: symbol "__T_4Base" unresolved
> [8615 refs]
> >>>
>
> Modified source code:
>
> #include <boost/python/call_method.hpp>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/utility.hpp>
> #include <cstring>
> #include <boost/ref.hpp>
>
> // class to be wrapped
> class Base {
> public:
>    virtual char const* class_name() const { return "Base"; }
>    virtual ~Base();
> };
>
> bool is_base(Base* b) {
>    return !std::strcmp(b->class_name(), "Base");
> }
>
> // Wrapper code begins here
> using namespace boost::python;
>
> // Callback class
> class Base_callback : public Base {
> public:
>    Base_callback(PyObject* self) : m_self(self) {}
>
>    char const* class_name() const {
>       return call_method<char const*>(m_self, "class_name");
>    }
>    char const* Base_name() const { return Base::class_name(); }
> private:
>    PyObject* m_self;
> };
>
> using namespace boost::python;
> BOOST_PYTHON_MODULE_INIT(my_module)
> {
>    module("my_module")
>       .def("is_base", is_base)
>       .add(
>            class_<Base,Base_callback, boost::noncopyable>("Base")
>            .def("class_name", Base_callback::Base_name)
>            )
>       ;
> }
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From hoel at germanlloyd.org  Wed Jul 24 17:13:23 2002
From: hoel at germanlloyd.org (=?ISO-8859-15?Q?Berthold_H=F6llmann?=)
Date: 24 Jul 2002 17:13:23 +0200
Subject: [C++-sig] Boost python build
Message-ID: <selm81gnvw.fsf@pc970145.GermanLloyd.de>

Hello,

I try to use the boost/python/py_interface.hpp header in one
project. But using boost::python::api::import_import_module leads to 

Undefined                       first referenced
 symbol                             in file
boost::python::api::import_import_module(char const*)sol2/BSXF.o

When I try to link my executable. It seems, that
boost/libs/python/src/py_interface.cpp is not compiled into
libboost_python? Is this due to an error or due to the early status of
py_interface?

Thanks

Berthold
-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 



From dave at boost-consulting.com  Wed Jul 24 18:15:52 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 24 Jul 2002 12:15:52 -0400
Subject: [C++-sig] Boost python build
References: <selm81gnvw.fsf@pc970145.GermanLloyd.de>
Message-ID: <008801c2332e$13bdc030$6801a8c0@boostconsulting.com>

It's the latter. Problems:

1. We don't have a single testcase we can use for py_interface.[ch]pp. Dave
checked in a test which exercises some of that code, and a whole bunch of
other stuff including nested modules, but that functionality got rolled
back and we don't have anything which we can use right now. We need some
focused test cases which check each of the elements supplied by
py_interface.

2. (secondary/minor) The name of the file and the organization are wrong.
Probably this should be called api.[ch]pp, and it should include a bunch of
component files with less functionality in them.

I've been waiting for Dave Hawkes to dig himself out so that he can address
some of the outstanding issues with his stuff. If you'd like to step in,
your contribution would be well appreciated.

-Dave


----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>
Hello,

I try to use the boost/python/py_interface.hpp header in one
project. But using boost::python::api::import_import_module leads to

Undefined                       first referenced
 symbol                             in file
boost::python::api::import_import_module(char const*)sol2/BSXF.o

When I try to link my executable. It seems, that
boost/libs/python/src/py_interface.cpp is not compiled into
libboost_python? Is this due to an error or due to the early status of
py_interface?

Thanks

Berthold





From lists at UltimateG.com  Wed Jul 24 21:29:08 2002
From: lists at UltimateG.com (Mark Evans)
Date: Wed, 24 Jul 2002 14:29:08 -0500
Subject: [C++-sig] VCF - Visual Component Framework
Message-ID: <812489099.20020724142908@UltimateG.com>

Thought you might be interested in this GUI toolkit.  It is very C++
centric with STL, templates, exceptions, etc.  I like it.  No Python
binding yet but it could be done.  Sophisticated dynamic event
handling and RTTI.

Mark

=================
VCF - Visual Component Framework
http://vcf.sourceforge.net
http://vcf.sourceforge.net/why_vcf.html

A C++ framework that was created to provide a simple to use cross
platform GUI framework, with many of the advanced design features of
Java and Java's Swing, and Borland's Visual Component Library. In
addition, the VCF provides advanced RTTI/Introspection features common
in languages like Object Pascal, Objective C, Smalltalk, and Java, but
not typically found in C++. The framework is divided into three main
sections: FoundationKit, ApplicationKit, and GraphicsKit, in addition
there are now two additional kits, the Network kit and the Remote
Object Kit.

The FoundationKit provides all of the base classes for the rest of the
Framework, as well as support for RTTI/Introspection, events, event
listeners, properties, and basic streaming capabilities. The VCF makes
use of C++'s Standard Template Library for it's collection classes,
and has a number of template based classes to support the Frameworks
RTTI/Introspection design. The VCF also makes use of C++ exception
handling, multiple inheritance, and C++ namespaces, so compiler's that
don't support these features may have problems getting the
FoundationKit (and any of the other kits) to compile. The GraphicsKit
provides a core set of easy to use 2D graphics classes, modeled
heavily after the design of Java's Graphics2D architecture. This
include support for 32bit color images, alpha channels, anti-aliased
graphics primitives, basic matrix transforms, filters, image loaders,
kernels, and easy to extend path classes. Image manipulation is
allowed at the bit level for those who like to bit- twiddle, but
higher level functions are/will be provided.

The ApplicationKit provides the classes used in the GUI portion of the
Framework. This includes basics like windows, components, standard
widgets (combo boxes, listboxes, trees, etc ), common dialogs, a basic
layout manager, drag-and-drop, and standard windowing events. A
simplified use of Model-View-Control design has been applied
(sometimes referred to as UI delegate, where the Controller and View
are combined ), similar to the way Java's Swing was designed. In
addition it will also provide core services to extend the component
framework with custom 3rd party libraries (DLL's or SO's) housing
components that can be plugged into a the VCFBuilder tool, similar to
Java Beans, or Borland's C++ Builder packages. The VCFBuilder is a
simplified version of the C++ Builder IDE, something that can allow
developer's to design their GUI's in real time, with out having to
waste time writing code, and extend their set of components through
3rd party libraries.




From rwgk at yahoo.com  Thu Jul 25 00:28:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 24 Jul 2002 15:28:48 -0700 (PDT)
Subject: [C++-sig] profiling question
Message-ID: <20020724222848.14963.qmail@web20207.mail.yahoo.com>

I have a Python script that uses Boost.Python bound C++ code. The script is
quite complex and significant amounts of time are spent in both Python and C++
code. I am considering to push more code into C++ for better runtime
performance. However, first I'd like to get a good estimate of the performance
gain that I can expect. So I'd like to know what fraction of the total time is
spent in Python. Unfortunately, the Python profiler is not aware of calls into
C++ and simply adds the time spent in C++ to the total for the enclosing
function. Is there something else that I could use? -- I am working with Win2K,
Linux and other Unixes.
Thanks in advance for any suggestions!
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Thu Jul 25 01:33:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 24 Jul 2002 19:33:10 -0400
Subject: [C++-sig] profiling question
References: <20020724222848.14963.qmail@web20207.mail.yahoo.com>
Message-ID: <01c401c2336a$a368cea0$6801a8c0@boostconsulting.com>

I have little experience with these tools, but people I know have used
gprof on Linux and Intel's VTune on Windows. I think since you're using
namespaces it should be pretty easy to separate the time spent in Python
from that spent in Boost.Python from whatever's spent in your own code with
a simple textual sort.

Good Luck,
Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, July 24, 2002 6:28 PM
Subject: [C++-sig] profiling question


> I have a Python script that uses Boost.Python bound C++ code. The script
is
> quite complex and significant amounts of time are spent in both Python
and C++
> code. I am considering to push more code into C++ for better runtime
> performance. However, first I'd like to get a good estimate of the
performance
> gain that I can expect. So I'd like to know what fraction of the total
time is
> spent in Python. Unfortunately, the Python profiler is not aware of calls
into
> C++ and simply adds the time spent in C++ to the total for the enclosing
> function. Is there something else that I could use? -- I am working with
Win2K,
> Linux and other Unixes.
> Thanks in advance for any suggestions!
> Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From daveh at cadlink.com  Thu Jul 25 01:45:17 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 24 Jul 2002 19:45:17 -0400
Subject: [C++-sig] V2: wrapping globals?
References: <1027089199.19917.4.camel@hunsmac.mit.edu> <0d6801c22f33$24e944a0$6501a8c0@boostconsulting.com>
Message-ID: <005101c2336c$2a9704e0$3e08a8c0@davehh>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: <c++-sig at python.org>
Cc: "Dave Hawkes" <daveh at cadlink.com>
Sent: Friday, July 19, 2002 10:44 AM
Subject: Re: [C++-sig] V2: wrapping globals?


>
> > to
> > wrap global variables and constants?
> >
> > Incidentally, this would also be a nice workaround for the current lack
> > of enum support...
>
> Hmm, there's no easy way to bind objects into module and class namespaces.
> I'd be willing to consider a patch if you'd like to contribute one. Dave
> Hawkes might have some ideas also, as he's been working in this area.

If 'global' implies placing objects in the global python dictionary, then
certainly the support for executing arbitrary python code we've been
discussing would make this possible.

Dave Hawkes





From rwgk at yahoo.com  Thu Jul 25 02:19:35 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 24 Jul 2002 17:19:35 -0700 (PDT)
Subject: [C++-sig] bpl_utils update
Message-ID: <20020725001935.56337.qmail@web20202.mail.yahoo.com>

I have just updated the bpl_utils:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bpl_utils.h?rev=1.2.2.15&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_tag=boost_python_v2_transition

This should work with the latest boost code from cvs. However, I've only tested
with Compaq cxx 6.5.

Ralf

P.S.: The bpl_utils include code for the automatic conversion of Python lists
or tuples (and other "measurable" sequences) to STL containers.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Thu Jul 25 03:07:46 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 24 Jul 2002 21:07:46 -0400
Subject: [C++-sig] bpl_utils update
References: <20020725001935.56337.qmail@web20202.mail.yahoo.com>
Message-ID: <024301c23378$00d97aa0$6801a8c0@boostconsulting.com>

Ralf, this stuff looks totally cool and super-useful! Can we put it in the
library?
Also, do you have any docs for it? I'd really like to see those to get a
better feel for it.

-Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, July 24, 2002 8:19 PM
Subject: [C++-sig] bpl_utils update


> I have just updated the bpl_utils:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bp
l_utils.h?rev=1.2.2.15&only_with_tag=boost_python_v2_transition&content-typ
e=text/vnd.viewcvs-markup
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_
tag=boost_python_v2_transition
>
> This should work with the latest boost code from cvs. However, I've only
tested
> with Compaq cxx 6.5.
>
> Ralf
>
> P.S.: The bpl_utils include code for the automatic conversion of Python
lists
> or tuples (and other "measurable" sequences) to STL containers.
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From daveh at cadlink.com  Thu Jul 25 04:24:23 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 24 Jul 2002 22:24:23 -0400
Subject: [C++-sig] Re: New module and class interface
References: <182d01c231c4$d6035990$6501a8c0@boostconsulting.com>
Message-ID: <000901c23382$643d01c0$3e08a8c0@davehh>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: "pysig" <c++-sig at python.org>
Cc: "Dave Hawkes" <daveh at cadlink.com>
Sent: Monday, July 22, 2002 5:14 PM
Subject: New module and class interface


>
> From this I take it that defining a module whose name begins with '.'
> creates a submodule of whatever the current outer module is (whatever was
> passed to BOOST_PYTHON_MODULE_INIT). The benefits of being able to drop
> *just* the outer module name seem questionable to me; I think people will
> be confused by the lack of uniformity. I think I'd rather see a simple and
> straightforward approach where the full module qualification is supplied.
I
> guess the question is, "how much work is it to make a submodule of an
> extension module that may be located anywhere in the package hierarchy?"
> OK, now I think I see why Dave wants to support '.'-prefixed module names.
>
> Because this usage creates a temporary which is destroyed immediately, I
> also take it that there's a "current inner module" into which new def()s
> and class_<> instances stick their Python results. At this point,

Correct, the last instantiated module is remembered until a new one replaces
it.

> python::module might as well be a function. One thing I dislike about that
> is that (if my assumptions are correct) some obvious usages give an
> unexpected result:
>
>     void initialize_inner()
>     {
>         module(".inner");
>         def("g", g);
>     }
>
>     BOOST_PYTHON_MODULE_INIT(outer)
>     {
>         def("f", f);
>         initialize_inner();
>         def("h", h);        // creates outer.inner.h!
>     }
>

Yes, that is one of the downsides. The current module needs to be 'reset'
after calling initialize_inner, though it is conceivable that a user could
use functions to deliberately change the module context.

> So we could return to the current syntax for inner modules:
>
>     void initialize_inner()
>     {
>         module("outer.inner")
>             .def("g", g)
>             ;
>     }
>
>     BOOST_PYTHON_MODULE_INIT(outer)
>     {
>         def("f", f);
>         initialize_inner();
>         def("h", h);       // ok
>     }
>

However one of the reasons for using sub-modules was to simplify large
embedding problems. In this case the majority of definitions could be in
sub-modules and we would lose the benefit of a simplified 'def'.

> I'm beginning to settle on the following conclusions:
>
> . module is a class derived from object. That makes constructs like:
>
>     m.attr("x") = 1
>
> possible.

Does this imply the construction of modules outside of initialisation? If it
does that may have some implications in tracking the current module.

>
> . It takes a single string in its constructor.
>
> . The name in the string is an absolute path if it does not begin with a
> '.'
>
> . Otherwise, the name in the string supplies a path relative to whatever
is
> being constructed with BOOST_PYTHON_MODULE_INIT.
>
> . I am not convinced of the utility of auto-creating missing intermediate
> modules in:
>
>     module("w.x.y.z")
>
> I'd be just as happy with a runtime error if it simplifies the code even a
> little. In fact, I take it back: not giving a runtime error could mask
> errors. I want to require that parent modules be constructed already.
>

Yes, in reality it is unlikely that many situations would exist that would
require this. However, unlike nested classes, construction of intermediate
modules is very straightforward and probably requires about the same amount
of code as generating an error.

> . What about auto-creating child modules? Clearly we want to be able to
> say:
>
>   module(".x")
>
> and have it create the x submodule. However I think I would be very
unhappy
> if module("sys") did anything other than retrieving (loading, if
> neccessary) the built-in "sys" module. Conclusion: when the constructor
arg

I am not keen on allowing this. In my original code I prohibited any
basename that was different from the name of the module being imported. It
didn't seem right to encourage functions to be defined outside of the scope
of the module being imported. In other words module("sys") would assert.

However if you wish to treat modules more like objects rather than a vehicle
for classes and functions to be defined in, then the the logic behind
disallowing this may not be so valid.

> begins with '.', we auto-construct leaf modules. Otherwise, we don't. That
> leaves out the ability to build new modules with an absolute package path
> using module(...). Oh, well, no great loss.

And that is probably a good thing.

> . BOOST_PYTHON_MODULE_INIT(...) creates a "module context", inside which
> def() and class_<> normally place their definitions. *If* we want to get
> around the class<> ordering problems for inner modules, we ought to
provide
> a "module_scope" class which changes the target module of def() and
> class_<>... Why not just use module() itself, so that the last module
> created will always be the target?
>
>     module("sys").attr("argv")
>
> is one good argument against it.
>
> . All of the stuff "above the line" can be done very cleanly; there are
> almost no questions about how it should work. We can afford to let the
> stuff "below the line" percolate a little bit before adding it.
>
> After we've had a round of comments on this message, we can discuss inner
> classes.

I'm not convinced that modules should be true objects as it invites too much
abuse. Importing a module should not result in classes and functions being
defined outside of that module.

Dave Hawkes





From vraghavan at cnmnetwork.com  Thu Jul 25 06:07:28 2002
From: vraghavan at cnmnetwork.com (Srivatsan Raghavan)
Date: Wed, 24 Jul 2002 21:07:28 -0700
Subject: [C++-sig] using boost::python v1
Message-ID: <3D3F7980.2040008@cnmnetwork.com>

hello all.. i've got some questions about using bpl, and i've searched 
the docs & the examples, and
i can find no answer

this example illustrates the issues i'm having

<cpp>
   class B ;
   class C ;

   class A
   {
   public:
        A() ;
       virtual bool func1 ( ) ;
       virtual bool func2 ( ) = 0 ;
       virtual ~A() ;
       virtual int  func3 ( std::list<C> ) ;   
   protected :
       B  m_Bobj ;
       std::string  m_Aname ;
    } ;
</cpp>

now , i know how to expose the virtual and pure virtual functions to pyhon,
i just write a  derived class A_callback, and write some static default 
functions that forward
the impl to the virtual function in A .
my problem is in the func3() and the protected members
do i need to write my own wrapper functions to python for mapping a 
list<C> ?
or does bpl do this itself in some way?

and how do i expose the protected members to python?
if i do something like this :
<cpp>
   boost::python::class_builder<A , A_callback> a_class ( this_module , 
"A" ) ;
   a_class.def ( &A::m_Bobj , "m_Bobj" ) ;
</cpp>
that line of code gets me this error (in msvc 6 : sp 5 )  :
 error C2248: 'm_Bobj': cannot access protected member declared in class 
'Logging::Endpoint'
<file-name> : see declaration of 'm_Bobj'

how can i get this to work?









From dave at boost-consulting.com  Thu Jul 25 06:49:51 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 00:49:51 -0400
Subject: [C++-sig] [ANN] Boost.Python v2 Interface changes
Message-ID: <033d01c23396$b70a1f00$6801a8c0@boostconsulting.com>

In the CVS, class_<> is now derived from object, and its object() member
function is
now gone.
This is the first of a series of changes in preparation for the v2 release
which will impact the interface for users. More significantly, the module
type, at least in its current form, will soon be deprecated. Instead,
class_<> instances will insert themselves into the current scope, and there
will be a def() free function which takes the place of the current
module::def() -- these are Dave Hawkes' excellent simplifications.

           ---------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From dave at boost-consulting.com  Thu Jul 25 13:16:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 07:16:44 -0400
Subject: [C++-sig] using boost::python v1
References: <3D3F7980.2040008@cnmnetwork.com>
Message-ID: <03fa01c233cc$c42aa7f0$6801a8c0@boostconsulting.com>

From: "Srivatsan Raghavan" <vraghavan at cnmnetwork.com>


> hello all.. i've got some questions about using bpl, and i've searched
> the docs & the examples, and
> i can find no answer
>
> this example illustrates the issues i'm having
>
> <cpp>
>    class B ;
>    class C ;
>
>    class A
>    {
>    public:
>         A() ;
>        virtual bool func1 ( ) ;
>        virtual bool func2 ( ) = 0 ;
>        virtual ~A() ;
>        virtual int  func3 ( std::list<C> ) ;
>    protected :
>        B  m_Bobj ;
>        std::string  m_Aname ;
>     } ;
> </cpp>
>
> now , i know how to expose the virtual and pure virtual functions to
pyhon,
> i just write a  derived class A_callback, and write some static default
> functions that forward
> the impl to the virtual function in A .
> my problem is in the func3() and the protected members
> do i need to write my own wrapper functions to python for mapping a
> list<C> ?

You can just use class_builder<std::list<C> > to expose it, the same as you
would any other class.

> or does bpl do this itself in some way?

Unfortunately not. In BPL v2 I hope to incorporate some facilities from
Ralf Grosse-Kunstleve which make it much easier to translate between Python
sequences (lists, tuples, etc) and C++ containers.

> and how do i expose the protected members to python?
> if i do something like this :
> <cpp>
>    boost::python::class_builder<A , A_callback> a_class ( this_module ,
> "A" ) ;
>    a_class.def ( &A::m_Bobj , "m_Bobj" ) ;
> </cpp>
> that line of code gets me this error (in msvc 6 : sp 5 )  :
>  error C2248: 'm_Bobj': cannot access protected member declared in class
> 'Logging::Endpoint'
> <file-name> : see declaration of 'm_Bobj'

Hence the name "protected"

> how can i get this to work?

Well, members are probably protected for a reason...

However, if you really want to break encapsulation, since you're writing a
callback class anyway you could add static get/set member functions to your
callback class, then expose them as __getattr__<NAME>__ and
__setattr__<NAME>__.

HTH,
Dave





From dave at boost-consulting.com  Thu Jul 25 15:00:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 09:00:44 -0400
Subject: [C++-sig] Re: Hnadling Python exceptions in C++
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de><03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com><septxj22xl.fsf@pc970145.GermanLloyd.de><0d8401c22f34$342e2740$6501a8c0@boostconsulting.com> <selm871zw4.fsf@pc970145.GermanLloyd.de>
Message-ID: <04ef01c233db$c1445310$6801a8c0@boostconsulting.com>

Hi Berthold,

Sorry it's taken so long for me to get back to you about this; I've just
been swamped...

From: "Berthold H?llmann" <hoel at germanlloyd.org>

> OK, I dove a little more into the boost python sources. One thing I
> did not understand was the purpose of the function
> "throw_error_already_set()". Why this indirection instead of calling
> "throw error_already_set()"?

Two reasons: first, it generates less code in the caller. Second, there are
issues with GCC 3.x and exception matching which mean that if you throw an
exception in your extension module and I try to catch it in libbpl.so, it
will fail. This is a complicated issue involving the way the linker
resolves weak symbols and the way typeinfo object comparison works. They
could fix it, but so far I've been unable to convince the GCC developers
(except one) that it's worth doing. Maybe if they heard from more users
about it...

> But anyway, it would be nice to have a
> facility to extract the error ocured when error_already_set was
> thrown. Some access to the reason a command failed.

Ah. Now I understand what you're after.

> This is where the
> proposed class "error_handler " comes into play. It reads the Python
> error state. It has a method "get_type" to get access to the python
> exception thrown and it has an operator to put the exception
> informations onto a stream. Calling the () operator will set back the
> exception status and returns NULL, ready to be returned to Python:

I already have plans for something else, but I haven't had time to
implement it yet. Please consider the following proposal:

  1. There should be an exception class hierarchy which mirrors Python's
exception hierarchy, with a base class called "python_exception".

  2. Catching a particular type of exception is as simple as, well,
catching that exception type (just as in Python)

  2a. finding out what exception was thrown is as simple as catching the
generalized python_exception and examining its type (just as in Python)

  3. Getting the error message from the exception is as simple as writing
str(x) (just as in Python)

  4. to deal with the gcc 3.x problem each exception type has a static
"throw_(...)" member function which constructs the exception using the
given arguments and throws it.

Would this fill your needs? If so, I invite you to take a stab at the
implementation!

-Dave





From rwgk at yahoo.com  Thu Jul 25 15:58:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 25 Jul 2002 06:58:42 -0700 (PDT)
Subject: [C++-sig] bpl_utils update
In-Reply-To: <024301c23378$00d97aa0$6801a8c0@boostconsulting.com>
Message-ID: <20020725135842.39990.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Ralf, this stuff looks totally cool and super-useful! Can we put it in the
> library?

Yes.

> Also, do you have any docs for it?

No.

> I'd really like to see those to get a better feel for it.

Realistically, I will not be able to work on this before September (due to
travel). More realistically, it might take even longer unless a miracle
happens. If you want, we could approach this incrementally: you establish the
slot in the doc tree (like the caption and the first sentence of the intro), I
fill in a little, you rework it a bit, I rework it a bit, etc. That would
probably help a lot in getting it done sooner rather than later, and cut down
significantly on the time-consuming need for writing lengthy e-mail messages.

We could start this way with the code: 1. you copy the relevant fragments from
the files where you think they should go (to boost cvs). 2. tell me where they
are and I'll fix them up so they get build with bjam, and I'll turn the
assertion based tests into doctests. 3. go through and fix the code up as you
see fit (be as intrusive as you find necessary); tell me when you are done and
I see if I can still use it in our package. etc.

To get things off the ground, I'd suggest to limit ourselves initially to
"measurable" sequences (that's what the code is doing now; checks should/could
be added). /Later/, when we hopefully have boost::python::sequence and
boost::python::iter(ator) we can adjust the "to STL container" converters to
deal with both.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Thu Jul 25 16:27:36 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 10:27:36 -0400
Subject: [C++-sig] bpl_utils update
References: <20020725135842.39990.qmail@web20207.mail.yahoo.com>
Message-ID: <054201c233e7$6e55e4a0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Thursday, July 25, 2002 9:58 AM
Subject: Re: [C++-sig] bpl_utils update


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > Ralf, this stuff looks totally cool and super-useful! Can we put it in
the
> > library?
>
> Yes.

...ccccoool....

> > Also, do you have any docs for it?
>
> No.
>
> > I'd really like to see those to get a better feel for it.
>
> Realistically, I will not be able to work on this before September (due
to
> travel).

Fine.

> More realistically, it might take even longer unless a miracle
> happens. If you want, we could approach this incrementally: you establish
the
> slot in the doc tree (like the caption and the first sentence of the
intro), I
> fill in a little, you rework it a bit, I rework it a bit, etc. That would
> probably help a lot in getting it done sooner rather than later, and cut
down
> significantly on the time-consuming need for writing lengthy e-mail
messages.

That's a fine approach for the tutorial section (once I've started it ;-))

> We could start this way with the code: 1. you copy the relevant fragments
from
> the files where you think they should go (to boost cvs). 2. tell me where
they
> are and I'll fix them up so they get build with bjam, and I'll turn the
> assertion based tests into doctests. 3. go through and fix the code up as
you
> see fit (be as intrusive as you find necessary); tell me when you are
done and
> I see if I can still use it in our package. etc.

Okay, sounds great. However, we also need reference documentation of the
type that's already in CVS. To write that, we need to at least decide on
the filenames.

> To get things off the ground, I'd suggest to limit ourselves initially to
> "measurable" sequences (that's what the code is doing now; checks
should/could
> be added).

I'm not sure that checking is possible, at least not today. And Guido seems
rather hostile to the idea of making it possible, though I might be
misinterpreting him. See
http://aspn.activestate.com/ASPN/search?query=Single-+vs.+Multi-pass+iterab
ility&type=Archive_python-dev
for details.

>  /Later/, when we hopefully have boost::python::sequence and
> boost::python::iter(ator) we can adjust the "to STL container" converters
to
> deal with both.

That sounds great to me.

-Dave




From dave at boost-consulting.com  Thu Jul 25 18:24:29 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 12:24:29 -0400
Subject: [C++-sig] Re: Hnadling Python exceptions in C++
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de><03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com><septxj22xl.fsf@pc970145.GermanLloyd.de><0d8401c22f34$342e2740$6501a8c0@boostconsulting.com><selm871zw4.fsf@pc970145.GermanLloyd.de><04ef01c233db$c1445310$6801a8c0@boostconsulting.com> <sen0sf3i3u.fsf@pc970145.GermanLloyd.de>
Message-ID: <05e701c233f7$c0a6a2c0$6801a8c0@boostconsulting.com>

Non-type template parameters must be compile-time constants, and those
pointers are not. Try using:

    template <PyObject** E>

with &PyExc_Exception, et al.

We could use a reference non-type parameter to make things prettier, but I
think VC6 will choke on that.

-Dave

----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>

If you are willing and able (from the time avaible) to help me I could
try.

I tried something like the following

#include <Python.h>
#define BOOST_PYTHON_V2 1
#include <boost/python/object_core.hpp>
namespace boost {
  namespace python {
    template <PyObject* E>
    class python_exception
    {
    public:
      python_exception() { };
    protected:
      static object PyExc;
    };
    template <PyTypeObject* E>
    object python_exception<E>::PyExc(E);
    class exception : public python_exception<PyExc_Exception>
    { };
    class standard_error : exception,
                           public python_exception<PyExc_StandardError>
    { };
    class keyboard_interrupt : public standard_error,
                               public
python_exception<PyExc_KeyboardInterrupt>
    { };
  }
}

I thought of this as a nice way to get the python exception
information into the C++ exception classes. But trying to compile this
(gcc 3.1) I get

g++ -g -Wall -isystem
/usr/local/gltools/python/Python-2.2.1/include/python2.2 -isystem
/usr/local/gltools/python/Python-2.2.1/sol2/include/python2.2
-I/usr/local/fitools/sol2/boost -I.  -c exceptions.cxx -o
sol2/exceptions.o
In file included from exceptions.cxx:32:
aa.h:17: `PyExc_Exception' is not a valid template argument
aa.h:17: it must be the address of an object with external linkage
aa.h:20: `PyExc_StandardError' is not a valid template argument
aa.h:20: it must be the address of an object with external linkage
aa.h:23: `PyExc_KeyboardInterrupt' is not a valid template argument
aa.h:23: it must be the address of an object with external linkage


aa.h:17: `PyExc_Exception' is not a valid template argument
aa.h:17: it must be the address of an object with external linkage

but isn't "extern PyObject *PyExc_Exception" the address of an object
with extenal linkage. Or is my idea totay dumb? Shall I give each
derived class its own static pointer to the Python exception?

Still learning C++

Berthold
--
Dipl.-Ing. Berthold H??llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email.

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc.





From dave at boost-consulting.com  Thu Jul 25 18:30:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 12:30:56 -0400
Subject: [C++-sig] Beginning handle<> -> object conversion
Message-ID: <05f501c233f8$a7b38020$6801a8c0@boostconsulting.com>

I've now begun the transition away from using handle<T> in interfaces and
towards using object. That will likely cause some disruption in user code.
If you are getting errors in code which used to work, you can use the
following techniques during the transition:

to make a handle<> from an object:

    handle<>(borrowed(o.ptr()))

to make an object from a handle, simply:

    object(h)

Thanks for your understanding while we reconstruct things ;-)

-Dave

           ---------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From dave at boost-consulting.com  Thu Jul 25 18:33:17 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 12:33:17 -0400
Subject: [C++-sig] Re: Hnadling Python exceptions in C++
References: <seit3efpu5.fsf@pc970145.GermanLloyd.de><03ff01c22d98$0a090f40$6501a8c0@boostconsulting.com><septxj22xl.fsf@pc970145.GermanLloyd.de><0d8401c22f34$342e2740$6501a8c0@boostconsulting.com><selm871zw4.fsf@pc970145.GermanLloyd.de><04ef01c233db$c1445310$6801a8c0@boostconsulting.com> <sen0sf3i3u.fsf@pc970145.GermanLloyd.de> <05e701c233f7$c0a6a2c0$6801a8c0@boostconsulting.com>
Message-ID: <060901c233f8$fc220870$6801a8c0@boostconsulting.com>

----- Original Message -----

> but isn't "extern PyObject *PyExc_Exception" the address of an object
> with extenal linkage. Or is my idea totay dumb? Shall I give each
> derived class its own static pointer to the Python exception?
>
> Still learning C++

Nothing wrong with your idea. To clarify the error message, PyExc_Exception
is an object of type PyObject* with external linkage. The thing it points
to is a heap-allocated thing with no linkage.

HTH,
Dave





From rwgk at yahoo.com  Thu Jul 25 18:39:19 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 25 Jul 2002 09:39:19 -0700 (PDT)
Subject: [C++-sig] bpl_utils update
In-Reply-To: <054201c233e7$6e55e4a0$6801a8c0@boostconsulting.com>
Message-ID: <20020725163919.72819.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > We could start this way with the code: 1. you copy the relevant fragments
> from
> > the files where you think they should go (to boost cvs). 2. tell me where
> they
> > are and I'll fix them up so they get build with bjam, and I'll turn the
> > assertion based tests into doctests. 3. go through and fix the code up as
> you
> > see fit (be as intrusive as you find necessary); tell me when you are
> done and
> > I see if I can still use it in our package. etc.
> 
> Okay, sounds great. However, we also need reference documentation of the
> type that's already in CVS. To write that, we need to at least decide on
> the filenames.

I'd find it most efficient if you make a unilateral (IOW dictatorial) decision.

> > To get things off the ground, I'd suggest to limit ourselves initially to
> > "measurable" sequences (that's what the code is doing now; checks
> should/could
> > be added).
> 
> I'm not sure that checking is possible, at least not today. And Guido seems
> rather hostile to the idea of making it possible, though I might be
> misinterpreting him. See
> http://aspn.activestate.com/ASPN/search?query=Single-+vs.+Multi-pass+iterab
> ility&type=Archive_python-dev
> for details.

161 messages! Help!!!
I cannot afford to be scientific about this.
Idea for a pragmatic approach:

We add static constant to the *_registration_adaptor's; e.g.

BOOST_STATIC_CONSTANT(bool, check_convertibility_per_element = true);

Then in convertible():

if (ContainerAdaptor::check_convertibility_per_element == true) {
  if (PyObject_Length(obj) < 0) return 0;
  // we traverse the sequence and return 0 if any element is not convertible
  return obj;
}
if (PyObject_Length(obj) >= 0) return obj;
PyErr_Clear();
if (handle<>(allow_null(PyObject_GetIter(obj))).get()) return obj;
PyErr_Clear();
return 0;

In construct() we do it the other way round:
1. try PyObject_GetIter() first and use PyIter_Next() on success.
2. if that fails fall back to PySequence_Fast()

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Thu Jul 25 19:00:58 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 13:00:58 -0400
Subject: [C++-sig] bpl_utils update
References: <20020725163919.72819.qmail@web20207.mail.yahoo.com>
Message-ID: <064c01c233fc$e9f025c0$6801a8c0@boostconsulting.com>

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

> > Okay, sounds great. However, we also need reference documentation of
the
> > type that's already in CVS. To write that, we need to at least decide
on
> > the filenames.
>
> I'd find it most efficient if you make a unilateral (IOW dictatorial)
decision.

OK. To do that I need to get a better understanding of what you've done. I
will be asking questions.

> > > To get things off the ground, I'd suggest to limit ourselves
initially to
> > > "measurable" sequences (that's what the code is doing now; checks
> > should/could
> > > be added).
> >
> > I'm not sure that checking is possible, at least not today. And Guido
seems
> > rather hostile to the idea of making it possible, though I might be
> > misinterpreting him. See
> >
http://aspn.activestate.com/ASPN/search?query=Single-+vs.+Multi-pass+iterab
> > ility&type=Archive_python-dev
> > for details.
>
> 161 messages! Help!!!
> I cannot afford to be scientific about this.

Sorry. For a condensed version, check
http://aspn.activestate.com/ASPN/Mail/Message/1284483
http://aspn.activestate.com/ASPN/Mail/Message/1284538
http://aspn.activestate.com/ASPN/Mail/Message/1287379
http://aspn.activestate.com/ASPN/Mail/Message/1287432

> Idea for a pragmatic approach:
>
> We add static constant to the *_registration_adaptor's; e.g.
>
> BOOST_STATIC_CONSTANT(bool, check_convertibility_per_element = true);
>
> Then in convertible():
>
> if (ContainerAdaptor::check_convertibility_per_element == true) {
>   if (PyObject_Length(obj) < 0) return 0;
>   // we traverse the sequence and return 0 if any element is not
convertible
>   return obj;
> }
> if (PyObject_Length(obj) >= 0) return obj;
> PyErr_Clear();
> if (handle<>(allow_null(PyObject_GetIter(obj))).get()) return obj;
> PyErr_Clear();
> return 0;
>
> In construct() we do it the other way round:
> 1. try PyObject_GetIter() first and use PyIter_Next() on success.
> 2. if that fails fall back to PySequence_Fast()

I need to look at your stuff in more detail before I can evaluate these
ideas.

-Dave





From dave at boost-consulting.com  Thu Jul 25 19:29:26 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 13:29:26 -0400
Subject: [C++-sig] Silly naming question
Message-ID: <069201c23400$d53d6490$6801a8c0@boostconsulting.com>

 As I revise the class_<> interface to use object instead of handle<>, I
came across

    .setattr("name", obj)

and I'm just wondering if the name "bind" wouldn't be more appropriate here
than a tweaky abbreviation like setattr:

    .bind("name", value)

I'm mildly +1 on this change before we release the library.

Other votes?

           ---------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From rwgk at yahoo.com  Thu Jul 25 21:11:00 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 25 Jul 2002 12:11:00 -0700 (PDT)
Subject: [C++-sig] boost/python/detail/module_init.hpp gone?
Message-ID: <20020725191100.44190.qmail@web20203.mail.yahoo.com>

As of last night we are having a problem with the Boost.Python V1 autobuild:

cxx: Error:
/net/ringneck/scratch1/sauter/daily_build/1027587601/boost/boost/python/module_builder.hpp,
line 16: #5 
          could not open source file "boost/python/detail/module_init.hpp"
# include <boost/python/detail/module_init.hpp>
-----------------------------------------------^

Is V1 being cleaned out already?
Thanks,
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Thu Jul 25 22:26:51 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 16:26:51 -0400
Subject: [C++-sig] boost/python/detail/module_init.hpp gone?
References: <20020725191100.44190.qmail@web20203.mail.yahoo.com>
Message-ID: <06f601c2341a$0a2f9600$6801a8c0@boostconsulting.com>

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


> As of last night we are having a problem with the Boost.Python V1
autobuild:
>
> cxx: Error:
>
/net/ringneck/scratch1/sauter/daily_build/1027587601/boost/boost/python/mod
ule_builder.hpp,
> line 16: #5
>           could not open source file
"boost/python/detail/module_init.hpp"
> # include <boost/python/detail/module_init.hpp>
> -----------------------------------------------^
>
> Is V1 being cleaned out already?
> Thanks,
> Ralf

This got answered already on the list, and the CVS is already fixed.

           ---------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From bhoel at web.de  Thu Jul 25 22:42:39 2002
From: bhoel at web.de (Berthold =?iso-8859-15?q?H=F6llmann?=)
Date: 25 Jul 2002 22:42:39 +0200
Subject: [C++-sig] Re: Silly naming question
In-Reply-To: <069201c23400$d53d6490$6801a8c0@boostconsulting.com>
References: <069201c23400$d53d6490$6801a8c0@boostconsulting.com>
Message-ID: <m2hein1qv4.fsf@pchoel.privat.uni-hamburg.de>

"David Abrahams" <dave at boost-consulting.com> writes:

>  As I revise the class_<> interface to use object instead of handle<>, I
> came across
> 
>     .setattr("name", obj)
> 
> and I'm just wondering if the name "bind" wouldn't be more appropriate here
> than a tweaky abbreviation like setattr:
> 
>     .bind("name", value)
> 
> I'm mildly +1 on this change before we release the library.
> 
> Other votes?

To me it sounds like a the python __setattr__ special object method.
If it has the same purpose, I would vote -1 for the namechange.

Greetings

Berthold
-- 
bhoel at web.de / http://starship.python.net/crew/bhoel/
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.



From rwgk at yahoo.com  Fri Jul 26 00:16:44 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 25 Jul 2002 15:16:44 -0700 (PDT)
Subject: [C++-sig] bpl_utils update
In-Reply-To: <064c01c233fc$e9f025c0$6801a8c0@boostconsulting.com>
Message-ID: <20020725221644.46253.qmail@web20208.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Idea for a pragmatic approach:
> >
> > We add static constant to the *_registration_adaptor's; e.g.
> >
> > BOOST_STATIC_CONSTANT(bool, check_convertibility_per_element = true);
> >
> > Then in convertible():
> >
> > if (ContainerAdaptor::check_convertibility_per_element == true) {
> >   if (PyObject_Length(obj) < 0) return 0;
> >   // we traverse the sequence and return 0 if any element is not
> convertible
> >   return obj;
> > }
> > if (PyObject_Length(obj) >= 0) return obj;
> > PyErr_Clear();
> > if (handle<>(allow_null(PyObject_GetIter(obj))).get()) return obj;
> > PyErr_Clear();
> > return 0;
> >
> > In construct() we do it the other way round:
> > 1. try PyObject_GetIter() first and use PyIter_Next() on success.
> > 2. if that fails fall back to PySequence_Fast()
> 
> I need to look at your stuff in more detail before I can evaluate these
> ideas.

I have just checked in a new version of bpl_utils.h with the code above pasted
in. This time I've tested with gcc 3.0.4 and cxx 6.5. The accompanying tests
work fine without modification. I've even tested for memory leaks.

Comment 1: I had to use a static function check_convertibility_per_element()
instead of a static bool to avoid warnings about unreachable statements.

Comment 2: In the final version we might want to use

template <bool CheckConvertibilityPerElement>
struct xxx_registration_adaptor { ... };

Comment 3:

This compiles:

          handle<> py_elem_hdl(allow_null(PyIter_Next(obj_iter.get())));
          ...
          extract<container_element_type> elem_proxy(py_elem_obj);
          ContainerAdaptor::set_value(result, i, elem_proxy());
          

But cxx 6.5 was upset about this:

          extract<container_element_type> elem_proxy(object(py_elem_hdl));

The error was that there are not enough function arguments for:
    elem_proxy()
in the following statement.

New code:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bpl_utils.h?rev=1.2.2.16&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From rwgk at yahoo.com  Fri Jul 26 03:41:50 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 25 Jul 2002 18:41:50 -0700 (PDT)
Subject: [C++-sig] Implicit constructors?
Message-ID: <20020726014150.71320.qmail@web20209.mail.yahoo.com>

The register_container_from_python_sequence in the bpl_utils enables implicit
conversion from Python sequences to container types such as std::vector<> when
function signatures are matched. Now say I've actually exposed
std::vector<double> with class_<> as std_vector in Python. Now I'd like this to
work:

from arrays import std_vector_double
v=std_vector_double((1,2,3))

Given that the corresponding register_container_from_python_sequence is in the
registry, could this be made to work (or will this work) without explicitly
def()'ing a constructor that takes a tuple?

Thanks,
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Fri Jul 26 04:52:05 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 25 Jul 2002 22:52:05 -0400
Subject: [C++-sig] Implicit constructors?
References: <20020726014150.71320.qmail@web20209.mail.yahoo.com>
Message-ID: <02ee01c2344f$7d256a60$6501a8c0@boostconsulting.com>

I think if you def() the copy constructor it should work automatically
(though it could be more efficient). Does that help?

           ---------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Thursday, July 25, 2002 9:41 PM
Subject: [C++-sig] Implicit constructors?


> The register_container_from_python_sequence in the bpl_utils enables
implicit
> conversion from Python sequences to container types such as std::vector<>
when
> function signatures are matched. Now say I've actually exposed
> std::vector<double> with class_<> as std_vector in Python. Now I'd like
this to
> work:
>
> from arrays import std_vector_double
> v=std_vector_double((1,2,3))
>
> Given that the corresponding register_container_from_python_sequence is
in the
> registry, could this be made to work (or will this work) without
explicitly
> def()'ing a constructor that takes a tuple?
>
> Thanks,
> Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From hoel at germanlloyd.org  Fri Jul 26 16:16:01 2002
From: hoel at germanlloyd.org (=?ISO-8859-15?Q?Berthold_H=F6llmann?=)
Date: 26 Jul 2002 16:16:01 +0200
Subject: [C++-sig] A first glance at what could be the boost::python exception system
Message-ID: <ser8hqshge.fsf@pc970145.GermanLloyd.de>

Hello all,

David asked if I coud implement the C++ wrapper system for the Python
exception system. Now, it is friday afternoon again and I won't have
time to work on this over the weekend. The only test I did was sending
this through the compiler (g++ 3.1). How do I enable "str(exception)"
doing someting meaningfull? Another facility that is missing is a
routine checking for a set Python exception and returning/raising the
apropriate C++ counterpart. Is there any idea how this could be
accomplished without a huge set of if/else if's and in a way easy
extensible for user defined exceptions? I tried to map the class
hierarchy found with

>python
Python 2.2.1 (#3, Jun  4 2002, 09:47:49) 
[GCC 3.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import exceptions
>>> help(exceptions)

I left out the warnings, because I don't think they should be mapped
to C++ Exceptions, but they could be added. I hope it's OK to attach
"exceptions.hpp" and "exceptions.cpp".

Greetings

Berthold



This email contains confidential information for the exclusive attention
of the intended addressee. Any access of third parties to this email is
unauthorized. Any use of this email by not intended recipients like
copying, distribution, disclosure etc. is prohibited and may be
unlawful. When addressed to our clients the content of this email is
subject to the General Terms and Conditions of GL's Group of Companies
applicable at the date of this email. 

GL's Group of Companies does not warrant and/or guarantee that this
message at the moment of receipt is authentic, correct and its
communication free of errors, interruption etc. 
-------------- next part --------------
// Copyright Berthold H?llmann 2002. Permission to copy, use,
// modify, sell and distribute this software is granted provided this
// copyright notice appears in all copies. This software is provided
// "as is" without express or implied warranty, and with no claim as
// to its suitability for any purpose.

#if !defined _HOEL20020726AA_H
#define _HOEL20020726AA_H

#include <Python.h>

#define BOOST_PYTHON_V2 1

#include <boost/python/object_core.hpp>

#include <iostream>

namespace boost {
  namespace python {
    namespace detail {
      // Standard Exceptions wrapper
      template <PyObject** E>
      class python_exception
      {
      public:
        BOOST_PYTHON_DECL python_exception(const object &_msg = object(Py_None)) :
          msg(_msg)
        {
        }
        object BOOST_PYTHON_DECL get()
        {
          PyObject *err = PyInstance_New(oclass, NULL, NULL);
          bool res = PyErr_GivenExceptionMatches(err, PyExc);
          Py_DECREF(err);
          return res;
        };
        bool BOOST_PYTHON_DECL operator== (const PyObject *other) const
        {
          return PyErr_GivenExceptionMatches(other, PyExc);
        }
        bool BOOST_PYTHON_DECL operator== (const python_exception &other) const
        {
          PyObject *oclass = other.get();
          PyObject *err = PyInstance_New(oclass, NULL, NULL);
          bool res = PyErr_GivenExceptionMatches(err, PyExc);
          Py_DECREF(err);
          return res;
        }
      protected:
        static BOOST_PYTHON_DECL object PyExc;
        object msg;
      };

      template <PyTypeObject** E>
      object python_exception<E>::PyExc(*E);
    }

    class exception :
      public detail::python_exception<&PyExc_Exception>
    {
    public:
      BOOST_PYTHON_DECL exception(const object &_msg =
                                  object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_Exception>(_msg)
      {
      }
    };
    class system_exit :
      public detail::python_exception<&PyExc_SystemExit>
    {
    public:
      BOOST_PYTHON_DECL system_exit(const object &_msg =
                                    object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_SystemExit>(_msg)
      {
      }
    };

    class stop_iteration :
      public detail::python_exception<&PyExc_StopIteration>
    {
    public:
      BOOST_PYTHON_DECL stop_iteration(const object &_msg =
                                       object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_StopIteration>(_msg)
      {
      }
    };

    class standard_error :
      public detail::python_exception<&PyExc_StandardError>
    {
    public:
      BOOST_PYTHON_DECL standard_error(const object &_msg =
                                       object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_StandardError>(_msg)
      {
      }
    };

    class keyboard_interrupt :
      public standard_error,
      public detail::python_exception<&PyExc_KeyboardInterrupt>
    {
    public:
      BOOST_PYTHON_DECL keyboard_interrupt(const object &_msg =
                                           object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_KeyboardInterrupt>(_msg)
      {
      }
    };

    class import_error :
      public standard_error,
      public detail::python_exception<&PyExc_ImportError>
    {
    public:
      BOOST_PYTHON_DECL import_error(const object &_msg =
                                     object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_ImportError>(_msg)
      {
      }
    };

    class environment_error :
      public standard_error,
      public detail::python_exception<&PyExc_EnvironmentError>
    {
    public:
      BOOST_PYTHON_DECL environment_error(const object &_msg =
                                          object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_EnvironmentError>(_msg)
      {
      }
    };

    class io_error :
      public environment_error,
      public detail::python_exception<&PyExc_IOError>
    {
    public:
      BOOST_PYTHON_DECL io_error(const object &_msg =
                                 object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_IOError>(_msg)
      {
      }
    };

    class os_error :
      public environment_error,
      public detail::python_exception<&PyExc_OSError>
    {
    public:
      BOOST_PYTHON_DECL os_error(const object &_msg =
                                 object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_OSError>(_msg)
      {
      }
    };
#ifdef MS_WINDOWS
    class windows_error :
      public os_error,
      public detail::python_exception<&PyExc_WindowsError>
    {
    public:
      BOOST_PYTHON_DECL windows_error(const object &_msg =
                                      object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_WindowsError>(_msg)
      {
      }
    };
#endif
    class eof_error :
      public standard_error,
      public detail::python_exception<&PyExc_EOFError>
    {
    public:
      BOOST_PYTHON_DECL eof_error(const object &_msg =
                                  object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_EOFError>(_msg)
      {
      }
    };

    class runtime_error :
      public standard_error,
      public detail::python_exception<&PyExc_RuntimeError>
    {
    public:
      BOOST_PYTHON_DECL runtime_error(const object &_msg =
                                      object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_RuntimeError>(_msg)
      {
      }
    };
    class not_implemented_error :
      public runtime_error,
      public detail::python_exception<&PyExc_NotImplementedError>
    {
    public:
      BOOST_PYTHON_DECL not_implemented_error(const object &_msg =
                                              object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_NotImplementedError>(_msg)
      {
      }
    };
    class name_error :
      public standard_error,
      public detail::python_exception<&PyExc_NameError>
    {
    public:
      BOOST_PYTHON_DECL name_error(const object &_msg =
                                   object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_NameError>(_msg)
      {
      }
    };
    class unbound_local_error :
      public name_error,
      public detail::python_exception<&PyExc_UnboundLocalError>
    {
    public:
      BOOST_PYTHON_DECL unbound_local_error(const object &_msg =
                                            object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_UnboundLocalError>(_msg)
      {
      }
    };
    class attribute_error :
      public standard_error,
      public detail::python_exception<&PyExc_AttributeError>
    {
    public:
      BOOST_PYTHON_DECL attribute_error(const object &_msg =
                                        object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_AttributeError>(_msg)
      {
      }
    };
    class syntax_error :
      public standard_error,
      public detail::python_exception<&PyExc_SyntaxError>
    {
    public:
      BOOST_PYTHON_DECL syntax_error(const object &_msg =
                                     object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_SyntaxError>(_msg)
      {
      }
    };
    class indentation_error :
      public  syntax_error,
      public detail::python_exception<&PyExc_IndentationError>
    {
    public:
      BOOST_PYTHON_DECL indentation_error(const object &_msg =
                                          object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_IndentationError>(_msg)
      {
      }
    };
    class tab_error :
      public indentation_error,
      public detail::python_exception<&PyExc_TabError>
    {
    public:
      BOOST_PYTHON_DECL tab_error(const object &_msg =
                                  object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_TabError>(_msg)
      {
      }
    };
    class type_error :
      public standard_error,
      public detail::python_exception<&PyExc_TypeError>
    {
    public:
      BOOST_PYTHON_DECL type_error(const object &_msg =
                                   object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_TypeError>(_msg)
      {
      }
    };
    class assertion_error :
      public standard_error,
      public detail::python_exception<&PyExc_AssertionError>
    {
    public:
      BOOST_PYTHON_DECL assertion_error(const object &_msg =
                                        object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_AssertionError>(_msg)
      {
      }
    };
    class lookup_error :
      public standard_error,
      public detail::python_exception<&PyExc_LookupError>
    {
    public:
      BOOST_PYTHON_DECL lookup_error(const object &_msg =
                                     object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_LookupError>(_msg)
      {
      }
    };
    class index_error :
      public lookup_error,
      public detail::python_exception<&PyExc_IndexError>
    {
    public:
      BOOST_PYTHON_DECL index_error(const object &_msg =
                                    object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_IndexError>(_msg)
      {
      }
    };
    class key_error :
      public lookup_error,
      public detail::python_exception<&PyExc_KeyError>
    {
    public:
      BOOST_PYTHON_DECL key_error(const object &_msg =
                                  object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_KeyError>(_msg)
      {
      }
    };
    class arithmetic_error :
      public standard_error,
      public detail::python_exception<&PyExc_ArithmeticError>
    {
    public:
      BOOST_PYTHON_DECL arithmetic_error(const object &_msg =
                                         object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_ArithmeticError>(_msg)
      {
      }
    };
    class overflow_error :
      public arithmetic_error,
      public detail::python_exception<&PyExc_OverflowError>
    {
    public:
      BOOST_PYTHON_DECL overflow_error(const object &_msg =
                                       object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_OverflowError>(_msg)
      {
      }
    };
    class zero_division_error :
      public arithmetic_error,
      public detail::python_exception<&PyExc_ZeroDivisionError>
    {
    public:
      BOOST_PYTHON_DECL zero_division_error(const object &_msg =
                                            object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_ZeroDivisionError>(_msg)
      {
      }
    };
    class floating_point_error :
      public arithmetic_error,
      public detail::python_exception<&PyExc_FloatingPointError>
    {
    public:
      BOOST_PYTHON_DECL floating_point_error(const object &_msg =
                                             object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_FloatingPointError>(_msg)
      {
      }
    };
    class value_error :
      public standard_error,
      public detail::python_exception<&PyExc_ValueError>
    {
    public:
      BOOST_PYTHON_DECL value_error(const object &_msg =
                                    object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_ValueError>(_msg)
      {
      }
    };
    class unicode_error :
      public value_error,
      public detail::python_exception<&PyExc_UnicodeError>
    {
    public:
      BOOST_PYTHON_DECL unicode_error(const object &_msg =
                                      object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_UnicodeError>(_msg)
      {
      }
    };
    class reference_error :
      public standard_error,
      public detail::python_exception<&PyExc_ReferenceError>
    {
    public:
      BOOST_PYTHON_DECL reference_error(const object &_msg =
                                        object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_ReferenceError>(_msg)
      {
      }
    };
    class system_error :
      public standard_error,
      public detail::python_exception<&PyExc_SystemError>
    {
    public:
      BOOST_PYTHON_DECL system_error(const object &_msg =
                                     object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_SystemError>(_msg)
      {
      }
    };
    class memory_error :
      public standard_error,
      public detail::python_exception<&PyExc_MemoryError>
    {
    public:
      BOOST_PYTHON_DECL memory_error(const object &_msg =
                                     object(detail::borrowed_reference(Py_None))) :
        detail::python_exception<&PyExc_MemoryError>(_msg)
      {
      }
    };

    BOOST_PYTHON_DECL void
    throw_exception(const object &_msg =
                    object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_system_exit(const object &_msg =
                      object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_stop_iteration(const object &_msg =
                         object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_standard_error(const object &_msg =
                         object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_keyboard_interrupt(const object &_msg =
                             object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_import_error(const object &_msg =
                       object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_environment_error(const object &_msg =
                            object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_io_error(const object &_msg =
                   object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL
    void throw_os_error(const object &_msg =
                        object(detail::borrowed_reference(Py_None)));
#ifdef MS_WINDOWS
    BOOST_PYTHON_DECL void
    throw_windows_error(const object &_msg =
                        object(detail::borrowed_reference(Py_None)));
#endif
    BOOST_PYTHON_DECL void
    throw_eof_error(const object &_msg =
                    object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_runtime_error(const object &_msg =
                        object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_not_implemented_error(const object &_msg =
                                object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_name_error(const object &_msg =
                     object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_unbound_local_error(const object &_msg =
                              object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_attribute_error(const object &_msg =
                          object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_syntax_error(const object &_msg =
                       object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_indentation_error(const object &_msg =
                            object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_tab_error(const object &_msg =
                    object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_type_error(const object &_msg =
                     object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_assertion_error(const object &_msg =
                          object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_lookup_error(const object &_msg =
                       object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_index_error(const object &_msg =
                      object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_key_error(const object &_msg =
                    object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_arithmetic_error(const object &_msg =
                           object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_overflow_error(const object &_msg =
                         object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_zero_division_error(const object &_msg =
                              object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_floating_point_error(const object &_msg =
                               object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_value_error(const object &_msg =
                      object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_unicode_error(const object &_msg =
                        object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_reference_error(const object &_msg =
                          object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_system_error(const object &_msg =
                       object(detail::borrowed_reference(Py_None)));
    BOOST_PYTHON_DECL void
    throw_memory_error(const object &_msg =
                       object(detail::borrowed_reference(Py_None)));

  }
}

#endif // _HOEL20020726AA_H
-------------- next part --------------
// Copyright Berthold H?llmann 2002. Permission to copy, use,
// modify, sell and distribute this software is granted provided this
// copyright notice appears in all copies. This software is provided
// "as is" without express or implied warranty, and with no claim as
// to its suitability for any purpose.


#include <exceptions.hpp>

namespace boost {
  namespace python {

    void BOOST_PYTHON_DECL throw_exception(const object &msg)
    {
      throw exception(msg);
    }
    void BOOST_PYTHON_DECL throw_system_exit(const object &msg)
    {
      throw system_exit(msg);
    }
    void BOOST_PYTHON_DECL throw_stop_iteration(const object &msg)
    {
      throw stop_iteration(msg);
    }
    void BOOST_PYTHON_DECL throw_standard_error(const object &msg)
    {
      throw standard_error(msg);
    }
    void BOOST_PYTHON_DECL throw_keyboard_interrupt(const object &msg)
    {
      throw keyboard_interrupt(msg);
    }
    void BOOST_PYTHON_DECL throw_import_error(const object &msg)
    {
      throw import_error(msg);
    }
    void BOOST_PYTHON_DECL throw_environment_error(const object &msg)
    {
      throw environment_error(msg);
    }
    void BOOST_PYTHON_DECL throw_io_error(const object &msg)
    {
      throw io_error(msg);
    }
    void BOOST_PYTHON_DECL throw_os_error(const object &msg)
    {
      throw os_error(msg);
    }
#ifdef MS_WINDOWS
    void BOOST_PYTHON_DECL throw_windows_error(const object &msg)
    {
      throw windows_error(msg);
    }
#endif
    void BOOST_PYTHON_DECL throw_eof_error(const object &msg)
    {
      throw eof_error(msg);
    }
    void BOOST_PYTHON_DECL throw_runtime_error(const object &msg)
    {
      throw runtime_error(msg);
    }
    void BOOST_PYTHON_DECL throw_not_implemented_error(const object &msg)
    {
      throw not_implemented_error(msg);
    }
    void BOOST_PYTHON_DECL throw_name_error(const object &msg)
    {
      throw name_error(msg);
    }
    void BOOST_PYTHON_DECL throw_unbound_local_error(const object &msg)
    {
      throw unbound_local_error(msg);
    }
    void BOOST_PYTHON_DECL throw_attribute_error(const object &msg)
    {
      throw attribute_error(msg);
    }
    void BOOST_PYTHON_DECL throw_syntax_error(const object &msg)
    {
      throw syntax_error(msg);
    }
    void BOOST_PYTHON_DECL throw_indentation_error(const object &msg)
    {
      throw indentation_error(msg);
    }
    void BOOST_PYTHON_DECL throw_tab_error(const object &msg)
    {
      throw tab_error(msg);
    }
    void BOOST_PYTHON_DECL throw_type_error(const object &msg)
    {
      throw type_error(msg);
    }
    void BOOST_PYTHON_DECL throw_assertion_error(const object &msg)
    {
      throw assertion_error(msg);
    }
    void BOOST_PYTHON_DECL throw_lookup_error(const object &msg)
    {
      throw lookup_error(msg);
    }
    void BOOST_PYTHON_DECL throw_index_error(const object &msg)
    {
      throw index_error(msg);
    }
    void BOOST_PYTHON_DECL throw_key_error(const object &msg)
    {
      throw key_error(msg);
    }
    void BOOST_PYTHON_DECL throw_arithmetic_error(const object &msg)
    {
      throw arithmetic_error(msg);
    }
    void BOOST_PYTHON_DECL throw_overflow_error(const object &msg)
    {
      throw overflow_error(msg);
    }
    void BOOST_PYTHON_DECL throw_zero_division_error(const object &msg)
    {
      throw zero_division_error(msg);
    }
    void BOOST_PYTHON_DECL throw_floating_point_error(const object &msg)
    {
      throw floating_point_error(msg);
    }
    void BOOST_PYTHON_DECL throw_value_error(const object &msg)
    {
      throw value_error(msg);
    }
    void BOOST_PYTHON_DECL throw_unicode_error(const object &msg)
    {
      throw unicode_error(msg);
    }
    void BOOST_PYTHON_DECL throw_reference_error(const object &msg)
    {
      throw reference_error(msg);
    }
    void BOOST_PYTHON_DECL throw_system_error(const object &msg)
    {
      throw system_error(msg);
    }
    void BOOST_PYTHON_DECL throw_memory_error(const object &msg)
    {
      throw memory_error(msg);
    }
  }
} // namespace boost::python
-------------- next part --------------

-- 
Dipl.-Ing. Berthold H?llmann   __   Address:
hoel at germanlloyd.org        G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374    -+----+- Vorsetzen 32/35    P.O.Box 111606
fax  : +49-40-36149-7320      \__/   D-20459 Hamburg    D-20416 Hamburg

From dave at boost-consulting.com  Fri Jul 26 17:47:55 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 26 Jul 2002 11:47:55 -0400
Subject: [C++-sig] A first glance at what could be the boost::python exception system
References: <ser8hqshge.fsf@pc970145.GermanLloyd.de>
Message-ID: <054201c234bc$558f5cf0$6501a8c0@boostconsulting.com>

Berthold,

I'm sorry that I probably don't have time to look at this in detail before
Friday afternoon ends for you; I'll try to get to it over the weekend, and
to respond to your questions in full. It looks good overall. On a stylistic
note I'd like to see more separation of interface from implementation (i.e.
moving member functions outside the function body) and macros (yes, really)
could be used to cut down on code duplication. However, these are minor
details.

Thanks for your contribution,
Dave


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Berthold H?llmann" <hoel at germanlloyd.org>
To: <c++-sig at python.org>
Sent: Friday, July 26, 2002 10:16 AM
Subject: [C++-sig] A first glance at what could be the boost::python
exception system


> Hello all,
>
> David asked if I coud implement the C++ wrapper system for the Python
> exception system. Now, it is friday afternoon again and I won't have
> time to work on this over the weekend. The only test I did was sending
> this through the compiler (g++ 3.1). How do I enable "str(exception)"
> doing someting meaningfull? Another facility that is missing is a
> routine checking for a set Python exception and returning/raising the
> apropriate C++ counterpart. Is there any idea how this could be
> accomplished without a huge set of if/else if's and in a way easy
> extensible for user defined exceptions? I tried to map the class
> hierarchy found with
>
> >python
> Python 2.2.1 (#3, Jun  4 2002, 09:47:49)
> [GCC 3.1] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import exceptions
> >>> help(exceptions)
>
> I left out the warnings, because I don't think they should be mapped
> to C++ Exceptions, but they could be added. I hope it's OK to attach
> "exceptions.hpp" and "exceptions.cpp".
>
> Greetings
>
> Berthold
>
>
>
> This email contains confidential information for the exclusive attention
> of the intended addressee. Any access of third parties to this email is
> unauthorized. Any use of this email by not intended recipients like
> copying, distribution, disclosure etc. is prohibited and may be
> unlawful. When addressed to our clients the content of this email is
> subject to the General Terms and Conditions of GL's Group of Companies
> applicable at the date of this email.
>
> GL's Group of Companies does not warrant and/or guarantee that this
> message at the moment of receipt is authentic, correct and its
> communication free of errors, interruption etc.
>




From rwgk at yahoo.com  Fri Jul 26 20:31:00 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 26 Jul 2002 11:31:00 -0700 (PDT)
Subject: [C++-sig] Implicit constructors?
In-Reply-To: <02ee01c2344f$7d256a60$6501a8c0@boostconsulting.com>
Message-ID: <20020726183100.38549.qmail@web20206.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> I think if you def() the copy constructor it should work automatically
> (though it could be more efficient). Does that help?

def()'ing the copy constructor works. However, registering the
python_sequence_to_container converter for a type that is also exposed with
class_<> leads to confusing behavior. I have not spent enough time to come to a
conlusion. To explain what I've found out so far:

"shared" is a reference-counted array type.

a = shared.double((1,2,3)) # works using the copy-constructor trick
a.as_tuple() # confusing behavior

    PyObject* // BPL_FUTURE return tuple
    as_tuple(const shared<ElementType>& v)
    {
      return bpl_utils::container_to_tuple<shared<ElementType> >::convert(v);
    }

Apparently overload resolution calls the sequence_to_container converter when
matching "a" (Python) to the as_tuple() (C++) argument. My current
implementation of the seq-container converter is so general that it decides "a"
can be converted to an iterator and then goes ahead and constructs a new
shared<ElementType> . Could this interpretation be right so far?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Fri Jul 26 21:10:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 26 Jul 2002 15:10:07 -0400
Subject: [C++-sig] Implicit constructors?
References: <20020726183100.38549.qmail@web20206.mail.yahoo.com>
Message-ID: <06a601c234d8$12cd4d20$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > I think if you def() the copy constructor it should work automatically
> > (though it could be more efficient). Does that help?
>
> def()'ing the copy constructor works. However, registering the
> python_sequence_to_container converter for a type that is also exposed
with
> class_<> leads to confusing behavior. I have not spent enough time to
come to a
> conlusion. To explain what I've found out so far:
>
> "shared" is a reference-counted array type.
>
> a = shared.double((1,2,3)) # works using the copy-constructor trick
> a.as_tuple() # confusing behavior
>
>     PyObject* // BPL_FUTURE return tuple
>     as_tuple(const shared<ElementType>& v)
>     {
>       return bpl_utils::container_to_tuple<shared<ElementType>
>::convert(v);
>     }
>
> Apparently overload resolution calls the sequence_to_container converter
when
> matching "a" (Python) to the as_tuple() (C++) argument. My current
> implementation of the seq-container converter is so general that it
decides "a"
> can be converted to an iterator and then goes ahead and constructs a new
> shared<ElementType> . Could this interpretation be right so far?

Yep. This is part of the reason we need a more-sophisticated overload
resolution mechanism.
However, remember that a const& argument matches rvalue converters. If you
only want to match converters which succeed when an actual shared<Element>
is contained within the Python object (lvalue converters), have your
function take a shared<Element> const* or a shared<Element>& parameter.

HTH,
Dave


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From rwgk at yahoo.com  Sat Jul 27 00:29:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 26 Jul 2002 15:29:48 -0700 (PDT)
Subject: [C++-sig] Implicit constructors?
In-Reply-To: <06a601c234d8$12cd4d20$6501a8c0@boostconsulting.com>
Message-ID: <20020726222948.65494.qmail@web20208.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Yep. This is part of the reason we need a more-sophisticated overload
> resolution mechanism.
> However, remember that a const& argument matches rvalue converters. If you
> only want to match converters which succeed when an actual shared<Element>
> is contained within the Python object (lvalue converters), have your
> function take a shared<Element> const* or a shared<Element>& parameter.

I decided that this was getting way too murky. Therefore I changed the
seq->container converter to only accept Python lists, tuples and iterators. So
if you have some custom type, you have to pass iter(myobj) (in Python) instead
of the bare myobj. As a side-affect, the C++ code looks more pleasing now.

With this change and the copy-contructor trick things are working very nicely
with tru64 cxx 6.5 and gcc 3.0.4.

If anybody would like to have a look at the latest version of my Python wrapper
for the shared<> C++ container including automatic conversions from Python
lists, tuples and iterators (the wrapper could easily be adapted for
std::vector<>), here it is:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/array_family/shared_bpl.h?rev=1.4.2.4&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From rwgk at yahoo.com  Sat Jul 27 00:32:45 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 26 Jul 2002 15:32:45 -0700 (PDT)
Subject: [C++-sig] (no subject)
Message-ID: <20020726223245.65798.qmail@web20208.mail.yahoo.com>

David, are you aware of this problem (8am build from today)?

http://cci.lbl.gov/boost/results/1027695600/dailylog_unix_gcc_test

Is it fixed? If not, you still have 29 minutes before the next auto-build
starts.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From vraghavan at cnmnetwork.com  Sat Jul 27 05:29:34 2002
From: vraghavan at cnmnetwork.com (Srivatsan Raghavan)
Date: Fri, 26 Jul 2002 20:29:34 -0700
Subject: [C++-sig] my final question , really i swear :)
Message-ID: <3D42139E.4080408@cnmnetwork.com>

i'd like to thank you all for your help, and the work you've done with 
boost::python
it's a great library, and i've *LOVED* using it ..

i've only got one *LAST* question :)
from my limited understanding bpl is used for extending c++ types in python
not for embedding python into a C++ application, am i wrong?
and if so i can use bpl to embed python, how can i call a function in a 
python script using one of my
bpl wrapped types ?

these will actually be 2 seperate dll's (if possible) ..

i have one dll called Logging.dll (the python interface to my C++ api)
that i've copy'd to %PYTHON_ROOT%\libs\site-packages\

now i can write scripts such as the following:
#in script.py
import Logging

def run( e ):
    print "this is a function run"
    # e is an object of type LogEvent


now, in another program , i've got a function call such as this
// in c++
bool OutputEvent ( LogEvent &le )
{}
 
now here in the OutputEvent() function , i want to call the function 
run() in script.py and pass it a pointer
or reference to le (and can i pass a ref to the original object that can 
be modified
in the python script) or do i have to pass a copy?
that's my question right now?

   


--vat




From rwgk at yahoo.com  Sat Jul 27 22:40:46 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 27 Jul 2002 13:40:46 -0700 (PDT)
Subject: [C++-sig] bpl_utils explained
Message-ID: <20020727204046.98274.qmail@web20206.mail.yahoo.com>

I beat some more on the convertible() function of the
register_container_from_python_sequence class in bpl_utils.h
(everything else pretty much unchanged). The goal was to make
this "more robust" rather than "more magical." This is how
it works now:

- Only Python lists, tuples, iterators and xrange objects are
  convertible. The limitation to these types is essential for
  avoiding surprises without much loss of generality: the Python
  list() or iter() command can be used to easily convert
  custom sequence types before passing them to a wrapped
  C++ function.

- Conversion policies are defined by a "registration_adaptor"
  struct (see bpl_utils.h).

- There are two fundamentally different conversion policies.
  Which one is used is determined by a static member function
  in the registration adaptors, e.g.:

  static bool check_convertibility_per_element() { return true; }

  true: The native Python object must be a list, tuple or xrange
        object. Any other object is not convertible.
        PyObject_Length() is used to determine the size of the
        sequence and passed to the check_size() function of
        the registration adaptor. If this returns true,
        lists and tuples are traversed. extract<> is called
        for each element. The input object is deemed convertible only
        if the size check returns true and if all elements are
        convertible.
        As an optimization, if the input sequence is a xrange
        object, only the first element is tested for convertibility.

        If overload resolution finally calls the construct()
        function, the input object is traversed a second time.

  false: convertible() returns true if the input object is a
         list, tuple, iterator or xrange object. No other
         checks are performed. The input sequence or iterator
         is not traversed.
         If overload resolution finally calls the construct()
         function the input object is traversed. An exception is
         thrown if any of the elements is not convertible.

David, I feel that this is now at a point where it could be moved to
the library. When doing this, we should rename virtually everything.
E.g.

registration_adaptor -> registration_policy,
register_container_from_python_sequence -> register_container_from_native
or maybe extract_container_from_native. Feel free to make
unilateral decisions on the naming.

Ralf

To get the files:

cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx co -r
boost_python_v2_transition cctbx

cctbx/include/cctbx/bpl_utils.h
cctbx/misc


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Sun Jul 28 03:43:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 27 Jul 2002 21:43:40 -0400
Subject: [C++-sig] bpl_utils explained
References: <20020727204046.98274.qmail@web20206.mail.yahoo.com>
Message-ID: <01f501c235d8$835a3390$6501a8c0@boostconsulting.com>

Hi Ralf,

I'm appreciative of all the work you've been doing, so please don't take
this the wrong way: I don't understand why the simple change of using a
pointer or non-const reference as the first argument to one of your
functions instead of a const reference is distasteful enough to warrant
removing conversion from general sequences. That seems like a pretty
radical change to make for the sake of the style of what is essentially an
implementation detail.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Saturday, July 27, 2002 4:40 PM
Subject: [C++-sig] bpl_utils explained


> I beat some more on the convertible() function of the
> register_container_from_python_sequence class in bpl_utils.h
> (everything else pretty much unchanged). The goal was to make
> this "more robust" rather than "more magical." This is how
> it works now:
>
> - Only Python lists, tuples, iterators and xrange objects are
>   convertible. The limitation to these types is essential for
>   avoiding surprises without much loss of generality: the Python
>   list() or iter() command can be used to easily convert
>   custom sequence types before passing them to a wrapped
>   C++ function.
>
> - Conversion policies are defined by a "registration_adaptor"
>   struct (see bpl_utils.h).
>
> - There are two fundamentally different conversion policies.
>   Which one is used is determined by a static member function
>   in the registration adaptors, e.g.:
>
>   static bool check_convertibility_per_element() { return true; }
>
>   true: The native Python object must be a list, tuple or xrange
>         object. Any other object is not convertible.
>         PyObject_Length() is used to determine the size of the
>         sequence and passed to the check_size() function of
>         the registration adaptor. If this returns true,
>         lists and tuples are traversed. extract<> is called
>         for each element. The input object is deemed convertible only
>         if the size check returns true and if all elements are
>         convertible.
>         As an optimization, if the input sequence is a xrange
>         object, only the first element is tested for convertibility.
>
>         If overload resolution finally calls the construct()
>         function, the input object is traversed a second time.
>
>   false: convertible() returns true if the input object is a
>          list, tuple, iterator or xrange object. No other
>          checks are performed. The input sequence or iterator
>          is not traversed.
>          If overload resolution finally calls the construct()
>          function the input object is traversed. An exception is
>          thrown if any of the elements is not convertible.
>
> David, I feel that this is now at a point where it could be moved to
> the library. When doing this, we should rename virtually everything.
> E.g.
>
> registration_adaptor -> registration_policy,
> register_container_from_python_sequence -> register_container_from_native
> or maybe extract_container_from_native. Feel free to make
> unilateral decisions on the naming.
>
> Ralf
>
> To get the files:
>
> cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx
co -r
> boost_python_v2_transition cctbx
>
> cctbx/include/cctbx/bpl_utils.h
> cctbx/misc
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From rwgk at yahoo.com  Sun Jul 28 11:14:26 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 28 Jul 2002 02:14:26 -0700 (PDT)
Subject: [C++-sig] bpl_utils explained
In-Reply-To: <01f501c235d8$835a3390$6501a8c0@boostconsulting.com>
Message-ID: <20020728091426.67108.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> I'm appreciative of all the work you've been doing, so please don't take
> this the wrong way: I don't understand why the simple change of using a
> pointer or non-const reference as the first argument to one of your
> functions instead of a const reference is distasteful enough to warrant
> removing conversion from general sequences. That seems like a pretty
> radical change to make for the sake of the style of what is essentially an
> implementation detail.

The short answer:

The "simple change" did not seem generally applicable to me. People will
have code like:

struct user
{
  void foo(std::vector<double> const& v);
};


The longer answer:

Users will want to know:

How does overload resolution work if you have both a class_<T> and
register_container_from_python_sequence<T, some_policy>?

(where T is e.g. std::vector<U> or std::list<U>)

My previous posting gives /an/ answer that I thought a wider audience
can absorb and work with. Could you please modify the explanation under
"true" and "false" to reflect what you'd like to see? I could then
try the implementation.

Say you have

class_<std::vector<int> > ...
register_container_from_python_sequence<
  std::vector<int>,
  variable_size_container_registration_adaptor>();

class_<std::vector<double> > ...
register_container_from_python_sequence<
  std::vector<double>,
  variable_size_container_registration_adaptor>();

struct user
{
  void foo(std::vector<double> const& v);
};

class_<user> ...

Do you want a std::vector<int> to match the argument of foo()?
Another situation:

struct user
{
  void foo(std::vector<int> const& v);
  void foo(std::vector<double> const& v);
};

What should happen now?

Ralf

P.S.: I've remove my as_tuple() function because tuple() (or list() or
iter()) does the job anyway:

Python 2.2.1 (#1, Apr 10 2002, 12:12:48) [C] on osf1V5
Type "help", "copyright", "credits" or "license" for more information.
>>> from cctbx_boost.arraytbx import shared
>>> a=shared.double((1,2,3))
>>> a
<cctbx_boost.arraytbx.shared.double object at 0x1400f9cd8>
>>> list(a)
[1.0, 2.0, 3.0]
>>> tuple(a)
(1.0, 2.0, 3.0)
>>> i=iter(a)
>>> print i.next()
1.0
>>> print i.next()
2.0
>>> print i.next()
3.0
>>> print i.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
StopIteration


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Sun Jul 28 15:13:01 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 28 Jul 2002 09:13:01 -0400
Subject: [C++-sig] bpl_utils explained
References: <20020728091426.67108.qmail@web20207.mail.yahoo.com>
Message-ID: <003601c23638$dbe2fd70$6801a8c0@boostconsulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
> > I'm appreciative of all the work you've been doing, so please don't
take
> > this the wrong way: I don't understand why the simple change of using a
> > pointer or non-const reference as the first argument to one of your
> > functions instead of a const reference is distasteful enough to warrant
> > removing conversion from general sequences. That seems like a pretty
> > radical change to make for the sake of the style of what is essentially
an
> > implementation detail.
>
> The short answer:
>
> The "simple change" did not seem generally applicable to me. People will
> have code like:
>
> struct user
> {
>   void foo(std::vector<double> const& v);
> };
>

You're right of course. I realized why this would be an issue the moment I
woke up this morning ;-).

However, I think I have a solution for you (it was there, lurking, all
along)...

> The longer answer:
>
> Users will want to know:
>
> How does overload resolution work if you have both a class_<T> and
> register_container_from_python_sequence<T, some_policy>?


OK. Well, first, you just need to use registry::push_back to register this
converter instead of registry::insert. That is the hack used by
implicitly_covertible<T,U> to make these conversions lowest-priority. I
think of the conversion you're registering the same way: it is determined
that some some C++ rvalue T can be extracted in the convertible step, then
in the convert step it is extracted  and converted to U.

In this case, the analogous T is a type we haven't yet actually written
called "sequence" which can be built from any sequence.

Anyway, that will put
register_container_from_python_sequence<T,some_policy> at the same priority
as all implicit conversions, which is to say it will be at a lower priority
than regular rvalue and lvalue conversions.

> (where T is e.g. std::vector<U> or std::list<U>)
>
> My previous posting gives /an/ answer that I thought a wider audience
> can absorb and work with.

I understand why you did that.

> Could you please modify the explanation under
> "true" and "false" to reflect what you'd like to see? I could then
> try the implementation.
>
> Say you have
>
> class_<std::vector<int> > ...
> register_container_from_python_sequence<
>   std::vector<int>,
>   variable_size_container_registration_adaptor>();
>
> class_<std::vector<double> > ...
> register_container_from_python_sequence<
>   std::vector<double>,
>   variable_size_container_registration_adaptor>();
>
> struct user
> {
>   void foo(std::vector<double> const& v);
> };
>
> class_<user> ...
>
> Do you want a std::vector<int> to match the argument of foo()?

If class_<std::vector<int> > exposes enough interface to make it a
sequence, I guess I do.

> Another situation:
>
> struct user
> {
>   void foo(std::vector<int> const& v);
>   void foo(std::vector<double> const& v);
> };
>
> What should happen now?

Well, here both functions match because our overload resolution mechanism
is naive, so currently you get whichever one was registered last(?).

I just want to stress that this is a problem with the formulation of BPL
overload resolution. I'd really REALLY like to address this. However, I'll
need other people to participate in thinking about how it should work at a
high level (not implementation details) in order to come up with something.
The question is basically this: what should the prioritization rule be when
multiple overloaded functions match?

When I brought this up on python-dev, Guido sent me over to the types-sig,
where it met with a deathly silence:
http://aspn.activestate.com/ASPN/Mail/Message/types-sig/1222793. Turns out
the types-sig is effectively dead. He claims this wasn't an attempt to kill
the conversation, but I have my doubts<wink>.

If anyone is ready to discuss this in the context of C++, so am I...

-Dave

> P.S.: I've remove my as_tuple() function because tuple() (or list() or
> iter()) does the job anyway:

Nice!


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Mon Jul 29 00:05:47 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 28 Jul 2002 15:05:47 -0700 (PDT)
Subject: [C++-sig] bpl_utils explained
In-Reply-To: <003601c23638$dbe2fd70$6801a8c0@boostconsulting.com>
Message-ID: <20020728220548.61543.qmail@web20205.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> OK. Well, first, you just need to use registry::push_back to register this
> converter instead of registry::insert.
> ...
> Anyway, that will put
> register_container_from_python_sequence<T,some_policy> at the same priority
> as all implicit conversions, which is to say it will be at a lower priority
> than regular rvalue and lvalue conversions.

The availability of registry::push_back changes everything.

> > struct user
> > {
> >   void foo(std::vector<double> const& v);
> > };
> >
> > class_<user> ...
> >
> > Do you want a std::vector<int> to match the argument of foo()?
> 
> If class_<std::vector<int> > exposes enough interface to make it a
> sequence, I guess I do.

Of course I was thinking that both std::vector<int> and std::vector<double>
are exposed via class_<> . With the registry::push_back trick this
should now work as one expects.

> > Another situation:
> >
> > struct user
> > {
> >   void foo(std::vector<int> const& v);
> >   void foo(std::vector<double> const& v);
> > };
> >
> > What should happen now?
> 
> Well, here both functions match because our overload resolution mechanism
> is naive, so currently you get whichever one was registered last(?).

But if both std::vector<int> and std::vector<double> are exposed
via class_<> there is no ambiguity, right?

Please look at the new register_container_from_python_sequence::convertible
(everything else unchanged; except for the insert->push_back change).

Revised explanation:

Let obj be the object to be converted.

- obj is convertible only if it can be converted to an iterator
  (test is equivalent to iter(obj) in Python).

- Conversion policies are defined by a "registration_adaptor"
  struct (see bpl_utils.h).

- There are two fundamentally different conversion policies.
  Which one is used is determined by a static member function
  in the registration adaptors, e.g.:

  static bool check_convertibility_per_element() { return true; }

  false: no further checks are performed. convertible() returns true.

  true: obj is convertible only if PyObject_Length(obj) >= 0.

        PyObject_Length() is used to determine the size of the sequence
        and passed to the check_size() function of the registration
        adaptor. If this returns true, the sequence is traversed and
        extract<> is called for each element. obj is convertible only
        if the size check returns true and if all elements are
        convertible.

        As an optimization, if obj is a xrange object, only the first
        element is tested for convertibility.

        If overload resolution finally calls the construct()
        function, the obj is traversed a second time.

This is very nice and general and my tests all work fine. Could there
be any unpleasant surprises lurking?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Mon Jul 29 01:48:16 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 28 Jul 2002 19:48:16 -0400
Subject: [C++-sig] bpl_utils explained
References: <20020728220548.61543.qmail@web20205.mail.yahoo.com>
Message-ID: <015101c23691$40230570$6801a8c0@boostconsulting.com>

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

> The availability of registry::push_back changes everything.

I don't think it changes /everything/ unfortunately.

> > > struct user
> > > {
> > >   void foo(std::vector<double> const& v);
> > > };
> > >
> > > class_<user> ...
> > >
> > > Do you want a std::vector<int> to match the argument of foo()?
> >
> > If class_<std::vector<int> > exposes enough interface to make it a
> > sequence, I guess I do.
>
> Of course I was thinking that both std::vector<int> and
std::vector<double>
> are exposed via class_<> . With the registry::push_back trick this
> should now work as one expects.
>
> > > Another situation:
> > >
> > > struct user
> > > {
> > >   void foo(std::vector<int> const& v);
> > >   void foo(std::vector<double> const& v);
> > > };
> > >
> > > What should happen now?
> >
> > Well, here both functions match because our overload resolution
mechanism
> > is naive, so currently you get whichever one was registered last(?).
>
> But if both std::vector<int> and std::vector<double> are exposed
> via class_<> there is no ambiguity, right?

If each one exposes a sequence interface, and if the presence of a sequence
interface and convertible elements is enough for your from_python converter
to report convertibility, then I think there is ambiguity. Although there
is a crude priority system for converter matching (rvalue converters that
have been "pushed back" are considered last for arguments for which rvalue
conversions are eligible -- T, T const&), the system for function overload
matching is still first-come, first-served.

IOW, function overloads are considered in sequence, and the first one for
which all arguments find converters is called.

> Please look at the new
register_container_from_python_sequence::convertible
> (everything else unchanged; except for the insert->push_back change).

I'm not sure I'm looking in the right place.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_
tag=boost_python_v2_transition shows the most recent change 27 hours ago...

> Revised explanation:
>
> Let obj be the object to be converted.
>
> - obj is convertible only if it can be converted to an iterator
>   (test is equivalent to iter(obj) in Python).
>
> - Conversion policies are defined by a "registration_adaptor"
>   struct (see bpl_utils.h).

I can't even find that file...

> - There are two fundamentally different conversion policies.
>   Which one is used is determined by a static member function
>   in the registration adaptors, e.g.:
>
>   static bool check_convertibility_per_element() { return true; }

Hmm, wouldn't it be better to do this with something that could be
evaluated at compile time? That would guarantee avoiding generating code
for the check in the case where it was false.

>   false: no further checks are performed. convertible() returns true.
>
>   true: obj is convertible only if PyObject_Length(obj) >= 0.
>
>         PyObject_Length() is used to determine the size of the sequence
>         and passed to the check_size() function of the registration
>         adaptor. If this returns true, the sequence is traversed and
>         extract<> is called for each element. obj is convertible only
>         if the size check returns true and if all elements are
>         convertible.
>
>         As an optimization, if obj is a xrange object, only the first
>         element is tested for convertibility.
>
>         If overload resolution finally calls the construct()
>         function, the obj is traversed a second time.
>
> This is very nice and general and my tests all work fine. Could there
> be any unpleasant surprises lurking?

I'm not really sure about the vector overloads we discussed earlier. If
there's no ambiguity, I'm a little surprised...

-Dave





From rwgk at yahoo.com  Mon Jul 29 08:27:17 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 28 Jul 2002 23:27:17 -0700 (PDT)
Subject: [C++-sig] bpl_utils explained
In-Reply-To: <015101c23691$40230570$6801a8c0@boostconsulting.com>
Message-ID: <20020729062717.89815.qmail@web20209.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> If each one exposes a sequence interface, and if the presence of a sequence
> interface and convertible elements is enough for your from_python converter
> to report convertibility, then I think there is ambiguity. Although there
> is a crude priority system for converter matching (rvalue converters that
> have been "pushed back" are considered last for arguments for which rvalue
> conversions are eligible -- T, T const&), the system for function overload
> matching is still first-come, first-served.

Sorry, you lost me here.
Let's call the "inserted" converters class 1 converters, and the
"pushed back" converters class 2 converters.
Isn't it that all converters generated via class_<> are class 1
converters?
Isn't it that overload resolution /always/ tests /all/ class 1
converters before resorting to class 2 converters?

Now let's say overload resolution is trying to match

void foo(std::vector<int> const& v)

Say there is only this one foo() (IOW no other overloads).
For the conversion to succeed there has to be at least one registered
std::vector<int> converter, either class 1 or class 2. If there is only
a class 2, the Python object to be converted cannot be a wrapped
std::vector<int> .
Right?
If there is a class1 converter, the Python object to be converted could
be a std::vector<int>, and if it is, it will be converted with the class 1
converter.
Right?
If the Python object to be converted is not a std::vector<int> but
it is a sequence (measurable or not measurable, depending on
"check_convertibility_per_element"), it will be converted by the
class 2 converter.
Right?

Now lets look at this:

void foo(std::vector<int> const& v)
void foo(std::vector<double> const& v)

If both vector types have a class 1 converter there is no ambiguity.
Right?
If both have only a class 2 converter the ambiguity is exactly
equivalent to this situation:

void foo(int)
void foo(double)

The overload that is tried first during overload resolution is used.
Right?

Now say std::vector<int> is class 1 & 2 convertible, and
std::vector<double> only class 2. If the object to be converted
is a wrapped std::vector<int> it will be converted class 1,
otherwise the overload tried first will be used.

If this is all correct, then I conclude that there is nothing new to
learn for Boost Python users. Just as we cannot be sure if we get
foo(int) or foo(double) until we know the order in which the converters
were registered we cannot be sure if we get foo(std::vector<int>) or
foo(std::vector<double>) if the class 1 vector containers are missing.
Other than that the conversions are "predictable" without having to know the
order of registration.
Correct?

> IOW, function overloads are considered in sequence, and the first one for
> which all arguments find converters is called.

Is my conclusion above what you mean?

> I'm not sure I'm looking in the right place.
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_
> tag=boost_python_v2_transition shows the most recent change 27 hours ago...

cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx co -r
boost_python_v2_transition cctbx

cctbx/include/cctbx/bpl_utils.h
cctbx/misc

cctbx/include/cctbx/array_family/shared_bpl.h
cctbx/arraytbx/shared*.cpp

> >   static bool check_convertibility_per_element() { return true; }
> 
> Hmm, wouldn't it be better to do this with something that could be
> evaluated at compile time? That would guarantee avoiding generating code
> for the check in the case where it was false.

After you move my stuff to the library I will check how you get this
to work without compile-time warnings ("unreachable code").

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Mon Jul 29 09:11:03 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 29 Jul 2002 03:11:03 -0400
Subject: [C++-sig] bpl_utils explained
References: <20020729062717.89815.qmail@web20209.mail.yahoo.com>
Message-ID: <023b01c236cf$34f6e0c0$6801a8c0@boostconsulting.com>

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 29, 2002 2:27 AM
Subject: Re: [C++-sig] bpl_utils explained


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > If each one exposes a sequence interface, and if the presence of a
sequence
> > interface and convertible elements is enough for your from_python
converter
> > to report convertibility, then I think there is ambiguity. Although
there
> > is a crude priority system for converter matching (rvalue converters
that
> > have been "pushed back" are considered last for arguments for which
rvalue
> > conversions are eligible -- T, T const&), the system for function
overload
> > matching is still first-come, first-served.
>
> Sorry, you lost me here.
> Let's call the "inserted" converters class 1 converters, and the
> "pushed back" converters class 2 converters.

Not to confuse things here, but within class 1 we have subcategories of
lvalue and rvalue converters (class 2 is only rvalue converters).

> Isn't it that all converters generated via class_<> are class 1
> converters?

Yes, they are in fact lvalue converters.

> Isn't it that overload resolution /always/ tests /all/ class 1
> converters before resorting to class 2 converters?

For each overload, yes. In other words, each overload is considered
separately. If an overload for which matches using a class 2 converter is
considered first, it won't matter that another overload can match using a
class 1 converter. That's what I mean by "naive overload resolution".

> Now let's say overload resolution is trying to match
>
> void foo(std::vector<int> const& v)
>
> Say there is only this one foo() (IOW no other overloads).
> For the conversion to succeed there has to be at least one registered
> std::vector<int> converter, either class 1 or class 2. If there is only
> a class 2, the Python object to be converted cannot be a wrapped
> std::vector<int> .
> Right?

Not neccessarily. You could create a class 2 converter which converts from
wrapped std::vector<int> to std::vector<int>. In fact, I think

    implicitly_convertible<std::vector<int>, std::vector<int> >();

would be enough to do it. However, barring such perversity, you are right.

> If there is a class1 converter, the Python object to be converted could
> be a std::vector<int>, and if it is, it will be converted with the class
1
> converter.
> Right?

Right.

> If the Python object to be converted is not a std::vector<int> but
> it is a sequence (measurable or not measurable, depending on
> "check_convertibility_per_element"), it will be converted by the
> class 2 converter.
> Right?

Right.

> Now lets look at this:
>
> void foo(std::vector<int> const& v)
> void foo(std::vector<double> const& v)
>
> If both vector types have a class 1 converter there is no ambiguity.
> Right?

I'm not sure whether by "class 1" you mean the specific converters which
are currently inserted, or any converter which is allowed to be inserted.
Since there's nothing stopping you from using insert on any particular
converter, I guess your statement above is false (in general).

Here's a statement which is true:

    If both types have ONLY an lvalue converter there is no ambiguity.

> If both have only a class 2 converter the ambiguity is exactly
> equivalent to this situation:
>
> void foo(int)
> void foo(double)
>
> The overload that is tried first during overload resolution is used.
> Right?

Right.

> Now say std::vector<int> is class 1 & 2 convertible, and
> std::vector<double> only class 2. If the object to be converted
> is a wrapped std::vector<int> it will be converted class 1,
> otherwise the overload tried first will be used.

That would be nice, but it ain't so. If the vector<double> overload is
tried first it will match, and overload resolution will stop there.

> If this is all correct, then I conclude that there is nothing new to
> learn for Boost Python users. Just as we cannot be sure if we get
> foo(int) or foo(double) until we know the order in which the converters
> were registered we cannot be sure if we get foo(std::vector<int>) or
> foo(std::vector<double>) if the class 1 vector containers are missing.
> Other than that the conversions are "predictable" without having to know
the
> order of registration.
> Correct?

Nope. FWIW, Even if that were the case, I'm not satisfied with having an
ordering dependency on converter registration.

> > IOW, function overloads are considered in sequence, and the first one
for
> > which all arguments find converters is called.
>
> Is my conclusion above what you mean?

No :(

> > I'm not sure I'm looking in the right place.
> >
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_
> > tag=boost_python_v2_transition shows the most recent change 27 hours
ago...
>
> cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx
co -r
> boost_python_v2_transition cctbx
>
> cctbx/include/cctbx/bpl_utils.h
> cctbx/misc
>
> cctbx/include/cctbx/array_family/shared_bpl.h
> cctbx/arraytbx/shared*.cpp
>
> > >   static bool check_convertibility_per_element() { return true; }
> >
> > Hmm, wouldn't it be better to do this with something that could be
> > evaluated at compile time? That would guarantee avoiding generating
code
> > for the check in the case where it was false.
>
> After you move my stuff to the library I will check how you get this
> to work without compile-time warnings ("unreachable code").

I doubt I'm going to be able to do any of this before I get back from
vacation. I'm trying to prepare to teach a class in Oregon on Tuesday and
I'm running out of time.

Thanks, though: I mean it!

-Dave





From rwgk at yahoo.com  Mon Jul 29 10:40:04 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 29 Jul 2002 01:40:04 -0700 (PDT)
Subject: [C++-sig] bpl_utils explained
In-Reply-To: <023b01c236cf$34f6e0c0$6801a8c0@boostconsulting.com>
Message-ID: <20020729084004.39278.qmail@web20204.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Now say std::vector<int> is class 1 & 2 convertible, and
> > std::vector<double> only class 2. If the object to be converted
> > is a wrapped std::vector<int> it will be converted class 1,
> > otherwise the overload tried first will be used.
> 
> That would be nice, but it ain't so. If the vector<double> overload is
> tried first it will match, and overload resolution will stop there.

Ouch.

Please forgive me, but I still feel I can protect myself from confusing
situations due to the "naive" overload resolution mechanism by restricting the
from_python_sequence converters to lists, tuples, iterators and xranges. For
the time being. To be relaxed once the overload resolution mechanism is
enhanced. Does that make sense as an interim approach?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From dave at boost-consulting.com  Mon Jul 29 10:45:01 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 29 Jul 2002 04:45:01 -0400
Subject: [C++-sig] bpl_utils explained
References: <20020729084004.39278.qmail@web20204.mail.yahoo.com>
Message-ID: <027b01c236dc$3befee00$6801a8c0@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > > Now say std::vector<int> is class 1 & 2 convertible, and
> > > std::vector<double> only class 2. If the object to be converted
> > > is a wrapped std::vector<int> it will be converted class 1,
> > > otherwise the overload tried first will be used.
> >
> > That would be nice, but it ain't so. If the vector<double> overload is
> > tried first it will match, and overload resolution will stop there.
>
> Ouch.
>
> Please forgive me, but I still feel I can protect myself from confusing
> situations due to the "naive" overload resolution mechanism by
restricting the
> from_python_sequence converters to lists, tuples, iterators and xranges.
For
> the time being. To be relaxed once the overload resolution mechanism is
> enhanced. Does that make sense as an interim approach?

Sure.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com