From rwgk at yahoo.com  Sat Jun  1 02:38:50 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 31 May 2002 17:38:50 -0700 (PDT)
Subject: [C++-sig] V2: isinstance(obj,cls) equivalent
In-Reply-To: <068101c208e8$a9f7a810$6601a8c0@boostconsulting.com>
Message-ID: <20020601003850.19520.qmail@web20203.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> 
> > I am really impressed by the nice mechanism for registering a custom
> > to_python conversion.
> > What is the best way to define and register an equivalent custom
> > from_python converter?
> 
> Have you looked at lvalue_from_pytype? The documentation is quite complete.

I had looked it this but failed to make the connection.
BTW: Where is the definition of noddy_NoddyType in the example?

> If you don't want to convert a particular Python type but would instead
> like to convert, e.g. any Python sequence, take a look at the
> implementation of lvalue_from_pytype instead. The low-level interfaces it
> uses are not documented, but it's pretty simple. If you wanted to make and
> document a more-general from_python converter registration facility which
> included a way to customize matching of Python types, I'd be happy to put
> it in the library.

My plan is to accept both Python lists and tuples for conversion
to a boost::array<T,N> look-alike (af::tiny<T,N>). Attached is code
that compiles and works at least partially.

Questions regarding this code:

- I was hoping that
      data->convertible = storage;
  signals that the conversion was successful, and failed otherwise.
  When I run the code it appears that this is not the case.
  Is convertible() the only way to signal failure (apart from
  throwing an exception)?
  If so, how can I get around having to unpack the tuple or list twice
  (once for convertible() and then for construct())?

- Will rvalue_stage1_data manage the memory that is allocated by
      new (storage) tiny_type();
  ?

Thanks,
        Ralf

P.S.: I realize that the code might be lower-level than necessary. It
is partially an exercise to familiarize myself with the new code base.


  template <typename ElementType, std::size_t N>
  struct register_tiny_from_python
  {
    typedef af::tiny<ElementType, N> tiny_type;

    register_tiny_from_python()
    {
      boost::python::converter::registry::insert(
        &convertible,
        &construct,
        boost::python::type_id<tiny_type>());
    }

    static void* convertible(PyObject* obj)
    {
      return obj;
    }

    static void construct(
      PyObject* obj, boost::python::converter::rvalue_stage1_data* data)
    {
      using namespace boost::python;

      void* storage = ((
        converter::rvalue_base_data<tiny_type>*)data)->storage.bytes;
      new (storage) tiny_type();
      tuple t;
      if      (PyList_Check(obj)) {
        t = tuple(ref(PyList_AsTuple(obj)));
      }
      else if (PyTuple_Check(obj)) {
        t = tuple(ref(obj, ref::increment_count));
      }
      else {
        return;
      }
      if (t.size() != N) return;
      tiny_type& result = *((tiny_type*)storage);
      for(std::size_t i=0;i<result.size();i++) {
        from_python<ElementType const&> from_py(t[i].get());
        if (!from_py.convertible()) return;
        result[i] = from_py(t[i].get());
      }
      data->convertible = storage;
    }
  };


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Sat Jun  1 03:06:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 21:06:30 -0400
Subject: [C++-sig] V2: isinstance(obj,cls) equivalent
References: <20020601003850.19520.qmail@web20203.mail.yahoo.com>
Message-ID: <071c01c20908$91a6eee0$6601a8c0@boostconsulting.com>

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

> > Have you looked at lvalue_from_pytype? The documentation is quite
complete.
>
> I had looked it this but failed to make the connection.
> BTW: Where is the definition of noddy_NoddyType in the example?

Follow the link to the noddy example module.

> My plan is to accept both Python lists and tuples for conversion
> to a boost::array<T,N> look-alike (af::tiny<T,N>). Attached is code
> that compiles and works at least partially.

Very nice effort!

> Questions regarding this code:
>
> - I was hoping that
>       data->convertible = storage;
>   signals that the conversion was successful, and failed otherwise.

Not quite:
data->convertible = 0 signals failure.
data->convertible = storage signals that the result object was constructed
in the converter, and must be destroyed

Note that there are 2 sides to any conversion: the client side and the
"server" (or converter) side.

When the client says "I need an rvalue of type vector<T>" (by wrapping a
function taking a vector<T> or vector<T> const& parameter), he's actually
willing to accept an lvalue. This matches C++ semantics; otherwise we'd be
forced to pass a temporary every time a function took a T or a T const&
parameter.

So the registration for rvalue from_python converters for a type T actually
includes all the rvalue /and/ lvalue "server" converters. a client-side
from_python converter for rvalues of type T sees all of them.

So, in case a matching lvalue "server" converter is found,
data->convertible will point to the T lvalue that was found. If an rvalue
converter is found, the T is constructed in the client-side converter
storage and data->convertible will point to that.

>   When I run the code it appears that this is not the case.
>   Is convertible() the only way to signal failure (apart from
>   throwing an exception)?

An rvalue (server side) converter must always register a function to signal
convertibility; that's how overload resolution works. If conversion is
going to fail after the convertible function returns true, it must be via
an exception.

>   If so, how can I get around having to unpack the tuple or list twice
>   (once for convertible() and then for construct())?

I'm not sure. I ran into a similar problem with implicitly_convertible<>.
You might want to check out boost/python/converter/implicit.hpp

> - Will rvalue_stage1_data manage the memory that is allocated by
>       new (storage) tiny_type();
>   ?

If you set data->convertible = storage as soon as that succeeds, then yes.
What you're doing below is too late.

> Thanks,
>         Ralf
>
> P.S.: I realize that the code might be lower-level than necessary. It
> is partially an exercise to familiarize myself with the new code base.

No, it's very good.

You should use converter::callback_from_python<ElementType> instead of
from_python<ElementType> to extract elements.

-Dave

>
>
>   template <typename ElementType, std::size_t N>
>   struct register_tiny_from_python
>   {
>     typedef af::tiny<ElementType, N> tiny_type;
>
>     register_tiny_from_python()
>     {
>       boost::python::converter::registry::insert(
>         &convertible,
>         &construct,
>         boost::python::type_id<tiny_type>());
>     }
>
>     static void* convertible(PyObject* obj)
>     {
>       return obj;
>     }
>
>     static void construct(
>       PyObject* obj, boost::python::converter::rvalue_stage1_data* data)
>     {
>       using namespace boost::python;
>
>       void* storage = ((
>         converter::rvalue_base_data<tiny_type>*)data)->storage.bytes;
>       new (storage) tiny_type();
>       tuple t;
>       if      (PyList_Check(obj)) {
>         t = tuple(ref(PyList_AsTuple(obj)));
>       }
>       else if (PyTuple_Check(obj)) {
>         t = tuple(ref(obj, ref::increment_count));
>       }
>       else {
>         return;
>       }
>       if (t.size() != N) return;
>       tiny_type& result = *((tiny_type*)storage);
>       for(std::size_t i=0;i<result.size();i++) {
>         from_python<ElementType const&> from_py(t[i].get());
>         if (!from_py.convertible()) return;
>         result[i] = from_py(t[i].get());
>       }
>       data->convertible = storage;
>     }
>   };
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From pearu at cens.ioc.ee  Sat Jun  1 10:23:19 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 1 Jun 2002 11:23:19 +0300 (EEST)
Subject: [C++-sig] cannot return boost::python::tuple
In-Reply-To: <20020530073909.17078.qmail@web20203.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0206011115560.1999-100000@cens.ioc.ee>

On Thu, 30 May 2002, Ralf W. Grosse-Kunstleve wrote:

> --- David Abrahams <david.abrahams at rcn.com> wrote:
> >     template <class T>
> >     ref make_ref(T const& x)
> >     {
> >         return
> > ref(boost::python::converter::callback_to_python<T>(x).get(),
> > ref::increment_count);
> >     }
> 
> This works great.
> 
> And, cool, this works, too:
> 
>   boost::python::module("any")
>     .setattr("__version__", boost::python::make_ref("1.2.3"));

Works also here but when trying to use it for an instance of a class A:

  m.add(boost::python::class_<A>("A").def_init(boost::python::args<>()));
  m.setattr("a", make_ref(A()));

I get

  TypeError: no to_python (by-value) converter found for type

when importing the extension module.
What I am missing here?

Thanks,
	Pearu





From pearu at cens.ioc.ee  Sat Jun  1 12:33:57 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 1 Jun 2002 13:33:57 +0300 (EEST)
Subject: [C++-sig] cannot return boost::python::tuple
In-Reply-To: <Pine.LNX.4.21.0206011115560.1999-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.21.0206011330540.14302-100000@cens.ioc.ee>

On Sat, 1 Jun 2002, Pearu Peterson wrote:

> Works also here but when trying to use it for an instance of a class A:
> 
>   m.add(boost::python::class_<A>("A").def_init(boost::python::args<>()));
>   m.setattr("a", make_ref(A()));
> 
> I get
> 
>   TypeError: no to_python (by-value) converter found for type
> 
> when importing the extension module.
> What I am missing here?

I was missing

  .def_init(boost::python::args<const A &>())

for the A wrapper that seems to create the required converter.

Regards,
	Pearu





From david.abrahams at rcn.com  Sat Jun  1 14:38:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 1 Jun 2002 08:38:10 -0400
Subject: [C++-sig] Small change to v2 overloading
Message-ID: <07c601c20969$3da254e0$6601a8c0@boostconsulting.com>

Just a heads-up: I am about to make a small change to the Boost.Python v2
overloading procedure. Since it's not documented yet anyway, this shouldn't
cause too much upheaval. The current behavior is to place new functions
added with .def() at the /end/ of the chain of overloads. I am going to
start placing them at the beginning, which will cause them to be preferred
in overload resolution.

This is needed to support binary operators, which must have a generalized
overload returning NotImplemented.

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 rwgk at yahoo.com  Sat Jun  1 14:58:04 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 1 Jun 2002 05:58:04 -0700 (PDT)
Subject: [C++-sig] register_boost_array_from_python
Message-ID: <20020601125804.78322.qmail@web20205.mail.yahoo.com>

> Very nice effort!

Thanks for the encouragement. Attached is the next version of the tiny
array converter, this time for boost::array<T,N> in case someone else
wants to play with it.

As shown, it does about 50000 conversions from tuples to boost::arrays
per second on our Linux PC without showing memory leaks. This includes
recovering from TypeErrors 20000 times (tuple too long; wrong element
type).

> You should use converter::callback_from_python<ElementType> instead of
> from_python<ElementType> to extract elements.

If I change #if 0 below to #if 1 I receive a segmentation fault after
a few successful passes. What am I doing wrong?

The following questions are not directly relevant to the code below,
but if you could answer them it would help foster my understanding.

> An rvalue (server side) converter must always register a function to signal
> convertibility; that's how overload resolution works. If conversion is
> going to fail after the convertible function returns true, it must be via
> an exception.

While playing around I tried throw_argument_error(). Then Python was
complaining about a "NULL result without error in PyObject_Call."
Of course, I was hoping that the overload resolution would catch
the exception and continue. Is that not an option anymore?

> > - I was hoping that
> >       data->convertible = storage;
> >   signals that the conversion was successful, and failed otherwise.
> 
> Not quite:
> data->convertible = 0 signals failure.
> data->convertible = storage signals that the result object was constructed
> in the converter, and must be destroyed

What is the behavior if data->convertible == 0? If I just set
data->convertible = 0 flow control still arrives in my wrapped
function, but accessing the passed value causes a segmentation fault.
Does that mean I absolutely have to throw an exception if something
goes wrong in construct()?

Thanks,
        Ralf

P.S.: I will now try to work this into a generic
array_from_python_list_or_tuple converter.


  template <typename ElementType, std::size_t N>
  struct register_boost_array_from_python
  {
    typedef boost::array<ElementType, N> array_type;

    register_boost_array_from_python()
    {
      boost::python::converter::registry::insert(
        &convertible,
        &construct,
        boost::python::type_id<array_type>());
    }

    static void* convertible(PyObject* obj)
    {
      using namespace boost::python;
      tuple t = list_or_tuple_as_tuple(obj);
      if (t.size() != N) return 0;
      for(std::size_t i=0;i<t.size();i++) {
        from_python<ElementType const&> from_py(t[i].get());
        if (!from_py.convertible()) return 0;
      }
      return obj;
    }

    static void construct(
      PyObject* obj, boost::python::converter::rvalue_stage1_data* data)
    {
      using namespace boost::python;
      tuple t = list_or_tuple_as_tuple(obj);
      //if (t.size() == 4) { data->convertible = 0; return; }
      void* storage = ((
        converter::rvalue_base_data<array_type>*)data)->storage.bytes;
      new (storage) array_type();
      data->convertible = storage;
      array_type& result = *((array_type*)storage);
      cctbx_assert(t.size() == result.size());
      for(std::size_t i=0;i<result.size();i++) {
#if 0
        result[i] = converter::callback_from_python<ElementType>()(t[i].get());
#else
        from_python<ElementType const&> from_py(t[i].get());
        result[i] = from_py(t[i].get());
#endif
      }
    }

    private:
      static boost::python::tuple list_or_tuple_as_tuple(PyObject* obj)
      {
        using namespace boost::python;
        tuple result;
        if      (PyList_Check(obj)) {
          result = tuple(ref(PyList_AsTuple(obj)));
        }
        else if (PyTuple_Check(obj)) {
          result = tuple(ref(obj, ref::increment_count));
        }
        return result;
      }
  };


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From achim.domma at syynx.de  Sat Jun  1 15:07:44 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 1 Jun 2002 15:07:44 +0200
Subject: [C++-sig] error C2904: 'from_python' : template-name already defined
In-Reply-To: <033601c20653$80f187c0$6401a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEFEDGAA.achim.domma@syynx.de>

Hi Dave,

> > Is there something wrong with this code? I have no idea where the error
> > comes from.
>
> The error comes from the fact that you're not #defining BOOST_PYTHON_V2
> You're not using bjam to build your extension module, are you?

I'm using bjam, but I made a mistake in the defintion of a subproject. After
merging everything in a single jam file it works now.

A simple version of the python version of ImageMagick is working now. I was
already able to convert (gif->jpeg), resize and rotate images. There is
still some work to do, but I'm quite confident now. Thanks again for your
support!

greetings
Achim






From david.abrahams at rcn.com  Sat Jun  1 17:40:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 1 Jun 2002 11:40:55 -0400
Subject: [C++-sig] register_boost_array_from_python
References: <20020601125804.78322.qmail@web20205.mail.yahoo.com>
Message-ID: <085301c20982$b8ee0400$6601a8c0@boostconsulting.com>

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


> > Very nice effort!
>
> Thanks for the encouragement. Attached is the next version of the tiny
> array converter, this time for boost::array<T,N> in case someone else
> wants to play with it.
>
> As shown, it does about 50000 conversions from tuples to boost::arrays
> per second on our Linux PC without showing memory leaks. This includes
> recovering from TypeErrors 20000 times (tuple too long; wrong element
> type).
>
> > You should use converter::callback_from_python<ElementType> instead of
> > from_python<ElementType> to extract elements.
>
> If I change #if 0 below to #if 1 I receive a segmentation fault after
> a few successful passes. What am I doing wrong?

callback_from_python takes possession of its argument just like reference<>
does. It looks like you're dropping a reference in the transfer from the
tuple.

> The following questions are not directly relevant to the code below,
> but if you could answer them it would help foster my understanding.
>
> > An rvalue (server side) converter must always register a function to
signal
> > convertibility; that's how overload resolution works. If conversion is
> > going to fail after the convertible function returns true, it must be
via
> > an exception.
>
> While playing around I tried throw_argument_error(). Then Python was
> complaining about a "NULL result without error in PyObject_Call."
> Of course, I was hoping that the overload resolution would catch
> the exception and continue. Is that not an option anymore?

No, it's not. I think that's strictly a v1 idiom. We could consider
reinstating it as an option, but I don't think it would play well with the
more-sophisticated mechanism for overload resolution that I have planned.

> > Not quite:
> > data->convertible = 0 signals failure.
> > data->convertible = storage signals that the result object was
constructed
> > in the converter, and must be destroyed
>
> What is the behavior if data->convertible == 0? If I just set
> data->convertible = 0 flow control still arrives in my wrapped
> function, but accessing the passed value causes a segmentation fault.

Well, yes. data->convertible is set initially to the result of your
convertible() function. If that returns 0, the function isn't considered a
candidate for overload resolution and the convert function is never called.
As I said earlier, once the convert function is called, the only way to
signal failure is with an exception.

> Does that mean I absolutely have to throw an exception if something
> goes wrong in construct()?

Yes.

> Thanks,
>         Ralf
>
> P.S.: I will now try to work this into a generic
> array_from_python_list_or_tuple converter.

How about a STL-container_from_something-which-supports-iter() converter?
That's what people really need.

-Dave





From rwgk at yahoo.com  Sat Jun  1 18:35:03 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 1 Jun 2002 09:35:03 -0700 (PDT)
Subject: [C++-sig] register_boost_array_from_python
In-Reply-To: <085301c20982$b8ee0400$6601a8c0@boostconsulting.com>
Message-ID: <20020601163503.34624.qmail@web20204.mail.yahoo.com>

> callback_from_python takes possession of its argument just like reference<>
> does. It looks like you're dropping a reference in the transfer from the
> tuple.

callback_from_python does not accept increment_count like reference<>
does. Are you suggesting that I use Py_INCREF directly?

> No, it's not. I think that's strictly a v1 idiom. We could consider
> reinstating it as an option, but I don't think it would play well with the
> more-sophisticated mechanism for overload resolution that I have planned.

I am happy with your approach.

> Well, yes. data->convertible is set initially to the result of your
> convertible() function. If that returns 0, the function isn't considered a
> candidate for overload resolution and the convert function is never called.
> As I said earlier, once the convert function is called, the only way to
> signal failure is with an exception.

Understood.

> How about a STL-container_from_something-which-supports-iter() converter?
> That's what people really need.

Sounds great. As it stands (new code below) I am iterating over the
sequence twice: first in convertible() and then again in construct().
Do all Python iterators support this?

Hm, if data->convertible is not 0, will construct() be called without
further preconditions? If so, I could manage my own memory where I
store the result of iterating over the input sequence. Can I then
simply assign ownership in construct() (to avoid a copy)?
Or, would it make sense to add, say, rvalue_stage0_data* to the
signature of convertible()?

About the code below: there are now three array adaptors that I have
stress-tested (so far Linux/gcc only) with boost::array, std::vector and
the "small" type of my array family which is similar to the
"fixed_capacity_vector" proposed a while ago by Synge Todo.
Example usage:

  bpl_utils::register_array_from_python_list_or_tuple<
    boost::array<double, 3>,
    bpl_utils::fixed_size_array_registration_adaptor>();

  bpl_utils::register_array_from_python_list_or_tuple<
    std::vector<double>,
    bpl_utils::variable_size_array_registration_adaptor>();

  bpl_utils::register_array_from_python_list_or_tuple<
    af::small<double, 6>,
    bpl_utils::fixed_capacity_array_registration_adaptor>();

If you are interested I'd be happy to contribute this +
improvements/fixes that you might suggest + documentation to the core
library.

Ralf


  struct fixed_size_array_registration_adaptor
  {
    template <typename ArrayType>
    static bool check_size(boost::python::type<ArrayType>, std::size_t sz)
    {
      return ArrayType::size() == sz;
    }

    template <typename ArrayType>
    static void reserve(ArrayType& a, std::size_t sz)
    {
      assert(check_size(a, sz));
    }

    template <typename ArrayType, typename ValueType>
    static void set_value(ArrayType& a, std::size_t i, ValueType const& v)
    {
      a[i] = v;
    }
  };

  struct variable_size_array_registration_adaptor
  {
    template <typename ArrayType>
    static bool check_size(boost::python::type<ArrayType>, std::size_t sz)
    {
      return true;
    }

    template <typename ArrayType>
    static void reserve(ArrayType& a, std::size_t sz)
    {
      a.reserve(sz);
    }

    template <typename ArrayType, typename ValueType>
    static void set_value(ArrayType& a, std::size_t i, ValueType const& v)
    {
      assert(a.size() == i);
      a.push_back(v);
    }
  };

  struct fixed_capacity_array_registration_adaptor
    : variable_size_array_registration_adaptor
  {
    template <typename ArrayType>
    static bool check_size(boost::python::type<ArrayType>, std::size_t sz)
    {
      return ArrayType::max_size() >= sz;
    }
  };

  template <typename ArrayType, typename ArrayAdaptor>
  struct register_array_from_python_list_or_tuple
  {
    typedef typename ArrayType::value_type array_element_type;

    register_array_from_python_list_or_tuple()
    {
      boost::python::converter::registry::insert(
        &convertible,
        &construct,
        boost::python::type_id<ArrayType>());
    }

    static void* convertible(PyObject* obj)
    {
      using namespace boost::python;
      tuple t = list_or_tuple_as_tuple(obj);
      if (!ArrayAdaptor::check_size(type<ArrayType>(), t.size())) return 0;
      for(std::size_t i=0;i<t.size();i++) {
        from_python<array_element_type const&> from_py(t[i].get());
        if (!from_py.convertible()) return 0;
      }
      return obj;
    }

    static void construct(
      PyObject* obj, boost::python::converter::rvalue_stage1_data* data)
    {
      using namespace boost::python;
      tuple t = list_or_tuple_as_tuple(obj);
      void* storage = ((
        converter::rvalue_base_data<ArrayType>*)data)->storage.bytes;
      new (storage) ArrayType();
      data->convertible = storage;
      ArrayType& result = *((ArrayType*)storage);
      ArrayAdaptor::reserve(result, t.size());
      for(std::size_t i=0;i<t.size();i++) {
#if 0
        result[i] = converter::callback_from_python<
          array_element_type>()(t[i].get());
#else
        from_python<array_element_type const&> from_py(t[i].get());
        ArrayAdaptor::set_value(result, i, from_py(t[i].get()));
#endif
      }
    }

    private:
      static boost::python::tuple list_or_tuple_as_tuple(PyObject* obj)
      {
        using namespace boost::python;
        tuple result;
        if      (PyList_Check(obj)) {
          result = tuple(ref(PyList_AsTuple(obj)));
        }
        else if (PyTuple_Check(obj)) {
          result = tuple(ref(obj, ref::increment_count));
        }
        return result;
      }
  };


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From pearu at cens.ioc.ee  Sat Jun  1 22:19:49 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 1 Jun 2002 23:19:49 +0300 (EEST)
Subject: [C++-sig] V2: python file object as an ostream argument
Message-ID: <Pine.LNX.4.21.0206012255160.22046-100000@cens.ioc.ee>

Hi,

Say, a class A has a method
  
  void A::output(std::ostream & os);

that sends lots of junk to `os'. My question is how to wrap such a method
with BPL V2 that would accept a Python file instance as an argument?
 
For simplicity, let's assume that the file is already opened in Python
side. Now one can write the following wrapper for this method but I could
not figure out how to make the connection between 
  FILE* f;
and 
  std::ostream os;
when using gcc 3.x compiler.

  void A_output(const A & a, PyObject* fp) {
    if (!PyFile_Check(fp)) {
      ...
      throw boost::python::error_already_set();
    }
    FILE* f = PyFile_AsFile(fp);
    // ??? Need something like std::ostream os(f); here. 
    a.output(os);
  }

I tried google but there I got very contradictionary results. E.g. in
gcc-2.95.3 there is ostdiostream to make this connection but in gcc-3.x
ostdiostream does not exist anymore.

Any hints how to solve this issue are very much appeciated.

Pearu





From david.abrahams at rcn.com  Sat Jun  1 22:20:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 1 Jun 2002 16:20:20 -0400
Subject: [C++-sig] register_boost_array_from_python
References: <20020601163503.34624.qmail@web20204.mail.yahoo.com>
Message-ID: <087b01c209a9$df09f550$6601a8c0@boostconsulting.com>

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


> > callback_from_python takes possession of its argument just like
reference<>
> > does. It looks like you're dropping a reference in the transfer from
the
> > tuple.
>
> callback_from_python does not accept increment_count like reference<>
> does. Are you suggesting that I use Py_INCREF directly?

That's one solution.

I think you can see now why I didn't just slap the name "from_python<>" on
callback_from_python and expose it to users...

> > How about a STL-container_from_something-which-supports-iter()
converter?
> > That's what people really need.
>
> Sounds great. As it stands (new code below) I am iterating over the
> sequence twice: first in convertible() and then again in construct().
> Do all Python iterators support this?

I don't think so; an iterator could work like a C++ input iterator, and
there's no way to introspect about it to find out which category you
have...

...well, that's not strictly true. If the type supports __getitem__ then
you're probably getting a random-access iterator.

> Hm, if data->convertible is not 0, will construct() be called without
> further preconditions?

The conversion function will only be called if /all/ the converters needed
to handle the function's arguments report non-zero from their convertible()
function... i.e. only if overload resolution succeeds.

> If so, I could manage my own memory where I
> store the result of iterating over the input sequence.

I'm not sure that I am providing a way for you to manage any extra memory.
The only destructor actions in the rvalue_from_python converter are in
converter::from_python_data::~from_python_data().

> Can I then
> simply assign ownership in construct() (to avoid a copy)?

I don't understand what you mean here, sorry.

> Or, would it make sense to add, say, rvalue_stage0_data* to the
> signature of convertible()?

We could extend rvalue_data to contain an additional pointer to an abstract
base class which can be used to store extra dynamically-allocated data
during conversion, and which is deleted in the destructor. However, that
would impose some overhead in each wrapped function to delete this extra
data for each argument. I'm not sure that it's worth it, since the extra
data is seldom needed. I want to keep the automatically-generated function
wrappers as lean-and-mean as possible.

However, I'm not dead-set against it. If you want to try this tack, I'd
like to see some measurements (of the optimized result) showing that the
time/space overhead is negligible when the facility isn't actually used.

> About the code below: there are now three array adaptors that I have
> stress-tested (so far Linux/gcc only) with boost::array, std::vector and
> the "small" type of my array family which is similar to the
> "fixed_capacity_vector" proposed a while ago by Synge Todo.
> Example usage:
>
>   bpl_utils::register_array_from_python_list_or_tuple<
>     boost::array<double, 3>,
>     bpl_utils::fixed_size_array_registration_adaptor>();
>
>   bpl_utils::register_array_from_python_list_or_tuple<
>     std::vector<double>,
>     bpl_utils::variable_size_array_registration_adaptor>();
>
>   bpl_utils::register_array_from_python_list_or_tuple<
>     af::small<double, 6>,
>     bpl_utils::fixed_capacity_array_registration_adaptor>();

Nice! those last template arguments are more like Policies than Adaptors,
though. I like the general approach.

> If you are interested I'd be happy to contribute this +
> improvements/fixes that you might suggest + documentation to the core
> library.

Of course I am!

My suggestions:

1. Make it more generic: the names shouldn't mention arrays, since it
should apply to std::list also. Either Container or Sequence might be the
right name. Use the presence of __iter__ and/or __getitem__ to determine
elegibility of the actual argument.

2. The one for variable-sized containers should construct the thing
in-place using a C++ iterator range when used with a conforming compiler.

3. Efficiency: don't build an intermediate tuple when given a list; Just
use the Python iterator

4. Consider whether it's possible to factor out any part of this code into
bpl.dll, to avoid instantiating it in every extension module.

Nice work,

Dave






From david.abrahams at rcn.com  Sat Jun  1 22:29:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 1 Jun 2002 16:29:55 -0400
Subject: [C++-sig] V2: python file object as an ostream argument
References: <Pine.LNX.4.21.0206012255160.22046-100000@cens.ioc.ee>
Message-ID: <089201c209ab$460c1610$6601a8c0@boostconsulting.com>

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

>
> I tried google but there I got very contradictionary results. E.g. in
> gcc-2.95.3 there is ostdiostream to make this connection but in gcc-3.x
> ostdiostream does not exist anymore.
>
> Any hints how to solve this issue are very much appeciated.

This question really has nothing to do with Python; you just want to know
how to make an ostream given a FILE*. It's unfortunate that C++ doesn't
have such a facility built-in. I think the right way to do this is to build
a streambuf around the FILE*. I believe "The C++ Standard Library", by
Nicolai Josuttis, contains the code for such a thing. You might also look
at newsgroup postings by Dietmar Kuehl.

Good Luck,
Dave






From david.abrahams at rcn.com  Sat Jun  1 22:56:00 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 1 Jun 2002 16:56:00 -0400
Subject: [C++-sig] Re: [boost] mirroring class instances between c++ and python
References: <000001c2099e$ba744520$0b00010a@tunguska>
Message-ID: <08a401c209ae$bd09a2c0$6601a8c0@boostconsulting.com>

David,

Please post followups to the C++-sig (c++-sig at python.org).

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


> Hi,
>
> I am hoping someone has managed to get this problem working before and
> can give me some pointers as to how to accomplish the task.
>
> What I am trying to do is have a class in C++ that is mirrored in
> python. This means that each instance of a class that is created will
> have a python class created along with it and that python instance can
> call into the c++ instance and vice versa.


That's the normal case for classes which have overridable virtual functions
as described at http://www.boost.org/libs/python/doc/overriding.html.

Why not just use class_builder<CTest,CTest>?

Every constructor you expose must have a hidden initial PyObject* parameter
not described in the parameters to constructor<...>, so:

struct CTest
{
    CTest(PyObject* self, Arg1 a1, Arg2 a2...)
        : m_self(self)
          ...
    {
        ...
    }

    ...

    PyObject* m_self;
};

class_builder<CTest,CTest> test(module,"PTest");
test.def(constructor<Arg1,Arg2...>())


HTH,
Dave







From pearu at cens.ioc.ee  Sun Jun  2 00:18:43 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 2 Jun 2002 01:18:43 +0300 (EEST)
Subject: [C++-sig] V2: python file object as an ostream argument
In-Reply-To: <089201c209ab$460c1610$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0206020105170.22046-100000@cens.ioc.ee>

On Sat, 1 Jun 2002, David Abrahams wrote:

> From: "Pearu Peterson" <pearu at cens.ioc.ee>
> 
> > I tried google but there I got very contradictionary results. E.g. in
> > gcc-2.95.3 there is ostdiostream to make this connection but in gcc-3.x
> > ostdiostream does not exist anymore.
> >
> > Any hints how to solve this issue are very much appeciated.
> 
> This question really has nothing to do with Python; you just want to know
> how to make an ostream given a FILE*. It's unfortunate that C++ doesn't
> have such a facility built-in. I think the right way to do this is to build
> a streambuf around the FILE*. I believe "The C++ Standard Library", by
> Nicolai Josuttis, contains the code for such a thing. You might also look
> at newsgroup postings by Dietmar Kuehl.

Thanks for the references.

Following (a rather buggy) example in

http://groups.google.com/groups?hl=en&lr=&safe=off&selm=86mtsc%248sh%241%40nnrp1.deja.com&rnum=4

I solved this issue as follows:
/////////////////////////////
#include <streambuf>

  class std_obuf: public std::streambuf {
  public:
    std_obuf(std::FILE* file): m_file(file) {}
  protected:
    std::streambuf::int_type overflow(std::streambuf::int_type c) {
      return std::fputc(c, m_file) ==EOF? std::streambuf::traits_type::eof(): c;
    }
    FILE* m_file;
  };

  void A_output(const A & a, PyObject* fp) {
    if (!PyFile_Check(fp)) {
      ...
      throw boost::python::error_already_set();
    }
    std::FILE* f = PyFile_AsFile(fp);
    std_obuf buf(f);
    std::ostream os(&buf);
    a.output(os);
  }
///////////////////////////////

And sorry being OT,
	Pearu





From david.abrahams at rcn.com  Sun Jun  2 00:44:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 1 Jun 2002 18:44:29 -0400
Subject: [C++-sig] V2: python file object as an ostream argument
References: <Pine.LNX.4.21.0206020105170.22046-100000@cens.ioc.ee>
Message-ID: <096d01c209be$aee0f5d0$6601a8c0@boostconsulting.com>

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

> Thanks for the references.
>
> Following (a rather buggy) example in
>
>
http://groups.google.com/groups?hl=en&lr=&safe=off&selm=86mtsc%248sh%241%40
nnrp1.deja.com&rnum=4
>
> I solved this issue as follows:
> /////////////////////////////
> #include <streambuf>
>
>   class std_obuf: public std::streambuf {
>   public:
>     std_obuf(std::FILE* file): m_file(file) {}
>   protected:
>     std::streambuf::int_type overflow(std::streambuf::int_type c) {
>       return std::fputc(c, m_file) ==EOF?
std::streambuf::traits_type::eof(): c;
>     }
>     FILE* m_file;
>   };
>
>   void A_output(const A & a, PyObject* fp) {
>     if (!PyFile_Check(fp)) {
>       ...
>       throw boost::python::error_already_set();
>     }
>     std::FILE* f = PyFile_AsFile(fp);
>     std_obuf buf(f);
>     std::ostream os(&buf);
>     a.output(os);
>   }
> ///////////////////////////////

That's great! Are you planning to submit this, enchanced to handle input as
well, to boost? Or would you please bug Dietmar about it until he submits
something as promised in his post from more than 2 years ago?

-Dave






From firestar at thenorth.org  Sun Jun  2 04:03:37 2002
From: firestar at thenorth.org (David GD Wilson)
Date: Sun, 2 Jun 2002 03:03:37 +0100
Subject: [C++-sig] RE: [boost] mirroring class instances between c++ and python
In-Reply-To: <08a401c209ae$bd09a2c0$6601a8c0@boostconsulting.com>
Message-ID: <000001c209d9$b55142b0$0b00010a@tunguska>

Dave,

Thanks for the response. I have looked into the method you have
suggested below. However unsure how I can create a CTest instance within
my c++ code? I can see how it will work if I create the CTest/PTest from
inside python, but I need to create the CTest/PTest from c++.

Is this going to be possible with the method you have suggested?

Thanks for any help.
David

> -----Original Message-----
> From: David Abrahams [mailto:david.abrahams at rcn.com]
> Sent: 01 June 2002 21:56
> To: "David GD Wilson"; pysig; boost
> Subject: Re: [boost] mirroring class instances between c++ and python
> 
> David,
> 
> Please post followups to the C++-sig (c++-sig at python.org).
> 
> ----- Original Message -----
> From: "David GD Wilson" <firestar at thenorth.org>
> 
> 
> > Hi,
> >
> > I am hoping someone has managed to get this problem working before
and
> > can give me some pointers as to how to accomplish the task.
> >
> > What I am trying to do is have a class in C++ that is mirrored in
> > python. This means that each instance of a class that is created
will
> > have a python class created along with it and that python instance
can
> > call into the c++ instance and vice versa.
> 
> 
> That's the normal case for classes which have overridable virtual
> functions
> as described at http://www.boost.org/libs/python/doc/overriding.html.
> 
> Why not just use class_builder<CTest,CTest>?
> 
> Every constructor you expose must have a hidden initial PyObject*
> parameter
> not described in the parameters to constructor<...>, so:
> 
> struct CTest
> {
>     CTest(PyObject* self, Arg1 a1, Arg2 a2...)
>         : m_self(self)
>           ...
>     {
>         ...
>     }
> 
>     ...
> 
>     PyObject* m_self;
> };
> 
> class_builder<CTest,CTest> test(module,"PTest");
> test.def(constructor<Arg1,Arg2...>())
> 
> 
> HTH,
> Dave
> 
> 






From david.abrahams at rcn.com  Sun Jun  2 07:09:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 2 Jun 2002 01:09:55 -0400
Subject: [C++-sig] RE: [boost] mirroring class instances between c++ and python
References: <000001c209d9$b55142b0$0b00010a@tunguska>
Message-ID: <0a6e01c209f3$ce71e9b0$6601a8c0@boostconsulting.com>

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


> Dave,
>
> Thanks for the response. I have looked into the method you have
> suggested below. However unsure how I can create a CTest instance within
> my c++ code? I can see how it will work if I create the CTest/PTest from
> inside python, but I need to create the CTest/PTest from c++.
>
> Is this going to be possible with the method you have suggested?

Sure. Just use

    class_builder<CTest,CTest> c_test;
    c_test.def_init(constructor<Arg1,Arg2...>());
    ...
    // Get the class object
    PyTypeObject* PTest = c_test.get_extension_class();
    ...

    // call the Python class to make a new instance.
    python::ref x = python::callback<python::ref>::call((PyObject*)PTest,
a1, a2...)

where a1, a2... are the constructor arguments.

Now x manages a Python PTest object which holds a CTest instance.

-Dave






From pearu at cens.ioc.ee  Sun Jun  2 11:02:53 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 2 Jun 2002 12:02:53 +0300 (EEST)
Subject: [C++-sig] V2: python file object as an ostream argument
In-Reply-To: <096d01c209be$aee0f5d0$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0206021146320.22046-100000@cens.ioc.ee>


On Sat, 1 Jun 2002, David Abrahams wrote:

<snip>

> That's great! Are you planning to submit this, enchanced to handle input as
> well, to boost? Or would you please bug Dietmar about it until he submits
> something as promised in his post from more than 2 years ago?

No. I tried to include also the input but I could not find out what is
fpeekc in gcc-3.x as this compiler does not have it in std. 

Also note that I am far from being a C++ expert. From reading google,
the real C++ experts seem not solved this issue for many years, or they
just don't consider it to be an issue at all but rather an OT for C++, or
I am just confused...

Regards,
	Pearu





From david.abrahams at rcn.com  Sun Jun  2 20:57:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 2 Jun 2002 14:57:51 -0400
Subject: [C++-sig] Boost.Python v2: automatic operator wrapping support
Message-ID: <0bf601c20a67$6723bda0$6601a8c0@boostconsulting.com>

I have implemented automatic wrapping of C++ operators for Boost.Python v2
in the current CVS state. Documentation to follow.

Quick summary:

#include <boost/python/operators.hpp>

In a class_<> definition, use the special object boost::python::self to
expose C++ operators:

    .def(self < self)
    .def(self == self)
    .def(self += self)

Heterogeneous operators can be defined as follows:

    .def(self * int())
    .def(int() * self)
or

    .def(self * 1)
    .def(1 * self)

or, if the other type is expensive to create,

    .def(self * other<my_heavy_type>())
    .def(other<my_heavy_type>() * self)

Support for Python's __int__ __float__ and __complex__ are provided:

    .def(int_(self))    // uses (long)x
    .def(float_(self))  // uses (double)x
    .def(complex_(self) // uses std::complex<double>(x)

Support for __str__ is provided:

    .def(str(self)) // uses lexical_cast<std::string>(x)

Support for __pow__(x,y) is provided:

    .def(pow(self,int())

Enjoy,
Dave

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





From achim.domma at syynx.de  Sun Jun  2 23:45:59 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 2 Jun 2002 23:45:59 +0200
Subject: [C++-sig] implicitly_convertible / virtual base class
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEFMDGAA.achim.domma@syynx.de>

Hi Dave,

I have a problem with following class combination:

The class Image has a member function 'draw' which expects a 'const
Drawable&'. The class Drawable has a ctor which accepts a 'const
DrawableBase&'. DrawableBase is a virtual base class, one derived example is
'DrawableStrokeColor'. In C++ one could write:

image_instance.draw(DrawableStrokeColor(some_data));

To enable this from python I tried the following:

- First I specified 'DrawableBase' as base class via the second parameter of
the class definition (class_<...,bases<DrawableBase> >). If I import such a
class I get an error, because there is no python wrapper for DrawableBase.
Trying to define such a wrapper fails because DrawableBase is virtual.

- I tried implicitly_convertible<DrawableStrokeColor,Drawable>() which does
not seems to change anything from my point of view. The error is:
TypeError: bad argument type for built-in operation

Could you put me to the right direction, please ?

Achim






From david.abrahams at rcn.com  Mon Jun  3 00:49:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 2 Jun 2002 18:49:34 -0400
Subject: [C++-sig] implicitly_convertible / virtual base class
References: <FCEMIEFBFOIDAOJDEPIAMEFMDGAA.achim.domma@syynx.de>
Message-ID: <0c3001c20a87$c6adb210$6601a8c0@boostconsulting.com>

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


> Hi Dave,
>
> I have a problem with following class combination:
>
> The class Image has a member function 'draw' which expects a 'const
> Drawable&'. The class Drawable has a ctor which accepts a 'const
> DrawableBase&'. DrawableBase is a virtual base class, one derived example
is
> 'DrawableStrokeColor'. In C++ one could write:
>
> image_instance.draw(DrawableStrokeColor(some_data));
>
> To enable this from python I tried the following:
>
> - First I specified 'DrawableBase' as base class via the second parameter
of
> the class definition (class_<...,bases<DrawableBase> >). If I import such
a
> class I get an error, because there is no python wrapper for
DrawableBase.
> Trying to define such a wrapper fails because DrawableBase is virtual.

?? A class can not be virtual. ??
Only a base class relationship can be virtual.
class<DrawableBase> can not fail simply due to its use as a virtual base
class of some other class.

Do you mean that DrawableBase is abstract?
If so, use class_<DrawableBase,boost::noncopyable>
Abstract classes cannot be copied.

-Dave






From achim.domma at syynx.de  Mon Jun  3 19:01:10 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Mon, 3 Jun 2002 19:01:10 +0200
Subject: [C++-sig] implicitly_convertible / virtual base class
In-Reply-To: <0c3001c20a87$c6adb210$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAAEGFDGAA.achim.domma@syynx.de>

> Do you mean that DrawableBase is abstract?
> If so, use class_<DrawableBase,boost::noncopyable>
> Abstract classes cannot be copied.

Yes, that was what I meant. It does not work if you define a ctor for such a
class, but after removing the ctor and using noncopyable it works now.
Thanks.

But my problem was not solved. I still have the following situation:
DrawableStrokeColor is derived from DrawableBase. Drawable has a ctor which
accepts 'const DrawableBase&'. As far as I understand this means, that
DrawableBase is implicit convertible to Drawable. Therefor I added the
following statement:

implicitly_convertible<DrawableStrokeColor,Drawable>();

The function I want to call is declared as:

Image::draw(const Drawable&)

If I try to use this function from python like:

img.draw(DrawableStrokeColor('red'))

I get the following error:

Traceback (most recent call last):
  File "E:\cvsroot\boost\libs\python\ImageMagick\test\magick.py", line 12,
in ?
    img.draw(DrawableStrokeColor('red'))
TypeError: bad argument type for built-in operation

Is the problem that draw expects a 'Drawable&' and no 'Drawable'?

Achim






From david.abrahams at rcn.com  Mon Jun  3 19:08:15 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 3 Jun 2002 13:08:15 -0400
Subject: [C++-sig] implicitly_convertible / virtual base class
References: <FCEMIEFBFOIDAOJDEPIAAEGFDGAA.achim.domma@syynx.de>
Message-ID: <0ea101c20b21$70e5f460$6601a8c0@boostconsulting.com>

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


> > Do you mean that DrawableBase is abstract?
> > If so, use class_<DrawableBase,boost::noncopyable>
> > Abstract classes cannot be copied.
>
> Yes, that was what I meant. It does not work if you define a ctor for
such a
> class, but after removing the ctor and using noncopyable it works now.
> Thanks.
>
> But my problem was not solved. I still have the following situation:
> DrawableStrokeColor is derived from DrawableBase. Drawable has a ctor
which
> accepts 'const DrawableBase&'. As far as I understand this means, that
> DrawableBase is implicit convertible to Drawable.

As long as the constructor is not marked "explicit", then yes.

> Therefor I added the
> following statement:
>
> implicitly_convertible<DrawableStrokeColor,Drawable>();
>
> The function I want to call is declared as:
>
> Image::draw(const Drawable&)
>
> If I try to use this function from python like:
>
> img.draw(DrawableStrokeColor('red'))
>
> I get the following error:
>
> Traceback (most recent call last):
>   File "E:\cvsroot\boost\libs\python\ImageMagick\test\magick.py", line
12,
> in ?
>     img.draw(DrawableStrokeColor('red'))
> TypeError: bad argument type for built-in operation
>
> Is the problem that draw expects a 'Drawable&' and no 'Drawable'?
                                                     ^^
I don't understand the question. Do you mean "not"   ^^ here?

If it actually expects Drawable&, then that is your problem. If it expects
const Drawable& as you wrote above, that's not your problem. Implicit
conversions produce rvalues, and rvalues cannot bind to non-const
references.

-Dave






From okuda1 at llnl.gov  Mon Jun  3 20:21:52 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Mon, 03 Jun 2002 11:21:52 -0700
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com> <3CF7CFFD.F2297EEF@llnl.gov> <065101c208df$c04805f0$6601a8c0@boostconsulting.com>
Message-ID: <3CFBB3C0.7049551A@llnl.gov>

<snip> 

And now I got another problem. At the end is a simple source code that
works ok... str1() is working ok, but if static is added, I get
TypeError message *UNLESS* you use str2(Tag*) instead of str2() and
similarly for str3 which issue TypeError. Could you please educate me
why "Tag*" is needed here, even though there is no need if you run in
c++ code... (I found the example code in m1.cpp struct B which uses
name(B*), and I followed this example and it worked... I dont understand
what is going on, since it seems to me that I have to do trial and error
differently many times until it succeeds...).

Thank you
Chuzo


>>> from Test1a import *
>>> t=Tag()
>>> t.str1()
'string return successful'
>>> t.str2()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
>>> t.str3()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation


-------------- source ----------------
#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/python/return_internal_reference.hpp>
#include <boost/python/copy_const_reference.hpp>
#include <boost/python/copy_non_const_reference.hpp>
#include <boost/python/return_value_policy.hpp>
#include <string>

class Tag {
public:
   Tag():mName("") {}
   ~Tag() {}
   std::string str1() {return "string return successful";}
   static std::string str2(Tag*) {return "problem here...";}
   static char const* str3(Tag*) {return "work???";}
private:
   std::string mName;
};

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

   class_<Tag> mod("Tag");
   mod
      .def_init()
      .def("str1", &Tag::str1)
      .def("str2", &Tag::str2)
      .def("str3", &Tag::str3)
      ;

   module("Test1a").add(mod);
-------------------------------------------




From okuda1 at llnl.gov  Mon Jun  3 20:29:53 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Mon, 03 Jun 2002 11:29:53 -0700
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com> <3CF7CFFD.F2297EEF@llnl.gov> <065101c208df$c04805f0$6601a8c0@boostconsulting.com> <3CFBB3C0.7049551A@llnl.gov>
Message-ID: <3CFBB5A1.F389235A@llnl.gov>

Sorry, I forgot to add one more question.
Is there a way to write BPL code that do not have to add "Tag*" to the
argument for "static std::string str2()" in the source? I do not want to
alter original source codes many people wrote.
Thank you...
Chuzo


chuzo okuda wrote:
> 
> <snip>
> 
> And now I got another problem. At the end is a simple source code that
> works ok... str1() is working ok, but if static is added, I get
> TypeError message *UNLESS* you use str2(Tag*) instead of str2() and
> similarly for str3 which issue TypeError. Could you please educate me
> why "Tag*" is needed here, even though there is no need if you run in
> c++ code... (I found the example code in m1.cpp struct B which uses
> name(B*), and I followed this example and it worked... I dont understand
> what is going on, since it seems to me that I have to do trial and error
> differently many times until it succeeds...).
> 
> Thank you
> Chuzo
> 
> >>> from Test1a import *
> >>> t=Tag()
> >>> t.str1()
> 'string return successful'
> >>> t.str2()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
> >>> t.str3()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
> 
> -------------- source ----------------
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/return_internal_reference.hpp>
> #include <boost/python/copy_const_reference.hpp>
> #include <boost/python/copy_non_const_reference.hpp>
> #include <boost/python/return_value_policy.hpp>
> #include <string>
> 
> class Tag {
> public:
>    Tag():mName("") {}
>    ~Tag() {}
>    std::string str1() {return "string return successful";}
>    static std::string str2(Tag*) {return "problem here...";}
>    static char const* str3(Tag*) {return "work???";}
> private:
>    std::string mName;
> };
> 
> BOOST_PYTHON_MODULE_INIT(Test1a)
> {
>    using namespace boost::python;
> 
>    class_<Tag> mod("Tag");
>    mod
>       .def_init()
>       .def("str1", &Tag::str1)
>       .def("str2", &Tag::str2)
>       .def("str3", &Tag::str3)
>       ;
> 
>    module("Test1a").add(mod);
> -------------------------------------------
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From david.abrahams at rcn.com  Mon Jun  3 20:26:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 3 Jun 2002 14:26:05 -0400
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com> <3CF7CFFD.F2297EEF@llnl.gov> <065101c208df$c04805f0$6601a8c0@boostconsulting.com> <3CFBB3C0.7049551A@llnl.gov>
Message-ID: <0f2401c20b2c$8b93eff0$6601a8c0@boostconsulting.com>

static member functions are just like free functions. They have no implicit
"this" pointer parameter, so if you are going to use them like member
functions you need to supply one yourself.

HTH,
-Dave

----- Original Message -----
From: "chuzo okuda" <okuda1 at llnl.gov>


> <snip>
>
> And now I got another problem. At the end is a simple source code that
> works ok... str1() is working ok, but if static is added, I get
> TypeError message *UNLESS* you use str2(Tag*) instead of str2() and
> similarly for str3 which issue TypeError. Could you please educate me
> why "Tag*" is needed here, even though there is no need if you run in
> c++ code... (I found the example code in m1.cpp struct B which uses
> name(B*), and I followed this example and it worked... I dont understand
> what is going on, since it seems to me that I have to do trial and error
> differently many times until it succeeds...).
>
> Thank you
> Chuzo
>
>
> >>> from Test1a import *
> >>> t=Tag()
> >>> t.str1()
> 'string return successful'
> >>> t.str2()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
> >>> t.str3()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
>
>
> -------------- source ----------------
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/return_internal_reference.hpp>
> #include <boost/python/copy_const_reference.hpp>
> #include <boost/python/copy_non_const_reference.hpp>
> #include <boost/python/return_value_policy.hpp>
> #include <string>
>
> class Tag {
> public:
>    Tag():mName("") {}
>    ~Tag() {}
>    std::string str1() {return "string return successful";}
>    static std::string str2(Tag*) {return "problem here...";}
>    static char const* str3(Tag*) {return "work???";}
> private:
>    std::string mName;
> };
>
> BOOST_PYTHON_MODULE_INIT(Test1a)
> {
>    using namespace boost::python;
>
>    class_<Tag> mod("Tag");
>    mod
>       .def_init()
>       .def("str1", &Tag::str1)
>       .def("str2", &Tag::str2)
>       .def("str3", &Tag::str3)
>       ;
>
>    module("Test1a").add(mod);
> -------------------------------------------
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Mon Jun  3 20:43:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 3 Jun 2002 14:43:30 -0400
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com> <3CF7CFFD.F2297EEF@llnl.gov> <065101c208df$c04805f0$6601a8c0@boostconsulting.com> <3CFBB3C0.7049551A@llnl.gov> <3CFBB5A1.F389235A@llnl.gov>
Message-ID: <0f3401c20b2e$8f122f50$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "chuzo okuda" <okuda1 at llnl.gov>


> Sorry, I forgot to add one more question.
> Is there a way to write BPL code that do not have to add "Tag*" to the
> argument for "static std::string str2()" in the source? I do not want to
> alter original source codes many people wrote.

You don't have to; static member functions can always be invoked from
Python as:

    Tag.str2()

mirroring the C++

    Tag::str2()

The fact that you can write

    tag_instance.str2()

in C++ is almost a quirky accident. If you want to be able to write that
from Python, your best bet is to write a "thin wrapper function", and pass
that to def():

std::string my_str2(Tag*) { return Tag::str2(); }

...

        .def("str2", &my_str2)


Eventually, we will have a way to define Python static functions so that
you can write both

    Tag.str2()
  and
    tag_instance.str2()

from Python.

HTH,
Dave






From okuda1 at llnl.gov  Mon Jun  3 21:12:27 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Mon, 03 Jun 2002 12:12:27 -0700
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com> <3CF7CFFD.F2297EEF@llnl.gov> <065101c208df$c04805f0$6601a8c0@boostconsulting.com> <3CFBB3C0.7049551A@llnl.gov> <3CFBB5A1.F389235A@llnl.gov> <0f3401c20b2e$8f122f50$6601a8c0@boostconsulting.com>
Message-ID: <3CFBBF9B.1C9DE3C1@llnl.gov>

Tag.str2() does not work, but thin_wrapper function worked fine (str4 is
the python function using my_str2 thin_wrapped function).

>>> t=Tag()
[8681 refs]
>>> t.str4()
'problem here...'
>>> Tag.str2()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unbound method Boost.Python.function object must be called
with Tag instance as first argument (got nothing instead)
>>> t.str2()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation

Chuzo



David Abrahams wrote:
> 
> ----- Original Message -----
> From: "chuzo okuda" <okuda1 at llnl.gov>
> 
> > Sorry, I forgot to add one more question.
> > Is there a way to write BPL code that do not have to add "Tag*" to the
> > argument for "static std::string str2()" in the source? I do not want to
> > alter original source codes many people wrote.
> 
> You don't have to; static member functions can always be invoked from
> Python as:
> 
>     Tag.str2()
> 
> mirroring the C++
> 
>     Tag::str2()
> 
> The fact that you can write
> 
>     tag_instance.str2()
> 
> in C++ is almost a quirky accident. If you want to be able to write that
> from Python, your best bet is to write a "thin wrapper function", and pass
> that to def():
> 
> std::string my_str2(Tag*) { return Tag::str2(); }
> 
> ...
> 
>         .def("str2", &my_str2)
> 
> Eventually, we will have a way to define Python static functions so that
> you can write both
> 
>     Tag.str2()
>   and
>     tag_instance.str2()
> 
> from Python.
> 
> HTH,
> Dave
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From achim.domma at syynx.de  Mon Jun  3 21:38:56 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Mon, 3 Jun 2002 21:38:56 +0200
Subject: [C++-sig] implicitly_convertible / virtual base class
In-Reply-To: <0ea101c20b21$70e5f460$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEGHDGAA.achim.domma@syynx.de>

> > TypeError: bad argument type for built-in operation
> >
> > Is the problem that draw expects a 'Drawable&' and no 'Drawable'?
>                                                      ^^
> I don't understand the question. Do you mean "not"   ^^ here?

yes I wanted to write 'not'

> If it actually expects Drawable&, then that is your problem. If it expects
> const Drawable& as you wrote above, that's not your problem. Implicit
> conversions produce rvalues, and rvalues cannot bind to non-const
> references.

I had to add another conversion I missed bevor, but now it works!!!
I have a lot of ctors with only one argument which should be available for
implicid conversion. Do I have to add a 'implicitly_convertible' for each
one? Wouldn't it make sense to have the possibility to specify at the
def_init function that a certain ctor should be used for implicit
conversion?

thanks again for your support,
Achim






From david.abrahams at rcn.com  Mon Jun  3 23:04:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 3 Jun 2002 17:04:42 -0400
Subject: [C++-sig] implicitly_convertible / virtual base class
References: <FCEMIEFBFOIDAOJDEPIAEEGHDGAA.achim.domma@syynx.de>
Message-ID: <104801c20b42$52997150$6601a8c0@boostconsulting.com>

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


> > > TypeError: bad argument type for built-in operation
> > >
> > > Is the problem that draw expects a 'Drawable&' and no 'Drawable'?
> >                                                      ^^
> > I don't understand the question. Do you mean "not"   ^^ here?
>
> yes I wanted to write 'not'
>
> > If it actually expects Drawable&, then that is your problem. If it
expects
> > const Drawable& as you wrote above, that's not your problem. Implicit
> > conversions produce rvalues, and rvalues cannot bind to non-const
> > references.
>
> I had to add another conversion I missed bevor, but now it works!!!
> I have a lot of ctors with only one argument which should be available
for
> implicid conversion. Do I have to add a 'implicitly_convertible' for each
> one?

Yeah.

> Wouldn't it make sense to have the possibility to specify at the
> def_init function that a certain ctor should be used for implicit
> conversion?

It might. In your case, it's not strictly equivalent unless you've declared

    class_<DrawableStrokeColor, bases<DrawableBase> >
                                ^^^^^^^^^^^^^^^^^^^

since the best we could do would be to generate
implicitly_convertible<DrawableBase,Drawable>() automatically.

So, I guess there is a question of interface. Should we generate implicit
conversions by default, like C++ (dangerously) does? We could provide a
member function:

    template <class T>
    def_init(explicit_<T>);

which defines a constructor without generating an implicit conversion.

Or, we could define

    template <class T>
    def_implicit(args<T>);

Hmmm....

Oh, BTW, patches to implement this would be welcome ;-)

-D





From achim.domma at syynx.de  Mon Jun  3 23:48:34 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Mon, 3 Jun 2002 23:48:34 +0200
Subject: [C++-sig] implicitly_convertible / virtual base class
In-Reply-To: <104801c20b42$52997150$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAAEGJDGAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams

> > Wouldn't it make sense to have the possibility to specify at the
> > def_init function that a certain ctor should be used for implicit
> > conversion?
>
> It might. In your case, it's not strictly equivalent unless
> you've declared
>
>     class_<DrawableStrokeColor, bases<DrawableBase> >
>                                 ^^^^^^^^^^^^^^^^^^^
>
> since the best we could do would be to generate
> implicitly_convertible<DrawableBase,Drawable>() automatically.

I realized this solution some minutes after sending the mail. First I
thought I would have to write an implicitly_convertible for each class,
derived from DrawableBase. But with 'bases<DrawableBase> defined and a
conversion from DrawableBase to Drawable it works fine now. This solves most
of my problems.

> Or, we could define
>
>     template <class T>
>     def_implicit(args<T>);

I would prefer this one. I have no problem writing down that the ctor should
be available for implicit conversion, but it would be much more intuitive to
do it directly on the class, than to specify it somewhere else via
implicitly_convertible.

> Oh, BTW, patches to implement this would be welcome ;-)

I'm developing in C++ for some years now, but I fear it's not good enough
for boost. Anyway, if you think it's not to hard to do, I would try it at
least. Could you give me a starting point?

Achim






From david.abrahams at rcn.com  Tue Jun  4 00:14:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 3 Jun 2002 18:14:36 -0400
Subject: [C++-sig] implicitly_convertible / virtual base class
References: <FCEMIEFBFOIDAOJDEPIAAEGJDGAA.achim.domma@syynx.de>
Message-ID: <10d301c20b4c$20d9a630$6601a8c0@boostconsulting.com>

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

> I realized this solution some minutes after sending the mail. First I
> thought I would have to write an implicitly_convertible for each class,
> derived from DrawableBase. But with 'bases<DrawableBase> defined and a
> conversion from DrawableBase to Drawable it works fine now. This solves
most
> of my problems.
>
> > Or, we could define
> >
> >     template <class T>
> >     def_implicit(args<T>);
>
> I would prefer this one.

Why?

So far I am leaning towards an interface that works more like C++ (implicit
is the default, "explicit_" is explicitly specified). I think people
writing wrappers will typically be looking over their C++ interface, so it
would be most natural to write:

    def_init(args<...>, explicit_)

> I have no problem writing down that the ctor should
> be available for implicit conversion, but it would be much more intuitive
to
> do it directly on the class, than to specify it somewhere else via
> implicitly_convertible.
>
> > Oh, BTW, patches to implement this would be welcome ;-)
>
> I'm developing in C++ for some years now, but I fear it's not good enough
> for boost. Anyway, if you think it's not to hard to do, I would try it at
> least. Could you give me a starting point?

It would be faster to implement it myself. However, the documentation will
be a PITA as usual. Would you like to contribute a doc patch?

-Dave






From david.abrahams at rcn.com  Tue Jun  4 14:40:59 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 4 Jun 2002 08:40:59 -0400
Subject: [C++-sig] boost-python-cvs list established
Message-ID: <12d201c20bc5$15655320$6601a8c0@boostconsulting.com>

Greetings,

If you're insane enough to want to get an email every time a CVS checkin to
the Boost.Python source occurs, please subscribe to:

http://lists.sourceforge.net/lists/listinfo/boost-python-cvs

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 achim.domma at syynx.de  Tue Jun  4 16:17:20 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Tue, 4 Jun 2002 16:17:20 +0200
Subject: [C++-sig] implicitly_convertible / virtual base class
In-Reply-To: <10d301c20b4c$20d9a630$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIACEHBDGAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams

> > >     template <class T>
> > >     def_implicit(args<T>);
> >
> > I would prefer this one.
>
> Why?
>
> So far I am leaning towards an interface that works more like C++
> (implicit
> is the default, "explicit_" is explicitly specified). I think people
> writing wrappers will typically be looking over their C++ interface, so it
> would be most natural to write:
>
>     def_init(args<...>, explicit_)

Your wrote in a previous mail, that this could be 'dangerous'. I usually
prefer to let user make his error actively, because they can not blame me
then. But it's true that one could expect the same behavior as in C++ as
default, so this version might be more intuitive.

> It would be faster to implement it myself. However, the documentation will
> be a PITA as usual. Would you like to contribute a doc patch?

What does PITA mean? If you want me to update the documentation according to
your changes, I will try my best. I think you are aware of the fact, that
I'm not a native speaker. Do you write the documentation 'by hand' or do you
use a tool?

Achim






From daveh at cadlink.com  Tue Jun  4 18:26:23 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 4 Jun 2002 12:26:23 -0400
Subject: [C++-sig] What CVS version for V2?
Message-ID: <adipo5$fkj$1@main.gmane.org>

Hi,

I tried to build V2 from CVS but was not very successful. The least errors
were if I got the HEAD tag on everything and the mpl_v2 tag on the mpl
directory. Even then I get:

boost\python\object\forward.hpp(9) : fatal error C1083: Cannot open include
file: 'boost/mpl/select_type.hpp': No such file or directory

It would appear that select_type.hpp is in the mpl-development branch, but
if I get that branch I have a lot more other errors...


Does anyone what the correct CVS branch is?

Thanks
Dave Hawkes









From david.abrahams at rcn.com  Tue Jun  4 19:01:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 4 Jun 2002 13:01:03 -0400
Subject: [C++-sig] What CVS version for V2?
References: <adipo5$fkj$1@main.gmane.org>
Message-ID: <adirr1$k8u$1@main.gmane.org>

"Dave Hawkes" <daveh at cadlink.com> wrote in message
news:adipo5$fkj$1 at main.gmane.org...
> Hi,
>
> I tried to build V2 from CVS but was not very successful. The least errors
> were if I got the HEAD tag on everything and the mpl_v2 tag on the mpl
> directory. Even then I get:
>
> boost\python\object\forward.hpp(9) : fatal error C1083: Cannot open
include
> file: 'boost/mpl/select_type.hpp': No such file or directory
>
> It would appear that select_type.hpp is in the mpl-development branch, but
> if I get that branch I have a lot more other errors...
>
>
> Does anyone what the correct CVS branch is?

It's "mpl-development"

What other errors are you getting?

-Dave








From daveh at cadlink.com  Tue Jun  4 20:02:44 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 4 Jun 2002 14:02:44 -0400
Subject: [C++-sig] Re: What CVS version for V2?
References: <adipo5$fkj$1@main.gmane.org> <adirr1$k8u$1@main.gmane.org>
Message-ID: <adivcq$s5q$1@main.gmane.org>

OK, I checked out the mpl-development branch and tried a simple test file
(VC6 SP5):


#include <boost/python/module.hpp>


int Test()
{
  return 5;
}

BOOST_PYTHON_MODULE_INIT(PyTest)
{
  module("PyTest").def("Test");
}

and get the following errors:

boost\python\converter\from_python.hpp(24) : error C2904: 'from_python' :
template-name already defined as 'volatile  __thiscall
boost::python::from_python'
boost\boost\mpl\aux_\count_if_not.hpp(61) : fatal error C1506: unrecoverable
block scoping error


Any ideas?

Thanks
Dave Hawkes


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:adirr1$k8u$1 at main.gmane.org...
>
> "Dave Hawkes" <daveh at cadlink.com> wrote in message
> news:adipo5$fkj$1 at main.gmane.org...
> > Hi,
> >
> > I tried to build V2 from CVS but was not very successful. The least
errors
> > were if I got the HEAD tag on everything and the mpl_v2 tag on the mpl
> > directory. Even then I get:
> >
> > boost\python\object\forward.hpp(9) : fatal error C1083: Cannot open
> include
> > file: 'boost/mpl/select_type.hpp': No such file or directory
> >
> > It would appear that select_type.hpp is in the mpl-development branch,
but
> > if I get that branch I have a lot more other errors...
> >
> >
> > Does anyone what the correct CVS branch is?
>
> It's "mpl-development"
>
> What other errors are you getting?
>
> -Dave








From david.abrahams at rcn.com  Tue Jun  4 20:14:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 4 Jun 2002 14:14:53 -0400
Subject: [C++-sig] Re: What CVS version for V2?
References: <adipo5$fkj$1@main.gmane.org> <adirr1$k8u$1@main.gmane.org> <adivcq$s5q$1@main.gmane.org>
Message-ID: <13f801c20bf4$267dce60$6601a8c0@boostconsulting.com>

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


> OK, I checked out the mpl-development branch and tried a simple test file
> (VC6 SP5):
>
>
> #include <boost/python/module.hpp>
>
>
> int Test()
> {
>   return 5;
> }
>
> BOOST_PYTHON_MODULE_INIT(PyTest)
> {
>   module("PyTest").def("Test");
> }
>
> and get the following errors:
>
> boost\python\converter\from_python.hpp(24) : error C2904: 'from_python' :
> template-name already defined as 'volatile  __thiscall
> boost::python::from_python'
> boost\boost\mpl\aux_\count_if_not.hpp(61) : fatal error C1506:
unrecoverable
> block scoping error
>
>
> Any ideas?

Try passing &Test as the second argument to def(), as required by the
interface...

-Dave






From daveh at cadlink.com  Tue Jun  4 20:35:22 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 4 Jun 2002 14:35:22 -0400
Subject: [C++-sig] Re: Re: What CVS version for V2?
References: <adipo5$fkj$1@main.gmane.org> <adirr1$k8u$1@main.gmane.org> <adivcq$s5q$1@main.gmane.org> <13f801c20bf4$267dce60$6601a8c0@boostconsulting.com>
Message-ID: <adj1a0$129$1@main.gmane.org>

Sorry my mistake, but the same error occurs even without this error. I tried
just including module.hpp without any code and still get the same error.

Dave Hawkes


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:13f801c20bf4$267dce60$6601a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> > OK, I checked out the mpl-development branch and tried a simple test
file
> > (VC6 SP5):
> >
> >
> > #include <boost/python/module.hpp>
> >
> >
> > int Test()
> > {
> >   return 5;
> > }
> >
> > BOOST_PYTHON_MODULE_INIT(PyTest)
> > {
> >   module("PyTest").def("Test");
> > }
> >
> > and get the following errors:
> >
> > boost\python\converter\from_python.hpp(24) : error C2904: 'from_python'
:
> > template-name already defined as 'volatile  __thiscall
> > boost::python::from_python'
> > boost\boost\mpl\aux_\count_if_not.hpp(61) : fatal error C1506:
> unrecoverable
> > block scoping error
> >
> >
> > Any ideas?
>
> Try passing &Test as the second argument to def(), as required by the
> interface...
>
> -Dave








From daveh at cadlink.com  Tue Jun  4 20:46:25 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 4 Jun 2002 14:46:25 -0400
Subject: [C++-sig] Re: Re: What CVS version for V2?
References: <adipo5$fkj$1@main.gmane.org> <adirr1$k8u$1@main.gmane.org> <adivcq$s5q$1@main.gmane.org> <13f801c20bf4$267dce60$6601a8c0@boostconsulting.com> <adj1a0$129$1@main.gmane.org>
Message-ID: <adj1un$2kj$1@main.gmane.org>

OK, I found it - I didn't realise I needed to define BOOST_PYTHON_V2 -;)


Dave Hawkes


"Dave Hawkes" <daveh at cadlink.com> wrote in message
news:adj1a0$129$1 at main.gmane.org...
> Sorry my mistake, but the same error occurs even without this error. I
tried
> just including module.hpp without any code and still get the same error.
>
> Dave Hawkes
>
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:13f801c20bf4$267dce60$6601a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> >
> > > OK, I checked out the mpl-development branch and tried a simple test
> file
> > > (VC6 SP5):
> > >
> > >
> > > #include <boost/python/module.hpp>
> > >
> > >
> > > int Test()
> > > {
> > >   return 5;
> > > }
> > >
> > > BOOST_PYTHON_MODULE_INIT(PyTest)
> > > {
> > >   module("PyTest").def("Test");
> > > }
> > >
> > > and get the following errors:
> > >
> > > boost\python\converter\from_python.hpp(24) : error C2904:
'from_python'
> :
> > > template-name already defined as 'volatile  __thiscall
> > > boost::python::from_python'
> > > boost\boost\mpl\aux_\count_if_not.hpp(61) : fatal error C1506:
> > unrecoverable
> > > block scoping error
> > >
> > >
> > > Any ideas?
> >
> > Try passing &Test as the second argument to def(), as required by the
> > interface...
> >
> > -Dave








From david.abrahams at rcn.com  Wed Jun  5 02:11:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 4 Jun 2002 20:11:17 -0400
Subject: [C++-sig] implicitly_convertible / virtual base class
References: <FCEMIEFBFOIDAOJDEPIACEHBDGAA.achim.domma@syynx.de>
Message-ID: <153601c20c25$c5e86420$6601a8c0@boostconsulting.com>

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


> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
>
> > > >     template <class T>
> > > >     def_implicit(args<T>);
> > >
> > > I would prefer this one.
> >
> > Why?
> >
> > So far I am leaning towards an interface that works more like C++
> > (implicit
> > is the default, "explicit_" is explicitly specified). I think people
> > writing wrappers will typically be looking over their C++ interface, so
it
> > would be most natural to write:
> >
> >     def_init(args<...>, explicit_)
>
> Your wrote in a previous mail, that this could be 'dangerous'.

It's only as dangerous as what you get in C++ by default.

> I usually
> prefer to let user make his error actively, because they can not blame me
> then. But it's true that one could expect the same behavior as in C++ as
> default, so this version might be more intuitive.

One other possibility: we could dispense with explicit_ (except possibly as
a way for the Python user to prevent the registration of an implicit
conversion that exists in C++) and simply create the implicit conversion if
the single argument type is convertible to the class type being wrapped.
That fact is detectable in C++ ;-)

> > It would be faster to implement it myself. However, the documentation
will
> > be a PITA as usual. Would you like to contribute a doc patch?
>
> What does PITA mean?

Pain in the <censored>... er, posterior.

> If you want me to update the documentation according to
> your changes, I will try my best. I think you are aware of the fact, that
> I'm not a native speaker. Do you write the documentation 'by hand' or do
you
> use a tool?

I do it by hand.

If I don't have to add "explicit_", a sentence or two of change in the docs
would do, and for that I wouldn't need your help.

OK, I'll give it a shot tomorrow.

-Dave






From hupp at cs.wisc.edu  Wed Jun  5 02:48:14 2002
From: hupp at cs.wisc.edu (Adam Hupp)
Date: Tue, 4 Jun 2002 19:48:14 -0500
Subject: [C++-sig] V2 Compilation problems
Message-ID: <20020605004814.GA16118@upl.cs.wisc.edu>

I've trying to work on Boost.Python V2 but have been having some
problems getting my project to build.  (My V1 wrapper works great).
When I try to link even a trivial example I get:

ITWrapper.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) public: __thiscall
boost::python::detail::module_base::~module_base(void)"
(__imp_??1module_base at detail@python at boost@@QAE at XZ)
ITWrapper.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) public: __thiscall
boost::python::detail::module_base::module_base(char const *)"
(__imp_??0module_base at detail@python at boost@@QAE at PBD@Z)
../../DLLs/pyImageTools.dll : fatal error LNK1120: 2 unresolved
externals
Error executing link.exe.

I'm building with MSVC 6.0, almost positive it's SP5.  I tried defining 
likely things that I had seen mentioned on the list during the build
("bjam -sTOOLS=msvc -sBOOST_PYTHON_DYNAMIC_LIB -sBOOST_PYTHON_V2"), but
no change.  


Another issue I've been having is that I cannot chain statements
like in the v2 examples.  That's not really a big deal, but I wonder if
it's a problem with my setup or a MSVC problems?


From david.abrahams at rcn.com  Wed Jun  5 03:03:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 4 Jun 2002 21:03:07 -0400
Subject: [C++-sig] V2 Compilation problems
References: <20020605004814.GA16118@upl.cs.wisc.edu>
Message-ID: <156b01c20c2d$166d7910$6601a8c0@boostconsulting.com>

From: "Adam Hupp" <hupp at cs.wisc.edu>

> I've trying to work on Boost.Python V2 but have been having some
> problems getting my project to build.  (My V1 wrapper works great).
> When I try to link even a trivial example I get:
>
> ITWrapper.obj : error LNK2001: unresolved external symbol
> "__declspec(dllimport) public: __thiscall
> boost::python::detail::module_base::~module_base(void)"
> (__imp_??1module_base at detail@python at boost@@QAE at XZ)
> ITWrapper.obj : error LNK2001: unresolved external symbol
> "__declspec(dllimport) public: __thiscall
> boost::python::detail::module_base::module_base(char const *)"
> (__imp_??0module_base at detail@python at boost@@QAE at PBD@Z)
> ../../DLLs/pyImageTools.dll : fatal error LNK1120: 2 unresolved
> externals
> Error executing link.exe.
>
> I'm building with MSVC 6.0, almost positive it's SP5.  I tried defining
> likely things that I had seen mentioned on the list during the build
> ("bjam -sTOOLS=msvc -sBOOST_PYTHON_DYNAMIC_LIB -sBOOST_PYTHON_V2"), but
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
This part has no effect.

Those are preprocessor defines, but only the people who aren't using bjam
need to worry about those.

Did you follow the recipe at
http://mail.python.org/pipermail/c++-sig/2002-April/000903.html for the
Jamfile you use to build your exntesion module?

That all still applies, but of course you should use bjam instead of jam.

> Another issue I've been having is that I cannot chain statements
> like in the v2 examples.  That's not really a big deal, but I wonder if
> it's a problem with my setup or a MSVC problems?
>
> From this:
>
> module m("pyImageTools").def("foo", &foo);
>
> I get:
>
>
P:\graphics\private\Students\hupp\ITImage\ImageTools\ITWrapper\ITWrapper.cp
p(19)
> : error C2143: syntax error : missing ';' before '.'

That example is wrong, sorry. You can't name the module variable *and*
chain off its declaration; it's one or the other. So you can write:

module("pyImageTools").def("foo", &foo);

or

module m("pyImageTools");
m.def("foo", &foo).def(...).def(...)...;

> Last, and probably least, I get a bunch of warnings when compiling.  I
> assume that is normal, but I'll put them at the end of the message just
> in case it's useful.  The test case I'm trying to build is also at the
> end of the message.


Using spaces instead of tabs for indentation survives mailers much better.

> #include <boost/python/module.hpp>
>
> using namespace boost::python;
>
> BOOST_PYTHON_MODULE_INIT(pyImageTools)
> {
>
>
> module m("pyImageTools");
>
> }
>
>
> And the results...
>
> p:\graphics\Tools\boost\boost/python/object/function.hpp(37) : warning
> C4251: 'm_fn' : class 'boost::function2<struct _object *,struct _object
> *,struct _object *,struct boost::empty_function_policy,struct
> boost::empty_function_mixin,int>' needs to h
> ave dll-interface to be used by clients of struct

<snip>

You're obviously not using Boost.Build to make your extension module.
Do it with bjam first; if you want to go back later and use your own build
tools you can copy the compiler options out of the "bjam -d+2" output.

HTH,
Dave






From david.abrahams at rcn.com  Wed Jun  5 03:08:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 4 Jun 2002 21:08:09 -0400
Subject: [C++-sig] V2 Compilation problems
References: <20020605004814.GA16118@upl.cs.wisc.edu> <156b01c20c2d$166d7910$6601a8c0@boostconsulting.com>
Message-ID: <157d01c20c2d$80827490$6601a8c0@boostconsulting.com>

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

> Did you follow the recipe at
> http://mail.python.org/pipermail/c++-sig/2002-April/000903.html for the
> Jamfile you use to build your exntesion module?

Another more-recent recipe is at:

http://mail.python.org/pipermail/c++-sig/2002-May/001052.html

-Dave





From daveh at cadlink.com  Wed Jun  5 17:51:23 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 5 Jun 2002 11:51:23 -0400
Subject: [C++-sig] sub module support in V2
Message-ID: <adlc2e$68b$1@main.gmane.org>

It would seem that it would be very easy to add sub module support to boost
python V2. This is useful for splitting up a large API into separate modules
even though they are all defined in the same executable. A large API occurs
more frequently when python is embedded in another large application and
this can save creating a myriad of small libraries.

As an example I tested the appended code (on Windows) and it appears to work
without problem, However it would be better if sub_module code was
integrated with the module code.

Would it be possible to add this to V2?
I can modify the module class and submit it if desired.


Dave Hawkes


#include <boost/python/module.hpp>

int Test1()
{
  return 1;
}

int Test2()
{
  return 2;
}

namespace boost { namespace python {

class sub_module : public module {
public:
  sub_module(const char* name) : module(name) {}
  sub_module(module& parent, const char* name) : module(name) {
    parent.setattr(name, object());
  }
  sub_module sub(const char* name) {
    return sub_module(*this, name);
  }
  template <class Fn>
  sub_module& def(char const* name, Fn fn) {
    this->module::def(name, fn);
    return  *this;
  }
};

}}

BOOST_PYTHON_MODULE_INIT(PyTest)
{
  boost::python::sub_module("PyTest").def("Test1",
Test1).sub("sm").def("Test2", Test2);
}



In python:

import PyTest
print PyTest.sm.Test2()









From david.abrahams at rcn.com  Wed Jun  5 18:17:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 5 Jun 2002 12:17:58 -0400
Subject: [C++-sig] sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>
Message-ID: <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com>

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


> It would seem that it would be very easy to add sub module support to
boost
> python V2. This is useful for splitting up a large API into separate
modules
> even though they are all defined in the same executable. A large API
occurs
> more frequently when python is embedded in another large application and
> this can save creating a myriad of small libraries.
>
> As an example I tested the appended code (on Windows) and it appears to
work
> without problem, However it would be better if sub_module code was
> integrated with the module code.
>
> Would it be possible to add this to V2?

I like the idea of supporting sub-modules, but your interface makes no
sense to me.
For one thing, I don't want to introduce a new class for sub-modules;
module itself should suffice.

> BOOST_PYTHON_MODULE_INIT(PyTest)
> {
>   boost::python::sub_module("PyTest")

Makes PyTest a sub-module of what?

>    .def("Test1",Test1)

Defines PyTest.Test1

>    .sub("sm")

".sub" is a nasty abbreviation. We only use ".def" because of Python

> .def("Test2", Test2);

Suppose I want to add a 2nd sub-module of PyTest?

Furthermore, I think "import sm" now imports PyTest.sm in your example,
which I presume was not intended.

-Dave






From daveh at cadlink.com  Wed Jun  5 19:08:27 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 5 Jun 2002 13:08:27 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com>
Message-ID: <adlgit$hmf$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:17ac01c20cac$9932b2a0$6601a8c0 at boostconsulting.com...
> I like the idea of supporting sub-modules, but your interface makes no
> sense to me.
> For one thing, I don't want to introduce a new class for sub-modules;
> module itself should suffice.
>

I agree, this was just a test class and is what I intended by mentioning
integrating it in to the module code, but I wasn't particularly explicit..

> > BOOST_PYTHON_MODULE_INIT(PyTest)
> > {
> >   boost::python::sub_module("PyTest")
>
> Makes PyTest a sub-module of what?

Nothing, it's the main module, this was just my test code so I did not have
to modify module.hpp

>
> >    .def("Test1",Test1)
>
> Defines PyTest.Test1
>
> >    .sub("sm")
>
> ".sub" is a nasty abbreviation. We only use ".def" because of Python
>

We could use sub_module (as the sub_module class will go), but is that too
verbose?

> > .def("Test2", Test2);
>
> Suppose I want to add a 2nd sub-module of PyTest?
>

Then we'll have to resort to this (or variation of):

boost::python::sub_module m("PyTest");
m.def("Test1", Test1).sub("sm").def("Test2", Test2);
m.sub("sm2").def...

> Furthermore, I think "import sm" now imports PyTest.sm in your example,
> which I presume was not intended.
>

Unfortuantely, yes, something will have to be done about Py_InitModule,
which call PyImport_AddModule. Maybe we should just delete the sys.modules
entry that is produced as a result? Unless there is a more elegant solution.

I'd also like to add some code that checks if a sub-module of the same name
already exists and return a reference to that rather than a new sub-module
so we don't lose previous definitions.

Dave Hawkes









From daveh at cadlink.com  Wed Jun  5 19:44:23 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 5 Jun 2002 13:44:23 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org>
Message-ID: <adlima$mnn$1@main.gmane.org>

"Dave Hawkes" <daveh at cadlink.com> wrote in message
news:adlgit$hmf$1 at main.gmane.org...
>
>
> Unfortuantely, yes, something will have to be done about Py_InitModule,
> which call PyImport_AddModule. Maybe we should just delete the sys.modules
> entry that is produced as a result? Unless there is a more elegant
solution.
>
> I'd also like to add some code that checks if a sub-module of the same
name
> already exists and return a reference to that rather than a new sub-module
> so we don't lose previous definitions.
>

No, this is not correct! I think we need to do something along these lines:

class sub_module : public module {
public:
  sub_module(const char* name) : module(name) {}
  sub_module(module& parent, const char* name) :
module(get_sub_module_name(parent, name).c_str()) {
    parent.setattr(name, object());
  }
  sub_module sub(const char* name) {
    return sub_module(*this, name);
  }
  template <class Fn>
  sub_module& def(char const* name, Fn fn) {
    this->module::def(name, fn);
    return  *this;
  }
  static std::string get_sub_module_name(module parent, const char *name) {
    ref module_name(PyObject_GetAttrString(parent.object().get(),
const_cast<char*>("__name__")));
    from_python<std::string> converter(module_name.get());
    std::string n = converter(module_name.get()) + '.';
    n += name;
    return n;
  }
};

This ensures sys.modules contains the correct dotted reference for the
sub-module.

Dave Hawkes









From david.abrahams at rcn.com  Wed Jun  5 20:09:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 5 Jun 2002 14:09:23 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org>
Message-ID: <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com>

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

> "Dave Hawkes" <daveh at cadlink.com> wrote in message
> news:adlgit$hmf$1 at main.gmane.org...
> >
> >
> > Unfortuantely, yes, something will have to be done about Py_InitModule,
> > which call PyImport_AddModule. Maybe we should just delete the
sys.modules
> > entry that is produced as a result? Unless there is a more elegant
> solution.
> >
> > I'd also like to add some code that checks if a sub-module of the same
> name
> > already exists and return a reference to that rather than a new
sub-module
> > so we don't lose previous definitions.
> >
>
> No, this is not correct! I think we need to do something along these
lines:

Just who are you arguing with here?

When the two of you work things out, please submit a patch ;-)

BTW, I am not happy about the interface in which sub() chaining introduces
another level of nesting. I would prefer it if you could find a way to get
something like this to work:

module("outer")
    .add(
        module("inner1")
            .def(...)
            ...
        )
    .add(
        module("inner2")
            .def(...)
            ...
    )

I realize this is a bit problematic, especially since class_<> instances
now get their __module__ attribute from the module they are added to. I'm
just asking you to think about it.

Perhaps Joel de Guzman has some creative phoenix-like ideas about this...
Joel?

-Dave







From david.abrahams at rcn.com  Wed Jun  5 20:23:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 5 Jun 2002 14:23:41 -0400
Subject: [C++-sig] NOTICE
Message-ID: <181d01c20cc3$c47dccd0$6601a8c0@boostconsulting.com>

I am changing some of the low-level details of how type conversions work in
Boost.Python v2. If you have been using undocumented low-level conversion
components (especially those from the boost::python::converter namespace,
but also including boost::python::from_python), you may find that your code
needs to be adjusted when I check these changes in.

caveat-emptor-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 daveh at cadlink.com  Wed Jun  5 22:40:49 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 5 Jun 2002 16:40:49 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com>
Message-ID: <adlt14$fnj$1@main.gmane.org>

> Just who are you arguing with here?

I thought I'd start a new trend and start flaming myself...

> BTW, I am not happy about the interface in which sub() chaining introduces
> another level of nesting. I would prefer it if you could find a way to get
> something like this to work:
>
> module("outer")
>     .add(
>         module("inner1")
>             .def(...)
>             ...
>         )
>     .add(
>         module("inner2")
>             .def(...)
>             ...
>     )
>
> I realize this is a bit problematic, especially since class_<> instances
> now get their __module__ attribute from the module they are added to. I'm
> just asking you to think about it.
>

Also how do the inner modules get their parent when they are instantiated at
this point? I'll certainly think about it as rough out a first
implementation.

Dave Hawkes









From david.abrahams at rcn.com  Wed Jun  5 22:47:25 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 5 Jun 2002 16:47:25 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org>
Message-ID: <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
>
> Also how do the inner modules get their parent when they are instantiated
at
> this point? I'll certainly think about it as rough out a first
> implementation.

Yes, it looks like you'd either have to:
1. Adjust the system's idea of the module when it's added to the parent, or
2. Defer Python module creation altogether until it's added to a parent (or
destroyed)
    2a. Defer class __module__ attribute setting

-Dave






From daveh at cadlink.com  Thu Jun  6 01:20:33 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 5 Jun 2002 19:20:33 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com>
Message-ID: <adm6c9$44l$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:186301c20cd3$2d84b5e0$6601a8c0 at boostconsulting.com...
>
> Yes, it looks like you'd either have to:
> 1. Adjust the system's idea of the module when it's added to the parent,
or
> 2. Defer Python module creation altogether until it's added to a parent
(or
> destroyed)
>     2a. Defer class __module__ attribute setting

I don't like either of these alternatives, so I'm thinking of a quite
different solution.

Instead of linking directly to the parent module, just define the sub-module
with a dotted name.

so we get:

boost::python::module("outer").def("Test1", Test1).def(...
boost::python::module("outer.inner1").def("Test2", Test2).def(...
boost::python::module("outer.inner2").def("Test3", Test3).def(...

This simplifies the chaining considerably as we can identify the parent
modules in sys.modules (and verify that it belongs to the current module).
An attempt to reuse a previous sub-module will just return a reference to
the existing one.

An advantage of this is that a later call to the main module would return a
reference to the previously created one and give more coding flexibility.

ie
boost::python::module("outer").def("Test1", Test1).def(...
boost::python::module("outer.inner").def("Test2", Test2).def(...
boost::python::module("outer").def("Test3", Test3).def(...    // get another
reference to the prior outer module
boost::python::module("outer.inner").def("Test4, Test4).def(...    // get
another reference to the prior inner module

Dave Hawkes









From david.abrahams at rcn.com  Thu Jun  6 01:25:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 5 Jun 2002 19:25:46 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org>
Message-ID: <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com>

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


> I don't like either of these alternatives, so I'm thinking of a quite
> different solution.
>
> Instead of linking directly to the parent module, just define the
sub-module
> with a dotted name.
>
> so we get:
>
> boost::python::module("outer").def("Test1", Test1).def(...
> boost::python::module("outer.inner1").def("Test2", Test2).def(...
> boost::python::module("outer.inner2").def("Test3", Test3).def(...
>
> This simplifies the chaining considerably as we can identify the parent
> modules in sys.modules (and verify that it belongs to the current
module).
> An attempt to reuse a previous sub-module will just return a reference to
> the existing one.
>
> An advantage of this is that a later call to the main module would return
a
> reference to the previously created one and give more coding flexibility.

I like it in principle, but the downside is that the absolute path to the
module is encoded in the source. You wouldn't be able to collect arbitrary
extension modules into a package later.

Got a workaround for that issue?





From daveh at cadlink.com  Thu Jun  6 02:20:15 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 5 Jun 2002 20:20:15 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com>
Message-ID: <adm9sj$9p9$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:191f01c20ce8$5388b790> reference to the previously created one and give
more coding flexibility.
>
> I like it in principle, but the downside is that the absolute path to the
> module is encoded in the source. You wouldn't be able to collect arbitrary
> extension modules into a package later.
>
> Got a workaround for that issue?

It shouldn't matter as we just need to identify our primary outer module and
work from there, it shouldn't be too hard to create a heuristic to identify
'our' outer module in sys.modules. Whether it is just 'outer' or
'xxx.yyy.outer' in the module list would make no difference, we (in effect)
just append the additional modules to the end.

Dave Hawkes









From david.abrahams at rcn.com  Thu Jun  6 02:31:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 5 Jun 2002 20:31:36 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org>
Message-ID: <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
>
> It shouldn't matter as we just need to identify our primary outer module
and
> work from there, it shouldn't be too hard to create a heuristic to
identify
> 'our' outer module in sys.modules. Whether it is just 'outer' or
> 'xxx.yyy.outer' in the module list would make no difference, we (in
effect)
> just append the additional modules to the end.

I was thinking along the same lines. Probably some small tweak to
BOOST_PYTHON_MODULE_INIT would suffice.
Looking forward to seeing what you come up with.

BTW, the bad news: submitted patches should eventually include tests and
docs ;-/

-Dave






From minxu at sci.ccny.cuny.edu  Thu Jun  6 17:53:48 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 06 Jun 2002 11:53:48 -0400
Subject: [C++-sig] TypeError: bad argument type for built-in operation
Message-ID: <1023378829.1529.6.camel@lax6>

I am troubled by this error for a long time even for a simple code. Can
anyone give me hints what is wrong here? Thanks. 

Output:

% compiles OK.
% python2.2 -c "import AA; print AA.AA().get1()"
Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: bad argument type for built-in operation


The simple code list:

#include <boost/python/class.hpp>
#include <boost/python/module.hpp>
#include <boost/ref.hpp>
#include <boost/utility.hpp>
using namespace boost::python;

class A
{
public:
	A() : x(0) {}
	virtual double get() = 0;
	virtual double get1(double x) = 0;
private:
	double x;
};


class AA : public A
{
public:
	AA() : A() {}
	double get() { return 0; }
	double get1(double x) { return x; }
	double get2(double x, double y) { return y+x; }
};


BOOST_PYTHON_MODULE_INIT(AA)
{
      module m("AA");
	  m.add(
	      class_<A, boost::noncopyable>("A")
	      .def("get", &A::get)
	      .def("get1", &A::get1)
	      );
	  m.add(
	      class_<AA, bases<A> >("AA")
	      .def_init(args<>())
	      .def("get2", &AA::get2)
	      );
}




Min Xu






From david.abrahams at rcn.com  Thu Jun  6 18:09:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 6 Jun 2002 12:09:57 -0400
Subject: [C++-sig] TypeError: bad argument type for built-in operation
References: <1023378829.1529.6.camel@lax6>
Message-ID: <1afb01c20d74$a74db3d0$6601a8c0@boostconsulting.com>

I don't understand what result you expect; There is no get1() function
which accepts zero arguments.


----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Thursday, June 06, 2002 11:53 AM
Subject: [C++-sig] TypeError: bad argument type for built-in operation


> I am troubled by this error for a long time even for a simple code. Can
> anyone give me hints what is wrong here? Thanks.
>
> Output:
>
> % compiles OK.
> % python2.2 -c "import AA; print AA.AA().get1()"
-----------------------------------------------^^
> Traceback (most recent call last):
>   File "<string>", line 1, in ?
> TypeError: bad argument type for built-in operation
>
>
> The simple code list:
>
> #include <boost/python/class.hpp>
> #include <boost/python/module.hpp>
> #include <boost/ref.hpp>
> #include <boost/utility.hpp>
> using namespace boost::python;
>
> class A
> {
> public:
> A() : x(0) {}
> virtual double get() = 0;
> virtual double get1(double x) = 0;
----------------------^^^^^^^^
> private:
> double x;
> };
>
>
> class AA : public A
> {
> public:
> AA() : A() {}
> double get() { return 0; }
> double get1(double x) { return x; }
--------------^^^^^^^^
> double get2(double x, double y) { return y+x; }
> };
>






From pearu at cens.ioc.ee  Thu Jun  6 19:03:45 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 6 Jun 2002 20:03:45 +0300 (EEST)
Subject: [C++-sig] TypeError: bad argument type for built-in operation
In-Reply-To: <1023378829.1529.6.camel@lax6>
Message-ID: <Pine.LNX.4.21.0206061954220.2115-100000@cens.ioc.ee>

Hi Dave,

On 6 Jun 2002, Min Xu wrote:

> Traceback (most recent call last):
>   File "<string>", line 1, in ?
> TypeError: bad argument type for built-in operation

This seems to be the most typical error that is raised within BPL and can 
be quite frustrating to track down the problems since the error message
is not really helpful --- it just says that something wrong but very
little hints what could be wrong. 

Is it possible to make this kind of error messages more verbose by
including, may be, the related class name, argument information
(number,type), what operation etc?

Thanks,
	Pearu





From minxu at sci.ccny.cuny.edu  Thu Jun  6 19:16:03 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 06 Jun 2002 13:16:03 -0400
Subject: [C++-sig] TypeError: bad argument type for built-in operation
In-Reply-To: <1afb01c20d74$a74db3d0$6601a8c0@boostconsulting.com>
References: <1023378829.1529.6.camel@lax6> 
	<1afb01c20d74$a74db3d0$6601a8c0@boostconsulting.com>
Message-ID: <1023383763.1529.12.camel@lax6>

Thanks for pointing out my error. I posted a wrong code. 

The problem is like this:

$ python2.2 -c "import AA; print AA.AA().get1(1); print AA.A().get1(1)"
1.0
Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: bad argument type for built-in operation


From david.abrahams at rcn.com  Thu Jun  6 19:35:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 6 Jun 2002 13:35:44 -0400
Subject: [C++-sig] TypeError: bad argument type for built-in operation
References: <1023378829.1529.6.camel@lax6> <1afb01c20d74$a74db3d0$6601a8c0@boostconsulting.com> <1023383763.1529.12.camel@lax6>
Message-ID: <1bb201c20d80$9e6be000$6601a8c0@boostconsulting.com>

You're missing a def_init() in class_<A>.

-Dave

----- Original Message ----- 
From: "Min Xu" <minxu at sci.ccny.cuny.edu>


> Thanks for pointing out my error. I posted a wrong code. 
> 
> The problem is like this:

<snip>





From david.abrahams at rcn.com  Thu Jun  6 19:56:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 6 Jun 2002 13:56:32 -0400
Subject: [C++-sig] TypeError: bad argument type for built-in operation
References: <Pine.LNX.4.21.0206061954220.2115-100000@cens.ioc.ee>
Message-ID: <1c0c01c20d83$951b0cd0$6601a8c0@boostconsulting.com>


----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>
To: <c++-sig at python.org>
Sent: Thursday, June 06, 2002 1:03 PM
Subject: Re: [C++-sig] TypeError: bad argument type for built-in operation


>
> Hi Dave,
>
> On 6 Jun 2002, Min Xu wrote:
>
> > Traceback (most recent call last):
> >   File "<string>", line 1, in ?
> > TypeError: bad argument type for built-in operation
>
> This seems to be the most typical error that is raised within BPL and can
> be quite frustrating to track down the problems since the error message
> is not really helpful --- it just says that something wrong but very
> little hints what could be wrong.
>
> Is it possible to make this kind of error messages more verbose by
> including, may be, the related class name, argument information
> (number,type), what operation etc?

Yes, it's in the plan, but there is an obstacle: GCC's type_info::name is
not really human-readable. However, you can help!
What we need is for someone to finish the project described below,
reimplementing the stream inserter (operator<<) for
boost::python::type_info on GCC.

-------


There are a few places where error reporting in Boost.Python depends on
being able to show users a reasonable representation of a C++ type name.
Currently, we use typeid(x).name() to get the name. Most compilers produce
a
good result, however g++ does not. I just ran a small experiment to see if
the type encoding scheme used by G++ could easily be deciphered, and it
appears that it can. If we want to improve error reporting with G++, it
should be relatively easy.

The enclosed program indicates the following encoding information:

v void
c char
h unsigned char
a signed char
i int
j unsigned int
i signed int
s short
l long
x long long
f float
d double
e long double
P% %*
R% %&
K% % const
V% %volatile
A##_% %[##]                an array of ## %s, e.g. A4_c => char[4]
##...                      A name of length ##, e.g. 3foo => foo
N%1%2...%nE   %1::%2::...%n    A qualified name, e.g. N3foo3barE =>
foo::bar
F%1%2...%nE   %1 ()(%2,...%n)  A function, e.g. PFicE => int (*)(char)

S_    Back-reference to the first name spelled ##..., e.g. PF3fooS_E => foo
(*)(foo)

S##_    Back-reference to the ##+2'th name, e.g. PF3foo3barS0_E => foo
(*)(bar,bar)

        Note that back-references increase the count, so:
            PF3fooS_3barS1_E => foo (*)(foo, bar, bar)
  not S0_ --------------^^^

M%1%2 %2 (%1::*)  Member pointer, e.g.  M3fooi => int (foo::*)
                                        M3fooFvvE => void (foo::*)(void)

%1I%2%3...%nE  %1<%2,%3...%n> class template, e.g. 3fooIilE =>
foo<int,long>
L%##   ##     non-type template parameter of type L and value ##, e.g.
                    3fooILi42E => foo<42>, where 42 is an int

I got stumped at function non-type template parameters:

3fooIXadL_Z1fvEEE => foo<f>, with template<void (*)()> class foo / void f()

     ^^^^^^^^^^^
3fooIXadsr6foobarNS0_1fEvEE => foo<foobar::f>,
     ^^^^^^^^^^^^^^^^^^^^^
    with template<void (foobar::*)()> class foo, void foobar::f()

---------

Anyway, if someone would like to translate this information into code (and
complete the job for non-type template parameters, if possible), we could
easily have better error reporting for g++ users.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: type_ids.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020606/b97e16d0/attachment.txt>

From daveh at cadlink.com  Thu Jun  6 20:41:07 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 6 Jun 2002 14:41:07 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com>
Message-ID: <adoacl$uu2$1@main.gmane.org>

I have a preliminary patch available against the current CVS (no tests or
docs yet...). There's a few rough edges and some tidying up to do, but it's
a good proof of concept. Should I email it to you directly or to this list?
Its about 10k in size.

Dave Hawkes


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:196c01c20cf1$c3a494f0$6601a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > It shouldn't matter as we just need to identify our primary outer module
> and
> > work from there, it shouldn't be too hard to create a heuristic to
> identify
> > 'our' outer module in sys.modules. Whether it is just 'outer' or
> > 'xxx.yyy.outer' in the module list would make no difference, we (in
> effect)
> > just append the additional modules to the end.
>
> I was thinking along the same lines. Probably some small tweak to
> BOOST_PYTHON_MODULE_INIT would suffice.
> Looking forward to seeing what you come up with.
>
> BTW, the bad news: submitted patches should eventually include tests and
> docs ;-/
>
> -Dave








From david.abrahams at rcn.com  Thu Jun  6 22:38:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 6 Jun 2002 16:38:28 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org>
Message-ID: <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com>

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


> I have a preliminary patch available against the current CVS (no tests or
> docs yet...). There's a few rough edges and some tidying up to do, but
it's
> a good proof of concept. Should I email it to you directly or to this
list?
> Its about 10k in size.

Please check it again against the current state; I just did a massive
checkin :-(

Then please send it to me or post it, compressed (your choice)

-Dave






From daveh at cadlink.com  Thu Jun  6 22:52:14 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 6 Jun 2002 16:52:14 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com>
Message-ID: <adoi2f$ica$1@main.gmane.org>

OK, here it is.


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1d9501c20d9a$1e8013b0$6601a8c0 at boostconsulting.com...
>
> ----- Original Message -----
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> > I have a preliminary patch available against the current CVS (no tests
or
> > docs yet...). There's a few rough edges and some tidying up to do, but
> it's
> > a good proof of concept. Should I email it to you directly or to this
> list?
> > Its about 10k in size.
>
> Please check it again against the current state; I just did a massive
> checkin :-(
>
> Then please send it to me or post it, compressed (your choice)
>
> -Dave


begin 666 submodule.zip
M4$L#!!0````(`%"&QBPFLU-:S@<``*DE```.````<W5B;6]D=6QE+F1I9F;M
M6GMSVS82_]N>\7?8:V9<RJ*L5Q)'5)-)ZKBMKG[D;.?:S-P,AR(ABPU%:@C0
ML<YU/WL7`$F0!"7V$B7M= [CD"*X+RQ^NP06F80>N;-@&D64=9<K-H_"[B+R
MDH <SI?+O=WGG][V=B^/KV#F!\2"KGM+XRAB7:Y076N5F[=[NS%AL4]N_? &
M8KQ1/PJA?]A_NK?K^;,9=!+HQ/P9BC9W.IUU`]IY`O],0ACT>@,8#*W'1U;_
M&71ZV':DV':[O9;W:8&W9ST>64]ZDG=O]^5+Z SZYC-HB^O+EWN[`,MD&OBN
MA3]Y8ZLE\<@,/,(</[ L*=B>.I0`OXR1#FWGI/*5X48A9>#.G?@`0F=!6N*U
M;);@,40WW#^@X;"!$YY7U09^^-YH'=X09J<]G,YHM;@D78=9SR]50SK";A=>
M>1Z0@"Q(R"BP"-B<I#8AC3)P'RB*8RS6+#7AS>IB^@MQV4$+/5('3VE)5_GO
MSX*J9D@#;(=EU Y!<1:1VZQBYW$)B8.G110/!8B;Q30#NM\S^WUHX^WQ4$(:
M__ at DT:7C$JD![@L]4ENI2VK&+L'==@.'4BA@"/ON\5\6*A)\)8RE??<%8"[M
M9>POG'@EL<OAO5_N&9>H%<(YJ7K*R;+XN8U\CT/3B#%0]Q=UNOV9\8^J_LX+
MC*,L=E0[J+%S457)-7'N.ET(HR0.-3F:V<4 at TB)ZO=REW>2*F- UINDN2&F+
M<I#DUF'$4D,]`&TL^ACJ#:/,8;XK_*5+4 0E014Q#_R"0)0H_/;BXNK:?O/N
M^H>+<_OUR?%I,1Z1ZE[/X9CACF."0P(G^^+ Y<F_WDXN3ZXLB,)@A9<LXX%/
MP174'BQ)G#%D.5[ITA,]M[.)R"R&R3[P*_)).W\K,F+O'TW1S>G6#WWVETBW
MW)"&54)ED0!%SN9TJPAW!B,X<U9YHAP.,%>J58/(M\URFO/M,W,X at O8S\\DH
MS[:/,-_ at G,S*8#V[>/WV],2>G$^N95I]! !(Y2/VWEQ.SEY=OLMH3B?G/Z:K
MA)KV'^05@<Y-M N at L1\]DMEC#*KIO!_Y,1"\&,A%!%M6):HWZ:W$N))1SO1B
M#.,*[\,#3TU5ITEOVM^]/3]6[OH(AVW at NX>F5L^'MZ(Z-37-?'):+$O.A675
M+P*SS)WR2?<@]!![J8,\P_YI<CX<M.#77U67??SN>^RV[98$JW+H6KA6?*L;
MW0C?9H>!-D&:QYIED#M&XA"^.OX*;-LC;D"7Q#6\("!WRRAF+:4D$Z[+:)SP
M9CLZ-9,X=T(/!T7N7+)DF.J,?7VLK;$.A&89.J!1D!S+PZ>/I;TVRK8QMSD$
M25"$[:O)S^H5,KI!XA'XIBY;._Z=+22K+=^++:!::Y\1_5OQY!BVVBK1]%G;
M-J+N?]&%+1V;VK:"_68U6? D89]&CO=ZA5[UW3.Y,1>?+!/2VW>3TQ/ ?>X?
MU:4EG6WCHJ#KB_ at QRW ;/E65J#0V>->$IDSXV7359$QLGYPUF]MVLO.7S.);
MR5%92B<!)7_KQ8<>\E\H#?Y_\?%1BX\0MYSU^^A(?!ZZLR1T^:#_I$VT9L6F
M'?2HO(,>0<:FML]-PG<&:L_;'UD]_!OF6^>1V#HWR6BN4X[,(VCC-2V\4Q8G
M+M/K.[GY8.6?ZZS.`Y"_-98K._MM0A)2_R8D'BS\T';B&UKL<NY$%SR'7FN<
M!LQO&:^JA76[<)90!G/GEL"M'[/$"< CTLXHIB*-P8<X0O='2Q([V(GO`\)D
M$<D)`L*!!V=7_SZ6,C,Q%77 F[RI%8D08.2/Q1*[K)9QQART at 3^EV630V,T.
M0-PO!==U^C<!]:@,U"-03!*FZX0VU-*/!$ W<>O0')2 at V3?[/6CC[<G1IY;0
M!7.GD"6+9TCK3XLL6&3K&=F3 at L.>8"([*YP7V:Y#V3="P N9($V1['PGL!<$
MS?)H\03*Y*58R_)#-^;%1&2/DI"UBE4A43&6I1Z9-FDR36VI/?@Y$UI>(_5!
M17&IV G[_,HUW1>*Z$LG1BM4I9W3'-[(DK2B<I.X3";9M%*R9UD8GAQF5%23
M,H=,^5,='=[]_Q*;G_+Q&G=$C5ZN>!;%AA\R"'BB&(_;[: %F>D;Q'@1XX*0
M2=IPB*L;S_CZ\&M3:I#R94L-4[3H:I1H"$*3B](X_)F!!J%%)6/R.O><N.]%
M<5C(]:GX'<7^C1\Z`2]SRZSE4$IBEO$KT:E&J4"]+JK K!1]``?H/(J9F["L
M;AY&S.$93>-2HQ2SJY]>CBLLTCA#<AVZT8+/ME'/VY*FCO6AE" B("5HS]^>
MGJ+KZL=V/4>/??"#`*9$EM@=/TP'J'%(:(;D at UU2930$:3XNF\]TJR9<U\3H
M6+= "Q_-FAHF/9H:.83O*6%EIVH6/12>'R30E*.5R\B=3QE&32&QZ/.7?_GL
M'QSZBK'X2D2:@<9K\VI"DY>Q*5.:S5'*OR=L&\K':W0+03)Q*)W7_$F'KR9&
M'6WFK!-ZE4S%09FA#4L9K+3FDH5 at O=4)44>&VN17[5IK at SX;U00^2X) QG at Y
M-?946E0FZ#&I-#8')%>UQ9C,)^-J&]@QU6@*C%)Q\V3!\PI[PZQIN:$A6!6_
M]OTH?1Y#[*QB;!H3YWWIR%^R0B:D#7WMW%V<@5>LY$2<0-TV++>:CV.1O[("
MJZZ")*>VV!'<K71O(O^'S>]02P$"% `4````" !0AL8L)K-36LX'``"I)0``
M#@```````````" (````````<W5B;6]D=6QE+F1I9F902P4&``````$``0`\
)````^@<`````
`
end







From david.abrahams at rcn.com  Fri Jun  7 00:08:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 6 Jun 2002 18:08:08 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org>
Message-ID: <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com>

Dave,

Thanks for spending time on this...

Remarks:

1. Please send a diff which can be used with the "patch" program
(preferably compatible with emacs' ediff-patch-file)

2. One of my design goals is to keep as much code out of extension modules
as possible. Thus

-    module(const char* name)
-        : base(name) {}
+     module(const char* name = detail::module_link().get_module_name())
+        : base(name, detail::module_link()) {}

this change ought to become two overloads.

Hmm...

If we don't need to pass arguments to the outer "module", maybe we should
dispense with it.
That would remove the need to break .add() chaining when classes have an
inheritance relationship... it would look like:

BOOST_PYTHON_MODULE_INIT(my_module)
{
   def("my_function", my_function);
   class_<my_class>("my_class")
      .def("memfn", &my_class::memfn)
       ...

   module("submodule")
   [
       def("my_function", my_function)
   ];
}

And, heck, we could use the same interface for class_ if we wanted to...

3. What's the rationale behind the name "module_link"?

4. Why are you creating a new module_link object here? That seems
needlessly expensive

5. You're not following my coding conventions (members begin with m_, no
other naming warts, aligned braces, lines less than 90 characters or so...)

6. What is the point of module_link's p_primary_module? It never gets moved
to point at anything else...

7. Initialize data members in member initializer lists

8. module_link::reset() can't throw; there's no point in complicating
BOOST_PYTHON_MODULE_INIT that way. Why don't you just stick the reset()
call in the outer init##name() function?

9. What is this all about? I've been testing against MSVC without problems
since the beginning, and I'm explicitly trying to avoid a virtual table:

     function(py_function, unsigned min_args, unsigned max_args = 0);
-    ~function();
+    // Must have virtual destructors else wrong operator delete is called
in MSVC
+    virtual ~function();

10. init_sub_module is too dense and under-commented for me to evaluate
quickly


----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Thursday, June 06, 2002 4:52 PM
Subject: [C++-sig] Re: Re: sub module support in V2


> OK, here it is.
>
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1d9501c20d9a$1e8013b0$6601a8c0 at boostconsulting.com...
> >
> > ----- Original Message -----
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> >
> > > I have a preliminary patch available against the current CVS (no
tests
> or
> > > docs yet...). There's a few rough edges and some tidying up to do,
but
> > it's
> > > a good proof of concept. Should I email it to you directly or to this
> > list?
> > > Its about 10k in size.
> >
> > Please check it again against the current state; I just did a massive
> > checkin :-(
> >
> > Then please send it to me or post it, compressed (your choice)
> >
> > -Dave
>
>
>


---------------------------------------------------------------------------
-----


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





From daveh at cadlink.com  Fri Jun  7 02:09:49 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 6 Jun 2002 20:09:49 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com>
Message-ID: <adotkq$9eb$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1e3001c20da6$ce8bb5f0$6601a8c0 at boostconsulting.com...

>
> 1. Please send a diff which can be used with the "patch" program
> (preferably compatible with emacs' ediff-patch-file)

I thought it was (cvs diff -u) ? Though I think I may of used the win32
version and not the cygwin version...


>
> 2. One of my design goals is to keep as much code out of extension modules
> as possible. Thus
>
> -    module(const char* name)
> -        : base(name) {}
> +     module(const char* name = detail::module_link().get_module_name())
> +        : base(name, detail::module_link()) {}
>
> this change ought to become two overloads.

The module_link code cannot be instantiated within the boost shared library
as it relies on its static element to be resolved in the extension module.
That way multiple extension modules linked to a common boost shared library
will have different singletons to identify themselves to the common module
code. Everytime a new module is instantiated the module_link carries a
'link' to the main module associated with the calling extension.


>
> Hmm...
>
> If we don't need to pass arguments to the outer "module", maybe we should
> dispense with it.
> That would remove the need to break .add() chaining when classes have an
> inheritance relationship... it would look like:
>
> BOOST_PYTHON_MODULE_INIT(my_module)
> {
>    def("my_function", my_function);
>    class_<my_class>("my_class")
>       .def("memfn", &my_class::memfn)
>        ...
>
>    module("submodule")
>    [
>        def("my_function", my_function)
>    ];
> }
>
> And, heck, we could use the same interface for class_ if we wanted to...

Yes that is definately feasible. I'm also looking at creating a new macro
that will work something like this:

BOOST_PYTHON_MODULES()
{
    module(".sm").def("another_function", another_function);
}

This macro would automatically chain from BOOST_PYTHON_INIT even in separate
code modules. This would make implementing large libraries easier as python
definitions could be added alongside their implementations. Note the
contraction above where a leading dot automatically signifies construction
of a sub-module. Also note that order of construction of modules is handled
transparantly, a sub-module can be defined before its parent.

>
> 3. What's the rationale behind the name "module_link"?
>
> 4. Why are you creating a new module_link object here? That seems
> needlessly expensive

see above...

>
> 5. You're not following my coding conventions (members begin with m_, no
> other naming warts, aligned braces, lines less than 90 characters or
so...)

Probably not, I just wanted to get a proof of concept at this point, in case
I had to do a significant rework. I'll tidy up if your happy with the basic
methods used to implement sub-modules.
>
> 6. What is the point of module_link's p_primary_module? It never gets
moved
> to point at anything else...

It would be different for each extension library linked to a common boost
shared library and also loaded by a common instance of the interpreter. It
needs to be created in the extension library so we can access the static
singleton from within the shared boost library itself.

>
> 7. Initialize data members in member initializer lists
>
> 8. module_link::reset() can't throw; there's no point in complicating
> BOOST_PYTHON_MODULE_INIT that way. Why don't you just stick the reset()
> call in the outer init##name() function?
>

I thought there was some potential here if it somehow landed up owning the
last remaining instance of the module object and the PyObject destructor
died.

> 9. What is this all about? I've been testing against MSVC without problems
> since the beginning, and I'm explicitly trying to avoid a virtual table:
>
>      function(py_function, unsigned min_args, unsigned max_args = 0);
> -    ~function();
> +    // Must have virtual destructors else wrong operator delete is called
> in MSVC
> +    virtual ~function();

see MS KB Q122675. If the destructor is not virtual then the new occurs with
the heap of the extension module and the delete occurs with the context of
the boost shared library. I got exceptions as a result of this and adding
the virtual destructor fixed it.

>
> 10. init_sub_module is too dense and under-commented for me to evaluate
> quickly
>
That's one of the places earmarked for tidying up, probably by splitting out
a couple of helper functions. It was one of those pieces of code that
started small and just grew a little too large.
>

Dave Hawkes









From david.abrahams at rcn.com  Fri Jun  7 04:18:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 6 Jun 2002 22:18:23 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org>
Message-ID: <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Thursday, June 06, 2002 8:09 PM
Subject: [C++-sig] Re: Re: Re: sub module support in V2


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1e3001c20da6$ce8bb5f0$6601a8c0 at boostconsulting.com...
>
> >
> > 1. Please send a diff which can be used with the "patch" program
> > (preferably compatible with emacs' ediff-patch-file)
>
> I thought it was (cvs diff -u) ? Though I think I may of used the win32
> version and not the cygwin version...
>
>
> >
> > 2. One of my design goals is to keep as much code out of extension
modules
> > as possible. Thus
> >
> > -    module(const char* name)
> > -        : base(name) {}
> > +     module(const char* name =
detail::module_link().get_module_name())
> > +        : base(name, detail::module_link()) {}
> >
> > this change ought to become two overloads.
>
> The module_link code cannot be instantiated within the boost shared
library
> as it relies on its static element to be resolved in the extension
module.

That's non-portable. Basically, you can write code that uses static members
as long as it's OK if they're shared between the things that are linked
together, but does not require it. Code that requires non-sharing of
identically-named objects may fail on some platforms.

> That way multiple extension modules linked to a common boost shared
library
> will have different singletons to identify themselves to the common
module
> code. Everytime a new module is instantiated the module_link carries a
> 'link' to the main module associated with the calling extension.

There are other, better ways to handle this, that don't stress the ODR so
much.
You can use the unnamed namespace, for example.

> Yes that is definately feasible. I'm also looking at creating a new macro
> that will work something like this:
>
> BOOST_PYTHON_MODULES()
> {
>     module(".sm").def("another_function", another_function);
> }
>
> This macro would automatically chain from BOOST_PYTHON_INIT even in
separate
> code modules.

Why do we need the macro?

> This would make implementing large libraries easier as python
> definitions could be added alongside their implementations. Note the
> contraction above where a leading dot automatically signifies
construction
> of a sub-module. Also note that order of construction of modules is
handled
> transparantly, a sub-module can be defined before its parent.

Bizarre. What makes that work?

> > 3. What's the rationale behind the name "module_link"?

Answer?

> > 4. Why are you creating a new module_link object here? That seems
> > needlessly expensive
>
> see above...
>
> >
> > 5. You're not following my coding conventions (members begin with m_,
no
> > other naming warts, aligned braces, lines less than 90 characters or
> so...)
>
> Probably not, I just wanted to get a proof of concept at this point, in
case
> I had to do a significant rework. I'll tidy up if your happy with the
basic
> methods used to implement sub-modules.

I'm not sure about it yet. Your module_link class is a very strange design
and the bulk of the work is in init_sub_module, which as I said is too
dense to evaluate.

> > 6. What is the point of module_link's p_primary_module? It never gets
> moved
> > to point at anything else...
>
> It would be different for each extension library linked to a common boost
> shared library and also loaded by a common instance of the interpreter.
It
> needs to be created in the extension library so we can access the static
> singleton from within the shared boost library itself.

Once you deconvolute that design, as Ralf likes to say, I might be happier
with it...

> > 7. Initialize data members in member initializer lists
> >
> > 8. module_link::reset() can't throw; there's no point in complicating
> > BOOST_PYTHON_MODULE_INIT that way. Why don't you just stick the reset()
> > call in the outer init##name() function?
> >
>
> I thought there was some potential here if it somehow landed up owning
the
> last remaining instance of the module object and the PyObject destructor
> died.

PyObjects don't have destructors. Do you mean its __del__ method? It still
won't throw a C++ exception.

> > 9. What is this all about? I've been testing against MSVC without
problems
> > since the beginning, and I'm explicitly trying to avoid a virtual
table:
> >
> >      function(py_function, unsigned min_args, unsigned max_args = 0);
> > -    ~function();
> > +    // Must have virtual destructors else wrong operator delete is
called
> > in MSVC
> > +    virtual ~function();
>
> see MS KB Q122675. If the destructor is not virtual then the new occurs
with
> the heap of the extension module and the delete occurs with the context
of
> the boost shared library.

So what? We're linked to a shared runtime.

> I got exceptions as a result of this and adding
> the virtual destructor fixed it.

Please provide a reproducible test case.

-Dave






From daveh at cadlink.com  Fri Jun  7 06:14:11 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 7 Jun 2002 00:14:11 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com>
Message-ID: <adpbun$sof$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1efd01c20dc9$a1aa10e0$6601a8c0 at boostconsulting.com...

> > > 2.> > as it relies on its static element to be resolved in the
extension
> module.
>
> That's non-portable. Basically, you can write code that uses static
members
> as long as it's OK if they're shared between the things that are linked
> together, but does not require it. Code that requires non-sharing of
> identically-named objects may fail on some platforms.
>

I don't know of any platforms that do that as it would be difficult to
implement unless all functions were exported, though come to think of it I
seem to remember a codewarrior for mac option that exports everything, but
then I suppose all your shared libraries together become a single
translation unit. That aside I can probably fix it by making the module_link
a base class of a new class that is created using the module name which then
holds the static singleton.

> > That way multiple extension modules linked to a common boost shared
> library
> > will have different singletons to identify themselves to the common
> module
> > code. Everytime a new module is instantiated the module_link carries a
> > 'link' to the main module associated with the calling extension.
>
> There are other, better ways to handle this, that don't stress the ODR so
> much.
> You can use the unnamed namespace, for example.
>

I'm not sure how to accomplish this by using an unnamed namespace, probably
the solution I outlined above is adequate and won't rely on the ODR.

> > BOOST_PYTHON_MODULES()
> > {
> >     module(".sm").def("another_function", another_function);
> > }
> >
> > This macro would automatically chain from BOOST_PYTHON_INIT even in
> separate
> > code modules.
>
> Why do we need the macro?
>

To save the user the bother of calling the other init functions directly
inside BOOST_PYTHON_MODULE_INIT

> > This would make implementing large libraries easier as python
> > definitions could be added alongside their implementations. Note the
> > contraction above where a leading dot automatically signifies
> construction
> > of a sub-module. Also note that order of construction of modules is
> handled
> > transparantly, a sub-module can be defined before its parent.
>
> Bizarre. What makes that work?
>

As part of the process of creating a sub-module, each parent must be checked
to see if it exists at each step. If it does not exist we could either
assert or transparantly create it anyway. I just chose to do the latter.
Then if the parent is referenced later we just pull a reference to the
previously created but yet unused module.

> > > 3. What's the rationale behind the name "module_link"?
>
> Answer?
>

I thought that may be clear from the previous explanation. It provides a
link between the main module, the boost shared library and the actual
extension.

> > > 5.
> I'm not sure about it yet. Your module_link class is a very strange design
> and the bulk of the work is in init_sub_module, which as I said is too
> dense to evaluate.
>

I'll refactor the init_sub_module in the next few days and send you another
diff.

> > > 6. What is the point of module_link's p_primary_module? It never gets
>
> Once you deconvolute that design, as Ralf likes to say, I might be happier
> with it...
>

I'll look in to simplifying it as part of changing the module_link
structure.

> > > 8.
>
> PyObjects don't have destructors. Do you mean its __del__ method? It still
> won't throw a C++ exception.
>

Yes I mean __del__ method which in our case can eventually land up calling:-

delete static_cast<function*>(p);

as part of cleaning up a module.

Also note that there is a final catch(...) which catches more than just C++
exceptions when using MSVC. In MSVC it will also catch access violations and
floating point exceptions (etc.). As an aside these are best handled by SEH
anyway, particularly when they are continuable, but I'm not going to suggest
an SEH block function for continuable floating point exceptions prior to the
catch(...)...

> > > 9.
> > see MS KB Q122675. If the destructor is not virtual then the new occurs
> with
> > the heap of the extension module and the delete occurs with the context
> of
> > the boost shared library.
>
> So what? We're linked to a shared runtime.
>

That maybe, but MS still provides a separate local heap for different dlls,
just try a straight malloc in one dll, passing the pointer to another and
freeing it. new and delete just use the regular malloc and free and have the
same issues if care is not taken.

Also not that, in fact, we may not even have a common run time for a number
of reasons. Sometimes the libraries are statically linked for localisation
reasons or to get around some MFC bugs/features that can only be resolved by
statically linking.


> > I got exceptions as a result of this and adding
> > the virtual destructor fixed it.
>
> Please provide a reproducible test case.
>

If your still not sure a virtual destructor is needed I'll look at packaging
up my MSVC test workspace files and sending them to you. Alternatively I
could use one of the other techniques that don't require a virtual
destructor to fix the problem.

Dave Hawkes









From david.abrahams at rcn.com  Fri Jun  7 07:17:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 7 Jun 2002 01:17:57 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org>
Message-ID: <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com>


----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Friday, June 07, 2002 12:14 AM
Subject: [C++-sig] Re: sub module support in V2


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:1efd01c20dc9$a1aa10e0$6601a8c0 at boostconsulting.com...
>
>
> I don't know of any platforms that do that as it would be difficult to
> implement unless all functions were exported,

All functions are exported on most Unix variants.

> though come to think of it I
> seem to remember a codewarrior for mac option that exports everything,
but
> then I suppose all your shared libraries together become a single
> translation unit. That aside I can probably fix it by making the
module_link
> a base class of a new class that is created using the module name which
then
> holds the static singleton.

That's very complicated. There's only one outer-level extension module
being loaded at any given time. Why don't you just keep track of that in a
single global which lives in the library.


> I'm not sure how to accomplish this by using an unnamed namespace,
probably
> the solution I outlined above is adequate and won't rely on the ODR.

I'm a little less worried about relying on the ODR than on relying on a
violation of it. That is, the language standard says "there's one copy of
any static data member of a class", and you said "I'm going to write code
that only works if there are multiple copies". Of course, you can't always
rely on things to work the way the standard says when shared libs are
involved, but relying on things NOT working the way the standard says seems
a bit... perverse to me.

> > >
> > > This macro would automatically chain from BOOST_PYTHON_INIT even in
> > separate
> > > code modules.
> >
> > Why do we need the macro?
> >
>
> To save the user the bother of calling the other init functions directly
> inside BOOST_PYTHON_MODULE_INIT

What other init functions? Why doesn't it just happen inside the module
constructor?

> > > transparantly, a sub-module can be defined before its parent.
> >
> > Bizarre. What makes that work?
> >
>
> As part of the process of creating a sub-module, each parent must be
checked
> to see if it exists at each step. If it does not exist we could either
> assert or transparantly create it anyway. I just chose to do the latter.
> Then if the parent is referenced later we just pull a reference to the
> previously created but yet unused module.

Ah. Defined, but not created.

> > > > 8.
> >
> > PyObjects don't have destructors. Do you mean its __del__ method? It
still
> > won't throw a C++ exception.
> >
>
> Yes I mean __del__ method which in our case can eventually land up
calling:-
>
> delete static_cast<function*>(p);

Which still doesn't throw.

> Also note that there is a final catch(...) which catches more than just
C++
> exceptions when using MSVC. In MSVC it will also catch access violations
and
> floating point exceptions (etc.).

And screw up your JIT debugging. Yes, I know.

> As an aside these are best handled by SEH
> anyway, particularly when they are continuable

What SEH exceptions are continuable?

> , but I'm not going to suggest
> an SEH block function for continuable floating point exceptions prior to
the
> catch(...)...

If you know a way to make some things smoother on Windows, I'm listening,
as long as it doesn't actually cover up bugs.

> > So what? We're linked to a shared runtime.
> >
>
> That maybe, but MS still provides a separate local heap for different
dlls,

That's perverse (seems to be my adjective-of-the-day).

> just try a straight malloc in one dll, passing the pointer to another and
> freeing it. new and delete just use the regular malloc and free and have
the
> same issues if care is not taken.

It works just fine for me. The enclosed Boost.Build project does just that
with the debugging runtime and raises no complaints.

> Also not that, in fact, we may not even have a common run time for a
number
> of reasons. Sometimes the libraries are statically linked for
localisation
> reasons or to get around some MFC bugs/features that can only be resolved
by
> statically linking.

I'm not supporting that configuration. I suppose I might consider adding
the virtual destructor with a switch for people who wanted to do that, but
I wouldn't make any guarantees about it.

> > > I got exceptions as a result of this and adding
> > > the virtual destructor fixed it.
> >
> > Please provide a reproducible test case.
> >
>
> If your still not sure a virtual destructor is needed I'll look at
packaging
> up my MSVC test workspace files and sending them to you. Alternatively I
> could use one of the other techniques that don't require a virtual
> destructor to fix the problem.

I just want proof that there is a local heap per-DLL.

-Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: shared_runtime.zip
Type: application/x-zip-compressed
Size: 1334 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020607/c313ebb1/attachment.bin>

From daveh at cadlink.com  Fri Jun  7 17:21:39 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 7 Jun 2002 11:21:39 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com>
Message-ID: <adqj2l$tbf$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1f3401c20de3$226029e0$6601a8c0 at boostconsulting.com...
>
> ----- Original Message -----
> From: "Dave Hawkes" <daveh at cadlink.com>
> Newsgroups: gmane.comp.python.c++
> To: <c++-sig at python.org>
> Sent: Friday, June 07, 2002 12:14 AM
> Subject: [C++-sig] Re: sub module support in V2
>
>
> >
> > "David Abrahams" <david.abrahams at rcn.com> wrote in message
> > news:1efd01c20dc9$a1aa10e0$6601a8c0 at boostconsulting.com...
> >
> >
> > I don't know of any platforms that do that as it would be difficult to
> > implement unless all functions were exported,
>
> All functions are exported on most Unix variants.

Though they will only know about each other if they are explicity linked to
each other. If we have to separate execution units linked to a common shared
library, they would not be linked to each other.

>
> > though come to think of it I
> > seem to remember a codewarrior for mac option that exports everything,
> but
> > then I suppose all your shared libraries together become a single
> > translation unit. That aside I can probably fix it by making the
> module_link
> > a base class of a new class that is created using the module name which
> then
> > holds the static singleton.
>
> That's very complicated. There's only one outer-level extension module
> being loaded at any given time. Why don't you just keep track of that in a
> single global which lives in the library.

Because if we have multiple extension libraries linked to a common BPL then
there will be more than one 'global' module as far as the BPL is concerned
when these extensions are imported by the same python session.

>
>
> > I'm not sure how to accomplish this by using an unnamed namespace,
> probably
> > the solution I outlined above is adequate and won't rely on the ODR.
>
> I'm a little less worried about relying on the ODR than on relying on a
> violation of it. That is, the language standard says "there's one copy of
> any static data member of a class", and you said "I'm going to write code
> that only works if there are multiple copies". Of course, you can't always
> rely on things to work the way the standard says when shared libs are
> involved, but relying on things NOT working the way the standard says
seems
> a bit... perverse to me.

Unless the extension library is actually linked to the other this should not
be a problem, but I think I have a better way of doing it which should be
more robust. I'll test and let you know.

>
> > > >
> > > > This macro would automatically chain from BOOST_PYTHON_INIT even in
> > > separate
> > > > code modules.
> > >
> > > Why do we need the macro?
> > >
> >
> > To save the user the bother of calling the other init functions directly
> > inside BOOST_PYTHON_MODULE_INIT
>
> What other init functions? Why doesn't it just happen inside the module
> constructor?
>

It sounds like I haven't explained what this achieves very well so I'll give
a code example:

instead of:

BOOST_PYTHON_MODULE_INIT(MyMod)
{
    module("MyMod").Add(...
    ...
    OtherModules1();
    OtherModules2();
}

OtherModules1()
{
    module("MyMod.SubMod1").Add(...
    ...
}

OtherModules2()
{
    module("MyMod.SubMod2").Add(...
    ...
}

we would have something like:

BOOST_PYTHON_MODULE_INIT(MyMod)
{
    module("MyMod").Add(...
    ...
}

BOOST_PYTHON_MODULES()
{
    module("MyMod.SubMod1").Add(...
    ...
}

BOOST_PYTHON_MODULES()
{
    module("MyMod.SubMod2").Add(...
    ...
}

where the BOOST_PYTHON_MODULES() could be located in separate source files.

> > > > transparantly, a sub-module can be defined before its parent.
> > >
> > > Bizarre. What makes that work?
> > >
> >
> > As part of the process of creating a sub-module, each parent must be
> checked
> > to see if it exists at each step. If it does not exist we could either
> > assert or transparantly create it anyway. I just chose to do the latter.
> > Then if the parent is referenced later we just pull a reference to the
> > previously created but yet unused module.
>
> Ah. Defined, but not created.
>

In fact it has to be created so the sub-module attribute can be added. It is
just not passed back at the time.

> > > > > 8.
> > >
> > > PyObjects don't have destructors. Do you mean its __del__ method? It
> still
> > > won't throw a C++ exception.
> > >
> >
> > Yes I mean __del__ method which in our case can eventually land up
> calling:-
> >
> > delete static_cast<function*>(p);
>
> Which still doesn't throw.
>

It might not throw a c++ exception, but it can sill throw an access
violation, for example, which is caught in catch(...) and possibly saves the
interpreter from exiting, though may be we don't want that functionality
anyway?

> > Also note that there is a final catch(...) which catches more than just
> C++
> > exceptions when using MSVC. In MSVC it will also catch access violations
> and
> > floating point exceptions (etc.).
>
> And screw up your JIT debugging. Yes, I know.
>
> > As an aside these are best handled by SEH
> > anyway, particularly when they are continuable
>
> What SEH exceptions are continuable?
>

Usually floating point exceptions where we use the MS _fpieee_flt
functionality. Typically done in CAD packages that heavily use floating
point so we can correct minor overflow/underflow/Inexact problems without
aborting the program. Of course libraries with catch(...) handlers are a
menace in this case as it prevents the outer floating point SEH block from
catching the exception.

> > , but I'm not going to suggest
> > an SEH block function for continuable floating point exceptions prior to
> the
> > catch(...)...
>
> If you know a way to make some things smoother on Windows, I'm listening,
> as long as it doesn't actually cover up bugs.
>

I'll look in to it. The best solution may well be to give the user an option
of avoiding the final catch(...) handler somehow so any outer SEH is not
messed up. Unknown c++ exceptions would have to be dealt with by the user as
well, but anyone doing this in the first place should be more than capable
of dealing with that minor problem.

> > > So what? We're linked to a shared runtime.
> > >
> >
> > That maybe, but MS still provides a separate local heap for different
> dlls,
>
> That's perverse (seems to be my adjective-of-the-day).
>
> > just try a straight malloc in one dll, passing the pointer to another
and
> > freeing it. new and delete just use the regular malloc and free and have
> the
> > same issues if care is not taken.
>
> It works just fine for me. The enclosed Boost.Build project does just that
> with the debugging runtime and raises no complaints.
>

I checked my projects and for some reason I was using the single threaded
libraries on the extension module.

> > Also not that, in fact, we may not even have a common run time for a
> number
> > of reasons. Sometimes the libraries are statically linked for
> localisation
> > reasons or to get around some MFC bugs/features that can only be
resolved
> by
> > statically linking.
>
> I'm not supporting that configuration. I suppose I might consider adding
> the virtual destructor with a switch for people who wanted to do that, but
> I wouldn't make any guarantees about it.
>
> > > > I got exceptions as a result of this and adding
> > > > the virtual destructor fixed it.
> > >
> > > Please provide a reproducible test case.
> > >
> >
> > If your still not sure a virtual destructor is needed I'll look at
> packaging
> > up my MSVC test workspace files and sending them to you. Alternatively I
> > could use one of the other techniques that don't require a virtual
> > destructor to fix the problem.
>
> I just want proof that there is a local heap per-DLL.
>

Is it a good idea to rely on there being a single common shared library for
allocation? What if the user overloads the global operator new function in
the extension library for customised memory allocation?

Dave Hawkes









From david.abrahams at rcn.com  Fri Jun  7 18:17:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 7 Jun 2002 12:17:51 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org>
Message-ID: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com>

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

> > All functions are exported on most Unix variants.
>
> Though they will only know about each other if they are explicity linked
to
> each other. If we have to separate execution units linked to a common
shared
> library, they would not be linked to each other.

Believe me; I know what's going on here. I've been involved in long
discussions with the GCC and GLIBC maintainers about this, as well as some
with the C++ standards committee about how we're going to standardize
shared lib behavior.

> > That's very complicated. There's only one outer-level extension module
> > being loaded at any given time. Why don't you just keep track of that
in a
> > single global which lives in the library.
>
> Because if we have multiple extension libraries linked to a common BPL
then
> there will be more than one 'global' module as far as the BPL is
concerned
> when these extensions are imported by the same python session.

But not at any given instant. Imports are serialized.

> > I'm a little less worried about relying on the ODR than on relying on a
> > violation of it. That is, the language standard says "there's one copy
of
> > any static data member of a class", and you said "I'm going to write
code
> > that only works if there are multiple copies". Of course, you can't
always
> > rely on things to work the way the standard says when shared libs are
> > involved, but relying on things NOT working the way the standard says
> seems
> > a bit... perverse to me.
>
> Unless the extension library is actually linked to the other this should
not
> be a problem, but I think I have a better way of doing it which should be
> more robust. I'll test and let you know.

They are linked to a common shared library, so there's a global sharing
path from one to the other. If the common shared lib instantiates the
symbol, it will be shared between the two libraries. This doesn't work
right on all systems today, but that's probably going to change.

> > What other init functions? Why doesn't it just happen inside the module
> > constructor?
> >
>
> It sounds like I haven't explained what this achieves very well so I'll
give
> a code example:
>
> instead of:
>
> BOOST_PYTHON_MODULE_INIT(MyMod)
> {
>     module("MyMod").Add(...
>     ...
>     OtherModules1();
>     OtherModules2();
> }
>
> OtherModules1()
> {
>     module("MyMod.SubMod1").Add(...
>     ...
> }
>
> OtherModules2()
> {
>     module("MyMod.SubMod2").Add(...
>     ...
> }
>
> we would have something like:
>
> BOOST_PYTHON_MODULE_INIT(MyMod)
> {
>     module("MyMod").Add(...
>     ...
> }
>
> BOOST_PYTHON_MODULES()
> {
>     module("MyMod.SubMod1").Add(...
>     ...
> }
>
> BOOST_PYTHON_MODULES()
> {
>     module("MyMod.SubMod2").Add(...
>     ...
> }
>
> where the BOOST_PYTHON_MODULES() could be located in separate source
files.

And the advantage to that is...?

(BTW, if you're doing what I think you are, the linker may be free to
remove the translation units containing the submodule definitions, which
would break this scheme -- AFAIK, explicit calls are the only portable
way).

> > Ah. Defined, but not created.
> >
>
> In fact it has to be created so the sub-module attribute can be added. It
is
> just not passed back at the time.


nice.

> > Which still doesn't throw.
> >
>
> It might not throw a c++ exception, but it can sill throw an access
> violation, for example, which is caught in catch(...) and possibly saves
the
> interpreter from exiting, though may be we don't want that functionality
> anyway?

Access violations as exceptions are outside the scope of the C++ standard.
I don't care what happens if there's an access violation -- some invariant
is broken and the program can't recover reliably anyway. Note the contents
of libs/python/test/module_tail.cpp which turns these into nice
JIT-debuggable crashes.

> > What SEH exceptions are continuable?
>
> Usually floating point exceptions where we use the MS _fpieee_flt
> functionality. Typically done in CAD packages that heavily use floating
> point so we can correct minor overflow/underflow/Inexact problems without
> aborting the program. Of course libraries with catch(...) handlers are a
> menace in this case as it prevents the outer floating point SEH block
from
> catching the exception.

More SEH perversity. Is there a way to get the SEH resumption to happen at
a lower level?

> > If you know a way to make some things smoother on Windows, I'm
listening,
> > as long as it doesn't actually cover up bugs.
> >
>
> I'll look in to it. The best solution may well be to give the user an
option
> of avoiding the final catch(...) handler somehow so any outer SEH is not
> messed up.

Yuck.

> Unknown c++ exceptions would have to be dealt with by the user as
> well, but anyone doing this in the first place should be more than
capable
> of dealing with that minor problem.

Not sure I agree.

> > It works just fine for me. The enclosed Boost.Build project does just
that
> > with the debugging runtime and raises no complaints.
>
> I checked my projects and for some reason I was using the single threaded
> libraries on the extension module.

Threading doesn't matter; it's just a question of static vs. dynamic
linking.

> Is it a good idea to rely on there being a single common shared library
for
> allocation? What if the user overloads the global operator new function
in
> the extension library for customised memory allocation?

OK, I hear ya. Really we should use Python's allocator/deallocator for
these objects, so it's a non-issue.
For now, the easy answer is to replace "new objects::function(" in
make_function.hpp with "objects::function::create(...", i.e. a static
member function call into the library.

-Dave







From rwgk at yahoo.com  Fri Jun  7 19:34:04 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 7 Jun 2002 10:34:04 -0700 (PDT)
Subject: [C++-sig] Re: Re: sub module support in V2
In-Reply-To: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com>
Message-ID: <20020607173404.91351.qmail@web20204.mail.yahoo.com>

Interesting discussion. I am still wondering, though, why support for
sub-modules is important. What can be done with sub-modules that cannot be done
within the framework of a regular Python package?
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Fri Jun  7 23:01:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 7 Jun 2002 17:01:01 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <20020607173404.91351.qmail@web20204.mail.yahoo.com>
Message-ID: <217f01c20e66$7c3cfd20$6601a8c0@boostconsulting.com>

A *very* interesting question; thanks for asking that!

-Dave

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


> Interesting discussion. I am still wondering, though, why support for
> sub-modules is important. What can be done with sub-modules that cannot
be done
> within the framework of a regular Python package?
> Ralf






From pyth at devel.trillke.net  Fri Jun  7 23:11:02 2002
From: pyth at devel.trillke.net (holger krekel)
Date: Fri, 7 Jun 2002 23:11:02 +0200
Subject: [C++-sig] Re: Re: sub module support in V2
In-Reply-To: <20020607173404.91351.qmail@web20204.mail.yahoo.com>; from rwgk@yahoo.com on Fri, Jun 07, 2002 at 10:34:04AM -0700
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com>
Message-ID: <20020607231102.E6609@prim.han.de>

Ralf W. Grosse-Kunstleve wrote:
> Interesting discussion. I am still wondering, though, why support for
> sub-modules is important. What can be done with sub-modules that cannot be done
> within the framework of a regular Python package?

IMO submodules allow nice grouping of related classes/functions internal
to a module. Isn't this question semantically similar to the question of 
why to have namespaces like ns1::subns:anothersubns... in C++?

Just wondering,

    holger




From david.abrahams at rcn.com  Fri Jun  7 23:06:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 7 Jun 2002 17:06:32 -0400
Subject: [C++-sig] Re: baking boost inside the main application instead of creating an extension module
References: <KJENIABEMDBBGDDMCPLHGEBKCAAA.miked@sinistergames.com>
Message-ID: <21b101c20e67$e38d16d0$6601a8c0@boostconsulting.com>

Please post follow-ups to c++-sig at python.org.

I know there are people who are using Boost.Python this way; I don't think
it's terribly complicated, but I don't know the steps off the top of my
head. Asking in a wider forum would probably get you better results. It
would be super if someone would knows could write an "embedding Python with
Boost.Python" guide for the docs.

-Dave

----- Original Message -----
From: "Mike Dickheiser" <miked at sinistergames.com>
To: <david.abrahams at rcn.com>
Sent: Friday, June 07, 2002 2:41 PM
Subject: baking boost inside the main application instead of creating an
extension module


> Hello Mr. Abrahams,
>
> (Please feel free to disgregard if you don't have time ;)
>
> I'm brand-spanking-new to Boost (and Python), so please forgive any
> ignorance exhibited in the text below.
>
> Currently I'm working on a gaming project that is to be ported to the
XBox.
> XBox doesn't support the use of .dll's, so in order to use Python I had
to
> build it as a static library (of course meaning the interpreter itself is
> embedded in the main application's executable. This has so far worked
very
> well, and I can use python just fine.
>
> However, I recently downloaded and built the Boost library, have used it
to
> wrap some C++ classes in my (Windows) application, but soon realized that
my
> Python scripts can't access these wrapped classes because I didn't create
an
> extension module out of my Boost code (as it's part of the main
> application).
>
> My question is: is there a way to use Boost in the manner I'm attempting?
> That is, when I use
>
> BOOST_PYTHON_MODULE_INIT(someClassWrapperModule)
> {
> ...
> }
>
> inside the application (main.cpp), is there a way to expose the generated
> module to my python scripts such that I can do:
>
> import someClassWrapperModule
> ... do stuff ...
>
> I was expecting to be able to do this because I AM able to create modules
> inside the application using the standard Python mechanism:
>
> static PyMethodDef PyInterfaceMethods[] = { stuff };
> Py_InitModule("PythonInterfaceModule", PyInterfaceMethods);
>
> which I can then import as above without problems.
>
>
> So, my question restated is: can the module created by
> BOOST_PYTHON_MODULE_INIT be exposed to my Python scripts in a manner
similar
> to the module created by Py_InitModule, given that the code for both is
in
> the same file in the main application?
>
> Thanks for any help you can offer,
> Mike Dickheiser
>





From david.abrahams at rcn.com  Fri Jun  7 23:17:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 7 Jun 2002 17:17:02 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de>
Message-ID: <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "holger krekel" <pyth at devel.trillke.net>
To: <c++-sig at python.org>
Sent: Friday, June 07, 2002 5:11 PM
Subject: Re: [C++-sig] Re: Re: sub module support in V2


> Ralf W. Grosse-Kunstleve wrote:
> > Interesting discussion. I am still wondering, though, why support for
> > sub-modules is important. What can be done with sub-modules that cannot
be done
> > within the framework of a regular Python package?
>
> IMO submodules allow nice grouping of related classes/functions internal
> to a module. Isn't this question semantically similar to the question of
> why to have namespaces like ns1::subns:anothersubns... in C++?

Sure, but you can do that with packages and separately-compiled extension
modules for each submodule. Is there some great advantage to being able to
compile a bunch of submodules into a single object?

> Just wondering,
>
>     holger


me-too-ly y'rs,
dave






From pyth at devel.trillke.net  Fri Jun  7 23:26:39 2002
From: pyth at devel.trillke.net (holger krekel)
Date: Fri, 7 Jun 2002 23:26:39 +0200
Subject: [C++-sig] Re: Re: sub module support in V2
In-Reply-To: <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com>; from david.abrahams@rcn.com on Fri, Jun 07, 2002 at 05:17:02PM -0400
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com>
Message-ID: <20020607232639.F6609@prim.han.de>

David Abrahams wrote:
> [me]
> > Ralf W. Grosse-Kunstleve wrote:
> > > Interesting discussion. I am still wondering, though, why support for
> > > sub-modules is important. What can be done with sub-modules that cannot
> be done
> > > within the framework of a regular Python package?
> >
> > IMO submodules allow nice grouping of related classes/functions internal
> > to a module. Isn't this question semantically similar to the question of
> > why to have namespaces like ns1::subns:anothersubns... in C++?
> 
> Sure, but you can do that with packages and separately-compiled extension
> modules for each submodule. Is there some great advantage to being able to
> compile a bunch of submodules into a single object?

well, actually i don't know because i haven't tried. i am going to try
to use boost::python to wrap up parts of ACE (adaptive communication
environment) putting it all together with SCons. Maybe after my first
attempts i can say if there any advantages on either side :-)

btw, when do you think would be a good time to try to use V2 "seriously"?
i am willing to bleed but not to die :-)

> > Just wondering,
> >
> me-too-ly y'rs,

me-still-ly y'rs,

    holger




From casado2 at llnl.gov  Fri Jun  7 23:38:01 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Fri, 7 Jun 2002 14:38:01 -0700
Subject: [C++-sig] Re: baking boost inside the main application instead of creating an extension module
In-Reply-To: <21b101c20e67$e38d16d0$6601a8c0@boostconsulting.com>
References: <KJENIABEMDBBGDDMCPLHGEBKCAAA.miked@sinistergames.com> <21b101c20e67$e38d16d0$6601a8c0@boostconsulting.com>
Message-ID: <0206071438010S.02517@avalanche.llnl.gov>

One way is to simply call the bpl init methods from within your main
method, after Py_Initialize() is called. 

                            ~~martin



> Please post follow-ups to c++-sig at python.org.
>
> I know there are people who are using Boost.Python this way; I don't think
> it's terribly complicated, but I don't know the steps off the top of my
> head. Asking in a wider forum would probably get you better results. It
> would be super if someone would knows could write an "embedding Python with
> Boost.Python" guide for the docs.
>
> -Dave
>
> ----- Original Message -----
> From: "Mike Dickheiser" <miked at sinistergames.com>
> To: <david.abrahams at rcn.com>
> Sent: Friday, June 07, 2002 2:41 PM
> Subject: baking boost inside the main application instead of creating an
> extension module
>
> > Hello Mr. Abrahams,
> >
> > (Please feel free to disgregard if you don't have time ;)
> >
> > I'm brand-spanking-new to Boost (and Python), so please forgive any
> > ignorance exhibited in the text below.
> >
> > Currently I'm working on a gaming project that is to be ported to the
>
> XBox.
>
> > XBox doesn't support the use of .dll's, so in order to use Python I had
>
> to
>
> > build it as a static library (of course meaning the interpreter itself is
> > embedded in the main application's executable. This has so far worked
>
> very
>
> > well, and I can use python just fine.
> >
> > However, I recently downloaded and built the Boost library, have used it
>
> to
>
> > wrap some C++ classes in my (Windows) application, but soon realized that
>
> my
>
> > Python scripts can't access these wrapped classes because I didn't create
>
> an
>
> > extension module out of my Boost code (as it's part of the main
> > application).
> >
> > My question is: is there a way to use Boost in the manner I'm attempting?
> > That is, when I use
> >
> > BOOST_PYTHON_MODULE_INIT(someClassWrapperModule)
> > {
> > ...
> > }
> >
> > inside the application (main.cpp), is there a way to expose the generated
> > module to my python scripts such that I can do:
> >
> > import someClassWrapperModule
> > ... do stuff ...
> >
> > I was expecting to be able to do this because I AM able to create modules
> > inside the application using the standard Python mechanism:
> >
> > static PyMethodDef PyInterfaceMethods[] = { stuff };
> > Py_InitModule("PythonInterfaceModule", PyInterfaceMethods);
> >
> > which I can then import as above without problems.
> >
> >
> > So, my question restated is: can the module created by
> > BOOST_PYTHON_MODULE_INIT be exposed to my Python scripts in a manner
>
> similar
>
> > to the module created by Py_InitModule, given that the code for both is
>
> in
>
> > the same file in the main application?
> >
> > Thanks for any help you can offer,
> > Mike Dickheiser
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From daveh at cadlink.com  Sat Jun  8 04:53:48 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 7 Jun 2002 22:53:48 -0400
Subject: [C++-sig] Re: baking boost inside the main application instead of creating an extension module
References: <KJENIABEMDBBGDDMCPLHGEBKCAAA.miked@sinistergames.com> <21b101c20e67$e38d16d0$6601a8c0@boostconsulting.com>
Message-ID: <adrrjr$7fj$1@main.gmane.org>

Or you could adapt something like iu (http://www.mcmillan-inc.com/iu.html),
or imputils, so that when python imports it always 'links to itself' but
uses the module name to find the entry point function as usual.

Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:21b101c20e67$e38d16d0$6601a8c0 at boostconsulting.com...
> Please post follow-ups to c++-sig at python.org.
>
> I know there are people who are using Boost.Python this way; I don't think
> it's terribly complicated, but I don't know the steps off the top of my
> head. Asking in a wider forum would probably get you better results. It
> would be super if someone would knows could write an "embedding Python
with
> Boost.Python" guide for the docs.
>
> -Dave
>
> ----- Original Message -----
> From: "Mike Dickheiser" <miked at sinistergames.com>
> To: <david.abrahams at rcn.com>
> Sent: Friday, June 07, 2002 2:41 PM
> Subject: baking boost inside the main application instead of creating an
> extension module
>
>
> > Hello Mr. Abrahams,
> >
> > (Please feel free to disgregard if you don't have time ;)
> >
> > I'm brand-spanking-new to Boost (and Python), so please forgive any
> > ignorance exhibited in the text below.
> >
> > Currently I'm working on a gaming project that is to be ported to the
> XBox.
> > XBox doesn't support the use of .dll's, so in order to use Python I had
> to
> > build it as a static library (of course meaning the interpreter itself
is
> > embedded in the main application's executable. This has so far worked
> very
> > well, and I can use python just fine.
> >
> > However, I recently downloaded and built the Boost library, have used it
> to
> > wrap some C++ classes in my (Windows) application, but soon realized
that
> my
> > Python scripts can't access these wrapped classes because I didn't
create
> an
> > extension module out of my Boost code (as it's part of the main
> > application).
> >
> > My question is: is there a way to use Boost in the manner I'm
attempting?
> > That is, when I use
> >
> > BOOST_PYTHON_MODULE_INIT(someClassWrapperModule)
> > {
> > ...
> > }
> >
> > inside the application (main.cpp), is there a way to expose the
generated
> > module to my python scripts such that I can do:
> >
> > import someClassWrapperModule
> > ... do stuff ...
> >
> > I was expecting to be able to do this because I AM able to create
modules
> > inside the application using the standard Python mechanism:
> >
> > static PyMethodDef PyInterfaceMethods[] = { stuff };
> > Py_InitModule("PythonInterfaceModule", PyInterfaceMethods);
> >
> > which I can then import as above without problems.
> >
> >
> > So, my question restated is: can the module created by
> > BOOST_PYTHON_MODULE_INIT be exposed to my Python scripts in a manner
> similar
> > to the module created by Py_InitModule, given that the code for both is
> in
> > the same file in the main application?
> >
> > Thanks for any help you can offer,
> > Mike Dickheiser
> >








From daveh at cadlink.com  Sat Jun  8 04:58:11 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 7 Jun 2002 22:58:11 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com>
Message-ID: <adrrs1$7o7$1@main.gmane.org>

My own need for sub-modules is to facilitate embedding python in a somewhat
large application (750,000 lines +) without a myriad of extension dlls to
group the various pieces of the applications functionality I want to expose
to python.

Dave Hawkes


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:21d401c20e68$ab5ef570$6601a8c0 at boostconsulting.com...
>
> ----- Original Message -----
> From: "holger krekel" <pyth at devel.trillke.net>
> To: <c++-sig at python.org>
> Sent: Friday, June 07, 2002 5:11 PM
> Subject: Re: [C++-sig] Re: Re: sub module support in V2
>
>
> > Ralf W. Grosse-Kunstleve wrote:
> > > Interesting discussion. I am still wondering, though, why support for
> > > sub-modules is important. What can be done with sub-modules that
cannot
> be done
> > > within the framework of a regular Python package?
> >
> > IMO submodules allow nice grouping of related classes/functions internal
> > to a module. Isn't this question semantically similar to the question of
> > why to have namespaces like ns1::subns:anothersubns... in C++?
>
> Sure, but you can do that with packages and separately-compiled extension
> modules for each submodule. Is there some great advantage to being able to
> compile a bunch of submodules into a single object?
>
> > Just wondering,
> >
> >     holger
>
>
> me-too-ly y'rs,
> dave








From daveh at cadlink.com  Sat Jun  8 05:34:47 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 7 Jun 2002 23:34:47 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com>
Message-ID: <adru0m$9jk$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:20c801c20e3f$220078e0$6601a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > > All functions are exported on most Unix variants.
> >
> > Though they will only know about each other if they are explicity linked
> to
> > each other. If we have to separate execution units linked to a common
> shared
> > library, they would not be linked to each other.
>
> Believe me; I know what's going on here. I've been involved in long
> discussions with the GCC and GLIBC maintainers about this, as well as some
> with the C++ standards committee about how we're going to standardize
> shared lib behavior.
>

OK, I've written out the module_link in favour of something simpler :)


> > > That's very complicated. There's only one outer-level extension module
> > > being loaded at any given time. Why don't you just keep track of that
> in a
> > > single global which lives in the library.
> >
> > Because if we have multiple extension libraries linked to a common BPL
> then
> > there will be more than one 'global' module as far as the BPL is
> concerned
> > when these extensions are imported by the same python session.
>
> But not at any given instant. Imports are serialized.

Yes, your right, for some reason I was thinking we needed to hang on to it
for the life of the module, but we don't.

>
> > > I'm a little less worried about relying on the ODR than on relying on
a
> > > violation of it. That is, the language standard says "there's one copy
> of
> > > any static data member of a class", and you said "I'm going to write
> code
> > > that only works if there are multiple copies". Of course, you can't
> always
> > > rely on things to work the way the standard says when shared libs are
> > > involved, but relying on things NOT working the way the standard says
> > seems
> > > a bit... perverse to me.
> >
> > Unless the extension library is actually linked to the other this should
> not
> > be a problem, but I think I have a better way of doing it which should
be
> > more robust. I'll test and let you know.
>
> They are linked to a common shared library, so there's a global sharing
> path from one to the other. If the common shared lib instantiates the
> symbol, it will be shared between the two libraries. This doesn't work
> right on all systems today, but that's probably going to change.
>

The new code now doesn't depend on any particular linking envronment.

> > where the BOOST_PYTHON_MODULES() could be located in separate source
> files.
>
> And the advantage to that is...?
>
> (BTW, if you're doing what I think you are, the linker may be free to
> remove the translation units containing the submodule definitions, which
> would break this scheme -- AFAIK, explicit calls are the only portable
> way).
>

I've implemented this for demonstration purposes, and no the linker won't
remove the functions as there addresses are taken by reference in a way that
can't be optimised out.

> > It might not throw a c++ exception, but it can sill throw an access
> > violation, for example, which is caught in catch(...) and possibly saves
> the
> > interpreter from exiting, though may be we don't want that functionality
> > anyway?
>
> Access violations as exceptions are outside the scope of the C++ standard.
> I don't care what happens if there's an access violation -- some invariant
> is broken and the program can't recover reliably anyway. Note the contents
> of libs/python/test/module_tail.cpp which turns these into nice
> JIT-debuggable crashes.
>

In which case there is no need to keep it there, but on the other hand if it
is kept there it has no detrimental effect and may be useful if something is
changed in the future that may create the potential of exceptions at this
point.


> > > What SEH exceptions are continuable?
> >
> > Usually floating point exceptions where we use the MS _fpieee_flt
> > functionality. Typically done in CAD packages that heavily use floating
> > point so we can correct minor overflow/underflow/Inexact problems
without
> > aborting the program. Of course libraries with catch(...) handlers are a
> > menace in this case as it prevents the outer floating point SEH block
> from
> > catching the exception.
>
> More SEH perversity. Is there a way to get the SEH resumption to happen at
> a lower level?
>

Not easily I suspect, without all sorts of rather inconvenient hooks to get
an inner try-except to do what the user wants.

>
> > Unknown c++ exceptions would have to be dealt with by the user as
> > well, but anyone doing this in the first place should be more than
> capable
> > of dealing with that minor problem.
>
> Not sure I agree.
>

If I think of a solution that will not impair the masses, I'll let you
know...

> > Is it a good idea to rely on there being a single common shared library
> for
> > allocation? What if the user overloads the global operator new function
> in
> > the extension library for customised memory allocation?
>
> OK, I hear ya. Really we should use Python's allocator/deallocator for
> these objects, so it's a non-issue.
> For now, the easy answer is to replace "new objects::function(" in
> make_function.hpp with "objects::function::create(...", i.e. a static
> member function call into the library.
>

I agree that would be more appropriate.


I've also implemented some code that allows functions and classes to be
added without chaining so we can do this:

BOOST_PYTHON_MODULE_INIT(PyTest)
{
    boost::python::def("Test1", Test1);

boost::python::add(boost::python::class_<ctest>("ctest").def_init().def("set
_v", &ctest::set_v).def("get_v", &ctest::get_v));
    boost::python::module(".sm");
    boost::python::def("Test2", Test2);
    boost::python::module("PyTest.sm.sm2");
    boost::python::def("Test3", Test3);
}

A similar rationale could probably be applied to classes as you suggested
earlier, but I haven't tried that yet.

Now I was going to send you a diff, but the current CVS appears to be broken
when I include module.hpp...

h:\projects\boost\boost\python\object\make_holder.hpp(54) : error C2059:
syntax error : 'constant'
        h:\projects\boost\boost\python\object\make_holder.hpp(54) : see
reference to class template instantiation
'boost::python::objects::make_holder<16>::apply<Holder,ArgList>' being
compiled
etc.

Dave Hawkes









From david.abrahams at rcn.com  Sat Jun  8 14:40:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 8 Jun 2002 08:40:46 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org>
Message-ID: <229301c20eea$365c9b10$6601a8c0@boostconsulting.com>

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

> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:20c801c20e3f$220078e0$6601a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > (BTW, if you're doing what I think you are, the linker may be free to
> > remove the translation units containing the submodule definitions,
which
> > would break this scheme -- AFAIK, explicit calls are the only portable
> > way).
> >
>
> I've implemented this for demonstration purposes, and no the linker won't
> remove the functions as there addresses are taken by reference in a way
that
> can't be optimised out.

No static initializations need to be performed in translation units whose
functions are not otherwise called. If you're relying on static
initialization for this, please see 3.6.2 para. 3 in the standard.

> > Access violations as exceptions are outside the scope of the C++
standard.
> > I don't care what happens if there's an access violation -- some
invariant
> > is broken and the program can't recover reliably anyway. Note the
contents
> > of libs/python/test/module_tail.cpp which turns these into nice
> > JIT-debuggable crashes.
> >
>
> In which case there is no need to keep it there

By "it" you mean module_tail.cpp?
I care what happens in my tests; I want a crash to crash in a way I can
debug it.

> , but on the other hand if it
> is kept there it has no detrimental effect and may be useful if something
is
> changed in the future that may create the potential of exceptions at this
> point.

I don't know what you're talking about here.

> > > > What SEH exceptions are continuable?
> > >
> > > Usually floating point exceptions where we use the MS _fpieee_flt
> > > functionality. Typically done in CAD packages that heavily use
floating
> > > point so we can correct minor overflow/underflow/Inexact problems
> without
> > > aborting the program. Of course libraries with catch(...) handlers
are a
> > > menace in this case as it prevents the outer floating point SEH block
> > from
> > > catching the exception.
> >
> > More SEH perversity. Is there a way to get the SEH resumption to happen
at
> > a lower level?
> >
>
> Not easily I suspect, without all sorts of rather inconvenient hooks to
get
> an inner try-except to do what the user wants.

What about _set_se_translator?

> I've also implemented some code that allows functions and classes to be
> added without chaining so we can do this:
>
> BOOST_PYTHON_MODULE_INIT(PyTest)
> {
>     boost::python::def("Test1", Test1);
>
>
boost::python::add(boost::python::class_<ctest>("ctest").def_init().def("se
t
> _v", &ctest::set_v).def("get_v", &ctest::get_v));
>     boost::python::module(".sm");
>     boost::python::def("Test2", Test2);
>     boost::python::module("PyTest.sm.sm2");
>     boost::python::def("Test3", Test3);
> }

Stripping out the qualification and reformatting:

BOOST_PYTHON_MODULE_INIT(PyTest)
{
    boost::python::def("Test1", Test1);

    add(boost::python::class_<ctest>("ctest")
        .def_init()
        .def("set_v", &ctest::set_v)
        .def("get_v", &ctest::get_v));

    module(".sm");
    def("Test2", Test2);
    module("PyTest.sm.sm2");
    def("Test3", Test3);
}


Nice, but let's dispense with add(...) for classes, as long as you have a
global which denotes the current module.

> A similar rationale could probably be applied to classes as you suggested
> earlier, but I haven't tried that yet.

Actually it couldn't. There's an interaction between .def() and the class
type being wrapped.

> Now I was going to send you a diff, but the current CVS appears to be
broken
> when I include module.hpp...

I think those problems are getting resolved, if they are not already.

-Dave






From david.abrahams at rcn.com  Sat Jun  8 15:00:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 8 Jun 2002 09:00:40 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com> <20020607232639.F6609@prim.han.de>
Message-ID: <22ba01c20eed$049c8600$6601a8c0@boostconsulting.com>

From: "holger krekel" <pyth at devel.trillke.net>

> well, actually i don't know because i haven't tried. i am going to try
> to use boost::python to wrap up parts of ACE (adaptive communication
> environment)

Oh, cool!

> putting it all together with SCons.

Doubly cool!

> Maybe after my first
> attempts i can say if there any advantages on either side :-)

I suppose you mean SCons/bjam? Each has its strengths.

> btw, when do you think would be a good time to try to use V2 "seriously"?

Now would be fine; We are within a month of an official release, and all of
the documented components are fairly stable.

> i am willing to bleed but not to die :-)

Neither is required ;-)

-Dave






From pyth at devel.trillke.net  Sat Jun  8 15:23:20 2002
From: pyth at devel.trillke.net (holger krekel)
Date: Sat, 8 Jun 2002 15:23:20 +0200
Subject: [C++-sig] Re: Re: sub module support in V2
In-Reply-To: <22ba01c20eed$049c8600$6601a8c0@boostconsulting.com>; from david.abrahams@rcn.com on Sat, Jun 08, 2002 at 09:00:40AM -0400
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com> <20020607232639.F6609@prim.han.de> <22ba01c20eed$049c8600$6601a8c0@boostconsulting.com>
Message-ID: <20020608152319.I6609@prim.han.de>

David Abrahams wrote:
> 
> From: "holger krekel" <pyth at devel.trillke.net>
> 
> > well, actually i don't know because i haven't tried. i am going to try
> > to use boost::python to wrap up parts of ACE (adaptive communication
> > environment)
> 
> Oh, cool!

unless i completly blow up :-)
 
> > putting it all together with SCons.
> 
> Doubly cool!
> 
> > Maybe after my first
> > attempts i can say if there any advantages on either side :-)
> 
> I suppose you mean SCons/bjam? Each has its strengths.

No, i meant submodules as separate library objects or packed into one.
btw, is there any nice comparison about SCons/bjam? or does anyone
offer a 4++ line comparison? I have worked mostly with 'make' in the
past...
 
> > btw, when do you think would be a good time to try to use V2 "seriously"?
> 
> Now would be fine; We are within a month of an official release, and all of
> the documented components are fairly stable.

hahaha ... (tricky definition of stable :-)
i'll take a closer look at the documentation then.

> > i am willing to bleed but not to die :-)
> 
> Neither is required ;-)

but optional &-}

cheers,

    holger




From david.abrahams at rcn.com  Sat Jun  8 15:48:31 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 8 Jun 2002 09:48:31 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com> <20020607232639.F6609@prim.han.de> <22ba01c20eed$049c8600$6601a8c0@boostconsulting.com> <20020608152319.I6609@prim.han.de>
Message-ID: <22fb01c20ef3$37cb0910$6601a8c0@boostconsulting.com>

From: "holger krekel" <pyth at devel.trillke.net>

is there any nice comparison about SCons/bjam? or does anyone
> offer a 4++ line comparison? I have worked mostly with 'make' in the
> past...

No, but as I understand it, Scons is focused on getting the build
infrastructure right -- only updating the minimal set of files, etc.
Boost.Build is focused on interpreting high-level build specifications for
multi-target/platform/compiler builds; in particular, a project that builds
on platform A should build on platform B.

-Dave






From daveh at cadlink.com  Sat Jun  8 20:29:53 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 8 Jun 2002 14:29:53 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com>
Message-ID: <adties$vis$1@main.gmane.org>

Here's the new sub-module code

I've put in the support that allows:

BOOST_PYTHON_MODULES(a1)
{
    boost::python::module("PyTest.sm.sm2");
    boost::python::def("Test3", Test3);
}

where a1 is a name unique to each BOOST_PYTHON_MODULES declaration.

Yes, the support does rely in part on static initialisations but as these
are in the same translation unit as the python init##name then they must be
constructed. If init##name is not called, then it doesn't matter if they are
not constructed anyway. The one thing I have avoided is using any memory
allocation functions in global static initialisers as I've run into problems
when that occurs on occasions.


> > In which case there is no need to keep it there
>
> By "it" you mean module_tail.cpp?
> I care what happens in my tests; I want a crash to crash in a way I can
> debug it.
>

No, I mean't the pre-init stuff I put in. This discussion is moot now as I
have changed it so that a module is initially constructed so the user can
add to it directly without initially creating the parent module.

> > , but on the other hand if it
> > is kept there it has no detrimental effect and may be useful if
something
> is
> > changed in the future that may create the potential of exceptions at
this
> > point.
>
> I don't know what you're talking about here.
>

No, that probably wasn't that clear, but is probably not relavent with the
latest code anyhow.

>
> What about _set_se_translator?
>

Doesn't help, it turns SEH exceptions into c++ exceptions at which point
they become non-continuable which is what we are trying to avoid in the
first place. Also I believe the SEH frame is corrupt after the c++ catch so
it would be difficult to rethrow an SEH exception at that point that could
be continued from it point of origin.

A few years ago I spoke to one of the VC developers about this issue and he
acknowledged other developers had complained as well. Apparently it was
going to be addressed in the next version of VC (VC7), but I have not had a
chance to look at VC7 recently to see if that really happened. At some point
I'll take a look and see if anything was done as there may now be a simpler
solution applicable to VC7.

>     module(".sm");
>     def("Test2", Test2);
>     module("PyTest.sm.sm2");
>     def("Test3", Test3);
> }
>
>
> Nice, but let's dispense with add(...) for classes, as long as you have a
> global which denotes the current module.
>

This patch doesn't do this yet.

Dave Hawkes



begin 666 submodule.zip
M4$L#!!0````(`/Q4R"Q?JJ\E5PT``#<W```.````<W5B;6]D=6QE+F1I9F;E
M6WEOVS at 6_[L!_!W8%DCE6#F<JZG39-OMF46/H$TQ&$P'@BS1,:>R:$A4$F_'
MWWW?XR%1E^VTF=D%EBV<6"+?\>,[R$?F+ [IS8 ,.4_%]G0FQCS>GO PB^C6
M>#KMK)W\?.NL?7KQF8Q81 =D.[A*$\[%MF)H?]:8NU>=M82*A-$K%E^2!'ZD
MC,>DO]4_[*R%;#0BFQG93/ [L67>W-QL4^C>`?E7%I/=G9U=LKLWV'\\Z!^1
MS1UH]Q397J_7.O:H&-O?'^P=#@YVU-C.VK-G9'.W[QZ1'GSV^^39L\X:(=-L
M&+%@@+]"$[,I#>F(A%3X+!H,%&5OZ*>4X,<Q] /AL:MZY00\3 at 4)QGZR06)_
M0KOZ-;:!'./(Q^3['"0G"T:2$_+ at 0==TJ at PWC[];[\DE%9Z6D,4C[G0W3U-X
M-$T83_0+9T.,6=H]-L/F4@'YZ_8V>1Z&A$9T0F.1$L&)&%,MG>ZCOJP3(.L+
MD=1D=LGY[./P#QJ(#>2!$!_TW4/2.]@O(-8-!9$"2DIJM)S&P4#-(\#M?Z/>
M*(L#`4;DC&*7C/TXC&C21>HY);"X+(F)5,T\1W2UDBEP8$$N^V45$@.FC:4F
MJ89Z at 9^*IWK\J=,`<YUF#C$B/%=V`A K3!X?(29'A^[N@<+DN[$WB0E.\V#@
MAZ%SD^M9T;&G]1-T,HU\0<G3(/+3E%RX1/WR3Z"1FB]O>132Y V-:>(+GIS"
M0!9'+*;DBK.0("?9T7MZX:J!U1%$SO0Z"1 L`Y32=3"H:[\E2787"/HZKDH!
M?N:@)2E6QIY>QV04K\@4*:A1,,3BW<C>8/.)IEDDWBJ[NH5,;GED;IFW%[6P
M:IQL[9'S.3HD=DFG?D#+GM%9.VO(`2I(;5LQZK^4#YH%:<\->^74L$=J*M32
M0S.+>_M6JM at 9[![:J6*O(5.TD%F2-?H[Z+[P>:2\%_Y7)HI\MYXH7J5'BB\\
MDJ-[RA*MF'(LK=:X\L>/GR^\\U\OWG[\X+U\]>*=C8\)'GG>DFEM%P7<A9B[
M4\1<:=#M at 3N!-*></(\Y>7 XGUU (M2!G4!00MO\(P,*&21"S!*8*!^EDE1E
ML(>O'*">1\12/);J;M13UW$1OX$71CV2CGD6A2"H'T4S, at 1@$W8%/@UI(Q.$
M"7(MWP=\,F4!^CH*QL#O94+S,8<0-I(=_;0LB\&F)(/U^SJ9L!R6(E]^4D'9
M1_!H0F.869TUS]6<*Q*$2^1 9#3\8<8BH6GH6(/8JSY.5TV"3IY[:&.]O4-W
M?Z\RD8BL- ^GF#AE+QY0ZNJ$8R :M$._7L7>`X*.E7=&9*)?FV>:ROGL/04M
MPY?0A<5,,#_R)O))^EO_=QE_]2S6[%L'R=QHK7"IL"_LDVRH]=* E$+HAR_O
MWC4E;DU$+Z#PAY6(>SE\Q5PC?C"]3;38R+D/3"=^,M.=MP`KR.U6'VSE/L!V
M4N4I>10X+UIRE(FU"E\"PXH'+:K8W9L$+%&XS0K)[E<E:@<9R\AP4A:1M+K9
M%"NFC(;9C)6E2Z-XMEAE7J6%VO(4BT;_/Y%BC2 +ME^5W1>IJ; DQ9J.]W:?
MD/?^+,^Q>[N#_2?%=JRS+,?F=);DV$.W?T!ZA^Z!WC4\9*,8=V+O/[[\\NZ5
M=_;A[,)[^<MS''^P^\1[>WZ.G7#!A@%U8:^.C$F5K#)-^- ?0EZ9\"L9Q?V8
M0R"'=1WU825,Z!7DD PS#XS]P6S?L8)A:U)'@+R(I9 B&F*DV9#*..!L0(B2
M^;7K="O6GY-QK*UF[9T>3HKD+ G3&QID at BJB%;^KTJ at F$/W80_LMI#*,IFS4
M)B@$>GHC[+0QG^L%?#ZO)=34)'_6^^EE[2O0D<I)AHIYZCU\J*+1\;+A>4,Z
ME6UJI3I0:,0BIX&;8K98GH[>N(!):\-O4%W:MS+HAT!18W3^21O^ZR\?7JP(
M3J,T,H+F$BVCH&A\7]9I2?NJC6,9PB,.*S+'@O/6--0FN[;F8\7L-- P^7 E
M<S$T;$AO:V^KZ6(Y^U;ANS:-N;$F7 $K0PD=[Y>S#WN[7?+GG\4C[\6O;^"Q
MYW55)K0,J\T"%]H8,"<UP[HE"JC #UFUU5 .""\4UA</7CP at GA?2($JG-'#"
M**(W4YZ(;B%HL]$CC3LP<%D/K$RHJ@!X]":@4UGL6J_CE</58A2+:5C.C(10
MEWFKE*NUA7,KS4=O1OM[I'=PY/;W\_TRFA6+ at R@+*7G:M%SPV8UGD<4EP^D=
MF..J[2Y,;M5V%RZR:JNXP5_:[L)=5FU?]=94ZY97H8EW/CN;H'=[[[@?OIP!
MJBQXK\*XW *X1/]X??;N%=E8`7##:TFTN)-F>/T=.'ZUCBI:\DW%*YT%Z+ID
ME1#VE_!J"'78?C;<K=+N(JRNVI:$7UD_.L028._Q7G[Z\I#02%8-[R"8WD60
MO(O at 5PUJ/^*8=Q&L_K]RNZZ/1&R8FMR=)H'>YV\%?U=9I)U_>S7D<;D:\IC8
M0F,AI)WHPB,&H(OECP6CZU6/0[OJ\1C72#WXA/?27;>WL78'XP-4018LKGGR
M;4L[\,(EE&4<>OG46VF *=&<MG-0Q>IM<S1K>G=^^"!$#K;J*KI6`NJ?Q;*R
MS%)*?!+3:Y)FP\V)#OL\,45#/X80`#L at A(G'=$L-OI" L2 at B?I1R$B04SP7\
M> :[QS3%OE,_D:?=?L0EP)1<^S,<G>BJM@?\3 IJ.NXN:N ;+"X5P=WR$<<4
M]I:=XG"0J0- <G)"[%HV-G.X8L0E83:9S,QAPC438ZGN9"IFQ<F#-5Y#8NKX
M/4V3%4A>^0GC64J84.>[("L5P5;'*JU*7+3BY 2E5\?<&HHNK)NRI-+''F,8
MIR*$;39X(<";JMJOC%,N&99*O("'>KV5LG]CS 9@=BJHF-,F2%I^%@F#B,11
MG>S =,=<@(U,IQ&CH34\-6<"%4UT.;I!7/@)DNBZE3?EJ;.3=QOQQ&&Q(!$0
MW#D^[O6B;JF4#<)"7 at VEM%C6*HL:R^>/0BX$#1_I4[-"TF81H#<*`0PU3LC 
M>;3UR%72%9<Z%'_Y$ %!7OXPY5$&Q at 3/&+JL.C3#5Q&-+\&B$#E*PQ)F,">&
MZ_V3LEPQ<K2Z8C-]-T\4\XI R$S;3 D.=2P&42Z@:4I#5ULE/APE?"+'*=,J
MTR/FL"UAEV,A#]&MX)!:G8=F[HV%94/0PY%"ND;L$GZ@>:0LL'S%1G'6LJJ3
M3SX%"*]HI&6T5:N,M."L&K=%W(\B?@U.GXYAK1MD!4&NSS!3>'T-4$(,"+E^
MZSQ I=3O#YH(#U<S?TN.8$R#;U)%>9*B+%?I''"8Q4 8C>4K7%82'R8P$15:
MZJ&C)-C"XUD8YC3+H=V^*@X at 5PHNZAPNCYVU.<(FPS\E$Q_<K3PU(:<J3,B,
M0694N*3(#A!%QA!2&RA68R(&V/.9AQGJO9J%AD%-3>81=:M()I/3'!P/[;+;
M=5<D5,DX*X\#R0<#2.V)/!KW`I[%H at 8Z-NEFTK&H(-G4NA&6YXZ&4:MEA at H?
M*STAE\N(#_VJ4\$LP?2 at Y0\IQ. ,!,-;/4TR2/NRCGE+(M1TG5O?Y\J6&_P^
M!L_3OH_1R;?"3;VS2&88H&0:0 2O:,)&L])"I1A.^*CD6=*E<!2&_ at IM3,^&
MA+4Z:? 94P;QWOKI<R&2SS)X.^7I4;ZTJN6L8+S=5G]\#NLT$(,-,1-IC5/4
M5*H[]E.85AJKB6V at T*!T[H5:T3=46(JNK!.VGT,%VPK(--F^O&*A at J"\*Y,K
M at Y=NFN)>,QDT.8J'3GAW$Q<,_B6$OE0TYT_3\(Y#SO L_9P-U:V2!JPU)+:L
M1IX6F*3+".('ZN04'$:-=0M'?H378G!AUS3AV)H$26A*13UIS2O?@?TUV%2+
MQZGP\8^ZU]QOU;W5L&/N(LRQ7H*J3!*VY1$8@)> 0A-01UF$@0X68=(/\"F7
MSJ\V7TQO3,S:J37H8+.7VTA7Y=7RNF>G6/.T69+.A?8%X%NYXP\D1=7J/I1K
M<>OLJ-J/YDC5;I,I_5 M^"TCTRO4/.JE&/;00]ED0D.&&+>Z9NZ6GTM![2?C
MU-(@=0M:[8ZRBFM2F4_'_I79V5<V!X+K-4;5^&K+BR79T&8NG14X),:PTU((
M*"_1E^YXAN FWRK;'#^\\O$F((>$KW:KW)Y=M2WKG>2[I1[I&PI&4*"B]_#2
M>&3X+%G5V)>7& EE\HZ*"F4\,8%'D]$TRG A+WVM0A\*ZWBN#L2M+ZU_RS#(
M;P0ZUI%!V>GK9J9W_55WM"BXS=ZFM;&X5NLR2+I&V:U?*L5$)6M-\_QT\E#^
M>4)__XF[OU_]^X2$7WLT27CB^1$`&\X\DW8T`75EHH3?LDNDG:("U'CO$JQY
M?<*L2;)Z;)19U=2S:.NI;[O:V41\?2%U-=3BT'2+%];<1&W)CLMR3&V52D6S
M$L_*#/[V.U#[#O\@8>G_L#@WMX-L\?7UAX8+$<4-)TOV*1L!Y?PFDBS0G*QR
MC6E!%R!0^=L,VS at L$?,+&I9 UV,&9KR >GGEL:CGYBEHURTOCA:+O9"8N9.%
M9.8-AL/R6V!U31<07F!(AB)X2]1L3?!"PXP5Y_G"/Y4PYXF=M?\`4$L!`A0+
M% ````@`_%3(+%^JKR57#0``-S<```X``````````0`@`````````'-U8FUO
?9'5L92YD:69F4$L%!@`````!``$`/ ```(,-````````
`
end







From daveh at cadlink.com  Sat Jun  8 20:32:33 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 8 Jun 2002 14:32:33 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com> <20020607232639.F6609@prim.han.de>
Message-ID: <adtijr$vqr$1@main.gmane.org>

"holger krekel" <pyth at devel.trillke.net> wrote in message
news:20020607232639.F6609 at prim.han.de...
> David Abrahams wrote:
> > [me]
>
> well, actually i don't know because i haven't tried. i am going to try
> to use boost::python to wrap up parts of ACE (adaptive communication
> environment) putting it all together with SCons. Maybe after my first
> attempts i can say if there any advantages on either side :-)
>

I've also been considering using SCons for a large project, it would be good
know your experiences if you proceed.

Dave Hawkes









From david.abrahams at rcn.com  Sat Jun  8 21:00:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 8 Jun 2002 15:00:49 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org>
Message-ID: <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com>

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


> Here's the new sub-module code
>
> I've put in the support that allows:
>
> BOOST_PYTHON_MODULES(a1)
> {
>     boost::python::module("PyTest.sm.sm2");
>     boost::python::def("Test3", Test3);
> }
>
> where a1 is a name unique to each BOOST_PYTHON_MODULES declaration.
>
> Yes, the support does rely in part on static initialisations but as these
> are in the same translation unit as the python init##name then they must
be
> constructed. If init##name is not called, then it doesn't matter if they
are
> not constructed anyway. The one thing I have avoided is using any memory
> allocation functions in global static initialisers as I've run into
problems
> when that occurs on occasions.

Sorry to be nitpicky, but I don't like that interface. Any interface which
introduces new macro cruft /and/ requires that the cruft be in the same TU
with BOOST_PYTHON_MODULE_INIT() seems like it provides too few advantages
to offset its drawbacks. Why not just have the main init function call the
other init functions?

> > What about _set_se_translator?
> >
>
> Doesn't help, it turns SEH exceptions into c++ exceptions

No, it doesn't have to. It just lets you hook SEH throwing at the innermost
level.

> at which point
> they become non-continuable which is what we are trying to avoid in the
> first place. Also I believe the SEH frame is corrupt after the c++ catch
so
> it would be difficult to rethrow an SEH exception at that point that
could
> be continued from it point of origin.

What catch? I'm just talking about installing some kind of handler with
_set_se_translator so that these continuable things are dealt with instead
of turning them into unwinding.

-Dave





From pyth at devel.trillke.net  Sun Jun  9 01:24:57 2002
From: pyth at devel.trillke.net (holger krekel)
Date: Sun, 9 Jun 2002 01:24:57 +0200
Subject: [C++-sig] Re: Re: Re: sub module support in V2
In-Reply-To: <adtijr$vqr$1@main.gmane.org>; from daveh@cadlink.com on Sat, Jun 08, 2002 at 02:32:33PM -0400
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com> <20020607232639.F6609@prim.han.de> <adtijr$vqr$1@main.gmane.org>
Message-ID: <20020609012457.J6609@prim.han.de>

Dave Hawkes wrote:
> 
> "holger krekel" <pyth at devel.trillke.net> wrote in message
> news:20020607232639.F6609 at prim.han.de...
> > David Abrahams wrote:
> > > [me]
> >
> > well, actually i don't know because i haven't tried. i am going to try
> > to use boost::python to wrap up parts of ACE (adaptive communication
> > environment) putting it all together with SCons. Maybe after my first
> > attempts i can say if there any advantages on either side :-)
> >
> 
> I've also been considering using SCons for a large project, it would be good
> know your experiences if you proceed.

i am also subscribed to the scons-list so we might meet there later :-)

    holger




From daveh at cadlink.com  Sun Jun  9 04:17:36 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 8 Jun 2002 22:17:36 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com>
Message-ID: <adudrt$103$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:243a01c20f1e$cf832870$6601a8c0 at boostconsulting.com...
>
> Sorry to be nitpicky, but I don't like that interface. Any interface which
> introduces new macro cruft /and/ requires that the cruft be in the same TU
> with BOOST_PYTHON_MODULE_INIT() seems like it provides too few advantages
> to offset its drawbacks. Why not just have the main init function call the
> other init functions?
>

I realised that this functionality can be easily split into a module totally
separate from boost, so I'll do that and keep it for my own use where I have
dozens of source files in a single project that I need to create boost
support for. It just saves creating and keeping track of a large number of
initialisation calls.

> > > What about _set_se_translator?
> > >
> >
> > Doesn't help, it turns SEH exceptions into c++ exceptions
>
> No, it doesn't have to. It just lets you hook SEH throwing at the
innermost
> level.
>

Initially I though this would be a problem as the handler that this installs
has no facility to continue in itself and if it returns it will just pass
the excepion upwards again...

However, I did some tests and found that by catching a structured exception,
then rethrowing a C++ exception, catching it and then rethrowing it within a
c++ handler will rethrow it as SE allowing it to be caught by an upper SEH
and then continued without error! Unfortunately I can find no documentation
that says this should work, but then I can find none that says it shouldn't.

I've attached my quick and dirty test project so its clear what I did. The
end conclusion is that we just need another catch prior to the catch(...)
that will catch a specific seh_filter class that we define. Then all the
user has to do is call _set_se_translator themselves with a simple handler
that throws the seh_filter class, rather than set the handler within boost.
That way we avoid contaminating boost with MS specific SEH code. Also if the
user is already using _set_se_translator they can integrate their support
and boosts support.

> > at which point
> > they become non-continuable which is what we are trying to avoid in the
> > first place. Also I believe the SEH frame is corrupt after the c++ catch
> so
> > it would be difficult to rethrow an SEH exception at that point that
> could
> > be continued from it point of origin.
>
> What catch? I'm just talking about installing some kind of handler with
> _set_se_translator so that these continuable things are dealt with instead
> of turning them into unwinding.
>

see above.

Dave Hawkes



begin 666 ex_test.zip
M4$L#!!0````(`+>NR"QM,:<FP@,``,D(```3````97A?=&5S="]E>%]T97-T
M+F-P<)56;6_;-A#^7 /^#[<.*^34<5)G&(9M*5#8<NNAL0,W?4&W at 6"D4T24
M(06*BNT4Z6_?D90M6=V&U8!AZ7CWW-MS1Y^<`&Z8Q=*.DJ* 7V"*F5!8 at LT1
M4%FSA4(+92'3QLL2K4HM$7A12)%P*[0:]7LG)_ 2%1HNP6&!U>!,N4JAX&4)
M)>9D;71UDP,9)7DT&HT&WF[*[Q!>\?4G<OKS\>^5.AZ?GH[[O7[O^]3'`N_G
MB[,Q>QV_6+ 7BRF[H =_+%0BJQ3AM[50J5Z7H_QY6UK:5.B.#/..("L$(G:U
M-DEA.[);O-5FV[66F@?%?L\5R:?FJQD-?NWW[K1(=^7U`J?#6))B(B%X9CG5
M2**)V.QR'L<Q6\63Y6H*1_YT#Z)PS:SAJI3<:A-5JA0W"M,AQ!\F\>75?+E@
ME\OYXBI>O3ER1KZRB72EMSFWL!92PC7Z'JP5O=K<=]/UI8Z at WPOZ)&*9D!8-
M?'[P4"'N6RY4Y!ZXN4F&D.3<'+GGNS_^HD9^[O> /N2U1 M5X=&;B!LG3HN1
M#GW;&1TFZ%*HX;B4>DU%3+!P7"MK!**A-5IF1?2%Q1?L8[Q:3N?OYM-X".QB
M\IYD.PS&'!/K^&I071E(GCX]C,I]. at WLFI!3H2I^3?S?1W0(\D#^PE'$Z at YG
MTD8OT<8[@XE.,1H,H2V;*YJO6S]-[NB0&X,!=2+ &[2547!*L3WLNMSDX6?O
M:R;NN],I1)N9(?8PF at T#!IVZ);P at _^B+42+D2,]NQ at T>>V:!L ?Z at IBG*YFZ
M;8'<!"Y2#DY7J!M(-0V](Y:E;U at Y^[(:3+1)2_BN0?1VG6#='NE$F>L"LTK*
M+:PQ,%]I1ULC[D+,C79AR'<6/2YS'Z;3NPXZ?ZK';0:T"N^]'[3C6:L=30*A
M&21*48IKVHT6*:14W E:'==;N$>CNSMBWZI45XYE&SB'9T/8TL_.=7UR3Z(-
MG,"V%N\RF8D-IFX`G<(/-Y3&$.X'K0!=[[)B1YEA:S\0!1/J9R=$M\OK/$/$
MW[S$ZJ1$%OGWX^<37I4X^DAH4^_*-_!1??C&<EN5K=,Z]T>-_0K+2MK1S(\,
MG)\#FQ7A95;\]&- HXH<*+_CLL*1._=/#G3D81\`)7'Y_Z&?C?\;_6S<0L]:
M\,&(+A%:?=&3Z!^L:>Q/AU"*>]3=4,+YP,,=$*_9_I/EXFJ^>!NS^$,\>>M$
MGA=>_2OEH!.S5W2=OHY7.W)X>OS;WO[V:ZA]*83MP/U]XQ96,R6E]ENBOI_J
MW:" Y\A3T-G!OP4'%I":%175W/X;4$L#!!0````(`-2NR"P(3BV+7P0``,41
M```3````97A?=&5S="]E>%]T97-T+F1S<.U776_B1A1]CY3_<.OM0[+:`H$J
MVL:E$F##H at T?PJ3;K"JA\?AB9F-[K/$X(?^^US8F4 +Y6+7:AT at 89N[<.7/F
MS/7!?@<#P95,Y%R#A;<8R!@5.#KUA(2QDM^0:^B*`.$7&+(0FP8N9QH3;5!@
MS/@-\Q%&=Q&JYN^__G%\].X07@\ICVGTH)V*P,MQ/T!7JI!I^!-5(F0$YY5:
M+<-Y_QZL$0Q'4["M_I2ZQT=9>-J:]*;78QN,+R)JU.%D^?'\%#HR2B21;,5Q
M(#C3!&1 ;5D[JS6R:9UNK[GB3;2+B1:ZJ7]\]-/ =IQ6SX;I0B1 GTAJ8'#+
M`N%!R&YP3B0K,)7 at YIQUEA:OA$D3$?DP'+0^VQ\VH-($*0_!7L92:1BL4(#+
M,&21!]FETFACQD8S1X/J'$JE*\3"J#R>?"U3X"R")$8NYO=$G,MH+OQ4Y1K 
MW0*C;*EHS7-CLGL/'A'+QS*Z(:.3`](*:&86*/D&(B()Z)P`ERR,`[QX"?4,
M<5TVV_(;C^.,99((-Q-L(07'!.:T]/;&F-I'8F>E"0;($C3 at Q*4?+]O<D[5S
M>@BPH/Y:N**,V^B+J+S!LL!X,AI#*PCDW1A5)]^KA3%&'D9<D 2U=9+#^2R;
MF-V.8!A;\4O)63!F>I$/=,;C)@\JN,3CHXG3:2I>M(E-OPM at _'Q"1W-J0+.Y
M7[6";KY N^78<)7@;-#M;/!9AW-=9I?"54QM4\Y31JF.4SVSA +C`7TSHQ]I
M5"%Z at CSB4-Z4*1]72 ]#N\P.DSK(YQE4=EBT+*O at 1[I#-9*!]"54OS2 at VOL+
MJJ,Z5"TJE?ZP43?RYM"RVU>]HCWKC(;.Z-)>]0;MCD/-Z]1(M,?FR\J">ET+
MJKQ<:&N-@?6?K9-OB(H'J@$9ZEFM]AM4O35FF74 at H>UT&O6FF_#,3(OZVT#.
M1\N-K$>V at Y?]X6>"(!>ZV9E?C,$-J at B#1KT2"#>S7[5J^IY8M>Y$E,12!GF'
MC,T+_-4(\VY97*8E"PQ*'+J+'UHLU25\*KPBZKF\3* FCU>='XO-NDB2U$WN
M$XWA!5]95)4<?T'>?M%O?#PO97U3]"DVSU>4C-:^=.PGS;;\,WRUU9[MM]H2
M^[#1/I;U/3;[0.@`ER=IO,1BP\+^OO;)`KU_6^#L%1;8^PK[_=;[?U;=X[ZS
MI]QW]N:^/P:;0U[A9<6^;1E0C3U7W\=XD6"LWRSYN6R^4^;,IX<6V?3FPWEA
M/D6D>-;>_XR\+^/!SPK,GI)I#(8C4\4Q?_]--FW?PCE+`SVC`7)&,'@<F]SD
MRZ6IN$GO:J8RI1>8 at JY%_,UTF=[ W@#-()W1U:1C-RM_E^]B!/;R1_^7_W\Y
M5^WII-69%HYY3>9XS3.CVU'9IC?++<Y%*)=H1[%/R#Q2Y$G%%B1,;"Y(L45H
MBB at P#L-.,'GF40 at N39XJTPUCDPJ9#J1.ES9=$9G*3TQ?S,UOL4\7YE_[%MYW
M2A/:X `K>JD/:%.69-%;OSW^`U!+`P04````" !!FL at LC@F#W=0````9`@``
M$P```&5X7W1E<W0O97A?=&5S="YD<W>UCD]+PT 4Q.^!?(>Q7C44K!Y"(Y1F
M4X,U&Y)@+ at 79ID^)C7UA=_T#(=^]K7K1BPIV3N_-,,/OIJXT&[ZW".F%&FY)
M([?/JYI1LEZ;5E6$J&[H!!'K)V5Q2]K4O,&%-QRZSC'*29;$R<Q'*)'(`B*,
M"\@,H9B+0J"XBG.4,KO.T\E4((KGXLAU=L7_U7XRU?Q(E?4QH+<[2\8.`F_Q
M>7HKT^(4J:K6ZH$@7S>D at _'H\KWW80;C\]W;=9WK]'W_)1A]"WZB^:/VD[.&
MEZKQ?\=S=GB>+5!+`0(4"Q0````(`+>NR"QM,:<FP@,``,D(```3````````
M``$`( ````````!E>%]T97-T+V5X7W1E<W0N8W!P4$L!`A0+% ````@`U*[(
M+ A.+8M?! ``Q1$``!,``````````0`@````\P,``&5X7W1E<W0O97A?=&5S
M="YD<W!02P$"% L4````" !!FL at LC@F#W=0````9`@``$P`````````!`" `
M``"#" ``97A?=&5S="]E>%]T97-T+F1S=U!+!08``````P`#`,,```"("0``
"````
`
end







From daveh at cadlink.com  Sun Jun  9 04:22:04 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 8 Jun 2002 22:22:04 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <20020607173404.91351.qmail@web20204.mail.yahoo.com> <20020607231102.E6609@prim.han.de> <21d401c20e68$ab5ef570$6601a8c0@boostconsulting.com> <20020607232639.F6609@prim.han.de> <adtijr$vqr$1@main.gmane.org> <20020609012457.J6609@prim.han.de>
Message-ID: <adue49$1bm$1@main.gmane.org>

"holger krekel" <pyth at devel.trillke.net> wrote in message
news:20020609012457.J6609 at prim.han.de...
> Dave Hawkes wrote:
> >
> > "holger krekel" <pyth at devel.trillke.net> wrote in message
> > news:20020607232639.F6609 at prim.han.de...
> > >
> >
> > I've also been considering using SCons for a large project, it would be
good
> > know your experiences if you proceed.
>
> i am also subscribed to the scons-list so we might meet there later :-)

I'll have to see if I can get the scons lists on to gmane, as I'm not
currently subscribed and my inbox overflows from other lists... -;(

Dave Hawkes









From david.abrahams at rcn.com  Sun Jun  9 05:13:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 8 Jun 2002 23:13:42 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com> <adudrt$103$1@main.gmane.org>
Message-ID: <24f201c20f64$394821d0$6601a8c0@boostconsulting.com>

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


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:243a01c20f1e$cf832870$6601a8c0 at boostconsulting.com...
> >
> > Sorry to be nitpicky, but I don't like that interface. Any interface
which
> > introduces new macro cruft /and/ requires that the cruft be in the same
TU
> > with BOOST_PYTHON_MODULE_INIT() seems like it provides too few
advantages
> > to offset its drawbacks. Why not just have the main init function call
the
> > other init functions?
> >
>
> I realised that this functionality can be easily split into a module
totally
> separate from boost, so I'll do that and keep it for my own use where I
have
> dozens of source files in a single project that I need to create boost
> support for. It just saves creating and keeping track of a large number
of
> initialisation calls.

It's a shame that we couldn't get something into the library. However, it
was starting to look like getting something I would be willing to support
was going to be a big effort for both of us. At least the library is doing
its job: it was meant to be an extensible framework. Also, I think the idea
of dispensing with module objects altogether and using a global current
module state is a valuable one, so that's a contribution.

> > No, it doesn't have to. It just lets you hook SEH throwing at the
> innermost
> > level.
> >
>
> Initially I though this would be a problem as the handler that this
installs
> has no facility to continue in itself and if it returns it will just pass
> the excepion upwards again...
>
> However, I did some tests and found that by catching a structured
exception,
> then rethrowing a C++ exception, catching it and then rethrowing it
within a
> c++ handler will rethrow it as SE allowing it to be caught by an upper
SEH
> and then continued without error! Unfortunately I can find no
documentation
> that says this should work, but then I can find none that says it
shouldn't.
>
> I've attached my quick and dirty test project so its clear what I did.
The
> end conclusion is that we just need another catch prior to the catch(...)
> that will catch a specific seh_filter class that we define.

This is neat, but unfortunately it requires the cooperation of everything
in the call chain. If the standard library uses catch(...), as it is likely
to in, say, uninitialized_fill, without using your seh_filter trick, the
unwinding actions will still execute.

However, I think the enclosed demonstrates that my little module_tail hack
is /ALWAYS/ the right thing to do ;-)

You can also run it with an argument to see how it invokes JIT debugging
for unhandled SEHs.

-Dave

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: foo.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020608/79b1ff35/attachment.txt>

From daveh at cadlink.com  Sun Jun  9 05:29:49 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sat, 8 Jun 2002 23:29:49 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com>
Message-ID: <adui3b$57j$1@main.gmane.org>

OK, here is the diff with the initialisation code stripped. I've also
changed the class_ so we can do this:

    class_<ctest>("ctest")
        .def_init()
        .def("set_v", &ctest::set_v)
        .def("get_v", &ctest::get_v)
        .add();

I did wonder about doing it in the constructor, but then it would possibly
break any current code that currently uses boost V2.

Additionally I looked at breaking up the class_ chain in the same way as the
module, bearing in mind your earlier comments. I believe it is feasible if
some of the class_ member functions were virtual in the base and also some
of the templated member functions were moved to the base. That may muddy the
implementation, but improve useability, so I'm not sure if it is even worth
attempting?

Dave Hawkes


begin 666 submodule.zip
M4$L#!!0````(`*NYR"R3$L[(L P``!4T```.````<W5B;6]D=6QE+F1I9F;E
M6GMOVS at 2_[O^%&P+)':L/&RG2>ML>NVUVVT.?01M%H?%=B'($AUK*TN&*"7U
M9?/=;X9#2J0>CM-D=P\XMK =B3,<#F=^,QSR) [XMS&;)(G(=A?+;);$NW[D
M";$S6RPZQW=OG4^O/K-I&/$QV_4O1)HDV2Z-9GY61W8N.BG/TI!?A/$Y2^%+
MA$G,!CO#_4X03J=L.V?;*?[)2FFWM[=;)O+@"?M7'K/AWMZ0#4?C_</QX"G;
MWH/V0++L]_MME,]*RKW1># <#YX09>?%"[8]>#9R#ED?OX8#]N)%AV$3/)IN
M,"\(W$6:+'B:+;O^S$N9G\0BVV*Q-^<.3&I*#S;8])QGO:/OI[4?"&+6V2[9
MP2,OR]*5G("F?WL*HMG=18E9EK!Y$N01-SG!BRX]91OS'KVYHB]L\QWL@%U[
MY4-8^SR-V58V"X42Z[H^EI^G*8^SEC'K0\D5'H]IB<=C["1'T#-O'9G!TBS2
M\,++T(IW6;9<<$'+A3\#T$@R^9W[F1B/I>6X8<#TCZ/.28./D<Q_BY.50[=Z
MV># \K+!`3/DK;E9^6ZEGP'3FI\9I*L=;3APGK(^? Z4FRWR213Z8WL5`K#:
M,!J/B:T[\01G^%&X`[WH2OME:-MDU3UZBVTL";KR*;NZ5I;10L>.V:-'AMV:
MQ.JI87\,7-55HH7Q-.GVMI^#GX&CATFJ7E0LDFR/2:M_"5;/(SX'DQ=H_MF,
M:],W9#1<MR*LPTZ7'Z69;@%_5.J3 at 7/ ^D_V"Z6JAB)(T20?HJTXS]S[RMUI
M'OL96$QW&CMLYL5!Q-.>!C)LMC>I&2D_%L ]] NISZN*J/NOXD:$KN^)[ =%
M_;S;H-HZQU[IT==H$J!5J8?#IZB'IP?.\(G4PU7'4 .N*('%-SVU"DC(*65\
MOH@`(-@/TO'9F4,(P/X)]$+_\3:)`I[^Q&.>>EF2/N_TPS@*8\XN$H ,'(1@
MXX<SA^BJ!!KE?5"/4 at W-;CRNSU="J]]K$_%-7!D?7*@!\-_$;!JO-1S2$PT0
MZ%&;QM7J^,1%'F5OR7+6%\:Q"0O3NZV,I='"PDI7N[Y&3\/W8N'YW+;Z1B G
MR-DU$.=O`?5F,5H!?F3A^XA5Q:]A?#/_!_L&WN^-AP<FWH_J<-_"Y88<:P^]
M$SZ?2N?L5)>'71E/:"#K$0T*CX"V3W9G( 7F,-I3/W[\?.:>_G+V]N,']_6/
MK]Z9:B%4T%%'AJ0ARC4$]-PKT%-:;CL`6[E328!N>KH\@R"F\)D!U* A_IX#
M at QR"&&(]!KE-(3G9M"Z^Z0+O(H4SH57.<JL>>\SD#8&,B5F21P'(Z$71DDVX
M3GD`^_.,A1F[E._]9+X(?71G%"H$UY8AR<- P,*I[.@)2Q"M%4L`X_<&FX=:
M(46X^T0 at ZZ'2..1YL)(JZ)W2&A,#E7F!O&CBDSR,,F*AL"0MDK-NCW1/L6^$
M]M0?'3C[(WOU4*'2'KI&4DVH#'QD9EUF at ZWZWJ@JW 5NW3* 3-E<O=5Y/_$X
M7;[G,+O at -?0(XS +O<B=RR?BU\%OB*ERW6IF+*%/6Z>!@:3KTA+9%F4V8V;A
MXH>?W[UKR,V)A<IT\*M,Q at M]E>N*"H.EK/,)I]V',-S<2Y>JZPYH!^*QD1LQ
MJ52C"XPXMX>3[$NUMF<(-J,6F:WY&X[>. .S<UTPBWK]1,;L93,TD<.P(UR!
M=G9&IY*;;:AH=XW*,6;0))8ICS5,F4?='!O1G/\'8J,6HWWS8^]]6%7\&V*C
M[O=@^(R]]Y9%<!P-Q_O/RLW03<&Q8+,Z.#YU!B-(79WA2 7'Q^!M,>Z%K&CV
M_N/KG]_]Z)Y\.#G#*/@8UA3Z(#Z>?J+'[IN?/[Q2VYX;VY=.7_H1"ND:MN,^
M?DPV>A,#R>+JICXWM"]DG)6=264/B/@'X:4K!8.H^ATL: =0BU\A<6MFH7V_
M.F!C4RQ,;6I%KD7/) O,MF'Y,0;3V at 9=]]\G'T;#'OOCC_*1^^J7G^"QZ_;(
M7 I+:#.8E4;QI<-JEG!+V4'T[S)"HX$4_%O&`00?O7K$7#?@?B06W.\&4<2_
M+9(TZY5B-MLHL+B[/<HJ0L42:(OA\F\^7\C-\D9=5X6JFHUI-0O#\9 /3.2Z
M5<3UVJI%!:-1R2\"SPB^]@OD01/VHSR G5X3LGGA-]=@B>CV_.X6N&Z[!S-;
MM]V#4ZS;;,O_4]L]>,BZ[0OEQ&IF1=F*N:?+DSFZL_LN\8+72U!IZ+\GJ)79
MB</4UYN3=S^RK36T_<5(_=O1X5Z:&NJO4.*7LJ#9$MLJSMA=H5J'K0%9?\I0
M=6C#=E=X6Z?=`XJNVU:BK=RJ'F")H;]_J.NTCQF/L")Q=_"\!U"\!["K at -CW
M^.(]@-/_2_A6.[4HG @=H$7JJWW'CO_7;-#:1V_=EQU:^[)#9 at B,6[)VCBNK
ME(=R([:"N+;_&NX9^Z]#S'_Z\ FOT35W=[%8`-0^2B_K:I=)^G5'.NO*[, at P
M!\J,^FOUU_O$YZW\J?JUJP]K5.?O+J/B_K%\>H75*)CT"=6J0L&9QV)^R40^
MV9XK3$]27:/P8O#T4&2HG"3F.Y+V3&HIC"+F12)A?LJQNNC%2]BW"8%=%UXJ
M3[V\*)%:Y>S26P)QJJID+HRFHTO3L5=94]NJ%-4<NTJZ@%U=<8H0TDD!.SYF
M1GT,FR[-:E%9D,_G2UV1O RSF9SI?)$MR_)EK6"C*H)]Q3$L57CAI6&2"Q9F
M=.P#8O+,WS&*.%(A:LKL&.6F`R^][W3TZ;C1QZ0I*L4![&S!VT"M at NI+$H@<
M-C$+2: )>KLCPO\@((-*]FQ]Z"HU1",OC_2A/)V24E48%CE.,C",Q2(*>5!2
M"UUAK,Q"U;OJHL(WB"'+WFSA+A+1W=.]IDG:#>.,1<!N[^BHWX]Z9JD,!(5@
M&4A)8X at YMIBQ?+X9)%G&@TVJM)=2-H\/G5$"&$YI"/EW-W<V'1+-O%P`H\MG
MJ H<R9N(),K!@.!9B+Y)I79\%?'X'*P(=<9Y8&H+UD*/^?#8EBK&\<J>V'37
M[6,:VI8&1[)O49 FJ)@...9S(7C@*$/$A],TF4LZ,B>+'=,5^C0\GV7R<,W 
M`6$DBGK%M57E$YA#5TKH:)E-S<&D(S(ZZT"=AE5RTB%)L@#=7?!(R6=.RR8T
M]%BQ9H.U%T7))?BWF$&ZZN<ENT0=> AX?0E*!'</].V7[B.<$/U^U,!WLI:]
M&U+X,^Y_E=.3!5HR5IJOG\#J^9F>K7R%R2'S8.'2S&9%S[HT_ at X>Y !5MUD*
MY>-'-:59,$)U_ (AJXN#30(\9W,/W,M>DR#A! DR)+ E7F0J\1\08P; 66=8
MQ3Z$T=.EBQ'H/>F_3M/49*"@:P0R6CPO%..B,?9ZSGI\*A%E73(0>SR&B)W*
MXS/73_(XJZH;F_0KZ4D\8_G"N/91A(<ZT5K at 7QG%B#\XQGF43+RJ&\'RP+J@
MM4\X8&T.8N')?H,$TJJ,LR%+ at .H\K\L_K\E\ZUX>@Z<I3T<<\@QDJ?7-TB5"
MD81Z5-T%3\/ITLH^2FJ63"U7DCZ$5(CO-FL,O9J#D7/4G427+-RWGGB99>EG
MB=!=>UG(>=8TES7LM=?F?R\A\0(AP at G&&C5;@;.44YUY`E:3Q[2>=08-$RZ\
M3LWR)YX9LUQW0MCNI!%L:VBEP=SE`2S!G3P\+V:"A_!-$-?(!2V-"SP;%])8
MF'<.*">RQOBH&QZ&%L.=B,_YA$Z;&]2LU&%*JJ5I5I%TDXQY?I;+0WQ/D3JE
MXV[B43EF:PTKC:U)C)0+'+7=:;'!V)=@22T^1ECQCYJC/&R==ILQQXF#^HU5
M2DG1(FB)%= ?KP0$&CBG>820!IF5-'U\FDA?IZU3J'87.B=J at QAL9NJ,;"EN
MV at G-7IG,M-B/"G;&7;Y;^=_MHQZUNM<44[AM^*/VG4&0VBU"H;SZB_!5FI;*
M.0N$$PAQZ)+A?,Z#$-7;YHN%'WZV`.QNH'0C(JW/JMTY;O9%+B/FS+O0._)*
MHI\E*G^HF%PM=5@=\(R1I7,"^U3;LC =WLZW;]JW3, OOMJ;%2^X\/ 64 +1
MG+::B;&DM+'J'Q<[GCX;*'HE(K!0&V]I+A(C+3N:>?+J$N.P?X<A"+*25$,,
M<5$L;"T=J;N.\@A6H36=&AM_M-TZ'A=7@;IEU=YV[;I)J5UZU>U*!DZS5]$D
MC"&KY1-D7./KU*^/00C"6M"U.@\\D%>)!_O/]$T$W;)9FERZ/$V3U/4BT&2P
M=%4TD<1TD<#2V4TWQ8H"3>,5*[#8C7FH5\1XO66/4IM1P58M<<L%KCK?C96,
MB:Y at WG0W#W)E1CNH(TN"13$/JX9EC599J5]_`TY7\ ]"C_H/*;6\-":OMZZZ
MWZI/;#K_!5!+`0(4"Q0````(`*NYR"R3$L[(L P``!4T```.``````````$`
L( ````````!S=6)M;V1U;&4N9&EF9E!+!08``````0`!`#P```#<# ``````
`
end







From david.abrahams at rcn.com  Sun Jun  9 06:21:21 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 9 Jun 2002 00:21:21 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com> <adui3b$57j$1@main.gmane.org>
Message-ID: <25c701c20f6d$6bdb20d0$6601a8c0@boostconsulting.com>

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


> OK, here is the diff with the initialisation code stripped. I've also
> changed the class_ so we can do this:
>
>     class_<ctest>("ctest")
>         .def_init()
>         .def("set_v", &ctest::set_v)
>         .def("get_v", &ctest::get_v)
>         .add();
>
> I did wonder about doing it in the constructor, but then it would
possibly
> break any current code that currently uses boost V2.

I'd be willing to make that change at this early stage. It could be made
backward-compatible by having the module's add() function do nothing.

> Additionally I looked at breaking up the class_ chain in the same way as
the
> module, bearing in mind your earlier comments. I believe it is feasible
if
> some of the class_ member functions were virtual in the base and also
some
> of the templated member functions were moved to the base. That may muddy
the
> implementation, but improve useability, so I'm not sure if it is even
worth
> attempting?

It's not. That wouldn't work anyway. member_function_cast() is a
compile-time operation, despite appearances, and needs the type identity of
the class being wrapped to do its work.

-Dave






From david.abrahams at rcn.com  Sun Jun  9 15:25:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 9 Jun 2002 09:25:20 -0400
Subject: [C++-sig] Retiring "ref", etc.
Message-ID: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com>

This is somewhat stream-of-consciousness, but it announces some important
plans, so please bear with me:

So I've been working on how to provide user-friendly to_python/from_python
converters for Boost.Python v2, and as usual it's turning into a more
"interesting" journey than I imagined at first.

The first, most-obvious point as far as I'm concerned is that the
user-accessible converters should not traffic in PyObject*s. Reference
counting is too hard to get right, or rather, it's too easy to get wrong,
so users should be working with something that takes care of it for them.

As I had announced a long while ago, because of the importance of
boost::ref() in the library I plan to retire the "boost::python::ref"
typedef for boost::python::reference<PyObject>, so I began to think about
the alternatives. My plan had been to give reference<> a default template
argument (PyObject) and leave it at that: users would work with reference<>
in the place of ref. However, Ralf pointed out that using "reference"
/triples/ the size of this useful name, and when you add the <>s, it's
nearly quadrupled. I think he has a point, and besides the library needs a
convenient name for its own use in contexts where reference() is a [member]
function, so I began looking for replacements for "ref".

I was gritting my teeth and working with the nearly unpronounceable name
"objref" when I began to grow dissatisfied with the reference<> interface.
The default behavior when constructed with a PyObject* argument is to steal
a reference, which works fine for the result of most (but not all) Python
'C' API functions, but is dangerous in general. Not every one of these
functions returns a new reference, and it's much better to leak a reference
than it is to leave one dangling. Also, the 'increment_count'/'null_ok'
interface for customizing behavior is really kludgy.

Then I realized that the name "object" is no longer than "objref" and is a
much nicer name... I had been planning to provide a generalized object
interface which would present all the operations available from Python with
a similar interface (see "Generic C++ to Python Object Interface" at
http://www.python.org/sigs/c++-sig/), so it seemed like the right answer
might be to replace uses of "ref" with the new "object" interface. However,
there's a small fly in that ointment: while it might make some sense to
allow a null reference, it makes no sense at all to think of a null object.
I'm not talking about None, here: I mean a null PyObject*. Unfortunately,
it's sometimes important to be able to manage a possibly-null PyObject*, so
it appears that reference<> must stay alive in some form or other.

On the other hand, the fly adds nourishing protien: if the throwing null
check (which is currently disabled by null_ok) is moved into object's
constructor, then everything gets much cleaner. reference<>s can be null,
and object's constructor enforces the invariant that objects can never be
null. I also note that users will really want to work with an object way
more-often than they'll want a reference. For example, the user_friendly
to_python and from_python converters should really traffic in objects. So,
I hope that the availability of "object" will reduce the importance of
having a short name for reference<>.

I'm actually interested in considering different names for reference<>,
since once you change the default reference counting of PyObject* arguments
it's really a different class. Since it's really a smart pointer I'd go for
ptr<>, but we already have boost::python::ptr() which plays a similar role
to boost::ref() :(. I plan to make the current reference-stealing behavior
available through an adopt(PyObject*) function which returns the smart
pointer type, but which is much more-explicit

The biggest remaining issue is the relationship between object and the
types in objects.hpp. The best option might be to use public inheritance
from object and to do something which restricts the interface in the
derived classes. I'll probably be trying a few experiments.

you-eat-lots-of-bugs-if-you-ride-with-your-mouth-open-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 daveh at cadlink.com  Sun Jun  9 18:58:52 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 9 Jun 2002 12:58:52 -0400
Subject: [C++-sig] Re: Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com>
Message-ID: <ae01g8$moj$1@main.gmane.org>

Does this mean that the entire Python C-API is going to be wrapped and
managed?

Or maybe some function templates (proxies) that take a python function as an
argument, then look up the function address in a table in the implementation
to decide if the result is a new or borrowed reference and then return an
object wrapper containing the PyObject* after calling the function?

Dave Hawkes









From david.abrahams at rcn.com  Sun Jun  9 19:29:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 9 Jun 2002 13:29:14 -0400
Subject: [C++-sig] Re: Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <ae01g8$moj$1@main.gmane.org>
Message-ID: <27a301c20fdb$4b82c130$6601a8c0@boostconsulting.com>

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


> Does this mean that the entire Python C-API is going to be wrapped and
> managed?

Not neccessarily. Much of it will eventually, though.

> Or maybe some function templates (proxies) that take a python function as
an
> argument, then look up the function address in a table in the
implementation
> to decide if the result is a new or borrowed reference and then return an
> object wrapper containing the PyObject* after calling the function?

That sounds both expensive and cumbersome compared to a bunch of inline
functions.

-Dave





From daveh at cadlink.com  Sun Jun  9 22:12:58 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 9 Jun 2002 16:12:58 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com> <adudrt$103$1@main.gmane.org>
Message-ID: <ae0cs8$6hk$3@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:24f201c20f64$394821d0$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> >
> > "David Abrahams" <david.abrahams at rcn.com> wrote in message
> > news:243a01c20f1e$cf832870$6601a8c0 at boostconsulting.com...
> > >
> > support for. It just saves creating and keeping track of a large number
> of
> > initialisation calls.
>
> It's a shame that we couldn't get something into the library. However, it
> was starting to look like getting something I would be willing to support
> was going to be a big effort for both of us. At least the library is doing
> its job: it was meant to be an extensible framework. Also, I think the
idea
> of dispensing with module objects altogether and using a global current
> module state is a valuable one, so that's a contribution.
>

It's not a lot of code and it does have other applications, so its probably
better outside of the BPL on reflection.

> The
> > end conclusion is that we just need another catch prior to the
catch(...)
> > that will catch a specific seh_filter class that we define.
>
> This is neat, but unfortunately it requires the cooperation of everything
> in the call chain. If the standard library uses catch(...), as it is
likely
> to in, say, uninitialized_fill, without using your seh_filter trick, the
> unwinding actions will still execute.
>

In fact looking through the MS STL code the greatest use of catch(...) is in
the stream support.

> However, I think the enclosed demonstrates that my little module_tail hack
> is /ALWAYS/ the right thing to do ;-)
>

It would appear that a rethrow from within the handler throws the exception
slightly differently so it passes through the catch(...) and can then only
be caught by a SEH block.
Strange, and I bet there's not much documentation on this...

> You can also run it with an argument to see how it invokes JIT debugging
> for unhandled SEHs.
>

As the JIT relies on receiving an SE then driving it through the catch all
will do the trick.

Dave Hawkes









From daveh at cadlink.com  Sun Jun  9 22:14:31 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 9 Jun 2002 16:14:31 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com> <adui3b$57j$1@main.gmane.org>
Message-ID: <ae0cv5$6m7$3@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:25c701c20f6d$6bdb20d0$6601a8c0 at boostconsulting.com...
>
> > I did wonder about doing it in the constructor, but then it would
> possibly
> > break any current code that currently uses boost V2.
>
> I'd be willing to make that change at this early stage. It could be made
> backward-compatible by having the module's add() function do nothing.
>

I'll send you another diff shortly with a couple of fixes and some tidying
up. The automatic class addition should be in as well. I decided to make the
add work shuch that if multiple additions are attempted only the first
succeeds and the rest will just detect this and do nothing.

In addition if a class is contructed multiple times it will find itself and
add to the previous definition, so we can do this,

    class_<ctest>("ctest")
        .def_init()
        .def("set_v", &ctest::set_v);
    class_<ctest>("ctest")
        .def("get_v", &ctest::get_v);

to build support for a single class. This has more to do with consistancy
and safety, rather than any coding efficiency.

> worth
> > attempting?
>
> It's not. That wouldn't work anyway. member_function_cast() is a
> compile-time operation, despite appearances, and needs the type identity
of
> the class being wrapped to do its work.
>

Unless something like

def<MyClass>("set_v", &MyClass::set_v);

was used, but then there's no real simplification.

Dave Hawkes









From david.abrahams at rcn.com  Sun Jun  9 23:49:31 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 9 Jun 2002 17:49:31 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org>   <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com> <adlt14$fnj$1@main.gmane.org> <186301c20cd3$2d84b5e0$6601a8c0@boostconsulting.com> <adm6c9$44l$1@main.gmane.org> <191f01c20ce8$5388b790$6601a8c0@boostconsulting.com> <adm9sj$9p9$1@main.gmane.org> <196c01c20cf1$c3a494f0$6601a8c0@boostconsulting.com> <adoacl$uu2$1@main.gmane.org> <1d9501c20d9a$1e8013b0$6601a8c0@boostconsulting.com> <adoi2f$ica$1@main.gmane.org> <1e3001c20da6$ce8bb5f0$6601a8c0@boostconsulting.com> <adotkq$9eb$1@main.gmane.org> <1efd01c20dc9$a1aa10e0$6601a8c0@boostconsulting.com> <adpbun$sof$1@main.gmane.org> <1f3401c20de3$226029e0$6601a8c0@boostconsulting.com> <adqj2l$tbf$1@main.gmane.org> <20c801c20e3f$220078e0$6601a8c0@boostconsulting.com> <adru0m$9jk$1@main.gmane.org> <229301c20eea$365c9b10$6601a8c0@boostconsulting.com> <adties$vis$1@main.gmane.org> <243a01c20f1e$cf832870$6601a8c0@boostconsulting.com> <adui3b$57j$1@main.gmane.org> <ae0cv5$6m7$3@main.gmane.org>
Message-ID: <285601c21000$20b51d20$6601a8c0@boostconsulting.com>

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

> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:25c701c20f6d$6bdb20d0$6601a8c0 at boostconsulting.com...

> In addition if a class is contructed multiple times it will find itself
and
> add to the previous definition, so we can do this,
>
>     class_<ctest>("ctest")
>         .def_init()
>         .def("set_v", &ctest::set_v);
>     class_<ctest>("ctest")
>         .def("get_v", &ctest::get_v);
>
> to build support for a single class. This has more to do with consistancy
> and safety, rather than any coding efficiency.

Those sound like good choices. It might be difficult to get nested classes
to work, but maybe that scoping is best done using the class name:

    class<ctest::nested>("ctest.nested")
        ...
        ;

-Dave






From daveh at cadlink.com  Mon Jun 10 02:16:11 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 9 Jun 2002 20:16:11 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com>
Message-ID: <ae0r49$o0e$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:285601c21000$20b51d20$6601a8c0 at boostconsulting.com...
>
> Those sound like good choices. It might be difficult to get nested classes
> to work, but maybe that scoping is best done using the class name:
>
>     class<ctest::nested>("ctest.nested")
>         ...
>         ;
>

That's straight forward apart from one small detail. Unlike modules, if a
parent does not exist I'm not sure that I can safely create it on the fly.
If I create an empty dummy class it may not have the correct base classes
when it is eventually constructed and so I would have to tear out the dummy
and replace it with the correct one when that happens. I'm not sure that I
like any of this, so maybe there should just be an assertion if the parent
classes are not created prior to the nested classes?

Dave Hawkes








From david.abrahams at rcn.com  Mon Jun 10 02:29:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 9 Jun 2002 20:29:23 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org>
Message-ID: <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com>

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

>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:285601c21000$20b51d20$6601a8c0 at boostconsulting.com...
> >
> > Those sound like good choices. It might be difficult to get nested
classes
> > to work, but maybe that scoping is best done using the class name:
> >
> >     class<ctest::nested>("ctest.nested")
> >         ...
> >         ;
> >
>
> That's straight forward apart from one small detail. Unlike modules, if a
> parent does not exist I'm not sure that I can safely create it on the
fly.
> If I create an empty dummy class it may not have the correct base classes
> when it is eventually constructed and so I would have to tear out the
dummy
> and replace it with the correct one when that happens. I'm not sure that
I
> like any of this, so maybe there should just be an assertion if the
parent
> classes are not created prior to the nested classes?

I thought of that; I think it's about all we can do...

...unless we add a parent scope argument to class' constructor, reminiscent
of v1. At least it could be optional in v2.

-Dave






From daveh at cadlink.com  Mon Jun 10 03:17:45 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 9 Jun 2002 21:17:45 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com>
Message-ID: <ae0unn$rkq$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:28bc01c21015$dfc9fef0$6601a8c0 at boostconsulting.com...
> I
> > like any of this, so maybe there should just be an assertion if the
> parent
> > classes are not created prior to the nested classes?
>
> I thought of that; I think it's about all we can do...
>
> ...unless we add a parent scope argument to class' constructor,
reminiscent
> of v1. At least it could be optional in v2.
>

How large a depth of nested classes do we have to support? Its just too much
complexity for a little gain. I think for now it's not unreasonable that the
user creates the nested classes in order. If we come up with a better
solution later it won't break anything.

Dave Hawkes








From david.abrahams at rcn.com  Mon Jun 10 03:23:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 9 Jun 2002 21:23:40 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org>
Message-ID: <28ce01c2101d$75096080$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Sunday, June 09, 2002 9:17 PM
Subject: [C++-sig] Re: Re: sub module support in V2


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:28bc01c21015$dfc9fef0$6601a8c0 at boostconsulting.com...
> > I
> > > like any of this, so maybe there should just be an assertion if the
> > parent
> > > classes are not created prior to the nested classes?
> >
> > I thought of that; I think it's about all we can do...
> >
> > ...unless we add a parent scope argument to class' constructor,
> reminiscent
> > of v1. At least it could be optional in v2.
> >
>
> How large a depth of nested classes do we have to support? Its just too
much
> complexity for a little gain. I think for now it's not unreasonable that
the
> user creates the nested classes in order. If we come up with a better
> solution later it won't break anything.

I think the optional parent scope constructor argument is a better
solution, and I don't like to have lots of ways to say the same thing (it's
un-pythonic), so I'd rather go with that.

-Dave






From djowel at gmx.co.uk  Mon Jun 10 05:31:12 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Mon, 10 Jun 2002 11:31:12 +0800
Subject: [C++-sig] Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com>
Message-ID: <023d01c21033$b560ed40$c2a451ca@asiagate.net>

----- Original Message ----- 
From: "David Abrahams" 

> you-eat-lots-of-bugs-if-you-ride-with-your-mouth-open-ly y'rs,
> dave

And yes, this is why I'm still lurking in the background and
keeping my mouth shut ;-) I was afraid (and shy) that I might
embarass myself publicly with potentially dumb remarks.
Duh ;-) So pardon me if I am not yet quite familiar with the
Python/BPL culture. I've been really rather itching to join in.

> there's a small fly in that ointment: while it might make some sense to
> allow a null reference, it makes no sense at all to think of a null object.
> I'm not talking about None, here: I mean a null PyObject*. 

object, as a name, seems to be perfect and sensible. I am not
quite sure about the implications but isn't it possible to make
the semantics of a null PyObject* be like a None object? 

> Unfortunately, it's sometimes important to be able to manage a 
> possibly-null PyObject*, 

I've written run-time libraries for dynamically typed interpreters before.
The core data type I always use is a C++ reference counted object
called 'value' [ object is a better name ]. In my implementation, there
is no null (in the C/C++ sense)-object. There's always an object being 
pointed to. There is however a nil object, akin to python-None. To
keep the implementation from having to construct/allocate destruct/
deallocate nil-objects, I keep only one that goes into scope at the
very beginning and out of scope at the very end. All nil objects share
this singleton.

> so it appears that reference<> must stay alive in some form or other.

IMHO, I don't see how a null reference makes more sense than 
having a null object. If you ask me, I'm more concerned about
having both a null-reference and a reference to None with different 
behavior.

//////////////////////////////////////////////
So, there's my 2c worth. Right now, I am still gaining confidence
with BPL and Python so I'm rather quite, ummmm, shy in the
presence of Python/BPL gurus as most of you are ;-)

Cheers,
--Joel










From daveh at cadlink.com  Mon Jun 10 06:21:57 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 10 Jun 2002 00:21:57 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com>
Message-ID: <ae19h5$sq4$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:28ce01c2101d$75096080$6601a8c0 at boostconsulting.com...
> >
> > How large a depth of nested classes do we have to support? Its just too
> much
> > complexity for a little gain. I think for now it's not unreasonable that
> the
> > user creates the nested classes in order. If we come up with a better
> > solution later it won't break anything.
>
> I think the optional parent scope constructor argument is a better
> solution, and I don't like to have lots of ways to say the same thing
(it's
> un-pythonic), so I'd rather go with that.
>
I'll take a look at how it could work.



On another note in module.cpp there is:

void module_base::add_type(ref x)
{
    assert(PyObject_TypeCheck(x.get(), &PyType_Type));
    add((PyTypeObject*)x.release());
}

why is the reference released at this point, is there a count consumed
implicitly somewhere else ?

Dave Hawkes









From djowel at gmx.co.uk  Mon Jun 10 06:46:51 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Mon, 10 Jun 2002 12:46:51 +0800
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <adlgit$hmf$1@main.gmane.org> <adlima$mnn$1@main.gmane.org> <180701c20cbf$10504ca0$6601a8c0@boostconsulting.com>
Message-ID: <02aa01c21039$df8c7660$c2a451ca@asiagate.net>

----- Original Message ----- 
From: "David Abrahams" :

> Perhaps Joel de Guzman has some creative phoenix-like ideas about this...
> Joel?

I'm just catching up on reading the past few days. Sorry if this
reply is late. I'll surely reply to this as soon as I catch my breath.
The past 2 weeks has been rather like a storm...

Regards,
--Joel











From david.abrahams at rcn.com  Mon Jun 10 06:43:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 00:43:53 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org>
Message-ID: <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com>

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

> On another note in module.cpp there is:
>
> void module_base::add_type(ref x)
> {
>     assert(PyObject_TypeCheck(x.get(), &PyType_Type));
>     add((PyTypeObject*)x.release());
> }
>
> why is the reference released at this point, is there a count consumed
> implicitly somewhere else ?

I don't see it now, so it may be a mistake. Yet another piece of evidence
for avoiding manual reference-counting.






From david.abrahams at rcn.com  Mon Jun 10 07:04:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 01:04:28 -0400
Subject: [C++-sig] Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net>
Message-ID: <003701c2103c$5f369510$6601a8c0@boostconsulting.com>

From: "joel de guzman" <djowel at gmx.co.uk>


> > there's a small fly in that ointment: while it might make some sense to
> > allow a null reference, it makes no sense at all to think of a null
object.
> > I'm not talking about None, here: I mean a null PyObject*.
>
> object, as a name, seems to be perfect and sensible. I am not
> quite sure about the implications but isn't it possible to make
> the semantics of a null PyObject* be like a None object?

Possible, but not desirable.

> > Unfortunately, it's sometimes important to be able to manage a
> > possibly-null PyObject*,
>
> I've written run-time libraries for dynamically typed interpreters
before.
> The core data type I always use is a C++ reference counted object
> called 'value' [ object is a better name ]. In my implementation, there
> is no null (in the C/C++ sense)-object. There's always an object being
> pointed to. There is however a nil object, akin to python-None. To
> keep the implementation from having to construct/allocate destruct/
> deallocate nil-objects, I keep only one that goes into scope at the
> very beginning and out of scope at the very end. All nil objects share
> this singleton.

The problem, unfortunately, is that Python will hand us a null PyObject*
whenever it wants to signal failure. Common idioms are:

    // get the attribute if it exists
    reference<> x(PyObject_GetAttrString(y.get(), "some_attribute"));
    if (!x) // if not found
    {
        PyErr_Clear(); // clear the exception
        ...            // do something else
    }
    else
    {
        // use x
    }

If I keep the (IMO wise) policy of avoiding manual reference-counting in
favor of taking immediate possesion with some kind of smart pointer there
will be times when initializing the smart pointer with 0 will be
unavoidable. I don't much care about how that zero-ness is represented
inside the smart pointer (we could make it point at some singleton), but
there needs to be a representation for zero.

> > so it appears that reference<> must stay alive in some form or other.
>
> IMHO, I don't see how a null reference makes more sense than
> having a null object.

I agree :(. So maybe reference<> is the wrong name, as I suggested earlier.
I'm still open to suggestions.

> If you ask me, I'm more concerned about
> having both a null-reference and a reference to None with different
> behavior.

There's nothing special about None, so in that respect there's nothing to
worry about.

-Dave





From djowel at gmx.co.uk  Mon Jun 10 08:20:07 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Mon, 10 Jun 2002 14:20:07 +0800
Subject: [C++-sig] Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com>
Message-ID: <031101c21047$457652e0$c2a451ca@asiagate.net>

----- Original Message ----- 
From: "David Abrahams" 

> > > Unfortunately, it's sometimes important to be able to manage a
> > > possibly-null PyObject*,
> >
> > I've written run-time libraries for dynamically typed interpreters
> before.
> > The core data type I always use is a C++ reference counted object
> > called 'value' [ object is a better name ]. In my implementation, there
> > is no null (in the C/C++ sense)-object. There's always an object being
> > pointed to. There is however a nil object, akin to python-None. To
> > keep the implementation from having to construct/allocate destruct/
> > deallocate nil-objects, I keep only one that goes into scope at the
> > very beginning and out of scope at the very end. All nil objects share
> > this singleton.
> 
> The problem, unfortunately, is that Python will hand us a null PyObject*
> whenever it wants to signal failure. Common idioms are:

I see. So the next thing that pops in my mind is to make the
null an internal implementation detail and instead expose
a pseudo *error_object* that abstracts the signaling of an
error condition. That way, there is only one interface where
an object with a null /representation/ will act practically as an 
error object.

> If I keep the (IMO wise) policy of avoiding manual reference-counting in
> favor of taking immediate possesion with some kind of smart pointer there
> will be times when initializing the smart pointer with 0 will be
> unavoidable. I don't much care about how that zero-ness is represented
> inside the smart pointer (we could make it point at some singleton), but
> there needs to be a representation for zero.

Other than signalling an error condition, what else is the role
of this special case? I reckon that the answer to this question
will ultimately lead us to >> what really is this thing which is
represented by a zero <<. I strongly feel that it is just a matter
of category.

> I agree :(. So maybe reference<> is the wrong name, as I suggested earlier.
> I'm still open to suggestions.

I'm inclined to suggest having just an ^object^ that covers the
special error case if the only difference between an ^object^
and a ^reference^ (or ptr), is the signalling of the error condition.
After all, it is quite intuitive to think of an error-object alongside
a none-object an int-object a tuple-object and so on.

Still-learning-and-thanks-for-your-patience-ly-yours ;-)
--Joel









From david.abrahams at rcn.com  Mon Jun 10 15:10:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 09:10:42 -0400
Subject: [C++-sig] Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net>
Message-ID: <007901c21080$b932aec0$6601a8c0@boostconsulting.com>

From: "joel de guzman" <djowel at gmx.co.uk>

> I see. So the next thing that pops in my mind is to make the
> null an internal implementation detail and instead expose
> a pseudo *error_object* that abstracts the signaling of an
> error condition. That way, there is only one interface where
> an object with a null /representation/ will act practically as an
> error object.

Sorry, I can't make heads nor tails of the above paragraph.

> > If I keep the (IMO wise) policy of avoiding manual reference-counting
in
> > favor of taking immediate possesion with some kind of smart pointer
there
> > will be times when initializing the smart pointer with 0 will be
> > unavoidable. I don't much care about how that zero-ness is represented
> > inside the smart pointer (we could make it point at some singleton),
but
> > there needs to be a representation for zero.
>
> Other than signalling an error condition, what else is the role
> of this special case?

Python is written in 'C'. What roles can a null PyObject* have?
Default-constructed smart pointers need to have a value.
Python tuples start out initially empty (not full of None) when you
construct them.
...and so forth.

> I reckon that the answer to this question
> will ultimately lead us to >> what really is this thing which is
> represented by a zero <<. I strongly feel that it is just a matter
> of category.

Not sure what the implications of assigning it a category it might be,
either.

> > I agree :(. So maybe reference<> is the wrong name, as I suggested
earlier.
> > I'm still open to suggestions.
>
> I'm inclined to suggest having just an ^object^ that covers the
> special error case if the only difference between an ^object^
> and a ^reference^ (or ptr), is the signalling of the error condition.

I'm against this approach. The current reference<> throws by default if you
pass null to the constructor, and that default behavior is used in 99% of
cases. It works with Python synergistically: when Python returns via an
error it becomes an exception in the user's code.

That really is the behavior users want from their object type in most
cases. Also, it's a basic principle of reliable software engineering that
"invalid" object states are best avoided. It's much cleaner to know that if
I get passed an "object", it's valid, and not some "error state". Otherwise
code is either full of checks to see whether we're holding the error
object, or (more likely) it simply ignores errors because they're too much
trouble.

What I'm heading toward is a two-level interface: a smart pointer type
("reference<>", or pick a better name) which can be null, for low-level
interfacing with Python, and a higher-level type, "object", which can never
be null, and which provides a nice Python-objec-like interface.

-Dave






From miked at sinistergames.com  Mon Jun 10 16:32:17 2002
From: miked at sinistergames.com (Mike Dickheiser)
Date: Mon, 10 Jun 2002 10:32:17 -0400
Subject: [C++-sig] Passing Boost wrapped classes (refs and/or pointers) to/from Python and C++
Message-ID: <KJENIABEMDBBGDDMCPLHEEBOCAAA.miked@sinistergames.com>

Ok. I've wrapped numerous C++ class using Boost, and I know how to call
Python functions from C++ and vice versa. But how do I call these functions
using a reference or pointer to one of my wrapped classes?

For example, say I have wrapped the C++ class "Vector3" and have the
following Python script:

def DoSomething(args)
   x = Vector3()
   x.set(0.0, 0.0, 0.0)

   y = [a Vector3 passed into args]
   y.set(0.0, 0.0, 0.0)


So, how do I extract 'y' from 'args'?

And how would I do it if a Vector3* were passed into args instead?

For that matter, how do I pack a Vector3 or Vector3* into the args to begin
with on the C++ side?

Finally, if I had DoSomething() return a Vector3, how would the C++ code
that called the function convert the returned PyObject into a Vector3?

I've searched all the documentation I can find on boost and Python, and
haven't found any discussion on how this is done. I've seen references to
functions that look like they are related to the process (e.g. "to_python"),
but no help on when/where/why to use them. In any case, what I HAVE found is
in the straight Python help, so I'm wary about using it because I'm now
using Boost which I would expect to provide a different (read: far easier)
mechanism.

Thanks for any help
Mike Dickheiser





From david.abrahams at rcn.com  Mon Jun 10 16:49:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 10:49:22 -0400
Subject: [C++-sig] Passing Boost wrapped classes (refs and/or pointers) to/from Python and C++
References: <KJENIABEMDBBGDDMCPLHEEBOCAAA.miked@sinistergames.com>
Message-ID: <011901c2108e$47f47a00$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Mike Dickheiser" <miked at sinistergames.com>


> Ok. I've wrapped numerous C++ class using Boost,

I presume you're using Boost.Python v1 and not the v2 library described at
the top of http://www.boost.org/libs/python/doc/index.html?

> and I know how to call
> Python functions from C++ and vice versa. But how do I call these
functions
> using a reference or pointer to one of my wrapped classes?
>
> For example, say I have wrapped the C++ class "Vector3" and have the
> following Python script:
>
> def DoSomething(args)
>    x = Vector3()
>    x.set(0.0, 0.0, 0.0)
>
>    y = [a Vector3 passed into args]
>    y.set(0.0, 0.0, 0.0)
>
>
> So, how do I extract 'y' from 'args'?

I don't understand what you're asking for.

> And how would I do it if a Vector3* were passed into args instead?

I don't mean to be rententive about this, but I don't understand the term
"passed into args".
It looks like you've got a python function that takes a single argument. If
the user has passed a Vector3 object as the function's argument, there's
nothing to extract on the Python side.

> For that matter, how do I pack a Vector3 or Vector3* into the args to
begin
> with on the C++ side?

What do you mean "pack"?

> Finally, if I had DoSomething() return a Vector3, how would the C++ code
> that called the function convert the returned PyObject into a Vector3?

If you are invoking DoSomething() from C++, I think what you're looking for
is the Python callback interface, in v1:

    boost::python::callback<ResultType>::call(arg1, arg2, arg3...);

Unfortunately, Boost.Python v1 doesn't give you a way to pass references
and pointers to the callback interface (well, you can pass references, but
the values are copied into new Python objects). Boost.Python v2 does have
that facility. For more details, consult
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/callbacks.html

Good luck,
Dave






From djowel at gmx.co.uk  Mon Jun 10 17:06:44 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Mon, 10 Jun 2002 23:06:44 +0800
Subject: [C++-sig] Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net> <007901c21080$b932aec0$6601a8c0@boostconsulting.com>
Message-ID: <008501c21090$d890d2a0$cdbe8aca@asiagate.net>

----- Original Message ----- 
From: "David Abrahams" :

> > I'm inclined to suggest having just an ^object^ that covers the
> > special error case if the only difference between an ^object^
> > and a ^reference^ (or ptr), is the signalling of the error condition.
> 
> I'm against this approach. The current reference<> throws by default if you
> pass null to the constructor, and that default behavior is used in 99% of
> cases. It works with Python synergistically: when Python returns via an
> error it becomes an exception in the user's code.
> 
> That really is the behavior users want from their object type in most
> cases. Also, it's a basic principle of reliable software engineering that
> "invalid" object states are best avoided. It's much cleaner to know that if
> I get passed an "object", it's valid, and not some "error state". Otherwise
> code is either full of checks to see whether we're holding the error
> object, or (more likely) it simply ignores errors because they're too much
> trouble.

I see. I too am against propagating error conditions. Perhaps I had
the mistaken notion that such states are part of life, which is not
unusual in a dynamically typed environment. As it is, code using
dynamically typed data is abundant with checks. Checks that we
take for granted in statically typed C++, for example. 

Yes. I agree that if it used in less than 1% of the cases, then it's 
better to deal with it differently.

> What I'm heading toward is a two-level interface: a smart pointer type
> ("reference<>", or pick a better name) which can be null, for low-level
> interfacing with Python, and a higher-level type, "object", which can never
> be null, and which provides a nice Python-objec-like interface.

Hmmm, so it seems that we have two types which are strikingly
similar to what we have in C++. 1) an object-reference that
cannot be null and 2) an object-pointer that can be null. While
object is indeed a nice name, the presence of another lower
level class that can point to a null object seems to suggest
(at least to me) the ref and ptr prefix. obj_ref and obj_ptr
comes to mind. Or, if you want to keep the nice "object" as
a name, just name the other "object_ptr". After all, this is a lower
level class that the client should avoid using if possible, so the 
longer name is ok.

    object: cannot be null [high level interface]
    object_ptr: can be null [low level interface]

Cheers,
--Joel





From achim.domma at syynx.de  Mon Jun 10 17:22:35 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Mon, 10 Jun 2002 17:22:35 +0200
Subject: [C++-sig] distribution of bpl.dll
Message-ID: <FCEMIEFBFOIDAOJDEPIAMELODGAA.achim.domma@syynx.de>

Hi,

how will bpl.dll be distributed in the future? Should every extension
provide his own version? If I understand right, the intension was to let
extensions share on bpl.dll, but arent't C++ libraries compiler dependent?

Achim






From miked at sinistergames.com  Mon Jun 10 19:21:30 2002
From: miked at sinistergames.com (Mike Dickheiser)
Date: Mon, 10 Jun 2002 13:21:30 -0400
Subject: [C++-sig] An apology
Message-ID: <KJENIABEMDBBGDDMCPLHAEBPCAAA.miked@sinistergames.com>

I should have prefaced my previous post with an apology about my being new
to Python and Boost, and also for my own limited investigation into my
question. I've been tasked with getting Python up and running as fast as
possible into our project, and am scrambling to learn both Python and Boost
as well as general multi-language interface design in a matter of a very
small number of days (all on top of my normal duties on the project).

If someone could just point me to documentation that best describes how to
accomplish what I'm asking, I'd be grateful, especially if that includes a
small (but complete) example of the steps to be taken.

I know I could probably find the answers myself if I read enough, but I'm
hoping someone could save me those (extremely valuable) hours ;)

Again, thanks for any help
-Mike





From david.abrahams at rcn.com  Mon Jun 10 19:26:52 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 13:26:52 -0400
Subject: [C++-sig] An apology
References: <KJENIABEMDBBGDDMCPLHAEBPCAAA.miked@sinistergames.com>
Message-ID: <01a401c210a4$05d26270$6601a8c0@boostconsulting.com>

From: "Mike Dickheiser" <miked at sinistergames.com>


> I should have prefaced my previous post with an apology about my being
new
> to Python and Boost, and also for my own limited investigation into my
> question.

You don't need to apologize.

> I've been tasked with getting Python up and running as fast as
> possible into our project, and am scrambling to learn both Python and
Boost
> as well as general multi-language interface design in a matter of a very
> small number of days (all on top of my normal duties on the project).

Quite a job.

> If someone could just point me to documentation that best describes how
to
> accomplish what I'm asking, I'd be grateful, especially if that includes
a
> small (but complete) example of the steps to be taken.
>
> I know I could probably find the answers myself if I read enough, but I'm
> hoping someone could save me those (extremely valuable) hours ;)

Everyone else's hours are valuable too.  Was something missing from my post
at http://mail.python.org/pipermail/c++-sig/2002-June/001329.html? If so,
please say what it was.

Specific, precisely-worded questions help.

-Dave





From daveh at cadlink.com  Mon Jun 10 19:58:21 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 10 Jun 2002 13:58:21 -0400
Subject: [C++-sig] Re: Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net> <007901c21080$b932aec0$6601a8c0@boostconsulting.com>
Message-ID: <ae2pbu$6hr$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:007901c21080$b932aec0$6601a8c0 at boostconsulting.com...
>
> Python is written in 'C'. What roles can a null PyObject* have?
> Default-constructed smart pointers need to have a value.
> Python tuples start out initially empty (not full of None) when you
> construct them.
> ...and so forth.
>
>

Another awkward twist is that some of the python API functions accept a NULL
PyObject* as a valid parameter. Which implies a 'NULL' reference should be
allowed which is not symantically an error condition. However I don't think
there any functions that can return a valid NULL apart from some of the
MACRO versions with no error checking.

I don't think it is unreasonable to construct a new smart pointer that holds
a NULL pointer as it currently does.

However for return values may be we should have a different smart pointer
called something like result_reference. We can then allow conversions
between the two that would check if result_reference was valid, before
converting to a regular reference.

Dave Hawkes









From daveh at cadlink.com  Mon Jun 10 20:20:08 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 10 Jun 2002 14:20:08 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com>
Message-ID: <ae2qko$chi$1@main.gmane.org>

Here is the latest diff that includes the nested class support. I've also
rearranged and tidied up a few items. Nested classes can be created before
their parents without error.

However I'm not sure that I like it.

maybe instead of:

    class_<ctest>("ctest")
        .def_init()
        .def("set_v", &ctest::set_v);
    class_<ctest::ctest2>("ctest.ctest2")
        .def_init()
        .def_readwrite("n", &ctest::ctest2::n);

we should do:

    class_<ctest>("ctest")
        .def_init()
        .def("set_v", &ctest::set_v);
        .def("ctest2", class_<ctest::ctest2>());
    class_<ctest::ctest2>()
        .def_init()
        .def_readwrite("n", &ctest::ctest2::n);

This could be achieved as once a particular class has been registered we can
find its object from the typeinfo, rather than by name.

In both scenarios there are still some issues to be worked out if a class is
registered multiple times with different parents/modules. Some tweaks to the
class registry will probably fix that though.

Dave Hawkes





begin 666 submodule.zip
M4$L#!!0````(`%=KRBQOU"6*"!<``(UB```.````<W5B;6]D=6QE+F1I9F;E
M/&MSVSB2G]=5_@^(4^50%F7KX4<L/V9F\YA)51ZNB>?NMB93+$J$8NY(I):D
M8FN]OM]^W6@`!$E0HASO?CDD9<M at H]%H] OHIH)P,F&=9/'QCKWZK\]L%,=I
MUC\0OP[FR^PFC@[&4S]-]V_F<WI:\W"KT^FL'OZ7?K?;[W2/.]TCUCL='IX,
M>R_WNZJQ3O>PV]UJM]LKI]%(>EW6ZP\'A\/#7 at 7)CS^R3N]TX)ZP-O[J]]B/
M/VXQ;"F?3G:9'P3>/(GG/,F6SOC&3]@XCM)LCT7^C+LLX1/JV&63KSQKG3U^
M;+$C)61;G1P==/E9EJS$!&/:FX[8WFIOTZB#`Z2993&;Q<%BRK=-9/#$H6ZV
M.VO)1_?R-[;9/H+L93=A*I"J_H1GBR1BXH'J?[#,.5XD"8^RNKEM4XJ-'PYI
MYX?##>;?!MXR-D_";W[&ATA%MISSE+8//P; H7CT=S[.TN%0R)07!DQ].!."
MTS_LHN#TCPY=D#$E. %P/9P.APG_&J893[QQ/%]Z at MO)8IS%R?GUI;.EJ&.S
M.<#"0J9>=AZF`M@?3?FET\IAW)P48 A\\&[B:< !DWO#IX&'!%\ZCOZ\U^JV
M]D&F`$<GQX$,Z%P2)J>E1,7^K"H4-YQ6CULE_BAL%\'6[8=;9N7(3_EP"!1Z
M]#=P)^-WF2<)0"$51("@P#YE')@$^\3.B8)K5Y+R/SW]J:\_#2YI<V!7CF%S
M3GKNJ=Z;_P###1Q5AF_$T^VG9ZH:`]3D[-T*UEMV$NH#(DS,5&?F[9"U-M\.
MGCN 0]8['O:/-W `:S""IG9?#H_ &_3MWJ"+8@,_7PJIV1(6,YW[8TZ3L7NC
MAZ8L=-'TT 5CV[2[DI0PFL2H6%MRT__ZZ=/G:^_J;]>_?/KHO7[SZCTS:-YB
M]VB@%J-I.!Z20/?=WB$(]*'II;[%8)6TG4<;P]#:6SU#/@!EZ&IY#8+[28C#
M'KMKG:%4_GT!"!8I%]*(@OTB%9B*8X7(.X!;NQN8/QR;Z]QC*(=&AZ-ML at 2&
MX;L""(QPG$C0"I1:7Q$*EP5.""48&_T$\G\E4^\C<@Z:!-LA->N*-DHZ,%("
M-N)A])6-%N$T(Q1A- TC+KBF](38=R;=19Q!)P^&9%8U/\1^.H;_)@4$'(I#
MQLXJZMF0S=2"X*_[![GR1EB;P[K$:6D,6F<%QV?GM;EMQN==- at O+^V-N^6YY
MSSV8V5&"A[2I]:HPB7!<+3]PV)W at -4"$49B%_M2;B9[T]]X?`/MPMKF)POF;
MF2@%V=!$*?"_]$Z/3SN]?F?0PQBUVX7_!8-RU-1$:8S:Z)UBP-H_' Z.K":J
MZW;!0KF'PD*U0>Y?@0]+PJ\W&7OM?X--_&F4^#?^+&6(<9]=\606IFD("H!Q
M%@"[J.3NMA@,5(03Z %'-V5^%+ `PI8D'"TR+CP82^-)=NLGG,'GKXD/<A2@
M*L!$/! 0A&>LB8ABV%;._/F<^TD*>\I\0 W/0Y[NL^LR3H6+T.SX,"+=8;<A
ML&J1,7XW3SA8RSAA(;CN$.:$@4@&T(SD(B!,B1(?SI at OJ8&%AAG,LP at S?Q1.
MPVS))H#"CY9 at 5)-Y#%Z!8ISGX23"8._#I]>_O7_CO?OX]A/V at AV?H"TH=L/_
MQ[H#&EUQ"-"'$:TT]-L%:R$4,#?J;$_$198X6,+C8W8A)C<"W=Q0Y+KM")M@
M#>/#B?,,S,/,3Y82F *;E@&#K0@#T\[*<VH+KVR[9389G!>1U1)?=@(U2S#!
M5A)6=#TKR=-P962FTS7L'V["*I0&F(E1&>:<TAK>R"<5LDQR2G,\R*C^X>&!
M/CSG$:B^\)P%,7^$L0VSIL:6(!L;6P*7IO&HTS_%>'#0'QZ>/BX>+&$$8_N2
M]?O#HSX at M1K;EVYOP-HOW?Y QH//F;08A?A-,_#=-09^SQE3%N3J5^KVWO[V
M\14=;=C:]F6K+:0>R54BA<&#]_PY2=8Z! +%_3J8->T+R53I!*(.N(:5 at LC 
M$81!&/D(%'1RJ80>(6&SHU!:6Y[0VB0*DYN*D8W&,X'B`6/WYV at BY=X&CO??
M[SX.^BWVKW_E7=ZKO_T,W9[7(G'1DE G,"N%XLL6JTC"AK0#Z8\20J,!%1 ]
M<C!<.Z]VF.<%?#Q-YWSL!-,I>. at XR5HYF789!13?+X\B[BY)P at U$`< 4?C?F
M\PR"'&>WRBO-*KLPK49A*![B at 84\U)+8K*W:5! :==P#PS,0ISYE>5"$Q]-%
MP-FYS<;YX9UGH$0[=_G]$MBT/8&8-6U/H!1-6U'R_ZWM"32D:?M")S"YLJNE
MN@?PKI;O9JC.WOO8#UXO@:7A^ .96A%4N$S^>OON_1NVUX#;7XS+ at WKK\"1-
M3O6?8.*7_&:UQK>5E-%9P5J7-3!9_Y:IJJ8-V_>:MR;M":QHT[;2VJ*M'1SC
M!7[[\,3MT=7:<\:G> ?W_<;S"8SB$QB[DA%[C"X^@7'Z_^*^&YR?<@=M.[+D
M3VO/23G(]R1++5CD_7AW>%3%(N['!^)^'%.FI"GVB(3N'R>W at 0Y"5D8NQE9M
M-$ =YR[QR-5L`%VV76XWO=M7\5C/[9VR-H1E_6.Z?E>7\T(D5,[0<K)A^$,G
M<Z6)+M_5&YFZH1@@#<7]@[3^->/8!=O9:1E7,Z71E.ADXI#_4Q" 7>,S'F4Z
MY41HMXPI=E?D$W2 at H&YUFPPQ\@S-AU4S%VK,YLD+P1QY/U*;2_PK<"U5?_PB
MLGT_\X at G?A8GEW*P20()^/FU2P/+(_0]O.T.B!*#^;W]>+^0>55@=9EK;%+J
M'K4:4Q W7,SC^5#*0\A(+9?Z53QIPCG73'&H5N"@C&TD_U"GCWIHRXY.U1&K
M.(L23A+(\O6#_R?W)HMH+/S-)'(9.:&DM7;^-BVGD$&Q7$=*L:FY.52)F3SI
M6QRMF":O^ECI8E&"R3M4931$&DKD6T"^#@X$CTY.D4>G1^X at SSH2?VAJE(&[
M/,E36.^#F/MQ0 at H#93I.IRR;BAJJW'UAH38.B7*5L5 X9-)CZ7P\F66-:-\W
M(]F4='$G5:'\;50B"SR3I0KH;<0F4:-Y<3R- at 0%J5MN\BDN_\G0QS7XAE6A.
MC%L<J'5J4QIS;3P3NPOB_/" /J+D\)4^-PO:R-2LKG(KP]0&<&7 /(P[8;W!
ML'<X[ V:AG&UN&3IV_&P:\\D#EYB`1/\S$MDJLEOB(J4Z9&U)&?*BNK\<_,Z
MMW(AP at 9#;25R>2*^6;4;B=$&`\AXZL2_:;H1K+;<9E5(4\SD&^EXO0.:TTVS
MWUGLT2>DXQOPDR=U(EH#6BNI-? Z)P-A<1>."R?#P\.F`KL:)67 3X;]$YL.
MB&!<R"W\[!E.24;@&B/XIM3+9U+.^CQWSV#A7PEHS(WGW9<LBI.9/PW_R8.S
M/$(IQ)%@2]ZE5+2EYF/^-.%^L&2J\H\'/TCH<.(89-'S9$EFK$JA at TOQP@`+
M!5LM]NRB:R9?21=1+HEB*^(P2J'/*#/<S9<T',HA^5.7%::LD[AI.$K5%J;)
M6!T?QUK.Z@%,Z:J'VK#NJP$B:0&/ACU[>N_$[1VQ-OSLTJD.]A75/5B,L39(
MU#_<QLF?^^(NJ,D!,S_"MAO!FR?89O#Y`;9F@'0'2IQ68R_[CN8'8TN5`Z8^
M\]Y[C!%04:BH)X2CF<\B?LO2Q:A#RW&QKD-Z%S]B_ [D%QD?1WQ?C!75(K<A
MEJ9,TYB-0<, at WL R#E'2`J!S/Q$'6G\:BQWC[-9?PN!$EA-Y,)N*$JI&V2P^
MVBM5'[G%BK;Y+,P#D9""#79QP3[^]OZ]<0)7)U%%*@L6L]E2Q?FB6 at 57.IMG
M:"EDG5HERI>E4\K6A#D+O_D0]RQ2%F844 *9/!OO$Z at H"Q ,D4MF%TAWY]*L
MPW!5H:D!8X[157U@*K 4"-B:4D&#N%6 LQ#5%&A.T-/]%*P+! W DFZ1'^I0
M#N;9A^A.\4(P,(1=RK ,*(HS$(RY*/')1Z>JJJ6T"EE at 4245?@,9HD21S;UY
MG#I=!36)$R>,,C8%=-VSLW9[VC+/5T#H)(RH+#<"3UXD,Q+]+X(X at SC@A7&Q
ML&)^`$8*8#K)(<3OO-A_X1)IYLD69A=]R J<R1^E\11KL* O1#4&MB\R\6C*
MHZ\@1<@S#B[/X!;LA9KSV461J at CGRR&Q*=#.!4U=I*9:D$R<H*I)L)%CGJ8\
M<*4 at 8N<DB6=B'(E3`1U3-TY4(X;QN6$'TAQVI'9<2=5B!&MP!(6NHMGD'"QZ
M2D)G[J:<5M))=T+Q''CWC4\E?>:RB@,-/I:DV4#M3Z?Q+>AW>A,GV7B1HXLQ
M/ 0+F<+C6V BJ'N at WJEP=G!!]'G'@G?42-X-*L8W?/RG6)ZX:R1A59$)[-XX
M4ZL5CS"OP<#4H_LOH*(^A^;?'\<S'.78J9 Z?E9A6L&,4-V8MI#ES<$F##QG
M,Q_4J[@G0<S)) B7P)88_>?V'RS&#1C.*L*R[4,S>K7TT -](/Y7Q]B:<!3>
MV$^S<^$M+C5C/!3&5LMMAJ?D49H.`[(QAH/5XF4M!,F+*"NS&YO0*Z%)/&.+
MN7&CJ]U#=5 CXU^:Q? _.,?7:3SRRVJ48LFED/81!UN[`++P<L!"@9 JHQJQ
M0$!YG0_YGP\DOE4MCT#3I*:C'?(-RU*!A?@839$P]<@ZB(3#R;(0?>2C63PI
MJ)+0(1R%]KV(&EVOPF#$'%4E49?HWB]^^A,<0#\+"^T4MX64IZ&X-)#75IW^
M_02!5Z;J?>5J4URE6.J-G\)N\HCVLXK LF"M=7*5/_/,6&73!6'[+HY@:\ 5
MB[B+\S>9._&B at UX)YAQL)LZ*!26-@^7"*F01#/A?P<JEF=4_JH;%MWJZ=^GG
MQ8BNN2ULENPP*574V%DDU"1C_CA;@.<"@9=#W5QQ7^ [$1BM678:FXV,A*<X
M:[W28H.Y;T&2:G2,;,4/%45Y5KOL.F&.8GSK"L250DKR%D&-KP!X?/<C4(9S
MLIBB2<-J<A1][(V%KM/!*92G"Q43U9D8;&;HC&C);Q8#FFX>S-3(CW1V1IIN
M(_W;W.M1JVJ-7L*F[H_:(YT at M0U<H7JGSA M&7-J"Y>BB4.5#&<S'H3(WCI=
MU'KXN6# OL\HK;5(S5'5*\=Z7>3"8][XW]2)O!3HB[<G,'XHB5PE=%CM\(R9
MA7("^D3)<FHJ?#'>7G=N&8%>_%D\K/C!-Q]?]XK!F]-1,S:VE Y6[0M]XFFS
MGAPO2004\N MQ$78R((<W?B9,&$<SN\P!9FL.%$FAK!(%$4NG<ETB:@>EM::
M4F?&'W7U`,8[8OE%9%&UJR(E3^EEM3/?!;9J%2W"F+)\?8*(*WC=ZJM^X(*4
M@:Z\MJ&0Y^^?%GCROR93J#KK\!C?>&SW!B?N$5W2B6'B#K\P=LU+<UL=F6[.
MD\C"OQN7\?2<?AIA at +#>)O_MH8T&P*;6J?QT=9MV/('8\W9:QMX4B<#K"LPV
M+/ 2H<8BY6/U2E9.*A<%T[KF`K7Q,*>?,$=-?\$Z/8/.[":);SV>)+"U\N+;
M4Y& 2KX:>7I%V:9O+3O%6H]6:8FMSF4V]T at N\WV4LH7)YTVEI)24-3+)=(>/
MO3H&,6[EY?&Y$"N^PJ.Y4Z+89;NT(@%2+/C0K%%7MT1M%HL5BDM518/+'L69
M\MM+V\IP%67=H*E&V T(;)M)NS%84Z2XW$#@C>%/(O$E"LHR;TQ7+_3;JHJ@
M*G#K7JG5=\HE.TJOSP(;=F>A<B+&X[WB+!4CK-%*KV3%;L.[NQ(QC=/(;:]^
MP_&>T:7/68&"N5J'52]7O."G%*VR1KI%*/H7O1?;(@=@64WEM3^%W\XIG*8Z
M3,X"CLA,(13F*CG*W_\`KMS#/XC\Y7_V0,4V;:Q/6%6 at H&J]&R;F"DF=^O1<
M&6Q5DJX,FZ?J^JS;&QX>#KO'&Z3J:M%APFXP[/?JOJU'E)\.Y+<S'#S!:\<"
MR\[WOG4LL#1XZ;@V#V<FX.I at I(U=G?W3^> #E0Y6%;4-$X!K("40U<32%^#T
M^K(:6#7T)_]8\&0IO1_62@?Y=RFHILHP-)0LDE!&'693Y2)YC40>@91+;OVY
M!\%LLCS7Z #;)1-]QG%!C;,JV%HTFGAQ2OG&Q3?ZB&>7X 516%2AWYFJ'#X:
MN.*;.XZ.L(38Y!,V28::?AK?\L0;X?D"W5 "GGX"AB2]<9&%Q:$N$>4 at XR2[
M6@:%ULH`D[D.;LH%*P42](R<HXP&'W34(/X0U:=F^)9_UB4'U:H:.M:)Y!B+
M%C,1?*NR.I00"4PG(?%0+/=>8Q2 :B6[+!$W'?27IE1'8GH&=GG!>OF9N.:Q
M=O)XV9U2XE],N**J0\2$R3X)ND#V>_>/EBTZ9+J@!VD6$!K^K "75W?0WP]J
M]=EB/J4<3^H(3L[\.V,5'=9SI3.FZ,?@]J73:QF"@0&.L7Q8O7IR3_)ZTA6O
MP_1/3MS>L2&O]$Z,`F5Y$U3MHRL.,S[#FRW:*W&\:N5;\Z!7M:V_"\F\D,!T
M)B7/"_DL#6E>J^%3(RE]9H&QIV+UP/U$I6.-/5B702ULED950"OO]XR[AM(W
MU:C-]).OJ3,P)!?^+G"19J8%[NM:`?.&IVY(3HVZ6"J-9[;Q($*TE0U@^RX+
M0G%(\5'];$/(7W?%M^L->L?NJ7(26GA0%&N"?&FA6O6!O;SFN%,*=XZ)6I:W
M%2?4CI1%+8=YV)6K+:F_*-2@`R.[5U^A0 #"?640%*2P="^_8S0/EA#K%"K_
M at C3+9:AH(A *D:0Y2UZ'B0,8=)JA`"]22>_!)GETT!1C%6@)MX#'H]4_Q;%*
MC/J,Y1KFH+/*$%4Q$8J*"?AU#AC@=[MMFP";(IWM(6:E''+&G]]<>^^NWWPP
M9P6W9ID8F^)')964L\1E>A8;^=C NL31=*GW218TB0WEJ74(,!;1TA3X!6YD
M0N TN$MV;8:5HWB$ET[7B at 5;6;8=V/X*Y?2Q=@\>"CWY7_2)#IUBF8" ^5)J
MY2V!"#\CGF(2Q%QQ'F6MN7ZI%DQ9K]8$TEP at B@GCFH(EJU6WUAG9(*UE/AI0
M$"EO8;7?K8OW5A\/<Z2H#&=G9<$_*%<-T08(P;<5#14&KW56=75#91+$53[6
MFL00@'+<;DI?F0DK(NR'\M#'5AV5;5%SMXFM4GM4)JM*N6#INNJC*9]DN'!Q
M)"S@;%A75+<L:U["8 at 0%Z:%F*%"NZ)?2`,H4`EL1A*I85(19-=AK:P7,4-VU
M6:&U^2:KI\ &ZUC6V,="I8,T%,VN"5>TQDNRMP8+M?L'D\GYI6UI>?:KVQK.
M83-/5&QO?BW\1_&@Q?9:92[*,U<M5CJ;@-C$D:C5B!=)^D,M--9CX71-/-B*
MI6 C?8Q N_!Z@\NJS10), .DE3A0:HI'-N/D% :.@:=NKU33?,C/9'"N$]IE
M8*GG##;@3F4[I!-&/@G.K6,+-M(3678 at J_UTK)''A&OQ6.-(V]6]O:G2J+7S
M2-.Z@%,PF^%12[@.52D!/)76:+\))H:U([?HL+!V1!S?L&8B0$1KQQ<JG5<O
MKO:I_4FUM]I#2>1"=Q'HH%PJEM>NR+HW62UEQE=E[_'LNPQX`Z-FV?&-BT^J
M\ZX)G4 at HSPU=L]6(Z%=SJQ/(6J398GQC5,A&\6T5<D\>:4%.\!M-G!V3W6HG
M=BQS.#0`T_[J4%QB'C[:$25N2(PH<U-ZL.393A7EU?)-DF L_TDYO3=W8^_7
M192%,_X&#YJN)+,VFJ\_E+*]@Z(TUFGTP69%>^MW-ZDOUUNKQ*(UDV9K:R#B
M:Y2TOIA%+C O9BD/A6U7I1T8.B^F`;+5!Z$LZS4B26-,Y* HQJ(&I(P--]?'
M;Q^60DD#*<)+<09,/*"D85U@**O)T/FY54R,406T""5!2K!@;P:T\:02O]M*
M7PHPUNH7#9'S\WMK8#2B4AD,;0/-J+Z/HOK=UR(\T.[<*UQ3ZRMB>0-^O_5_
M4$L!`A0+% ````@`5VO*+&_4)8H(%P``C6(```X``````````0`@````````
E`'-U8FUO9'5L92YD:69F4$L%!@`````!``$`/ ```#07````````
`
end







From david.abrahams at rcn.com  Mon Jun 10 20:41:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 14:41:03 -0400
Subject: [C++-sig] Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com> <ae2qko$chi$1@main.gmane.org>
Message-ID: <01ee01c210ae$83206f10$6601a8c0@boostconsulting.com>

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


> Here is the latest diff that includes the nested class support. I've also
> rearranged and tidied up a few items. Nested classes can be created
before
> their parents without error.
>
> However I'm not sure that I like it.
>
> maybe instead of:
>
>     class_<ctest>("ctest")
>         .def_init()
>         .def("set_v", &ctest::set_v);
>     class_<ctest::ctest2>("ctest.ctest2")
>         .def_init()
>         .def_readwrite("n", &ctest::ctest2::n);
>
> we should do:
>
>     class_<ctest>("ctest")
>         .def_init()
>         .def("set_v", &ctest::set_v);
>         .def("ctest2", class_<ctest::ctest2>());
>     class_<ctest::ctest2>()
>         .def_init()
>         .def_readwrite("n", &ctest::ctest2::n);

I guess I didn't make myself clear earlier. I was suggesting

    class_<ctest> c("ctest")
        .def_init()
        .def("set_v", &ctest::set_v);
        ;

    class_<ctest::ctest2>("ctest2", c)
        .def_init()
        .def_readwrite("n", &ctest::ctest2::n)
        ;


which nicely enforces the existence of c before ctest2 is declared.

> This could be achieved as once a particular class has been registered we
can
> find its object from the typeinfo, rather than by name.

Why do you prefer your second approach? Seems messier than the first to me.





From david.abrahams at rcn.com  Mon Jun 10 20:49:21 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 14:49:21 -0400
Subject: [C++-sig] Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net> <007901c21080$b932aec0$6601a8c0@boostconsulting.com> <008501c21090$d890d2a0$cdbe8aca@asiagate.net>
Message-ID: <020101c210af$cc3e4770$6601a8c0@boostconsulting.com>

From: "joel de guzman" <djowel at gmx.co.uk>

> > What I'm heading toward is a two-level interface: a smart pointer type
> > ("reference<>", or pick a better name) which can be null, for low-level
> > interfacing with Python, and a higher-level type, "object", which can
never
> > be null, and which provides a nice Python-objec-like interface.
>
> Hmmm, so it seems that we have two types which are strikingly
> similar to what we have in C++. 1) an object-reference that
> cannot be null and 2) an object-pointer that can be null. While
> object is indeed a nice name, the presence of another lower
> level class that can point to a null object seems to suggest
> (at least to me) the ref and ptr prefix. obj_ref and obj_ptr
> comes to mind. Or, if you want to keep the nice "object" as
> a name, just name the other "object_ptr". After all, this is a lower
> level class that the client should avoid using if possible, so the
> longer name is ok.
>
>     object: cannot be null [high level interface]
>     object_ptr: can be null [low level interface]

The problem is that object_ptr needs to be parametrized on the type it's
pointing at (e.g. PyObject, PyTypeObject...). object_ptr<PyObject> is
redundant and object_ptr<PyTypeObject> is sort-of inaccurate.

So my latest thought is that the smart pointer class is spelled "handle",
and the one currently spelled "ref" is spelt "handle<>". I could supply

    typedef handle<> obj_ptr;

or

    typedef handle<> hdl;

or

    typedef handle<> objptr;

but I'm resisting: I hate unpronounceable names.

-Dave






From miked at sinistergames.com  Mon Jun 10 21:02:30 2002
From: miked at sinistergames.com (Mike Dickheiser)
Date: Mon, 10 Jun 2002 15:02:30 -0400
Subject: [C++-sig] RE: passing Boost wrapped classes (refs and/or pointers) to/from Python and C++
Message-ID: <KJENIABEMDBBGDDMCPLHKEBPCAAA.miked@sinistergames.com>

I'm starting to feel a bit like Alice in Boostland ;)

I entered the world of boost through
http://www.boost.org/libs/python/doc/index.html, and read through all the
documentation available on that page (items 1 - 15 in the table of
contents). Nowehere in that documentation did I see discussion on how to
call a Python function from C++, and so I assumed that I had to use the
standard method of:

PyObject* pValue = PyObject_CallObject(pPythonFunc, pArgs);

What I wanted to know was how to pass/pack/put-in/convert a Vector3 into
pArgs (assuming Vector3 has been wrapped by Boost v1). I know how to put
integers, floats, strings and other basic types into "pArgs", but not custom
types like my Vector3. I also needed to know how to get a Vector3 out of
pValue, assuming that's what the called python function returns.

I looked into the usual Py_BuildValue stuff and tuple-packing, but still had
no clue, which led me to seek answers at the SIG.

Now I see in your response a reference to

boost::python::callback<ResultType>::call(arg1, arg2, arg3...);

This is something I haven't seen before at all in any of the documents at
the previously mentioned address, but looks a lot like what I need. Where
can I find the documentation that includes this? I'm assuming I can find v1
docs at the sourceforge.net address you gave, but if that's incorrect please
let me know.

Thanks again,
Mike









From daveh at cadlink.com  Mon Jun 10 21:53:12 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 10 Jun 2002 15:53:12 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com> <ae2qko$chi$1@main.gmane.org> <01ee01c210ae$83206f10$6601a8c0@boostconsulting.com>
Message-ID: <ae3039$69a$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:01ee01c210ae$83206f10$6601a8c0 at boostconsulting.com...
>
> I guess I didn't make myself clear earlier. I was suggesting
>
>     class_<ctest> c("ctest")
>         .def_init()
>         .def("set_v", &ctest::set_v);
>         ;
>
>     class_<ctest::ctest2>("ctest2", c)
>         .def_init()
>         .def_readwrite("n", &ctest::ctest2::n)
>         ;
>
>
> which nicely enforces the existence of c before ctest2 is declared.
>

This is probably straight forward as well, maybe I'll code it and see if
there are in wrinkles when I do a few tests.

> > This could be achieved as once a particular class has been registered we
> can
> > find its object from the typeinfo, rather than by name.
>
> Why do you prefer your second approach? Seems messier than the first to
me.

It just seemed to be consistent with defining other attributes of a class
such as member functions and member variables.










From djowel at gmx.co.uk  Mon Jun 10 22:04:38 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Tue, 11 Jun 2002 04:04:38 +0800
Subject: [C++-sig] Retiring "ref", etc.
References: <020101c210af$cc3e4770$6601a8c0@boostconsulting.com>
Message-ID: <01cc01c210ba$344fc640$cdbe8aca@asiagate.net>

----- Original Message ----- 
From: "David Abrahams" 

> >     object: cannot be null [high level interface]
> >     object_ptr: can be null [low level interface]
> 
> The problem is that object_ptr needs to be parametrized on the type it's
> pointing at (e.g. PyObject, PyTypeObject...). object_ptr<PyObject> is
> redundant and object_ptr<PyTypeObject> is sort-of inaccurate.
> 
> So my latest thought is that the smart pointer class is spelled "handle",
> and the one currently spelled "ref" is spelt "handle<>". I could supply
> 
>     typedef handle<> obj_ptr;
> 
> or
> 
>     typedef handle<> hdl;
> 
> or
> 
>     typedef handle<> objptr;
> 
> but I'm resisting: I hate unpronounceable names.

Yes. You wrote the naming guidelines ;-)

"handle" is nice! How about:

    typedef handle<PyObject> object_ptr;
    typedef handle<PyTypeObject> type_ptr;

Cheers,
--Joel








From whisper at oz.net  Mon Jun 10 23:00:02 2002
From: whisper at oz.net (David LeBlanc)
Date: Mon, 10 Jun 2002 14:00:02 -0700
Subject: [C++-sig] (no subject)
Message-ID: <GCEDKONBLEFPPADDJCOEGEOPDHAA.whisper@oz.net>

Is CVS the best source of Boost for starting a new python wrapping project?
Is CVS kept "clean" (buildable)?

TIA,

David LeBlanc
Seattle, WA USA





From david.abrahams at rcn.com  Tue Jun 11 00:28:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 18:28:28 -0400
Subject: [C++-sig] RE: passing Boost wrapped classes (refs and/or pointers) to/from Python and C++
References: <KJENIABEMDBBGDDMCPLHKEBPCAAA.miked@sinistergames.com>
Message-ID: <029101c210ce$a04132d0$6601a8c0@boostconsulting.com>

From: "Mike Dickheiser" <miked at sinistergames.com>


> I'm starting to feel a bit like Alice in Boostland ;)
>
> I entered the world of boost through
> http://www.boost.org/libs/python/doc/index.html, and read through all the
> documentation available on that page (items 1 - 15 in the table of
> contents). Nowehere in that documentation did I see discussion on how to
> call a Python function from C++, and so I assumed that I had to use the
> standard method of:
>
> PyObject* pValue = PyObject_CallObject(pPythonFunc, pArgs);
>
> What I wanted to know was how to pass/pack/put-in/convert a Vector3 into
> pArgs (assuming Vector3 has been wrapped by Boost v1).

Ah, very much clearer, thank you.

> I know how to put
> integers, floats, strings and other basic types into "pArgs", but not
custom
> types like my Vector3. I also needed to know how to get a Vector3 out of
> pValue, assuming that's what the called python function returns.

You don't want to do this, but:

The standard technique is to use from_python(py_obj, type<Vector3&>()) to
get the Vector3 reference /out/ of the PyObject* py_obj, and
to_python(vec3) to copy a Vector3 object vec3 into a new python object.

What you want to do is to use callback<> as described earlier; it takes
care of the to_/from_python stuff for you.

> I looked into the usual Py_BuildValue stuff and tuple-packing, but still
had
> no clue, which led me to seek answers at the SIG.
>
> Now I see in your response a reference to
>
> boost::python::callback<ResultType>::call(arg1, arg2, arg3...);
>
> This is something I haven't seen before at all in any of the documents at
> the previously mentioned address, but looks a lot like what I need.

It is a lot like what you need. However, you mentioned wanting to pass
pointers and references as argumets to Python functions; I assume you meant
without copying the pointee/referent. If you need to do that, you'll need
to use v2 of the library.

> Where can I find the documentation that includes this?

Nowhere :(. But, you can look at the section on overridable virtual
functions (http://www.boost.org/libs/python/doc/overriding.html) which uses
a similar construct

    boost::python::callback<ResultType>::call_method(...)

> I'm assuming I can find v1
> docs at the sourceforge.net address you gave, but if that's incorrect
please
> let me know.

That's incorrect. The sourceforge.net address I gave points you at the v2
documentation under development.
The v1 docs, such as they are, are all at www.boost.org/libs/python/doc
There's lots of undocumented stuff in v1 of Boost.Python; I'm correcting
that for v2.

HTH,
Dave






From david.abrahams at rcn.com  Tue Jun 11 00:30:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 18:30:38 -0400
Subject: [C++-sig] Retiring "ref", etc.
References: <020101c210af$cc3e4770$6601a8c0@boostconsulting.com> <01cc01c210ba$344fc640$cdbe8aca@asiagate.net>
Message-ID: <029201c210ce$a068df10$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "joel de guzman" <djowel at gmx.co.uk>
To: <c++-sig at python.org>
Sent: Monday, June 10, 2002 4:04 PM
Subject: Re: [C++-sig] Retiring "ref", etc.


>
> ----- Original Message -----
> From: "David Abrahams"
>
> > >     object: cannot be null [high level interface]
> > >     object_ptr: can be null [low level interface]
> >
> > The problem is that object_ptr needs to be parametrized on the type
it's
> > pointing at (e.g. PyObject, PyTypeObject...). object_ptr<PyObject> is
> > redundant and object_ptr<PyTypeObject> is sort-of inaccurate.
> >
> > So my latest thought is that the smart pointer class is spelled
"handle",
> > and the one currently spelled "ref" is spelt "handle<>". I could supply
> >
> >     typedef handle<> obj_ptr;
> >
> > or
> >
> >     typedef handle<> hdl;
> >
> > or
> >
> >     typedef handle<> objptr;
> >
> > but I'm resisting: I hate unpronounceable names.
>
> Yes. You wrote the naming guidelines ;-)
>
> "handle" is nice! How about:
>
>     typedef handle<PyObject> object_ptr;

For people who prefer underscores to angle brackets? ;-)

object_ptr
handle<>

Which one is easier?

>     typedef handle<PyTypeObject> type_ptr;

I like that one. I'd be willing to supply object_ptr just for consistency.

-Dave






From david.abrahams at rcn.com  Tue Jun 11 02:31:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 10 Jun 2002 20:31:07 -0400
Subject: [C++-sig] (no subject)
References: <GCEDKONBLEFPPADDJCOEGEOPDHAA.whisper@oz.net>
Message-ID: <02c801c210df$d8dcdde0$6601a8c0@boostconsulting.com>

From: "David LeBlanc" <whisper at oz.net>


> Is CVS the best source of Boost for starting a new python wrapping
project?

It depends how much stability you require.
Also, if you are working with Boost.Python v1, I would definitely recommend
NOT using the CVS, since it is essentially unchanged since 1.28.0

However, I would recommend starting with Boost.Python v2 if you're starting
fresh, since it has a future. For that you will need the CVS (HEAD plus the
mpl-development branch of boost/mpl).

> Is CVS kept "clean" (buildable)?

We try, but you can't test everywhere simultaneously. Also, occasionally a
checkin to another boost library will break part of Boost.Python.

-Dave






From daveh at cadlink.com  Tue Jun 11 03:48:46 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 10 Jun 2002 21:48:46 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com> <ae2qko$chi$1@main.gmane.org> <01ee01c210ae$83206f10$6601a8c0@boostconsulting.com>
Message-ID: <ae3ku0$1bg$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:01ee01c210ae$83206f10$6601a8c0 at boostconsulting.com...
> >     class_<ctest::ctest2>()
> >         .def_init()
> >         .def_readwrite("n", &ctest::ctest2::n);
>
> I guess I didn't make myself clear earlier. I was suggesting
>
>     class_<ctest> c("ctest")
>         .def_init()
>         .def("set_v", &ctest::set_v);
>         ;
>
>     class_<ctest::ctest2>("ctest2", c)
>         .def_init()
>         .def_readwrite("n", &ctest::ctest2::n)
>         ;
>
I was just taking a deeper look at this and realised one slight problem. The
class_ constructor that takes no arguments and attempts to find its name
from the typeid will be unfortunate when it is extended in this way.

ie

    class_(class_<...>& c);

Of course this will look like a duck, walk like a duck and bark like a
dog...

This probably means putting in some superfluous argument so it doesn't look
like a copy constrctor.

Dave Hawkes









From djowel at gmx.co.uk  Tue Jun 11 04:14:33 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Tue, 11 Jun 2002 10:14:33 +0800
Subject: [C++-sig] Retiring "ref", etc.
References: <020101c210af$cc3e4770$6601a8c0@boostconsulting.com> <01cc01c210ba$344fc640$cdbe8aca@asiagate.net> <029201c210ce$a068df10$6601a8c0@boostconsulting.com>
Message-ID: <009901c210f3$5b59bbe0$84be8aca@asiagate.net>

----- Original Message ----- 
From: "David Abrahams" 

> For people who prefer underscores to angle brackets? ;-)
> 
> object_ptr
> handle<>
> 
> Which one is easier?

If it's expected to be used in less than 1% of the time,
compared to object, then a bit of typing wouldn't hurt ;)
And in fact might be beneficial. Consider also that it is a 
low level and relatively unsafe (possibility of a dangling 
pointer) interface, then I won't hesitate to type in a bit more, 
ala reinterpret_cast<> and its brethren :-)

2c W :-) --Joel





From daveh at cadlink.com  Tue Jun 11 05:45:32 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 10 Jun 2002 23:45:32 -0400
Subject: [C++-sig] BPL and embedding python
Message-ID: <ae3rov$r0h$1@main.gmane.org>

I've noticed that more and more people are attempting to embed python in
applications and documentation  on how to do this effectively is quite
scarce. One of the strengths of boost is the ability to create a c++ class
instance and override some of its members in python, but use the actual
class instance from within c++. In fact you can create a class instance,
modify some of its members using on the fly generated python code and then
pass the c++ instance back to yor c++ code.

I've done this with with boost V1 along these lines:

(Make sure your boost extension module is already imported.)

PyObject  *pPyModule = PyImport_AddModule(const_cast<char *>("MyModule"));
PyObject  *pPyDict = PyModule_GetDict(pPyModule);
PyObject  *pPyClass = PyDict_GetItemString(pPyDict, const_cast<char
*>("MyClass"));
if(pPyClass == NULL) {

    // The python code overiding the desired members of your c++/python
class.
    PyRun_String("python...code", Py_file_input, pPyDict, pPyDict);
    pPyClass = PyDict_GetItemString(*ppPyDict, const_cast<char
*>("MyClass"));
}

// pPyClass will now contain the python object corresponding to our c++
class
// Next we need instantiate this for our c++ code

// just in case
if(pPyClass) {
    // Remember the Python GIL, I just use my own class here to deal with
this
    // note that as this call is initiated from c++ rather than a callback
we have to be careful
    //  ...especially if you are using pythonwin
    CReEnterLeavePython _celp;
    // create an instance of our class
    // OK callback is a misnomer in this case!
    PyObject *pPyInstance = python::callback<PyObject *>::call(pPyClass);
    if(pPyInstance) {
        MyClass *pInstance = python::from_python(pPyInstance,
python::type<MyClass *>());
        if(pInstance) {
            // return our instance here
            // ... use our pInstance as a c++ class, ie
            return pInstance;
        } else {
            Py_DECREF(pPyInstance);
        }
    }
}

The only real problem here is that you cannot do this:

delete pInstance;

where pInstance is created as above. Instead we must decrement its PyObject
reference when it is no longer needed, ie:

{
    CReEnterLeavePython _celp;
    Py_DECREF(pPyInstance);
}

The best way of dealing with this is to remember the self passed to the
constructor in python and then create a del method such as:

class MyClass
{
public:
    virtual PyObject *GetPyObject()
    {
        return NULL;
    }
    void del()
    {
        if(GetPyObject()) {
            CReEnterLeavePython _celp;
            Py_DECREF(GetPyObject());
        } else
            assert(false);
    }
}
protected:
    MyClass() {}
    virtual ~MyClass();
private:
     PyObject *self;
};

class MyClass_callback : public MyClass
{
public:
    MyClass_callback(PyObject *self_) : MyClass(), self(self_) {}
    ~MyClass_callback() {}
    virtual PyObject *GetPyObject()
    {
        return self;
    }
private:
     PyObject *self;
};

We would have to use something like:

 class_builder<MyClass, MyClass_callback> MyClass_class(module, "MyClass");

to declare this class to python using boost.



Remember this is NOT complete code and just an outline of how to proceed.

The fly in the ointment is not being able to directly delete the class
instances (Dave, do you have any ideas ?)


Dave Hawkes









From miked at sinistergames.com  Tue Jun 11 16:21:56 2002
From: miked at sinistergames.com (Mike Dickheiser)
Date: Tue, 11 Jun 2002 10:21:56 -0400
Subject: [C++-sig] re: passing Boost wrapped classes
Message-ID: <KJENIABEMDBBGDDMCPLHIECBCAAA.miked@sinistergames.com>

Ok, Dave, thank you.

It looks like I probably will be moving to V2, then. As I mentioned before,
I had to build Python and Boost both as a static lib because the Xbox
doesn't support the use of .dll's. Off the top of your head do you know of
any major difficulties with doing this to V2? I wouldn't expect any, but
thought I'd ask anyway just in case.

By the way, how do I post responses that stay "within the thread"? Each time
I've posted so far it has started a new thread. The only address I know to
post to is "c++-sig at python.org", and I don't see any reply buttons
anywhere...






From david.abrahams at rcn.com  Tue Jun 11 16:37:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 10:37:53 -0400
Subject: [C++-sig] re: passing Boost wrapped classes
References: <KJENIABEMDBBGDDMCPLHIECBCAAA.miked@sinistergames.com>
Message-ID: <002101c21156$0b4adb30$6501a8c0@boostconsulting.com>

From: "Mike Dickheiser" <miked at sinistergames.com>


> Ok, Dave, thank you.
>
> It looks like I probably will be moving to V2, then. As I mentioned
before,
> I had to build Python and Boost both as a static lib because the Xbox
> doesn't support the use of .dll's. Off the top of your head do you know
of
> any major difficulties with doing this to V2? I wouldn't expect any, but
> thought I'd ask anyway just in case.

No, but you'll need to define BOOST_PYTHON_STATIC_LIB, and there may be a
few other things you'll need to adjust. It's not a configuration I support
directly, or use for testing (though some users have been doing this).

> By the way, how do I post responses that stay "within the thread"? Each
time
> I've posted so far it has started a new thread. The only address I know
to
> post to is "c++-sig at python.org", and I don't see any reply buttons
> anywhere...

Buttons are a function of email and/or newsreader clients. I have no clue
about your software.

I just reply to the posts I get in my inbox in the usual way, and they show
up threaded.

-Dave





From whisper at oz.net  Tue Jun 11 16:49:12 2002
From: whisper at oz.net (David LeBlanc)
Date: Tue, 11 Jun 2002 07:49:12 -0700
Subject: [C++-sig] re: passing Boost wrapped classes
In-Reply-To: <KJENIABEMDBBGDDMCPLHIECBCAAA.miked@sinistergames.com>
Message-ID: <GCEDKONBLEFPPADDJCOECECMDIAA.whisper@oz.net>

Posts get threaded by their subject line and the "RE:" is a clue that it's a
reply to an earlier post that this post should be threaded onto. This "RE:"
tag is autmatically added when you hit "Reply" in one of the places
mentioned below.

Since, from the look of your mail headers, you are using Outlook, you should
see "Reply", "Reply to All" and "Forward" buttons on the toolbar. If you
don't see such a toolbar, go to Tools|Customize and then click on the
toolbars tab to add the correct toolbar to the top of your outlook windows.
These actions are also available on the Actions pulldown menu and also on
the right-click popup menu when you select and then right click a message in
the top message list pane.

HTH,

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Mike Dickheiser
> Sent: Tuesday, June 11, 2002 7:22
> To: c++-sig at python.org
> Subject: [C++-sig] re: passing Boost wrapped classes
>
>
> Ok, Dave, thank you.
>
> It looks like I probably will be moving to V2, then. As I
> mentioned before,
> I had to build Python and Boost both as a static lib because the Xbox
> doesn't support the use of .dll's. Off the top of your head do you know of
> any major difficulties with doing this to V2? I wouldn't expect any, but
> thought I'd ask anyway just in case.
>
> By the way, how do I post responses that stay "within the
> thread"? Each time
> I've posted so far it has started a new thread. The only address I know to
> post to is "c++-sig at python.org", and I don't see any reply buttons
> anywhere...
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Tue Jun 11 17:19:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 11:19:02 -0400
Subject: [C++-sig] re: passing Boost wrapped classes
References: <GCEDKONBLEFPPADDJCOECECMDIAA.whisper@oz.net>
Message-ID: <004001c2115b$a7271e10$6501a8c0@boostconsulting.com>

From: "David LeBlanc" <whisper at oz.net>


> Posts get threaded by their subject line

I used to think that, too. However, now I think they get threaded according
to their message headers (which are usually hidden when you read the
message in a mail client).

-Dave





From niki at vintech.bg  Tue Jun 11 17:43:41 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Tue, 11 Jun 2002 18:43:41 +0300
Subject: [C++-sig] re: passing Boost wrapped classes
References: <GCEDKONBLEFPPADDJCOECECMDIAA.whisper@oz.net> <004001c2115b$a7271e10$6501a8c0@boostconsulting.com>
Message-ID: <3D061AAD.3080602@vintech.bg>

David Abrahams wrote:
> From: "David LeBlanc" <whisper at oz.net>
> 
> 
>>Posts get threaded by their subject line
> 
> 
> I used to think that, too. However, now I think they get threaded according
> to their message headers (which are usually hidden when you read the
> message in a mail client).
> 

Some mail clients can switch threading mode - e.g. "The bat"

Niki Spahiev





From rwgk at yahoo.com  Tue Jun 11 19:42:33 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 11 Jun 2002 10:42:33 -0700 (PDT)
Subject: [C++-sig] current spelling of from_python<>?
Message-ID: <20020611174233.35388.qmail@web20207.mail.yahoo.com>

Until about a week ago the code below worked as a placeholder
for a user-level from_python<> converter:

  template <typename U>
  struct extractor
  {
    static
    U
    get(PyObject* obj)
    {
      Py_INCREF(obj);
      return converter::callback_from_python<U>()(obj);
    }
  };

converter::callback_from_python<> is defined in the obsolete file
converter/callback.hpp. What should I be using instead?

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Tue Jun 11 19:53:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 13:53:06 -0400
Subject: [C++-sig] current spelling of from_python<>?
References: <20020611174233.35388.qmail@web20207.mail.yahoo.com>
Message-ID: <00d901c21170$d8c454f0$6501a8c0@boostconsulting.com>

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


> Until about a week ago the code below worked as a placeholder
> for a user-level from_python<> converter:
> 
>   template <typename U>
>   struct extractor
>   {
>     static
>     U
>     get(PyObject* obj)
>     {
>       Py_INCREF(obj);
>       return converter::callback_from_python<U>()(obj);
>     }
>   };
> 
> converter::callback_from_python<> is defined in the obsolete file
> converter/callback.hpp. What should I be using instead?

    converter::return_from_python<> in converter/return_from_python.hpp

also see

    converter::arg_to_python<> in converter/arg_to_python.hpp

-Dave





From rwgk at yahoo.com  Tue Jun 11 20:05:36 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 11 Jun 2002 11:05:36 -0700 (PDT)
Subject: [C++-sig] implicit imports?
Message-ID: <20020611180536.18158.qmail@web20201.mail.yahoo.com>

Let certain Boost.Python V2 bindings for std::vector be defined in a
std_vector extension module. E.g.:

import std_vector
d = std_vector.double()

Now suppose that other V2 extension modules contain functions that take
a std::vector<double> as an argument or return a std::vector<double>.
It is my understanding that the conversions from/to std::vector will
succeed if the user imports std_vector before any of these functions
is used, but will fail otherwise. Correct?

Is it possible to ensure that the conversions will succeed even if the
user does not explicitly import std_vector?

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Tue Jun 11 20:13:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 14:13:28 -0400
Subject: [C++-sig] implicit imports?
References: <20020611180536.18158.qmail@web20201.mail.yahoo.com>
Message-ID: <010e01c21174$599c4fd0$6501a8c0@boostconsulting.com>

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

> Let certain Boost.Python V2 bindings for std::vector be defined in a
> std_vector extension module. E.g.:
>
> import std_vector
> d = std_vector.double()
>
> Now suppose that other V2 extension modules contain functions that take
> a std::vector<double> as an argument or return a std::vector<double>.
> It is my understanding that the conversions from/to std::vector will
> succeed if the user imports std_vector before any of these functions
> is used, but will fail otherwise. Correct?

Yes.

> Is it possible to ensure that the conversions will succeed even if the
> user does not explicitly import std_vector?

You can have the dependent modules load the std_vector module from their
init functions.

HTH,
Dave






From david.abrahams at rcn.com  Tue Jun 11 21:53:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 15:53:37 -0400
Subject: [C++-sig] May 2002 progress report
Message-ID: <018901c21181$ae43af80$6501a8c0@boostconsulting.com>

The belated May progress report for Boost.Python is now available at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/Apr2002.html?rev=HEAD&content-type=text/html

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 rwgk at yahoo.com  Tue Jun 11 23:12:09 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 11 Jun 2002 14:12:09 -0700 (PDT)
Subject: [C++-sig] current spelling of from_python<>?
In-Reply-To: <00d901c21170$d8c454f0$6501a8c0@boostconsulting.com>
Message-ID: <20020611211209.46046.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> 
> > Until about a week ago the code below worked as a placeholder
> > for a user-level from_python<> converter:
> > 
> >   template <typename U>
> >   struct extractor
> >   {
> >     static
> >     U
> >     get(PyObject* obj)
> >     {
> >       Py_INCREF(obj);
> >       return converter::callback_from_python<U>()(obj);
> >     }
> >   };
> > 
> > converter::callback_from_python<> is defined in the obsolete file
> > converter/callback.hpp. What should I be using instead?
> 
>     converter::return_from_python<> in converter/return_from_python.hpp

Using return_from_python<>, extractor<T> works fine. Thanks!
Is it expected that extractor<T const&> does not work for
converting the elements of a Python tuple of Python float or int?

I also need this convertible() test:

    static void* convertible(PyObject* obj)
    {
      using namespace boost::python;
      tuple t = list_or_tuple_as_tuple(obj);
      if (!ContainerAdaptor::check_size(
        type<ContainerType>(), t.size())) return 0;
      for(std::size_t i=0;i<t.size();i++) {
        arg_from_python<container_element_type const&> from_py(t[i].get());
        if (!from_py.convertible()) return 0;
      }
      return obj;
    }

Observations:

The code as shown works with Linux/gcc304, but VC6 reports
"indirect_traits.hpp(308) : error C2057: expected constant expression."
arg_from_python<container_element_type> also works with Linux/gcc304, but VC6
reports "fatal error C1001: INTERNAL COMPILER ERROR."
Should/could I use a different approach for testing convertibility that VC6
might not choke on?

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Tue Jun 11 23:37:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 17:37:30 -0400
Subject: [C++-sig] current spelling of from_python<>?
References: <20020611211209.46046.qmail@web20204.mail.yahoo.com>
Message-ID: <020d01c21190$6397a2c0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Tuesday, June 11, 2002 5:12 PM
Subject: Re: [C++-sig] current spelling of from_python<>?


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> >
> >
> > > Until about a week ago the code below worked as a placeholder
> > > for a user-level from_python<> converter:
> > >
> > >   template <typename U>
> > >   struct extractor
> > >   {
> > >     static
> > >     U
> > >     get(PyObject* obj)
> > >     {
> > >       Py_INCREF(obj);
> > >       return converter::callback_from_python<U>()(obj);
> > >     }
> > >   };
> > >
> > > converter::callback_from_python<> is defined in the obsolete file
> > > converter/callback.hpp. What should I be using instead?
> >
> >     converter::return_from_python<> in converter/return_from_python.hpp
>
> Using return_from_python<>, extractor<T> works fine. Thanks!
> Is it expected that extractor<T const&> does not work for
> converting the elements of a Python tuple of Python float or int?

return_from_python<> converts Python function return values to C++

Rhetorical question: does the Python int contain an int lvalue? Does the
Python float contain a float lvalue?
Answer: no, a Python int contains a C++ long; a python float contains a C++
double.
So what would the int const& refer to?

Question: OK, what about long const&?
Answer: Python doesn't actually expose the contained long lvalue as part of
the documented interface, so we can't touch it.

[short answer: yes]

> I also need this convertible() test:
>
>     static void* convertible(PyObject* obj)
>     {
>       using namespace boost::python;
>       tuple t = list_or_tuple_as_tuple(obj);
>       if (!ContainerAdaptor::check_size(
>         type<ContainerType>(), t.size())) return 0;
>       for(std::size_t i=0;i<t.size();i++) {
>         arg_from_python<container_element_type const&>
from_py(t[i].get());
>         if (!from_py.convertible()) return 0;
>       }
>       return obj;
>     }
>
> Observations:
>
> The code as shown works with Linux/gcc304, but VC6 reports
> "indirect_traits.hpp(308) : error C2057: expected constant expression."
> arg_from_python<container_element_type> also works with Linux/gcc304, but
VC6
> reports "fatal error C1001: INTERNAL COMPILER ERROR."
> Should/could I use a different approach for testing convertibility that
VC6
> might not choke on?

Try breaking up the definition of value into little steps so that the
expression is simpler.

G'luck,
Dave






From ssmith at magnet.fsu.edu  Tue Jun 11 23:51:43 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Tue, 11 Jun 2002 17:51:43 -0400
Subject: [C++-sig] Constructor w/ string
In-Reply-To: <20020531164256.41380.qmail@web20210.mail.yahoo.com>
Message-ID: <NFBBINAMBILHLOCDJKAEOEBCCCAA.ssmith@magnet.fsu.edu>

Greetings,

A simple problem I'll bet. I have three constructors in my
(now very simple) class. One that takes no arguments, one that
does self-construction, and one that takes a string. When I
export these in Boost 1.25.0 all three work fine, but with 1.28.0
only the first two work , the third always dies with complaints about
a Debug Assertion Failure in dgbheap.c from the Python IDE.

I hope someone can help me figure out the following:

1.) How to I change the export function to make this work again?
2.) Is there documentation that has this in detail?

I often look through http://mail.python.org/pipermail/c++-sig/ and have
used the new Google search on the main WWW page, but haven't found anything.
The getting_started2 example works OK and it also has a construtor that
uses a string, but upon exiting the interpreter it gives the same error
message when I add in empty & self constructors. (I am unclear on why that
example needs <iostream> and why exactly the const string& must be just
string
in the corresponding init function, however neither of these influences my
result.)

I am using Python 2.2.1 & MSVC++ 6.0.  My class header, code, and the
Boost.Python interface are below if that helps.  Note that in my non-clipped
verson I do actually use the string I construct with, same problem though.

Thanks for any help.
Scott

/* Isotope.h ************************************************************/
# include <string>
class Isotope
{
int Iso;					// An isotope index

public:

Isotope();
Isotope(const Isotope& I);
Isotope(const std::string& symbol);
};

/* Isotope.cc ***********************************************************/

#include "Isotope.h"		// Include the interface
#include <string>			// Include libstd++ string class

Isotope::Isotope()                          { Iso = 0; }
Isotope::Isotope(const Isotope& I)          { Iso = I.Iso;}
Isotope::Isotope(const std::string& symbol) { Iso = 0; }

/* PythonInterface.h ****************************************************/

#include "Isotope.h"
#include <boost/python/class_builder.hpp>
#include <boost/python/reference.hpp>
namespace python = boost::python;

BOOST_PYTHON_MODULE_INIT(gamma)
  {
    python::module_builder gamma("gamma");
    python::class_builder<Isotope> Isotope_class(gamma, "Isotope");
    Isotope_class.def(python::constructor<>());
    Isotope_class.def(python::constructor<Isotope>());
    Isotope_class.def(python::constructor<std::string>());
  }



-----------------------------------------
-----------------------------------------

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From rwgk at yahoo.com  Tue Jun 11 23:55:10 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 11 Jun 2002 14:55:10 -0700 (PDT)
Subject: [C++-sig] current spelling of from_python<>?
In-Reply-To: <020d01c21190$6397a2c0$6501a8c0@boostconsulting.com>
Message-ID: <20020611215510.63085.qmail@web20210.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > Observations:
> >
> > The code as shown works with Linux/gcc304, but VC6 reports
> > "indirect_traits.hpp(308) : error C2057: expected constant expression."
> > arg_from_python<container_element_type> also works with Linux/gcc304, but
> VC6
> > reports "fatal error C1001: INTERNAL COMPILER ERROR."
> > Should/could I use a different approach for testing convertibility that
> VC6
> > might not choke on?
> 
> Try breaking up the definition of value into little steps so that the
> expression is simpler.

Indeed,

        PyObject* ti = t[i].get();
        arg_from_python<container_element_type const&> from_py(ti);

works! That was just too obvious.
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Wed Jun 12 00:02:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 18:02:06 -0400
Subject: [C++-sig] current spelling of from_python<>?
References: <20020611215510.63085.qmail@web20210.mail.yahoo.com>
Message-ID: <022501c21193$e44de4d0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Tuesday, June 11, 2002 5:55 PM
Subject: Re: [C++-sig] current spelling of from_python<>?


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > Observations:
> > >
> > > The code as shown works with Linux/gcc304, but VC6 reports
> > > "indirect_traits.hpp(308) : error C2057: expected constant
expression."
> > > arg_from_python<container_element_type> also works with Linux/gcc304,
but
> > VC6
> > > reports "fatal error C1001: INTERNAL COMPILER ERROR."
> > > Should/could I use a different approach for testing convertibility
that
> > VC6
> > > might not choke on?
> >
> > Try breaking up the definition of value into little steps so that the
> > expression is simpler.
>
> Indeed,
>
>         PyObject* ti = t[i].get();
>         arg_from_python<container_element_type const&> from_py(ti);
>
> works! That was just too obvious.

That wasn't what I had in mind; I was looking at the definition of "value"
in indirect_traits.hpp... but, whatever.





From david.abrahams at rcn.com  Wed Jun 12 00:19:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 18:19:16 -0400
Subject: [C++-sig] Constructor w/ string
References: <NFBBINAMBILHLOCDJKAEOEBCCCAA.ssmith@magnet.fsu.edu>
Message-ID: <023701c21196$a58db790$6501a8c0@boostconsulting.com>


----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Tuesday, June 11, 2002 5:51 PM
Subject: [C++-sig] Constructor w/ string


> Greetings,
>
> A simple problem I'll bet. I have three constructors in my
> (now very simple) class. One that takes no arguments, one that
> does self-construction, and one that takes a string. When I
> export these in Boost 1.25.0 all three work fine, but with 1.28.0
> only the first two work , the third always dies with complaints about
> a Debug Assertion Failure in dgbheap.c from the Python IDE.

What "Python IDE"?

> I hope someone can help me figure out the following:
>
> 1.) How to I change the export function to make this work again?
> 2.) Is there documentation that has this in detail?
>
> I often look through http://mail.python.org/pipermail/c++-sig/ and have
> used the new Google search on the main WWW page, but haven't found
anything.
> The getting_started2 example works OK and it also has a construtor that
> uses a string, but upon exiting the interpreter it gives the same error
> message when I add in empty & self constructors. (I am unclear on why
that
> example needs <iostream> and why exactly the const string& must be just
> string
> in the corresponding init function, however neither of these influences
my
> result.)
>
> I am using Python 2.2.1 & MSVC++ 6.0.  My class header, code, and the
> Boost.Python interface are below if that helps.  Note that in my
non-clipped
> verson I do actually use the string I construct with, same problem
though.

Your example works fine for me (at least with the current CVS state). The
enclosed Boost subproject demonstrates it (unpack to libs/python):

cd c:/boost/libs/python/smith/
myjam -sBUILD=debug-python -sTOOLS=msvc smith.test
...found 588 targets...
...updating 5 targets...
MkDir1 c:\build\libs\python\example\bin\smith.test
MkDir1 c:\build\libs\python\example\bin\smith.test\msvc
MkDir1 c:\build\libs\python\example\bin\smith.test\msvc\debug-python
MkDir1
c:\build\libs\python\example\bin\smith.test\msvc\debug-python\runtime-link-
dynamic
python-test-target
c:\build\libs\python\example\bin\smith.test\msvc\debug-python\runtime-link-
dynamic\smith.test
Adding parser accelerators ...
Done.
[3543 refs]
...updated 5 targets...

Compilation finished at Tue Jun 11 18:18:51

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smith.zip
Type: application/x-zip-compressed
Size: 1798 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020611/15afe995/attachment.bin>

From david.abrahams at rcn.com  Wed Jun 12 00:49:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 18:49:17 -0400
Subject: [C++-sig] BPL and embedding python
References: <ae3rov$r0h$1@main.gmane.org>
Message-ID: <000f01c2119a$6a196480$6501a8c0@boostconsulting.com>

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


> I've noticed that more and more people are attempting to embed python in
> applications and documentation  on how to do this effectively is quite
> scarce. One of the strengths of boost is the ability to create a c++
class
> instance and override some of its members in python, but use the actual
> class instance from within c++. In fact you can create a class instance,
> modify some of its members using on the fly generated python code and
then
> pass the c++ instance back to yor c++ code.
>
> I've done this with with boost V1 along these lines:

Thanks for your post. Just to clarify, what you're demonstrating below is
how to create a Python instance of your wrapped C++ class from C++.


<snip>

> Remember this is NOT complete code and just an outline of how to proceed.
>
> The fly in the ointment is not being able to directly delete the class
> instances (Dave, do you have any ideas ?)

Hmm. Unfortunately, no. The class instance itself is a data member of
another class; that would lead to double-destruction. Why do you want to
directly delete the class instance?

I've been thinking about a smart pointer type which manages a python object
but "points to" some internally-held C++ object for v2, so you could write:

    lvalue_ptr<MyClass> p(call<PyObject*>(pPyClass));

and then,

    p->some_member_function();

Would that help?

Hmm, lvalue_ptr<> would probably replace back_reference<> in the v2
interface...

-Dave





From rwgk at yahoo.com  Wed Jun 12 00:57:54 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 11 Jun 2002 15:57:54 -0700 (PDT)
Subject: [C++-sig] implicit imports?
In-Reply-To: <010e01c21174$599c4fd0$6501a8c0@boostconsulting.com>
Message-ID: <20020611225754.5599.qmail@web20203.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> You can have the dependent modules load the std_vector module from their
> init functions.

Checked with Linux/gcc and found to be true. Cool!
(V1 does not support this, right?)

Quick experiment:

  ext1 -> imports ext2
  ext2 -> imports ext1

Under Linux Python resolves this gracefully. Haven't tried other OS's yet.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Wed Jun 12 01:12:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 19:12:50 -0400
Subject: [C++-sig] Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com> <ae2qko$chi$1@main.gmane.org> <01ee01c210ae$83206f10$6601a8c0@boostconsulting.com> <ae3ku0$1bg$1@main.gmane.org>
Message-ID: <004f01c2119d$e4c9e710$6501a8c0@boostconsulting.com>

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

> ie
>
>     class_(class_<...>& c);
>
> Of course this will look like a duck, walk like a duck and bark like a
> dog...

Why?
It doesn't match the regular copy-constructor, if that's what you're
worried about.

> This probably means putting in some superfluous argument so it doesn't
look
> like a copy constrctor.

Are you just concerned that people will be confused?






From david.abrahams at rcn.com  Wed Jun 12 01:14:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 19:14:46 -0400
Subject: [C++-sig] implicit imports?
References: <20020611225754.5599.qmail@web20203.mail.yahoo.com>
Message-ID: <005001c2119d$e50876b0$6501a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > You can have the dependent modules load the std_vector module from
their
> > init functions.
>
> Checked with Linux/gcc and found to be true. Cool!
> (V1 does not support this, right?)

Sure; you're not using any special Boost.Python facilities, are you?

> Quick experiment:
>
>   ext1 -> imports ext2
>   ext2 -> imports ext1
>
> Under Linux Python resolves this gracefully. Haven't tried other OS's
yet.

I don't see why it wouldn't work everywhere.

-Dave





From david.abrahams at rcn.com  Wed Jun 12 01:17:54 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 19:17:54 -0400
Subject: [C++-sig] distribution of bpl.dll
References: <FCEMIEFBFOIDAOJDEPIAMELODGAA.achim.domma@syynx.de>
Message-ID: <005601c2119e$9868b8a0$6501a8c0@boostconsulting.com>

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


> Hi,
>
> how will bpl.dll be distributed in the future?

Good question!

> Should every extension provide his own version?

No; that would thoroughly undermine the cross-module support.

> If I understand right, the intension was to let
> extensions share on bpl.dll, but arent't C++ libraries compiler
dependent?

In general, yes. All compilers using bpl.dll would have to have compatible
ABIs.
A scheme which used a different bpl shared library per ABI is conceivable,
but I'm not ready to tackle it.

-Dave






From david.abrahams at rcn.com  Wed Jun 12 01:23:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 19:23:28 -0400
Subject: [C++-sig] Re: Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net> <007901c21080$b932aec0$6601a8c0@boostconsulting.com> <ae2pbu$6hr$1@main.gmane.org>
Message-ID: <006f01c2119f$4c95c070$6501a8c0@boostconsulting.com>

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

> Another awkward twist is that some of the python API functions accept a
NULL
> PyObject* as a valid parameter.

Not according to Guido:
http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1235121

> Which implies a 'NULL' reference should be
> allowed which is not symantically an error condition. However I don't
think
> there any functions that can return a valid NULL apart from some of the
> MACRO versions with no error checking.
>
> I don't think it is unreasonable to construct a new smart pointer that
holds
> a NULL pointer as it currently does.
>
> However for return values may be we should have a different smart pointer
> called something like result_reference. We can then allow conversions
> between the two that would check if result_reference was valid, before
> converting to a regular reference.

I'm thinking that return values of Python API wrappers should always return
"object", which has a builtin check for null that throws.

-Dave






From daveh at cadlink.com  Wed Jun 12 03:14:05 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 11 Jun 2002 21:14:05 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com> <ae2qko$chi$1@main.gmane.org> <01ee01c210ae$83206f10$6601a8c0@boostconsulting.com> <ae3ku0$1bg$1@main.gmane.org> <004f01c2119d$e4c9e710$6501a8c0@boostconsulting.com>
Message-ID: <ae6790$jg2$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:004f01c2119d$e4c9e710$6501a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > ie
> >
> >     class_(class_<...>& c);
> >
> > Of course this will look like a duck, walk like a duck and bark like a
> > dog...
>
> Why?
> It doesn't match the regular copy-constructor, if that's what you're
> worried about.
>
> > This probably means putting in some superfluous argument so it doesn't
> look
> > like a copy constrctor.
>
> Are you just concerned that people will be confused?

Primarily, yes, as it superficially looks like it could be used to copy
class_ instances, but that is not its function.

Dave Hawkes









From daveh at cadlink.com  Wed Jun 12 03:21:43 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 11 Jun 2002 21:21:43 -0400
Subject: [C++-sig] Re: Re: Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net> <007901c21080$b932aec0$6601a8c0@boostconsulting.com> <ae2pbu$6hr$1@main.gmane.org> <006f01c2119f$4c95c070$6501a8c0@boostconsulting.com>
Message-ID: <ae67nb$kuk$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:006f01c2119f$4c95c070$6501a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > Another awkward twist is that some of the python API functions accept a
> NULL
> > PyObject* as a valid parameter.
>
> Not according to Guido:
> http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1235121

But from the python 2.2 manual, PyObject_Dir, for example, can take a NULL
pointer as a valid argument. Also note that this function can in some
circumstance return a NULL result without setting PyErr_Occured. This is not
a unique function as I have spotted one or two others with similar
behaviour.

>
> > Which implies a 'NULL' reference should be
> > allowed which is not symantically an error condition. However I don't
> think
> > there any functions that can return a valid NULL apart from some of the
> > MACRO versions with no error checking.
> >
> > I don't think it is unreasonable to construct a new smart pointer that
> holds
> > a NULL pointer as it currently does.
> >
> > However for return values may be we should have a different smart
pointer
> > called something like result_reference. We can then allow conversions
> > between the two that would check if result_reference was valid, before
> > converting to a regular reference.
>
> I'm thinking that return values of Python API wrappers should always
return
> "object", which has a builtin check for null that throws.
>

Then how are functions like PyObject_Dir handled if you can't have a valid
NULL pointer?

Dave Hawkes









From david.abrahams at rcn.com  Wed Jun 12 03:30:59 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 21:30:59 -0400
Subject: [C++-sig] Re: Re: Re: sub module support in V2
References: <adlc2e$68b$1@main.gmane.org> <17ac01c20cac$9932b2a0$6601a8c0@boostconsulting.com> <ae0r49$o0e$1@main.gmane.org> <28bc01c21015$dfc9fef0$6601a8c0@boostconsulting.com> <ae0unn$rkq$1@main.gmane.org> <28ce01c2101d$75096080$6601a8c0@boostconsulting.com> <ae19h5$sq4$1@main.gmane.org> <002201c2103a$01fb4ff0$6601a8c0@boostconsulting.com> <ae2qko$chi$1@main.gmane.org> <01ee01c210ae$83206f10$6601a8c0@boostconsulting.com> <ae3ku0$1bg$1@main.gmane.org> <004f01c2119d$e4c9e710$6501a8c0@boostconsulting.com> <ae6790$jg2$1@main.gmane.org>
Message-ID: <00dc01c211b1$63d19b80$6501a8c0@boostconsulting.com>

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


> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:004f01c2119d$e4c9e710$6501a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > > ie
> > >
> > >     class_(class_<...>& c);
> > >
> > > Of course this will look like a duck, walk like a duck and bark like
a
> > > dog...
> >
> > Why?
> > It doesn't match the regular copy-constructor, if that's what you're
> > worried about.
> >
> > > This probably means putting in some superfluous argument so it
doesn't
> > look
> > > like a copy constrctor.
> >
> > Are you just concerned that people will be confused?
>
> Primarily, yes, as it superficially looks like it could be used to copy
> class_ instances, but that is not its function.

In that case, to reduce confusion, have it accept boost::python::object,
which will be a base of class_<>.

-Dave





From david.abrahams at rcn.com  Wed Jun 12 03:34:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 11 Jun 2002 21:34:30 -0400
Subject: [C++-sig] Re: Re: Retiring "ref", etc.
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <023d01c21033$b560ed40$c2a451ca@asiagate.net> <003701c2103c$5f369510$6601a8c0@boostconsulting.com> <031101c21047$457652e0$c2a451ca@asiagate.net> <007901c21080$b932aec0$6601a8c0@boostconsulting.com> <ae2pbu$6hr$1@main.gmane.org> <006f01c2119f$4c95c070$6501a8c0@boostconsulting.com> <ae67nb$kuk$1@main.gmane.org>
Message-ID: <00dd01c211b1$6403f620$6501a8c0@boostconsulting.com>

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


> Then how are functions like PyObject_Dir handled if you can't have a
valid
> NULL pointer?

Simple: Use overloading (unavailable in "C") to represent dir(o) and dir().
If there is no frame active when you call dir(), it's an error, and an
exception is raised. I don't know what Python exception to translate this
into, of course...

-Dave





From daveh at cadlink.com  Wed Jun 12 03:36:15 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 11 Jun 2002 21:36:15 -0400
Subject: [C++-sig] Re: BPL and embedding python
References: <ae3rov$r0h$1@main.gmane.org> <000f01c2119a$6a196480$6501a8c0@boostconsulting.com>
Message-ID: <002201c211b1$8b1afb00$3e08a8c0@davehh>

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
Newsgroups: gmane.comp.python.c++
Sent: Tuesday, June 11, 2002 6:49 PM
Subject: Re: BPL and embedding python


> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> > I've noticed that more and more people are attempting to embed python in
> > applications and documentation  on how to do this effectively is quite
> > scarce. One of the strengths of boost is the ability to create a c++
> class
> > instance and override some of its members in python, but use the actual
> > class instance from within c++. In fact you can create a class instance,
> > modify some of its members using on the fly generated python code and
> then
> > pass the c++ instance back to yor c++ code.
> >
> > I've done this with with boost V1 along these lines:
>
> Thanks for your post. Just to clarify, what you're demonstrating below is
> how to create a Python instance of your wrapped C++ class from C++.
>
>

That's basically it.

> <snip>
>
> > Remember this is NOT complete code and just an outline of how to
proceed.
> >
> > The fly in the ointment is not being able to directly delete the class
> > instances (Dave, do you have any ideas ?)
>
> Hmm. Unfortunately, no. The class instance itself is a data member of
> another class; that would lead to double-destruction. Why do you want to
> directly delete the class instance?
>
> I've been thinking about a smart pointer type which manages a python
object
> but "points to" some internally-held C++ object for v2, so you could
write:
>
>     lvalue_ptr<MyClass> p(call<PyObject*>(pPyClass));
>
> and then,
>
>     p->some_member_function();
>
> Would that help?
>
> Hmm, lvalue_ptr<> would probably replace back_reference<> in the v2
> interface...
>

Then when the smart pointer is destroyed it just decrements the object
reference. Yes, that sounds like a promising solution.


Dave Hawkes





From daveh at cadlink.com  Wed Jun 12 03:53:43 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Tue, 11 Jun 2002 21:53:43 -0400
Subject: [C++-sig] Docs and Testing for V2
Message-ID: <ae69jb$rjg$1@main.gmane.org>

I've started a small project to automate testing of some boost components.
What I'm doing is expanding my embedded python example code I posted earlier
to a full working model that can also be used for testing. This way one file
can contain both the python code and c++ code to simultaneously test from
both sides of the fence.

Not only would this code be used for testing but it should be reasonably
well anotated and so also serve as a substantial example for documentation
purposes, as I believe most people learn best from example. Especially if
the code demonstrates some of the 'tougher' (less well documented)
implementations.

Hopefully within the next few weeks I'll have something to post.

Initially I'm going to develop this in windows, but without relying on
windows features, making it relatively easy to port.

If anyone has any ideas for items that should be tested or documented by
example, let me know.

Dave Hawkes









From dubreus at csit.fsu.edu  Wed Jun 12 15:36:37 2002
From: dubreus at csit.fsu.edu (Mitscher Dubreus)
Date: Wed, 12 Jun 2002 09:36:37 -0400
Subject: [C++-sig] short boost example from boost.org
In-Reply-To: <00dd01c211b1$6403f620$6501a8c0@boostconsulting.com>
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <ae67nb$kuk$1@main.gmane.org> <00dd01c211b1$6403f620$6501a8c0@boostconsulting.com>
Message-ID: <20020612133638.3973423A43@mailer.csit.fsu.edu>

Hi, 
I tried to test your boost getting_started example from boost.org.
I use gcc3.0.4 on RedHat7.2, with python2.1
When I compile my getting_started.cpp file to get a .so file, there's no pb.

g++3 getting_started1.cpp -Wall -c -fPIC -shared -o getting_started1.so 
-I/usr/local/lib/python/boost_1_28_0/ -I /usr/include/python2.1/

But when I import the getting_started librairie into python, I get an error 
message:

Traceback (most recent call last):
  File "./boost.py", line 3, in ?
    import getting_started1
ImportError: ./getting_started1.so: ELF file's phentsize not the expected size


I don't know why I get this message, but I hope you can help me.
Thanks in advance




From david.abrahams at rcn.com  Wed Jun 12 15:44:48 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 12 Jun 2002 09:44:48 -0400
Subject: [C++-sig] short boost example from boost.org
References: <276a01c20fb9$1ae18970$6601a8c0@boostconsulting.com> <ae67nb$kuk$1@main.gmane.org> <00dd01c211b1$6403f620$6501a8c0@boostconsulting.com> <20020612133638.3973423A43@mailer.csit.fsu.edu>
Message-ID: <01f601c21217$569f3f60$6501a8c0@boostconsulting.com>

From: "Mitscher Dubreus" <dubreus at csit.fsu.edu>


> Hi,
> I tried to test your boost getting_started example from boost.org.
> I use gcc3.0.4 on RedHat7.2, with python2.1
> When I compile my getting_started.cpp file to get a .so file, there's no
pb.
>
> g++3 getting_started1.cpp -Wall -c -fPIC -shared -o getting_started1.so
> -I/usr/local/lib/python/boost_1_28_0/ -I /usr/include/python2.1/
>
> But when I import the getting_started librairie into python, I get an
error
> message:
>
> Traceback (most recent call last):
>   File "./boost.py", line 3, in ?
>     import getting_started1
> ImportError: ./getting_started1.so: ELF file's phentsize not the expected
size
>
>
> I don't know why I get this message, but I hope you can help me.

Sorry, I am without a clue. I think you'll need to ask on some GCC/ELF list
about this problem.

The one thing I *can* say is that building is only supported using
Boost.Build. The library has been built and tested with Boost.Build on your
platform.

-Dave






From ssmith at magnet.fsu.edu  Wed Jun 12 18:25:42 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 12 Jun 2002 12:25:42 -0400
Subject: [C++-sig] Constructor w/ string
In-Reply-To: <023701c21196$a58db790$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEKEBFCCAA.ssmith@magnet.fsu.edu>

Hi Dave,

Thanks for your time and the info.

> What "Python IDE"?

This was the Windows IDLE that comes with Python 2.2.1. The same
problem occurs in the simple Python shell.

> Your example works fine for me (at least with the current CVS state).

O.K. I obtained the latest CVS today and built it with both MSVC++ and
Cygwin (putting to use all the help you and others previously gave me).
Then I built the getting_started2 example inside MSVC++ and again, it
produces the result but when I exit Python (^D) I get the error about a
Debug Assertion Failure in dgbheap.c. In my full code the error occurs
while the interpreter is running and that stops everything.

So, I followed your build instructions using bjam... it had some problems
but essentially worked. The pyd output did NOT cause the error and
worked fine, as you said. With the -sBUILD=debug-python I get a message
LINK : fatal error LNK1104: cannot open file "python22_d.lib", so I just
used "debug" and/or "release" and things worked as you had indicated.

So, I guess I have other problems/questions/statments.

1.) I need to find out the difference between building a dll and building
    a pyd file? Why is one preferrable over the other? As I mentioned, the
    dll build of my project with Boost 1.25.0 worked just fine.
2.) What version of Boost.Python am I using? If I build it from the main
directory
    I think I understand that I make 1.2x with x>=8, even though the CVS
distribution
    contains both? But I think Ralf told me that
    if one builds things in the Python sub-directory it uses 2.0. Can this
cause
    trouble or should I just not worry about it? Since I am nearly back to
square 1
    at this point I have no problems just using 2.0, but I am not sure how.
3.) While I have python22.lib I don't have python22_d.lib, is that for
debugging?
    If so, where can I get this or how can I build it? Apparently I will
need it.
4.) When I build my Boost.Python example with Jam it appears that it
automatically
    a.) Builds Boost.Python (e.g. when I set the BUILD variable differently)
    b.) Sets up the PYTHONPATH and PATH
    c.) Attempts to run my example?
5.) I have never actually seen the tests/examples run automatically during
the
    build of test. Is there supposed to be something other than compiler
output
    when one issues a "bjam test"?  Now that I've CVS upgraded the mpl stuff
    it seems to compile fine (is this version 2.0?) but if it is supposed to
    invoke Python and do something else I don't see it.

The Cygwin build of my example goes wild about path problems (even though
the
environment is set exactly as it was in the entire Boost build), but I won't
bother about it until I figure out more basics.

Thanks
Scott

-----------------------------------------
-----------------------------------------

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From david.abrahams at rcn.com  Wed Jun 12 18:42:48 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 12 Jun 2002 12:42:48 -0400
Subject: [C++-sig] Constructor w/ string
References: <NFBBINAMBILHLOCDJKAEKEBFCCAA.ssmith@magnet.fsu.edu>
Message-ID: <02f001c21230$8a797120$6501a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> So, I guess I have other problems/questions/statments.
>
> 1.) I need to find out the difference between building a dll and building
>     a pyd file? Why is one preferrable over the other?

The .pyd shows a nice little Python icon; otherwise they are exactly
identical.

> As I mentioned, the
>     dll build of my project with Boost 1.25.0 worked just fine.
> 2.) What version of Boost.Python am I using? If I build it from the main
> directory

What is "the main directory"?

>     I think I understand that I make 1.2x with x>=8, even though the CVS
> distribution
>     contains both? But I think Ralf told me that
>     if one builds things in the Python sub-directory it uses 2.0. Can
this

Yes.

> cause
>     trouble or should I just not worry about it?


Don't worry about it.

> Since I am nearly back to
> square 1
>     at this point I have no problems just using 2.0, but I am not sure
how.

If you really want to start over with v2:
http://mail.python.org/pipermail/c++-sig/2002-May/001100.html

> 3.) While I have python22.lib I don't have python22_d.lib, is that for
> debugging?

Read the section on "Build Variants" at
http://www.boost.org/libs/python/doc/building.html

>     If so, where can I get this or how can I build it? Apparently I will
> need it.

You don't need it, but it will help you to detect certain problems if you
use it.

> 4.) When I build my Boost.Python example with Jam it appears that it
> automatically
>     a.) Builds Boost.Python (e.g. when I set the BUILD variable
differently)
>     b.) Sets up the PYTHONPATH and PATH
>     c.) Attempts to run my example?


Yes.

> 5.) I have never actually seen the tests/examples run automatically
during
> the
>     build of test. Is there supposed to be something other than compiler
> output
>     when one issues a "bjam test"?

See the section on Testing at
http://www.boost.org/libs/python/doc/building.html

> Now that I've CVS upgraded the mpl stuff
>     it seems to compile fine (is this version 2.0?) but if it is supposed
to
>     invoke Python and do something else I don't see it.

Does this clarify?

build in             target     version    requirements     result
--------             ------     -------    ------------     ------
libs/python/build    all/<none> v1         Boost            libboost_python
libs/python/build    test       v1         Boost            v1 tests

libs/python          all/<none> v2         +mpl-development bpl library
libs/python/test     test       v2         +mpl-development v2 tests







From ponderor at lycos.com  Wed Jun 12 20:02:25 2002
From: ponderor at lycos.com (Dean Goodmanson)
Date: Wed, 12 Jun 2002 11:02:25 -0700
Subject: [C++-sig] Python's role in C++ projects
Message-ID: <PAHELLJCHGENFDAA@mailcity.com>

I responded to a question on comp.lang.python regarding Prototyping Good OO design in Python. ( http://groups.google.com/groups?lr=&selm=mailman.1022957762.16687.python-list%40python.org )

( sorry for the long URL )

I expected answer ( http://groups.google.com/groups?selm=e81be8b2.0206022315.3a0bf9a9%40posting.google.com ) was filled with more cue's than facts.

Strangely enough, this made the weekly Python-URL!, but wasn't followed up with many specific facts about C++.

If you see mistakes in my post, have further insights "from the trenches", or other comments please respond to the c.l.py list or me personally and I can follow up with a summary.

Best Regards,

Dean
 


_______________________________________________________
WIN a first class trip to Hawaii.  Live like the King of Rock and Roll
on the big Island. Enter Now!
http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes




From ssmith at magnet.fsu.edu  Wed Jun 12 23:19:22 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 12 Jun 2002 17:19:22 -0400
Subject: [C++-sig] OS X
In-Reply-To: <20020531004518.307.qmail@web20203.mail.yahoo.com>
Message-ID: <NFBBINAMBILHLOCDJKAEOEBGCCAA.ssmith@magnet.fsu.edu>

Greetings,

I am back looking at Boost.Python on OS X today. I downloaded all from
CVS and built Boost.Python. As before, it had trouble so I built my own
makefile and it compiled with just a warning that it did not know _environ
during the link step. Then I realized that since I was doing this in
python/build it was not using Boost 2.0 but 1.2x?

So, I moved one level back and retried this. According to Ralf this will
build using 2.0. Being tired of using my own makefiles I tweaked the
file boostcvs/tools/build/gcc-tools.jam to put in the "proper" compiler
flags, at least the the ones that build 1.28.0 OK.

Now the first error is this:

../../../libs/python/src/converter/type_id.cpp:12: ostream.h: No such file
or directory

Apparently the __GNUC__ flag is not being set as expected in type_id.cpp.
Short of just
changing type_id.cpp, is there a differnt way to fix this so that it knows
to use <ostream>?

Why is it compiling type_id.cpp for this, it didn't bother
about it in the 1.28.0 build (until the tests were built).

Thanks,
Scott



-----------------------------------------
-----------------------------------------

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From rwgk at yahoo.com  Wed Jun 12 23:37:06 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 12 Jun 2002 14:37:06 -0700 (PDT)
Subject: [C++-sig] OS X
In-Reply-To: <NFBBINAMBILHLOCDJKAEOEBGCCAA.ssmith@magnet.fsu.edu>
Message-ID: <20020612213707.51028.qmail@web20209.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> So, I moved one level back and retried this. According to Ralf this will
> build using 2.0. Being tired of using my own makefiles I tweaked the
> file boostcvs/tools/build/gcc-tools.jam to put in the "proper" compiler
> flags, at least the the ones that build 1.28.0 OK.
> 
> Now the first error is this:
> 
> ../../../libs/python/src/converter/type_id.cpp:12: ostream.h: No such file
> or directory
> 
> Apparently the __GNUC__ flag is not being set as expected in type_id.cpp.
> Short of just
> changing type_id.cpp, is there a differnt way to fix this so that it knows
> to use <ostream>?

To keep going, you could try adding -D__GNUC__ to the gcc-Cc-action rule,
e.g. right before the -D$(DEFINES).
Ralf
BTW: Under Solaris we had problems with "-isystem". Changing this to "-I"
helped (i.e. we have a complete Solaris/gcc304 build now).


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Wed Jun 12 23:46:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 12 Jun 2002 17:46:09 -0400
Subject: [C++-sig] OS X
References: <20020612213707.51028.qmail@web20209.mail.yahoo.com>
Message-ID: <008d01c2125a$b8428900$6501a8c0@boostconsulting.com>

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

> BTW: Under Solaris we had problems with "-isystem". Changing this to "-I"
> helped (i.e. we have a complete Solaris/gcc304 build now).

Did you ever file a GNATS bug report on this one?

-Dave






From rwgk at yahoo.com  Thu Jun 13 01:01:49 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 12 Jun 2002 16:01:49 -0700 (PDT)
Subject: [C++-sig] OS X
In-Reply-To: <008d01c2125a$b8428900$6501a8c0@boostconsulting.com>
Message-ID: <20020612230149.91434.qmail@web20201.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> ----- Original Message -----
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > BTW: Under Solaris we had problems with "-isystem". Changing this to "-I"
> > helped (i.e. we have a complete Solaris/gcc304 build now).
> 
> Did you ever file a GNATS bug report on this one?

No. I do not even understand the purpose of -isystem, and I will not have the
time to find out more about this :-(
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From bugcreator at gmx.de  Thu Jun 13 04:20:23 2002
From: bugcreator at gmx.de (Dominic =?iso-8859-15?q?Sacr=E9?=)
Date: Thu, 13 Jun 2002 04:20:23 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
Message-ID: <200206130417.29282.bugcreator@gmx.de>

Hi,

I've got a problem with BPL V2 (current CVS). Here's some code...

--------------------------------------------------------
#include <string>
#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/python/call_method.hpp>
#include <boost/utility.hpp>

using namespace boost::python;

class Base {
  public: void blah () { }
};

class Foo : public Base {
  public:
    Foo (const std::string & str) { }
    ~Foo () { }
    void call_bar () { bar (); }
    virtual void bar () { }
};

class FooCallback : public Foo {
  public:
    FooCallback (PyObject * self, const std::string & str)
        : Foo (str), m_self (self) { }
    void bar () { call_method<void> (m_self, "bar"); }
    void bar_impl () { this->Foo::bar (); }
  private:
    PyObject * m_self;
};

BOOST_PYTHON_MODULE_INIT(foo_module)
{
    module ("foo_module")

        .add ( class_ <Base> ("Base")
            .def ("blah", &Base::blah) )

        .add ( class_ <Foo,
                    bases<Base>, // <--- this seems to cause the problem
                    boost::shared_ptr<FooCallback>,
                    boost::noncopyable> ("Foo")
            .def_init (args<const std::string &>())
            .def ("call_bar", &Foo::call_bar)
            .def ("bar", &FooCallback::bar_impl) )
    ;
}
--------------------------------------------------------

If I remove the line where Base is specified as a base class of Foo, it 
compiles without problems (of course I can't call Foo.blah() then).
But with this line, I get the following error (with gcc-3.1), and I can't 
make head or tail of it...

foo.cpp:42: no matching function for call to `boost::python::module::add(
   boost::python::class_<Foo, boost::python::bases<Base, 
   boost::mpl::null_argument, boost::mpl::null_argument, 
   boost::mpl::null_argument, boost::mpl::null_argument, 
   boost::mpl::null_argument, boost::mpl::null_argument, 
   boost::mpl::null_argument, boost::mpl::null_argument, 
   boost::mpl::null_argument, boost::mpl::null_argument, 
   boost::mpl::null_argument, boost::mpl::null_argument, 
   boost::mpl::null_argument, boost::mpl::null_argument>, 
   boost::shared_ptr<FooCallback>, boost::noncopyable>&)'
src/boost-gcc-3.1/boost/python/module.hpp:78: candidates are: 
   boost::python::module& boost::python::module::add(PyTypeObject*)

What does that mean, what am I missing?


Oh, and one more thing (not related to the above). With gcc-3.1, BPL and 
the test modules compile correctly, but with gcc-2.95.3, I get this 
error:

../../../boost/python/converter/arg_to_python.hpp:97: `Aindex' was not 
declared in this scope
../../../boost/python/converter/arg_to_python.hpp:97: stray '\' in program
../../../boost/python/converter/arg_to_python.hpp:98: template argument 1 
is invalid
../../../boost/python/converter/arg_to_python.hpp:98: confused by earlier 
errors, bailing out

Thanks in advance,
    Dominic




From ich at peabody.jhu.edu  Thu Jun 13 04:31:50 2002
From: ich at peabody.jhu.edu (ich at peabody.jhu.edu)
Date: Wed, 12 Jun 2002 22:31:50 -0400 (EDT)
Subject: [C++-sig] boost 1.28 on OS X
Message-ID: <Pine.LNX.4.44.0206122158530.8377-100000@mambo.peabody.jhu.edu>

I'm having difficulty porting boost 1.28 to OS X using Apple's version of 
gcc 3.1, which does not seems to initialize templated static data members.

I've sent email to darwin-GCC3 at opensource.apple.com yesterday but haven't 
heard back yet (email included below).

For example, with the abstract test, I get:

c++   -g -fPIC -bundle -bundle_loader /usr/local/bin/python -framework 
Python -framework System -flat_namespace -undefined warning -lstdc++  -o 
"../../../libs/python/build/bin/abstract.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/abstract.so"  
-L/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/config 
-L../../../libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true   
"../../../libs/python/build/bin/abstract.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/abstract.o"    
-lutil -lboost_python  
    
ld: warning undefined symbols:
__ZN5boost6python6detail14class_registryI8AbstractE19static_class_objectE
__ZN5boost6python6detail14class_registryI8AbstractE22static_base_class_infoE
__ZN5boost6python6detail14class_registryI8AbstractE25static_derived_class_infoE

If I use Apple's gcc 2.95, I get a different error:
ld: warning undefined symbols:
___tiQ45boost6python6detailt15instance_holder1Z8Abstract

BTW, one test (getting_started1) does work!

Any help will be appreciated.

Thank you,

Ichiro Fujinaga
Computer Music Department
Peabody Institute of the Johns Hopkins University

===========================================
Date: Tue, 11 Jun 2002 18:34:56 -0400 (EDT)
From: ich at peabody.jhu.edu
To: darwin-GCC3 at opensource.apple.com
Subject: C++

The following code works on linux gcc 3.1 & 2.96 and OS X gcc 2.95
but OS X gcc 3.1 results in (c++ test.cpp):

ld: Undefined symbols:
__ZN3FooIiE1jE

=========================
#include <iostream>
using namespace std;

template <class T>
class Foo
{
 static int j;
public:
 T i;
 void reset() { i = j; }
};

template <class T>
  int Foo<T>::j = 0;

int main()
{
  Foo<int> f;
  f.i = 3;
  cout << f.i << endl;
  f.reset();
  cout << f.i << endl;
}







From david.abrahams at rcn.com  Thu Jun 13 05:24:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 12 Jun 2002 23:24:58 -0400
Subject: [C++-sig] OS X
References: <20020612230149.91434.qmail@web20201.mail.yahoo.com>
Message-ID: <00dd01c2128a$60f98fb0$6501a8c0@boostconsulting.com>

-isystem adds a path to the #include <...> search paths.

You could zip a boost tree with the -o output of bjam into a reproducible
test case.


----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, June 12, 2002 7:01 PM
Subject: Re: [C++-sig] OS X


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> >
> > ----- Original Message -----
> > From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> >
> > > BTW: Under Solaris we had problems with "-isystem". Changing this to
"-I"
> > > helped (i.e. we have a complete Solaris/gcc304 build now).
> >
> > Did you ever file a GNATS bug report on this one?
>
> No. I do not even understand the purpose of -isystem, and I will not have
the
> time to find out more about this :-(
> Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From ssmith at magnet.fsu.edu  Thu Jun 13 12:34:10 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 13 Jun 2002 06:34:10 -0400
Subject: [C++-sig] OS X
In-Reply-To: <00dd01c2128a$60f98fb0$6501a8c0@boostconsulting.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLGEBJCAAA.ssmith@magnet.fsu.edu>

The same problem occurs on OS X with -isystem, I had already
just replaced this in the gcc-tools file. As for the __GNUG__
I tried to do this in gcc-tools too but that caused complaints
about it being defined twice. I know I can just set this with
-D on the command line, I guess my question was more of
where is this set for bjam? The same for isystem, how is bjam
(not)figuring out what to set this as. 

I'll be trying OS X some more when I am back at work today.

Scott

> -isystem adds a path to the #include <...> search paths.

> You could zip a boost tree with the -o output of bjam into a reproducible
> test case.

> > > BTW: Under Solaris we had problems with "-isystem". Changing this to
"-I"
> > > helped (i.e. we have a complete Solaris/gcc304 build now).
> >
> > Did you ever file a GNATS bug report on this one?
>
> No. I do not even understand the purpose of -isystem, and I will not have
the
> time to find out more about this :-(





From ssmith at magnet.fsu.edu  Thu Jun 13 13:11:52 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 13 Jun 2002 07:11:52 -0400
Subject: [C++-sig] OS X
In-Reply-To: <20020612213707.51028.qmail@web20209.mail.yahoo.com>
Message-ID: <NFBBINAMBILHLOCDJKAECEBHCCAA.ssmith@magnet.fsu.edu>

Hi Ralf,

> To keep going, you could try adding -D__GNUC__ to the gcc-Cc-action rule,
> e.g. right before the -D$(DEFINES).

Nope, adding this to gcc-Cc-action does nothing. Adding it to gcc-C++-action
produces a complaint about __GNUC__ being defined twice in the
initialization
and  then dies.

Scott

-----------------------------------------
-----------------------------------------

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From ssmith at magnet.fsu.edu  Thu Jun 13 13:23:14 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 13 Jun 2002 07:23:14 -0400
Subject: [C++-sig] boost 1.28 on OS X
In-Reply-To: <Pine.LNX.4.44.0206122158530.8377-100000@mambo.peabody.jhu.edu>
Message-ID: <NFBBINAMBILHLOCDJKAEKEBHCCAA.ssmith@magnet.fsu.edu>

Ichiro,

I am trying to build boost CVS on OS X, can you tell me what you
did in the 1.28.0 build? For example, I see you are able to link
to -lutil, I cannot. Did this library come on your system or did
you install it? Also I see you have Python in /usr/local/bin, did
you build this yourself (I used Fink and it puts it in /sw somewhere).
Did all of this work directly or have you needed to mess around with
the jam stuff?  How did you get the -framework flags in the build
commands? My system is behaving quite differently than yours
even on the build of 1.28.0.

I am using GCC 2.95 and also saw problems with templates when building
the tests with 1.28.0, but now I am trying the latest CVS stuff.

Thanks,
Scott


> I'm having difficulty porting boost 1.28 to OS X using Apple's version of
> gcc 3.1, which does not seems to initialize templated static data members.
>
> I've sent email to darwin-GCC3 at opensource.apple.com yesterday but haven't
> heard back yet (email included below).
>
> For example, with the abstract test, I get:
>
> c++   -g -fPIC -bundle -bundle_loader /usr/local/bin/python -framework
> Python -framework System -flat_namespace -undefined warning -lstdc++  -o
> "../../../libs/python/build/bin/abstract.so/gcc/debug/runtime-link
> -dynamic/shared-linkable-true/abstract.so"
> -L/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/config
> -L../../../libs/python/build/bin/libboost_python.so/gcc/debug/runt
> ime-link-dynamic/shared-linkable-true
> "../../../libs/python/build/bin/abstract.so/gcc/debug/runtime-link
> -dynamic/shared-linkable-true/abstract.o"
> -lutil -lboost_python
>
----------------------------------------
-----------------------------------------

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu






From david.abrahams at rcn.com  Thu Jun 13 15:18:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 09:18:04 -0400
Subject: [C++-sig] OS X
References: <PCEJJPDHEECNEKDDLPNLGEBJCAAA.ssmith@magnet.fsu.edu>
Message-ID: <01f201c212dc$c199ea70$6501a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> The same problem occurs on OS X with -isystem, I had already
> just replaced this in the gcc-tools file. As for the __GNUG__
> I tried to do this in gcc-tools too but that caused complaints
> about it being defined twice. I know I can just set this with
> -D on the command line, I guess my question was more of
> where is this set for bjam? The same for isystem, how is bjam
> (not)figuring out what to set this as.

bjam doesn't figure out any of these settings, it just invokes g++.

As the maintainer of Boost.Build I am really uncomfortable with not knowing
why -isystem isn't working properly in some environments. It's documented
in the GCC manual, so it should work. I want to submit a bug report to the
appropriate people, or fix one of my own, but I don't have the compilation
environments where it's causing the problems. Ralf, I would really
appreciate it if you could at least generate the preprocessor output for a
file which fails to compile using both -I and -isystem, so I can diff them.

Thanks,
Dave






From david.abrahams at rcn.com  Thu Jun 13 16:06:24 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 10:06:24 -0400
Subject: [C++-sig] What's wrong here? (BPL V2)
References: <200206130417.29282.bugcreator@gmx.de>
Message-ID: <001401c212e3$8292cc50$6601a8c0@boostconsulting.com>

My mistake, Dominic,

It's now fixed in CVS.

Thanks for reporting this.

-Dave





From bugcreator at gmx.de  Thu Jun 13 17:18:56 2002
From: bugcreator at gmx.de (Dominic =?windows-1252?q?Sacr=E9?=)
Date: Thu, 13 Jun 2002 17:18:56 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <001401c212e3$8292cc50$6601a8c0@boostconsulting.com>
References: <200206130417.29282.bugcreator@gmx.de> <001401c212e3$8292cc50$6601a8c0@boostconsulting.com>
Message-ID: <200206131708.57165.bugcreator@gmx.de>

On Thursday 13 June 2002 16:06, David Abrahams wrote:
> My mistake, Dominic,
>
> It's now fixed in CVS.

Thanks, works now...
But what about the second problem? I still can't compile with 
gcc-2.95.3...

And I have another question... If I remember correctly, I already asked 
the same a few months ago, but at that time I was using v1. Now I 
switched to v2, and I have the same problem again...

If I have a PyObject*, and I know that it points to a wrapped C++ class,
how can I get a pointer to the C++ object?

With v1 I used
from_python (p, boost::python::type<Foo *>())
but I can't find the v2 equivalent.
Probably I'm missing something obvious again...

Thanks,
    Dominic




From rwgk at yahoo.com  Thu Jun 13 17:41:26 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 13 Jun 2002 08:41:26 -0700 (PDT)
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <200206131708.57165.bugcreator@gmx.de>
Message-ID: <20020613154126.77567.qmail@web20207.mail.yahoo.com>

--- Dominic Sacr? <bugcreator at gmx.de> wrote:
> If I have a PyObject*, and I know that it points to a wrapped C++ class,
> how can I get a pointer to the C++ object?
> 
> With v1 I used
> from_python (p, boost::python::type<Foo *>())
> but I can't find the v2 equivalent.
> Probably I'm missing something obvious again...

David is currently working on the user-level from_python equivalent.
Until then, here is what I use as a place-holder (haven't tried it
to extract pointers, though):

#include <boost/python/converter/return_from_python.hpp>

  template <typename U>
  struct extractor
  {
    static
    U
    get(PyObject* obj)
    {
      Py_INCREF(obj);
      return converter::return_from_python<U>()(obj);
    }
  };

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From ssmith at magnet.fsu.edu  Thu Jun 13 17:46:24 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 13 Jun 2002 11:46:24 -0400
Subject: [C++-sig] Linux
References: <NFBBINAMBILHLOCDJKAECEBHCCAA.ssmith@magnet.fsu.edu>
Message-ID: <3D08BE50.3000105@magnet.fsu.edu>

Hello,

Can someone please explain what Jam looks for in deciding whether to build
Boost.Python or not? I am now trying the build on Linux and (I'm special)
it does not want to do it. The rest of Boost has no problems. Here is what
is set in my environment (from env | grep PY)

PYTHON_LIB_PATH=/usr/lib/python2.2/config
PYTHON=/usr/bin/python2
PYTHON_STDLIB_PATH=/usr/lib/python2.2
PYTHON_VERSION=2.2
PYTHON_INCLUDES=/usr/include/python2.2
PYTHON_ROOT=/usr

All of this looks proper to me, this is exactly where things are on my 
system.
That pretty much covers everything listed on 
http://www.boost.org/libs/python/doc/building.html
Yet when I do the build I still get the following

[ssmith at gamma5 boostcvs]$ bjam -sTOOLS=gcc -sBUILD=debug

---------------------------------------------------------------------
skipping Boost.Python library build
You can configure the location of your python installation, by setting:
PYTHON_ROOT    - currently "/usr"
PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. 
"2.2", NOT "2.2.1")  - currently "2.2"

The following are automatically configured from PYTHON_ROOT if not 
otherwise set:
    PYTHON_INCLUDES    - path to Python #include directories; currently 
"/usr/include/python2.2"
    PYTHON_LIB_PATH    - path to Python library; currently  
"/usr/lib/python2.2/config"
    PYTHON_STDLIB_PATH - path to Python standard library modules; 
currently "/usr/lib/python2.2"
---------------------------------------------------------------------

All of the above looks proper too.... what else is there? It must be 
looking for something that
I cannot find documented. I have found libs/python/build/__init__.py 
that puts out this stuff, and libs/python/build/Jamfile that has 
<find-python-install> which apparently causes the failure.
I guess this is looking for some subdirectory named test stemming from 
PYTHON_STDLIB_PATH?
My Red Hat 7.3 install (very recently done, I would call it a typical 
install)  has no such directory.
Do I need this test directory, do I need its contents?

Thanks,
Scott








From david.abrahams at rcn.com  Thu Jun 13 18:01:48 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 12:01:48 -0400
Subject: [C++-sig] Linux
References: <NFBBINAMBILHLOCDJKAECEBHCCAA.ssmith@magnet.fsu.edu> <3D08BE50.3000105@magnet.fsu.edu>
Message-ID: <00d701c212f3$f9c89420$6601a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hello,
>
> Can someone please explain what Jam looks for in deciding whether to
build
> Boost.Python or not?

> I cannot find documented. I have found libs/python/build/__init__.py
> that puts out this stuff, and libs/python/build/Jamfile that has
> <find-python-install> which apparently causes the failure.
> I guess this is looking for some subdirectory named test stemming from
> PYTHON_STDLIB_PATH?

Yes. You don't have it?

> My Red Hat 7.3 install (very recently done, I would call it a typical
> install)  has no such directory.

That's very odd. No /usr/lib/python2.2/test ?

> Do I need this test directory, do I need its contents?

No, you don't need its contents. It's just being used as a hack to help us
detect the Python installation. You could just clear the contents of
libs/python/build/__init__.py. I will have to revise the way this test
works for Boost 1.29.0

BTW, this test is not done for Boost.Build v2; if you're seeing it with an
attempted v2 build, you're building from the wrong place.

-Dave






From david.abrahams at rcn.com  Thu Jun 13 18:21:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 12:21:16 -0400
Subject: [C++-sig] What's wrong here? (BPL V2)
References: <200206130417.29282.bugcreator@gmx.de> <001401c212e3$8292cc50$6601a8c0@boostconsulting.com> <200206131708.57165.bugcreator@gmx.de>
Message-ID: <010901c212f6$58c84590$6601a8c0@boostconsulting.com>

From: "Dominic Sacr?" <bugcreator at gmx.de>
<<On Thursday 13 June 2002 16:06, David Abrahams wrote:>>
> My mistake, Dominic,
>
> It's now fixed in CVS.

<<Thanks, works now...
But what about the second problem? I still can't compile with
gcc-2.95.3...>>

I have no clue; your code compiles fine for me with that front-end. The
error messages make it look like the source was corrupted (I don't use the
symbol "Aindex" anywhere).

<<And I have another question... If I remember correctly, I already asked
the same a few months ago, but at that time I was using v1. Now I
switched to v2, and I have the same problem again...

If I have a PyObject*, and I know that it points to a wrapped C++ class,
how can I get a pointer to the C++ object?>>

Ralf gave the answer...

-D






From david.abrahams at rcn.com  Thu Jun 13 18:26:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 12:26:12 -0400
Subject: [C++-sig] boost 1.28 on OS X
References: <Pine.LNX.4.44.0206122158530.8377-100000@mambo.peabody.jhu.edu>
Message-ID: <011c01c212f7$0bfa99b0$6601a8c0@boostconsulting.com>

From: <ich at peabody.jhu.edu>

> I'm having difficulty porting boost 1.28 to OS X using Apple's version of
> gcc 3.1, which does not seems to initialize templated static data
members.

3.1 isn't supported for Boost.Python v1; There are conformance bugs in the
library which prevent it from working with more-modern compilers, which is
one of the reasons for Boost.Python v2.

It doesn't look like you're running into those particular problems, though
:(





From ich at peabody.jhu.edu  Thu Jun 13 18:29:28 2002
From: ich at peabody.jhu.edu (ich at peabody.jhu.edu)
Date: Thu, 13 Jun 2002 12:29:28 -0400 (EDT)
Subject: [C++-sig] boost 1.28 on OS X
In-Reply-To: <NFBBINAMBILHLOCDJKAEKEBHCCAA.ssmith@magnet.fsu.edu>
Message-ID: <Pine.LNX.4.44.0206131202040.11304-100000@mambo.peabody.jhu.edu>

On Thu, 13 Jun 2002, Scott A. Smith wrote:

> Ichiro,
> 
> I am trying to build boost CVS on OS X, can you tell me what you
> did in the 1.28.0 build? For example, I see you are able to link
> to -lutil, I cannot. Did this library come on your system or did
> you install it? 
>
No, it's just a link to libSystem.B.dylib: 
ln -s libSystem.B.dylib libutil.dylib

> Also I see you have Python in /usr/local/bin, did
> you build this yourself (I used Fink and it puts it in /sw somewhere).
>
Also a link to :
/Library/Frameworks/Python.framework/Versions/Current/bin/python

I don't use Fink.

> Did all of this work directly or have you needed to mess around with
> the jam stuff?  
>
I've messed around quite a bit. 8-)

> How did you get the -framework flags in the build
> commands? My system is behaving quite differently than yours
> even on the build of 1.28.0.
> 
In boost_1_28_0/tools/buidl/gcc-tools.jam:
Replaced (line 205):
    flags gcc LINKFLAGS <target-type>$(SHARED_TYPES) : -shared ;
with:
 flags gcc LINKFLAGS <target-type>$(SHARED_TYPES) : -bundle -bundle_loader 
/usr/local/bin/python -framework Python -framework System -flat_namespace 
-undefined warning -lstdc++ ;

> I am using GCC 2.95 and also saw problems with templates when building
> the tests with 1.28.0, but now I am trying the latest CVS stuff.
>
I also build a different type of libboost_python by:
cd 
boost_1_28_0/libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true
ld -dynamic -r -o libboost_python.dylib *.o 

So that it can be linked by other static linker (ld).

Ichiro

> Thanks,
> Scott
> 
> 
> > I'm having difficulty porting boost 1.28 to OS X using Apple's version of
> > gcc 3.1, which does not seems to initialize templated static data members.
> >
> > I've sent email to darwin-GCC3 at opensource.apple.com yesterday but haven't
> > heard back yet (email included below).
> >
> > For example, with the abstract test, I get:
> >
> > c++   -g -fPIC -bundle -bundle_loader /usr/local/bin/python -framework
> > Python -framework System -flat_namespace -undefined warning -lstdc++  -o
> > "../../../libs/python/build/bin/abstract.so/gcc/debug/runtime-link
> > -dynamic/shared-linkable-true/abstract.so"
> > -L/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/config
> > -L../../../libs/python/build/bin/libboost_python.so/gcc/debug/runt
> > ime-link-dynamic/shared-linkable-true
> > "../../../libs/python/build/bin/abstract.so/gcc/debug/runtime-link
> > -dynamic/shared-linkable-true/abstract.o"
> > -lutil -lboost_python
> >
> ----------------------------------------
> -----------------------------------------
> 
>  Dr. Scott A. Smith
>  Associate in Research
>  National High Magnetic Field Laboratory
>  1800 East Paul Dirac Drive
>  Tallahassee, FL 32310
> 
>  phone: (850) 644-6348
>  FAX:   (850) 644-1366
>  email: ssmith at magnet.fsu.edu
>  http://www.magnet.fsu.edu
>  http://gamma.magnet.fsu.edu
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 






From ich at peabody.jhu.edu  Thu Jun 13 18:46:57 2002
From: ich at peabody.jhu.edu (ich at peabody.jhu.edu)
Date: Thu, 13 Jun 2002 12:46:57 -0400 (EDT)
Subject: [C++-sig] boost 1.28 on OS X
In-Reply-To: <011c01c212f7$0bfa99b0$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.44.0206131236380.11304-100000@mambo.peabody.jhu.edu>

> 3.1 isn't supported for Boost.Python v1; There are conformance bugs in the
> library which prevent it from working with more-modern compilers, which is
> one of the reasons for Boost.Python v2.
> 
> It doesn't look like you're running into those particular problems, though
> :(
> 

Unfortunately, we have a quite a bit of code written in V1, which works
great under linux.  Any tips on why I'm getting the errors under gcc
2.95, e.g.:

ld: warning undefined symbols:
___tiQ45boost6python6detailt15instance_holder1ZQ25boostt8rational1Zi
___tiQ45boost6python6detailt15instance_holder1ZQ28bpl_test12CallbackTest
___tiQ45boost6python6detailt15instance_holder1ZQ28bpl_test12OverloadTest
...
___tiQ45boost6python6detailt19instance_ptr_holder2ZQ25boostt10shared_ptr1ZQ28bpl_test3FooZB2
___tiQ45boost6python6detailt19instance_ptr_holder2Zt8auto_ptr1ZQ28bpl_test3BazZB2

You mention about a bug in class_builder.hpp.  Do you think this is 
related?

Thanks,

Ichiro







From david.abrahams at rcn.com  Thu Jun 13 18:42:54 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 12:42:54 -0400
Subject: [C++-sig] Boost.Python v2: reference-counting and user-friendly conversions
Message-ID: <013e01c212f9$da854940$6601a8c0@boostconsulting.com>

So handle<> went into the codebase as a replacement for reference<> last
night. I hope it didn't cause too much pain. Contradicting my earlier
suggestion, and because Python  so commonly passes back new references, the
protocol for reference-counting remained the same as with reference<>: the
constructor does not increment the reference count of its argument by
default. Also, at least for the time being, the default behavior is to
throw an exception if it is initialized with a zero pointer. This might be
changed once the "object" class, discussed below, is finished.

The interface for causing the reference count to be incremented has
changed: now one passes the argument through the borrow() function,
signaling that we are getting a borrowed reference:

    handle<> x(borrow(PyTuple_GetItem(t, n)));

The interface for accepting null pointer arguments without throwing an
exception is similar:

    handle<> x(allow_null(PyObject_GetAttrString(o, name)));


Now, on to user-friendly conversions. It seems to me that the best way to
spell to_python(x) would be simply:

    object(x)

That is, object would have a templated explicit constructor which performs
the conversion. But don't be distracted by this, it doesn't change any of
the issues below (we have all the same problems if we spell it object x =
to_python(x)).

So, what's the behavior when the user passes a raw PyObject*? It seems to
me that we'd like the following to work:

    object(PyObject_GetAttrString(some_PyObject_pointer,
"some_attribute_name"))

Which implies, of course, that object has the same reference-counting
behavior as handle<>. However, the explicit to_python conversion behavior
is currently defined to be the same as that which is used for arguments to
call<> and call_method<>. Let's take a look at what's defined there:

Right now, if you pass a PyObject* as an argument to call<>, we first check
for NULL (in which case we manufacture a reference to None) then the
reference count is incremented before the arg_to_python converter takes
possession.

So that contradicts the desired semantics for object construction. Now, I'm
less-than-confident that the NULL => None behavior for arguments to call<>
is really preferable to throwing an immediate exception when NULL is
passed, however, it seems obvious to me that we don't want call<> stealing
references from arbitrary PyObject*s. I think this just goes to prove once
again that manual reference-counting is nasty.

There's also the issue of converting other raw Python object pointers, of
which there are two varieties:

A. Pointers to C++ classes derived from PyObject
B. Pointers to POD structs which are layout-compatible with PyObject, e.g.
PyTypeObject*. These are pseudo-derived types.

I can reliably detect A above, but very few compilers can detect B, and
then it's a crapshoot (you can look for a publicly-accessible ob_refcnt
member of the right type, for example). We could work around that with a
traits class that the user explicitly specializes for each "pseudo-derived"
type he wants to use.

Questions:

1. How should we handle raw Python object arguments to
call<>/call_method<>?
    a. is NULL->None conversion a good idea for these particular pointers?
       I still think it makes sense for most pointers, but maybe not these.
       see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/callbacks.html
       for a review of semantics

    b. is there any reason to think that stealing semantics should be
       introduced, so that:

            call<void>(my_function, PyObject_GetAttrString(x, y))

       would work correctly? Remember that we will be providing wrappers
for
       the Python API functions. Also remember that my_function is
currently
       a PyObject* which is /not/ stolen.

    c. Is it important to be able to accept variety A and B of
       raw Python object pointer as arguments here? Remember that we will
       have object and handle<> whose refcount semantics are unambiguous

    d. Is it reasonable to require a traits specialization or other action
       from the user to explicitly denote variety B? We can neither
generate
       a compile-time error nor special handling if we can't detect them.

2. How should we handle raw Python object arguments to the object()
constructor?
    a. is NULL->None conversion a good idea for these particular pointers?

    b. is there any reason to think that stealing semantics should not be
       used?

    c. Is it important to be able to accept variety A and B of
       raw Python object pointer as arguments here? Remember that we will
       have object and handle<> whose refcount semantics are unambiguous

Thanks for your feedback,
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 bugcreator at gmx.de  Thu Jun 13 18:43:45 2002
From: bugcreator at gmx.de (Dominic =?windows-1252?q?Sacr=E9?=)
Date: Thu, 13 Jun 2002 18:43:45 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <010901c212f6$58c84590$6601a8c0@boostconsulting.com>
References: <200206130417.29282.bugcreator@gmx.de> <200206131708.57165.bugcreator@gmx.de> <010901c212f6$58c84590$6601a8c0@boostconsulting.com>
Message-ID: <200206131843.45785.bugcreator@gmx.de>

On Thursday 13 June 2002 18:21, David Abrahams wrote:
> From: "Dominic Sacr?" <bugcreator at gmx.de>
> But what about the second problem? I still can't compile with
> gcc-2.95.3...>>
>
> I have no clue; your code compiles fine for me with that front-end. The
> error messages make it look like the source was corrupted (I don't use
> the symbol "Aindex" anywhere).

Hmm... the source doesn't seem to be corrupted.
This is the piece of code from converter/arg_to_python.hpp that gcc 
complains about...

# define BOOST_PYTHON_ARG_TO_PYTHON_GET(index,ignored)     \
    converter::arg_to_python<BOOST_PP_CAT(A,index)>(       \
        BOOST_PP_CAT(a,index)).get()

Perhaps it's a problem with Boost.Preprocessor?

    Dominic






From david.abrahams at rcn.com  Thu Jun 13 18:50:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 12:50:06 -0400
Subject: [C++-sig] boost 1.28 on OS X
References: <Pine.LNX.4.44.0206131236380.11304-100000@mambo.peabody.jhu.edu>
Message-ID: <014701c212fa$5fd3df80$6601a8c0@boostconsulting.com>

From: <ich at peabody.jhu.edu>

> Unfortunately, we have a quite a bit of code written in V1, which works
> great under linux.  Any tips on why I'm getting the errors under gcc
> 2.95, e.g.:
>
> ld: warning undefined symbols:
> ___tiQ45boost6python6detailt15instance_holder1ZQ25boostt8rational1Zi
> ___tiQ45boost6python6detailt15instance_holder1ZQ28bpl_test12CallbackTest
> ___tiQ45boost6python6detailt15instance_holder1ZQ28bpl_test12OverloadTest
> ...
>
___tiQ45boost6python6detailt19instance_ptr_holder2ZQ25boostt10shared_ptr1ZQ
28bpl_test3FooZB2
>
___tiQ45boost6python6detailt19instance_ptr_holder2Zt8auto_ptr1ZQ28bpl_test3
BazZB2

Nope, sorry.

> You mention about a bug in class_builder.hpp.

I did?





From david.abrahams at rcn.com  Thu Jun 13 19:13:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 13:13:39 -0400
Subject: [C++-sig] What's wrong here? (BPL V2)
References: <200206130417.29282.bugcreator@gmx.de> <200206131708.57165.bugcreator@gmx.de> <010901c212f6$58c84590$6601a8c0@boostconsulting.com> <200206131843.45785.bugcreator@gmx.de>
Message-ID: <015f01c212fd$e2d37550$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dominic Sacr?" <bugcreator at gmx.de>

<<Perhaps it's a problem with Boost.Preprocessor?>>

I dunno. There have been some recent changes to that lib. When was your
last cvs update?





From ich at peabody.jhu.edu  Thu Jun 13 19:23:44 2002
From: ich at peabody.jhu.edu (ich at peabody.jhu.edu)
Date: Thu, 13 Jun 2002 13:23:44 -0400 (EDT)
Subject: [C++-sig] boost 1.28 on OS X
In-Reply-To: <014701c212fa$5fd3df80$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.44.0206131320230.11575-100000@mambo.peabody.jhu.edu>

On Thu, 13 Jun 2002, David Abrahams wrote:
> From: <ich at peabody.jhu.edu>
> 
> > You mention about a bug in class_builder.hpp.
> 
> I did?
> 
I meant "MSVC6.x/GCC2.95.2 bug" described in class_builder.hpp.  Perhaps 
it was Ralf.

Ichiro






From david.abrahams at rcn.com  Thu Jun 13 19:46:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 13:46:08 -0400
Subject: [C++-sig] boost 1.28 on OS X
References: <Pine.LNX.4.44.0206131320230.11575-100000@mambo.peabody.jhu.edu>
Message-ID: <019201c21302$894666f0$6601a8c0@boostconsulting.com>

From: <ich at peabody.jhu.edu>

> On Thu, 13 Jun 2002, David Abrahams wrote:
> > From: <ich at peabody.jhu.edu>
> >
> > > You mention about a bug in class_builder.hpp.
> >
> > I did?
> >
> I meant "MSVC6.x/GCC2.95.2 bug" described in class_builder.hpp.  Perhaps
> it was Ralf.

I don't think it's related. It seems to be complaining about missing
type_info records.





From ssmith at magnet.fsu.edu  Thu Jun 13 19:30:21 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 13 Jun 2002 13:30:21 -0400
Subject: [C++-sig] Linux
References: <NFBBINAMBILHLOCDJKAECEBHCCAA.ssmith@magnet.fsu.edu> <3D08BE50.3000105@magnet.fsu.edu> <00d701c212f3$f9c89420$6601a8c0@boostconsulting.com>
Message-ID: <3D08D6AD.8030601@magnet.fsu.edu>

Hi Dave,

>
>That's very odd. No /usr/lib/python2.2/test ?
>
Nope. I've decided I am just extremely lucky with all of my recent 
dealings with Boost! My problems with the RH 7.3 Linux build were not 
due to any environment variable settings, but due to a lack of a Python 
test directory, in this case /usr/lib/python2.2/test. I downloaded the
Python sources and copied its Lib/test there instead.  The build then  
worked perfectly.

>
>No, you don't need its contents. 
>
Good, because I don't know if the one I copied is the proper test 
directory?  I have
looked to see that other Python RPM's include a test directory, but I 
 haven't found one yet that will use the newer libraries on my system or 
I would just reinstall it. I don't know why RH didn't install the test 
directory when Linux (Python) was installed. My disks are at home so
I can't check to see if it is provided somewhere at all.  I 'll have a 
look see at home tonight.
I am pretty sure that my system at home does not have this test 
directory either and I normally
install all of the development stuff when I put Linux on.

>
>BTW, this test is not done for Boost.Build v2; if you're seeing it with an
>attempted v2 build, you're building from the wrong place.
>
I was building 1.28.0 from the boost_1_28_0 directory. I started using 
that now for all builds so I would not confuse myself over version 
issues, evidently that did not work....as I guess I've just figured the 
"versioning" out. As for the latest CVS, the build from libs/python works
fine without any Python test directory. Got it, this is V2 because it 
makes libbpl.so.
Alternatively, a build of Boost from the main directory complains about 
the missing
test directory and will not make Boost.Python.  Then if I reinstate the 
Python test directory and build from my  Boost root it runs fine with no 
complaints about Python missing and makes libboost_python.so .... OK 
that is V1.

So then, is v1 vs. v2 just applicable to Boost.Python. not the overall 
Boost package?

Anyhow, this Linux problem is solved.
Thanks,
Scott






From david.abrahams at rcn.com  Thu Jun 13 20:02:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 14:02:07 -0400
Subject: [C++-sig] Linux
References: <NFBBINAMBILHLOCDJKAECEBHCCAA.ssmith@magnet.fsu.edu> <3D08BE50.3000105@magnet.fsu.edu> <00d701c212f3$f9c89420$6601a8c0@boostconsulting.com> <3D08D6AD.8030601@magnet.fsu.edu>
Message-ID: <01c301c21304$7bec5d00$6601a8c0@boostconsulting.com>

----- Original Message ----- 
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> So then, is v1 vs. v2 just applicable to Boost.Python. not the overall 
> Boost package?

Yes.

-Dave






From daveh at cadlink.com  Thu Jun 13 20:10:28 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 13 Jun 2002 14:10:28 -0400
Subject: [C++-sig] Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com>
Message-ID: <aean6r$u0k$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:013e01c212f9$da854940$6601a8c0 at boostconsulting.com...
>
> Questions:
>
> 1. How should we handle raw Python object arguments to
> call<>/call_method<>?
>     a. is NULL->None conversion a good idea for these particular pointers?
>        I still think it makes sense for most pointers, but maybe not
these.
>        see
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> python/doc/v2/callbacks.html
>        for a review of semantics

As this probably acceptable for the fast majority of cases then yes, but
provide the ability to pass a true NULL by passing something like a
null_object class if the user really does need to do this.

>
>     b. is there any reason to think that stealing semantics should be
>        introduced, so that:
>
>             call<void>(my_function, PyObject_GetAttrString(x, y))
>
>        would work correctly? Remember that we will be providing wrappers
> for
>        the Python API functions. Also remember that my_function is
> currently
>        a PyObject* which is /not/ stolen.
>

Which then begs the question should a raw PyObject be allowed as an argument
at all? Is it too much too insist that the user does this:

    call<void>(my_function, handle<>(PyObject_GetAttrString(x, y)))

that way we can also do:

    call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))


>     c. Is it important to be able to accept variety A and B of
>        raw Python object pointer as arguments here? Remember that we will
>        have object and handle<> whose refcount semantics are unambiguous
>

see above.

>     d. Is it reasonable to require a traits specialization or other action
>        from the user to explicitly denote variety B? We can neither
> generate
>        a compile-time error nor special handling if we can't detect them.
>

I would prefer just to rely on the type conversion provided by handle<> etc.

    PyTypeObject* p
    handle<>(type_handle(p)).get()

If the handle type conversion can be verified at compile time then fine, if
it can't then we will have to rely on run-time exceptions.

> 2. How should we handle raw Python object arguments to the object()
> constructor?
>     a. is NULL->None conversion a good idea for these particular pointers?
>

Yes, if there is some explicit way to create a NULL if we really need one,
maybe it should be a derived class, null_object ?

>     b. is there any reason to think that stealing semantics should not be
>        used?
>

We will then have to live with this assumption once people are using V2 and
it will be difficult to go back. I'd rather disallow raw PyObjects.

>     c. Is it important to be able to accept variety A and B of
>        raw Python object pointer as arguments here? Remember that we will
>        have object and handle<> whose refcount semantics are unambiguous
>

No, get rid of the raw PyObjects, If we have an effective solution in handle
lets concentrate reference counting, type converting etc. in one place.

Dave Hawkes









From bugcreator at gmx.de  Thu Jun 13 22:27:30 2002
From: bugcreator at gmx.de (Dominic =?windows-1252?q?Sacr=E9?=)
Date: Thu, 13 Jun 2002 22:27:30 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <015f01c212fd$e2d37550$6601a8c0@boostconsulting.com>
References: <200206130417.29282.bugcreator@gmx.de> <200206131843.45785.bugcreator@gmx.de> <015f01c212fd$e2d37550$6601a8c0@boostconsulting.com>
Message-ID: <200206132226.08187.bugcreator@gmx.de>

On Thursday 13 June 2002 19:13, David Abrahams wrote:
> ----- Original Message -----
> From: "Dominic Sacr?" <bugcreator at gmx.de>
>
> <<Perhaps it's a problem with Boost.Preprocessor?>>
>
> I dunno. There have been some recent changes to that lib. When was your
> last cvs update?

Yesterday. But I also tried it with older versions of the preprocessor 
library now, same result...

    Dominic






From bugcreator at gmx.de  Thu Jun 13 22:24:10 2002
From: bugcreator at gmx.de (Dominic =?iso-8859-1?q?Sacr=E9?=)
Date: Thu, 13 Jun 2002 22:24:10 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <20020613154126.77567.qmail@web20207.mail.yahoo.com>
References: <20020613154126.77567.qmail@web20207.mail.yahoo.com>
Message-ID: <200206132220.52555.bugcreator@gmx.de>

On Thursday 13 June 2002 17:41, Ralf W. Grosse-Kunstleve wrote:
> David is currently working on the user-level from_python equivalent.
> Until then, here is what I use as a place-holder (haven't tried it
> to extract pointers, though):
>
> #include <boost/python/converter/return_from_python.hpp>
>
>   template <typename U>
>   struct extractor
>   {
>     static
>     U
>     get(PyObject* obj)
>     {
>       Py_INCREF(obj);
>       return converter::return_from_python<U>()(obj);
>     }
>   };

Apparently extracting pointers doesn't work, I got a SIGABRT when I tried 
that...
This extractor works if I can return an object by making a copy of it, but 
what I need is just a pointer, the object is noncopyable.

Any ideas?
I can post the backtrace if that's of any use.

    Dominic






From david.abrahams at rcn.com  Thu Jun 13 23:25:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 17:25:12 -0400
Subject: [C++-sig] Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <aean6r$u0k$1@main.gmane.org>
Message-ID: <01ef01c21321$6c19bdb0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:013e01c212f9$da854940$6601a8c0 at boostconsulting.com...
> >
> > Questions:
> >
> > 1. How should we handle raw Python object arguments to
> > call<>/call_method<>?
> >     a. is NULL->None conversion a good idea for these particular
pointers?
> >        I still think it makes sense for most pointers, but maybe not
> these.
> >        see
> >
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> > python/doc/v2/callbacks.html
> >        for a review of semantics
>
> As this probably acceptable for the fast majority of cases then yes, but
> provide the ability to pass a true NULL by passing something like a
> null_object class if the user really does need to do this.

No, I don't think so. That would construct an argument tuple containing a
NULL object entry, and that's never legitimate.

> >
> >     b. is there any reason to think that stealing semantics should be
> >        introduced, so that:
> >
> >             call<void>(my_function, PyObject_GetAttrString(x, y))
> >
> >        would work correctly? Remember that we will be providing
wrappers
> > for
> >        the Python API functions. Also remember that my_function is
> > currently
> >        a PyObject* which is /not/ stolen.
> >
>
> Which then begs the question should a raw PyObject be allowed as an
argument
> at all? Is it too much too insist that the user does this:

Yes, that's what I'm asking below.

>     call<void>(my_function, handle<>(PyObject_GetAttrString(x, y)))
>
> that way we can also do:
>
>     call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))

Yeah; I had that thought myself. The only problem here is that making
variety "B" pointers (at least the ones we don't already know about) cause
a compiler error depends on the user specializing some traits, with the
only purpose being to make certain code fail to compile. Who's going to do
that?

OTOH, we already know about most of the variety B pointers.

> >     d. Is it reasonable to require a traits specialization or other
action
> >        from the user to explicitly denote variety B? We can neither
> > generate
> >        a compile-time error nor special handling if we can't detect
them.
> >
>
> I would prefer just to rely on the type conversion provided by handle<>
etc.
>
>     PyTypeObject* p
>     handle<>(type_handle(p)).get()
>
> If the handle type conversion can be verified at compile time then fine,

How do you think the conversion above works? There's a traits class called
base_type_traits<>, specialized for PyTypeObject.

> if
> it can't then we will have to rely on run-time exceptions.

How would you do it at run-time?

> > 2. How should we handle raw Python object arguments to the object()
> > constructor?
> >     a. is NULL->None conversion a good idea for these particular
pointers?
> >
>
> Yes, if there is some explicit way to create a NULL if we really need
one,
> maybe it should be a derived class, null_object ?

All object instances will point to a real object; that's part of the
design, and I think not open to negotiation. You can always make a null
handle<> if you need one for something. I would need to see some
compelling, specific examples to be convinced otherwise. Remember, the
Python "C" API is always available if something really unusual is required.

> >     b. is there any reason to think that stealing semantics should not
be
> >        used?
> >
>
> We will then have to live with this assumption once people are using V2
and
> it will be difficult to go back. I'd rather disallow raw PyObjects.

That's a good point. Much better to try to live without a dangerous
facility first.

> >     c. Is it important to be able to accept variety A and B of
> >        raw Python object pointer as arguments here? Remember that we
will
> >        have object and handle<> whose refcount semantics are
unambiguous
> >
>
> No, get rid of the raw PyObjects, If we have an effective solution in
handle
> lets concentrate reference counting, type converting etc. in one place.

Very nice; thanks for the clear thinking!

-Dave






From david.abrahams at rcn.com  Thu Jun 13 23:53:33 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 17:53:33 -0400
Subject: [C++-sig] What's wrong here? (BPL V2)
References: <20020613154126.77567.qmail@web20207.mail.yahoo.com> <200206132220.52555.bugcreator@gmx.de>
Message-ID: <021701c21324$ec2df360$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dominic Sacr?" <bugcreator at gmx.de>

<<Apparently extracting pointers doesn't work, I got a SIGABRT when I tried
that...
This extractor works if I can return an object by making a copy of it, but
what I need is just a pointer, the object is noncopyable.>>

It should work. The extractor uses the same mechanism used to convert
results from python functions in call<> and call_method<>. From
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/callbacks.html:

Result Handling
In general, call<ResultType>() and call_method<ResultType>() return
ResultType by exploiting all lvalue and rvalue from_python converters
registered for ResultType and returning a copy of the result. However, when
ResultType is a pointer or reference type, Boost.Python searches only for
lvalue converters. To prevent dangling pointers and references, an
exception will be thrown if the Python result object has only a single
reference count.

<<Any ideas? I can post the backtrace if that's of any use.>>

It is possible that an exception is being thrown, but never caught.
Possible causes are as described above (hmm, the extractor used for
explicit conversions by users should probably not do this check. What
happens when you construct an additional handle<> to hold the source
object, just to force an additional reference?), and also that no lvalue
from_python converter is registered for the pointee type.

-Dave






From david.abrahams at rcn.com  Fri Jun 14 00:25:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 18:25:30 -0400
Subject: [C++-sig] boost 1.28 on OS X
References: <Pine.LNX.4.44.0206131320230.11575-100000@mambo.peabody.jhu.edu> <019201c21302$894666f0$6601a8c0@boostconsulting.com>
Message-ID: <024301c21329$d2e735b0$6601a8c0@boostconsulting.com>

Would those who are trying to get Boost.Python to build on OS X with bjam
kindly make themselves known on the jamboost list at
www.yahoogroups.com/group/jamboost? Rene Rivera, who has been maintaining
the gcc toolset, has graciously volunteered to coordinate efforts to add OS
X support. I think this problem could be solved relatively quickly with a
little cooperation.

Thanks,
Dave






From david.abrahams at rcn.com  Fri Jun 14 00:53:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 18:53:27 -0400
Subject: [C++-sig] Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <aean6r$u0k$1@main.gmane.org>
Message-ID: <028e01c2132d$25672d10$6601a8c0@boostconsulting.com>

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

> Which then begs the question should a raw PyObject be allowed as an
argument
> at all? Is it too much too insist that the user does this:
>
>     call<void>(my_function, handle<>(PyObject_GetAttrString(x, y)))
>
> that way we can also do:
>
>     call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))

It just occurred to me that we can allow

    call<void>(my_function, borrow(PyImport_AddModule(name)))

as a convenience.

Regards,
Dave






From rwgk at yahoo.com  Fri Jun 14 01:46:22 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 13 Jun 2002 16:46:22 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: reference-counting and user-friendly conversions
In-Reply-To: <013e01c212f9$da854940$6601a8c0@boostconsulting.com>
Message-ID: <20020613234622.90035.qmail@web20203.mail.yahoo.com>

> The interface for causing the reference count to be incremented has
> changed: now one passes the argument through the borrow() function,
> signaling that we are getting a borrowed reference:
> 
>     handle<> x(borrow(PyTuple_GetItem(t, n)));

"borrow" sounds like we are about to borrow something, when indeed
we are "signaling that we are getting a borrowed reference."
Therefore                                     ^^

      handle<> x(borrowed(PyTuple_GetItem(t, n)));

seems much more intuitive to me.

> Now, on to user-friendly conversions. It seems to me that the best way to
> spell to_python(x) would be simply:
> 
>     object(x)

Cool.

> So, what's the behavior when the user passes a raw PyObject*? It seems to
> me that we'd like the following to work:
>
>    object(PyObject_GetAttrString(some_PyObject_pointer,
>"some_attribute_name"))

Considering all the questions that follow, are you sure it is worth it?
I'd only expect to be able to do this:

     object(handle<>(PyObject_GetAttrString(
       some_PyObject_pointer, "some_attribute_name")))

If I understand correctly, eventually there will be a wrapper for
PyObject_GetAttrString anyway, so being able to construct an object()
from PyObject* directly as a convenience will not be interesting.

> Right now, if you pass a PyObject* as an argument to call<>, we first check
> for NULL (in which case we manufacture a reference to None) then the
> reference count is incremented before the arg_to_python converter takes
> possession.

If you'd make handle<> the only interface that accepts PyObject* you
could avoid many of your questions. You could make the NULL -> None
conversion explicit: in addition to borrowed() and allow_null() you
could supply null_to_none().

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Fri Jun 14 01:53:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 19:53:58 -0400
Subject: [C++-sig] Boost.Python v2: reference-counting and user-friendly conversions
References: <20020613234622.90035.qmail@web20203.mail.yahoo.com>
Message-ID: <02c101c21336$401b7c20$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Thursday, June 13, 2002 7:46 PM
Subject: Re: [C++-sig] Boost.Python v2: reference-counting and
user-friendly conversions


> > The interface for causing the reference count to be incremented has
> > changed: now one passes the argument through the borrow() function,
> > signaling that we are getting a borrowed reference:
> >
> >     handle<> x(borrow(PyTuple_GetItem(t, n)));
>
> "borrow" sounds like we are about to borrow something, when indeed
> we are "signaling that we are getting a borrowed reference."
> Therefore                                     ^^
>
>       handle<> x(borrowed(PyTuple_GetItem(t, n)));
>
> seems much more intuitive to me.

I had that thought myself, and will happily make the change if you don't
mind typing the extra two characters ;-)


> > So, what's the behavior when the user passes a raw PyObject*? It seems
to
> > me that we'd like the following to work:
> >
> >    object(PyObject_GetAttrString(some_PyObject_pointer,
> >"some_attribute_name"))
>
> Considering all the questions that follow, are you sure it is worth it?
> I'd only expect to be able to do this:
>
>      object(handle<>(PyObject_GetAttrString(
>        some_PyObject_pointer, "some_attribute_name")))

Hooray, consensus!

> If I understand correctly, eventually there will be a wrapper for
> PyObject_GetAttrString anyway, so being able to construct an object()
> from PyObject* directly as a convenience will not be interesting.

There's a small potential efficiency gain from not manipulating reference
counts, but not (IMO) worth it. The bare metal is always available if you
need it.

> > Right now, if you pass a PyObject* as an argument to call<>, we first
check
> > for NULL (in which case we manufacture a reference to None) then the
> > reference count is incremented before the arg_to_python converter takes
> > possession.
>
> If you'd make handle<> the only interface that accepts PyObject* you
> could avoid many of your questions. You could make the NULL -> None
> conversion explicit: in addition to borrowed() and allow_null() you
> could supply null_to_none().

Yep. Or, the user can write:

    p ? handle<>(p) : none()

Which is just fine.

Mind you, I still think NULL -> None makes sense for other pointers, e.g.
char*, MyWrappedClass*, ...

-Dave






From bugcreator at gmx.de  Fri Jun 14 02:10:02 2002
From: bugcreator at gmx.de (Dominic =?windows-1252?q?Sacr=E9?=)
Date: Fri, 14 Jun 2002 02:10:02 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <021701c21324$ec2df360$6601a8c0@boostconsulting.com>
References: <20020613154126.77567.qmail@web20207.mail.yahoo.com> <200206132220.52555.bugcreator@gmx.de> <021701c21324$ec2df360$6601a8c0@boostconsulting.com>
Message-ID: <200206140205.16744.bugcreator@gmx.de>

On Thursday 13 June 2002 23:53, David Abrahams wrote:
> It is possible that an exception is being thrown, but never caught.
> Possible causes are as described above (hmm, the extractor used for
> explicit conversions by users should probably not do this check. What
> happens when you construct an additional handle<> to hold the source
> object, just to force an additional reference?), and also that no
> lvalue from_python converter is registered for the pointee type.

Ah, you're right, it's indeed an exception I didn't catch:
ReferenceError: Attempt to return dangling internal reference

Constructing an additional handle<> doesn't change anything, I still get 
the same error...

In which situations would no converter be registered? Or do I somehow have 
to register a converter myself? Should/could these not be registered 
automatically, at least for simple classes?

    Dominic






From daveh at cadlink.com  Fri Jun 14 02:34:46 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 13 Jun 2002 20:34:46 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <aean6r$u0k$1@main.gmane.org> <01ef01c21321$6c19bdb0$6601a8c0@boostconsulting.com>
Message-ID: <aebdn5$hja$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:01ef01c21321$6c19bdb0$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > As this probably acceptable for the fast majority of cases then yes, but
> > provide the ability to pass a true NULL by passing something like a
> > null_object class if the user really does need to do this.
>
> No, I don't think so. That would construct an argument tuple containing a
> NULL object entry, and that's never legitimate.
>

OK, maybe it's not worth worrying about the small number of times a NULL
PyObject* is really needed. When the python function wrapping is completed
then we'll just use the no-argument versions.

> > >
> > >     b. is there any reason to think that stealing semantics should be
> > >        introduced, so that:
> > >
> > >             call<void>(my_function, PyObject_GetAttrString(x, y))
> > >
> > >        would work correctly? Remember that we will be providing
> wrappers
> > > for
> > >        the Python API functions. Also remember that my_function is
> > > currently
> > >        a PyObject* which is /not/ stolen.
> > >
> >
> > Which then begs the question should a raw PyObject be allowed as an
> argument
> > at all? Is it too much too insist that the user does this:
>
> Yes, that's what I'm asking below.
>
> >     call<void>(my_function, handle<>(PyObject_GetAttrString(x, y)))
> >
> > that way we can also do:
> >
> >     call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))
>
> Yeah; I had that thought myself. The only problem here is that making
> variety "B" pointers (at least the ones we don't already know about) cause
> a compiler error depends on the user specializing some traits, with the
> only purpose being to make certain code fail to compile. Who's going to do
> that?
>
> OTOH, we already know about most of the variety B pointers.
>
> > >     d. Is it reasonable to require a traits specialization or other
> action
> > >        from the user to explicitly denote variety B? We can neither
> > > generate
> > >        a compile-time error nor special handling if we can't detect
> them.
> > >
> >
> > I would prefer just to rely on the type conversion provided by handle<>
> etc.
> >
> >     PyTypeObject* p
> >     handle<>(type_handle(p)).get()
> >
> > If the handle type conversion can be verified at compile time then fine,
>
> How do you think the conversion above works? There's a traits class called
> base_type_traits<>, specialized for PyTypeObject.

I was thinking of just letting handle use the traits rather than call use
them as well, which would possibly add unnecessary complexity.

>
> > if
> > it can't then we will have to rely on run-time exceptions.
>
> How would you do it at run-time?

I wasn't sure if we could make use of  PyType_IsSubtype or
PyObject_IsSubclass in some cases.

>
> > > 2. How should we handle raw Python object arguments to the object()
> > > constructor?
> > >     a. is NULL->None conversion a good idea for these particular
> pointers?
> > >
> >
> > Yes, if there is some explicit way to create a NULL if we really need
> one,
> > maybe it should be a derived class, null_object ?
>
> All object instances will point to a real object; that's part of the
> design, and I think not open to negotiation. You can always make a null
> handle<> if you need one for something. I would need to see some
> compelling, specific examples to be convinced otherwise. Remember, the
> Python "C" API is always available if something really unusual is
required.
>

Will handle<> and object be able to be used interchangeably then?

> > >     b. is there any reason to think that stealing semantics should not
> be
> > >        used?
> > >
> >
> > We will then have to live with this assumption once people are using V2
> and
> > it will be difficult to go back. I'd rather disallow raw PyObjects.
>
> That's a good point. Much better to try to live without a dangerous
> facility first.
>

Yes, it would be easier to add this later if practical problems arise,
rather than take it away.

Dave Hawkes









From david.abrahams at rcn.com  Fri Jun 14 02:44:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 20:44:46 -0400
Subject: [C++-sig] What's wrong here? (BPL V2)
References: <20020613154126.77567.qmail@web20207.mail.yahoo.com> <200206132220.52555.bugcreator@gmx.de> <021701c21324$ec2df360$6601a8c0@boostconsulting.com> <200206140205.16744.bugcreator@gmx.de>
Message-ID: <02fe01c2133d$511f6520$6601a8c0@boostconsulting.com>

From: "Dominic Sacr?" <bugcreator at gmx.de>

<<Ah, you're right, it's indeed an exception I didn't catch:
ReferenceError: Attempt to return dangling internal reference>>

That's still strange. What was the context? The built-in handle_exception()
function should have converted this to something visible in Python.

<<<Constructing an additional handle<> doesn't change anything, I still get
the same error...>>

First remember that a handle<> adopts by default; to get it to increment
the reference count you need to pass the PyObject* through the borrow()
function.

<<In which situations would no converter be registered? Or do I somehow
have
to register a converter myself? Should/could these not be registered
automatically, at least for simple classes?>>

No, it's not possible to determine how simple a class is and register
converters automatically on that basis

Converters are registered for classes declared with class_<>.
There are also built-in converters registered for complex<T> and
std::string, though not lvalue converters (these are converted to/from the
corresponding Python types).

-Dave






From daveh at cadlink.com  Fri Jun 14 02:54:03 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 13 Jun 2002 20:54:03 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <aean6r$u0k$1@main.gmane.org> <028e01c2132d$25672d10$6601a8c0@boostconsulting.com>
Message-ID: <aebera$j7b$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:028e01c2132d$25672d10$6601a8c0 at boostconsulting.com...
> > that way we can also do:
> >
> >     call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))
>
> It just occurred to me that we can allow
>
>     call<void>(my_function, borrow(PyImport_AddModule(name)))
>
> as a convenience.

This seems just a contrivance really, I think it is still cleaner to
'disconnect' call from the whole new/borrowed reference symantics. Once the
function wrappers are in place it will be less of an issue anyway.

Also remember if someone really does want the reduced typing overhead of
passing in raw PyObjects it would be simple enough to create a templated
function wrapper that called the boost call function and wrapped the args in
appropriate handle<> constructs to steal the object anyway.

Dave Hawkes








From daveh at cadlink.com  Fri Jun 14 03:02:15 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 13 Jun 2002 21:02:15 -0400
Subject: [C++-sig] Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <20020613234622.90035.qmail@web20203.mail.yahoo.com>
Message-ID: <aebfam$k34$1@main.gmane.org>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote in message
news:20020613234622.90035.qmail at web20203.mail.yahoo.com...
> Therefore                                     ^^
>
>       handle<> x(borrowed(PyTuple_GetItem(t, n)));
>
> seems much more intuitive to me.
>

That does seem to more explicitly state what is occuring. There could even
be a derived borrowed_handle class:

       borrowed_handle<> x(PyTuple_GetItem(t, n));


Dave Hawkes









From david.abrahams at rcn.com  Fri Jun 14 03:03:21 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 21:03:21 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <aean6r$u0k$1@main.gmane.org> <01ef01c21321$6c19bdb0$6601a8c0@boostconsulting.com> <aebdn5$hja$1@main.gmane.org>
Message-ID: <06bf01c2133f$6c49f9d0$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:01ef01c21321$6c19bdb0$6601a8c0 at boostconsulting.com...
> > From: "Dave Hawkes" <daveh at cadlink.com>
> > >
> > > I would prefer just to rely on the type conversion provided by
handle<>
> > etc.
> > >
> > >     PyTypeObject* p
> > >     handle<>(type_handle(p)).get()
> > >
> > > If the handle type conversion can be verified at compile time then
fine,
> >
> > How do you think the conversion above works? There's a traits class
called
> > base_type_traits<>, specialized for PyTypeObject.
>
> I was thinking of just letting handle use the traits rather than call use
> them as well, which would possibly add unnecessary complexity.


OK.

> >
> > > if
> > > it can't then we will have to rely on run-time exceptions.
> >
> > How would you do it at run-time?
>
> I wasn't sure if we could make use of  PyType_IsSubtype or
> PyObject_IsSubclass in some cases.

Not without crashing in the cases when it's not a Python object pointer.

> Will handle<> and object be able to be used interchangeably then?

Not neccessarily in all cases. I still need convincing to see the
importance of this NULL business.

-Dave





From bugcreator at gmx.de  Fri Jun 14 04:04:49 2002
From: bugcreator at gmx.de (Dominic =?windows-1252?q?Sacr=E9?=)
Date: Fri, 14 Jun 2002 04:04:49 +0200
Subject: [C++-sig] What's wrong here? (BPL V2)
In-Reply-To: <02fe01c2133d$511f6520$6601a8c0@boostconsulting.com>
References: <20020613154126.77567.qmail@web20207.mail.yahoo.com> <200206140205.16744.bugcreator@gmx.de> <02fe01c2133d$511f6520$6601a8c0@boostconsulting.com>
Message-ID: <200206140401.06307.bugcreator@gmx.de>

On Friday 14 June 2002 02:44, David Abrahams wrote:
> <<Ah, you're right, it's indeed an exception I didn't catch:
> ReferenceError: Attempt to return dangling internal reference>>
>
> That's still strange. What was the context? The built-in
> handle_exception() function should have converted this to something
> visible in Python.

Well, I don't use handle_exception(), at least not directly.
I'm embedding Python in a C++ program, and not vice versa. I'm not quite 
sure what the correct way to handle exceptions is in this case, but the 
"usual" way won't work.
I was calling the extractor directly from C++, so there was no 
handle_exception() involved, and the exception wasn't caught.

> <<<Constructing an additional handle<> doesn't change anything, I still
> get the same error...>>
>
> First remember that a handle<> adopts by default; to get it to
> increment the reference count you need to pass the PyObject* through
> the borrow() function.

Whoops :O
No wonder that handle<> didn't help... But borrow() solves the problem 
indeed, the extractor works now!

Thanks,
    Dominic




From david.abrahams at rcn.com  Fri Jun 14 04:33:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 22:33:39 -0400
Subject: [C++-sig] What's wrong here? (BPL V2)
References: <20020613154126.77567.qmail@web20207.mail.yahoo.com> <200206140205.16744.bugcreator@gmx.de> <02fe01c2133d$511f6520$6601a8c0@boostconsulting.com> <200206140401.06307.bugcreator@gmx.de>
Message-ID: <06e801c21352$44639c60$6601a8c0@boostconsulting.com>

From: "Dominic Sacr?" <bugcreator at gmx.de>


On Friday 14 June 2002 02:44, David Abrahams wrote:
> <<Ah, you're right, it's indeed an exception I didn't catch:
> ReferenceError: Attempt to return dangling internal reference>>
>
> That's still strange. What was the context? The built-in
> handle_exception() function should have converted this to something
> visible in Python.

<<Well, I don't use handle_exception(), at least not directly.
I'm embedding Python in a C++ program, and not vice versa.>>

That explains everything. It's clear to me that we'll need to start
thinking your way as well pretty soon. Until then, thanks for blazing the
trail!

<< I'm not quite
sure what the correct way to handle exceptions is in this case, but the
"usual" way won't work.>>

Yah. There's no single correct approach for that scenario.

<<Whoops :O
No wonder that handle<> didn't help... But borrow() solves the problem
indeed, the extractor works now!>>

Great!






From david.abrahams at rcn.com  Fri Jun 14 04:39:45 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 13 Jun 2002 22:39:45 -0400
Subject: [C++-sig] Re: Boost.Python v2: reference-counting and user-friendly conversions
References: <013e01c212f9$da854940$6601a8c0@boostconsulting.com> <20020613234622.90035.qmail@web20203.mail.yahoo.com> <aebfam$k34$1@main.gmane.org>
Message-ID: <06e901c21352$448247f0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Thursday, June 13, 2002 9:02 PM
Subject: [C++-sig] Re: Boost.Python v2: reference-counting and
user-friendly conversions


>
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote in message
> news:20020613234622.90035.qmail at web20203.mail.yahoo.com...
> > Therefore                                     ^^
> >
> >       handle<> x(borrowed(PyTuple_GetItem(t, n)));
> >
> > seems much more intuitive to me.
> >
>
> That does seem to more explicitly state what is occuring. There could
even
> be a derived borrowed_handle class:
>
>        borrowed_handle<> x(PyTuple_GetItem(t, n));

I wouldn't do it that way; once constructed a borrowed_handle<> is just
like a handle<>; the type has no semantic value. However, making all the
conversions work would be very complicated.

Instead, you could write a handle-returning function which borrows if you
really want this:

template <class T>
handle<T> borrowed_handle(T* x) { return handle<T>(borrowed(x)); }

-dave





From stefan.seefeld at orthosoft.ca  Fri Jun 14 16:20:00 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Fri, 14 Jun 2002 10:20:00 -0400
Subject: [C++-sig] problems with boost.python and mipspro
Message-ID: <1be0774fd58e4ff6ec94b4413d2141023d0a08b8@>

hi there,

I just compiled boost.python on linux RH 7.3 (gcc 3.1)
as well as IRIX 6.5 (mipspro 7.3). All seemed to work
fine.

However, when trying to compile a little demo extension,
I got an error on IRIX as one boost header includes
<cstddef>, which doesn't seem to exist for mipspro 7.3
(it seems none of the C standard headers has been ported
to the std C++ namespace/file layout).

Since mipspro is listed as one of the tested platforms,
I'm probably missing something. ANy help would be highly
appreciated !

Regards,
		Stefan

PS: how big are the changes between boost.python v1 and v2
     on the interface level ? Does it make sense to start
     a project now with v1 and switch to v2 later when it
     is ready ?





From david.abrahams at rcn.com  Fri Jun 14 16:25:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 14 Jun 2002 10:25:14 -0400
Subject: [C++-sig] problems with boost.python and mipspro
References: <1be0774fd58e4ff6ec94b4413d2141023d0a08b8@>
Message-ID: <08b201c213af$66566de0$6601a8c0@boostconsulting.com>

From: "Stefan Seefeld" <stefan.seefeld at orthosoft.ca>

> PS: how big are the changes between boost.python v1 and v2
>      on the interface level ?

Pretty significant. The principles and the structure of your code are
similar, but the names and how they're used are all different.

> Does it make sense to start
>      a project now with v1 and switch to v2 later when it
>      is ready ?

I don't think so. V2 is pretty close to being ready now.
See http://mail.python.org/pipermail/c++-sig/2002-May/001100.html to get
started.

-Dave






From rwgk at yahoo.com  Fri Jun 14 18:27:31 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 14 Jun 2002 09:27:31 -0700 (PDT)
Subject: [C++-sig] problems with boost.python and mipspro
In-Reply-To: <1be0774fd58e4ff6ec94b4413d2141023d0a08b8@>
Message-ID: <20020614162731.15198.qmail@web20207.mail.yahoo.com>

--- Stefan Seefeld <stefan.seefeld at orthosoft.ca> wrote:
> hi there,
> 
> I just compiled boost.python on linux RH 7.3 (gcc 3.1)
> as well as IRIX 6.5 (mipspro 7.3). All seemed to work
> fine.
> 
> However, when trying to compile a little demo extension,
> I got an error on IRIX as one boost header includes
> <cstddef>, which doesn't seem to exist for mipspro 7.3
> (it seems none of the C standard headers has been ported
> to the std C++ namespace/file layout).
> 
> Since mipspro is listed as one of the tested platforms,
> I'm probably missing something. ANy help would be highly
> appreciated !

You have to use the headers in the boost compatibility library. Run bjam with
-d+2 to see the corresponding -I.../boost/boost/compatibility/cpp_c_headers
command line option.
You may also view an IRIX bjam -d+2 build log at this URL:
  http://cci.lbl.gov/boost/
Ralf
P.S.: We are (still) using our custom mipspro toolset.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From daveh at cadlink.com  Fri Jun 14 20:28:14 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 14 Jun 2002 14:28:14 -0400
Subject: [C++-sig] How to use call?
Message-ID: <aedck3$so8$1@main.gmane.org>

I am obviously missing something here but I could not get call to work. Just
trying a simple test always seems to throw the 'throw_if_not_registered
exception'. ie

    PyObject *p = python::call(co, &boost::type<PyObject*>());

where co is a callable object (constructor in this case).

I know the intention here is to copy the lvalue and prevent pointer
conversions, but if the returned value is a class we don't want to copy it
as we loose the benefit of the virtual function overrides. Maybe this will
be fixed when the object work is complete and the return type can be object.

For now what is the easiest way to allow the PyObect* through, should I just
define a specialised return_from_python converter ?

Obviously I can get round this by using PyEval_CallFunction directly.

Dave Hawkes










From david.abrahams at rcn.com  Fri Jun 14 20:46:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 14 Jun 2002 14:46:07 -0400
Subject: [C++-sig] How to use call?
References: <aedck3$so8$1@main.gmane.org>
Message-ID: <097b01c213d4$232b7400$6601a8c0@boostconsulting.com>

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


> I am obviously missing something here but I could not get call to work.
Just
> trying a simple test always seems to throw the 'throw_if_not_registered
> exception'. ie
>
>     PyObject *p = python::call(co, &boost::type<PyObject*>());
>
> where co is a callable object (constructor in this case).

You mean a type/class? If it's an __init__ function you'll need an argument
for the object.

That's a very strange way to invoke call<>. Did you look at the simple
example at

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/call.html

and the more-complete text at

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/callbacks.html

?

Looking at the source probably made you think you were supposed to pass it
the address of a temporary boost::type<> object, but that's just a VC6
workaround. Please look at the docs first and use the source as a last
resort.

> I know the intention here is to copy the lvalue

Huh? Which lvalue?

> and prevent pointer conversions, but if the returned value is a class we
don't want to copy it
> as we loose the benefit of the virtual function overrides.

You seem to think that the result object will be copied no matter what.
That's not right.
If you want to return a pointer or reference, go ahead:

MyClass* p = call<MyClass*>(callable, arg1, arg2, ...);

> Maybe this will
> be fixed when the object work is complete and the return type can be
object.

Not sure what you think that would buy you; you'd still need to get the C++
object out of it.

> For now what is the easiest way to allow the PyObect* through, should I
just
> define a specialised return_from_python converter ?
>
> Obviously I can get round this by using PyEval_CallFunction directly.

Let me know if this is still unclear to you.

-Dave






From daveh at cadlink.com  Fri Jun 14 21:39:04 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 14 Jun 2002 15:39:04 -0400
Subject: [C++-sig] Re: How to use call?
References: <aedck3$so8$1@main.gmane.org> <097b01c213d4$232b7400$6601a8c0@boostconsulting.com>
Message-ID: <aedgot$63o$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:097b01c213d4$232b7400$6601a8c0 at boostconsulting.com...
> >
> > where co is a callable object (constructor in this case).
>
> You mean a type/class? If it's an __init__ function you'll need an
argument
> for the object.

No, its the class type object itself. I suppose I shouldn't really call that
a constructor...

>
> That's a very strange way to invoke call<>. Did you look at the simple
> example at
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> python/doc/v2/call.html
>
> and the more-complete text at
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> python/doc/v2/callbacks.html
>

Yes, but due to some previous compile errors I review the docs agains the
source and wasn't sure if the comment about MSVC meant the parameter was
required or not.

> ?
>
> Looking at the source probably made you think you were supposed to pass it
> the address of a temporary boost::type<> object, but that's just a VC6
> workaround. Please look at the docs first and use the source as a last
> resort.
>
> > I know the intention here is to copy the lvalue
>
> Huh? Which lvalue?
>

The lvalue_from_python code that seems to get invoked

> > and prevent pointer conversions, but if the returned value is a class we
> don't want to copy it
> > as we loose the benefit of the virtual function overrides.
>
> You seem to think that the result object will be copied no matter what.
> That's not right.
> If you want to return a pointer or reference, go ahead:
>
> MyClass* p = call<MyClass*>(callable, arg1, arg2, ...);
>

Then I  will get the "Attempt to return dangling internal reference"
exception because I need to take possesion of the returned object.

> > Maybe this will
> > be fixed when the object work is complete and the return type can be
> object.
>
> Not sure what you think that would buy you; you'd still need to get the
C++
> object out of it.
>

see above, the returned object needs to be 'owned'.

Dave Hawkes









From david.abrahams at rcn.com  Fri Jun 14 22:06:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 14 Jun 2002 16:06:37 -0400
Subject: [C++-sig] Re: How to use call?
References: <aedck3$so8$1@main.gmane.org> <097b01c213d4$232b7400$6601a8c0@boostconsulting.com> <aedgot$63o$1@main.gmane.org>
Message-ID: <09e401c213df$33ce2d60$6601a8c0@boostconsulting.com>


> > That's a very strange way to invoke call<>. Did you look at the simple
> > example at
> >
> >
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> > python/doc/v2/call.html
> >
> > and the more-complete text at
> >
> >
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> > python/doc/v2/callbacks.html
> >
>
> Yes, but due to some previous compile errors I review the docs agains the
> source and wasn't sure if the comment about MSVC meant the parameter was
> required or not.

What comment about MSVC?

> > > I know the intention here is to copy the lvalue
> >
> > Huh? Which lvalue?
> >
>
> The lvalue_from_python code that seems to get invoked

There is no intention to copy an lvalue unless the explicit template
argument to call<> is a non-pointer, non-reference type.

> > MyClass* p = call<MyClass*>(callable, arg1, arg2, ...);
> >
>
> Then I  will get the "Attempt to return dangling internal reference"
> exception because I need to take possesion of the returned object.

Well, yeah. Who else is going to keep it alive?

> > > Maybe this will
> > > be fixed when the object work is complete and the return type can be
> > object.
> >
> > Not sure what you think that would buy you; you'd still need to get the
> C++
> > object out of it.
> >
>
> see above, the returned object needs to be 'owned'.

OK, you need what I mentioned to Dominic in a previous message: a smart
pointer type which holds a PyObject* and which "points to" its contained
lvalue. Yeah, that's not implemented, but patches are welcome.

-Dave






From daveh at cadlink.com  Sat Jun 15 04:49:52 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 14 Jun 2002 22:49:52 -0400
Subject: [C++-sig] Re: Re: How to use call?
References: <aedck3$so8$1@main.gmane.org> <097b01c213d4$232b7400$6601a8c0@boostconsulting.com> <aedgot$63o$1@main.gmane.org> <09e401c213df$33ce2d60$6601a8c0@boostconsulting.com>
Message-ID: <aeea0c$br8$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:09e401c213df$33ce2d60$6601a8c0 at boostconsulting.com...
> What comment about MSVC?
>

I'm sure I saw a comment in the source a while back, but I can't find it
now...

> > > > I know the intention here is to copy the lvalue
> > >
> > > Huh? Which lvalue?
> > >
> >
> > The lvalue_from_python code that seems to get invoked
>
> There is no intention to copy an lvalue unless the explicit template
> argument to call<> is a non-pointer, non-reference type.
>

OK


> > > MyClass* p = call<MyClass*>(callable, arg1, arg2, ...);
> > >
> >
> > Then I  will get the "Attempt to return dangling internal reference"
> > exception because I need to take possesion of the returned object.
>
> Well, yeah. Who else is going to keep it alive?
>

Yes, I know, that's my problem.

> >
> > see above, the returned object needs to be 'owned'.
>
> OK, you need what I mentioned to Dominic in a previous message: a smart
> pointer type which holds a PyObject* and which "points to" its contained
> lvalue. Yeah, that's not implemented, but patches are welcome.
>

Well here's my 'quick fix'. It is not feature complete, but if your
interested in something along these lines I can complete it:

namespace boost { namespace python {

template<class T>
struct class_handle {
    class_handle() : class_ptr(NULL) {}
    class_handle(PyObject* p) : h(p) { init(p); }
    class_handle(handle<> h) : h(h) { init(h.get()); }
    T* operator->() const { return class_ptr; }
    T* get() const { return class_ptr; }
private:
    void init(PyObject* p)
    {
        class_ptr = reinterpret_cast<T*>(objects::find_instance_impl(p,
type_id<T>()));
        if(!class_ptr) {
            PyErr_SetString(
                PyExc_ReferenceError
                , const_cast<char*>("attempt to find a class pointer from a
non class object"));
            throw_error_already_set();
        }
    }
    handle<> h;
    T* class_ptr;
};

namespace converter {

template<>
struct return_from_python<handle<> > {
    typedef handle<> result_type;
    handle<> operator()(PyObject* p) const { return handle<>(p); }
};

}

}}

After putting this in an appropriate header(?) we can do:

        class_handle<MyClass> pClass(call<handle<> >(pPyClass));
        std::string msg = pClass->func();

There's some small issues such as should the class throw an exception or
just provide a NULL pointer. Also should I use a more generic way of
converting from python, but then class_handle would valid for more than just
our own classes?

Dave Hawkes










From achim.domma at syynx.de  Sun Jun 16 20:59:43 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 16 Jun 2002 20:59:43 +0200
Subject: [C++-sig] problems compiling bpl.dll after cvs update
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEDEDHAA.achim.domma@syynx.de>

Hi Dave,

after getting the latest boost version from cvs (via 'cvs update -d'), I get
the following errors if I try to compile bpl.dll. I'm working von Win2K with
VC++ SP5. Any idea what I'm doing wrong?

greetings
Achim

...found 360 targets...
...updating 21 targets...
MkDir1 ..\..\libs\python\bin\bpl.dll
MkDir1 ..\..\libs\python\bin\bpl.dll\msvc
MkDir1 ..\..\libs\python\bin\bpl.dll\msvc\release
MkDir1 ..\..\libs\python\bin\bpl.dll\msvc\release\runtime-link-dynamic
vc-C++
..\..\libs\python\bin\bpl.dll\msvc\release\runtime-link-dynamic\aix_init_mod
ule.obj
aix_init_module.cpp
vc-C++
..\..\libs\python\bin\bpl.dll\msvc\release\runtime-link-dynamic\from_python.
obj
from_python.cpp
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2061: syntax error : identifier 'BOOST_PP_TUPLE2_EAT'
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2059: syntax error : 'constant'
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2091: function returns function
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2146: syntax error : missing ';' before identifier
'BOOST_PP_IFBOOST_PP_BOOLBOOST_PP_TUPLE16_ELEM'
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2501: 'BOOST_PP_IFBOOST_PP_BOOLBOOST_PP_TUPLE16_ELEM' : missing
storage-class or type specifiers
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2061: syntax error : identifier 'BOOST_PP_TUPLE4_EAT'
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2059: syntax error : '('
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled
E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(65) : error
C2091: function returns function
        E:\cvsroot\boost\boost/python/converter/from_python_data.hpp(68) :
see reference to class template instantiation
'boost::python::converter::detail::lower_size<target>' being compiled

...






From david.abrahams at rcn.com  Sun Jun 16 21:20:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 16 Jun 2002 15:20:41 -0400
Subject: [C++-sig] problems compiling bpl.dll after cvs update
References: <FCEMIEFBFOIDAOJDEPIAEEDEDHAA.achim.domma@syynx.de>
Message-ID: <012f01c2156a$e9d80400$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: "C++-Sig at Python. Org" <c++-sig at python.org>
Sent: Sunday, June 16, 2002 2:59 PM
Subject: [C++-sig] problems compiling bpl.dll after cvs update


> Hi Dave,
>
> after getting the latest boost version from cvs (via 'cvs update -d'), I
get
> the following errors if I try to compile bpl.dll. I'm working von Win2K
with
> VC++ SP5. Any idea what I'm doing wrong?

It's a bug/interaction between recent changes to the PREPROCESSOR library
and VC6.

From achim.domma at syynx.de  Sun Jun 16 21:38:53 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 16 Jun 2002 21:38:53 +0200
Subject: [C++-sig] problems compiling bpl.dll after cvs update
In-Reply-To: <012f01c2156a$e9d80400$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEDEDHAA.achim.domma@syynx.de>

Works fine now, thanks for the fast help!

Achim





From david.abrahams at rcn.com  Sun Jun 16 22:51:24 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 16 Jun 2002 16:51:24 -0400
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
Message-ID: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com>

I've just checked in the foundations for generalized object support
(boost/python/object.hpp). Details:

borrow() has been renamed to borrowed() as per user suggestions.
handle<> now converts automatically to/from python in argument lists and
return values
object converts automatically to/from python also

object attribute access is available through the "_" member function:

C++                    Python

x._("foo") = 1;        x.foo = 1
y = x._("foo");        y = x.foo

getitem/setitem support is implemented via operator[] in the expected ways.

x["foo"] = 1;          x['foo'] = 1
y = x[z];              y = x[z];

callable objects can be called from C++, just as from Python:

z = x(1, y)            z = x(1, y)

operators are coming, as are the python built-in functions such as
isinstance().

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 achim.domma at syynx.de  Sun Jun 16 23:30:40 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 16 Jun 2002 23:30:40 +0200
Subject: [C++-sig] NOTICE
In-Reply-To: <181d01c20cc3$c47dccd0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAKEDGDHAA.achim.domma@syynx.de>

Hi Dave,

> Boost.Python v2. If you have been using undocumented low-level conversion
> components (especially those from the boost::python::converter namespace,
> but also including boost::python::from_python), you may find that
> your code needs to be adjusted when I check these changes in.

I specialized from_python to make enums convertible and this code does not
work anymore. Could you give an short example (or point me to an existing
one) how to do that at the moment?

thanks
Achim






From daveh at cadlink.com  Sun Jun 16 23:23:34 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 16 Jun 2002 17:23:34 -0400
Subject: [C++-sig] Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com>
Message-ID: <aeivk9$deg$1@main.gmane.org>

Is CVS missing borrowed.hpp ?

Thanks
Dave Hawkes

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:017e01c21577$ad3a8420$6501a8c0 at boostconsulting.com...
> I've just checked in the foundations for generalized object support
> (boost/python/object.hpp). Details:
>
> borrow() has been renamed to borrowed() as per user suggestions.
> handle<> now converts automatically to/from python in argument lists and
> return values
> object converts automatically to/from python also
>
> object attribute access is available through the "_" member function:
>
> C++                    Python
>
> x._("foo") = 1;        x.foo = 1
> y = x._("foo");        y = x.foo
>
> getitem/setitem support is implemented via operator[] in the expected
ways.
>
> x["foo"] = 1;          x['foo'] = 1
> y = x[z];              y = x[z];
>
> callable objects can be called from C++, just as from Python:
>
> z = x(1, y)            z = x(1, y)
>
> operators are coming, as are the python built-in functions such as
> isinstance().
>
> Regards,
> Dave
>
> +---------------------------------------------------------------+
>                   David Abrahams
>       C++ Booster (http://www.boost.org)               O__  ==
>       Pythonista (http://www.python.org)              c/ /'_ ==
>   resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
>           email: david.abrahams at rcn.com
> +---------------------------------------------------------------+








From david.abrahams at rcn.com  Sun Jun 16 23:25:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 16 Jun 2002 17:25:09 -0400
Subject: [C++-sig] NOTICE
References: <FCEMIEFBFOIDAOJDEPIAKEDGDHAA.achim.domma@syynx.de>
Message-ID: <01a501c2157c$92f171a0$6501a8c0@boostconsulting.com>

Please post what you had; I'll try to come up with a translation
----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Sunday, June 16, 2002 5:30 PM
Subject: RE: [C++-sig] NOTICE


> Hi Dave,
>
> > Boost.Python v2. If you have been using undocumented low-level
conversion
> > components (especially those from the boost::python::converter
namespace,
> > but also including boost::python::from_python), you may find that
> > your code needs to be adjusted when I check these changes in.
>
> I specialized from_python to make enums convertible and this code does
not
> work anymore. Could you give an short example (or point me to an existing
> one) how to do that at the moment?
>
> thanks
> Achim
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Sun Jun 16 23:32:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 16 Jun 2002 17:32:01 -0400
Subject: [C++-sig] Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org>
Message-ID: <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com>

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


> Is CVS missing borrowed.hpp ?

Yep; good catch. Fixed.





From achim.domma at syynx.de  Sun Jun 16 23:40:38 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 16 Jun 2002 23:40:38 +0200
Subject: [C++-sig] NOTICE
In-Reply-To: <01a501c2157c$92f171a0$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAGEDHDHAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
>
> Please post what you had; I'll try to come up with a translation

something like this, where MagickLib::AlignType is an enum:

template <>
struct from_python<MagickLib::AlignType> : private boost::noncopyable 
{
	from_python(PyObject*){};
	bool convertible() const {return true;};
	MagickLib::AlignType operator()(PyObject*) const { ... };
};







From david.abrahams at rcn.com  Sun Jun 16 23:57:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 16 Jun 2002 17:57:41 -0400
Subject: [C++-sig] NOTICE
References: <FCEMIEFBFOIDAOJDEPIAGEDHDHAA.achim.domma@syynx.de>
Message-ID: <01d001c21581$82773490$6501a8c0@boostconsulting.com>

For now, just change "from_python" to "arg_from_python" and you should be
fine.
There may of course be further changes to this interface in the (near)
future...

-Dave

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Sunday, June 16, 2002 5:40 PM
Subject: RE: [C++-sig] NOTICE


> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> >
> > Please post what you had; I'll try to come up with a translation
>
> something like this, where MagickLib::AlignType is an enum:
>
> template <>
> struct from_python<MagickLib::AlignType> : private boost::noncopyable
> {
> from_python(PyObject*){};
> bool convertible() const {return true;};
> MagickLib::AlignType operator()(PyObject*) const { ... };
> };
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From daveh at cadlink.com  Mon Jun 17 05:08:11 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 16 Jun 2002 23:08:11 -0400
Subject: [C++-sig] Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com>
Message-ID: <aejjq9$4vj$1@main.gmane.org>

The object code seems to work well with the few tests I did with some spare
time this evening. The only thing we're missing now is the class support.
Maybe something fairly minimal as appended at the bottom here would suffice.
Chances are most people would just want to construct it from a regular
object anyway.


Dave Hawkes



namespace boost { namespace python {

namespace detail {
void *find_class_ptr(PyObject *p, type_info const& ti);
}

template<class T>
struct class_object : public object
{
    typedef object base;
    class_object() : m_class_ptr(NULL) {}
    class_object(object const& o) : base(o) { init(); }
    class_object& operator=(object const& o)
    {
        base::operator=(o);
        init();
        return *this;
    }
    T* operator->() const { return m_class_ptr; }
    T& operator*() const { return *m_class_ptr; }
private:
    void init()
    {
        m_class_ptr =
reinterpret_cast<T*>(detail::find_class_ptr(base::operator->(),
type_id<T>()));
    }
    T* m_class_ptr;
};

namespace detail {

// implementation in a .cpp somewhere
void *find_class_ptr(PyObject *p, type_info const& ti)
{
    void *class_ptr = NULL;
    if(p) {
        class_ptr = objects::find_instance_impl(p, ti);
        if(!class_ptr) {
            PyErr_SetString(
                PyExc_ReferenceError
                , const_cast<char*>("attempt to find a class pointer from a
non class object"));
            throw_error_already_set();
        }
    } else
        class_ptr = NULL;
    return class_ptr;
}

}

}}









From daveh at cadlink.com  Mon Jun 17 05:09:02 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Sun, 16 Jun 2002 23:09:02 -0400
Subject: [C++-sig] Threading support ?
Message-ID: <aejjrv$524$1@main.gmane.org>

A useful facility in boost would be the ability for the user to 'plug-in'
code to support the Python GIL. Using the call policies precall/postcall
facilty would possibly be one way that this could be achieved when calling
c++ code from Python, though this is not ideal as it would be difficult to
make it exception proof. Also there is not similar support when calling from
c++ to python.

What I think is needed is a way of specifying a user defined class to be
defined inline with the call, much as the converter is in the code snippet
from boost below:

template<class R>
typename converter::return_from_python<R>::result_type
call(PyObject*callable,boost::type<R>* =0)
{
    converter::return_from_python<R>converter;
    return converter(
        PyEval_CallFunction(
            callable,const_cast<char*>("(" ")")));
}


In fact, by providing a specialised converter its constructor/destructor
could manage the GIL, but this is not really very practical.

Any ideas for supporting the GIL within boost, without adding overhead where
it's not needed?

Dave Hawkes











From niki at vintech.bg  Mon Jun 17 09:13:58 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Mon, 17 Jun 2002 10:13:58 +0300
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com>
Message-ID: <3D0D8C36.8030704@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. _("...") is 
default marker for gettext. Can boost.python use something other?

regards,
Niki Spahiev





From david.abrahams at rcn.com  Mon Jun 17 11:27:45 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 05:27:45 -0400
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <3D0D8C36.8030704@vintech.bg>
Message-ID: <001701c215e2$6606a960$6601a8c0@boostconsulting.com>

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?

> _("...") is  default marker for gettext. Can boost.python use something
other?

I'm not sure. What problems could this cause?

The only alternative I can think of  looks like:


    x||"foo"

or

    x&&"foo"

Which looks uglier to my eye and might not always have the right
precedence.

-Ddave





From niki at vintech.bg  Mon Jun 17 12:07:49 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Mon, 17 Jun 2002 13:07:49 +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>
Message-ID: <3D0DB4F5.6000901@vintech.bg>

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





From david.abrahams at rcn.com  Mon Jun 17 12:17:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 06:17:58 -0400
Subject: [C++-sig] Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com> <aejjq9$4vj$1@main.gmane.org>
Message-ID: <003801c215e8$43054510$6601a8c0@boostconsulting.com>

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


> The object code seems to work well with the few tests I did with some
spare
> time this evening. The only thing we're missing now is the class support.

Ha! I wish. There's all of the operators, the rest of the Python "C" API,
direct support for the built-in types like tuple, list..., documentation,
and probably a little bit more.

> Maybe something fairly minimal as appended at the bottom here would
suffice.
> Chances are most people would just want to construct it from a regular
> object anyway.

You keep suggesting things which depend on the object being an extension
class instance, but not all classes will ultimately be wrapped that way.
I'd much rather just re-use the same generalized mechanism used to extract
a T* from a python object, which might turn out to do the same work
under-the-covers:

template <class T>
struct lvalue_ptr
{
    explicit lvalue_ptr(object)
        : m_object(object)
        , m_ptr(converter::return_from_python<T*>()(&*object))
    {}

    ...
 private:
    object m_object;
    T* m_ptr;
};

That's much cleaner, also.

I think I like your idea of deriving from object, partly because of how the
implementation of converters works (you should be able to pass these
lvalue_ptrs as arguments to wrapped functions, etc!). If we do that, we
should get rid of operator* and operator-> in object itself, and rename the
PyObject* access. Suggestions?

Also, the name for this thing should end in _ptr, since it is a classic
smart pointer. What should the first part of the name be?

-Dave







From david.abrahams at rcn.com  Mon Jun 17 12:25:35 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 06:25:35 -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: <004201c215e9$524ebb90$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Niki Spahiev" <niki at vintech.bg>
> >
> > What is that?
>
> http://www.gnu.org/software/gettext/gettext.html

AFAICT from reading that you don't need to use "_(" but can use "gettext("
instead, and AFAICT no automated tools are recognizing "_("...

> >>_("...") 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?

Why don't you use a different macro? Or better yet, enter the modern world
and use an inline function instead? ;-)


If we are really forced to switch to letters we should just use

    x.attr("foo")

We could provide parallel interfaces for people using gettext. Note also
that people can use:

    getattr(x,"foo")
    setattr(x,"bar", 2)

-Dave





From niki at vintech.bg  Mon Jun 17 12:43:32 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Mon, 17 Jun 2002 13:43:32 +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> <004201c215e9$524ebb90$6601a8c0@boostconsulting.com>
Message-ID: <3D0DBD54.7050702@vintech.bg>

>>Why not:
>>
>>x.a("foo") = 1
>>y = x.a("foo")
>>
>>or any other letter?
> 
> 
> Why don't you use a different macro? Or better yet, enter the modern world
> and use an inline function instead? ;-)

Because code with _("") is already written, but Python interface is not :)

regards,
Niki Spahiev





From david.abrahams at rcn.com  Mon Jun 17 12:55:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 06:55:34 -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> <004201c215e9$524ebb90$6601a8c0@boostconsulting.com> <3D0DBD54.7050702@vintech.bg>
Message-ID: <005201c215ed$83076e90$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Niki Spahiev" <niki at vintech.bg>

> > Why don't you use a different macro? Or better yet, enter the modern
world
> > and use an inline function instead? ;-)
>
> Because code with _("") is already written, but Python interface is not
:)

Nasty; that macro is going to stomp on Boost.Python's headers even if I
provide an alternate interface for you. In how many places is this macro
defined? Can't you write:

    #undef _
    inline void _(char const* x) { gettext(x); }

Macros, especially short ones, are up to no good.

-Dave





From david.abrahams at rcn.com  Mon Jun 17 13:06:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 07:06: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> <004201c215e9$524ebb90$6601a8c0@boostconsulting.com> <3D0DBD54.7050702@vintech.bg> <005201c215ed$83076e90$6601a8c0@boostconsulting.com>
Message-ID: <005e01c215ee$f95174a0$6601a8c0@boostconsulting.com>

From: "David Abrahams" <david.abrahams at rcn.com>
> Nasty; that macro is going to stomp on Boost.Python's headers even if I
> provide an alternate interface for you. In how many places is this macro
> defined? Can't you write:
> 
>     #undef _
>     inline void _(char const* x) { gettext(x); }

Err, sorry; that's obviously wrong. Should be something more like:

    inline char const* _(char const* x) { gettext(x); }







From david.abrahams at rcn.com  Mon Jun 17 13:23:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 07:23:53 -0400
Subject: [C++-sig] Threading support ?
References: <aejjrv$524$1@main.gmane.org>
Message-ID: <008d01c215f1$c6a8fb60$6601a8c0@boostconsulting.com>

Dave,

This is hardly the only place where the GIL would need to be acquired, is
it? Don't you need to acquire it around *every* Python "C" API function?
Besides this, I doubt that much of the code in Boost.Python is itself
threadsafe. Isn't acquiring the GIL expensive? I'm inclined to think that
the SGI approach to thread safety applies here: don't acquire locks around
individual library operations because it will be incredibly expensive;
besides that you probably won't get true safety that way. Instead, let the
user decide the granularity of locking/unlocking.

Thoughts?

-Dave


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


> A useful facility in boost would be the ability for the user to 'plug-in'
> code to support the Python GIL. Using the call policies precall/postcall
> facilty would possibly be one way that this could be achieved when
calling
> c++ code from Python, though this is not ideal as it would be difficult
to
> make it exception proof. Also there is not similar support when calling
from
> c++ to python.
>
> What I think is needed is a way of specifying a user defined class to be
> defined inline with the call, much as the converter is in the code
snippet
> from boost below:
>
> template<class R>
> typename converter::return_from_python<R>::result_type
> call(PyObject*callable,boost::type<R>* =0)
> {
>     converter::return_from_python<R>converter;
>     return converter(
>         PyEval_CallFunction(
>             callable,const_cast<char*>("(" ")")));
> }
>
>
> In fact, by providing a specialised converter its constructor/destructor
> could manage the GIL, but this is not really very practical.
>
> Any ideas for supporting the GIL within boost, without adding overhead
where
> it's not needed?
>
> Dave Hawkes
>
>
>
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From daveh at cadlink.com  Mon Jun 17 19:53:37 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 17 Jun 2002 13:53:37 -0400
Subject: [C++-sig] Re: Threading support ?
References: <aejjrv$524$1@main.gmane.org> <008d01c215f1$c6a8fb60$6601a8c0@boostconsulting.com>
Message-ID: <ael7n0$srb$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:008d01c215f1$c6a8fb60$6601a8c0 at boostconsulting.com...
> Dave,
>
> This is hardly the only place where the GIL would need to be acquired, is
> it? Don't you need to acquire it around *every* Python "C" API function?
> Besides this, I doubt that much of the code in Boost.Python is itself
> threadsafe. Isn't acquiring the GIL expensive? I'm inclined to think that
> the SGI approach to thread safety applies here: don't acquire locks around
> individual library operations because it will be incredibly expensive;
> besides that you probably won't get true safety that way. Instead, let the
> user decide the granularity of locking/unlocking.
>
> Thoughts?
>

Yes, it is needed on nearly every API call, but a large number of these in
boost python are only called during the init function execution, which can
be protected in its own right. However the object class now changes that
somewhat. I don't think acquiring the Python GIL is an enormous penalty and
the convenience of integrated support may outweigh the slight performance
penalty.

What I'm thinking of here is having someway of allowing the user to use fine
locking easily without having to provide proxies for every function/class
that is exposed.

Having said all that, I stood back and looked at implementing it as a user
'layer' over boost python at various points. That way it would require no
modifications to the boost python code. If the user needs it then they just
include an additional header, so, for example, we could have a locked_call
function that just managed the lock but delegated the actual call to boost
python.

I'll think about it some more and if I do something for our own use then
I'll post the code separately.

Dave Hawkes









From koning at pobox.com  Mon Jun 17 18:47:39 2002
From: koning at pobox.com (Joe Koning)
Date: Mon, 17 Jun 2002 09:47:39 -0700 (PDT)
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
In-Reply-To: <003801c215e8$43054510$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.44.0206170938510.32204-100000@dhcp-37-2.attbi.com>

I get this error when building boost python on a tru64 v5.1 based alpha 
system using KCC v3.4d and 4.0f. I have built the v2 boost python library 
successfully in the past using the 3.4d compiler (boost python v2 will not 
compile at all with the tru64cxx tools):

    KCC  -c  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 
-DBOOST_PYTHON_SOURCE  -g +K0   -I"../../libs/python" -I"."  
-I"/usr/casc/EMSolve/OSF1/include/python2.2" 
-I"/usr/casc_scratch/koning/boost"  -o 
"../../libs/python/bin/libbpl.so/kcc/debug/object_protocol.o"  
"src/object_protocol.cpp"

"src/object_protocol.cpp", line 13: error: specific definition of inline
          template function must precede its first use
  object getattr(object const& target, object const& key)
         ^

"src/object_protocol.cpp", line 18: error: specific definition of inline
          template function must precede its first use
  void setattr(object const& target, object const& key, object const& 
value)
       ^

"src/object_protocol.cpp", line 24: error: specific definition of inline
          template function must precede its first use
  object getitem(object const& target, object const& key)
         ^

"src/object_protocol.cpp", line 29: error: specific definition of inline
          template function must precede its first use
  void setitem(object const& target, object const& key, object const& 
value)
       ^

4 errors detected in the compilation of "src/object_protocol.cpp".
KCC: Compilation failed.

Thanks,
Joe





From rwgk at yahoo.com  Mon Jun 17 20:25:14 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 17 Jun 2002 11:25:14 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: beginning of generalized object support
In-Reply-To: <004201c215e9$524ebb90$6601a8c0@boostconsulting.com>
Message-ID: <20020617182514.56932.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> If we are really forced to switch to letters we should just use
> 
>     x.attr("foo")

I'd like this best anyway because one can understand it even without looking at
the docs.
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From daveh at cadlink.com  Mon Jun 17 20:32:09 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 17 Jun 2002 14:32:09 -0400
Subject: [C++-sig] Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com> <aejjq9$4vj$1@main.gmane.org> <003801c215e8$43054510$6601a8c0@boostconsulting.com>
Message-ID: <ael9v9$2cc$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:003801c215e8$43054510$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
>
>
> > The object code seems to work well with the few tests I did with some
> spare
> > time this evening. The only thing we're missing now is the class
support.
>
> Ha! I wish. There's all of the operators, the rest of the Python "C" API,
> direct support for the built-in types like tuple, list..., documentation,
> and probably a little bit more.
>

I meant with just the object support, though operators prossibly provide
some interesting issues. I know the other outstanding tasks are not exactly
insignificant.

> > Maybe something fairly minimal as appended at the bottom here would
> suffice.
> > Chances are most people would just want to construct it from a regular
> > object anyway.
>
> You keep suggesting things which depend on the object being an extension
> class instance, but not all classes will ultimately be wrapped that way.
> I'd much rather just re-use the same generalized mechanism used to extract
> a T* from a python object, which might turn out to do the same work
> under-the-covers:
>
> template <class T>
> struct lvalue_ptr
> {
>     explicit lvalue_ptr(object)
>         : m_object(object)
>         , m_ptr(converter::return_from_python<T*>()(&*object))
>     {}
>
>     ...
>  private:
>     object m_object;
>     T* m_ptr;
> };
>
> That's much cleaner, also.

I did wonder about doing something like that, but wanted to ensure that the
object did contain a known extension class instance, before we started using
its pointer directly. I'm not sure how else a class can get wrapped and
still be safely manipulated through it pointer. If it can't then we may as
well just use a plain object anyway.

>
> I think I like your idea of deriving from object, partly because of how
the
> implementation of converters works (you should be able to pass these
> lvalue_ptrs as arguments to wrapped functions, etc!). If we do that, we
> should get rid of operator* and operator-> in object itself, and rename
the
> PyObject* access. Suggestions?
>

I did consider suggesting making object a template with object<PyObject> a
special case and also the default type (like handle). But reconsidered as
the possibly minority (class instance) case would complicate object and
result in an unnecessary data member for the default case. In any case I
think that operator* and operator-> should be replaced by a simple access
function, as I often just land up doing &*my_object to get a PyObject
pointer anyway and an access function would be much clearer.

> Also, the name for this thing should end in _ptr, since it is a classic
> smart pointer. What should the first part of the name be?
>

I'm not that keen on lvalue_ptr as it is not particularly explicit. If it
derives from object it will also contain its functionality also (operators
will be interesting!), but object_ptr could be misconstrued. I'm not much
help here, what else could (or should) this ptr contain besides an extension
class instance, maybe that will give some more hints for a name.

Dave Hawkes










From david.abrahams at rcn.com  Mon Jun 17 22:16:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 16:16:55 -0400
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
References: <Pine.LNX.4.44.0206170938510.32204-100000@dhcp-37-2.attbi.com>
Message-ID: <01c701c2163b$edae4d60$6601a8c0@boostconsulting.com>

From: "Joe Koning" <koning at pobox.com>

> I get this error when building boost python on a tru64 v5.1 based alpha
> system using KCC v3.4d and 4.0f.

That's a compiler bug, but I just checked in a workaround. HTH

> I have built the v2 boost python library
> successfully in the past using the 3.4d compiler (boost python v2 will
not
> compile at all with the tru64cxx tools):

I know Ralf Grosse-Kunstleve has been building it successfully with
tru64cxx. Ralf?





From rwgk at yahoo.com  Mon Jun 17 22:57:51 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 17 Jun 2002 13:57:51 -0700 (PDT)
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
In-Reply-To: <01c701c2163b$edae4d60$6601a8c0@boostconsulting.com>
Message-ID: <20020617205751.12577.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> From: "Joe Koning" <koning at pobox.com>
> 
> > I get this error when building boost python on a tru64 v5.1 based alpha
> > system using KCC v3.4d and 4.0f.
> 
> That's a compiler bug, but I just checked in a workaround. HTH
> 
> > I have built the v2 boost python library
> > successfully in the past using the 3.4d compiler (boost python v2 will
> not
> > compile at all with the tru64cxx tools):
> 
> I know Ralf Grosse-Kunstleve has been building it successfully with
> tru64cxx. Ralf?

The last successful build is from Sun Jun 16 08:04:21 PDT 2002.
Starting at Sun Jun 16 16:03:59 PDT 2002 the Tru64 cxx builds
are broken with error messages that appear to be similar to
the KCC errors. The next automatic build is at 4PM PDT today:

http://cci.lbl.gov/boost/

We are using the tru64_cxx65 toolset which requires the latest
cxx compiler (version 6.5).

Ralf

P.S.: All the other builds are currently broken because our machines
are messed up :-(


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Mon Jun 17 22:51:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 16:51:12 -0400
Subject: [C++-sig] Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com> <aejjq9$4vj$1@main.gmane.org> <003801c215e8$43054510$6601a8c0@boostconsulting.com> <ael9v9$2cc$1@main.gmane.org>
Message-ID: <01f801c21640$c348ee90$6601a8c0@boostconsulting.com>

From: "Dave Hawkes" <daveh at cadlink.com>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> > > The object code seems to work well with the few tests I did with some
> > spare
> > > time this evening. The only thing we're missing now is the class
> support.
> >
> > Ha! I wish. There's all of the operators, the rest of the Python "C"
API,
> > direct support for the built-in types like tuple, list...,
documentation,
> > and probably a little bit more.
> >
>
> I meant with just the object support, though operators prossibly provide
> some interesting issues. I know the other outstanding tasks are not
exactly
> insignificant.

OK.

> > You keep suggesting things which depend on the object being an
extension
> > class instance, but not all classes will ultimately be wrapped that
way.
> > I'd much rather just re-use the same generalized mechanism used to
extract
> > a T* from a python object, which might turn out to do the same work
> > under-the-covers:
> >
> > template <class T>
> > struct lvalue_ptr
> > {
> >     explicit lvalue_ptr(object)
> >         : m_object(object)
> >         , m_ptr(converter::return_from_python<T*>()(&*object))
> >     {}
> >
> >     ...
> >  private:
> >     object m_object;
> >     T* m_ptr;
> > };
> >
> > That's much cleaner, also.
>
> I did wonder about doing something like that, but wanted to ensure that
the
> object did contain a known extension class instance, before we started
using
> its pointer directly.

What's wrong with just ensuring that the object contains an lvalue of T?

> I'm not sure how else a class can get wrapped and
> still be safely manipulated through it pointer.

There are examples in libs/python/test/m1.cpp. Imagine you wanted to work
with some extension type from a non-Boost.Python module.

> If it can't then we may as well just use a plain object anyway.

It can, though. Besides being more-general, my code is so much simpler and
exploits existing facilities...

> > I think I like your idea of deriving from object, partly because of how
> the
> > implementation of converters works (you should be able to pass these
> > lvalue_ptrs as arguments to wrapped functions, etc!). If we do that, we
> > should get rid of operator* and operator-> in object itself, and rename
> the
> > PyObject* access. Suggestions?
>
> I did consider suggesting making object a template with object<PyObject>
a
> special case and also the default type (like handle). But reconsidered as
> the possibly minority (class instance) case would complicate object

Hugely.

> and
> result in an unnecessary data member for the default case.

What data member?

> In any case I
> think that operator* and operator-> should be replaced by a simple access
> function, as I often just land up doing &*my_object to get a PyObject
> pointer anyway and an access function would be much clearer.

Yes, I was trolling for name suggestions for this function. I don't like
get() because that traditionally acccesses the same thing as operator->(),
and the derived lvalue_ptr-thing will cover the get() function with its
own, which accesses something else.

> > Also, the name for this thing should end in _ptr, since it is a classic
> > smart pointer. What should the first part of the name be?
>
> I'm not that keen on lvalue_ptr as it is not particularly explicit.

Me neither.

> If it
> derives from object it will also contain its functionality also
(operators
> will be interesting!)

I'm not sure it's all that useful. Perhaps the derivation from object isn't
such a hot plan after all, and I should do the small amount of extra
implementation work implied by making it a non-derived class.

> , but object_ptr could be misconstrued. I'm not much
> help here, what else could (or should) this ptr contain besides an
extension
> class instance, maybe that will give some more hints for a name.

It will hold a Python object which can be converted to (and thus contains)
an lvalue of type T. That's why I chose "lvalue_ptr".

-Dave






From koning at pobox.com  Mon Jun 17 22:15:20 2002
From: koning at pobox.com (Joe Koning)
Date: Mon, 17 Jun 2002 13:15:20 -0700 (PDT)
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
In-Reply-To: <01c701c2163b$edae4d60$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.44.0206171255480.32347-100000@dhcp-37-2.attbi.com>

Ok compiles fine now except for this warning:

cc: Info: /usr/casc_scratch/koning/boost/boost/python/cast.hpp, line 58: 
In this statement, 
"check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi", 
which was declared with an old-style function definition, expects 0 
arguments, but 1 are supplied. (toomanyargso)
return 
upcast__tm__22_7_object11_typeobject__Q3_5boost6python6detailFPZ2ZPiPQ2_5boost15type__tm__4_Z1Z_PZ1Z(__26268_31_x, 
(check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi(__26268_31_x)), 
((struct __Q2_5boost20type__tm__9_7_object *)0));


Thanks,
Joe

On Mon, 17 Jun 2002, David Abrahams wrote:

> 
> From: "Joe Koning" <koning at pobox.com>
> 
> > I get this error when building boost python on a tru64 v5.1 based alpha
> > system using KCC v3.4d and 4.0f.
> 
> That's a compiler bug, but I just checked in a workaround. HTH
> 
> > I have built the v2 boost python library
> > successfully in the past using the 3.4d compiler (boost python v2 will
> not
> > compile at all with the tru64cxx tools):
> 
> I know Ralf Grosse-Kunstleve has been building it successfully with
> tru64cxx. Ralf?
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 





From koning at pobox.com  Mon Jun 17 22:22:17 2002
From: koning at pobox.com (Joe Koning)
Date: Mon, 17 Jun 2002 13:22:17 -0700 (PDT)
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
In-Reply-To: <20020617205751.12577.qmail@web20202.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0206171316530.32347-100000@dhcp-37-2.attbi.com>

I only have access to v6.3. The errors are undefined global symbols: 
/usr/casc_scratch/koning/boost/boost/compatibility/cpp_c_headers/cmath, 
line 11: #282
          the global scope has no "acos"
  using ::acos;

I am not using cxx just wanted to let you know.


Thanks,
Joe

On Mon, 17 Jun 2002, Ralf W. Grosse-Kunstleve wrote:

> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > 
> > From: "Joe Koning" <koning at pobox.com>
> > 
> > > I get this error when building boost python on a tru64 v5.1 based alpha
> > > system using KCC v3.4d and 4.0f.
> > 
> > That's a compiler bug, but I just checked in a workaround. HTH
> > 
> > > I have built the v2 boost python library
> > > successfully in the past using the 3.4d compiler (boost python v2 will
> > not
> > > compile at all with the tru64cxx tools):
> > 
> > I know Ralf Grosse-Kunstleve has been building it successfully with
> > tru64cxx. Ralf?
> 
> The last successful build is from Sun Jun 16 08:04:21 PDT 2002.
> Starting at Sun Jun 16 16:03:59 PDT 2002 the Tru64 cxx builds
> are broken with error messages that appear to be similar to
> the KCC errors. The next automatic build is at 4PM PDT today:
> 
> http://cci.lbl.gov/boost/
> 
> We are using the tru64_cxx65 toolset which requires the latest
> cxx compiler (version 6.5).
> 
> Ralf
> 
> P.S.: All the other builds are currently broken because our machines
> are messed up :-(
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.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  Mon Jun 17 23:59:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 17:59:46 -0400
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
References: <20020617205751.12577.qmail@web20202.mail.yahoo.com>
Message-ID: <022d01c2164a$940e95d0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> The last successful build is from Sun Jun 16 08:04:21 PDT 2002.
> Starting at Sun Jun 16 16:03:59 PDT 2002 the Tru64 cxx builds
> are broken with error messages that appear to be similar to
> the KCC errors.

No, those are different!
I think I have a fix. I think you're gonna love this hack ;-/
It involves forcing an incomplete type through a template to make it into a
dependent type so the compiler doesn't complain about it being incomplete
in phase 1 of template compilation.

Anyway, it'll be in within an hour or so.

> The next automatic build is at 4PM PDT today:
>
> http://cci.lbl.gov/boost/
>
> We are using the tru64_cxx65 toolset which requires the latest
> cxx compiler (version 6.5).
>
> Ralf
>
> P.S.: All the other builds are currently broken because our machines
> are messed up :-(

My sympathies...





From david.abrahams at rcn.com  Tue Jun 18 00:01:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 18:01:29 -0400
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
References: <Pine.LNX.4.44.0206171255480.32347-100000@dhcp-37-2.attbi.com>
Message-ID: <022e01c2164a$94304ea0$6601a8c0@boostconsulting.com>

Yeah, I'm working on a workaround for that one. Tougher than it looks...

What a waste of time; can't you people use modern compilers (but not too
modern or it will catch /my/ errors <.02 wink>)?

thanks-for-the-reports-ly y'rs,
dave


----- Original Message -----
From: "Joe Koning" <koning at pobox.com>
To: <c++-sig at python.org>
Sent: Monday, June 17, 2002 4:15 PM
Subject: Re: [C++-sig] Error in BPL v2 build using KCC on tru64


> Ok compiles fine now except for this warning:
>
> cc: Info: /usr/casc_scratch/koning/boost/boost/python/cast.hpp, line 58:
> In this statement,
> "check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi",
> which was declared with an old-style function definition, expects 0
> arguments, but 1 are supplied. (toomanyargso)
> return
>
upcast__tm__22_7_object11_typeobject__Q3_5boost6python6detailFPZ2ZPiPQ2_5bo
ost15type__tm__4_Z1Z_PZ1Z(__26268_31_x,
>
(check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi(__262
68_31_x)),
> ((struct __Q2_5boost20type__tm__9_7_object *)0));
>






From david.abrahams at rcn.com  Tue Jun 18 00:16:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 18:16:17 -0400
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
References: <Pine.LNX.4.44.0206171255480.32347-100000@dhcp-37-2.attbi.com>
Message-ID: <025e01c2164c$ae354f10$6601a8c0@boostconsulting.com>

From: "Joe Koning" <koning at pobox.com>


> Ok compiles fine now except for this warning:
>
> cc: Info: /usr/casc_scratch/koning/boost/boost/python/cast.hpp, line 58:
> In this statement,
> "check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi",
> which was declared with an old-style function definition, expects 0
> arguments, but 1 are supplied. (toomanyargso)
> return
>
upcast__tm__22_7_object11_typeobject__Q3_5boost6python6detailFPZ2ZPiPQ2_5bo
ost15type__tm__4_Z1Z_PZ1Z(__26268_31_x,
>
(check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi(__262
68_31_x)),
> ((struct __Q2_5boost20type__tm__9_7_object *)0));
>

Please try again; should be fixed now.





From daveh at cadlink.com  Tue Jun 18 01:15:10 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 17 Jun 2002 19:15:10 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com> <aejjq9$4vj$1@main.gmane.org> <003801c215e8$43054510$6601a8c0@boostconsulting.com> <ael9v9$2cc$1@main.gmane.org> <01f801c21640$c348ee90$6601a8c0@boostconsulting.com>
Message-ID: <aelqhb$c2b$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:01f801c21640$c348ee90$6601a8c0 at boostconsulting.com...
>
>
> What's wrong with just ensuring that the object contains an lvalue of T?
>
> > I'm not sure how else a class can get wrapped and
> > still be safely manipulated through it pointer.
>
> There are examples in libs/python/test/m1.cpp. Imagine you wanted to work
> with some extension type from a non-Boost.Python module.
>
> > If it can't then we may as well just use a plain object anyway.
>
> It can, though. Besides being more-general, my code is so much simpler and
> exploits existing facilities...
>

I see what you mean from the sample. I didn't consider the possibility of 2
co-operating modules, one boost, one not, though not sure how often this
would occur in practice.

> > and
> > result in an unnecessary data member for the default case.
>
> What data member?
>

The T* m_ptr which would not be required for the default object<>.

> > In any case I
> > think that operator* and operator-> should be replaced by a simple
access
> > function, as I often just land up doing &*my_object to get a PyObject
> > pointer anyway and an access function would be much clearer.
>
> Yes, I was trolling for name suggestions for this function. I don't like
> get() because that traditionally acccesses the same thing as operator->(),
> and the derived lvalue_ptr-thing will cover the get() function with its
> own, which accesses something else.
>

Maybe something like get_native(), native_ptr() or just native().
It would also be useful to be able to extract the handle<> directly somehow
(return the private handle<>  instance).

> > > Also, the name for this thing should end in _ptr, since it is a
classic
> > > smart pointer. What should the first part of the name be?
> >
> > I'm not that keen on lvalue_ptr as it is not particularly explicit.
>
> Me neither.
>

If verbosity is not important then there is class_obj_ptr.

> > If it
> > derives from object it will also contain its functionality also
> (operators
> > will be interesting!)
>
> I'm not sure it's all that useful. Perhaps the derivation from object
isn't
> such a hot plan after all, and I should do the small amount of extra
> implementation work implied by making it a non-derived class.
>

Maybe, as there isn't to much of the object functionality that's really
useful for a class instance besides attributes.

> > , but object_ptr could be misconstrued. I'm not much
> > help here, what else could (or should) this ptr contain besides an
> extension
> > class instance, maybe that will give some more hints for a name.
>
> It will hold a Python object which can be converted to (and thus contains)
> an lvalue of type T. That's why I chose "lvalue_ptr".
>

OK

Dave Hawkes









From koning at pobox.com  Tue Jun 18 00:09:43 2002
From: koning at pobox.com (Joe Koning)
Date: Mon, 17 Jun 2002 15:09:43 -0700 (PDT)
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
In-Reply-To: <025e01c2164c$ae354f10$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.44.0206171506470.315-100000@dhcp-37-2.attbi.com>

OK it compiles cleanly now. I thought KCC was a modern compiler :). Just 
out of curiosity which compiler would you recommend?

Thanks,
Joe
On Mon, 17 Jun 2002, David Abrahams wrote:

> From: "Joe Koning" <koning at pobox.com>
> 
> 
> > Ok compiles fine now except for this warning:
> >
> > cc: Info: /usr/casc_scratch/koning/boost/boost/python/cast.hpp, line 58:
> > In this statement,
> > "check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi",
> > which was declared with an old-style function definition, expects 0
> > arguments, but 1 are supplied. (toomanyargso)
> > return
> >
> upcast__tm__22_7_object11_typeobject__Q3_5boost6python6detailFPZ2ZPiPQ2_5bo
> ost15type__tm__4_Z1Z_PZ1Z(__26268_31_x,
> >
> (check__Q4_5boost6python6detail29convertible__tm__10_P7_objectSFve_Pi(__262
> 68_31_x)),
> > ((struct __Q2_5boost20type__tm__9_7_object *)0));
> >
> 
> Please try again; should be fixed now.
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 





From rwgk at yahoo.com  Tue Jun 18 01:26:10 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 17 Jun 2002 16:26:10 -0700 (PDT)
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
In-Reply-To: <Pine.LNX.4.44.0206171316530.32347-100000@dhcp-37-2.attbi.com>
Message-ID: <20020617232610.89438.qmail@web20205.mail.yahoo.com>

--- Joe Koning <koning at pobox.com> wrote:
> I only have access to v6.3. The errors are undefined global symbols: 
> /usr/casc_scratch/koning/boost/boost/compatibility/cpp_c_headers/cmath, 
> line 11: #282
>           the global scope has no "acos"
>   using ::acos;
> 
> I am not using cxx just wanted to let you know.

cxx 6.3 provides the "C" headers (such as <cstdio>) and Boost.Compatibility is
therefore not needed.
I am not testing with cxx 6.3 because it has a bug in the IO initialization
that causes a crash a run-time. cxx 6.2 has the same bug. Should you ever
consider using cxx with Boost.Python V2, make sure you have cxx 6.5 before you
start.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Tue Jun 18 01:33:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 19:33:55 -0400
Subject: [C++-sig] Error in BPL v2 build using KCC on tru64
References: <Pine.LNX.4.44.0206171506470.315-100000@dhcp-37-2.attbi.com>
Message-ID: <02c601c21657$f5822c70$6601a8c0@boostconsulting.com>

From: "Joe Koning" <koning at pobox.com>

> OK it compiles cleanly now. I thought KCC was a modern compiler :).

Only a modern KCC is a modern compiler ;-)
You're using an older version, right?

> Just out of curiosity which compiler would you recommend?

You can keep using the old KCC you're working with; my contract with
Livermore requires me to support it**, so you're safe for now. However, KCC
is going away :(, so you might consider other tools for your platform. If
you're targeting tru64, I guess that makes it tru64cxx 6.5 (one of those
annoyingly modern compilers that catches every little mistake <wink>) or
GCC 3.1.

-Dave

**I had some trouble logging into their machine yesterday, which is why
those problems slipped in.





From david.abrahams at rcn.com  Tue Jun 18 02:56:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 17 Jun 2002 20:56:42 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com> <aejjq9$4vj$1@main.gmane.org> <003801c215e8$43054510$6601a8c0@boostconsulting.com> <ael9v9$2cc$1@main.gmane.org> <01f801c21640$c348ee90$6601a8c0@boostconsulting.com> <aelqhb$c2b$1@main.gmane.org>
Message-ID: <030801c21663$3532a4c0$6601a8c0@boostconsulting.com>

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


> I see what you mean from the sample. I didn't consider the possibility of
2
> co-operating modules, one boost, one not, though not sure how often this
> would occur in practice.

Often enough. Consider popular packages like NumPy...

> > > and
> > > result in an unnecessary data member for the default case.
> >
> > What data member?
> >
>
> The T* m_ptr which would not be required for the default object<>.

Oh, I had misunderstood what you were going to point at. When you said
"like handle<>", I assumed you meant that it would be a smart pointer to a
Python object (e.g. PyTypeObject).

> > Yes, I was trolling for name suggestions for this function. I don't
like
> > get() because that traditionally acccesses the same thing as
operator->(),
> > and the derived lvalue_ptr-thing will cover the get() function with its
> > own, which accesses something else.
> >
>
> Maybe something like get_native(), native_ptr() or just native().

What about raw()? Hopefully people won't be doing this much.

> It would also be useful to be able to extract the handle<> directly
somehow
> (return the private handle<>  instance).

is that better than handle<>(borrowed(p.raw()))?
Actually, I prefer to make the raw pointer less-accessible, so:

    p.handle() -> handle<>
    p.handle().get() -> PyObject*

Which solves one naming problem, anyway.

> > > I'm not that keen on lvalue_ptr as it is not particularly explicit.
> >
> > Me neither.
> >
>
> If verbosity is not important then there is class_obj_ptr.

But accuracy is important. You could write:

    lvalue_ptr<char const> x(string("x"))

which would get you a smart pointer to the 'x' character managed by a
Python string object. I realize this one is esoteric, but consider Python
buffer objects, wrapped boost::array<double>, etc...

The point being that it doesn't have to refer to a class.

> > I'm not sure it's all that useful. Perhaps the derivation from object
> isn't
> > such a hot plan after all, and I should do the small amount of extra
> > implementation work implied by making it a non-derived class.
> >
>
> Maybe, as there isn't to much of the object functionality that's really
> useful for a class instance besides attributes.

I was thinking that if you have direct access to the C++ lvalue being
referred to, do you really want a fancy interface to the Python wrapper? I
mean:

    lvalue_ptr<base> b(some_object);
    object elt = b[1];
    b->cplus_plus_method();
    b->member = 2;
    b.attr("member") = 2; // synonym

Is that too wierd? I kinda like it, I hate to admit.

> > > , but object_ptr could be misconstrued. I'm not much
> > > help here, what else could (or should) this ptr contain besides an
> > extension
> > > class instance, maybe that will give some more hints for a name.
> >
> > It will hold a Python object which can be converted to (and thus
contains)
> > an lvalue of type T. That's why I chose "lvalue_ptr".
> >
>
> OK

Does that mean you actually buy lvalue_ptr? I wish we could find something
less tweaky...
Maybe object_ptr<T> is best.

-Dave






From daveh at cadlink.com  Tue Jun 18 04:12:58 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Mon, 17 Jun 2002 22:12:58 -0400
Subject: [C++-sig] Re: Re: Re: Boost.Python v2: beginning of generalized object support
References: <017e01c21577$ad3a8420$6501a8c0@boostconsulting.com> <aeivk9$deg$1@main.gmane.org> <01b201c2157d$416e2cf0$6501a8c0@boostconsulting.com> <aejjq9$4vj$1@main.gmane.org> <003801c215e8$43054510$6601a8c0@boostconsulting.com> <ael9v9$2cc$1@main.gmane.org> <01f801c21640$c348ee90$6601a8c0@boostconsulting.com> <aelqhb$c2b$1@main.gmane.org> <030801c21663$3532a4c0$6601a8c0@boostconsulting.com>
Message-ID: <aem4uk$r9o$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:030801c21663$3532a4c0$6601a8c0 at boostconsulting.com...
> > (return the private handle<>  instance).
>
> is that better than handle<>(borrowed(p.raw()))?
> Actually, I prefer to make the raw pointer less-accessible, so:
>
>     p.handle() -> handle<>
>     p.handle().get() -> PyObject*
>
> Which solves one naming problem, anyway.
>

I prefer that too, get the managed handle and if the pointer is really
needed, then go from there.

> > > > I'm not that keen on lvalue_ptr as it is not particularly explicit.
> > >
> > > Me neither.
> > >
> >
> > If verbosity is not important then there is class_obj_ptr.
>
> But accuracy is important. You could write:
>
>     lvalue_ptr<char const> x(string("x"))
>
> which would get you a smart pointer to the 'x' character managed by a
> Python string object. I realize this one is esoteric, but consider Python
> buffer objects, wrapped boost::array<double>, etc...
>
> The point being that it doesn't have to refer to a class.
>

So in effect it's managing any object that contains a representation that
can be pointed at and can be directly manipulated. In that case almost every
python object could be represented somehow with some form of specialization.
So a lvalue_ptr<PyIntObject> could contain a pointer to its integral long.
Did I see some earlier thread about accessing int, etc directly? Maybe this
is going a bit too far...

>
> I was thinking that if you have direct access to the C++ lvalue being
> referred to, do you really want a fancy interface to the Python wrapper? I
> mean:
>
>     lvalue_ptr<base> b(some_object);
>     object elt = b[1];
>     b->cplus_plus_method();
>     b->member = 2;
>     b.attr("member") = 2; // synonym
>
> Is that too wierd? I kinda like it, I hate to admit.
>

I was also thinking of adding attributes that are not members in the first
place, but then, of course, they would not be accessible as c++ members
afterwards either.

> > > > , but object_ptr could be misconstrued. I'm not much
> > > > help here, what else could (or should) this ptr contain besides an
> > > extension
> > > > class instance, maybe that will give some more hints for a name.
> > >
> > > It will hold a Python object which can be converted to (and thus
> contains)
> > > an lvalue of type T. That's why I chose "lvalue_ptr".
> > >
> >
> > OK
>
> Does that mean you actually buy lvalue_ptr? I wish we could find something
> less tweaky...
> Maybe object_ptr<T> is best.
>

If it can generalised to encompass many builtin python types then that could
well be more appropriate.
I'm running out of further ideas here.

Dave Hawkes









From bugcreator at gmx.de  Tue Jun 18 11:29:52 2002
From: bugcreator at gmx.de (Dominic =?iso-8859-15?q?Sacr=E9?=)
Date: Tue, 18 Jun 2002 11:29:52 +0200
Subject: [C++-sig] Memory leaks in make_function.hpp?
Message-ID: <200206181121.23288.bugcreator@gmx.de>

Hi,

I tried to detect memory leaks in my own code by overriding operators new 
and delete, and keeping track of all allocations.
It turned out there are also some leaks in Boost.Python. If I'm not 
mistaken, the objects allocated by make_function() and make_constructor() 
(called indirectly by class_<>.def() and class_<>.def_init()) are never 
deleted. I guess that's not a big problem, as these objects will usually 
only be destroyed when the program exits anyway, but would it be possible 
to fix this?

    Dominic






From david.abrahams at rcn.com  Tue Jun 18 12:52:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 18 Jun 2002 06:52:38 -0400
Subject: [C++-sig] Memory leaks in make_function.hpp?
References: <200206181121.23288.bugcreator@gmx.de>
Message-ID: <040301c216b6$83dbbc30$6601a8c0@boostconsulting.com>

Not easily. The problem is that the class needs to be registered with the
class_registry in the BPL library. Since the class owns a reference to its
methods, that keeps the whole package alive indefinitely. I could use some
kind of weak reference to manage this, but that would only seem to make
things much more complicated.

    Dave

----- Original Message -----
From: "Dominic Sacr?" <bugcreator at gmx.de>
To: <c++-sig at python.org>
Sent: Tuesday, June 18, 2002 5:29 AM
Subject: [C++-sig] Memory leaks in make_function.hpp?


Hi,

I tried to detect memory leaks in my own code by overriding operators new
and delete, and keeping track of all allocations.
It turned out there are also some leaks in Boost.Python. If I'm not
mistaken, the objects allocated by make_function() and make_constructor()
(called indirectly by class_<>.def() and class_<>.def_init()) are never
deleted. I guess that's not a big problem, as these objects will usually
only be destroyed when the program exits anyway, but would it be possible
to fix this?

    Dominic




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





From david.abrahams at rcn.com  Tue Jun 18 15:52:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 18 Jun 2002 09:52:17 -0400
Subject: [C++-sig] Boost.Python v2: object operators
Message-ID: <050001c216cf$5dbbb820$6601a8c0@boostconsulting.com>

I just checked in full operator support for objects, including inplace
operators and inplace operator combinations such as

    x.attr("y") += z;

and

    x[y] >>= 1;

Additionally:

    ._("...") has been changed to .attr("...")
    Problems with tru64cxx6.5 should be fixed now

I'm thinking about some source file reorganization: all of the new stuff
(now in boost::python::api) should go in its own subdirectory
boost/python/api.

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 bugcreator at gmx.de  Tue Jun 18 18:04:49 2002
From: bugcreator at gmx.de (Dominic =?windows-1252?q?Sacr=E9?=)
Date: Tue, 18 Jun 2002 18:04:49 +0200
Subject: [C++-sig] Memory leaks in make_function.hpp?
In-Reply-To: <040301c216b6$83dbbc30$6601a8c0@boostconsulting.com>
References: <200206181121.23288.bugcreator@gmx.de> <040301c216b6$83dbbc30$6601a8c0@boostconsulting.com>
Message-ID: <200206181759.34395.bugcreator@gmx.de>

On Tuesday 18 June 2002 12:52, David Abrahams wrote:
> Not easily. The problem is that the class needs to be registered with
> the class_registry in the BPL library. Since the class owns a reference
> to its methods, that keeps the whole package alive indefinitely. I
> could use some kind of weak reference to manage this, but that would
> only seem to make things much more complicated.

Hm, okay. I have no idea how complicated it would be to solve this 
problem, so if you think it's not worth the effort to fix it, that's fine 
with me. I'll simply modify my leak detector to ignore leaks from the 
BPL. After all I want to find my own leaks, not yours ;)

Cheers,
    Dominic




From david.abrahams at rcn.com  Tue Jun 18 23:21:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 18 Jun 2002 17:21:50 -0400
Subject: [C++-sig] container construction
Message-ID: <06a801c2170e$502072c0$6601a8c0@boostconsulting.com>

So I'm thinking about how we're going to build lists, tuples, and
dictionaries from C++.

Clearly, there should be a constructor that takes a single object argument
and checks to make sure it's an object of the corresponding Python type,
raising an exception otherwise.

Now, what about creating lists/tuples of more than one argument?
It would be lovely to be able to write:

    list(3, 5, 7) // i.e. [3, 5, 7]

but python doesn't work that way, and furthermore in that case it wouldn't
make much sense to have:

    list(3) // error, 3 is not a list

Furthermore, it should be possible to write:

    list(some_tuple)

as you can in Python. So, I guess we need

    make_list(3, 5, 7) -> [3, 5, 7]

and

    make_tuple('x', 2) -> ('x', 2)

Other interfaces are possible, though:

    tuple(items = 'x', 2)
    list(items = 3, 5, 7)

I'm open to suggestion here.

What about dictionaries? Since:

    >>> dict(((1,'one'), (2,'two')))
    {1: 'one', 2: 'two'}

I guess we could write:

    dict(make_tuple(make_tuple(1,"one"), make_tuple(2,"two")))

but man, that's ugly!

Other possibilities:

    dict(1, "one").add(2, "two")   // chaining
    dict(1, "one"), dict(2, "two") // overloaded comma operator
    dict(1, 'one', 2, 'two')       // even arities only

I'm somewhat inclined toward the last one.

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 rwgk at yahoo.com  Wed Jun 19 00:37:16 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 18 Jun 2002 15:37:16 -0700 (PDT)
Subject: [C++-sig] container construction
In-Reply-To: <06a801c2170e$502072c0$6601a8c0@boostconsulting.com>
Message-ID: <20020618223716.17479.qmail@web20206.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> as you can in Python. So, I guess we need
> 
>     make_list(3, 5, 7) -> [3, 5, 7]
> 
> and
> 
>     make_tuple('x', 2) -> ('x', 2)
> 
> Other interfaces are possible, though:
> 
>     tuple(items = 'x', 2)
>     list(items = 3, 5, 7)

make_list, make_tuple looks best to my twisted mind.

>     dict(1, "one").add(2, "two")   // chaining
>     dict(1, "one"), dict(2, "two") // overloaded comma operator
>     dict(1, 'one', 2, 'two')       // even arities only

I'd go with .add(). dict(1, 'one', 2, 'two') is clear, but you might also have
dict(3, 16, 7, 13, 13, 14, 19, 12, 15, 1). dict(3, 16).add(7, 13).add(13,
14).add(19, 12).add(15, 1) is a bit more to type but the expression is more
obvious.

Ralf



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Wed Jun 19 01:03:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 18 Jun 2002 19:03:57 -0400
Subject: [C++-sig] The fix is in
Message-ID: <072a01c2171c$6dc0a4e0$6601a8c0@boostconsulting.com>

Paul Mensonides has committed the Preprocessor Library workarounds needed
to make the current CVS state work with VC6. You can "cvs update -A" in
boost/preprocessor to bring your installation up-to-date if you've been
using a rolled-back PP lib.

Thanks, Paul!

-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 Jun 19 22:15:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 19 Jun 2002 16:15:14 -0400
Subject: [C++-sig] Boost.Python v2: object facilities updated
Message-ID: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com>

After a little testing I discovered that the object class didn't allow
certain kinds of expressions, e.g.

object f(object list_of_lists)
{
    list_of_lists[0][1] = 5;
}

Basically the proxy being returned by item (operator[]) and attribute
(attr()) access functions was not defined to support all of the same
operations as the object class itself. Getting this to work was "fun" ;-),
especially since it uncovered code generation bugs in MSVC6 and GCC 2.95.x.

Next up: slicing, then list, tuple, dict, type, etc...

Two jobs I could use help with:

1. Examine places in the public interface to the rest of the project for
uses of PyObject* or handle<T> which should really be using object. Make a
proposal for appropriate interface changes.

2. Move code generated by the use of object and its proxies into the shared
library. I expect that the natural use of object instances generates a fair
amount of code in the user's extension module which could be shared,
reducing both compilation times and the size of extension modules. This job
is more ambitious and requires some understanding of the differences in
template instantiation and shared libs among different platforms/compilers.

Thanks,
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 Jun 19 23:16:18 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 19 Jun 2002 23:16:18 +0200
Subject: [C++-sig] conversion of std::list<...> parameters in function call
Message-ID: <FCEMIEFBFOIDAOJDEPIAOEHLDHAA.achim.domma@syynx.de>

Hi Dave,

once again a conversion question:

I want to call a ctor which expects a 'const std::list<Magick::VPath>&'. In
python I build a list like this:

path =
[PathMovetoAbs(Coordinate(50,50)),PathLinetoVerticalRel(-40),PathClosePath()
]

All three PathXXX classes are derived from VPathBase and their boost.python
wrappers are defined with bases<VPathBase>. VPathBase is declared as
implicit convertible to VPath.

Is it already possible to do such a conversion at the moment? Should I write
my own converter or is there a better way?

Achim






From daveh at cadlink.com  Wed Jun 19 23:29:05 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 19 Jun 2002 17:29:05 -0400
Subject: [C++-sig] Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com>
Message-ID: <aer38g$kqm$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0acc01c217ce$0702c8c0$6601a8c0 at boostconsulting.com...
> After a little testing I discovered that the object class didn't allow
> certain kinds of expressions, e.g.
>
> object f(object list_of_lists)
> {
>     list_of_lists[0][1] = 5;
> }
>
> Basically the proxy being returned by item (operator[]) and attribute
> (attr()) access functions was not defined to support all of the same
> operations as the object class itself. Getting this to work was "fun" ;-),

I can see that..

> especially since it uncovered code generation bugs in MSVC6 and GCC
2.95.x.
>

There's a surprise -;)

> Next up: slicing, then list, tuple, dict, type, etc...
>
> Two jobs I could use help with:
>
> 1. Examine places in the public interface to the rest of the project for
> uses of PyObject* or handle<T> which should really be using object. Make a
> proposal for appropriate interface changes.
>

I'll tidy up the code for global module/sub-module/nested classes support to
use this where appropriate

> 2. Move code generated by the use of object and its proxies into the
shared
> library. I expect that the natural use of object instances generates a
fair
> amount of code in the user's extension module which could be shared,
> reducing both compilation times and the size of extension modules. This
job
> is more ambitious and requires some understanding of the differences in
> template instantiation and shared libs among different
platforms/compilers.
>

I noticed object.ptr().get() is really needed quite a bit and you created a
wrapper for it.
Maybe there should be an object member function called ptr_get()?

Dave Hawkes









From david.abrahams at rcn.com  Thu Jun 20 01:33:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 19 Jun 2002 19:33:22 -0400
Subject: [C++-sig] Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com> <aer38g$kqm$1@main.gmane.org>
Message-ID: <0b8601c217e9$c4ee0ff0$6601a8c0@boostconsulting.com>

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

> > Next up: slicing, then list, tuple, dict, type, etc...
> >
> > Two jobs I could use help with:
> >
> > 1. Examine places in the public interface to the rest of the project
for
> > uses of PyObject* or handle<T> which should really be using object.
Make a
> > proposal for appropriate interface changes.
> >
>
> I'll tidy up the code for global module/sub-module/nested classes support
to
> use this where appropriate

Thanks. I'm really looking forward to integrating this stuff -- when I find
a few minutes ;-/.

> I noticed object.ptr().get() is really needed quite a bit and you created
a
> wrapper for it.

I assume you're seeing converter::get_managed_object() - that's not really
a wrapper for ptr().get(); it just happens to do that when passed an
object. Seriously; it has a different purpose.

> Maybe there should be an object member function called ptr_get()?

Didn't we just discuss this, with the conclusion that we shouldn't provide
direct access to the PyObject*?
Or are you just talking about implementation details?

-Dave





From daveh at cadlink.com  Thu Jun 20 02:31:36 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 19 Jun 2002 20:31:36 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com> <aer38g$kqm$1@main.gmane.org> <0b8601c217e9$c4ee0ff0$6601a8c0@boostconsulting.com>
Message-ID: <aer7o9$sc4$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0b8601c217e9$c4ee0ff0$6601a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > > Next up: slicing, then list, tuple, dict, type, etc...
> > >
> > > Two jobs I could use help with:
> > >
> > > 1. Examine places in the public interface to the rest of the project
> for
> > > uses of PyObject* or handle<T> which should really be using object.
> Make a
> > > proposal for appropriate interface changes.
> > >
> >
> > I'll tidy up the code for global module/sub-module/nested classes
support
> to
> > use this where appropriate
>
> Thanks. I'm really looking forward to integrating this stuff -- when I
find
> a few minutes ;-/.
>

OK

> > I noticed object.ptr().get() is really needed quite a bit and you
created
> a
> > wrapper for it.
>
> I assume you're seeing converter::get_managed_object() - that's not really
> a wrapper for ptr().get(); it just happens to do that when passed an
> object. Seriously; it has a different purpose.
>

I guessed it was intended to be something symantically different from the
converter context, but the end result was the same for object.

> > Maybe there should be an object member function called ptr_get()?
>
> Didn't we just discuss this, with the conclusion that we shouldn't provide
> direct access to the PyObject*?
> Or are you just talking about implementation details?
>

Yes, we did, but using the new code revealed that it was needed more than I
anticipated, but that will probably change when the API wrappers are
complete. If that's not far away then it's probably not worth worrying
about.

Dave Hawkes










From david.abrahams at rcn.com  Thu Jun 20 02:55:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 19 Jun 2002 20:55:05 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com> <aer38g$kqm$1@main.gmane.org> <0b8601c217e9$c4ee0ff0$6601a8c0@boostconsulting.com> <aer7o9$sc4$1@main.gmane.org>
Message-ID: <0c2701c217f5$a62e3e30$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Wednesday, June 19, 2002 8:31 PM
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0b8601c217e9$c4ee0ff0$6601a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > > > Next up: slicing, then list, tuple, dict, type, etc...
> > > >
> > > > Two jobs I could use help with:
> > > >
> > > > 1. Examine places in the public interface to the rest of the
project
> > for
> > > > uses of PyObject* or handle<T> which should really be using object.
> > Make a
> > > > proposal for appropriate interface changes.
> > > >
> > >
> > > I'll tidy up the code for global module/sub-module/nested classes
> support
> > to
> > > use this where appropriate
> >
> > Thanks. I'm really looking forward to integrating this stuff -- when I
> find
> > a few minutes ;-/.
> >
>
> OK
>
> > > I noticed object.ptr().get() is really needed quite a bit and you
> created
> > a
> > > wrapper for it.
> >
> > I assume you're seeing converter::get_managed_object() - that's not
really
> > a wrapper for ptr().get(); it just happens to do that when passed an
> > object. Seriously; it has a different purpose.
> >
>
> I guessed it was intended to be something symantically different from the
> converter context, but the end result was the same for object.
>
> > > Maybe there should be an object member function called ptr_get()?
> >
> > Didn't we just discuss this, with the conclusion that we shouldn't
provide
> > direct access to the PyObject*?
> > Or are you just talking about implementation details?
> >
>
> Yes, we did, but using the new code revealed that it was needed more than
I
> anticipated, but that will probably change when the API wrappers are
> complete. If that's not far away then it's probably not worth worrying
> about.

In theory it's not, but I could really use some help with that stuff. Do
you think you might take on the job of fleshing out the missing pieces?
It's fairly mechanical, mostly, but requires some attention. My idea was to
follow the Python/C API documentation and make files like
object_protocol.hpp which mirror pages like
http://www.python.org/dev/doc/devel/api/object.html. Of course, many
functions are covered by the operators already defined, so we don't need
separate functions for those. The idea is just to cover the built-in
functions (http://www.python.org/dev/doc/devel/lib/built-in-funcs.html) and
any 'C' API functions which aren't otherwise handled.

-Dave






From daveh at cadlink.com  Thu Jun 20 04:30:34 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 19 Jun 2002 22:30:34 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com> <aer38g$kqm$1@main.gmane.org> <0b8601c217e9$c4ee0ff0$6601a8c0@boostconsulting.com> <aer7o9$sc4$1@main.gmane.org> <0c2701c217f5$a62e3e30$6601a8c0@boostconsulting.com>
Message-ID: <aerenb$71r$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0c2701c217f5$a62e3e30$6601a8c0 at boostconsulting.com...
I
> > anticipated, but that will probably change when the API wrappers are
> > complete. If that's not far away then it's probably not worth worrying
> > about.
>
> In theory it's not, but I could really use some help with that stuff. Do
> you think you might take on the job of fleshing out the missing pieces?
> It's fairly mechanical, mostly, but requires some attention. My idea was
to
> follow the Python/C API documentation and make files like
> object_protocol.hpp which mirror pages like
> http://www.python.org/dev/doc/devel/api/object.html. Of course, many
> functions are covered by the operators already defined, so we don't need
> separate functions for those. The idea is just to cover the built-in
> functions (http://www.python.org/dev/doc/devel/lib/built-in-funcs.html)
and
> any 'C' API functions which aren't otherwise handled.
>

I have a number of ideas for an aproach to this, but I want to try a couple
of things before I post here. Once I'm clear what's involved I can let you
know if I can do this, plus some timescales.

An issue I keep having with 'object' is the lack of a default constructor. I
think this may have been discussed before, but I can't remember the outcome.
What is the reason for not creating a Py_None object with the default
constructor? With all its extra functionality now it can be used for much
more than just capturing return values. It is occasionally useful to declare
an object and defer its actual assignment.

Dave Hawkes









From david.abrahams at rcn.com  Thu Jun 20 04:43:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 19 Jun 2002 22:43:26 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com> <aer38g$kqm$1@main.gmane.org> <0b8601c217e9$c4ee0ff0$6601a8c0@boostconsulting.com> <aer7o9$sc4$1@main.gmane.org> <0c2701c217f5$a62e3e30$6601a8c0@boostconsulting.com> <aerenb$71r$1@main.gmane.org>
Message-ID: <0cc701c21804$c6d7c340$6601a8c0@boostconsulting.com>

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

> > In theory it's not, but I could really use some help with that stuff.
Do
> > you think you might take on the job of fleshing out the missing pieces?
> > It's fairly mechanical, mostly, but requires some attention. My idea
was
> to
> > follow the Python/C API documentation and make files like
> > object_protocol.hpp which mirror pages like
> > http://www.python.org/dev/doc/devel/api/object.html. Of course, many
> > functions are covered by the operators already defined, so we don't
need
> > separate functions for those. The idea is just to cover the built-in
> > functions (http://www.python.org/dev/doc/devel/lib/built-in-funcs.html)
> and
> > any 'C' API functions which aren't otherwise handled.
> >
>
> I have a number of ideas for an aproach to this,

Not to thwart creativity, but I hope you're not thinking of anything too
fancy. It does seem like a fairly mechanical job to me...

> but I want to try a couple
> of things before I post here. Once I'm clear what's involved I can let
you
> know if I can do this, plus some timescales.

Thanks, I really appreciate your contributions.

> An issue I keep having with 'object' is the lack of a default
constructor. I
> think this may have been discussed before, but I can't remember the
outcome.

You can always search
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/c++-sig...

> What is the reason for not creating a Py_None object with the default
> constructor?

No direct analogue in Python. But that's not neccessarily a good reason.
Wouldn't it be better to have a None object, though?

    object x = None;

> With all its extra functionality now it can be used for much
> more than just capturing return values. It is occasionally useful to
declare
> an object and defer its actual assignment.

Sure. I'll add the default constructor if there's a good reason to, but I
don't see one yet.





From daveh at cadlink.com  Thu Jun 20 05:55:40 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 19 Jun 2002 23:55:40 -0400
Subject: [C++-sig] Re: Re: Re: Boost.Python v2: object facilities updated
References: <0acc01c217ce$0702c8c0$6601a8c0@boostconsulting.com> <aer38g$kqm$1@main.gmane.org> <0b8601c217e9$c4ee0ff0$6601a8c0@boostconsulting.com> <aer7o9$sc4$1@main.gmane.org> <0c2701c217f5$a62e3e30$6601a8c0@boostconsulting.com> <aerenb$71r$1@main.gmane.org> <0cc701c21804$c6d7c340$6601a8c0@boostconsulting.com>
Message-ID: <aerjmt$e04$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0cc701c21804$c6d7c340$6601a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > > In theory it's not, but I could really use some help with that stuff.
> Do
> > > you think you might take on the job of fleshing out the missing
pieces?
> > > It's fairly mechanical, mostly, but requires some attention. My idea
> was
> > to
> > > follow the Python/C API documentation and make files like
> > > object_protocol.hpp which mirror pages like
> > > http://www.python.org/dev/doc/devel/api/object.html. Of course, many
> > > functions are covered by the operators already defined, so we don't
> need
> > > separate functions for those. The idea is just to cover the built-in
> > > functions
(http://www.python.org/dev/doc/devel/lib/built-in-funcs.html)
> > and
> > > any 'C' API functions which aren't otherwise handled.
> > >
> >
> > I have a number of ideas for an aproach to this,
>
> Not to thwart creativity, but I hope you're not thinking of anything too
> fancy. It does seem like a fairly mechanical job to me...
>

No, nothing very elaborate, more ideas for consistancy, especially as I
don't have access to a large number of platforms.

> > but I want to try a couple
> > of things before I post here. Once I'm clear what's involved I can let
> you
> > know if I can do this, plus some timescales.
>
> Thanks, I really appreciate your contributions.
>
> > An issue I keep having with 'object' is the lack of a default
> constructor. I
> > think this may have been discussed before, but I can't remember the
> outcome.
>
> You can always search
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/c++-sig...
>
> > What is the reason for not creating a Py_None object with the default
> > constructor?
>
> No direct analogue in Python. But that's not neccessarily a good reason.
> Wouldn't it be better to have a None object, though?
>
>     object x = None;
>
> > With all its extra functionality now it can be used for much
> > more than just capturing return values. It is occasionally useful to
> declare
> > an object and defer its actual assignment.
>
> Sure. I'll add the default constructor if there's a good reason to, but I
> don't see one yet.

There's no direct analogue in Python because there's no variable
declarations. I was just thinking that a C++ variable declaration:

object x;

is equivalent to Python

x = None

A bit of a stretch I know, but there has to be some accomadation for the
fundamental language differences.

My reasononing for requiring the default constructor is that should a user
have a number of object classes as member variables of another class, then
these must all be initialised in the constructor initialiser list which is a
little tedious. It could be that the user cannot fully assign relavent
values until later or that their compiler does not support catching
exceptions in the initialiser list.

ie we have to do:

class MyClass {
    MyClass() : x1(handle<>(borrowed(Py_none))),
x2(handle<>(borrowed(Py_none))), x3(handle<>(borrowed(Py_none)))
    {
        try {
            x1 = 4;
            x2 = get_some_value();
            x3 = x1 + x2;
        } catch(...) {
            ...
        }
    }
    object x1, x2, x3;
};

Dave Hawkes









From djowel at gmx.co.uk  Wed Jun 19 21:26:13 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Wed, 19 Jun 2002 12:26:13 -0700
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated
References: <0cc701c21804$c6d7c340$6601a8c0@boostconsulting.com>
Message-ID: <3D10DAD5.6090305@gmx.co.uk>

David Abrahams wrote:

>>What is the reason for not creating a Py_None object with the default
>>constructor?
>>
>
>No direct analogue in Python. But that's not neccessarily a good reason.
>Wouldn't it be better to have a None object, though?
>
>    object x = None;
>
>>With all its extra functionality now it can be used for much
>>more than just capturing return values. It is occasionally useful to
>>
>declare
>
>>an object and defer its actual assignment.
>>
>
>Sure. I'll add the default constructor if there's a good reason to, but I
>don't see one yet.
>
Is there a reason why not? I mean, will there be problems if a default 
constructor
that creates a None object was introduced? Aesthetically, I kinda agree with
Dave Hawkes. Right off the bat, it might be useful when, say, stuffing 
preallocated
vector<object>, for instance. But I am not sure if that would be useful 
nor practical.

2c worth ;-) Pardon me if this does not make sense.

--Joel











From david.abrahams at rcn.com  Thu Jun 20 13:19:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 07:19:32 -0400
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated
References: <0cc701c21804$c6d7c340$6601a8c0@boostconsulting.com> <3D10DAD5.6090305@gmx.co.uk>
Message-ID: <0d8701c2184c$c21e6c30$6601a8c0@boostconsulting.com>

From: "Joel de Guzman" <djowel at gmx.co.uk>
Right off the bat, it might be useful when, say, stuffing 

> preallocated
> vector<object>, for instance. 


or boost::tuple<object, object, object>.


> But I am not sure if that would be useful 
> nor practical.
> 
> 2c worth ;-) Pardon me if this does not make sense.
> 

Sounds good; I'm convinced.

-Dave





From david.abrahams at rcn.com  Thu Jun 20 14:34:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 08:34:04 -0400
Subject: [C++-sig] conversion of std::list<...> parameters in function call
References: <FCEMIEFBFOIDAOJDEPIAOEHLDHAA.achim.domma@syynx.de>
Message-ID: <0e8701c21857$11e7f1f0$6601a8c0@boostconsulting.com>

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

> once again a conversion question:
>
> I want to call a ctor which expects a 'const std::list<Magick::VPath>&'.
In
> python I build a list like this:
>
> path =
>
[PathMovetoAbs(Coordinate(50,50)),PathLinetoVerticalRel(-40),PathClosePath(
)
> ]
>
> All three PathXXX classes are derived from VPathBase and their
boost.python
> wrappers are defined with bases<VPathBase>. VPathBase is declared as
> implicit convertible to VPath.
>
> Is it already possible to do such a conversion at the moment? Should I
write
> my own converter or is there a better way?

I think Ralf has done something like this. Ralf?





From rwgk at yahoo.com  Thu Jun 20 15:09:50 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 06:09:50 -0700 (PDT)
Subject: [C++-sig] conversion of std::list<...> parameters in function call
In-Reply-To: <0e8701c21857$11e7f1f0$6601a8c0@boostconsulting.com>
Message-ID: <20020620130950.41290.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Achim Domma" <achim.domma at syynx.de>
> 
> > once again a conversion question:
> >
> > I want to call a ctor which expects a 'const std::list<Magick::VPath>&'.
> In
> > python I build a list like this:
> >
> > path =
> >
> [PathMovetoAbs(Coordinate(50,50)),PathLinetoVerticalRel(-40),PathClosePath(
> )
> > ]
> >
> > All three PathXXX classes are derived from VPathBase and their
> boost.python
> > wrappers are defined with bases<VPathBase>. VPathBase is declared as
> > implicit convertible to VPath.
> >
> > Is it already possible to do such a conversion at the moment? Should I
> write
> > my own converter or is there a better way?
> 
> I think Ralf has done something like this. Ralf?

The code that David is eluding to is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bpl_utils.h?rev=1.2.2.11&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

The interesting bit is struct register_container_from_python_list_or_tuple.

See also:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/bpl_utils.cpp?rev=1.1.2.6&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

This code has a flaw (marked with XXX) and will not compile with the latest
CVS. Replacing "ref" by "handle<>" and "make_ref" by "object" is the minimum
that has to be done, but more adjustment might be necessary. A week ago it
worked with std::vector and boost::array. I have not tested it with std::list.
Another adaptor might be required (see struct
variable_size_container_registration_adaptor).

Sorry for all the vagueness. I would not normally have advertised the code, but
who am I to resist David's challenges?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Thu Jun 20 15:09:48 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 09:09:48 -0400
Subject: [C++-sig] GNU gettext and "_"
Message-ID: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com>

I'm working on slicing now and I find myself in need of a way to represent
x[:y]. This is technically not equivalent to x[0:y] since you can slice on
any type. "Obviously", the answer is to use

    x.slice(_,y)

but I suppose that's going to collide with gettext again.

I suppose we could check "#if defined(_)" and supply some other symbol for
those people who need gettext compatibility. Suggestions?

-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  Thu Jun 20 15:12:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 09:12:42 -0400
Subject: [C++-sig] conversion of std::list<...> parameters in function call
References: <20020620130950.41290.qmail@web20202.mail.yahoo.com>
Message-ID: <0ee601c2185c$9695c210$6601a8c0@boostconsulting.com>

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

> This code has a flaw (marked with XXX) and will not compile with the
latest
> CVS. Replacing "ref" by "handle<>" and "make_ref" by "object" is the
minimum
> that has to be done, but more adjustment might be necessary. A week ago
it
> worked with std::vector and boost::array. I have not tested it with
std::list.
> Another adaptor might be required (see struct
> variable_size_container_registration_adaptor).
>
> Sorry for all the vagueness. I would not normally have advertised the
code, but
> who am I to resist David's challenges?

BTW, you might look at the PySequence_FAST... functions for this.

-Dave






From rwgk at yahoo.com  Thu Jun 20 15:17:43 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 06:17:43 -0700 (PDT)
Subject: [C++-sig] Re: Re: Re: Boost.Python v2: object facilities updated
In-Reply-To: <aerjmt$e04$1@main.gmane.org>
Message-ID: <20020620131743.90448.qmail@web20208.mail.yahoo.com>

--- Dave Hawkes <daveh at cadlink.com> wrote:
> class MyClass {
>     MyClass() : x1(handle<>(borrowed(Py_none))),
> x2(handle<>(borrowed(Py_none))), x3(handle<>(borrowed(Py_none)))
>     {
>         try {
>             x1 = 4;
>             x2 = get_some_value();
>             x3 = x1 + x2;
>         } catch(...) {
>             ...
>         }
>     }
>     object x1, x2, x3;
> };

Why do a want to do this in C++? Wouldn't it much easier to do this in Python?
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From nr at netatec.de  Thu Jun 20 15:18:33 2002
From: nr at netatec.de (Norbert Riedlin)
Date: Thu, 20 Jun 2002 15:18:33 +0200
Subject: [C++-sig] cPickle in extension module
Message-ID: <004701c2185c$fa176410$0564010a@ka.netatec>

Hi all,

in my application (embedding a python interpreter and using an
extension-module) I want to send python-objects between two python scripts.
So in my extension-module I expose the functions "module.to_script(obj)" and
"module.get_object()". Those functions are implemented using the
cPickle-module I import in my C++-application (I use a
cPickle-Singleton-class). My problem seems to be in "module.get_object()",
which is essentially implemented like the following:

  // this fn exposed as get_object
  PyObject* get_object(const std::string& msg)
  {
    return Netatec::PickleModule::Instance().Loads(msg);
  }

And PickleModule::Loads() looks like this:

  PyObject* Netatec::PickleModule::Loads(const std::string& theString) const
  {
    // m_loads previsously assigned to cPickle.loads
    return PyObject_CallFunction(m_loads, "s", theString.c_str());
  }

Now in python I can write:

  import module

  c = SomeClass()
  open("test.txt", "w").write(module.to_script(c))


The problem arises in a second script:

  import module

  def read():
    f=open("test.txt", "r")
    s = f.readlines()
    s1 =""
    for i in s:
      s1 += i
    t=module.get_object(s1) # 1.
    # use t

  read()

Everything works like expected. In the line marked 1. "t" is the previously
pickled object and I can use it. BUT: "t"'s reference-count seems to be too
high, "t" will never be deleted (It's __del__-method is never invoked). Am I
doing something wrong? Is there a better (more boostish way) to call
cPickle.loads()?


I'm using boost.python version 1.22.0. I know it's a bit aged, but in this
stage of our project we don't want to change core-parts of our application.

Thanks in advance for your help

Norbert

--
Norbert Riedlin
Tel.: +49 (0)7243-2176-24
Fax.: +49 (0)7243-2176-19
mailto:norbert.riedlin at netatec.de

netatec GmbH
Am Hardtwald 3
76275 Ettlingen






From rwgk at yahoo.com  Thu Jun 20 15:23:01 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 06:23:01 -0700 (PDT)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com>
Message-ID: <20020620132301.43973.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> I'm working on slicing now and I find myself in need of a way to represent
> x[:y]. This is technically not equivalent to x[0:y] since you can slice on
> any type. "Obviously", the answer is to use
> 
>     x.slice(_,y)

x.slice(open_interval_left(y))
x.slice(open_interval_right(y))

self.Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From niki at vintech.bg  Thu Jun 20 15:35:35 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Thu, 20 Jun 2002 16:35:35 +0300
Subject: [C++-sig] GNU gettext and "_"
References: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com>
Message-ID: <3D11DA27.8030808@vintech.bg>

David Abrahams wrote:
> I'm working on slicing now and I find myself in need of a way to represent
> x[:y]. This is technically not equivalent to x[0:y] since you can slice on
> any type. 

AFAIK *Python* can't slice on anything but integer. And x[y:] is the 
same as x[y:sys.maxint] (from recent thread in c.l.py)

> "Obviously", the answer is to use
> 
>     x.slice(_,y)
> 
> but I suppose that's going to collide with gettext again.
> 
> I suppose we could check "#if defined(_)" and supply some other symbol for
> those people who need gettext compatibility. Suggestions?

IMHO _ alone is not problem. Most compilers wont cofuse it with _()

Niki Spahiev





From pearu at cens.ioc.ee  Thu Jun 20 15:32:11 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 20 Jun 2002 16:32:11 +0300 (EEST)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0206201620570.10525-100000@cens.kybi>

On Thu, 20 Jun 2002, David Abrahams wrote:

> I'm working on slicing now and I find myself in need of a way to represent
> x[:y]. This is technically not equivalent to x[0:y] since you can slice on
> any type. "Obviously", the answer is to use
> 
>     x.slice(_,y)
> 
> but I suppose that's going to collide with gettext again.

"Obvious" to me would be to use the same convention as used in Python
slice object, that is,
 
  x[:y]   would be x.slice(None,y)
  x[:y:]  would be x.slice(None,y,None)
  etc.

> I suppose we could check "#if defined(_)" and supply some other symbol for
> those people who need gettext compatibility. 

-1. It would mean that there will be two groups of BPL users who cannot
use each other codes, very roughly speaking.

Pearu






From david.abrahams at rcn.com  Thu Jun 20 15:33:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 09:33:43 -0400
Subject: [C++-sig] cPickle in extension module
References: <004701c2185c$fa176410$0564010a@ka.netatec>
Message-ID: <0f0201c2185f$19ba3a70$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Norbert Riedlin" <nr at netatec.de>


> I'm using boost.python version 1.22.0. I know it's a bit aged, but in
this
> stage of our project we don't want to change core-parts of our
application.


Norbert,

Some reference-counting bugs /have/ been fixed in Boost.Python since 1.22.
All I can suggest is that you /try/ building with the latest release and
see if the problem goes away. If you really don't want to upgrade your
boost installation you could proceed to diff 1.28.0 with 1.22 to see if you
can find the fix and patch your boost...

...but I would recommend against that. The other advantages of Boost 1.28.0
are so huge that it's probably worth the minimal pain of upgrading.

-Dave





From david.abrahams at rcn.com  Thu Jun 20 15:37:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 09:37:27 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com> <3D11DA27.8030808@vintech.bg>
Message-ID: <0f0f01c2185f$ce2de830$6601a8c0@boostconsulting.com>

From: "Niki Spahiev" <niki at vintech.bg>


> David Abrahams wrote:
> > I'm working on slicing now and I find myself in need of a way to
represent
> > x[:y]. This is technically not equivalent to x[0:y] since you can slice
on
> > any type.
>
> AFAIK *Python* can't slice on anything but integer.

That's just wrong. See sliceobject.

> And x[y:] is the
> same as x[y:sys.maxint] (from recent thread in c.l.py)

Also wrong.

class X(object):
    def getitem(self, key):
        print key

print X()['hello':'world']
print X()['hello':]
print X()[:'world']

> > "Obviously", the answer is to use
> >
> >     x.slice(_,y)
> >
> > but I suppose that's going to collide with gettext again.
> >
> > I suppose we could check "#if defined(_)" and supply some other symbol
for
> > those people who need gettext compatibility. Suggestions?
>
> IMHO _ alone is not problem. Most compilers wont cofuse it with _()

Also wrong. The preprocessor is nasty:

int x = 0;
#define x() y
int y = 1;
int z = x; // error

Sorry :(

-Dave





From daveh at cadlink.com  Thu Jun 20 15:44:07 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 20 Jun 2002 09:44:07 -0400
Subject: [C++-sig] Python API wrapping details
Message-ID: <aesm6v$7me$1@main.gmane.org>

I'm proposing the following  techniques for wrapping the python API for BPL.

Boost header files will be created from a python script. The script will
contain a list of all the supported API functions and their attributes, such
as whether borrowed or new references are returned, error handling, etc. All
the API metadata will be defined in the python script. The python script
will then use a set of rules to generate the API wrappers from this
metadata.

This way if we find at some point we don't like the structure of the
wrappers it is just a matter of adjusting the generator rules rather than
re-editing all the headers.

There are a few issues about the structure of the wrappers:

1) For functions that take non-PyObjects (ie int) as arguments should we
still insist that the arg is wrapped in an object? Maybe there should be
overloaded functions so that either type of arg is acceptable?

2) How should we deal with PyObect** args (ie PyString_InternInPlace) should
the argument type be object& or object*? I suspect its probably better to
force the user to do an explicit &obj.

3) Should all functions always return an object (unless they are void)?
There may be efficiency concerns if we keep wrapping int returns all the
time. We could also provide versions of the functions that do either (though
we can't overload on return type). Some return types may not even be
appropriate to return as an object (ie FILE*).

Thanks
Dave Hawkes









From pearu at cens.ioc.ee  Thu Jun 20 15:47:25 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 20 Jun 2002 16:47:25 +0300 (EEST)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <3D11DA27.8030808@vintech.bg>
Message-ID: <Pine.LNX.4.21.0206201637360.10525-100000@cens.kybi>


On Thu, 20 Jun 2002, Niki Spahiev wrote:

> David Abrahams wrote:
> > I'm working on slicing now and I find myself in need of a way to represent
> > x[:y]. This is technically not equivalent to x[0:y] since you can slice on
> > any type. 
> 
> AFAIK *Python* can't slice on anything but integer. 

Almost true. For example, in Numeric Python it is possible to slice also
on None. In general, slice accepts any arguments. However, implementation
of objects that use slices may restrict the types of arguments. E.g.

>>> slice(None,"aaa",[])
slice(None, 'aaa', [])
>>> [1,2][None:"aaa":[]]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sequence index must be integer

> And x[y:] is the same as x[y:sys.maxint] (from recent thread in c.l.py)

x[y:] is acctually the same as x[y:len(x)] 
(from Python-2.2/Objects/sliceobject.c)

Pearu





From david.abrahams at rcn.com  Thu Jun 20 15:44:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 09:44:47 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <Pine.LNX.4.21.0206201620570.10525-100000@cens.kybi>
Message-ID: <0f2101c21861$36170d90$6601a8c0@boostconsulting.com>

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

> "Obvious" to me would be to use the same convention as used in Python
> slice object, that is,
>
>   x[:y]   would be x.slice(None,y)
>   x[:y:]  would be x.slice(None,y,None)
>   etc.

Unfortunately not equivalent.

>>> range(10)[slice(None:3)]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sequence index must be integer

> > I suppose we could check "#if defined(_)" and supply some other symbol
for
> > those people who need gettext compatibility.
>
> -1. It would mean that there will be two groups of BPL users who cannot
> use each other codes, very roughly speaking.

No, the method that doesn't collide with "_" would be ugly, but would work
everywhere (for now).
However, I don't really want to bend over backwards to stay out of the way
of gettext. There is simply no way to protect yourself from macros. If we
invent a name that we think is safe, say, "nil", somebody will #define nil
0. As a matter of fact, Apple does that in their system headers.

So, what I'm thinking of is something like:

enum slice_nil
{
#ifndef _
    _
#endif
};

So people using systems where "_" is defined can write slice_nil() instead.

-Dave





From daveh at cadlink.com  Thu Jun 20 15:48:35 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 20 Jun 2002 09:48:35 -0400
Subject: [C++-sig] Re: Re: Re: Re: Boost.Python v2: object facilities updated
References: <aerjmt$e04$1@main.gmane.org> <20020620131743.90448.qmail@web20208.mail.yahoo.com>
Message-ID: <aesmfc$8d6$1@main.gmane.org>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote in message
news:20020620131743.90448.qmail at web20208.mail.yahoo.com...
> --- Dave Hawkes <daveh at cadlink.com> wrote:
> > class MyClass {
> >     MyClass() : x1(handle<>(borrowed(Py_none))),
> > x2(handle<>(borrowed(Py_none))), x3(handle<>(borrowed(Py_none)))
> >     {
> >         try {
> >             x1 = 4;
> >             x2 = get_some_value();
> >             x3 = x1 + x2;
> >         } catch(...) {
> >             ...
> >         }
> >     }
> >     object x1, x2, x3;
> > };
>
> Why do a want to do this in C++? Wouldn't it much easier to do this in
Python?
> Ralf
>

It was just a contrived example that would normally be part of a larger c++
class.

Dave Hawkes









From niki at vintech.bg  Thu Jun 20 15:55:00 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Thu, 20 Jun 2002 16:55:00 +0300
Subject: [C++-sig] GNU gettext and "_"
References: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com> <3D11DA27.8030808@vintech.bg> <0f0f01c2185f$ce2de830$6601a8c0@boostconsulting.com>
Message-ID: <3D11DEB4.9010105@vintech.bg>

David Abrahams wrote:
>>AFAIK *Python* can't slice on anything but integer.
> 
> 
> That's just wrong. See sliceobject.
> 
> 
>>And x[y:] is the
>>same as x[y:sys.maxint] (from recent thread in c.l.py)
> 
> 
> Also wrong.
> 
> class X(object):
>     def getitem(self, key):
>         print key
> 
> print X()['hello':'world']
> print X()['hello':]
> print X()[:'world']

I am still in 2.1 era :(

Niki Spahiev





From david.abrahams at rcn.com  Thu Jun 20 15:51:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 09:51:12 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <20020620132301.43973.qmail@web20202.mail.yahoo.com>
Message-ID: <0f2401c21861$ea9eb880$6601a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > I'm working on slicing now and I find myself in need of a way to
represent
> > x[:y]. This is technically not equivalent to x[0:y] since you can slice
on
> > any type. "Obviously", the answer is to use
> >
> >     x.slice(_,y)
>
> x.slice(open_interval_left(y))
> x.slice(open_interval_right(y))

Yikes, Ralf! The whole point of this is that it should be convenient and
mirror Python syntax!
If we have to, I would prefer:

    x.slice(y,z)
    x.slice_from(y)
    x.slice_to(z)

though

    x.slice(y,_)
    x.slice(_,z)

seems much clearer to me.

__import__('Somerville').Dave







From pearu at cens.ioc.ee  Thu Jun 20 15:54:42 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 20 Jun 2002 16:54:42 +0300 (EEST)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <0f2101c21861$36170d90$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0206201651230.10525-100000@cens.kybi>

On Thu, 20 Jun 2002, David Abrahams wrote:

> ----- Original Message -----
> From: "Pearu Peterson" <pearu at cens.ioc.ee>
> 
> > "Obvious" to me would be to use the same convention as used in Python
> > slice object, that is,
> >
> >   x[:y]   would be x.slice(None,y)
> >   x[:y:]  would be x.slice(None,y,None)
> >   etc.
> 
> Unfortunately not equivalent.

Read the source code.

> >>> range(10)[slice(None:3)]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: sequence index must be integer

This example is nonsense. First 
  slice(None:3)
gives syntax error, and second also 
  range(10)[slice(1:3)]
gives 
  TypeError: sequence index must be integer
because index of a list *must* be integer, not a slice or anything else.

Pearu





From david.abrahams at rcn.com  Thu Jun 20 16:06:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 10:06:26 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <0edc01c2185b$e2734190$6601a8c0@boostconsulting.com> <3D11DA27.8030808@vintech.bg> <0f0f01c2185f$ce2de830$6601a8c0@boostconsulting.com> <3D11DEB4.9010105@vintech.bg>
Message-ID: <0f5501c21864$07b4c980$6601a8c0@boostconsulting.com>

----- Original Message ----- 
From: "Niki Spahiev" <niki at vintech.bg>
To: <c++-sig at python.org>
Sent: Thursday, June 20, 2002 9:55 AM
Subject: Re: [C++-sig] GNU gettext and "_"


> David Abrahams wrote:
> >>AFAIK *Python* can't slice on anything but integer.
> > 
> > 
> > That's just wrong. See sliceobject.
> > 
> > 
> >>And x[y:] is the
> >>same as x[y:sys.maxint] (from recent thread in c.l.py)
> > 
> > 
> > Also wrong.
> > 
> > class X(object):
> >     def getitem(self, key):
> >         print key
> > 
> > print X()['hello':'world']
> > print X()['hello':]
> > print X()[:'world']
> 
> I am still in 2.1 era :(

How can that be? Boost.Python v2 depends on 2.2.

modernizing-the-world-one-python-installation-at-a-time-ly y'rs,
dave





From david.abrahams at rcn.com  Thu Jun 20 16:12:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 10:12:05 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <Pine.LNX.4.21.0206201651230.10525-100000@cens.kybi>
Message-ID: <0f5701c21864$765fa0d0$6601a8c0@boostconsulting.com>

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

> > > "Obvious" to me would be to use the same convention as used in Python
> > > slice object, that is,
> > >
> > >   x[:y]   would be x.slice(None,y)
> > >   x[:y:]  would be x.slice(None,y,None)
> > >   etc.
> >
> > Unfortunately not equivalent.
>
> Read the source code.

I have. Which source are you looking at?

see ceval.c: apply_slice()/assign_slice()

> > >>> range(10)[slice(None:3)]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: sequence index must be integer
>
> This example is nonsense. First
>   slice(None:3)
> gives syntax error, and second also
>   range(10)[slice(1:3)]
> gives
>   TypeError: sequence index must be integer
> because index of a list *must* be integer, not a slice or anything else.

Uh, sorry, I meant:

>>> range(10)[slice(None,3)]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sequence index must be integer

Anyway:

>>> range(10).__getslice__(None,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: an integer is required

So, really, I'm not kidding: None is not a substitute for () where slicing
is concerned.

-Dave






From david.abrahams at rcn.com  Thu Jun 20 16:33:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 10:33:38 -0400
Subject: [C++-sig] Python API wrapping details
References: <aesm6v$7me$1@main.gmane.org>
Message-ID: <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Thursday, June 20, 2002 9:44 AM
Subject: [C++-sig] Python API wrapping details


> I'm proposing the following  techniques for wrapping the python API for
BPL.
>
> Boost header files will be created from a python script. The script will
> contain a list of all the supported API functions and their attributes,
such
> as whether borrowed or new references are returned, error handling, etc.
All
> the API metadata will be defined in the python script. The python script
> will then use a set of rules to generate the API wrappers from this
> metadata.

That sounds slower than just doing it by hand overall. The API isn't that
big.

> This way if we find at some point we don't like the structure of the
> wrappers it is just a matter of adjusting the generator rules rather than
> re-editing all the headers.
>
> There are a few issues about the structure of the wrappers:
>
> 1) For functions that take non-PyObjects (ie int) as arguments should we
> still insist that the arg is wrapped in an object? Maybe there should be
> overloaded functions so that either type of arg is acceptable?

That's the approach I've been taking. It's not checked in yet, but I've
overloaded the xxxattr() function to accept char const* keys.

> 2) How should we deal with PyObect** args (ie PyString_InternInPlace)
should
> the argument type be object& or object*? I suspect its probably better to
> force the user to do an explicit &obj.

This is an artifact of a C implementation; we should think about what makes
sense for C++, and mirror Python's interface:

>>> intern
<built-in function intern>
>>> s = 'in-tern'
>>> id(s)
8814968
>>> z = intern(s)
>>> z
'in-tern'
>>> id(z)
8814968
>>> y = 'in-tern'
>>> id(y)
8805080
>>> intern(y)
'in-tern'
>>> id(intern(y))
8814968
>>> id(y)
8805080

> 3) Should all functions always return an object (unless they are void)?

Not neccessarily

> There may be efficiency concerns if we keep wrapping int returns all the
> time.

It depends how things are used. What functions did you have in mind?

> We could also provide versions of the functions that do either (though
> we can't overload on return type). Some return types may not even be
> appropriate to return as an object (ie FILE*).

try:

    >>> help(file)

HTH,
Dave







From daveh at cadlink.com  Thu Jun 20 17:16:41 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 20 Jun 2002 11:16:41 -0400
Subject: [C++-sig] Re: Python API wrapping details
References: <aesm6v$7me$1@main.gmane.org> <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com>
Message-ID: <aesrki$ldb$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0f8401c21867$9d4d9280$6601a8c0 at boostconsulting.com...
> > the API metadata will be defined in the python script. The python script
> > will then use a set of rules to generate the API wrappers from this
> > metadata.
>
> That sounds slower than just doing it by hand overall. The API isn't that
> big.
>

I think it will be less error prone this way, particularly if we find that
we want a large number of overloads of the same function.

> > overloaded functions so that either type of arg is acceptable?
>
> That's the approach I've been taking. It's not checked in yet, but I've
> overloaded the xxxattr() function to accept char const* keys.
>

OK

> > force the user to do an explicit &obj.
>
> This is an artifact of a C implementation; we should think about what
makes
> sense for C++, and mirror Python's interface:
>

Using that logic would mean that the vast majority of these functions should
really be members of object as their first parameter is invariably
PyObject*? Would you consider 'growing' the object declaration to include
the API?

> > 3) Should all functions always return an object (unless they are void)?
>
> Not neccessarily

OK

>
> > There may be efficiency concerns if we keep wrapping int returns all the
> > time.
>
> It depends how things are used. What functions did you have in mind?
>

Functions like PyObject_HasAttrString, but then, as above, this is so
commonly used maybe it should be a member anyway.

> > We could also provide versions of the functions that do either (though
> > we can't overload on return type). Some return types may not even be
> > appropriate to return as an object (ie FILE*).
>
> try:
>
>     >>> help(file)
>

Yes I know there is a PyFileObject. but the intent of some of the file api
is to allow the user access to the underlying FILE*, which you won't get if
the result is wrapped in object as a python file.

Anyway this is answered in 3 above.

Dave Hawkes









From david.abrahams at rcn.com  Thu Jun 20 17:27:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 11:27:01 -0400
Subject: [C++-sig] Re: Python API wrapping details
References: <aesm6v$7me$1@main.gmane.org> <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com> <aesrki$ldb$1@main.gmane.org>
Message-ID: <0fc101c2186e$ed449840$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Thursday, June 20, 2002 11:16 AM
Subject: [C++-sig] Re: Python API wrapping details


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0f8401c21867$9d4d9280$6601a8c0 at boostconsulting.com...
> > > the API metadata will be defined in the python script. The python
script
> > > will then use a set of rules to generate the API wrappers from this
> > > metadata.
> >
> > That sounds slower than just doing it by hand overall. The API isn't
that
> > big.
> >
>
> I think it will be less error prone this way, particularly if we find
that
> we want a large number of overloads of the same function.
>
> > > overloaded functions so that either type of arg is acceptable?
> >
> > That's the approach I've been taking. It's not checked in yet, but I've
> > overloaded the xxxattr() function to accept char const* keys.
> >
>
> OK
>
> > > force the user to do an explicit &obj.
> >
> > This is an artifact of a C implementation; we should think about what
> makes
> > sense for C++, and mirror Python's interface:
> >
>
> Using that logic would mean that the vast majority of these functions
should
> really be members of object as their first parameter is invariably
> PyObject*?

No, they're not methods in Python; they should be free functions in
Boost.Python.

> Would you consider 'growing' the object declaration to include
> the API?

No, that would be bloaty (and unneccessary).

> > > 3) Should all functions always return an object (unless they are
void)?
> >
> > Not neccessarily

Note for example that:

    x < y => bool

> > It depends how things are used. What functions did you have in mind?
> >
>
> Functions like PyObject_HasAttrString, but then, as above, this is so
> commonly used maybe it should be a member anyway.

a. That wouldn't change anything w.r.t. the return type
b. No, we want hasattr(x, "foo"), just like in Python

Read my original post which suggested starting by replicating the Python
built-ins.

> Yes I know there is a PyFileObject. but the intent of some of the file
api
> is to allow the user access to the underlying FILE*, which you won't get
if
> the result is wrapped in object as a python file.

OK, you're right about this one.

-Dave






From rwgk at yahoo.com  Thu Jun 20 18:45:55 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 09:45:55 -0700 (PDT)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <0f2401c21861$ea9eb880$6601a8c0@boostconsulting.com>
Message-ID: <20020620164555.41757.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > I'm working on slicing now and I find myself in need of a way to
> represent
> > > x[:y]. This is technically not equivalent to x[0:y] since you can slice
> on
> > > any type. "Obviously", the answer is to use
> > >
> > >     x.slice(_,y)
> >
> > x.slice(open_interval_left(y))
> > x.slice(open_interval_right(y))
> 
> Yikes, Ralf!

It wouldn't really work for [::] anyway.

> The whole point of this is that it should be convenient and
> mirror Python syntax!

I am having real difficulties seeing the usefulness of the "mirror Python
syntax" approach, especially if you threaten to mess around with defines in
questionable ways. Why would I want to write Python in C++? If I want
convenience I use Python, and if I need speed I use (pure/real/familiar) C++.
Writing Python in C++ is a bit like trying to be half pregnant. IMO this is
sending the wrong signals and will lead to the wrong expectations.

> If we have to, I would prefer:
> 
>     x.slice(y,z)
>     x.slice_from(y)
>     x.slice_to(z)
>

This I like a lot.

> though
> 
>     x.slice(y,_)
>     x.slice(_,z)
> 
> seems much clearer to me.

Not to me, FWIW.
 
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From pearu at cens.ioc.ee  Thu Jun 20 18:57:57 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 20 Jun 2002 19:57:57 +0300 (EEST)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <0f5701c21864$765fa0d0$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0206201726330.10525-100000@cens.kybi>


On Thu, 20 Jun 2002, David Abrahams wrote:

> 
> ----- Original Message -----
> From: "Pearu Peterson" <pearu at cens.ioc.ee>
> 
> > > > "Obvious" to me would be to use the same convention as used in Python
> > > > slice object, that is,
> > > >
> > > >   x[:y]   would be x.slice(None,y)
> > > >   x[:y:]  would be x.slice(None,y,None)
> > > >   etc.
> > >
> > > Unfortunately not equivalent.
> >
> > Read the source code.
> 
> I have. Which source are you looking at?
> 
> see ceval.c: apply_slice()/assign_slice()

I am looking at Objects/sliceobject.c and the docs of api/slice-objects.

> Anyway:
> 
> >>> range(10).__getslice__(None,3)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: an integer is required
> 
> So, really, I'm not kidding: None is not a substitute for () where slicing
> is concerned.

Me neither. I guess we are talking about different things: me about
using slice objects for getting slices while you about getting slices 
directly (which I think would mean that you'll need to repeat some of the
code from Python sources that could be avoided when using slice objects). 

The slice constructor accepts any objects as arguments and when slice
object is used to calculate indices then None is used to indicate missing
values in 
  start:stop:step 
pattern (see sliceobject.c). On the other hand, when getting slices of
sequences, only integer arguments are accepted (see the signatures of
Py(Tuple|List)_GetSlice functions). 

I was assuming that
  x.slice(...)
method first constructs a slice object. This slice object is used to
calculate the indices that in turn are used to construct the slice of x.
If this is not what you expect x.slice(...) to do, then I am confused.

Notice that (probably for efficiency reasons) list and tuple objects do
not use slice objects at all. Nor they accept the step argument.

So, what is the actual purpose of x.slice(start,stop,step)? Is x always
assumed to be a standard Python sequence like list or tuple? Or can x be
also user defined object like Numeric array that accepts also step
argument through the slice object feature?

Pearu






From rwgk at yahoo.com  Thu Jun 20 19:04:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 10:04:42 -0700 (PDT)
Subject: [C++-sig] Python API wrapping details
In-Reply-To: <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com>
Message-ID: <20020620170442.92753.qmail@web20202.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > I'm proposing the following  techniques for wrapping the python API for
> BPL.
> >
> > Boost header files will be created from a python script. The script will
> > contain a list of all the supported API functions and their attributes,
> such
> > as whether borrowed or new references are returned, error handling, etc.
> All
> > the API metadata will be defined in the python script. The python script
> > will then use a set of rules to generate the API wrappers from this
> > metadata.
> 
> That sounds slower than just doing it by hand overall. The API isn't that
> big.

I am a big fan of the python script idea, having done similar things several
times myself. In my experience this approach always saves you more time than
you think. Keep in mind that you do not have to bend over backwards mentally to
generate code with Python (in comparison with certain alternative automatic
code generation techniques; no names mentioned; it is a pitty that the C++
compiler cannot call Python to generate code on demand). It is also much more
fun to keep the script up-to-date than highly redundant source code.

Recently I stumbled over something in the Python directory (unpacked tar
file)that looked like an approximation to the API metafile you have in mind.
Are you aware of this?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From prabhu at aero.iitm.ernet.in  Thu Jun 20 19:11:42 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 20 Jun 2002 22:41:42 +0530
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <20020620164555.41757.qmail@web20209.mail.yahoo.com>
References: <0f2401c21861$ea9eb880$6601a8c0@boostconsulting.com>
	<20020620164555.41757.qmail@web20209.mail.yahoo.com>
Message-ID: <15634.3278.212639.388860@monster.linux.in>

>>>>> "RWGK" == Ralf W Grosse-Kunstleve <rwgk at yahoo.com> writes:

    RWGK> I am having real difficulties seeing the usefulness of the
    RWGK> "mirror Python syntax" approach, especially if you threaten
    RWGK> to mess around with defines in questionable ways. Why would
    RWGK> I want to write Python in C++? If I want convenience I use
    RWGK> Python, and if I need speed I use (pure/real/familiar) C++.

I agree.  So long as the interface does not use very long names and is
well documented I dont see a real point in mirroring Python syntax.

my 2p.
prabhu




From david.abrahams at rcn.com  Thu Jun 20 19:35:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 13:35:46 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <0f2401c21861$ea9eb880$6601a8c0@boostconsulting.com><20020620164555.41757.qmail@web20209.mail.yahoo.com> <15634.3278.212639.388860@monster.linux.in>
Message-ID: <101a01c21880$e9d07af0$6601a8c0@boostconsulting.com>

> >>>>> "RWGK" == Ralf W Grosse-Kunstleve <rwgk at yahoo.com> writes:
>
>     RWGK> I am having real difficulties seeing the usefulness of the
>     RWGK> "mirror Python syntax" approach,

I can't believe I'm reading this. The advantages seem obvious to me:

    1. There's less to learn.
    2. It's easier to remember
    3. It's more convenient.
    4. Somebody (Guido) already figured out what a good interface to these
facilities looks like. Names like PyObject_GetAttrString() are a mere
concession to "C". Guido designed it to read: "getattr()"

>     RWGK> especially if you threaten
>     RWGK> to mess around with defines in questionable ways.

You're kidding, right? It's the person who sticks "#define _(x) gettext(x)"
in a header file that's doing questionable things with defines! I'm willing
to make a small concession to those people by avoiding that identifier if
they've #defined it, and that's all.

>     RWGK> Why would I want to write Python in C++?

Because it's the best interface for manipulating Python objects.

>If I want convenience I use Python, and if I need speed I use
(pure/real/familiar) C++.

Occasionally you want to write functions in C++ that have to interface with
Python objects. Boost.Python is not intended to restrict people to doing
that sort of interaction on the Python side.

-Dave





From rwgk at yahoo.com  Thu Jun 20 19:58:06 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 10:58:06 -0700 (PDT)
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <101a01c21880$e9d07af0$6601a8c0@boostconsulting.com>
Message-ID: <20020620175806.3731.qmail@web20210.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> >     RWGK> especially if you threaten
> >     RWGK> to mess around with defines in questionable ways.
> 
> You're kidding, right? It's the person who sticks "#define _(x) gettext(x)"
> in a header file that's doing questionable things with defines! I'm willing
> to make a small concession to those people by avoiding that identifier if
> they've #defined it, and that's all.

This is what made me worried:

> enum slice_nil
> {
> #ifndef _
>     _
> #endif
> };

Isn't this an invitation to write non-portable code?
 
> >     RWGK> Why would I want to write Python in C++?
> 
> Because it's the best interface for manipulating Python objects.

I'd argue that Python is the best interface for manipulating Python object.

> Occasionally you want to write functions in C++ that have to interface with
> Python objects. Boost.Python is not intended to restrict people to doing
> that sort of interaction on the Python side.

That's all fine. If you don't use defines like the one above you will not see
me arguing.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From prabhu at aero.iitm.ernet.in  Thu Jun 20 19:58:11 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 20 Jun 2002 23:28:11 +0530
Subject: [C++-sig] GNU gettext and "_"
In-Reply-To: <101a01c21880$e9d07af0$6601a8c0@boostconsulting.com>
References: <0f2401c21861$ea9eb880$6601a8c0@boostconsulting.com>
	<20020620164555.41757.qmail@web20209.mail.yahoo.com>
	<15634.3278.212639.388860@monster.linux.in>
	<101a01c21880$e9d07af0$6601a8c0@boostconsulting.com>
Message-ID: <15634.6067.41497.908289@monster.linux.in>

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

    >> >>>>> "RWGK" == Ralf W Grosse-Kunstleve <rwgk at yahoo.com>
    >> writes:
    >> 
    RWGK> I am having real difficulties seeing the usefulness of the
    RWGK> "mirror Python syntax" approach,

    DA> I can't believe I'm reading this. The advantages seem obvious
    DA> to me:

    DA>     1. There's less to learn.  2. It's easier to remember
    DA> 3. It's more convenient.  4. Somebody (Guido) already figured
    DA> out what a good interface to these facilities looks
    DA> like. Names like PyObject_GetAttrString() are a mere
    DA> concession to "C". Guido designed it to read: "getattr()"

Well, thats right but it I thought that isn't worth spending too much
of your time trying to please everyone.  Sure, its a choice that you
make and we all thank you for it.  However, I guess Ralf and me just
want to say, "Don't worry about this too much".  If you think its
important enough to take the extra effort to make it hiss just like a
Python, thats great. :)

cheers,
prabhu





From daveh at cadlink.com  Thu Jun 20 19:55:07 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Thu, 20 Jun 2002 13:55:07 -0400
Subject: [C++-sig] Re: Re: Python API wrapping details
References: <aesm6v$7me$1@main.gmane.org> <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com> <aesrki$ldb$1@main.gmane.org> <0fc101c2186e$ed449840$6601a8c0@boostconsulting.com>
Message-ID: <aet4tk$f7v$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0fc101c2186e$ed449840$6601a8c0 at boostconsulting.com...
> > Using that logic would mean that the vast majority of these functions
> should
> > really be members of object as their first parameter is invariably
> > PyObject*?
>
> No, they're not methods in Python; they should be free functions in
> Boost.Python.
>

I was thinking about the built-in type member functions such as the file
functions. Also file objects appear to have a bit of a dichotamy between the
python API and the 'C' API, for example there is no 'C' seek function. Even
with string there is no capitalize 'C' API method. And then again the
builtin functions hex and oct are not directly exposed.

The python 'C' API appears to be designed to facilitate interfacing with
python rather than exposing its functionality so I'm beginning to wonder
what we should be doing here. For example should the builtin python
functions that have no 'C' API be exposed through the likes of
PyObject_CallFunctionObjArgs?

Perhaps we should concentrate on exposing those functions that are required
to carry out the interface tasks between python and c++.

OK, I'm rambling here, basically I'm saying there's two separate elements to
this. Exposing the pure python functionality and exposing the python
interface functionality and I thinkg they mah have slightly different
requirements.

> > Would you consider 'growing' the object declaration to include
> > the API?
>
> No, that would be bloaty (and unneccessary).
>

OK

> > > > 3) Should all functions always return an object (unless they are
> void)?
> > >
> > > Not neccessarily
>
> Note for example that:
>
>     x < y => bool
>

Yes, I've been thinking about that.

> > commonly used maybe it should be a member anyway.
>
> a. That wouldn't change anything w.r.t. the return type
> b. No, we want hasattr(x, "foo"), just like in Python
>
> Read my original post which suggested starting by replicating the Python
> built-ins.
>

I was thinking ahead to try and keep things consistant.

Dave Hawkes









From david.abrahams at rcn.com  Thu Jun 20 20:17:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 14:17:43 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <20020620175806.3731.qmail@web20210.mail.yahoo.com>
Message-ID: <106301c21887$27e1b470$6601a8c0@boostconsulting.com>

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

> This is what made me worried:
>
> > enum slice_nil
> > {
> > #ifndef _
> >     _
> > #endif
> > };
>
> Isn't this an invitation to write non-portable code?

No, it's a concession to the real world.
If someone's #defined _ in your environment, write slice_nil() instead.

> > Because it's the best interface for manipulating Python objects.
>
> I'd argue that Python is the best interface for manipulating Python
object.

Bleah. It's the best interface you'll get in C++ for manipulating Python
objects.

> > Occasionally you want to write functions in C++ that have to interface
with
> > Python objects. Boost.Python is not intended to restrict people to
doing
> > that sort of interaction on the Python side.
>
> That's all fine. If you don't use defines like the one above you will not
see
> me arguing.

I'm not using #defines like the one above. I'm just staying out of their
way when they crop up.

-Dave





From david.abrahams at rcn.com  Thu Jun 20 23:26:21 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 17:26:21 -0400
Subject: [C++-sig] GNU gettext and "_"
References: <Pine.LNX.4.21.0206201726330.10525-100000@cens.kybi>
Message-ID: <110c01c218a1$31d57830$6601a8c0@boostconsulting.com>

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

> > see ceval.c: apply_slice()/assign_slice()
>
> I am looking at Objects/sliceobject.c and the docs of api/slice-objects.

Well apparently the latest CVS fixes it for lists and tuples, but AFAICT
not for older extension types which don't implement the mapping protocol.

> > So, really, I'm not kidding: None is not a substitute for () where
slicing
> > is concerned.
>
> Me neither. I guess we are talking about different things: me about
> using slice objects for getting slices while you about getting slices
> directly (which I think would mean that you'll need to repeat some of the
> code from Python sources that could be avoided when using slice objects).

No, I don't think we're discussing different things.

> The slice constructor accepts any objects as arguments and when slice
> object is used to calculate indices then None is used to indicate missing
> values in
>   start:stop:step
> pattern (see sliceobject.c). On the other hand, when getting slices of

Yes, thanks, I know this stuff.

> sequences, only integer arguments are accepted (see the signatures of
> Py(Tuple|List)_GetSlice functions).

I know that too.

> I was assuming that
>   x.slice(...)
> method first constructs a slice object.

I could make it do that, but...

> This slice object is used to
> calculate the indices that in turn are used to construct the slice of x.

I would have to look at the target object to see if it as an mp_getitem
field, then if it doesn't I would have to try to translate None to an int
zero... and who knows what else?

> If this is not what you expect x.slice(...) to do, then I am confused.

I expect x.slice(_,y) to be equivalent to x[:y] in Python. Period. How we
get there is (mostly) immaterial. However, using slice objects doesn't
appear to be a universal solution, at least not in current Pythons.

> Notice that (probably for efficiency reasons) list and tuple objects do
> not use slice objects at all. Nor they accept the step argument.

Thanks, I'm aware of that, too.

> So, what is the actual purpose of x.slice(start,stop,step)? Is x always
> assumed to be a standard Python sequence like list or tuple?

No

> Or can x be
> also user defined object like Numeric array that accepts also step
> argument through the slice object feature?

Yes.

-Dave






From david.abrahams at rcn.com  Thu Jun 20 23:52:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 20 Jun 2002 17:52:36 -0400
Subject: [C++-sig] Object slicing added
Message-ID: <114501c218a4$cb297470$6601a8c0@boostconsulting.com>

I've just added slicing support (2 args only; 3 should be an easy
modification). More gode-generation bug fun was had (CWPro8, this time)!

I also added a del() function for proxies, so:

    del(x[2])
    del(x.attr("y"))
    del(x.slice(_,-2))

should all work. However, no tests have been written for that. If someone
would like to extend libs/python/test/object.cpp to check that del() is
working, I'd love 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 rwgk at yahoo.com  Fri Jun 21 02:51:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 20 Jun 2002 17:51:42 -0700 (PDT)
Subject: [C++-sig] Regular multi-platform builds of Boost.Python 2
Message-ID: <20020621005142.91609.qmail@web20205.mail.yahoo.com>

The log files for automatic builds of Boost.Python 2 are available
at this location:

    http://cci.lbl.gov/boost/

Builds against the most current CVS tree are started three times a day
at 0am, 8am and 4pm. For the first time, the 4pm build from today is a
full success with eight different compilers on four different
machines. Compile times range from a few minutes (Windows) to
roughly one hour (Solaris and IRIX).

We would be delighted if the Boost developer and user community finds
this a useful resource.

Nick Sauter & Ralf Grosse-Kunstleve


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Fri Jun 21 14:39:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 21 Jun 2002 08:39:49 -0400
Subject: [C++-sig] Re: Re: Python API wrapping details
References: <aesm6v$7me$1@main.gmane.org> <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com> <aesrki$ldb$1@main.gmane.org> <0fc101c2186e$ed449840$6601a8c0@boostconsulting.com> <aet4tk$f7v$1@main.gmane.org>
Message-ID: <126b01c21921$641b2170$6601a8c0@boostconsulting.com>

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


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0fc101c2186e$ed449840$6601a8c0 at boostconsulting.com...
> > > Using that logic would mean that the vast majority of these functions
> > should
> > > really be members of object as their first parameter is invariably
> > > PyObject*?
> >
> > No, they're not methods in Python; they should be free functions in
> > Boost.Python.
> >
>
> I was thinking about the built-in type member functions such as the file
> functions. Also file objects appear to have a bit of a dichotamy between
the
> python API and the 'C' API, for example there is no 'C' seek function.

Of course, there's always f.attr("seek")(offset)

> Even
> with string there is no capitalize 'C' API method.

likewise s.attr("capitalize")()

However, I do want to have a str type derived from object which has all the
known string methods as member functions directly:

    s.capitalize()


> And then again the
> builtin functions hex and oct are not directly exposed.

I think we could look them up on demand and expose them, but aren't they
somewhat trivial to write directly?

> The python 'C' API appears to be designed to facilitate interfacing with
> python rather than exposing its functionality

I don't get what the difference is, yet.

> so I'm beginning to wonder
> what we should be doing here. For example should the builtin python
> functions that have no 'C' API be exposed through the likes of
> PyObject_CallFunctionObjArgs?

No, they should be exposed through call<>(), so we get the C++ -> Python
type conversions.

> Perhaps we should concentrate on exposing those functions that are
required
> to carry out the interface tasks between python and c++.

Like which ones?

> OK, I'm rambling here, basically I'm saying there's two separate elements
to
> this. Exposing the pure python functionality and exposing the python
> interface functionality and I thinkg they mah have slightly different
> requirements.

Maybe; I'd need to hear more to form an opinion.

> > > commonly used maybe it should be a member anyway.
> >
> > a. That wouldn't change anything w.r.t. the return type
> > b. No, we want hasattr(x, "foo"), just like in Python
> >
> > Read my original post which suggested starting by replicating the
Python
> > built-ins.
> >
>
> I was thinking ahead to try and keep things consistant.

I appreciate the attention to consistency. I don't see how using member
functions improves consistency, though.

-Dave






From daveh at cadlink.com  Fri Jun 21 15:43:55 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 21 Jun 2002 09:43:55 -0400
Subject: [C++-sig] Re: Re: Python API wrapping details
References: <aesm6v$7me$1@main.gmane.org> <0f8401c21867$9d4d9280$6601a8c0@boostconsulting.com> <aesrki$ldb$1@main.gmane.org> <0fc101c2186e$ed449840$6601a8c0@boostconsulting.com> <aet4tk$f7v$1@main.gmane.org> <126b01c21921$641b2170$6601a8c0@boostconsulting.com>
Message-ID: <aevaij$ade$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:126b01c21921$641b2170$6601a8c0 at boostconsulting.com...

> > with string there is no capitalize 'C' API method.
>
> likewise s.attr("capitalize")()
>
> However, I do want to have a str type derived from object which has all
the
> known string methods as member functions directly:
>
>     s.capitalize()
>
>
> > And then again the
> > builtin functions hex and oct are not directly exposed.
>
> I think we could look them up on demand and expose them, but aren't they
> somewhat trivial to write directly?
>

> > The python 'C' API appears to be designed to facilitate interfacing with
> > python rather than exposing its functionality
>
> I don't get what the difference is, yet.


I suppose it a matter of intended purpose, for example PyObject_Hash is
clearly provided to expose the internal python function hash and both are
likely to be used in similar ways in both C/C++ and Python. So here the API
is exposing hash as a piece of python functionality that would be awkward
replicate precisely outside of python.

However the API function PyFile_AsFile has no real built-in counterpart
(fileno is the closest) because it is provided purely to allow the user to
'interface' with the python file object.

The builtin hex function however is fairly trivial to implement outside of
python and is not required at all to interface with python and is therefore
not exposed at all.

So I'm thinking that some functionality should be exposed through the use of
the API where there is a direct duality with the corresponding python
functions Other functions where the duality is not so clear should just be
exposed by calling the internal python function directly.

>
> > so I'm beginning to wonder
> > what we should be doing here. For example should the builtin python
> > functions that have no 'C' API be exposed through the likes of
> > PyObject_CallFunctionObjArgs?
>
> No, they should be exposed through call<>(), so we get the C++ -> Python
> type conversions.
>

I was thinking of the cases where we want all args to be object and the
result to be an object, but, yes, it probably makes sense to use the
call<>() mechanism for everything anyway.

> > Perhaps we should concentrate on exposing those functions that are
> required
> > to carry out the interface tasks between python and c++.
>
> Like which ones?
>

see above.

> > I was thinking ahead to try and keep things consistant.
>
> I appreciate the attention to consistency. I don't see how using member
> functions improves consistency, though.
>

I meant thinking ahead to see what we do about the API functions that don't
correspond directly to builtins. The member function thought was just one of
those things that struck me when I looked at the API list and saw PyObject*
as the first argument to most calls. But as you say it would then not
function equivalently to python.

Dave Hawkes









From nr at netatec.de  Fri Jun 21 16:08:29 2002
From: nr at netatec.de (Norbert Riedlin)
Date: Fri, 21 Jun 2002 16:08:29 +0200
Subject: [C++-sig] cPickle in extension module
References: <20020620135600.2917.73346.Mailman@mail.python.org>
Message-ID: <005b01c2192d$1ecb5520$0564010a@ka.netatec>

> Norbert,
>
> Some reference-counting bugs /have/ been fixed in Boost.Python since 1.22.
> All I can suggest is that you /try/ building with the latest release and
> see if the problem goes away. If you really don't want to upgrade your
> boost installation you could proceed to diff 1.28.0 with 1.22 to see if
you
> can find the fix and patch your boost...
>
> ...but I would recommend against that. The other advantages of Boost
1.28.0
> are so huge that it's probably worth the minimal pain of upgrading.
>
> -Dave
>

Hi Dave,

thank you for the advice. I downloaded version 1.28 and installed it, but
the effect is the same. The pickled object won't be deleted. Could someone
have a closer look at this problem?

TIA

Norbert






From david.abrahams at rcn.com  Fri Jun 21 16:20:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 21 Jun 2002 10:20:22 -0400
Subject: [C++-sig] cPickle in extension module
References: <20020620135600.2917.73346.Mailman@mail.python.org> <005b01c2192d$1ecb5520$0564010a@ka.netatec>
Message-ID: <13d201c2192e$ea2309b0$6601a8c0@boostconsulting.com>

From: "Norbert Riedlin" <nr at netatec.de>

> Hi Dave,
>
> thank you for the advice. I downloaded version 1.28 and installed it, but
> the effect is the same. The pickled object won't be deleted. Could
someone
> have a closer look at this problem?

I won't be able to devote any time to it for at least a week. Maybe someone
else will step forward in the meantime if you can post a *minimal*
reproducible test case.

-Dave






From daveh at cadlink.com  Fri Jun 21 19:56:35 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 21 Jun 2002 13:56:35 -0400
Subject: [C++-sig] using object constructor
Message-ID: <aevpcb$gbc$1@main.gmane.org>

I noticed that new object class instances are usually created from function
returns with code like this:

    return
object((object::new_pyobject_reference*)PyObject_GetItem(target.ptr().get(),
key.ptr().get()));

The new_pyobject_reference is an incomplete class which seems to be used
just to prevent a raw PyObject* being used in the construction of an object.

If we want to start wrapping a significant number of functions to return
objects is this the best way to do it as it seems inherently unsafe as
almost any type of pointer return could be cast in this way.

Is there any reason why a new template class like borrowed but called
(possibly) new_pyobject was not used? That way we could get some additional
type safety from using new_pyobject<PyObject*> in the constructor definition
akin to the existing borrowed/null_ok definitions.

Thanks
Dave Hawkes









From david.abrahams at rcn.com  Fri Jun 21 20:06:11 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 21 Jun 2002 14:06:11 -0400
Subject: [C++-sig] using object constructor
References: <aevpcb$gbc$1@main.gmane.org>
Message-ID: <147401c2194e$aa1bb040$6601a8c0@boostconsulting.com>

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

> If we want to start wrapping a significant number of functions to return
> objects is this the best way to do it as it seems inherently unsafe as
> almost any type of pointer return could be cast in this way.

It's an implementation detail, not for public consumption.

> Is there any reason why a new template class like borrowed but called
> (possibly) new_pyobject was not used?

It adds complication and overhead in debug builds.

> That way we could get some additional
> type safety from using new_pyobject<PyObject*> in the constructor
definition
> akin to the existing borrowed/null_ok definitions.

Yeah, technically you're right. I am not very happy about all the code that
gets generated to handle borrowed, etc. right now though. I'm ambivalent
about making the change, but would be willing to look at a patch.

-Dave






From daveh at cadlink.com  Fri Jun 21 20:29:26 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 21 Jun 2002 14:29:26 -0400
Subject: [C++-sig] Re: using object constructor
References: <aevpcb$gbc$1@main.gmane.org> <147401c2194e$aa1bb040$6601a8c0@boostconsulting.com>
Message-ID: <aevr9u$k6v$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:147401c2194e$aa1bb040$6601a8c0 at boostconsulting.com...
>
> From: "Dave Hawkes" <daveh at cadlink.com>
>
> > If we want to start wrapping a significant number of functions to return
> > objects is this the best way to do it as it seems inherently unsafe as
> > almost any type of pointer return could be cast in this way.
>
> It's an implementation detail, not for public consumption.
>

So what's the recommended public method, is it
object(handle<>(my_py_object_ptr)) ?

> > Is there any reason why a new template class like borrowed but called
> > (possibly) new_pyobject was not used?
>
> It adds complication and overhead in debug builds.
>

I don't think it would need all the additional support borrowed entails, but
I haven't checked in depth.

> > That way we could get some additional
> > type safety from using new_pyobject<PyObject*> in the constructor
> definition
> > akin to the existing borrowed/null_ok definitions.
>
> Yeah, technically you're right. I am not very happy about all the code
that
> gets generated to handle borrowed, etc. right now though. I'm ambivalent
> about making the change, but would be willing to look at a patch.
>

OK, I may do that if I get more concerned about the issue at some point.

> -Dave








From david.abrahams at rcn.com  Fri Jun 21 20:40:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 21 Jun 2002 14:40:05 -0400
Subject: [C++-sig] Re: using object constructor
References: <aevpcb$gbc$1@main.gmane.org> <147401c2194e$aa1bb040$6601a8c0@boostconsulting.com> <aevr9u$k6v$1@main.gmane.org>
Message-ID: <14b601c21953$291d20f0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Friday, June 21, 2002 2:29 PM
Subject: [C++-sig] Re: using object constructor


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:147401c2194e$aa1bb040$6601a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > > If we want to start wrapping a significant number of functions to
return
> > > objects is this the best way to do it as it seems inherently unsafe
as
> > > almost any type of pointer return could be cast in this way.
> >
> > It's an implementation detail, not for public consumption.
> >
>
> So what's the recommended public method, is it
> object(handle<>(my_py_object_ptr)) ?

Yep.

> > > Is there any reason why a new template class like borrowed but called
> > > (possibly) new_pyobject was not used?
> >
> > It adds complication and overhead in debug builds.
> >
>
> I don't think it would need all the additional support borrowed entails,
but
> I haven't checked in depth.

How could it be less?
Well, I'm willing to consider a patch with concrete code, as previously
stated.

Thanks again,
Dave






From achim.domma at syynx.de  Sat Jun 22 19:26:32 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 22 Jun 2002 19:26:32 +0200
Subject: [C++-sig] conversion of std::list<...> parameters in function call
In-Reply-To: <20020620130950.41290.qmail@web20202.mail.yahoo.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEKNDHAA.achim.domma@syynx.de>

Hi Ralf,

it works for my problem, thanks a lot! I reduced it to the parts required
for converting lists, and it seems, that everyting I didn't understand was
not necessary for me! ;-)

Could you please have a look at the following function? Do I have to call
Py_INCREF for the obj in the PyTuple_Check branch?

namespace bpl_utils {
  boost::python::tuple
  list_or_tuple_as_tuple(PyObject* obj)
  {
    using namespace boost::python;
    tuple result;
    if      (PyList_Check(obj)) {
      result = tuple(PyList_AsTuple(obj));
    }
    else if (PyTuple_Check(obj)) {
        //  Py_INCREF ???
      result = tuple(obj);
    }
    // else XXX!?!
    return result;
  }
}

Is it ok to use this code in my (free) ImageMagick wrapper, if I mark it as
based on work copyrighted by you and your university, or is there a license
probem?

greetings
Achim






From rwgk at yahoo.com  Sun Jun 23 11:57:53 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 23 Jun 2002 02:57:53 -0700 (PDT)
Subject: [C++-sig] conversion of std::list<...> parameters in function call
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAIEKNDHAA.achim.domma@syynx.de>
Message-ID: <20020623095753.24163.qmail@web20204.mail.yahoo.com>

--- Achim Domma <achim.domma at syynx.de> wrote:
> Is it ok to use this code in my (free) ImageMagick wrapper, if I mark it as
> based on work copyrighted by you and your university, or is there a license
> probem?

Please remove my list_or_tuple_as_tuple hack from your mind and your disk. It
is not appropriate for general consumption. Here is something better that works
with the latest CVS and that you may use without restrictions:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bpl_utils.h?rev=1.2.2.13&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

See also files
  bpl_utils.cpp
  container_from_list_or_tuple.cpp
  container_from_list_or_tuple.py
in:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_tag=boost_python_v2_transition

The new code is based on PySequence_Fast and will be much more efficient than
the old code if you pass a list or tuple (because these are not copied any
longer).

To get started, look for "sequence_fast" in bpl_utils.h.

Did you have to write a new adoptor fr std::list<>? If so, could you please
post it?

David, please feel free to incorporate the sequence_fast class or any other
code from cctbx::bpl_utils into Boost.Python.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Sun Jun 23 12:03:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 23 Jun 2002 06:03:23 -0400
Subject: [C++-sig] conversion of std::list<...> parameters in function call
References: <20020623095753.24163.qmail@web20204.mail.yahoo.com>
Message-ID: <185901c21a9d$374fa7b0$6601a8c0@boostconsulting.com>

Ralf,

Cool! Please remind me of this on Wednesday; I am currently stuck in a
Microsoft gravity well, trying to survive the inevitable impact.

Best Regards,
Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Sunday, June 23, 2002 5:57 AM
Subject: RE: [C++-sig] conversion of std::list<...> parameters in function
call


> --- Achim Domma <achim.domma at syynx.de> wrote:
> > Is it ok to use this code in my (free) ImageMagick wrapper, if I mark
it as
> > based on work copyrighted by you and your university, or is there a
license
> > probem?
>
> Please remove my list_or_tuple_as_tuple hack from your mind and your
disk. It
> is not appropriate for general consumption. Here is something better that
works
> with the latest CVS and that you may use without restrictions:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bp
l_utils.h?rev=1.2.2.13&only_with_tag=boost_python_v2_transition&content-typ
e=text/vnd.viewcvs-markup
>
> See also files
>   bpl_utils.cpp
>   container_from_list_or_tuple.cpp
>   container_from_list_or_tuple.py
> in:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_
tag=boost_python_v2_transition
>
> The new code is based on PySequence_Fast and will be much more efficient
than
> the old code if you pass a list or tuple (because these are not copied
any
> longer).
>
> To get started, look for "sequence_fast" in bpl_utils.h.
>
> Did you have to write a new adoptor fr std::list<>? If so, could you
please
> post it?
>
> David, please feel free to incorporate the sequence_fast class or any
other
> code from cctbx::bpl_utils into Boost.Python.
>
> Ralf
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.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 Jun 23 12:11:12 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 23 Jun 2002 03:11:12 -0700 (PDT)
Subject: [C++-sig] object, handle<>, .ptr(), PyObject*
Message-ID: <20020623101112.29126.qmail@web20204.mail.yahoo.com>

Consider these fragments from the latest CVS:

template <class T>
class handle
{
    // ...
    T* get() const;
    // ...
};

  class object : // ...
  {
      // ...
      handle<> const& ptr() const;
      // ...
  };

To a novice it will be very confusing that object::ptr() returns
a handle<>. I'd expect that ptr() must be PyObject*, but in fact
another .get() is required to obtain that.

I'd find it significantly less misleading of we had object::hdl().

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From rwgk at yahoo.com  Sun Jun 23 12:13:12 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 23 Jun 2002 03:13:12 -0700 (PDT)
Subject: [C++-sig] conversion of std::list<...> parameters in function call
In-Reply-To: <185901c21a9d$374fa7b0$6601a8c0@boostconsulting.com>
Message-ID: <20020623101312.6049.qmail@web20207.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Cool! Please remind me of this on Wednesday; I am currently stuck in a
> Microsoft gravity well, trying to survive the inevitable impact.

What is a Microsoft gravity well? Are they suing you for having superior
technology?
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From achim.domma at syynx.de  Sun Jun 23 17:28:11 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 23 Jun 2002 17:28:11 +0200
Subject: [C++-sig] conversion of std::list<...> parameters in function call
In-Reply-To: <20020623095753.24163.qmail@web20204.mail.yahoo.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIELBDHAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Ralf W. Grosse-Kunstleve
> Subject: RE: [C++-sig] conversion of std::list<...> parameters in
> function call

> Did you have to write a new adoptor fr std::list<>? If so, could
> you please
> post it?

The following adaptor works for me with lists:

  struct growing_container_registration_adaptor
  {
    template <typename ContainerType>
    static bool check_size(boost::type<ContainerType>, std::size_t sz)
    {
      return true;
    }

    template <typename ContainerType>
    static void reserve(ContainerType& a, std::size_t sz) { }

    template <typename ContainerType, typename ValueType>
    static void set_value(ContainerType& a, std::size_t i, ValueType const&
v)
    {
      a.push_back(v);
    }
  };

Achim






From achim.domma at syynx.de  Sun Jun 23 18:37:59 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 23 Jun 2002 18:37:59 +0200
Subject: [C++-sig] exposing properties with getters and setters
Message-ID: <FCEMIEFBFOIDAOJDEPIAKELCDHAA.achim.domma@syynx.de>

Hi,

what is the correct way to expose properties in boost.python V2, if I have a
function pair for getting and setting the property? Can/Should I use
'__setattr__propertyname' or something else? I tried to use add_property,
but it expects two handles, not functionpointers. The only example I found
was iterator.cpp, but I didn't understand it.

Achim






From nr at netatec.de  Mon Jun 24 10:52:47 2002
From: nr at netatec.de (Norbert Riedlin)
Date: Mon, 24 Jun 2002 10:52:47 +0200
Subject: [C++-sig] Re: cPickle in extension module
References: <20020621160007.16157.81697.Mailman@mail.python.org>
Message-ID: <000d01c21b5c$83aab860$0564010a@ka.netatec>

> I won't be able to devote any time to it for at least a week. Maybe
someone
> else will step forward in the meantime if you can post a *minimal*
> reproducible test case.
>
> -Dave
>
OK, I'll try to make it short:

<code>
// pickletest.cpp
#include "picklemodule.h"

#include <boost/python/detail/wrap_python.hpp>
#include <boost/python/class_builder.hpp>
#include <boost/python/objects.hpp>

PYTHON_API std::string ToScript(PyObject* msg);
PYTHON_API PyObject* FromScript(const std::string& msg);

BOOST_PYTHON_MODULE_INIT(pickletest)
{
  try {
    python::module_builder module("pickletest");

    // pickle
    module.def(&FromScript,   "get_object");
    module.def(&ToScript,       "to_script");
  }
  catch(...) {
    python::handle_exception(); // Deal with the exception for Python
  }
}

PYTHON_API std::string ToScript(PyObject* msg)
{
  return Netatec::PickleModule::Instance().Dumps(msg);
}

PYTHON_API PyObject* FromScript(const std::string& msg)
{
  return Netatec::PickleModule::Instance().Loads(msg);
}

// picklemodule.h, methods inlined for brevity

namespace Netatec {
  class PickleModule {
    private:
      PickleModuleMgr() {
         PyObject* mod = PyImport_ImportModule("cPickle");
         if(mod == 0) {
           PyErr_SetString(PyExc_ImportError, "no module cPickle found");
           throw boost::python::error_already_set();
         }
         m_dumps = PyObject_GetAttrString(mod, "dumps");
         m_loads = PyObject_GetAttrString(mod, "loads");

        Py_XDECREF(mod);
      }

    public:
      static PickleModule& Instance() {
        static PickleModule theModule;
        return theModule;
      }

      ~PickleModuleMgr() {
          Py_XDECREF(m_dumps);
          Py_XDECREF(m_loads);
      }
      std::string Dumps(PyObject* theObject) const {
        const int binary = 0; // 1: binary, 0: text
        PyObject* str = PyObject_CallFunction(m_dumps, "Ni",
                                              theObject, binary);
        if(str == 0) {
          throw boost::python::error_already_set();
        }
        std::string result = PyString_AsString(str);
        Py_XDECREF(str);
        return result;
      }

      PyObject* Loads(const std::string& theString) const {
        return PyObject_CallFunction(m_loads, "s", theString.c_str());
      }
    private:
      PyObject* m_dumps;
      PyObject* m_loads;
  };
}
</code>

Then I compile and link the extensionmodule (BTW, Im using VC++6 an gcc
2.95.2 and (now) boost.python 1.28 ).
In python I have the folowing code:

<code>
# test.py

# A simple testclass, to show that the __del__ message for a loaded object
won't be called:
class test:
  def __init__(self, p1, p2): # so we have some data to pickle
    self.p1 = p1
    self.p2 = p2

  def __del__(self):
    print "__del__-method called", self.p1, self.p2

import pickletest # the extensionmodule

def save():
  t=test(1, 2)
  s=pickletest.to_script(t)
  open("pickled.txt", "w").write(s)
  # here t.__del__() is invoked

def load():
  f=open("pickled.txt", "r")
  s = f.readlines()
  # append all lines in f. I'm sure there is a more elegant way, but who
cares...
  s1 =""
  for i in s:
    s1 += i
  t=pickletest.get_object(s1)
  # here t.__del__() is NOT invoked!!!

save()
load()

</code>

I hope the code isn't too extensive.
Thanks in advance for your help

Norbert

--
Norbert Riedlin
Tel.: +49 (0)7243-2176-24
Fax.: +49 (0)7243-2176-19
mailto:norbert.riedlin at netatec.de

netatec GmbH
Am Hardtwald 3
76275 Ettlingen






From rwgk at yahoo.com  Mon Jun 24 16:47:13 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 24 Jun 2002 07:47:13 -0700 (PDT)
Subject: [C++-sig] Re: cPickle in extension module
In-Reply-To: <000d01c21b5c$83aab860$0564010a@ka.netatec>
Message-ID: <20020624144713.82822.qmail@web20207.mail.yahoo.com>

--- Norbert Riedlin <nr at netatec.de> wrote:
>       PyObject* Loads(const std::string& theString) const {
>         return PyObject_CallFunction(m_loads, "s", theString.c_str());
>       }

I remember a long while ago I also had a problem with memory leaks when
returning PyObject*. This was "fixed" by returning a boost::python::ref
instead. For example:

boost::python::ref Loads(const std::string& theString) const {
  return boost::python::ref(PyObject_CallFunction(m_loads, "s",
theString.c_str()));
}

You might want to replace all your PyObject* by ref. That way you could
eliminate all DECREF and the destructor of your pickle helper class.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From s13361562 at bach.sun.ac.za  Mon Jun 24 23:26:23 2002
From: s13361562 at bach.sun.ac.za (Hugo van der Merwe)
Date: Mon, 24 Jun 2002 23:26:23 +0200
Subject: [C++-sig] Another BPLV2 newbie...
Message-ID: <20020624212623.GA17764@vervet.localnet>

I recently finally got round to taking a look at V2, and seeing if I can
do something with it. (Seems I can't ;)

I immediately ran into two things I don't know how to handle.

First is related to trying to wrap a library which has
constructors with many many parameters. With V1 the solution was:

python ../gen_all.py 20

20 isn't quite necessary. How do I do something similar with V2?

Second, what is wrong with this:

==== test.cpp ====
#define BOOST_PYTHON_V2
#include <boost/python/module.hpp>

class test
{
public:
    test();
};

BOOST_PYTHON_MODULE_INIT(testmod)
{
    boost::python::module testmod("testmod");
    testmod
	.add(
	    boost::python::class_<test>("test")
	    .def_init()
	    );
}
==== test.cpp ====

I get the following error tryinc to compile it:

demeter.cpp:42: type `boost::python::class_<Demeter::Settings,boost::python::detail::not_specified,boost::python::detail::not_specified,boost::python::detail::not_specified>' is not yet defined

I'm worried I might have broken something by trying gen_all.py, but the
tests appear to build fine. (I ran 
$ jam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr
in libs/python/test, with BOOST_ROOT set in environment.)

Thanks,
Hugo van der Merwe




From rwgk at yahoo.com  Tue Jun 25 00:31:59 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 24 Jun 2002 15:31:59 -0700 (PDT)
Subject: [C++-sig] Another BPLV2 newbie...
In-Reply-To: <20020624212623.GA17764@vervet.localnet>
Message-ID: <20020624223159.1072.qmail@web20201.mail.yahoo.com>

--- Hugo van der Merwe <s13361562 at bach.sun.ac.za> wrote:
> First is related to trying to wrap a library which has
> constructors with many many parameters. With V1 the solution was:
> 
> python ../gen_all.py 20
> 
> 20 isn't quite necessary. How do I do something similar with V2?

The python script is no longer required with V2. Arbitrary arities are handled
by the preprocessor library. This is explained in one of David's progress
reports (around April). You can find these somewhere in the CVS tree, or search
the C++-SIG archive through Active State's interface:

http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/C++-sig
 
> Second, what is wrong with this:
> 
> ==== test.cpp ====
> #define BOOST_PYTHON_V2
> #include <boost/python/module.hpp>

I think you are just missing

#include <boost/python/class.hpp>

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From nr at netatec.de  Tue Jun 25 11:09:24 2002
From: nr at netatec.de (Norbert Riedlin)
Date: Tue, 25 Jun 2002 11:09:24 +0200
Subject: [C++-sig] Re: Re: Re: cPickle in extension module
References: <20020624160034.16835.69754.Mailman@mail.python.org>
Message-ID: <006601c21c28$00dfed20$0564010a@ka.netatec>

> Date: Mon, 24 Jun 2002 07:47:13 -0700 (PDT)
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> Subject: Re: [C++-sig] Re: cPickle in extension module
> To: c++-sig at python.org
> Reply-To: c++-sig at python.org
>
>
> I remember a long while ago I also had a problem with memory leaks when
> returning PyObject*. This was "fixed" by returning a boost::python::ref
> instead. For example:
>
> boost::python::ref Loads(const std::string& theString) const {
>   return boost::python::ref(PyObject_CallFunction(m_loads, "s",
> theString.c_str()));
> }
>
> You might want to replace all your PyObject* by ref. That way you could
> eliminate all DECREF and the destructor of your pickle helper class.
>
> Ralf
>
Hi Ralf,

thank you for your help, now all memory leaks have vanished even in version
1.22. One last question: "... replace all your PyObject* by ref...."
excludes overloads of to_python, right? In my original code (not in the
example above) there are quite a few places I need the overloads.

Norbert
--
Norbert Riedlin
Tel.: +49 (0)7243-2176-24
Fax.: +49 (0)7243-2176-19
mailto:norbert.riedlin at netatec.de

netatec GmbH
Am Hardtwald 3
76275 Ettlingen






From rwgk at yahoo.com  Tue Jun 25 16:53:36 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 25 Jun 2002 07:53:36 -0700 (PDT)
Subject: [C++-sig] Re: Re: Re: cPickle in extension module
In-Reply-To: <006601c21c28$00dfed20$0564010a@ka.netatec>
Message-ID: <20020625145336.15599.qmail@web20206.mail.yahoo.com>

--- Norbert Riedlin <nr at netatec.de> wrote:
> thank you for your help, now all memory leaks have vanished even in version
> 1.22. One last question: "... replace all your PyObject* by ref...."
> excludes overloads of to_python, right? In my original code (not in the
> example above) there are quite a few places I need the overloads.

Yes, in V1 to_python has to return a raw PyObject*.
Ralf
P.S.: In V2 you will not need to trade raw PyObject* anymore unless you use the
Python API directly.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From casado2 at llnl.gov  Tue Jun 25 18:44:31 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Tue, 25 Jun 2002 09:44:31 -0700
Subject: [C++-sig] from python conversions
In-Reply-To: <3C99E60C.133962E6@informatik.uni-hamburg.de>
References: <5.1.0.14.2.20020306193539.0315fc38@mail.earthlink.net> <08e001c1d032$d2ffb480$6f99accf@boostconsulting.com> <3C99E60C.133962E6@informatik.uni-hamburg.de>
Message-ID: <0206250944310F.02424@avalanche.llnl.gov>

 I'm trying to rewrite my python to c++ object conversions that 
 I had under the old interface and am running into some problems.

 Am I correct in thinking that we need to use rvalue_from_python
 and lvalue_from_python?  Is there any mechanism similar to
 the old method, in which for a given type_id you can register
 two functions, one to determine whether you can convert the object,
 and the second to do the conversion?

 Thanks,
 Martin




From rwgk at yahoo.com  Tue Jun 25 20:54:56 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 25 Jun 2002 11:54:56 -0700 (PDT)
Subject: [C++-sig] from python conversions
In-Reply-To: <0206250944310F.02424@avalanche.llnl.gov>
Message-ID: <20020625185456.72219.qmail@web20206.mail.yahoo.com>

--- Martin Casado <casado2 at llnl.gov> wrote:
>  Am I correct in thinking that we need to use rvalue_from_python
>  and lvalue_from_python?  Is there any mechanism similar to
>  the old method, in which for a given type_id you can register
>  two functions, one to determine whether you can convert the object,
>  and the second to do the conversion?

Until you get a more definitive answer from David (who still seems to be stuck
in the Microsoft gravity well), check this out:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bpl_utils.h?rev=1.2.2.14&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup

Look for

struct register_container_from_python_sequence

HTH,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From casado2 at llnl.gov  Wed Jun 26 01:33:44 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Tue, 25 Jun 2002 16:33:44 -0700
Subject: [C++-sig] from python conversions
In-Reply-To: <20020625185456.72219.qmail@web20206.mail.yahoo.com>
References: <20020625185456.72219.qmail@web20206.mail.yahoo.com>
Message-ID: <0206251633440K.02424@avalanche.llnl.gov>

> --- Martin Casado <casado2 at llnl.gov> wrote:
> >  Am I correct in thinking that we need to use rvalue_from_python
> >  and lvalue_from_python?  Is there any mechanism similar to
> >  the old method, in which for a given type_id you can register
> >  two functions, one to determine whether you can convert the object,
> >  and the second to do the conversion?
>
> Until you get a more definitive answer from David (who still seems to be
> stuck in the Microsoft gravity well), check this out:
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/bp
>l_utils.h?rev=1.2.2.14&only_with_tag=boost_python_v2_transition&content-type
>=text/vnd.viewcvs-markup
>
> Look for
>
> struct register_container_from_python_sequence
>
> HTH,
>         Ralf

  This is perfect, thanks.  Are you planning on submitting these to Dave
  for inclusion in BPL? They are really helpful.

         ~~m

> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.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  Tue Jun 25 23:52:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 25 Jun 2002 17:52:26 -0400
Subject: [C++-sig] tuple, list, dict, et. al
Message-ID: <1aa401c21d0b$8e143550$6601a8c0@boostconsulting.com>

The answers below are mine, but I'm interested in feedback about them.

----

Question:
    What should the following do, where o is a python::object?

        tuple(o)

Answer:

    I believe (strongly) that it should do something exactly
    corresponding to what does in Python:

    >>> help(tuple)
    Help on class tuple in module __builtin__:

    class tuple(object)
     |  tuple() -> an empty tuple
     |  tuple(sequence) -> tuple initialized from sequence's items
     |
     |  If the argument is a tuple, the return value is the same object.

Question:

    How do I specify that a wrapped function accepts a tuple argument?

Answer:

    Put a boost::tuple in the function signature

Question:

    What should that mean in terms of overload resolution?

Answer 1:

    The function only matches if the actual argument is a Python
    tuple or a subclass of tuple

Answer 2:

    The function matches if the actual argument is any Python sequence;
    tuple(arg) will be applied to retrieve the tuple object used inside
    the wrapped function

Which of the above answers is better? So far liberal conversion during
function matching (e.g. Python Float -> C++ int) has caused problems
for at least one person. On the other hand, in the long run that
problem should be resolved and overloads should be resolved more-smartly.

Opinions?

-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 Jun 26 02:07:59 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 25 Jun 2002 20:07:59 -0400
Subject: [C++-sig] exposing properties with getters and setters
References: <FCEMIEFBFOIDAOJDEPIAKELCDHAA.achim.domma@syynx.de>
Message-ID: <1aa501c21d0b$8e344070$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: "C++-Sig at Python. Org" <c++-sig at python.org>
Sent: Sunday, June 23, 2002 12:37 PM
Subject: [C++-sig] exposing properties with getters and setters


> Hi,
>
> what is the correct way to expose properties in boost.python V2, if I
have a
> function pair for getting and setting the property? Can/Should I use
> '__setattr__propertyname'

No, that's a v1 idiom

> or something else?

Yes, something else.

> I tried to use add_property,
> but it expects two handles, not functionpointers. The only example I
found
> was iterator.cpp, but I didn't understand it.

You can use make_function() to create a callable Python object from a
function or member function pointer, so:

    .add_property(
        handle<>(make_function(my_get_func))
       , handle<>(make_function(my_set_func))))






From niki at vintech.bg  Wed Jun 26 14:41:23 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Wed, 26 Jun 2002 15:41:23 +0300
Subject: [C++-sig] tuple, list, dict, et. al
References: <1aa401c21d0b$8e143550$6601a8c0@boostconsulting.com>
Message-ID: <3D19B673.4070901@vintech.bg>

David Abrahams wrote:
> Question:
> 
>     What should that mean in terms of overload resolution?
> 
> Answer 1:
> 
>     The function only matches if the actual argument is a Python
>     tuple or a subclass of tuple
> 
> Answer 2:
> 
>     The function matches if the actual argument is any Python sequence;
>     tuple(arg) will be applied to retrieve the tuple object used inside
>     the wrapped function

When i start with pure python prototype all functions behave like Answer 
2. If later some of them are replaced with C++ code i expect it to 
behave the same.

Niki Spahiev





From david.abrahams at rcn.com  Wed Jun 26 15:46:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 09:46:14 -0400
Subject: [C++-sig] Another BPLV2 newbie...
References: <20020624212623.GA17764@vervet.localnet>
Message-ID: <1bee01c21d18$5df51a80$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Hugo van der Merwe" <s13361562 at bach.sun.ac.za>
To: <c++-sig at python.org>
Sent: Monday, June 24, 2002 5:26 PM
Subject: [C++-sig] Another BPLV2 newbie...


> I recently finally got round to taking a look at V2, and seeing if I can
> do something with it. (Seems I can't ;)
>
> I immediately ran into two things I don't know how to handle.
>
> First is related to trying to wrap a library which has
> constructors with many many parameters. With V1 the solution was:
>
> python ../gen_all.py 20
>
> 20 isn't quite necessary. How do I do something similar with V2?

We support up to 15 arguments by default on all compilers, 17 on non-EDG
compilers.

If you need support for more arguments, you can set #define
BOOST_PYTHON_MAX_ARITY to the number of arguments you need to support. You
can do this on the compiler command-line with -DBOOST_PYTHON_MAX_ARITY=20
or in your bjam invocation by adding

    <define>BOOST_PYTHON_MAX_ARITY=20

to your BUILD variable. For example,

    bjam "-sBUILD=debug <define>BOOST_PYTHON_MAX_ARITY=20" ...

However, if you are using an EDG-based compiler (see if the symbol
__EDG_VERSION is automatically #defined to find out), your compilations
will slow to a crawl, since their preprocessor is so slow -- we have
"manually" preprocessed many of the files which need expansion, too keep
compilation with EDG going at a reasonable pace, but only up to 15 args.
Changes are planned which will correct this problem so that fewer manually
preprocessed files will be needed, but they haven't been instituted yet. If
you need help manually preprocessing these files for more arguments, please
let me know and I'll make instructions available.

> Second, what is wrong with this:
>
> ==== test.cpp ====
> #define BOOST_PYTHON_V2
> #include <boost/python/module.hpp>
>
> class test
> {
> public:
>     test();
> };
>
> BOOST_PYTHON_MODULE_INIT(testmod)
> {
>     boost::python::module testmod("testmod");
>     testmod
> .add(
>     boost::python::class_<test>("test")
>     .def_init()
>     );
> }
> ==== test.cpp ====
>
> I get the following error tryinc to compile it:
>
> demeter.cpp:42: type
`boost::python::class_<Demeter::Settings,boost::python::detail::not_specifi
ed,boost::python::detail::not_specified,boost::python::detail::not_specifie
d>' is not yet defined

Looks like a missing #include <boost/python/class.hpp> to me.

> I'm worried I might have broken something by trying gen_all.py, but the
> tests appear to build fine. (I ran
> $ jam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr
> in libs/python/test, with BOOST_ROOT set in environment.)

Don't use "jam"; the executable you want is "bjam" (the name matters).

HTH,
Dave






From daveh at cadlink.com  Wed Jun 26 15:59:14 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Wed, 26 Jun 2002 09:59:14 -0400
Subject: [C++-sig] Re: tuple, list, dict, et. al
References: <1aa401c21d0b$8e143550$6601a8c0@boostconsulting.com>
Message-ID: <afchb1$q1h$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1aa401c21d0b$8e143550$6601a8c0 at boostconsulting.com...
> The answers below are mine, but I'm interested in feedback about them.
> Which of the above answers is better? So far liberal conversion during
> function matching (e.g. Python Float -> C++ int) has caused problems
> for at least one person. On the other hand, in the long run that
> problem should be resolved and overloads should be resolved more-smartly.
>
> Opinions?
>

I vote for having an exact argument match (answer 1). Too many overloads can
eventually lead to type matching ambiguity. If the user has a problem with
an application because it uses arguments in a particular way they can easily
create their own specific wrapper.

I'd also go back to an argument I've used before: It is easier to give than
take-away. Should it eventually be shown that more liberal matching really
is useful then it could be added at a later date.

Dave Hawkes









From david.abrahams at rcn.com  Wed Jun 26 17:33:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 11:33:41 -0400
Subject: [C++-sig] exposing properties with getters and setters
References: <FCEMIEFBFOIDAOJDEPIAKELCDHAA.achim.domma@syynx.de> <1aa501c21d0b$8e344070$6601a8c0@boostconsulting.com>
Message-ID: <1dd701c21d27$39ac5300$6601a8c0@boostconsulting.com>

From: "David Abrahams" <david.abrahams at rcn.com>
> You can use make_function() to create a callable Python object from a
> function or member function pointer, so:
> 
>     .add_property(
>         handle<>(make_function(my_get_func))
>        , handle<>(make_function(my_set_func))))
> 

Oops, that's not exception-safe and I forgot the property name. Make that:

    handle<> get(make_function(my_get_func));
    handle<> set(make_function(my_set_func));
    ...

    .add_property("name", get, set)


I do plan to change things so that you can write:

    object x(my_get_func)

and

    callable y(my_get_func)

and

    .add_property("name", my_get_func, my_set_func)

eventually. Sorry for the temporary inconvenience.

-Dave






From rwgk at yahoo.com  Wed Jun 26 18:40:17 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 26 Jun 2002 09:40:17 -0700 (PDT)
Subject: [C++-sig] tuple, list, dict, et. al
In-Reply-To: <1aa401c21d0b$8e143550$6601a8c0@boostconsulting.com>
Message-ID: <20020626164017.40031.qmail@web20206.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> Answer 1:
> 
>     The function only matches if the actual argument is a Python
>     tuple or a subclass of tuple
> 
> Answer 2:
> 
>     The function matches if the actual argument is any Python sequence;
>     tuple(arg) will be applied to retrieve the tuple object used inside
>     the wrapped function

And here is the third opinion: give the user a choice. If you want a tuple and
only a tuple, the user specifies boost::python::tuple as the argument. If any
sequence is acceptable, boost::python::sequence_fast, which is a wrapper around
the PySequence_Fast family of Python API functions (just like the one in the
bpl_utils that I posted before).

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Wed Jun 26 18:48:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 12:48:10 -0400
Subject: [C++-sig] tuple, list, dict, et. al
References: <20020626164017.40031.qmail@web20206.mail.yahoo.com>
Message-ID: <1efa01c21d31$e79db2b0$6601a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > Answer 1:
> >
> >     The function only matches if the actual argument is a Python
> >     tuple or a subclass of tuple
> >
> > Answer 2:
> >
> >     The function matches if the actual argument is any Python sequence;
> >     tuple(arg) will be applied to retrieve the tuple object used inside
> >     the wrapped function
>
> And here is the third opinion: give the user a choice. If you want a
tuple and
> only a tuple, the user specifies boost::python::tuple as the argument. If
any
> sequence is acceptable, boost::python::sequence_fast, which is a wrapper
around
> the PySequence_Fast family of Python API functions (just like the one in
the
> bpl_utils that I posted before).

That's actually answer 1, which is also what I was leaning towards.
However, note that PySequence_Fast is not a complete solution, in that it
only works with tuples and lists. To see the difference:

    >>> xrange(10)        # not a tuple or list
    xrange(10)
    >>> tuple(xrange(10)) # converts any sequence
    (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)

The version of Ralf's sequence conversion code that I accept into
Boost.Python should really work for any sequence, IMO. So, while I don't
mind having a boost::python::sequence_fast which matches tuple and list
arguments, I really want a boost::python::sequence type which matches any
sequence.

-Dave






From rwgk at yahoo.com  Wed Jun 26 19:11:34 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 26 Jun 2002 10:11:34 -0700 (PDT)
Subject: [C++-sig] conversion of std::list<...>
Message-ID: <20020626171134.47049.qmail@web20206.mail.yahoo.com>

> Cool! Please remind me of this on Wednesday; I am currently stuck in a
> Microsoft gravity well, trying to survive the inevitable impact.

The

struct register_container_from_python_sequence

in the bpl_utils still has an undesirable feature: the input Python sequence is
traversed twice. This does not matter if the user passes a list or tuple, but
will cause confusion (at least) if the user passes an object that can only be
traversed once (something similar to a file object for example; or some kind of
iterator).

Consider the static member functions of
register_container_from_python_sequence:

static void* convertible(PyObject* obj_ptr)
{
  //...
  sequence_fast seq(obj, 0); // first traversal
  //...
}

static void construct(PyObject* obj_ptr,
boost::python::converter::rvalue_stage1_data* data)
{
  //...
  sequence_fast seq(obj, 0); // second traversal
  //...
}

Could we somehow avoid the second traversal?

Idea: sequence_fast has a handle<> with the result of PySequence_Fast().
I know I could return the corresponding PyObject* from convertible(),
and this will then be passed as the first argument to construct(). I.e. I could
just use the PyObject* knowing it is the result of PySequence_Fast() and would
not have to call PySequence_Fast() a second time.

Problem: PySequence_Fast returns a new reference. There is no guarantee that
construct() will be called. So the reference count has to be managed outside of
convertible() and construct(). Could this be done in the current framework?

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From rwgk at yahoo.com  Wed Jun 26 19:28:21 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 26 Jun 2002 10:28:21 -0700 (PDT)
Subject: [C++-sig] tuple, list, dict, et. al
In-Reply-To: <1efa01c21d31$e79db2b0$6601a8c0@boostconsulting.com>
Message-ID: <20020626172821.41119.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> However, note that PySequence_Fast is not a complete solution, in that it
> only works with tuples and lists.


From david.abrahams at rcn.com  Wed Jun 26 19:59:33 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 13:59:33 -0400
Subject: [C++-sig] from python conversions
References: <5.1.0.14.2.20020306193539.0315fc38@mail.earthlink.net> <08e001c1d032$d2ffb480$6f99accf@boostconsulting.com> <3C99E60C.133962E6@informatik.uni-hamburg.de> <0206250944310F.02424@avalanche.llnl.gov>
Message-ID: <1f7501c21d3b$3bfb34f0$6601a8c0@boostconsulting.com>

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

>  I'm trying to rewrite my python to c++ object conversions that
>  I had under the old interface and am running into some problems.
>
>  Am I correct in thinking that we need to use rvalue_from_python
>  and lvalue_from_python?

Not sure what you're trying to do, so it's hard to say. There's no
lvalue_from_python anymore, though, so I guess the answer is no.

>  Is there any mechanism similar to
>  the old method, in which for a given type_id you can register
>  two functions, one to determine whether you can convert the object,
>  and the second to do the conversion?

The mechanism is the same, though some names have changed to protect the
innocent. Which conversion are you trying to do (i.e. which slot in the
following matrix)?

                   to_python  from_python
                 +----------+------------+
function argument|          |            |
                 +----------+------------+
function result  |          |            |
                 +----------+------------+


Dave





From david.abrahams at rcn.com  Wed Jun 26 20:15:19 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 14:15:19 -0400
Subject: [C++-sig] tuple, list, dict, et. al
References: <20020626172821.41119.qmail@web20209.mail.yahoo.com>
Message-ID: <1f9e01c21d3e$0a3fb3c0$6601a8c0@boostconsulting.com>

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

> This implies to me that it will work for any sequence, and a quick test
just
> convinced me that PySequence_Fast() works with o = xrange(n), even if
traversed
> twice.

In that case, rock me, Amadeus!

Just so long as we can call it python::sequence.

and-not-sequence_fast-ly y'rs,
dave







From david.abrahams at rcn.com  Wed Jun 26 20:44:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 14:44:03 -0400
Subject: [C++-sig] tuple, list, dict, et. al
References: <20020626172821.41119.qmail@web20209.mail.yahoo.com> <1f9e01c21d3e$0a3fb3c0$6601a8c0@boostconsulting.com>
Message-ID: <1fb401c21d41$72f40670$6601a8c0@boostconsulting.com>

Oh, wait: I take it back. The problem with using PySequence_Fast() is that
it changes the type of the argument. In other words, if I wrap the
following:

    object sequence_type(sequence x)
    {
        return x.attr("__class__")
    }

and then, I write:

    >>> sequence_type(xrange(10))

I want it to say

    xrange

not

    tuple

. So, I'm back to my earlier position: we can have sequence_fast for people
who want something that converts to a tuple (or preserves a list), but I
want sequence for people who want to accept any sequence without modifying
it.

-Dave



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


>
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
>
> > This implies to me that it will work for any sequence, and a quick test
> just
> > convinced me that PySequence_Fast() works with o = xrange(n), even if
> traversed
> > twice.
>
> In that case, rock me, Amadeus!
>
> Just so long as we can call it python::sequence.
>
> and-not-sequence_fast-ly y'rs,
> dave






From david.abrahams at rcn.com  Wed Jun 26 21:18:25 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 15:18:25 -0400
Subject: [C++-sig] conversion of std::list<...>
References: <20020626171134.47049.qmail@web20206.mail.yahoo.com>
Message-ID: <20e701c21d46$3fae77f0$6601a8c0@boostconsulting.com>

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


> > Cool! Please remind me of this on Wednesday; I am currently stuck in a
> > Microsoft gravity well, trying to survive the inevitable impact.

Looks like I came out the other side of the black hole OK... though I might
be my evil twin. Let me go look in the mirror to see if I have a goatee...
hmm, I might: I'm not saying.


> The
>
> struct register_container_from_python_sequence
>
> in the bpl_utils still has an undesirable feature: the input Python
sequence is
> traversed twice. This does not matter if the user passes a list or tuple,
but
> will cause confusion (at least) if the user passes an object that can
only be
> traversed once (something similar to a file object for example; or some
kind of
> iterator).
>
> Consider the static member functions of
> register_container_from_python_sequence:
>
> static void* convertible(PyObject* obj_ptr)
> {
>   //...
>   sequence_fast seq(obj, 0); // first traversal
>   //...
> }
>
> static void construct(PyObject* obj_ptr,
> boost::python::converter::rvalue_stage1_data* data)
> {
>   //...
>   sequence_fast seq(obj, 0); // second traversal
>   //...
> }
>
> Could we somehow avoid the second traversal?

We discussed this on the phone; don't you remember? the answer is to change
the protocol for rvalue from_python converters so that the convertible()
function gets access to the from_python_data and can do the construction at
that point.

> Idea: sequence_fast has a handle<> with the result of PySequence_Fast().
> I know I could return the corresponding PyObject* from convertible(),
> and this will then be passed as the first argument to construct(). I.e. I
could
> just use the PyObject* knowing it is the result of PySequence_Fast() and
would
> not have to call PySequence_Fast() a second time.
>
> Problem: PySequence_Fast returns a new reference. There is no guarantee
that
> construct() will be called. So the reference count has to be managed
outside of
> convertible() and construct(). Could this be done in the current
framework?

It's an intriguing idea, but I don't think it's superior to the solution we
discussed. For one thing, it means that for non list/tuple sequences (e.g.
xrange, NumPy array), at some point a python list or tuple will need to be
created as an intermediate step of the conversion. Especially for the case
of stream-based sequences, where the elements don't exist in memory all at
once, this could be really expensive because it means creating the tuple
and Python elements just so we can copy them into the container being
constructed. The memory overhead for a Python int/float over a C++
int/double is not insignificant. If the conversion happened one element at
a time it could be far better in terms of locality of reference and
especially memory requirements.

For another thing, it would complicate the destructor of rvalue
arg_from_python converters, because they would have to manage not only
destroying the temporary object but also decrementing the reference count
of a possible intermediate Python object. That conflicts with the goal of
keeping these extremely lightweight.

There are a lot of features people want, and I can only do so much. I would
be happy to concentrate on this problem if someone would pick up the ball
in implementing tuple, dict, int_, list, et. al., which are pretty
mechanical (hint, hint).

-Dave








From rwgk at yahoo.com  Wed Jun 26 21:24:08 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 26 Jun 2002 12:24:08 -0700 (PDT)
Subject: [C++-sig] tuple, list, dict, et. al
In-Reply-To: <1fb401c21d41$72f40670$6601a8c0@boostconsulting.com>
Message-ID: <20020626192408.16008.qmail@web20210.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> So, I'm back to my earlier position: we can have sequence_fast for people
> who want something that converts to a tuple (or preserves a list), but I
> want sequence for people who want to accept any sequence without modifying
> it.

This sounds to me as if you want a wrapper for the family of API functions
listed here:

http://www.python.org/doc/current/api/sequence.html

At first sight this looks straight-forward. Do you see major difficulties?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




From david.abrahams at rcn.com  Wed Jun 26 21:35:19 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 15:35:19 -0400
Subject: [C++-sig] tuple, list, dict, et. al
References: <20020626192408.16008.qmail@web20210.mail.yahoo.com>
Message-ID: <20fd01c21d48$9d43eb00$6601a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > So, I'm back to my earlier position: we can have sequence_fast for
people
> > who want something that converts to a tuple (or preserves a list), but
I
> > want sequence for people who want to accept any sequence without
modifying
> > it.
>
> This sounds to me as if you want a wrapper for the family of API
functions
> listed here:
>
> http://www.python.org/doc/current/api/sequence.html

No, we already have what we need as far as API with object. All of these
other classes (tuple, string, dict, sequence) I'm discussing should just be
classes derived from object, with appropriate constructors invoking the
corresponding built-in type on the argument to get the argument for the
base class constructor. The only other step is to make the appropriate
client-side to/from_python converters. These should probably be handled as
specializations, as was done for object and its proxies.

I would consider adding some optimizations for particular types (e.g. use
PyString_Concat to implement operator+ on strings), but it seems
unneccessary as the existing object interfaces already work, and a little
dangerous in the case of in-place operators. If the type's in-place op ever
returned an object of a different type, a python::string could end up
wrapping some other python type, for example.


> At first sight this looks straight-forward. Do you see major
difficulties?

No, I think it is straightforward... just not the same way you suggested
;-)

-Dave






From david.abrahams at rcn.com  Wed Jun 26 22:29:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 16:29:16 -0400
Subject: [C++-sig] tuple, list, dict, et. al
References: <1aa401c21d0b$8e143550$6601a8c0@boostconsulting.com> <3D19B673.4070901@vintech.bg>
Message-ID: <216401c21d50$3fe0c700$6601a8c0@boostconsulting.com>

From: "Niki Spahiev" <niki at vintech.bg>

> > Answer 2:
> >
> >     The function matches if the actual argument is any Python sequence;
> >     tuple(arg) will be applied to retrieve the tuple object used inside
> >     the wrapped function
>
> When i start with pure python prototype all functions behave like Answer
> 2. If later some of them are replaced with C++ code i expect it to
> behave the same.

But getting that functionality is easy. Just use an argument of type
"object".

-Dave






From david.abrahams at rcn.com  Wed Jun 26 22:30:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 16:30:01 -0400
Subject: [C++-sig] Re: tuple, list, dict, et. al
References: <1aa401c21d0b$8e143550$6601a8c0@boostconsulting.com> <afchb1$q1h$1@main.gmane.org>
Message-ID: <216501c21d50$40101460$6601a8c0@boostconsulting.com>

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

> I vote for having an exact argument match (answer 1). Too many overloads
can
> eventually lead to type matching ambiguity. If the user has a problem
with
> an application because it uses arguments in a particular way they can
easily
> create their own specific wrapper.

OK.

> I'd also go back to an argument I've used before: It is easier to give
than
> take-away. Should it eventually be shown that more liberal matching
really
> is useful then it could be added at a later date.

Please don't hesitate to keep reminding me of that ;-)

-Dave






From hugo at adept.co.za  Thu Jun 27 00:29:29 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Thu, 27 Jun 2002 00:29:29 +0200
Subject: [C++-sig] Another BPLV2 newbie...
In-Reply-To: <1bee01c21d18$5df51a80$6601a8c0@boostconsulting.com>
References: <20020624212623.GA17764@vervet.localnet> <1bee01c21d18$5df51a80$6601a8c0@boostconsulting.com>
Message-ID: <20020626222929.GA7523@vervet.localnet>

> If you need support for more arguments, you can set #define
> BOOST_PYTHON_MAX_ARITY to the number of arguments you need to support. You
> can do this on the compiler command-line with -DBOOST_PYTHON_MAX_ARITY=20

I must rebuild Boost.Python with that parameter I take it. (Just setting
it in my code didn't work. Though it did slow down a simple example from
5 seconds compile time to 10 seconds... so it did *something* ;) I will
try this "tomorrow" (after sleep). (My timezone is "+0200"). For now I
have commented the .def for the one horrible 17 parameter method...

Interesting thing I did notice, even with this commented, I need to pass
gcc a -ftemplate-depth-35 parameter (I'm using GCC 2.95.4.
-ftemplate-depth-34 doesn't work.) I'll do some "trimming" of my code
later to find out exactly what causes this to be required...

> Looks like a missing #include <boost/python/class.hpp> to me.

That's what it was, yes, thanks.

> > I'm worried I might have broken something by trying gen_all.py, but the
> > tests appear to build fine. (I ran
> > $ jam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr
> > in libs/python/test, with BOOST_ROOT set in environment.)
> 
> Don't use "jam"; the executable you want is "bjam" (the name matters).

I ran make in the tools/build/jam_src directory, then I ran
bin.linuxx86/bjam install - this installed a "jam" named binary only,
though it is identical to the "bjam" also in that dir. I realise "bjam"
is to distinguish between boost's jam and the original - I suggest the
tools/build/jam_src/Jamfile be adjusted to install a "bjam"-named binary
by default then instead?

One last thing I will get back to investigating later:

>>> import test_module
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: /home/hugo/Programming/boost/libs/python/bin/libbpl.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/libbpl.so.1.29.0: undefined symbol: PyType_GenericAlloc

Anyone have a tip to lessen the amount of time I'll spend scratching my
head?

Thanks!
Hugo van der Merwe




From casado2 at llnl.gov  Thu Jun 27 00:37:18 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Wed, 26 Jun 2002 15:37:18 -0700
Subject: [C++-sig] Another BPLV2 newbie...
In-Reply-To: <20020626222929.GA7523@vervet.localnet>
References: <20020624212623.GA17764@vervet.localnet> <1bee01c21d18$5df51a80$6601a8c0@boostconsulting.com> <20020626222929.GA7523@vervet.localnet>
Message-ID: <0206261537180P.02424@avalanche.llnl.gov>

On Wednesday 26 June 2002 15:29, you wrote:
> > If you need support for more arguments, you can set #define
> > BOOST_PYTHON_MAX_ARITY to the number of arguments you need to support.
> > You can do this on the compiler command-line with
> > -DBOOST_PYTHON_MAX_ARITY=20
>
> I must rebuild Boost.Python with that parameter I take it. (Just setting
> it in my code didn't work. Though it did slow down a simple example from
> 5 seconds compile time to 10 seconds... so it did *something* ;) I will
> try this "tomorrow" (after sleep). (My timezone is "+0200"). For now I
> have commented the .def for the one horrible 17 parameter method...
>
> Interesting thing I did notice, even with this commented, I need to pass
> gcc a -ftemplate-depth-35 parameter (I'm using GCC 2.95.4.
> -ftemplate-depth-34 doesn't work.) I'll do some "trimming" of my code
> later to find out exactly what causes this to be required...
>
> > Looks like a missing #include <boost/python/class.hpp> to me.
>
> That's what it was, yes, thanks.
>
> > > I'm worried I might have broken something by trying gen_all.py, but the
> > > tests appear to build fine. (I ran
> > > $ jam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr
> > > in libs/python/test, with BOOST_ROOT set in environment.)
> >
> > Don't use "jam"; the executable you want is "bjam" (the name matters).
>
> I ran make in the tools/build/jam_src directory, then I ran
> bin.linuxx86/bjam install - this installed a "jam" named binary only,
> though it is identical to the "bjam" also in that dir. I realise "bjam"
> is to distinguish between boost's jam and the original - I suggest the
> tools/build/jam_src/Jamfile be adjusted to install a "bjam"-named binary
> by default then instead?
>
> One last thing I will get back to investigating later:
> >>> import test_module
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError:
> /home/hugo/Programming/boost/libs/python/bin/libbpl.so/gcc/release/inlining
>-on/runtime-link-dynamic/shared-linkable-true/libbpl.so.1.29.0: undefined
> symbol: PyType_GenericAlloc
>
> Anyone have a tip to lessen the amount of time I'll spend scratching my
> head?
>
> Thanks!
> Hugo van der Merwe
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From casado2 at llnl.gov  Thu Jun 27 00:38:39 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Wed, 26 Jun 2002 15:38:39 -0700
Subject: [C++-sig] Another BPLV2 newbie...
In-Reply-To: <20020626222929.GA7523@vervet.localnet>
References: <20020624212623.GA17764@vervet.localnet> <1bee01c21d18$5df51a80$6601a8c0@boostconsulting.com> <20020626222929.GA7523@vervet.localnet>
Message-ID: <0206261538390Q.02424@avalanche.llnl.gov>

On Wednesday 26 June 2002 15:29, you wrote:
> > If you need support for more arguments, you can set #define
> > BOOST_PYTHON_MAX_ARITY to the number of arguments you need to support.
> > You can do this on the compiler command-line with
> > -DBOOST_PYTHON_MAX_ARITY=20
>
> I must rebuild Boost.Python with that parameter I take it. (Just setting
> it in my code didn't work. Though it did slow down a simple example from
> 5 seconds compile time to 10 seconds... so it did *something* ;) I will
> try this "tomorrow" (after sleep). (My timezone is "+0200"). For now I
> have commented the .def for the one horrible 17 parameter method...
>
> Interesting thing I did notice, even with this commented, I need to pass
> gcc a -ftemplate-depth-35 parameter (I'm using GCC 2.95.4.
> -ftemplate-depth-34 doesn't work.) I'll do some "trimming" of my code
> later to find out exactly what causes this to be required...
>
> > Looks like a missing #include <boost/python/class.hpp> to me.
>
> That's what it was, yes, thanks.
>
> > > I'm worried I might have broken something by trying gen_all.py, but the
> > > tests appear to build fine. (I ran
> > > $ jam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr
> > > in libs/python/test, with BOOST_ROOT set in environment.)
> >
> > Don't use "jam"; the executable you want is "bjam" (the name matters).
>
> I ran make in the tools/build/jam_src directory, then I ran
> bin.linuxx86/bjam install - this installed a "jam" named binary only,
> though it is identical to the "bjam" also in that dir. I realise "bjam"
> is to distinguish between boost's jam and the original - I suggest the
> tools/build/jam_src/Jamfile be adjusted to install a "bjam"-named binary
> by default then instead?
>
> One last thing I will get back to investigating later:
> >>> import test_module
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError:
> /home/hugo/Programming/boost/libs/python/bin/libbpl.so/gcc/release/inlining
>-on/runtime-link-dynamic/shared-linkable-true/libbpl.so.1.29.0: undefined
> symbol: PyType_GenericAlloc
>

seems to me that you are not using python2.2.

        ~~m




From david.abrahams at rcn.com  Thu Jun 27 01:29:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 26 Jun 2002 19:29:40 -0400
Subject: [C++-sig] Another BPLV2 newbie...
References: <20020624212623.GA17764@vervet.localnet> <1bee01c21d18$5df51a80$6601a8c0@boostconsulting.com> <20020626222929.GA7523@vervet.localnet>
Message-ID: <222f01c21d69$6fe5add0$6601a8c0@boostconsulting.com>

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


> > If you need support for more arguments, you can set #define
> > BOOST_PYTHON_MAX_ARITY to the number of arguments you need to support.
You
> > can do this on the compiler command-line
with -DBOOST_PYTHON_MAX_ARITY=20
>
> I must rebuild Boost.Python with that parameter I take it.

Technically yes, but practically speaking, no. There is no C++
implementation I know of where it makes a difference what this parameter is
set to when bpl.so is compiled.

>  (Just setting
> it in my code didn't work. Though it did slow down a simple example from
> 5 seconds compile time to 10 seconds... so it did *something* ;)

So, what /did/ happen?

> I will
> try this "tomorrow" (after sleep). (My timezone is "+0200"). For now I
> have commented the .def for the one horrible 17 parameter method...

We already support 17 arguments by default with GCC; maybe you're having a
different problem.

> Interesting thing I did notice, even with this commented, I need to pass
> gcc a -ftemplate-depth-35 parameter (I'm using GCC 2.95.4.
> -ftemplate-depth-34 doesn't work.)

2.95.4 is not an official release of GCC, FWIW, so I'm not officially
supporting it.

> > Don't use "jam"; the executable you want is "bjam" (the name matters).
>
> I ran make in the tools/build/jam_src directory, then I ran
> bin.linuxx86/bjam install

Where did you get the idea to do that?

> - this installed a "jam" named binary only,
> though it is identical to the "bjam" also in that dir. I realise "bjam"
> is to distinguish between boost's jam and the original - I suggest the
> tools/build/jam_src/Jamfile be adjusted to install a "bjam"-named binary
> by default then instead?

"bjam install" was never a prescribed part of the process...

> One last thing I will get back to investigating later:
>
> >>> import test_module
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError:
/home/hugo/Programming/boost/libs/python/bin/libbpl.so/gcc/release/inlining
-on/runtime-link-dynamic/shared-linkable-true/libbpl.so.1.29.0: undefined
symbol: PyType_GenericAlloc
>
> Anyone have a tip to lessen the amount of time I'll spend scratching my
> head?

Looks like a possible mismatch between the python version you're testing
with and the python version you're building with.

-Dave






From hugo at stonethree.com  Thu Jun 27 10:20:52 2002
From: hugo at stonethree.com (hugo at stonethree.com)
Date: Thu, 27 Jun 2002 10:20:52 +0200 (SAST)
Subject: [C++-sig] Another BPLV2 newbie...
In-Reply-To: <222f01c21d69$6fe5add0$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.30.0206270954310.20212-100000@mondriaan.stonethree.com>

> I must rebuild Boost.Python with that parameter I take it.
>
> Technically yes, but practically speaking, no. There is no C++
> implementation I know of where it makes a difference what this
> parameter is set to when bpl.so is compiled.

OK, I will get back to trying to "debug" this issue tonight.

> >  (Just setting
> > it in my code didn't work. Though it did slow down a simple example from
> > 5 seconds compile time to 10 seconds... so it did *something* ;)
>
> So, what /did/ happen?

Other than slower compilation, I didn't notice any difference. That was
late last night though...

> We already support 17 arguments by default with GCC; maybe you're
> having a different problem.

Its error message was something related to 15. Again, on todo list for
tonight, though I do not really have significant time tonight. Then it
will be tomorrow.

> 2.95.4 is not an official release of GCC, FWIW, so I'm not officially
> supporting it.

OK, I will try other GCC too, I think I may have gcc-3.0.4 on my home
system. (Which is where I am working on this specific wrapper.)

> > I ran make in the tools/build/jam_src directory, then I ran
> > bin.linuxx86/bjam install
>
> Where did you get the idea to do that?

> "bjam install" was never a prescribed part of the process...

I was just "playing" a bit with bjam, wanting to get a "feel" for it, see
how it usually operates. (I am considering using jam for my projects in
the future, was curious about an equivalent to --prefix or DESTDIR= etc.
when using GNU autoconf/automake. I found -sBINDIR ...)

> Looks like a possible mismatch between the python version you're
> testing with and the python version you're building with.

Whoops. I remember now I ran "python" and not "python2.2". I think I
should change my default on that system since I've done this before and
will no doubt be doing it many more times...

Thanks,
Hugo van der Merwe





From david.abrahams at rcn.com  Fri Jun 28 01:55:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 27 Jun 2002 19:55:10 -0400
Subject: [C++-sig] return type of list::index(object const&)
Message-ID: <022001c21e36$6fe96830$6501a8c0@boostconsulting.com>

I have a choice about whether to return python::object or long from this
function and others like it. I'm leaning towards long; anyone want to argue
for object?

-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  Fri Jun 28 16:10:38 2002
From: daveh at cadlink.com (Dave Hawkes)
Date: Fri, 28 Jun 2002 10:10:38 -0400
Subject: [C++-sig] Re: return type of list::index(object const&)
References: <022001c21e36$6fe96830$6501a8c0@boostconsulting.com>
Message-ID: <afhqo7$7dh$1@main.gmane.org>

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:022001c21e36$6fe96830$6501a8c0 at boostconsulting.com...
> I have a choice about whether to return python::object or long from this
> function and others like it. I'm leaning towards long; anyone want to
argue
> for object?
>
This same issue also applies to wrapping many of the API functions. My
thought was that where a simple type can be returned directly, to use it,
rather than construct an object. There will be many instances where the
value is required directly and does not justify the overhead of holding the
value in an object.

Dave Hawkes









From david.abrahams at rcn.com  Fri Jun 28 16:15:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 28 Jun 2002 10:15:29 -0400
Subject: [C++-sig] Re: return type of list::index(object const&)
References: <022001c21e36$6fe96830$6501a8c0@boostconsulting.com> <afhqo7$7dh$1@main.gmane.org>
Message-ID: <04fb01c21eae$480512b0$6501a8c0@boostconsulting.com>

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

> This same issue also applies to wrapping many of the API functions. My
> thought was that where a simple type can be returned directly, to use it,
> rather than construct an object. There will be many instances where the
> value is required directly and does not justify the overhead of holding
the
> value in an object.

The interesting part is that there's no direct 'C' API for list.index(), so
I end up unwrapping a Python int object. However, I sure don't want users
to have to worry about whether there's a direct 'C' API for any given
function!

-Dave






From casado2 at llnl.gov  Fri Jun 28 20:19:58 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Fri, 28 Jun 2002 11:19:58 -0700
Subject: [C++-sig] python sequence to stl container
In-Reply-To: <009901c21e0a$508c1860$6501a8c0@boostconsulting.com>
References: <226901c21d6c$dfc55440$6601a8c0@boostconsulting.com> <0206271141190S.02424@avalanche.llnl.gov> <009901c21e0a$508c1860$6501a8c0@boostconsulting.com>
Message-ID: <0206281119580X.02424@avalanche.llnl.gov>

> ----- Original Message -----
> From: "Martin Casado" <casado2 at llnl.gov>
>
> > > Ralf's version is the one to use, for now. I'm still hoping to get him
>
> to
>
> > > build the one we really want to put in the library...
> >
> > If there is a description for the one you really want to put into the
> > library I can give it a stab..
>
> We've been discussing a version which converts any sequence without going
> through an intermediate tuple. Part of this requires changing the rvalue
> conversion protocol so that the convertible() function is able to do some
> or all of the conversion work, by giving it access to the
> rvalue_from_python_data. In the case of Python sequences, you really have
> to try to do all the conversion as part of the overload resolution step
> since you might not be able to make a second pass over some sequences (e.g.
> input streams).

  Is it not possible to change the rvalue conversion protocol so that
  the check to see if the object is convertible and the conversion
  happen within construct() since it already has access to the
  rvalue_from_python_data?  The problem I suppose is signifying that
  the object is not convertible, using exceptions would almost certainly
  be too slow.  Do you have some ideas about how you were going to go
  about this?

                        ~~m




From david.abrahams at rcn.com  Fri Jun 28 20:50:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 28 Jun 2002 14:50:47 -0400
Subject: [C++-sig] python sequence to stl container
References: <226901c21d6c$dfc55440$6601a8c0@boostconsulting.com> <0206271141190S.02424@avalanche.llnl.gov> <009901c21e0a$508c1860$6501a8c0@boostconsulting.com> <0206281119580X.02424@avalanche.llnl.gov>
Message-ID: <067501c21ed4$b87d88d0$6501a8c0@boostconsulting.com>

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

>   Is it not possible to change the rvalue conversion protocol so that
>   the check to see if the object is convertible and the conversion
>   happen within construct() since it already has access to the
>   rvalue_from_python_data?

That's almost the same thing, but it wouldn't be a good idea. Most
conversions should do just a little work to check for convertibility and
defer all of the actual work until the overload is actually chosen.

> The problem I suppose is signifying that
>   the object is not convertible, using exceptions would almost certainly
>   be too slow.  Do you have some ideas about how you were going to go
>   about this?

Yeah, it's pretty straightforward.

1. from_python_stage1_data would acquire a PyObject* member which would
store the source object

2. The protocol for the convertible() function of rvalue from_python
conversion servers would be to take a pointer to from_python_stage1_data
instead of the PyObject* -- they can retrieve the PyObject* from the data.

3. If they want to they can downcast to rvalue_data<T>* and construct the
result object in-place, returning the pointer to storage to indicate
success

4. As a nice side-effect, the construct() protocol no longer needs a
PyObject* argument, and the protocol for client-side converters' operator()
doesn't, either.

Ready to go and implement it?
If not, I'm happy to trade that for another task...

-Dave






From achim.domma at syynx.de  Sat Jun 29 10:25:01 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 29 Jun 2002 10:25:01 +0200
Subject: [C++-sig] high level overview of boost.python implementation
Message-ID: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de>

Hi Dave,

would it be possible to get a high level overview ot the implementation of
boost.python? (if there's already such a document, I was not able to find
it) You sometimes ask for contributions, especially implementation of not
too complex, straight forward code. Looking at the code, I understand single
pieces, but I do not get the big picture, which is neccessary, if I would
try to contribute (and I would like to contribute, if possible).
I don't ask for more documentation, only a starting point where look, to get
familiar with the code, and the main concepts you are using.

Achim






From david.abrahams at rcn.com  Sat Jun 29 14:19:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 29 Jun 2002 08:19:22 -0400
Subject: [C++-sig] high level overview of boost.python implementation
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de>
Message-ID: <088501c21f67$4fa26310$6501a8c0@boostconsulting.com>

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


> Hi Dave,
>
> would it be possible to get a high level overview ot the implementation
of
> boost.python?

Somebody should write that, at some point.

> (if there's already such a document, I was not able to find
> it)

There is not such a document yet.

> You sometimes ask for contributions, especially implementation of not
> too complex, straight forward code. Looking at the code, I understand
single
> pieces, but I do not get the big picture, which is neccessary, if I would
> try to contribute (and I would like to contribute, if possible).

I'm not sure whether a big-picture view is neccessary for all jobs, but I
appreciate that it can be scary to propose a change without seeing
everything.

> I don't ask for more documentation,

Well, really, you are asking for that <0.2 wink>!

> only a starting point where look, to get
> familiar with the code, and the main concepts you are using.

Suggestion: ask specific questions and write down the answers until the big
picture begins to form in your mind, then write the implementation overview
document yourself and contribute it to the project. I'll be happy to add
corrections, etc. If it's any consolation, I have to do the same thing for
the Python codebase itself at some point ;-)

-Dave






From djowel at gmx.co.uk  Sat Jun 29 19:12:50 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Sun, 30 Jun 2002 01:12:50 +0800
Subject: [C++-sig] high level overview of boost.python implementation
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <088501c21f67$4fa26310$6501a8c0@boostconsulting.com>
Message-ID: <3D1DEA92.6000108@gmx.co.uk>

David Abrahams wrote:

>
>I'm not sure whether a big-picture view is neccessary for all jobs, but I
>appreciate that it can be scary to propose a change without seeing
>everything.
>
>>I don't ask for more documentation,
>>
>
>Well, really, you are asking for that <0.2 wink>!
>
>>only a starting point where look, to get
>>familiar with the code, and the main concepts you are using.
>>
>
>Suggestion: ask specific questions and write down the answers until the big
>picture begins to form in your mind, then write the implementation overview
>document yourself and contribute it to the project. I'll be happy to add
>corrections, etc. If it's any consolation, I have to do the same thing for
>the Python codebase itself at some point ;-)
>

It's difficult to make any promises at this point but I think what I can 
do is
follow this discussion thread more closely (Initiated by Achima of 
course :-)
and take notes. Then from what I gather, I can draft an "inside BPL"
documentation. How does that sound? I think such an initiative will give
me further insights into the library which I *too* really need to have now.

Regards,
--Joel










From achim.domma at syynx.de  Sat Jun 29 19:40:04 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 29 Jun 2002 19:40:04 +0200
Subject: [C++-sig] high level overview of boost.python implementation
In-Reply-To: <3D1DEA92.6000108@gmx.co.uk>
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEBIDIAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Joel de Guzman
> Sent: Saturday, June 29, 2002 19:13
> To: c++-sig at python.org
> Subject: Re: [C++-sig] high level overview of boost.python
> implementation
>
>
> David Abrahams wrote:
> >Suggestion: ask specific questions and write down the answers
> until the big
> >picture begins to form in your mind, then write the
> implementation overview
> >document yourself and contribute it to the project. I'll be happy to add
> >corrections, etc. If it's any consolation, I have to do the same
> thing for
> >the Python codebase itself at some point ;-)
> >
>
> It's difficult to make any promises at this point but I think what I can
> do is
> follow this discussion thread more closely (Initiated by Achima of
> course :-)
> and take notes. Then from what I gather, I can draft an "inside BPL"
> documentation. How does that sound? I think such an initiative will give
> me further insights into the library which I *too* really need to
> have now.

Sounds good to me. I think I will try to use my debugger to step through the
code. This way I usually should get a feeling about how the library works at
all. Doing this, more 'specific questions' will arise, and I will try to
document my progress. Probably its not a bad idea to have this document
written by someone else than David, because his understanding is 'too
complete' perhaps.
I could also make no promisse when this will happen. In fact I should finish
my Diplomarbeit (equal to a master thesis, I think), but boost.python is
much more interesting ... ;-)

Achim






From david.abrahams at rcn.com  Sat Jun 29 19:38:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 29 Jun 2002 13:38:05 -0400
Subject: [C++-sig] high level overview of boost.python implementation
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <088501c21f67$4fa26310$6501a8c0@boostconsulting.com> <3D1DEA92.6000108@gmx.co.uk>
Message-ID: <093401c21f93$c2d2be80$6501a8c0@boostconsulting.com>

From: "Joel de Guzman" <djowel at gmx.co.uk>

> >Suggestion: ask specific questions and write down the answers until the
big
> >picture begins to form in your mind, then write the implementation
overview
> >document yourself and contribute it to the project. I'll be happy to add
> >corrections, etc. If it's any consolation, I have to do the same thing
for
> >the Python codebase itself at some point ;-)
> >
>
> It's difficult to make any promises at this point but I think what I can
> do is
> follow this discussion thread more closely (Initiated by Achima of
> course :-)
> and take notes. Then from what I gather, I can draft an "inside BPL"
> documentation. How does that sound? I think such an initiative will give
> me further insights into the library which I *too* really need to have
now.

Sounds great. I will try to throw you all a clue now and again also.

Here's the first: to_python and from_python conversions used to wrap/unwrap
arguments and return values are built on a client-server architecture. Each
extension module that defines conversions registers them with the converter
registry, which is an associative structure indexed on C++ types. These are
the server-side converters.

When a conversion needs to be performed, client-side converters are used.
Associative registry lookups are all perfomed at static initialization
time, and the results (pointers to the corresponding registry entries) are
stored in static data members of class templates parameterized on the C++
types involved in the conversion. Client-side conversions look in these
static data members to find a registered converter that can do the job
requested.

Some special types use client-side converter specializations. Since there
can be only one way to convert a given C++ type to_python, this works well
for built-ins like int, long, char const*, std::string, et al. Using a
specialization saves the mechanics of indirecting into the converter
registry for common cases. Some other special types (e.g. object and coming
soon: list, tuple et al) have only one reasonable from_python conversion
method, and so use specialization for from_python conversions also.

HTH a little,
Dave








From djowel at gmx.co.uk  Sat Jun 29 19:58:28 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Sun, 30 Jun 2002 01:58:28 +0800
Subject: [C++-sig] high level overview of boost.python implementation
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <088501c21f67$4fa26310$6501a8c0@boostconsulting.com> <3D1DEA92.6000108@gmx.co.uk> <093401c21f93$c2d2be80$6501a8c0@boostconsulting.com>
Message-ID: <3D1DF544.8050405@gmx.co.uk>


David Abrahams wrote:

>
>
>Sounds great. I will try to throw you all a clue now and again also.
>
>Here's the first: to_python and from_python conversions used to wrap/unwrap
>arguments and return values are built on a client-server architecture. Each
>extension module that defines conversions registers them with the converter
>registry, which is an associative structure indexed on C++ types. These are
>the server-side converters.
>
>When a conversion needs to be performed, client-side converters are used.
>Associative registry lookups are all perfomed at static initialization
>time, and the results (pointers to the corresponding registry entries) are
>stored in static data members of class templates parameterized on the C++
>types involved in the conversion. Client-side conversions look in these
>static data members to find a registered converter that can do the job
>requested.
>
>Some special types use client-side converter specializations. Since there
>can be only one way to convert a given C++ type to_python, this works well
>for built-ins like int, long, char const*, std::string, et al. Using a
>specialization saves the mechanics of indirecting into the converter
>registry for common cases. Some other special types (e.g. object and coming
>soon: list, tuple et al) have only one reasonable from_python conversion
>method, and so use specialization for from_python conversions also.
>
Hi,

Great!

Do we have a layer/module diagram(map) of the library? This is a good 
starting
point to get the *big picture*. To make my point clear, for instance 
here's Phoenix's
layer/module diagram:

::Organization

    The framework is organized in five (5) layers.

                     +-----------+
                     |  binders  |
                     +-----------+-----------+------------+
                     | functions | operators | statements |
        +------------+-----------+-----------+------------+
        | primitives |             composite              |
        +------------+------------------------------------+
        |                     actor                       |
        +-------------------------------------------------+
        |                     tuples                      |
        +-------------------------------------------------+

Then, we can proceed bottom-up.

Regards,
--Joel









From david.abrahams at rcn.com  Sat Jun 29 20:15:11 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 29 Jun 2002 14:15:11 -0400
Subject: [C++-sig] high level overview of boost.python implementation
References: <FCEMIEFBFOIDAOJDEPIAOEBEDIAA.achim.domma@syynx.de> <088501c21f67$4fa26310$6501a8c0@boostconsulting.com> <3D1DEA92.6000108@gmx.co.uk> <093401c21f93$c2d2be80$6501a8c0@boostconsulting.com> <3D1DF544.8050405@gmx.co.uk>
Message-ID: <094b01c21f98$e990dbb0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Joel de Guzman" <djowel at gmx.co.uk>

> Great!
>
> Do we have a layer/module diagram(map) of the library?

Nope.

> This is a good
> starting
> point to get the *big picture*.

Agreed.

> To make my point clear, for instance
> here's Phoenix's
> layer/module diagram:
>
> ::Organization
>
>     The framework is organized in five (5) layers.
>
>                      +-----------+
>                      |  binders  |
>                      +-----------+-----------+------------+
>                      | functions | operators | statements |
>         +------------+-----------+-----------+------------+
>         | primitives |             composite              |
>         +------------+------------------------------------+
>         |                     actor                       |
>         +-------------------------------------------------+
>         |                     tuples                      |
>         +-------------------------------------------------+

I'm not sure the library lends itself to this sort of decomposition -- the
dependency graph may be too complicated to lay out in 2d without some arc
crossings -- but I could be wrong.

Let me know how I can help.

> Then, we can proceed bottom-up.

Sounds good to me.

-Dave






From david.abrahams at rcn.com  Sat Jun 29 21:30:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 29 Jun 2002 15:30:29 -0400
Subject: [C++-sig] Boost.Python V2: list implementation
Message-ID: <09b301c21fa3$6f700da0$6501a8c0@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.  This is another of those "fairly
mechanical" tasks with which I would really appreciate having some help.

The interface design follows the following protocol:
I did:

>>> help(list)