From vraghavan at cnmnetwork.com  Fri Aug  2 05:21:12 2002
From: vraghavan at cnmnetwork.com (Srivatsan Raghavan)
Date: Thu, 01 Aug 2002 20:21:12 -0700
Subject: [C++-sig] bjam issue related to boost::python
Message-ID: <3D49FAA8.9000902@cnmnetwork.com>

hi all ,
i created a c++ extension module using python which worked fine..

then i wanted to embed a call to PyRun_SimpleFile in another app,
and the script i was calling is attempting to use my extension module

but i was getting telling me that the interpreter wasn't initialized
after much searching, research, and work with msvc's Dependency Walker
i narrowed it down to the fact that boost_python_debug.dll is trying to link
to the release version of python22.dll , whereas it should be linking to 
python22_d.dll
(which unfortunately does not come with the python installer , that has 
to be compiled manually )

at any rate, how can the boost::python Jamfile be modified to try this 
check when it comes boost::python ?

--vat
==.sig==
Evil requires nothing more to win than that good men do nothing






From dave at boost-consulting.com  Fri Aug  2 15:33:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 2 Aug 2002 09:33:40 -0400
Subject: [C++-sig] bjam issue related to boost::python
References: <3D49FAA8.9000902@cnmnetwork.com>
Message-ID: <05e101c23a2c$82140f80$120a0a0a@boostconsulting.com>

From: "Srivatsan Raghavan" <vraghavan at cnmnetwork.com>


> hi all ,
> i created a c++ extension module using python which worked fine..
>
> then i wanted to embed a call to PyRun_SimpleFile in another app,
> and the script i was calling is attempting to use my extension module
>
> but i was getting telling me that the interpreter wasn't initialized
> after much searching, research, and work with msvc's Dependency Walker
> i narrowed it down to the fact that boost_python_debug.dll is trying to
link
> to the release version of python22.dll , whereas it should be linking to
> python22_d.dll
> (which unfortunately does not come with the python installer , that has
> to be compiled manually )
>
> at any rate, how can the boost::python Jamfile be modified to try this
> check when it comes boost::python ?


Please see the section on "Build Variants" at
www.boost.org/libs/python/doc/building.html#variants
No modification of the Jamfile is needed. If you want a build using the
debug version of the Python DLL, you should be using
    -sBUILD=debug-python

-Dave



-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From mikeowen at llnl.gov  Fri Aug  2 20:21:25 2002
From: mikeowen at llnl.gov (J. Michael Owen)
Date: Fri, 2 Aug 2002 11:21:25 -0700
Subject: [C++-sig] call_back and inheritance
Message-ID: <200208021821.LAA00987@popcorn.llnl.gov>

I'm running into a problem trying to use the call_back class idiom for exposing
virtual functions of classes for overriding from python.  The problem occurs
when I have a class with virtual functions I want to expose this way, which
inherits from another class that also has virtual functions and a corresponding
call_back class to expose its methods.  When I do the obvious thing and write a
call_back class for this derived class, everything compiles OK but I get a
runtime SEGV when I try to use these methods.  I'm including an example code and
python script to exercise the problem -- is this a bug or just user error?

Mike Owen.

-- 
 "Hey...where are the sunflower seeds?" |       J. Michael Owen         
        o_o /                           |       Phone:  925-423-7160     
        (")                             |       Email:  mikeowen at llnl.gov
       \/'\/                            |
____(__(,_,)_______________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callback.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020802/8d459769/attachment.tar>

From vraghavan at cnmnetwork.com  Fri Aug  2 22:13:04 2002
From: vraghavan at cnmnetwork.com (Srivatsan Raghavan)
Date: Fri, 02 Aug 2002 13:13:04 -0700
Subject: [C++-sig] bjam issue related to boost::python
References: <3D49FAA8.9000902@cnmnetwork.com> <05e101c23a2c$82140f80$120a0a0a@boostconsulting.com>
Message-ID: <3D4AE7D0.7040506@cnmnetwork.com>

David Abrahams wrote:

>From: "Srivatsan Raghavan" <vraghavan at cnmnetwork.com>
>
>
>  
>
>>hi all ,
>>i created a c++ extension module using python which worked fine..
>>
>>then i wanted to embed a call to PyRun_SimpleFile in another app,
>>and the script i was calling is attempting to use my extension module
>>
>>but i was getting telling me that the interpreter wasn't initialized
>>after much searching, research, and work with msvc's Dependency Walker
>>i narrowed it down to the fact that boost_python_debug.dll is trying to
>>    
>>
>link
>  
>
>>to the release version of python22.dll , whereas it should be linking to
>>python22_d.dll
>>(which unfortunately does not come with the python installer , that has
>>to be compiled manually )
>>
>>at any rate, how can the boost::python Jamfile be modified to try this
>>check when it comes boost::python ?
>>    
>>
>
>
>Please see the section on "Build Variants" at
>www.boost.org/libs/python/doc/building.html#variants
>No modification of the Jamfile is needed. If you want a build using the
>debug version of the Python DLL, you should be using
>    -sBUILD=debug-python
>
>-Dave
>  
>


thank you kindly for your assistance Dave


--vat
vraghavan at cnmnetwork.com
==.sig==
Evil requires nothing more to win than that good men do nothing





From mikeowen at llnl.gov  Fri Aug  2 22:36:10 2002
From: mikeowen at llnl.gov (J. Michael Owen)
Date: Fri, 2 Aug 2002 13:36:10 -0700
Subject: [C++-sig] call_back and inheritance
Message-ID: <200208022036.NAA20685@popcorn.llnl.gov>

Whoops, looks like the tar archive I used for the example files in my post
didn't travel very well.  Here's the ascii version.

Mike.

------------------------------ C++ source --------------------------------------

#include <iostream>
using namespace std;

// BPL includes.
#include "boost/python/class.hpp"
#include "boost/python/module.hpp"
#include "boost/python/call_method.hpp"
using namespace boost::python;

//------------------------------------------------------------------------------
// Class definitions.
//------------------------------------------------------------------------------
class AbstractBase {
public:
  AbstractBase():
    mInternalValue(-10) {}
  virtual ~AbstractBase() {}
  virtual void pureVirtualMethod() = 0;
  virtual int processValue() = 0;

  void printInternalValue() {
    cout << "AbstractBase::InternalValue = " << mInternalValue << endl;
  }

  void callVirtualMethod() {
    cout << "AbstractBase::callVirtualMethod()" << endl;
    pureVirtualMethod();
  }

  int internalValue() {
    return mInternalValue;
  }

private:
  int mInternalValue;
};

class Derived: public AbstractBase {
public:
  Derived():
    AbstractBase() {}
  virtual ~Derived() {}

  virtual void pureVirtualMethod() {
    cout << "Derived::pureVirtualMethod()" << endl;
    printInternalValue();
  }

  virtual int processValue() {
    cout << "Derived::processValue()" << endl;
    return 2*internalValue();
  }

};

//------------------------------------------------------------------------------
// Call back class to provide BPL overrides for AbstractBase.
//------------------------------------------------------------------------------
class AbstractBaseCallBack: public AbstractBase {
public:
  AbstractBaseCallBack(PyObject *self):
    AbstractBase(),
    mSelf(self) {}

  void pureVirtualMethod() {
    return call_method<void>(mSelf, "pureVirtualMethod");
  }

  int processValue() {
    return call_method<int>(mSelf, "processValue");
  }

private:
  PyObject* mSelf;
};

//------------------------------------------------------------------------------
// Call back class to provide BPL overrides for Derived.
//------------------------------------------------------------------------------
class DerivedCallBack: public Derived {
public:
  DerivedCallBack(PyObject *self):
    Derived(),
    mSelf(self) {}

  void pureVirtualMethod() {
    return call_method<void>(mSelf, "pureVirtualMethod");
  }

  int processValue() {
    return call_method<int>(mSelf, "processValue");
  }

private:
  PyObject* mSelf;
};

// class DerivedCallBack: public Derived, 
//                        public AbstractBaseCallBack {
// public:
//   DerivedCallBack(PyObject *self):
//     Derived(),
//     AbstractBaseCallBack(self),
//     mSelf(self) {}

// private:
//   PyObject* mSelf;
// };

//------------------------------------------------------------------------------
// Helper methods to wrap the classes in this module.
//------------------------------------------------------------------------------
void wrapAbstractBase(module& mod) {
  mod.add(class_<AbstractBase,
 	         boost::shared_ptr<AbstractBaseCallBack>,
                 boost::noncopyable>("AbstractBase")
          .def_init()
          .def("pureVirtualMethod", &AbstractBase::pureVirtualMethod)
          .def("printInternalValue", &AbstractBase::printInternalValue)
          .def("callVirtualMethod", &AbstractBase::callVirtualMethod)
          );
}

void wrapDerived(module& mod) {
    mod.add(class_<Derived,
                   bases<AbstractBase>,
                   boost::shared_ptr<DerivedCallBack>,
                   boost::noncopyable>("Derived")
            .def_init()
            );
}

//------------------------------------------------------------------------------
// The BPL wrapped python module.
//------------------------------------------------------------------------------
BOOST_PYTHON_MODULE_INIT(callback) {

  try {
    module mod("callback");

    // AbstractBase
    wrapAbstractBase(mod);

    // Derived
    wrapDerived(mod);

  } catch(...) {
    handle_exception();
  }

}

--------------------------------- python example -------------------------------

import callback

class overrideAbstract(callback.AbstractBase):
    def __init__(self):
        callback.AbstractBase.__init__(self)
        return

    def pureVirtualMethod(self):
        print "This is python!  overrideAbstact.pureVirtualMethod()"
        return

    def processValue(self):
        print "This is python!  overrideAbstact.processValue()"
        return 10

class overrideDerived(callback.Derived):
    def __init__(self):
        callback.Derived.__init__(self)
        return

    def pureVirtualMethod(self):
        print "This is python!  overrideDerived.pureVirtualMethod()"
        callback.Derived.pureVirtualMethod(self)
        return

a = callback.Derived()
b = overrideAbstract()
c = overrideDerived()

print "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
print type(a)
print a.callVirtualMethod()
print "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
print type(b)
print b.callVirtualMethod()
print "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
print type(c)
print c.callVirtualMethod()
print "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"

-- 
 "Hey...where are the sunflower seeds?" |       J. Michael Owen         
        o_o /                           |       Phone:  925-423-7160     
        (")                             |       Email:  mikeowen at llnl.gov
       \/'\/                            |
____(__(,_,)_______________________________________________________________



From dave at boost-consulting.com  Sat Aug  3 07:21:19 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 3 Aug 2002 01:21:19 -0400
Subject: [C++-sig] call_back and inheritance
References: <200208021821.LAA00987@popcorn.llnl.gov>
Message-ID: <080601c23aad$cfe8aa00$120a0a0a@boostconsulting.com>

Yes, Mike, I'm relieved to report that it's user error ;-)

A pure virtual function with no C++ implementation should be overridden in
the callback class to dispatch to Python via call_method<>, but should
never be exposed to Python with def().  After all, there's not supposed to
be an implementation there. The implementation of pureVirtualMethod you
exposed with def() gets found when you try to call it with call_method<>,
which of course finds the implementation of pureVirtualMethod you exposed
with def(), which you try to call with call_method<>, and so on until you
blow the stack.

I can't really understand why your Derived class is using call_method<>
directly to call pureVirtualMethod recursively on itself. That use of
call_method<> should really be reserved for callback classes.

Note also that the exception-handling stuff in the module init function is
superfluous. That's taken care of for you by the library.

HTH,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "J. Michael Owen" <mikeowen at llnl.gov>
To: <c++-sig at python.org>
Sent: Friday, August 02, 2002 2:21 PM
Subject: [C++-sig] call_back and inheritance


> I'm running into a problem trying to use the call_back class idiom for
exposing
> virtual functions of classes for overriding from python.  The problem
occurs
> when I have a class with virtual functions I want to expose this way,
which
> inherits from another class that also has virtual functions and a
corresponding
> call_back class to expose its methods.  When I do the obvious thing and
write a
> call_back class for this derived class, everything compiles OK but I get
a
> runtime SEGV when I try to use these methods.  I'm including an example
code and
> python script to exercise the problem -- is this a bug or just user
error?
>
> Mike Owen.
>
> --
>  "Hey...where are the sunflower seeds?" |       J. Michael Owen
>         o_o /                           |       Phone:  925-423-7160
>         (")                             |       Email:  mikeowen at llnl.gov
>        \/'\/                            |
>
____(__(,_,)_______________________________________________________________
>




From mikeowen at speakeasy.net  Sat Aug  3 08:46:07 2002
From: mikeowen at speakeasy.net (Mike Owen)
Date: Fri, 2 Aug 2002 23:46:07 -0700
Subject: [C++-sig] call_back and inheritance
Message-ID: <E17asfy-0006U9-00@mail.python.org>

Ah, I see what you're saying, and indeed when I remove the .def() from the 
AbstractBase definitions I can correctly override and use the AbstractBase 
from python.   Cool!

However, I still don't see how I can get the ability to override the method 
again in python classes that inherit from the Derived C++ class.   I seem to 
be having trouble trying to define a call_back class for the Derived class in 
this example, and therefore I have not been able to get a python method to 
override it's methods.  How should we handle the wrapping of Derived so we 
can override it's methods too?

Thanks for the pointers!

Mike.

Here's the modified version of the previous example where I've removed the 
.def for the pure virtual method from AbstractBase call_back again.
#include <iostream>
using namespace std;

// BPL includes.
#include "boost/python/class.hpp"
#include "boost/python/module.hpp"
#include "boost/python/call_method.hpp"
using namespace boost::python;

//------------------------------------------------------------------------------
// Class definitions.
//------------------------------------------------------------------------------
class AbstractBase {
public:
  AbstractBase():
    mInternalValue(-10) {}
  virtual ~AbstractBase() {}
  virtual void pureVirtualMethod() = 0;
  virtual int processValue() = 0;

  void printInternalValue() {
    cout << "AbstractBase::InternalValue = " << mInternalValue << endl;
  }

  void callVirtualMethod() {
    cout << "AbstractBase::callVirtualMethod()" << endl;
    pureVirtualMethod();
  }

  int internalValue() {
    return mInternalValue;
  }

private:
  int mInternalValue;
};

class Derived: public AbstractBase {
public:
  Derived():
    AbstractBase() {}
  virtual ~Derived() {}

  virtual void pureVirtualMethod() {
    cout << "Derived::pureVirtualMethod()" << endl;
    printInternalValue();
  }

  virtual int processValue() {
    cout << "Derived::processValue()" << endl;
    return 2*internalValue();
  }

};

//------------------------------------------------------------------------------
// Call back class to provide BPL overrides for AbstractBase.
//------------------------------------------------------------------------------
class AbstractBaseCallBack: public AbstractBase {
public:
  AbstractBaseCallBack(PyObject *self):
    AbstractBase(),
    mSelf(self) {}

  void pureVirtualMethod() {
    return call_method<void>(mSelf, "pureVirtualMethod");
  }

  int processValue() {
    return call_method<int>(mSelf, "processValue");
  }

private:
  PyObject* mSelf;
};

//------------------------------------------------------------------------------
// Call back class to provide BPL overrides for Derived.
//------------------------------------------------------------------------------
class DerivedCallBack: public Derived {
public:
  DerivedCallBack(PyObject *self):
    Derived(),
    mSelf(self) {}

  void pureVirtualMethod() {
    return call_method<void>(mSelf, "pureVirtualMethod");
  }

  int processValue() {
    return call_method<int>(mSelf, "processValue");
  }

private:
  PyObject* mSelf;
};

// class DerivedCallBack: public Derived, 
//                        public AbstractBaseCallBack {
// public:
//   DerivedCallBack(PyObject *self):
//     Derived(),
//     AbstractBaseCallBack(self) {}
// };

//------------------------------------------------------------------------------
// Helper methods to wrap the classes in this module.
//------------------------------------------------------------------------------
void wrapAbstractBase(module& mod) {
  mod.add(class_<AbstractBase,
 	         boost::shared_ptr<AbstractBaseCallBack>,
                 boost::noncopyable>("AbstractBase")
          .def_init()
          .def("printInternalValue", &AbstractBase::printInternalValue)
          .def("callVirtualMethod", &AbstractBase::callVirtualMethod)
          );
}

void wrapDerived(module& mod) {
    mod.add(class_<Derived,
                   bases<AbstractBase>,
                   boost::shared_ptr<DerivedCallBack>,
                   boost::noncopyable>("Derived")
            .def_init()
            .def("pureVirtualMethod", &AbstractBase::pureVirtualMethod)
            );
}

//------------------------------------------------------------------------------
// The BPL wrapped python module.
//------------------------------------------------------------------------------
BOOST_PYTHON_MODULE_INIT(callback) {
  module mod("callback");

  // AbstractBase
  wrapAbstractBase(mod);
    
  // Derived
  wrapDerived(mod);

}

-- 
 "Hey...where are the sunflower seeds?" |       J. Michael Owen         
        o_o /                           |       Phone:  925-423-7160     
        (")                             |       Email:  mikeowen at llnl.gov
        \/'\/                            |
____(__(,_,)_______________________________________________________________



From dave at boost-consulting.com  Sat Aug  3 14:12:03 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 3 Aug 2002 08:12:03 -0400
Subject: [C++-sig] call_back and inheritance
References: <E17asfy-0006U9-00@mail.python.org>
Message-ID: <082901c23ae6$ff41d9f0$120a0a0a@boostconsulting.com>

From: "Mike Owen" <mikeowen at speakeasy.net>


> Ah, I see what you're saying, and indeed when I remove the .def() from
the
> AbstractBase definitions I can correctly override and use the
AbstractBase
> from python.   Cool!
>
> However, I still don't see how I can get the ability to override the
method
> again in python classes that inherit from the Derived C++ class.


> I seem to
> be having trouble trying to define a call_back class for the Derived
class in
> this example, and therefore I have not been able to get a python method
to
> override it's methods.  How should we handle the wrapping of Derived so
we
> can override it's methods too?


Mike,

Rule #1 of support requests: provide a precise description of what you did,
what results you got, and what results you expected.
I don't see anything here that prevents you from overriding the
"pureVirtualMethod" of Python classes derived from Derived.

OK, looking more closely, I spy this line:

             .def("pureVirtualMethod", &AbstractBase::pureVirtualMethod)

virtual functions should basically never be exposed directly with .def().
If you want to expose the default implementation of a virtual function you
need to write a thin non-virtual wrapper over it, much as described in the
v1 docs (www.boost.org/libs/python/doc/overriding.html). The virtual
function overriding procedure has remained largely unchanged from v1.

HTH2,
Dave

> Thanks for the pointers!
>
> Mike.
>
> Here's the modified version of the previous example where I've removed
the
> .def for the pure virtual method from AbstractBase call_back again.
> #include <iostream>
> using namespace std;
>
> // BPL includes.
> #include "boost/python/class.hpp"
> #include "boost/python/module.hpp"
> #include "boost/python/call_method.hpp"
> using namespace boost::python;
>
>
//-------------------------------------------------------------------------
-----
> // Class definitions.
>
//-------------------------------------------------------------------------
-----
> class AbstractBase {
> public:
>   AbstractBase():
>     mInternalValue(-10) {}
>   virtual ~AbstractBase() {}
>   virtual void pureVirtualMethod() = 0;
>   virtual int processValue() = 0;
>
>   void printInternalValue() {
>     cout << "AbstractBase::InternalValue = " << mInternalValue << endl;
>   }
>
>   void callVirtualMethod() {
>     cout << "AbstractBase::callVirtualMethod()" << endl;
>     pureVirtualMethod();
>   }
>
>   int internalValue() {
>     return mInternalValue;
>   }
>
> private:
>   int mInternalValue;
> };
>
> class Derived: public AbstractBase {
> public:
>   Derived():
>     AbstractBase() {}
>   virtual ~Derived() {}
>
>   virtual void pureVirtualMethod() {
>     cout << "Derived::pureVirtualMethod()" << endl;
>     printInternalValue();
>   }
>
>   virtual int processValue() {
>     cout << "Derived::processValue()" << endl;
>     return 2*internalValue();
>   }
>
> };
>
>
//-------------------------------------------------------------------------
-----
> // Call back class to provide BPL overrides for AbstractBase.
>
//-------------------------------------------------------------------------
-----
> class AbstractBaseCallBack: public AbstractBase {
> public:
>   AbstractBaseCallBack(PyObject *self):
>     AbstractBase(),
>     mSelf(self) {}
>
>   void pureVirtualMethod() {
>     return call_method<void>(mSelf, "pureVirtualMethod");
>   }
>
>   int processValue() {
>     return call_method<int>(mSelf, "processValue");
>   }
>
> private:
>   PyObject* mSelf;
> };
>
>
//-------------------------------------------------------------------------
-----
> // Call back class to provide BPL overrides for Derived.
>
//-------------------------------------------------------------------------
-----
> class DerivedCallBack: public Derived {
> public:
>   DerivedCallBack(PyObject *self):
>     Derived(),
>     mSelf(self) {}
>
>   void pureVirtualMethod() {
>     return call_method<void>(mSelf, "pureVirtualMethod");
>   }
>
>   int processValue() {
>     return call_method<int>(mSelf, "processValue");
>   }
>
> private:
>   PyObject* mSelf;
> };
>
> // class DerivedCallBack: public Derived,
> //                        public AbstractBaseCallBack {
> // public:
> //   DerivedCallBack(PyObject *self):
> //     Derived(),
> //     AbstractBaseCallBack(self) {}
> // };
>
>
//-------------------------------------------------------------------------
-----
> // Helper methods to wrap the classes in this module.
>
//-------------------------------------------------------------------------
-----
> void wrapAbstractBase(module& mod) {
>   mod.add(class_<AbstractBase,
>            boost::shared_ptr<AbstractBaseCallBack>,
>                  boost::noncopyable>("AbstractBase")
>           .def_init()
>           .def("printInternalValue", &AbstractBase::printInternalValue)
>           .def("callVirtualMethod", &AbstractBase::callVirtualMethod)
>           );
> }
>
> void wrapDerived(module& mod) {
>     mod.add(class_<Derived,
>                    bases<AbstractBase>,
>                    boost::shared_ptr<DerivedCallBack>,
>                    boost::noncopyable>("Derived")
>             .def_init()
>             .def("pureVirtualMethod", &AbstractBase::pureVirtualMethod)
>             );
> }
>
>
//-------------------------------------------------------------------------
-----
> // The BPL wrapped python module.
>
//-------------------------------------------------------------------------
-----
> BOOST_PYTHON_MODULE_INIT(callback) {
>   module mod("callback");
>
>   // AbstractBase
>   wrapAbstractBase(mod);
>
>   // Derived
>   wrapDerived(mod);
>
> }






From Paul_Kunz at SLAC.Stanford.EDU  Sat Aug  3 15:50:24 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Sat, 03 Aug 2002 06:50:24 -0700
Subject: [C++-sig] compile problem
References: <20020525144401.10829.66823.Mailman@mail.python.org>
 <000901c204c9$4c3207c0$0100a8c0@albert>
Message-ID: <200208031350.g73DoOu13459@libra3.SLAC.Stanford.EDU>

   The following code...

---
python::ref TClassWrap_instantiate_raw( PyObject * aTuple, PyObject * aDict )
{
  PyObject* self = PyTuple_GetItem(aTuple, 0);
  TClassWrap* cw = BOOST_PYTHON_CONVERSION::from_python( self,python::type<TClassWrap*>());
  PyObject * obj = cw->m_constructor->invoke(aTuple, aDict);
  python::ref r = obj;
  return r;
}
---
does not compile with gcc 3.1.1, but does compile with gcc 2.95.3 and
VC++ 6 sp5.   The gcc 3.1.1 error message is

/usr/local/test/bin/c++ -DHAVE_CONFIG_H -I. -I../../../RootPython/src/RootModule -I../.. -I../../../RootPython -I/usr/local/test/boost -I/usr/local/include/python2.1 -I/usr/local/root/include -g -O2 -Wall -Wp,-MD,.deps/TClassWrap.pp -c ../../../RootPython/src/RootModule/TClassWrap.cpp  -fPIC -DPIC
../../../RootPython/src/RootModule/TClassWrap.cpp: In function 
   `boost::python::ref TClassWrap_instantiate_raw(PyObject*, PyObject*)':
../../../RootPython/src/RootModule/TClassWrap.cpp:57: conversion from `
   PyObject*' to non-scalar type `boost::python::reference<PyObject>' requested

I'm confused.  Any hints?



From Paul_Kunz at SLAC.Stanford.EDU  Sat Aug  3 16:23:39 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Sat, 03 Aug 2002 07:23:39 -0700
Subject: [C++-sig] Re: compile problems
References: <20020525144401.10829.66823.Mailman@mail.python.org>
 <000901c204c9$4c3207c0$0100a8c0@albert>
Message-ID: <200208031423.g73ENdv13534@libra3.SLAC.Stanford.EDU>

Problem solved.   I changed the code to

--
python::ref TClassWrap_instantiate_raw( PyObject * aTuple, PyObject * aDict )
{
  PyObject* self = PyTuple_GetItem(aTuple, 0);
  TClassWrap* cw = BOOST_PYTHON_CONVERSION::from_python( self,python::type<TClassWrap*>());
  PyObject * obj = cw->m_constructor->invoke(aTuple, aDict);
  python::ref r (obj);
  return r;
}
--
Using explict constructor instead of assignment of python::ref did the
trick.



From Tim.Field at mcs.vuw.ac.nz  Sun Aug  4 05:11:13 2002
From: Tim.Field at mcs.vuw.ac.nz (Tim Field)
Date: Sun, 4 Aug 2002 15:11:13 +1200 (NZST)
Subject: [C++-sig] Problem compiling V2 tests.
Message-ID: <Pine.NEB.4.44.0208041450110.13122-100000@avid.mcs.vuw.ac.nz>

Hi there,

I'm having trouble compiling Boost.Python V2 from the current CVS sources
(using GCC 3.1 on a P4 running NetBSD 1.6D).  I downloaded and tried to
compile the sources as per instructions in:

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

While I'm able to compile libbpl.so without any errors, compiling any of
the tests or using it myself gives errors in bases.hpp (which is included
by module.hpp).

For example, if I try compiling this simple file:

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

BOOST_PYTHON_MODULE_INIT(test)
{
    boost::python::module m("test");
}
---

then I get the following output (where I've used [...] to shorten the
lines):

---
g++ -I[...]/boost -I[...]/include/python2.2 -c -o Test.o Test.cpp
In file included from [...]/boost/boost/python/class_fwd.hpp:10,
                 from [...]/boost/boost/python/module.hpp:12,
                 from mine.cpp:1:
[...]/boost/boost/python/bases.hpp:15: parse error before numeric constant
[...]/boost/boost/python/bases.hpp:20: Internal compiler error in
           resume_binding_level, at cp/decl.c:614
Please submit a full bug report, with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake: *** [Test.o] Error 1
---

The preprocessor gives the following output for bases.hpp:

---
namespace boost { namespace python {

  template<typename 0 = ::boost::mpl::null_argument,
           typename B1 = ::boost::mpl::null_argument,
           typename B2 = ::boost::mpl::null_argument,
           [...]
           typename B14 = ::boost::mpl::null_argument>

  struct bases : ::boost::mpl::type_list<0, B1, B2, [...], B14>::type {};

  namespace detail
  {
    template <class T> struct specifies_bases
    {
        static const bool value = false;
    };
    template <class 0, class B1, class B2, [...], class B14>
    struct specifies_bases<bases<0, B1, B2, [...], B14> >
    {
        static const bool value = true;
    };

  [...]
---

Obviously '0' isn't a valid typename, which is causing the error.  It
seems as though bases.hpp exists in two different versions in CVS
(with a different one under the mpl_v2 branch) but I'm not knowledgeable
enough with CVS to work out which versions I need, or how to get them.

Help... please... anyone? :)


Thanks in advance,
Tim (very much looking forward to the release of v2)




From dave at boost-consulting.com  Sun Aug  4 05:43:27 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 3 Aug 2002 23:43:27 -0400
Subject: [C++-sig] Problem compiling V2 tests.
References: <Pine.NEB.4.44.0208041450110.13122-100000@avid.mcs.vuw.ac.nz>
Message-ID: <009301c23b69$197de0c0$62a6accf@boostconsulting.com>

[Paul, this guy is reporting some strange PP behavior on a particular build
of GCC -- any clues?]

Hi Tim,

From: "Tim Field" <Tim.Field at mcs.vuw.ac.nz>


> Hi there,
>
> I'm having trouble compiling Boost.Python V2 from the current CVS sources
> (using GCC 3.1 on a P4 running NetBSD 1.6D).  I downloaded and tried to
> compile the sources as per instructions in:
>
>     http://mail.python.org/pipermail/c++-sig/2002-May/001100.html
>
> While I'm able to compile libbpl.so without any errors, compiling any of
> the tests or using it myself gives errors in bases.hpp (which is included
> by module.hpp).
>
> For example, if I try compiling this simple file:
>
> ---
> #include <boost/python/module.hpp>
>
> BOOST_PYTHON_MODULE_INIT(test)
> {
>     boost::python::module m("test");
> }
> ---
>
> then I get the following output (where I've used [...] to shorten the
> lines):
>
> ---
> g++ -I[...]/boost -I[...]/include/python2.2 -c -o Test.o Test.cpp
> In file included from [...]/boost/boost/python/class_fwd.hpp:10,
>                  from [...]/boost/boost/python/module.hpp:12,
>                  from mine.cpp:1:
> [...]/boost/boost/python/bases.hpp:15: parse error before numeric
constant
> [...]/boost/boost/python/bases.hpp:20: Internal compiler error in
>            resume_binding_level, at cp/decl.c:614
> Please submit a full bug report, with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> gmake: *** [Test.o] Error 1

The fact that there's an internal compiler error should be a pretty strong
hint that this is a bug in your compiler. Since I test with GCC 3.1
regularly on at least 2 platforms, this is a bug in your particular GCC 3.1
configuration, specifically in the preprocessor.

> ---
>
> The preprocessor gives the following output for bases.hpp:
>
> ---
> namespace boost { namespace python {
>
>   template<typename 0 = ::boost::mpl::null_argument,
>            typename B1 = ::boost::mpl::null_argument,
>            typename B2 = ::boost::mpl::null_argument,
>            [...]
>            typename B14 = ::boost::mpl::null_argument>
>
>   struct bases : ::boost::mpl::type_list<0, B1, B2, [...], B14>::type {};


Yep, you've got a preprocessor bug. That should be "typename B0 = ..."
I suggest (strongly!) that you report the bug as specified by the error
message, then consider ways to rebuild your preprocessor or compiler which
might work around the problem.

>   namespace detail
>   {
>     template <class T> struct specifies_bases
>     {
>         static const bool value = false;
>     };
>     template <class 0, class B1, class B2, [...], class B14>
>     struct specifies_bases<bases<0, B1, B2, [...], B14> >
>     {
>         static const bool value = true;
>     };
>
>   [...]
> ---
>
> Obviously '0' isn't a valid typename, which is causing the error.  It
> seems as though bases.hpp exists in two different versions in CVS
> (with a different one under the mpl_v2 branch) but I'm not knowledgeable
> enough with CVS to work out which versions I need, or how to get them.

You don't need any branch versions of anything other than the
mpl-development branch of boost/mpl as specified in the message you linked
to.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Sun Aug  4 15:15:03 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 4 Aug 2002 09:15:03 -0400
Subject: [C++-sig] Problem compiling V2 tests.
References: <Pine.NEB.4.44.0208041450110.13122-100000@avid.mcs.vuw.ac.nz> <009301c23b69$197de0c0$62a6accf@boostconsulting.com>
Message-ID: <00cd01c23bb8$f360e4f0$62a6accf@boostconsulting.com>

From: "David Abrahams" <dave at boost-consulting.com>



> The fact that there's an internal compiler error should be a pretty
strong
> hint that this is a bug in your compiler. Since I test with GCC 3.1
> regularly on at least 2 platforms, this is a bug in your particular GCC
3.1
> configuration, specifically in the preprocessor.
> > ---
> >
> > The preprocessor gives the following output for bases.hpp:
> >
> > ---
> > namespace boost { namespace python {
> >
> >   template<typename 0 = ::boost::mpl::null_argument,
> >            typename B1 = ::boost::mpl::null_argument,
> >            typename B2 = ::boost::mpl::null_argument,
> >            [...]
> >            typename B14 = ::boost::mpl::null_argument>
> >
> >   struct bases : ::boost::mpl::type_list<0, B1, B2, [...], B14>::type
{};
>
>
> Yep, you've got a preprocessor bug. That should be "typename B0 = ..."
> I suggest (strongly!) that you report the bug as specified by the error
> message, then consider ways to rebuild your preprocessor or compiler
which
> might work around the problem.

Paul (the preprocessor library guru) suggested a much more obvious
explanation: that you have

#define B0 0

somewhere in your translation unit
You might try adding #undef B0 somewhere near the top of bases.hpp, but
after its dependent #includes.

HTH,
Dave

P.S. You should still report the ICE, even if this fixes it!

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From Tim.Field at mcs.vuw.ac.nz  Mon Aug  5 01:14:42 2002
From: Tim.Field at mcs.vuw.ac.nz (Tim Field)
Date: Mon, 5 Aug 2002 11:14:42 +1200 (NZST)
Subject: [C++-sig] Problem compiling V2 tests.
Message-ID: <Pine.NEB.4.44.0208051105210.14714-100000@avid.mcs.vuw.ac.nz>

> Paul (the preprocessor library guru) suggested a much more obvious
> explanation: that you have
>
> #define B0 0
>
> somewhere in your translation unit
> You might try adding #undef B0 somewhere near the top of bases.hpp, but
> after its dependent #includes.

Yup, that was the problem -- it was already defined! (can't think where
tho...)

> HTH,
> Dave
>
> P.S. You should still report the ICE, even if this fixes it!

Will do.  (first I'll try upgrading to the latest gcc because I'm pretty
sure I was using a CVS snapshot rather than the official 3.1 release)

Thanks for your help guys.


Cheers,
Tim




From gathmann at cenix-bioscience.com  Mon Aug  5 17:21:12 2002
From: gathmann at cenix-bioscience.com (F. Oliver Gathmann)
Date: Mon, 05 Aug 2002 17:21:12 +0200
Subject: [C++-sig] baffling memory leak with libboost 1.29.0
Message-ID: <3D4E97E8.7010007@cenix-bioscience.com>

I have a beginner's question concerning the return of smart pointers
to Python; please let me know if I am off-topic with this.

Consider the following code adapted from the "getting_started2.cpp"
sample in the boost distribution:

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

#include <memory>
#include <iostream>
#include <string>
#include <boost/python/objects.hpp>
#include <boost/python/class_builder.hpp>


namespace example {

  class hello
  {
    public:
      hello(const std::string& country) { this->country = country; }
      std::string greet() const { return "Hello from " + country; }
    private:
      std::string country;
  };

  std::auto_ptr<hello> get_as_pointer(const std::string& country)
  {
    std::auto_ptr<hello> p(new hello(country));
    return p;
  }

  // forward declaration:
  PyObject * get_as_pyobject(const std::string& country);

}

namespace python = boost::python;
using namespace example;

BOOST_PYTHON_MODULE_INIT(boostexample)
{
    // Create an object representing this extension module.
    python::module_builder this_module("boostexample");

    // Create the Python type object for our extension class.
    python::class_builder<hello> hello_class(this_module, "hello");

    // Add the __init__ function.
    hello_class.def(python::constructor<std::string>());
    // Add a regular member function.
    hello_class.def(&hello::greet, "greet");

    this_module.def(get_as_pointer, "get_as_pointer");
    this_module.def(get_as_pyobject, "get_as_pyobject");

}

namespace example {

  PyObject * get_as_pyobject(const std::string& country)
  {
    std::auto_ptr<hello> p(new hello(country));
    return BOOST_PYTHON_CONVERSION::to_python(p);
  }

}

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

Now, while both calls to get_as_pointer() and get_as_pyobject() will
return a "hello" instance as expected, get_as_pyobject() leaks memory
while get_as_pointer() doesn't. This is particularly surprizing as I
thought that if I return a smart pointer p directly (as this is done
in get_as_pointer()), the library just calls to_python(p) internally,
which is exactly what I am doing in get_as_pyobject(). Can anybody
explain to me what I am doing wrong here?

Any help is much appreciated,

Oliver

--------------------------
F. Oliver Gathmann, Ph.D.
Cenix BioScience GmbH
Pfotenhauer Strasse 108
D-01307 Dresden, Germany
phone: +49 (351) 210-2735
fax:   +49 (351) 210-1309
--------------------------





From david at drysdale-wilson.com  Mon Aug  5 22:03:42 2002
From: david at drysdale-wilson.com (David GD Wilson)
Date: Mon, 5 Aug 2002 21:03:42 +0100
Subject: [C++-sig] python error when running release build
Message-ID: <000001c23cbb$32b6d8f0$152ca8c0@tunguska>

Hi,

I have a simple 3D vector class that exposes some operators and member
variables to python.

I compile my vector dll in debug mode and everything behaves as
expected:

>>> a = core.CVector()
>>> a
<core.CVector object at 0x00877428>
>>> a.x
0.0

However when I compile my vector dll in release mode python comes back
with the following when I try to access any of the member variables or
operators:

>>> a = core.CVector()
>>> a
<core.CVector object at 0x008A4118>
>>> a.x
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation

I am using boost.python v2, and VC.NET. Is there any know issue that I
am unaware of that effects release builds with boost.python v2?

Any help much appreciated :)

David




From vraghavan at cnmnetwork.com  Mon Aug  5 22:14:42 2002
From: vraghavan at cnmnetwork.com (Srivatsan Raghavan)
Date: Mon, 05 Aug 2002 13:14:42 -0700
Subject: [C++-sig] continuing problems with bpl  & jam
Message-ID: <3D4EDCB2.3080409@cnmnetwork.com>

after taking dave's earlier info and recompiling using the 
-sBUILD="debug-python" option
i again tried linking to boost_python_pydebug.lib
but was still getting the runtime error saying that it can't find 
boost_python.dll (which it shouldnt' since only boost_python_pydebug.dll 
is in the path) ..
for a while i couldnt' figure out what my problems where.. i was *ONLY* 
linking to the pydebug version
eventually i looked at boost_python_pydebug.lib in gvim, and it appears 
that the stub is pointing to boost_python.dll , why is this?
my reasoning was cause of how jam works..
it does all the building and linking in different directories and giving 
all the various versions (debug python, debug and release) the *SAME* 
name in their individual directories..
then doing a copy & rename of the file.. so that the lib's are still 
pointing their local version of boost_python.dll but in the \bin-stage 
directory, that would be the release version ..
here is a graphical explanation

python\build
    bin
        boost_pythondll
            msvc
                debug\runtime-link-dynamic
                        boost_python.lib & boost_python.dll
   
                debug-python\runtime-link-dynamic
                    boost_python.lib & boost_python.dll

                release\runtime-link-dynamic
                    boost_python.lib & boost_python.dll
    bin-stage
        boost_python.dll
        boost_python_debug.dll
        boost_python_pydebug.dll      
        #all of these files point to boost_python.dll
        boost_python.lib
        boost_python_debug.lib
        boost_python_pydebug.lib



is this problem fixable? and how?





From dave at boost-consulting.com  Mon Aug  5 22:25:24 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 5 Aug 2002 16:25:24 -0400
Subject: [C++-sig] python error when running release build
References: <000001c23cbb$32b6d8f0$152ca8c0@tunguska>
Message-ID: <00dd01c23cbf$0384a540$62f0fc0c@boostconsulting.com>

We just discovered this VC7 bug which causes static intializers to be
"optimized away" illegally.
We're working on a workaround. In the meantime, you can link your release
builds with:

    /link /opt:noref

If you're using bjam, add <linkflags>-link <linkflags>-opt:noref to your
BUILD variable.

    bjam -sBUILD="release <linkflags>-opt:noref" ...

HTH,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "David GD Wilson" <david at drysdale-wilson.com>
To: <c++-sig at python.org>
Sent: Monday, August 05, 2002 4:03 PM
Subject: [C++-sig] python error when running release build


> Hi,
>
> I have a simple 3D vector class that exposes some operators and member
> variables to python.
>
> I compile my vector dll in debug mode and everything behaves as
> expected:
>
> >>> a = core.CVector()
> >>> a
> <core.CVector object at 0x00877428>
> >>> a.x
> 0.0
>
> However when I compile my vector dll in release mode python comes back
> with the following when I try to access any of the member variables or
> operators:
>
> >>> a = core.CVector()
> >>> a
> <core.CVector object at 0x008A4118>
> >>> a.x
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
>
> I am using boost.python v2, and VC.NET. Is there any know issue that I
> am unaware of that effects release builds with boost.python v2?
>
> Any help much appreciated :)
>
> David
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From dave at boost-consulting.com  Mon Aug  5 23:54:53 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 5 Aug 2002 17:54:53 -0400
Subject: [C++-sig] python error when running release build
References: <000001c23cbb$32b6d8f0$152ca8c0@tunguska> <00dd01c23cbf$0384a540$62f0fc0c@boostconsulting.com>
Message-ID: <014d01c23cca$c630ea30$62f0fc0c@boostconsulting.com>

OK, a vc7 workaround is now checked into CVS.

HTH,
Dave
-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Monday, August 05, 2002 4:25 PM
Subject: Re: [C++-sig] python error when running release build


> We just discovered this VC7 bug which causes static intializers to be
> "optimized away" illegally.
> We're working on a workaround. In the meantime, you can link your release
> builds with:
>
>     /link /opt:noref
>
> If you're using bjam, add <linkflags>-link <linkflags>-opt:noref to your
> BUILD variable.
>
>     bjam -sBUILD="release <linkflags>-opt:noref" ...
>
> ----- Original Message -----
> From: "David GD Wilson" <david at drysdale-wilson.com>
>
> > Hi,
> >
> > I have a simple 3D vector class that exposes some operators and member
> > variables to python.
> >
> > I compile my vector dll in debug mode and everything behaves as
> > expected:
> >
> > >>> a = core.CVector()
> > >>> a
> > <core.CVector object at 0x00877428>
> > >>> a.x
> > 0.0
> >
> > However when I compile my vector dll in release mode python comes back
> > with the following when I try to access any of the member variables or
> > operators:
> >





From grafik666 at redshift-software.com  Tue Aug  6 00:26:09 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon,  5 Aug 2002 17:26:09 -0500
Subject: Fw: [C++-sig] continuing problems with bpl  & jam
In-Reply-To: <014c01c23cca$c5bfd8e0$62f0fc0c@boostconsulting.com>
Message-ID: <20020805172610-r01010800-c386e092-0860-0108@12.100.89.43>

[2002-08-05] David Abrahams wrote:

>Rene, can you comment on this?
>
>Many thanks,
>Dave
>
>-----------------------------------------------------------
>           David Abrahams * Boost Consulting
>dave at boost-consulting.com * http://www.boost-consulting.com
>
>
>----- Original Message -----
>From: "Srivatsan Raghavan" <vraghavan at cnmnetwork.com>
>To: <c++-sig at python.org>
>Sent: Monday, August 05, 2002 4:14 PM
>Subject: [C++-sig] continuing problems with bpl & jam
>
>
>> after taking dave's earlier info and recompiling using the
>> -sBUILD="debug-python" option
>> i again tried linking to boost_python_pydebug.lib
>> but was still getting the runtime error saying that it can't find
>> boost_python.dll (which it shouldnt' since only boost_python_pydebug.dll
>> is in the path) ..
>> for a while i couldnt' figure out what my problems where.. i was *ONLY*
>> linking to the pydebug version
>> eventually i looked at boost_python_pydebug.lib in gvim, and it appears
>> that the stub is pointing to boost_python.dll , why is this?
>> my reasoning was cause of how jam works..
>> it does all the building and linking in different directories and giving
>> all the various versions (debug python, debug and release) the *SAME*
>> name in their individual directories..
>> then doing a copy & rename of the file.. so that the lib's are still
>> pointing their local version of boost_python.dll but in the \bin-stage
>> directory, that would be the release version ..
>> here is a graphical explanation
>>
>> python\build
>>     bin
>>         boost_pythondll
>>             msvc
>>                 debug\runtime-link-dynamic
>>                         boost_python.lib & boost_python.dll
>>
>>                 debug-python\runtime-link-dynamic
>>                     boost_python.lib & boost_python.dll
>>
>>                 release\runtime-link-dynamic
>>                     boost_python.lib & boost_python.dll
>>     bin-stage
>>         boost_python.dll
>>         boost_python_debug.dll
>>         boost_python_pydebug.dll
>>         #all of these files point to boost_python.dll
>>         boost_python.lib
>>         boost_python_debug.lib
>>         boost_python_pydebug.lib
>>
>>
>>
>> is this problem fixable? and how?

It's a known problem, but I've avoided fixing it until Boost.Build V2 is
out. The plan was to account for this situation directly in V2 as opposed to
trying to hack around it in V1.

Fixing it is a bit entertaining and there are two options I know of... the
first involves adding the renaming that the "stage" target does to happen
before things get moved into the stage so that the above would generate:

python\build\bin\boost_python_pydebug.dll\msvc\debug-python\runtime-link-dynamic
    boost_python_pydebug.lib & *.dll

The other option is to regenerate the *.lib files when they are moved to the
stage. This would involve creating a new target type to invoke IMPLIB (I
think that's the vc tool?).

Doing the second is more of a hack but it's something other people (other
than me :-) can do.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From dave at boost-consulting.com  Tue Aug  6 05:11:08 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 5 Aug 2002 23:11:08 -0400
Subject: Fw: [C++-sig] continuing problems with bpl  & jam
References: <20020805172610-r01010800-c386e092-0860-0108@12.100.89.43>
Message-ID: <018901c23cf6$ff7c41f0$62f0fc0c@boostconsulting.com>

From: "Rene Rivera" <grafik666 at redshift-software.com>


> >> is this problem fixable? and how?
>
> It's a known problem, but I've avoided fixing it until Boost.Build V2 is
> out. The plan was to account for this situation directly in V2 as opposed
to
> trying to hack around it in V1.
>
> Fixing it is a bit entertaining and there are two options I know of...
the
> first involves adding the renaming that the "stage" target does to happen
> before things get moved into the stage so that the above would generate:
>
>
python\build\bin\boost_python_pydebug.dll\msvc\debug-python\runtime-link-dy
namic
>     boost_python_pydebug.lib & *.dll
>
> The other option is to regenerate the *.lib files when they are moved to
the
> stage. This would involve creating a new target type to invoke IMPLIB (I
> think that's the vc tool?).
>
> Doing the second is more of a hack but it's something other people (other
> than me :-) can do.

Well, that's the long answer about fixing the "stage" rule. The short and
expedient answer is that if you are willing to keep the versions of bpl.dll
in separate directories, there doesn't have to be a problem. In fact, if
you build and test extensions with Boost.Build using the first method
described at www.boost.org/libs/python/doc/building.html, that's what
happens automatically. All the versions of the library actually have the
same name, and the "stage" rule is just renaming them.

HTH,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Tue Aug  6 17:43:12 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Aug 2002 08:43:12 -0700 (PDT)
Subject: [C++-sig] baffling memory leak with libboost 1.29.0
In-Reply-To: <3D4E97E8.7010007@cenix-bioscience.com>
Message-ID: <20020806154312.25669.qmail@web20208.mail.yahoo.com>

--- "F. Oliver Gathmann" <gathmann at cenix-bioscience.com> wrote:
>   PyObject * get_as_pyobject(const std::string& country)
>   {
>     std::auto_ptr<hello> p(new hello(country));
>     return BOOST_PYTHON_CONVERSION::to_python(p);
>   }
> 
> }
> 
> ------------------------------------------------------------------------
> 
> Now, while both calls to get_as_pointer() and get_as_pyobject() will
> return a "hello" instance as expected, get_as_pyobject() leaks memory
> while get_as_pointer() doesn't. This is particularly surprizing as I
> thought that if I return a smart pointer p directly (as this is done
> in get_as_pointer()), the library just calls to_python(p) internally,
> which is exactly what I am doing in get_as_pyobject(). Can anybody
> explain to me what I am doing wrong here?

If you have your function return a boost::python::ref the memory leak will most
likely go away. I think you can do it like this (untested):

   boost::python::ref get_as_pyobject(const std::string& country)
   {
     std::auto_ptr<hello> p(new hello(country));
     return boost::python::make_ref(p);
   }

Ralf

P.S.: This is an old known problem that never got resolved. It is not an issue
anymore in the upcoming V2 release.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



From enrico at fnal.gov  Tue Aug  6 23:41:46 2002
From: enrico at fnal.gov (Enrico Ng)
Date: Tue, 06 Aug 2002 16:41:46 -0500
Subject: [C++-sig] non-const arguments
Message-ID: <008601c23d92$10164650$9912e183@fnal.gov>

I am new to boost and am attepting to use V2.

I get the "TypeError: bad argument type for built-in operation" error
message from python.  It seems that since the variable "idum" is not
const and changes, python can't handle it.

I have looked around your documentation and the copy_non_cost_reference
class seems close to what I need but I am not sure.

Here is some of the relavent code:

class MathLib {
  public:
  static Real ran1(Integer &idum);   <- idum is modified
};

==============================================

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

namespace python = boost::python;

BOOST_PYTHON_MODULE_INIT(mathlib)
{
   python::module("mathlib")
   .def("ran1", &MathLib::ran1)
   ;
}




From dave at boost-consulting.com  Tue Aug  6 23:54:11 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 6 Aug 2002 17:54:11 -0400
Subject: [C++-sig] non-const arguments
References: <008601c23d92$10164650$9912e183@fnal.gov>
Message-ID: <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com>

What is the definition of Integer?

if it's

    typedef X Integer;

Where X is some builtin numeric type, well of course you can't publish that
interface in Python. All of the builtin numeric types are immutable.

Decide on a Python interface that's consistent with Python's immutability
restrictions, and we can see how to wrap it.

Perhaps

    tuple ran1(Integer x)

would work better for you?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Enrico Ng" <enrico at fnal.gov>
To: <c++-sig at python.org>
Sent: Tuesday, August 06, 2002 5:41 PM
Subject: [C++-sig] non-const arguments


> I am new to boost and am attepting to use V2.
>
> I get the "TypeError: bad argument type for built-in operation" error
> message from python.  It seems that since the variable "idum" is not
> const and changes, python can't handle it.
>
> I have looked around your documentation and the copy_non_cost_reference
> class seems close to what I need but I am not sure.
>
> Here is some of the relavent code:
>
> class MathLib {
>   public:
>   static Real ran1(Integer &idum);   <- idum is modified
> };
>
> ==============================================
>
> #include <boost/python/class.hpp>
> #include <boost/python/module.hpp>
>
> namespace python = boost::python;
>
> BOOST_PYTHON_MODULE_INIT(mathlib)
> {
>    python::module("mathlib")
>    .def("ran1", &MathLib::ran1)
>    ;
> }
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From dave at boost-consulting.com  Wed Aug  7 01:49:02 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 6 Aug 2002 19:49:02 -0400
Subject: [C++-sig] Boost.Python v2: More interface-breaking changes
Message-ID: <061201c23da3$e98dc0a0$62f0fc0c@boostconsulting.com>

More of the interface has been changed to use object instead of handle<>,
as part of the work on docstring support.
Major changes:

* object(f), where f is a function pointer now works. Returning a
  function pointer from a function should work also.
* make_function/make_constructor now return object instead of a raw
pointer.
* module::setattr() now accepts anything which can be passed to object's
constructor.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From gathmann at cenix-bioscience.com  Wed Aug  7 09:59:16 2002
From: gathmann at cenix-bioscience.com (F. Oliver Gathmann)
Date: Wed, 07 Aug 2002 09:59:16 +0200
Subject: [C++-sig] baffling memory leak with libboost 1.29.0
Message-ID: <3D50D354.809@cenix-bioscience.com>

Ralf W. Grosse-Kunstleve wrote:

>--- "F. Oliver Gathmann" <gathmann at cenix-bioscience.com> wrote:
>>   PyObject * get_as_pyobject(const std::string& country)
>>   {
>>     std::auto_ptr<hello> p(new hello(country));
>>     return BOOST_PYTHON_CONVERSION::to_python(p);
>>   }
>> 
>> }
>> 
>> ------------------------------------------------------------------------
>> 
>> Now, while both calls to get_as_pointer() and get_as_pyobject() will
>> return a "hello" instance as expected, get_as_pyobject() leaks memory
>> while get_as_pointer() doesn't. This is particularly surprizing as I
>> thought that if I return a smart pointer p directly (as this is done
>> in get_as_pointer()), the library just calls to_python(p) internally,
>> which is exactly what I am doing in get_as_pyobject(). Can anybody
>> explain to me what I am doing wrong here?
>
>If you have your function return a boost::python::ref the memory leak will most
>likely go away. I think you can do it like this (untested):
>
>   boost::python::ref get_as_pyobject(const std::string& country)
>   {
>     std::auto_ptr<hello> p(new hello(country));
>     return boost::python::make_ref(p);
>   }
>
>
>
>Ralf
>
>P.S.: This is an old known problem that never got resolved. It is not an issue
>anymore in the upcoming V2 relelease.
>
Yes, this worked, although I had to use
        boost::python::ref(boost::python::to_python(p)),
as make_ref() expects a const object.

Thank you so much - I was losing my last hair over this...

I will try the V2 release in due course.

Oliver

--------------------------
F. Oliver Gathmann, Ph.D.
Cenix BioScience GmbH
Pfotenhauer Strasse 108
D-01307 Dresden, Germany
phone: +49 (351) 210-2735
fax:   +49 (351) 210-1309
--------------------------






From dave at boost-consulting.com  Thu Aug  8 00:49:15 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 7 Aug 2002 18:49:15 -0400
Subject: [C++-sig] Boost.Python v2: full docstring support
Message-ID: <0a9101c23e64$a9ee65a0$62f0fc0c@boostconsulting.com>

I have just checked in full support for docstrings. See
libs/python/test/docstring.[cpp/py] for examples.

Cheers,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From dave at boost-consulting.com  Thu Aug  8 01:37:57 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 7 Aug 2002 19:37:57 -0400
Subject: [C++-sig] status of exceptions and new-style classes
Message-ID: <0b8d01c23e6b$76677670$62f0fc0c@boostconsulting.com>

Hello,

What's the current status of the requirement that exceptions be old-style
classes?

I am implementing C++-to-python exception translation for Boost.Python, and
I'd love to be able to tell people that they can throw extension classes
they've created...

TIA,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From enrico at fnal.gov  Thu Aug  8 16:27:24 2002
From: enrico at fnal.gov (Enrico Ng)
Date: Thu, 08 Aug 2002 09:27:24 -0500
Subject: [C++-sig] non-const arguments
References: <008601c23d92$10164650$9912e183@fnal.gov>
 <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com>
Message-ID: <017301c23ee7$b6edcb00$9912e183@fnal.gov>

It is an int.
----- Original Message -----
From: "David Abrahams" <dave at boost-consulting.com>
To: "pysig" <c++-sig at python.org>
Sent: Tuesday, August 06, 2002 4:54 PM
Subject: Re: [C++-sig] non-const arguments


> What is the definition of Integer?
>
> if it's
>
>     typedef X Integer;
>
> Where X is some builtin numeric type, well of course you can't publish
that
> interface in Python. All of the builtin numeric types are immutable.
>
> Decide on a Python interface that's consistent with Python's
immutability
> restrictions, and we can see how to wrap it.
>
> Perhaps
>
>     tuple ran1(Integer x)
>
> would work better for you?
>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
> ----- Original Message -----
> From: "Enrico Ng" <enrico at fnal.gov>
> To: <c++-sig at python.org>
> Sent: Tuesday, August 06, 2002 5:41 PM
> Subject: [C++-sig] non-const arguments
>
>
> > I am new to boost and am attepting to use V2.
> >
> > I get the "TypeError: bad argument type for built-in operation"
error
> > message from python.  It seems that since the variable "idum" is not
> > const and changes, python can't handle it.
> >
> > I have looked around your documentation and the
copy_non_cost_reference
> > class seems close to what I need but I am not sure.
> >
> > Here is some of the relavent code:
> >
> > class MathLib {
> >   public:
> >   static Real ran1(Integer &idum);   <- idum is modified
> > };
> >
> > ==============================================
> >
> > #include <boost/python/class.hpp>
> > #include <boost/python/module.hpp>
> >
> > namespace python = boost::python;
> >
> > BOOST_PYTHON_MODULE_INIT(mathlib)
> > {
> >    python::module("mathlib")
> >    .def("ran1", &MathLib::ran1)
> >    ;
> > }
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From enrico at fnal.gov  Thu Aug  8 21:10:01 2002
From: enrico at fnal.gov (Enrico Ng)
Date: Thu, 08 Aug 2002 14:10:01 -0500
Subject: [C++-sig] problems with complex
References: <008601c23d92$10164650$9912e183@fnal.gov>
 <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com>
Message-ID: <01e401c23f0f$31f0f710$9912e183@fnal.gov>

I am new to boost and am attepting to use V2.
I have wrapped several functions, but have run into trouble with
"complex" ones

I get an error when compiling.  I am using version 3.1 of the GNU
compiler.

pysupercode.cc: In function `void init_module_supercode()':
pysupercode.cc:147: no matching function for call to `
   SuperCode::Array3<std::complex<double> >::Array3(const char[14])'
sctypes.h:251: candidates are: SuperCode::Array3<T>::Array3(const
   SuperCode::Array3<T>&) [with T = std::complex<double>]
sctypes.h:214:                 SuperCode::Array3<T>::Array3(int, int,
int)
   [with T = std::complex<double>]
pysupercode.cc:158: parse error before `)' token


I only get this error with the complex class, the other one works fine.
Is there something special with complex that I am forgetting?

Thanx,
Enrico Ng <enrico at fnal.gov>


Here is some of the code:
from sctypes.h
=========================================================
namespace SuperCode {

template<class T> class Array3 {

 public:

  Array3<T>(int rows, int cols, int depth);
  Array3<T>(const Array3<T>& a3);
 ~Array3<T>();
  T    get(int i, int j, int k) const;
 ...


from pysupercode.cc
=======================================================
#include <boost/python/operators.hpp>
#include <boost/python/class.hpp>
#include <boost/python/module.hpp>


using std::complex;

namespace python = boost::python;
using namespace SuperCode;

BOOST_PYTHON_MODULE_INIT(supercode)
{
   python::module("supercode")

     .add(
   python::class_<Array3<int> >("IntegerArray3")
   .def_init(python::args<int,int,int>())
   .def_init(python::args<Array3<int>&>())
   .def("get", &Array3<int>::get)

...

     .add(
   python::class_<Array3<complex<double> >("ComplexArray3")
   .def_init(python::args<int,int,int>())
   .def_init(python::args<const Array3<complex<double> >&>())
   .def("get", &Array3<complex<double> >::get)

...






From dave at boost-consulting.com  Thu Aug  8 22:41:21 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 8 Aug 2002 16:41:21 -0400
Subject: [C++-sig] problems with complex
References: <008601c23d92$10164650$9912e183@fnal.gov> <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com> <01e401c23f0f$31f0f710$9912e183@fnal.gov>
Message-ID: <112e01c23f1c$5361aea0$62f0fc0c@boostconsulting.com>

Suport requests 101: always give a complete copy of the error and show
which line of the source the error is occurring on. I can't correlate your
error message to the code excerpt you posted.

Can you post a minimal example from which I can reproduce your error?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Enrico Ng" <enrico at fnal.gov>
To: <c++-sig at python.org>
Sent: Thursday, August 08, 2002 3:10 PM
Subject: [C++-sig] problems with complex


> I am new to boost and am attepting to use V2.
> I have wrapped several functions, but have run into trouble with
> "complex" ones
>
> I get an error when compiling.  I am using version 3.1 of the GNU
> compiler.
>
> pysupercode.cc: In function `void init_module_supercode()':
> pysupercode.cc:147: no matching function for call to `
>    SuperCode::Array3<std::complex<double> >::Array3(const char[14])'
> sctypes.h:251: candidates are: SuperCode::Array3<T>::Array3(const
>    SuperCode::Array3<T>&) [with T = std::complex<double>]
> sctypes.h:214:                 SuperCode::Array3<T>::Array3(int, int,
> int)
>    [with T = std::complex<double>]
> pysupercode.cc:158: parse error before `)' token
>
>
> I only get this error with the complex class, the other one works fine.
> Is there something special with complex that I am forgetting?
>
> Thanx,
> Enrico Ng <enrico at fnal.gov>
>
>
> Here is some of the code:
> from sctypes.h
> =========================================================
> namespace SuperCode {
>
> template<class T> class Array3 {
>
>  public:
>
>   Array3<T>(int rows, int cols, int depth);
>   Array3<T>(const Array3<T>& a3);
>  ~Array3<T>();
>   T    get(int i, int j, int k) const;
>  ...
>
>
> from pysupercode.cc
> =======================================================
> #include <boost/python/operators.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/module.hpp>
>
>
> using std::complex;
>
> namespace python = boost::python;
> using namespace SuperCode;
>
> BOOST_PYTHON_MODULE_INIT(supercode)
> {
>    python::module("supercode")
>
>      .add(
>    python::class_<Array3<int> >("IntegerArray3")
>    .def_init(python::args<int,int,int>())
>    .def_init(python::args<Array3<int>&>())
>    .def("get", &Array3<int>::get)
>
> ...
>
>      .add(
>    python::class_<Array3<complex<double> >("ComplexArray3")
>    .def_init(python::args<int,int,int>())
>    .def_init(python::args<const Array3<complex<double> >&>())
>    .def("get", &Array3<complex<double> >::get)
>
> ...
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From enrico at fnal.gov  Thu Aug  8 23:15:05 2002
From: enrico at fnal.gov (Enrico Ng)
Date: Thu, 08 Aug 2002 16:15:05 -0500
Subject: [C++-sig] problems with complex
References: <008601c23d92$10164650$9912e183@fnal.gov>
 <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com>
 <01e401c23f0f$31f0f710$9912e183@fnal.gov>
 <112e01c23f1c$5361aea0$62f0fc0c@boostconsulting.com>
Message-ID: <022a01c23f20$aaaaf870$9912e183@fnal.gov>

Sorry, here is an example code:

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

namespace SuperCode {
template<class T> class Array3 {
 public:
  Array3<T>(int rows, int cols, int depth);
  Array3<T>(const Array3<T>& a3);
 ~Array3<T>();
  T    get(int i, int j, int k) const;
 private:
  int   _rows;
  int   _cols;
  int   _depth;
};
}

using std::complex;
namespace python = boost::python;
using namespace SuperCode;
BOOST_PYTHON_MODULE_INIT(supercode)
{
   python::module("supercode")

   //  ** ComplexArray3 **

     .add(
   python::class_<Array3<complex<double> >("ComplexArray3")
   .def_init(python::args<int,int,int>())
   .def_init(python::args<const Array3<complex<double> >&>())
   .def("get", &Array3<complex<double> >::get)
   )
     ;
}
----------------------------------------------------------------

I get the following error message when I compile:

pysupercode.cc: In function `void init_module_supercode()':
pysupercode.cc:39: no matching function for call to `
   SuperCode::Array3<std::complex<double> >::Array3(const char[14])'
pysupercode.cc:9: candidates are: SuperCode::Array3<T>::Array3(const
   SuperCode::Array3<T>&) [with T = std::complex<double>]
pysupercode.cc:8:                 SuperCode::Array3<T>::Array3(int, int,
int)
   [with T = std::complex<double>]
pysupercode.cc:43: parse error before `)' token



----- Original Message -----
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Thursday, August 08, 2002 3:41 PM
Subject: Re: [C++-sig] problems with complex


> Suport requests 101: always give a complete copy of the error and show
> which line of the source the error is occurring on. I can't correlate
your
> error message to the code excerpt you posted.
>
> Can you post a minimal example from which I can reproduce your error?
>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
> ----- Original Message -----
> From: "Enrico Ng" <enrico at fnal.gov>
> To: <c++-sig at python.org>
> Sent: Thursday, August 08, 2002 3:10 PM
> Subject: [C++-sig] problems with complex
>
>
> > I am new to boost and am attepting to use V2.
> > I have wrapped several functions, but have run into trouble with
> > "complex" ones
> >
> > I get an error when compiling.  I am using version 3.1 of the GNU
> > compiler.
> >
> > pysupercode.cc: In function `void init_module_supercode()':
> > pysupercode.cc:147: no matching function for call to `
> >    SuperCode::Array3<std::complex<double> >::Array3(const char[14])'
> > sctypes.h:251: candidates are: SuperCode::Array3<T>::Array3(const
> >    SuperCode::Array3<T>&) [with T = std::complex<double>]
> > sctypes.h:214:                 SuperCode::Array3<T>::Array3(int,
int,
> > int)
> >    [with T = std::complex<double>]
> > pysupercode.cc:158: parse error before `)' token
> >
> >
> > I only get this error with the complex class, the other one works
fine.
> > Is there something special with complex that I am forgetting?
> >
> > Thanx,
> > Enrico Ng <enrico at fnal.gov>
> >
> >
> > Here is some of the code:
> > from sctypes.h
> > =========================================================
> > namespace SuperCode {
> >
> > template<class T> class Array3 {
> >
> >  public:
> >
> >   Array3<T>(int rows, int cols, int depth);
> >   Array3<T>(const Array3<T>& a3);
> >  ~Array3<T>();
> >   T    get(int i, int j, int k) const;
> >  ...
> >
> >
> > from pysupercode.cc
> > =======================================================
> > #include <boost/python/operators.hpp>
> > #include <boost/python/class.hpp>
> > #include <boost/python/module.hpp>
> >
> >
> > using std::complex;
> >
> > namespace python = boost::python;
> > using namespace SuperCode;
> >
> > BOOST_PYTHON_MODULE_INIT(supercode)
> > {
> >    python::module("supercode")
> >
> >      .add(
> >    python::class_<Array3<int> >("IntegerArray3")
> >    .def_init(python::args<int,int,int>())
> >    .def_init(python::args<Array3<int>&>())
> >    .def("get", &Array3<int>::get)
> >
> > ...
> >
> >      .add(
> >    python::class_<Array3<complex<double> >("ComplexArray3")
> >    .def_init(python::args<int,int,int>())
> >    .def_init(python::args<const Array3<complex<double> >&>())
> >    .def("get", &Array3<complex<double> >::get)
> >
> > ...
> >
> >
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From dave at boost-consulting.com  Fri Aug  9 00:43:16 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 8 Aug 2002 18:43:16 -0400
Subject: [C++-sig] problems with complex
References: <008601c23d92$10164650$9912e183@fnal.gov> <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com> <01e401c23f0f$31f0f710$9912e183@fnal.gov> <112e01c23f1c$5361aea0$62f0fc0c@boostconsulting.com> <022a01c23f20$aaaaf870$9912e183@fnal.gov>
Message-ID: <11ec01c23f2c$fe5d3f30$62f0fc0c@boostconsulting.com>

From: "Enrico Ng" <enrico at fnal.gov>

You're missing an angle bracket...

> #include <complex>
> #include <boost/python/class.hpp>
> #include <boost/python/module.hpp>
> 
> namespace SuperCode {
> template<class T> class Array3 {
>  public:
>   Array3<T>(int rows, int cols, int depth);
>   Array3<T>(const Array3<T>& a3);
>  ~Array3<T>();
>   T    get(int i, int j, int k) const;
>  private:
>   int   _rows;
>   int   _cols;
>   int   _depth;
> };
> }
> 
> using std::complex;
> namespace python = boost::python;
> using namespace SuperCode;
> BOOST_PYTHON_MODULE_INIT(supercode)
> {
>    python::module("supercode")
> 
>    //  ** ComplexArray3 **
> 
>      .add(
>    python::class_<Array3<complex<double> >("ComplexArray3")
HERE--------------------------------------^

>    .def_init(python::args<int,int,int>())
>    .def_init(python::args<const Array3<complex<double> >&>())
>    .def("get", &Array3<complex<double> >::get)
>    )
>      ;
> }

HTH,

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From lists at UltimateG.com  Fri Aug  9 01:41:09 2002
From: lists at UltimateG.com (Mark Evans)
Date: Thu, 8 Aug 2002 18:41:09 -0500
Subject: [C++-sig] PySTL
Message-ID: <19125031984.20020808184109@UltimateG.com>

Anyone seen this Python wrapper for the C++ Standard Template Library?
How does it relate, if at all, to the work of Boost and this group?

http://www.malcolmson.com/pystl/

Mark




From mike at bindkey.com  Fri Aug  9 21:46:24 2002
From: mike at bindkey.com (Mike Rovner)
Date: Fri, 9 Aug 2002 12:46:24 -0700
Subject: [C++-sig] Re: [jamboost] Re: 1_28_0 python2.2.1 gcc3.0.4 build on sparc-solaris-2.7 problem report
References: <ad60ik$i9s$1@main.gmane.org> <02ff01c20825$aa9440d0$6601a8c0@boostconsulting.com> <ad6add$82u$1@main.gmane.org> <ad6dcn$dh3$2@main.gmane.org>
Message-ID: <aj164k$4um$1@main.gmane.org>

It is known bug in 3.0.4. One solution is to include <iostream.h> before
Python.h
That allows to compile BPL.
But python.jam unconditionally uses -lutil which is not part of Solaris and
after manual exclusion I still
get:
python-test-target
../../../libs/python/build/bin/comprehensive.test/gcc/debug-python/runtime-l
ink-dynamic/comprehensive.test
Traceback (most recent call last):
  File "../test/comprehensive.py", line 1245, in ?
    from boost_python_test import *
ImportError: ld.so.1: /usr/local/bin/python: fatal: relocation error: file
/export/home/mike/boost_1_28_0/libs/python/build/bin/boost_python_test.so/gc
c/debug-python/runtime-link-dynamic/shared-linkable-true/boost_python_test.s
o: symbol _Py_RefTotal: referenced symbol not found

Thanks,
Mike

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:ad6dcn$dh3$2 at main.gmane.org...
> Moving this to the C++-sig, where it belongs...
>
> ----- Original Message -----
> From: "Mike Rovner" <gclbb-jamboost at m.gmane.org>
>
>
> >
> > "David Abrahams" wrote...
> > > Sounds like you're right. What's the proposed fix?
> >
> > Modify boost[.python] to use 64-bit file operations [in that case].
>
> Boost.Python doesn't use any file operations.
>
> > I.e. include wrap_python.hpp first, huh?
>
> "huh", Huh?
>
> Which file should #include wrap_python first?
>
> > Or exclude <cstddef> from config.hpp - I see no use of it in that file.
>
> It's needed for offsetof()... though it appears BOOST_OFFSETOF is not used
> anywhere anymore, so we could just dispense with that.
>
> What happens if you comment out the #include <cstddef> from config.hpp?
>
> -Dave







From dave at boost-consulting.com  Tue Aug 13 02:34:58 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Aug 2002 20:34:58 -0400
Subject: [C++-sig] Boost.Python v2: C++->Python exception translation
Message-ID: <061101c24261$43105540$6501a8c0@boostconsulting.com>

I have just checked into Boost CVS some facilities for translating C++
exceptions to Python exceptions. See
libs/python/test/exception_translator.[cpp/py] for details.

The basic idiom is:

    register_exception_translator<CppExceptionType>(translate);

where the expression:

    translate(x)

is legal for an object x of type CppExceptionType, and is expected to call
PyErr_SetString or PyErr_SetObject to set up the Python exception.

Notes:

    1. This is obviously a somewhat minimalist implementation. We could
think about all sorts of additional nice facilities for creating new Python
exception types, for example.

    2. Some systems (Linux GCC 3.0.x in particular) have some pretty nasty
requirements in terms of exception-catching across shared library
boundaries. The issues are subtle, though you can read about them in the
threads referenced in the "Shared Libraries" section here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/May2002.html#shared

My advice to you if you need to use exception translation on these systems
is to be sure that each place that throws a given C++ exception type and
that registers a translator for that type be located in the same shared
library.

Cheers,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From enrico at fnal.gov  Tue Aug 13 18:29:25 2002
From: enrico at fnal.gov (Enrico Ng)
Date: Tue, 13 Aug 2002 11:29:25 -0500
Subject: [C++-sig] non-const arguments
References: <008601c23d92$10164650$9912e183@fnal.gov>
 <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com>
Message-ID: <07e201c242e6$96bf83c0$9912e183@fnal.gov>

> Decide on a Python interface that's consistent with Python's
immutability
> restrictions, and we can see how to wrap it.
>
> Perhaps
>
>     tuple ran1(Integer x)
>
> would work better for you?

This works fine, but I have to create thin wrappers for every function
[to return the resulting non-const arguments]

Is there already am implementation of this in boostv2?  If so, what is
it called?

Thanx,
Enrico Ng <enrico at fnal.gov>




From dave at boost-consulting.com  Tue Aug 13 18:13:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Aug 2002 12:13:28 -0400
Subject: [C++-sig] non-const arguments
References: <008601c23d92$10164650$9912e183@fnal.gov> <055f01c23d94$351ecba0$62f0fc0c@boostconsulting.com> <07e201c242e6$96bf83c0$9912e183@fnal.gov>
Message-ID: <09a201c242e4$9caf3520$6501a8c0@boostconsulting.com>

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Enrico Ng" <enrico at fnal.gov>
To: <c++-sig at python.org>
Sent: Tuesday, August 13, 2002 12:29 PM
Subject: Re: [C++-sig] non-const arguments


> > Decide on a Python interface that's consistent with Python's
> immutability
> > restrictions, and we can see how to wrap it.
> >
> > Perhaps
> >
> >     tuple ran1(Integer x)
> >
> > would work better for you?
>
> This works fine, but I have to create thin wrappers for every function
> [to return the resulting non-const arguments]
>
> Is there already am implementation of this in boostv2?

An implementation of what?

There's no facility which automatically decides the interface that should
be used for otherwise-unwrappable functions and creates thin wrappers for
you, if that's what you mean.

Do you have lots of functions with the same signature? It may be possible
to build a class template which does the job... depending which compiler(s)
you're targeting.

-Dave





From dave at boost-consulting.com  Tue Aug 13 20:48:22 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Aug 2002 14:48:22 -0400
Subject: [C++-sig] Re: [boost] Error if member function not called?
References: <0a0001c242ed$501dfc60$6501a8c0@boostconsulting.com> <003701c242f3$9a207620$1d00a8c0@pdimov2>
Message-ID: <0a7c01c242fa$04f00050$6501a8c0@boostconsulting.com>


From: "Peter Dimov" <pdimov at mmltd.net>


> From: "David Abrahams" <dave at boost-consulting.com>
> > Hi everybody,
> >
> > I'm looking for a clever trick, if anyone can come up with it...
> > In v2 of the Boost.Python library, when users define a class wrapper,
it
> > looks something like this:
> >
> >     class_<X>("X")
> >         .def_init(args<int, char*>())  // constructor
> >         .def("foo", &X::foo)           // member function
> >         ;
> >
> > Each of class_<>'s member functions returns *this to allow the chaining
> > idiom shown above.
> >
> > What I'd like is to be able to generate a compiler warning or error if
the
> > user fails to call the def_init() member function somewhere in the
chain.
> > Any ideas?
>
> class_<X>("X", args<int, char*>()).def("foo", &X::foo);

I thought of that too, just after I posted. Not a bad idea, since not
passing any args<> can be the same as the default constructor -- that's
actually better than causing an error.

The (minor) problem with this is that it's asymmetric -- the user can add
other constructor overloads, but those will use def_init. Overall, I like
it, though.

This discussion came out of a desire to implement the "Automatic Object
Initialization" feature detailed at http://www.python.org/sigs/c++-sig/.
Opinions from the C++-sig?


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Tue Aug 13 21:29:45 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Aug 2002 15:29:45 -0400
Subject: [C++-sig] Re: [boost] Error if member function not called?
References: <Pine.LNX.4.44.0208131439420.7759-100000@hythloth.kitwarein.com> <0aac01c242fc$5dc1a9c0$6501a8c0@boostconsulting.com>
Message-ID: <0b0601c24300$10ab06a0$6501a8c0@boostconsulting.com>

From: "David Abrahams" <dave at boost-consulting.com>


> I was going to use a special template parameter to indicate that rare
case.
>
>     class_<A, not_constructible>("A").def("method", &A::method)

Come to think of it, I'd probably opt for a special no_init parameter to
the constructor:

    class_<A, not_constructible>("A", no_init).def("method", &A::method)

Thoughts?

-Dave

> From: "Brad King" <brad.king at kitware.com>
> >
> > What if the class really doesn't have any public constructors?
> >
> > A* get_A();
> >
> > class A
> > {
> >   A() {}
> >   friend A* get_A();
> > public:
> >   void method();
> > };
> >
> > ...
> >
> > module("my_module")
> >   .add(class_<A>("A").def("method", &A::method))
> >   .def("get_A", get_A, return_value_policy<manage_new_object>());
> >
> > -Brad
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>




From dave at boost-consulting.com  Tue Aug 13 22:21:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Aug 2002 16:21:12 -0400
Subject: [C++-sig] Re: [boost] Re: Error if member function not called?
References: <Pine.LNX.4.44.0208131439420.7759-100000@hythloth.kitwarein.com><0aac01c242fc$5dc1a9c0$6501a8c0@boostconsulting.com><25942.9790465676$1029268776@news.gmane.org> <ajbqmm$9d9$1@main.gmane.org>
Message-ID: <0b7c01c24307$7f54ef60$6501a8c0@boostconsulting.com>

From: "David B. Held" <dheld at codelogicconsulting.com>


> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:25942.9790465676$1029268776 at news.gmane.org...
> > [...]
> > Come to think of it, I'd probably opt for a special no_init parameter
to
> > the constructor:
> >
> >     class_<A, not_constructible>("A", no_init).def("method",
&A::method)
>
> Is this redundant, or did you mean to say:
>
> class_<A>("A", no_init).def("method", &A::method);

Yes, that's what I meant. Thanks very much indeed!
OK, I'm not hearing any objections, so I'm going to implement this.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From dave at boost-consulting.com  Wed Aug 14 01:50:06 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Aug 2002 19:50:06 -0400
Subject: [C++-sig] BPL v2: Auto initialization/massive code breakage!!!
Message-ID: <0c8f01c24324$7ac46490$6501a8c0@boostconsulting.com>

I've just implemented an auto_initialization feature as described in the
"Automatic C++ Object Initialization" section at
http://www.python.org/sigs/c++-sig, and pretty much all of the test files
had to be changed to accomodate it.

Okay, calm down -- the code breakage is not all that massive ;-)

What happened is that essentially, the argument(s) to a class_<> instance's
first def_init() function got added to its constructor. If the class had no
def_init(...) calls, you now must pass python::no_init instead. On the
upside, you never need to call def_init() with no arguments, since that's
the default. So:

OLD WAY                                 NEW WAY

class_<A>("A")                          class_<A>("A")
    .def_init()                             .def_init(args<int, int>())
    .def_init(args<int, int>())             .def(...)
    .def(...)                               ;
    ;

class_<B>("B")                          class_<B>("B", args<int, int>())
    .def_init(args<int, int>())             .def(...)
    .def(...)                               ;
    ;

class_<C>("C", "C's docstring")         class_<C>("C", "C's docstring"
    .def_init(args<int, int>())                   , args<int, int>())
    .def(...)                               .def(...)
    ;                                       ;

class_<D>("D", "D's docstring")         class_<D>("D", "D's docstring"
    .def_init(args<int, int>(), "doc")            , args<int, int>(),
"doc")
    .def(...)                               .def(...)
    ;                                       ;


class_<E>("E")                          class_<E>("E", no_init)
    .def(...)                                   .def(...)
    ;                                           ;

class_<F>("F")                          class_<F>("F", no_init)
    .def(...)                                   .def(...)
    ;

class_<G>("G", "G's docstring")         class_<G>("G", "G's docstring",
no_init)
    .def(...)                               .def(...)
    ;                                       ;


I plan to check this stuff in later this evening. I just wanted everyone to
be aware of what's coming.

Regards,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From enrico at fnal.gov  Fri Aug 16 20:55:02 2002
From: enrico at fnal.gov (Enrico Ng)
Date: Fri, 16 Aug 2002 13:55:02 -0500
Subject: [C++-sig] Python Assignment
References: <0c8f01c24324$7ac46490$6501a8c0@boostconsulting.com>
Message-ID: <00b401c24556$6d3b1dd0$9912e183@fnal.gov>

I would like the beable to tell python when to make a copy and when not
to.

In python, if I do:

a=MyMatrix
b=a

changes in b will affect a and vice versa because b points to a.
I would like to tell python to make a copy if I try to change b so a is
not affected.
Same if I try to change a.

Is there a way to do this?




From jeyk at cox.net  Fri Aug 16 23:53:36 2002
From: jeyk at cox.net (Jey Kottalam)
Date: Fri, 16 Aug 2002 17:53:36 -0400
Subject: [C++-sig] Python Assignment
Message-ID: <20020816215336.FVWY1369.fed1mtao04.cox.net@smtp.west.cox.net>

I believe this is off-topic here, but...

import copy
a = MyMatrix
b = copy.deepcopy(a) # I think this is correct

Can someone confirm this?

-Jey Kottalam

> 
> From: Enrico Ng <enrico at fnal.gov>
> Date: 2002/08/16 Fri PM 02:55:02 EDT
> To: c++-sig at python.org
> Subject: [C++-sig] Python Assignment
> 
> I would like the beable to tell python when to make a copy and when not
> to.
> 
> In python, if I do:
> 
> a=MyMatrix
> b=a
> 
> changes in b will affect a and vice versa because b points to a.
> I would like to tell python to make a copy if I try to change b so a is
> not affected.
> Same if I try to change a.
> 
> Is there a way to do this?
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 




From dave at boost-consulting.com  Sat Aug 17 20:50:17 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 17 Aug 2002 14:50:17 -0400
Subject: [C++-sig] Python Assignment
References: <0c8f01c24324$7ac46490$6501a8c0@boostconsulting.com> <00b401c24556$6d3b1dd0$9912e183@fnal.gov>
Message-ID: <018f01c2461f$8c8c7160$6501a8c0@boostconsulting.com>

From: "Enrico Ng" <enrico at fnal.gov>


> I would like the beable to tell python when to make a copy and when not
> to.
>
> In python, if I do:
>
> a=MyMatrix
> b=a
>
> changes in b will affect a and vice versa because b points to a.
> I would like to tell python to make a copy if I try to change b so a is
> not affected.
> Same if I try to change a.
>
> Is there a way to do this?

There's no way to control what '=' does in Python. It always rebinds
references to objects, so when you write

    b = a

a and b will always refer to the same object. That's just how Python is.

If you want, you can arrange for b = copy.copy(a) to make a copy of a. I
believe that if you implement pickling for MyMatrix that this just works
automatically (but I don't remember). Take a look at the copy module in the
Python standard library.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Sat Aug 17 23:55:25 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 17 Aug 2002 14:55:25 -0700 (PDT)
Subject: [C++-sig] Python Assignment
In-Reply-To: <018f01c2461f$8c8c7160$6501a8c0@boostconsulting.com>
Message-ID: <20020817215525.656.qmail@web20202.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> If you want, you can arrange for b = copy.copy(a) to make a copy of a. I
> believe that if you implement pickling for MyMatrix that this just works
> automatically (but I don't remember). Take a look at the copy module in the
> Python standard library.

The detour through pickle is potentially expensive. So this is how I do it:

b = a.deep_copy()

where I supply the deep_copy() method myself.

Ralf


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com



From franke at ableton.com  Mon Aug 19 14:48:32 2002
From: franke at ableton.com (Stefan Franke)
Date: Mon, 19 Aug 2002 14:48:32 +0200
Subject: [C++-sig] Boost v2 questions
Message-ID: <6FB30F72F5FF9145B785936278BC25C81823A8@exserver.ouroffice.de>

I have an application where I want to enable the user to write
extension scripts which can access parts of the document. Think 
of a vector drawing program with graphical object the user can 
manipulate and assign properties to. Consider the following 
hypothetical script using two wrapped C++ classes Canvas and 
Shape:

s = canvas().getShapeByName("myshape")
# canvas() returns a CanvasWrapper instance
# s is of class ShapeWrapper

s.x = 100         # x: member of C++ class as a Python attribute
s.mydata = [1, 2] # User assigned Pyton data

canvas().deleteShape("myshape")
print s.x             # Access C++ member

Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
ReferenceError: Cannot access property 'x' of object 's'.


Here my questions:
1. Is it possible that an instace of the Boost-generated class 
ShapeWrapper has an instance dictionary that the user can assign
values to?

2. The C++ function Canvas::deleteShape() deletes the shape. This 
is existing functionality that can hardly be changed. I'd like to
have weak referencing behaviour for almost all of my wrapped objects.
There already exists a weak pointer type for my C++ classes that I 
can easily extend.

Is it possible to instruct Boost not to hold a plain pointer to the
C++ instance inside its wrapper objects, but one of my smart 
pointers?
And further, is it possible to get a Python exception whenever a 
member function of a dangling object is called? I envision to put the
checks into the dereferencing operators of my smart pointer type and
then throwing a C++ exception to signal to Boost that the operation
has failed.

Are my desires too far-fetched? OTOH I'd say this behaviour is pretty
standard whenever you want to enable user scripting for an existing 
application. 

Or am I missing something obvious and there's an easier way to 
achieve the same thing? Note that I neither want to check object 
validity on the Python side (user scripting should be as easy as 
possible) nor write dedicated C++ classes like "ShapeAccessor" or 
"CanvasAccessor" that implement the validity checks (since there are 
just too many classes to wrap and I'd loose one of Boosts major 
advantage then).

Thanks for any feedback
Stefan






From dave at boost-consulting.com  Mon Aug 19 14:28:23 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Aug 2002 08:28:23 -0400
Subject: [C++-sig] Boost v2 questions
References: <6FB30F72F5FF9145B785936278BC25C81823A8@exserver.ouroffice.de>
Message-ID: <009d01c2477c$353aadb0$6501a8c0@boostconsulting.com>

From: "Stefan Franke" <franke at ableton.com>


> I have an application where I want to enable the user to write
> extension scripts which can access parts of the document. Think
> of a vector drawing program with graphical object the user can
> manipulate and assign properties to. Consider the following
> hypothetical script using two wrapped C++ classes Canvas and
> Shape:
>
> s = canvas().getShapeByName("myshape")
> # canvas() returns a CanvasWrapper instance
> # s is of class ShapeWrapper
>
> s.x = 100         # x: member of C++ class as a Python attribute
> s.mydata = [1, 2] # User assigned Pyton data
>
> canvas().deleteShape("myshape")
> print s.x             # Access C++ member
>
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ReferenceError: Cannot access property 'x' of object 's'.

I can't tell from the above whether you're illustrating a problem, desired
behavior, or something else. Also, since I can't see your C++ code I can't
tell how you got there.

> Here my questions:
> 1. Is it possible that an instace of the Boost-generated class
> ShapeWrapper has an instance dictionary that the user can assign
> values to?

Not only possible, but true.

> 2. The C++ function Canvas::deleteShape() deletes the shape. This
> is existing functionality that can hardly be changed. I'd like to
> have weak referencing behaviour for almost all of my wrapped objects.
> There already exists a weak pointer type for my C++ classes that I
> can easily extend.
>
> Is it possible to instruct Boost not to hold a plain pointer to the
> C++ instance inside its wrapper objects, but one of my smart
> pointers?

Sure. Have you looked at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/class.html#class_-spec?

You can simply specify your own smart pointer as the HeldType parameter,
and specialize the pointee<> template appropriately (sorry, no docs - see
boost/python/pointee.hpp).

> And further, is it possible to get a Python exception whenever a
> member function of a dangling object is called? I envision to put the
> checks into the dereferencing operators of my smart pointer type and
> then throwing a C++ exception to signal to Boost that the operation
> has failed.

Perfect. Just install a Python exception translator for your C++ exception
as neccessary:

http://mail.python.org/pipermail/c++-sig/2002-August/001922.html

> Are my desires too far-fetched? OTOH I'd say this behaviour is pretty
> standard whenever you want to enable user scripting for an existing
> application.
>
> Or am I missing something obvious and there's an easier way to
> achieve the same thing?

Easier than what?

> Note that I neither want to check object
> validity on the Python side (user scripting should be as easy as
> possible) nor write dedicated C++ classes like "ShapeAccessor" or
> "CanvasAccessor" that implement the validity checks (since there are
> just too many classes to wrap and I'd loose one of Boosts major
> advantage then).

Let me know if this has failed to help you.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From gideon at computer.org  Mon Aug 19 15:10:37 2002
From: gideon at computer.org (gideon may)
Date: Mon, 19 Aug 2002 15:10:37 +0200
Subject: [C++-sig] rfe: change of behaviour with return_internal_reference policy
Message-ID: <106086424.1029769837@[10.0.0.16]>

Dear Dave,

I have the following code example (obvious stuff missing :
<============================================
class Node {
};

class Leaf1 : public Node {
};

class Leaf2 : public Node {
};

class Group : public Node {
  public:
    void addChild(Node * child) { _child = child; }
    Node * getChild() { return _child; }
  private:
    Node * _child;
};

toGroup(Node * self) {    return dynamic_cast<Group *>(self); }

toLeaf1(Node * self) {    return dynamic_cast<Leaf1 *>(self); }

toLeaf2(Node * self) {    return dynamic_cast<Leaf2 *>(self); }

BOOST_PYTHON_MODULE_INIT(cast)
{
    module("cast")
        .add(class_<Node>("Node")
            .def_init()
            .def("toGroup", &nodeToGroup, return_internal_reference<>())
            .def("toLeaf1", &nodeToLeaf1, return_internal_reference<>())
            .def("toLeaf2", &nodeToLeaf2, return_internal_reference<>())
         )
         .add(class_<Group>("Group")
         .add(class_<Leaf1>("Leaf1")
         .add(class_<Leaf2>("Leaf2")
    ;
}
=======================================>

this allows me to do stuff like :

>>> g = Group()
>>> n = g.getChild()
>>> l1 = n.toLeaf1()
>>> if l1:
>>>     print "I'm leaf1"
>>> l2 = n.toLeaf2()
>>> if l2:
>>>     print "I'm leaf2"

Unfortunately it doesn't work, because of the weak references being used 
with return_internal_reference.
It seems that within make_nurse_and_patient (life_support.cpp), a weak 
reference is being
created between the result and the originator. In my case the result can be 
a NULL pointer, failing
the PyWeakref_NewRef function. If however a check is made that the nurse is 
an object supporting
weak references the function continues as intended else returning a PyNone, 
then
my code works. Thus inserting

	if (!PyType_SUPPORTS_WEAKREFS(nurse->ob_type)) {
		Py_INCREF(Py_None);
		return Py_None;
	}

at the beginning of function make_nurse_and_patient would do the trick for 
me. Would
this be possible ?

This brings me to a second point, it seems that life_support_dealloc is 
never called. If it would,
the tp_free would be called for self, which is not initialized ie a NULL 
function pointer.


ciao,

gideon




From dave at boost-consulting.com  Mon Aug 19 15:25:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Aug 2002 09:25:28 -0400
Subject: [C++-sig] rfe: change of behaviour with return_internal_reference policy
References: <106086424.1029769837@[10.0.0.16]>
Message-ID: <00b901c24783$ed12b7f0$6501a8c0@boostconsulting.com>

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "gideon may" <gideon at computer.org>
To: "pysig" <c++-sig at python.org>
Sent: Monday, August 19, 2002 9:10 AM
Subject: [C++-sig] rfe: change of behaviour with return_internal_reference
policy


> Dear Dave,
>
> I have the following code example (obvious stuff missing :
> <============================================
> class Node {
> };
>
> class Leaf1 : public Node {
> };
>
> class Leaf2 : public Node {
> };
>
> class Group : public Node {
>   public:
>     void addChild(Node * child) { _child = child; }
>     Node * getChild() { return _child; }
>   private:
>     Node * _child;
> };
>
> toGroup(Node * self) {    return dynamic_cast<Group *>(self); }
>
> toLeaf1(Node * self) {    return dynamic_cast<Leaf1 *>(self); }
>
> toLeaf2(Node * self) {    return dynamic_cast<Leaf2 *>(self); }
>
> BOOST_PYTHON_MODULE_INIT(cast)
> {
>     module("cast")
>         .add(class_<Node>("Node")
>             .def_init()
>             .def("toGroup", &nodeToGroup, return_internal_reference<>())
>             .def("toLeaf1", &nodeToLeaf1, return_internal_reference<>())
>             .def("toLeaf2", &nodeToLeaf2, return_internal_reference<>())
>          )
>          .add(class_<Group>("Group")
>          .add(class_<Leaf1>("Leaf1")
>          .add(class_<Leaf2>("Leaf2")
>     ;
> }
> =======================================>
>
> this allows me to do stuff like :
>
> >>> g = Group()
> >>> n = g.getChild()
> >>> l1 = n.toLeaf1()
> >>> if l1:
> >>>     print "I'm leaf1"
> >>> l2 = n.toLeaf2()
> >>> if l2:
> >>>     print "I'm leaf2"
>
> Unfortunately it doesn't work, because of the weak references being used
> with return_internal_reference.
> It seems that within make_nurse_and_patient (life_support.cpp), a weak
> reference is being
> created between the result and the originator.

No, not exactly. We're creating a weak reference from the result to a
life_support object, which holds a reference to the originator and to the
weak reference. It's a sick little trick which keeps the originator alive
as long as the result is.

> In my case the result can be
> a NULL pointer,

Which gets translated to None.

> failing
> the PyWeakref_NewRef function.

Ah yes; None doesn't support weak references.

> If however a check is made that the nurse is
> an object supporting
> weak references the function continues as intended else returning a
PyNone,
> then
> my code works. Thus inserting
>
> if (!PyType_SUPPORTS_WEAKREFS(nurse->ob_type)) {
> Py_INCREF(Py_None);
> return Py_None;
> }
>
> at the beginning of function make_nurse_and_patient would do the trick
for
> me. Would
> this be possible ?

No, not that; it wouldn't be the right fix, since code which expects to be
able to keep the originator alive but gets an object which doesn't support
weak refs needs to get a Python exception rather than a crash.

However, we /could/ check explicitly for None, since that's going to stay
alive no matter what we do.
I think in the case that's failing for you, both the nurse and patient
parameters in make_nurse_and_patient are PyNone, right?

> This brings me to a second point, it seems that life_support_dealloc is
> never called.
> If it would,
> the tp_free would be called for self, which is not initialized ie a NULL
> function pointer.

Really? Hmm, I'm not sure about that. Which fields in an extension type are
filled in automatically by Python and when they're called remains a little
mysterious to me, I have to admit.




From gideon at computer.org  Mon Aug 19 16:27:25 2002
From: gideon at computer.org (gideon may)
Date: Mon, 19 Aug 2002 16:27:25 +0200
Subject: [C++-sig] rfe: change of behaviour with
 return_internal_reference policy
In-Reply-To: <00b901c24783$ed12b7f0$6501a8c0@boostconsulting.com>
References: <00b901c24783$ed12b7f0$6501a8c0@boostconsulting.com>
Message-ID: <110694299.1029774445@[10.0.0.16]>


--On Monday, August 19, 2002 9:25 AM -0400 David Abrahams 
<dave at boost-consulting.com> wrote:

>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
> ----- Original Message -----
> From: "gideon may" <gideon at computer.org>
> To: "pysig" <c++-sig at python.org>
> Sent: Monday, August 19, 2002 9:10 AM
> Subject: [C++-sig] rfe: change of behaviour with return_internal_reference
> policy
>
>
>> Dear Dave,
>>


>> Unfortunately it doesn't work, because of the weak references being used
>> with return_internal_reference.
>> It seems that within make_nurse_and_patient (life_support.cpp), a weak
>> reference is being
>> created between the result and the originator.
>
> No, not exactly. We're creating a weak reference from the result to a
> life_support object, which holds a reference to the originator and to the
> weak reference. It's a sick little trick which keeps the originator alive
> as long as the result is.

The internal working evaded me but now i understand :-)

>
>> In my case the result can be
>> a NULL pointer,
>
> Which gets translated to None.

Right.

>
>> failing
>> the PyWeakref_NewRef function.
>
> Ah yes; None doesn't support weak references.
>


> However, we /could/ check explicitly for None, since that's going to stay
> alive no matter what we do.
> I think in the case that's failing for you, both the nurse and patient
> parameters in make_nurse_and_patient are PyNone, right?

Actually, you're right, that's what I had before. But only the nurse needs
to be checked for PyNone, the patient is the 'self' parameter in toGroup 
afaik,
which is guaranteed to be not PyNone. Thus I guess that it suffices to 
change the
beginning of the function to :

if (nurse == Py_None) {
    Py_INCREF(Py_None);
    return Py_None;
}

>
>> This brings me to a second point, it seems that life_support_dealloc is
>> never called.
>> If it would,
>> the tp_free would be called for self, which is not initialized ie a NULL
>> function pointer.
>
> Really? Hmm, I'm not sure about that. Which fields in an extension type
> are filled in automatically by Python and when they're called remains a
> little mysterious to me, I have to admit.
>

I stumbled upon this because of my previous point. Without the mentioned 
change,
PyWeakref_Newref returns a NULL. This causes 'system' to be Py_XDEFREF'd -> 
crash in
life_support_dealloc (line 24). But somehow the the life_support_dealloc 
function is never
being called. I did some investigating in the functioning of weak 
references (esp the function
PyWeakref_NewRef) and it seems that the referent is being Py_XINCREF'd by 
default. Don'
know why but don't feel like spending too much time understanding.

BTW, am enjoying BPL more and more! Any news on enum_ <wink> ?




From franke at ableton.com  Mon Aug 19 16:59:16 2002
From: franke at ableton.com (Stefan Franke)
Date: Mon, 19 Aug 2002 16:59:16 +0200
Subject: [C++-sig] Boost v2 questions
In-Reply-To: <6FB30F72F5FF9145B785936278BC25C8166C02@exserver.ouroffice.de>
Message-ID: <6FB30F72F5FF9145B785936278BC25C81823AB@exserver.ouroffice.de>

Dave,

thanks a lot for this informative answer. v2 seems to be exactly 
what I need.

BTW: The link to the pointee type in the docs doesn't seem to work:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/v2/pointee.html



Stefan


> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Monday, August 19, 2002 2:28 PM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Boost v2 questions
> 
> 
> From: "Stefan Franke" <franke at ableton.com>
> 
> 
> > I have an application where I want to enable the user to write
> > extension scripts which can access parts of the document. Think
> > of a vector drawing program with graphical object the user can
> > manipulate and assign properties to. Consider the following
> > hypothetical script using two wrapped C++ classes Canvas and
> > Shape:
> >
> > s = canvas().getShapeByName("myshape")
> > # canvas() returns a CanvasWrapper instance
> > # s is of class ShapeWrapper
> >
> > s.x = 100         # x: member of C++ class as a Python attribute
> > s.mydata = [1, 2] # User assigned Pyton data
> >
> > canvas().deleteShape("myshape")
> > print s.x             # Access C++ member
> >
> > Traceback (most recent call last):
> >   File "<interactive input>", line 1, in ?
> > ReferenceError: Cannot access property 'x' of object 's'.
> 
> I can't tell from the above whether you're illustrating a 
> problem, desired
> behavior, or something else. Also, since I can't see your C++ 
> code I can't
> tell how you got there.
> 
> > Here my questions:
> > 1. Is it possible that an instace of the Boost-generated class
> > ShapeWrapper has an instance dictionary that the user can assign
> > values to?
> 
> Not only possible, but true.
> 
> > 2. The C++ function Canvas::deleteShape() deletes the shape. This
> > is existing functionality that can hardly be changed. I'd like to
> > have weak referencing behaviour for almost all of my 
> wrapped objects.
> > There already exists a weak pointer type for my C++ classes that I
> > can easily extend.
> >
> > Is it possible to instruct Boost not to hold a plain pointer to the
> > C++ instance inside its wrapper objects, but one of my smart
> > pointers?
> 
> Sure. Have you looked at
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boos
> t/boost/libs/
> python/doc/v2/class.html#class_-spec?
> 
> You can simply specify your own smart pointer as the HeldType 
> parameter,
> and specialize the pointee<> template appropriately (sorry, 
> no docs - see
> boost/python/pointee.hpp).
> 
> > And further, is it possible to get a Python exception whenever a
> > member function of a dangling object is called? I envision 
> to put the
> > checks into the dereferencing operators of my smart pointer type and
> > then throwing a C++ exception to signal to Boost that the operation
> > has failed.
> 
> Perfect. Just install a Python exception translator for your 
> C++ exception
> as neccessary:
> 
> http://mail.python.org/pipermail/c++-sig/2002-August/001922.html
> 
> > Are my desires too far-fetched? OTOH I'd say this behaviour 
> is pretty
> > standard whenever you want to enable user scripting for an existing
> > application.
> >
> > Or am I missing something obvious and there's an easier way to
> > achieve the same thing?
> 
> Easier than what?
> 
> > Note that I neither want to check object
> > validity on the Python side (user scripting should be as easy as
> > possible) nor write dedicated C++ classes like "ShapeAccessor" or
> > "CanvasAccessor" that implement the validity checks (since there are
> > just too many classes to wrap and I'd loose one of Boosts major
> > advantage then).
> 
> Let me know if this has failed to help you.
> 
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 




From dave at boost-consulting.com  Mon Aug 19 16:53:55 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Aug 2002 10:53:55 -0400
Subject: [C++-sig] Boost v2 questions
References: <6FB30F72F5FF9145B785936278BC25C81823AB@exserver.ouroffice.de>
Message-ID: <012001c24790$7750c540$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>


> Dave,
>
> thanks a lot for this informative answer. v2 seems to be exactly
> what I need.
>
> BTW: The link to the pointee type in the docs doesn't seem to work:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/pointee.html
>


> and specialize the pointee<> template appropriately
> (sorry, no docs - see boost/python/pointee.hpp).
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


HTH,
Dave



-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com

> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > Sent: Monday, August 19, 2002 2:28 PM
> > To: c++-sig at python.org
> > Subject: Re: [C++-sig] Boost v2 questions
> >
> >
> > From: "Stefan Franke" <franke at ableton.com>
> >
> >
> > > I have an application where I want to enable the user to write
> > > extension scripts which can access parts of the document. Think
> > > of a vector drawing program with graphical object the user can
> > > manipulate and assign properties to. Consider the following
> > > hypothetical script using two wrapped C++ classes Canvas and
> > > Shape:
> > >
> > > s = canvas().getShapeByName("myshape")
> > > # canvas() returns a CanvasWrapper instance
> > > # s is of class ShapeWrapper
> > >
> > > s.x = 100         # x: member of C++ class as a Python attribute
> > > s.mydata = [1, 2] # User assigned Pyton data
> > >
> > > canvas().deleteShape("myshape")
> > > print s.x             # Access C++ member
> > >
> > > Traceback (most recent call last):
> > >   File "<interactive input>", line 1, in ?
> > > ReferenceError: Cannot access property 'x' of object 's'.
> >
> > I can't tell from the above whether you're illustrating a
> > problem, desired
> > behavior, or something else. Also, since I can't see your C++
> > code I can't
> > tell how you got there.
> >
> > > Here my questions:
> > > 1. Is it possible that an instace of the Boost-generated class
> > > ShapeWrapper has an instance dictionary that the user can assign
> > > values to?
> >
> > Not only possible, but true.
> >
> > > 2. The C++ function Canvas::deleteShape() deletes the shape. This
> > > is existing functionality that can hardly be changed. I'd like to
> > > have weak referencing behaviour for almost all of my
> > wrapped objects.
> > > There already exists a weak pointer type for my C++ classes that I
> > > can easily extend.
> > >
> > > Is it possible to instruct Boost not to hold a plain pointer to the
> > > C++ instance inside its wrapper objects, but one of my smart
> > > pointers?
> >
> > Sure. Have you looked at
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boos
> > t/boost/libs/
> > python/doc/v2/class.html#class_-spec?
> >
> > You can simply specify your own smart pointer as the HeldType
> > parameter,
> > and specialize the pointee<> template appropriately (sorry,
> > no docs - see
> > boost/python/pointee.hpp).
> >
> > > And further, is it possible to get a Python exception whenever a
> > > member function of a dangling object is called? I envision
> > to put the
> > > checks into the dereferencing operators of my smart pointer type and
> > > then throwing a C++ exception to signal to Boost that the operation
> > > has failed.
> >
> > Perfect. Just install a Python exception translator for your
> > C++ exception
> > as neccessary:
> >
> > http://mail.python.org/pipermail/c++-sig/2002-August/001922.html
> >
> > > Are my desires too far-fetched? OTOH I'd say this behaviour
> > is pretty
> > > standard whenever you want to enable user scripting for an existing
> > > application.
> > >
> > > Or am I missing something obvious and there's an easier way to
> > > achieve the same thing?
> >
> > Easier than what?
> >
> > > Note that I neither want to check object
> > > validity on the Python side (user scripting should be as easy as
> > > possible) nor write dedicated C++ classes like "ShapeAccessor" or
> > > "CanvasAccessor" that implement the validity checks (since there are
> > > just too many classes to wrap and I'd loose one of Boosts major
> > > advantage then).
> >
> > Let me know if this has failed to help you.
> >
> > -----------------------------------------------------------
> >            David Abrahams * Boost Consulting
> > dave at boost-consulting.com * http://www.boost-consulting.com
> >
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From dave at boost-consulting.com  Mon Aug 19 17:34:42 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Aug 2002 11:34:42 -0400
Subject: [C++-sig] rfe: change of behaviour with return_internal_reference policy
References: <00b901c24783$ed12b7f0$6501a8c0@boostconsulting.com> <110694299.1029774445@[10.0.0.16]>
Message-ID: <012901c24796$13d52f00$6501a8c0@boostconsulting.com>

From: "gideon may" <gideon at computer.org>
> --On Monday, August 19, 2002 9:25 AM -0400 David Abrahams
> <dave at boost-consulting.com> wrote:
> > From: "gideon may" <gideon at computer.org>


> >
> >> In my case the result can be
> >> a NULL pointer,
> >
> > Which gets translated to None.
>
> Right.
>
> >
> >> failing
> >> the PyWeakref_NewRef function.
> >
> > Ah yes; None doesn't support weak references.
> >
>
>
> > However, we /could/ check explicitly for None, since that's going to
stay
> > alive no matter what we do.
> > I think in the case that's failing for you, both the nurse and patient
> > parameters in make_nurse_and_patient are PyNone, right?
>
> Actually, you're right, that's what I had before. But only the nurse
needs
> to be checked for PyNone, the patient is the 'self' parameter in toGroup
> afaik,
> which is guaranteed to be not PyNone. Thus I guess that it suffices to
> change the
> beginning of the function to :
>
> if (nurse == Py_None) {
>     Py_INCREF(Py_None);
>     return Py_None;
> }

Okay, fixed.

> >> This brings me to a second point, it seems that life_support_dealloc
is
> >> never called.
> >> If it would,
> >> the tp_free would be called for self, which is not initialized ie a
NULL
> >> function pointer.
> >
> > Really? Hmm, I'm not sure about that. Which fields in an extension type
> > are filled in automatically by Python and when they're called remains a
> > little mysterious to me, I have to admit.
> >
>
> I stumbled upon this because of my previous point. Without the mentioned
> change,
> PyWeakref_Newref returns a NULL. This causes 'system' to be
Py_XDEFREF'd ->
> crash in
> life_support_dealloc (line 24). But somehow the the life_support_dealloc
> function is never
> being called.

Those two sentences contradict one another!
However, I think it's fixed.

> BTW, am enjoying BPL more and more!

Great!

> Any news on enum_ <wink> ?

Contract obligations force me to concentrate on other things until probably
9/30.

However, you could do:

    .setattr("enum_value_1", (int)enum_value_1)

on your module object.

-Dave




From gideon at computer.org  Mon Aug 19 18:06:01 2002
From: gideon at computer.org (gideon may)
Date: Mon, 19 Aug 2002 18:06:01 +0200
Subject: [C++-sig] rfe: change of behaviour with
 return_internal_reference policy
Message-ID: <116609886.1029780361@[10.0.0.16]>

>
> Okay, fixed.

Works perfect. Thanks!

>> I stumbled upon this because of my previous point. Without the mentioned
>> change,
>> PyWeakref_Newref returns a NULL. This causes 'system' to be
> Py_XDEFREF'd ->
>> crash in
>> life_support_dealloc (line 24). But somehow the the life_support_dealloc
>> function is never
>> being called.
>
> Those two sentences contradict one another!
> However, I think it's fixed.

I see what you mean, after reading my own post :)

> Contract obligations force me to concentrate on other things until
> probably 9/30.
>
> However, you could do:
>
>     .setattr("enum_value_1", (int)enum_value_1)
>

OK, that's what I've been doing.

ciao,

gideon 



From david.abrahams at rcn.com  Tue Aug 20 02:07:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 19 Aug 2002 20:07:09 -0400
Subject: [C++-sig] Re: Python 2.2.1 C API - Error Handling
Message-ID: <011501c247dd$df061ee0$6501a8c0@boostconsulting.com>

<cseymour at thrush.eos.ubc.ca> wrote in message
news:kvwuqmtpsd.fsf at thrush.eos.ubc.ca...
> Hi,
>
> We have some extension modules that worked with Python 2.1, but now
> that we use Python 2.2.1 they crash whenever a PyErr is thrown.
>
> We're using Boost (couldn't get any help from their mailing list),

Never saw your posting. Try C++-sig at python.org instead, though: that's more
Boost.Python specific

> with the usual Boost module setup, where there's a try for the module
> builder stuff, and a catch afterwards which runs
> Boost's handle_exception() function, which causes Python errors. In
> Python 2.1, whenever we throw an error, it is caught by this "catch(...)"
> clause, and an error is raised inside Python. In
> Python 2.2.1, the catch seems to be completely skipped and we get a seg
> fault. I have seen this same behaviour in multiple extension modules.

What is your compiler and platform? Did you switch compiler versions between
2.1 and 2.2.1?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com







From dave at boost-consulting.com  Tue Aug 20 02:48:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Aug 2002 20:48:40 -0400
Subject: [C++-sig] Progress towards "the Dave Hawkes ideal"
Message-ID: <015101c247e3$d19d4b10$6501a8c0@boostconsulting.com>

The module class is now unneeded for defining extension classes. See almost
any Boost.Python v2 test module in the CVS for examples; you can just
construct the class; it gets added to the current scope().

libs/python/test/nested.[cpp/py] shows an example of using a class_<> as
the current scope to produce a nested class.

Nested modules are waiting on an answer to this question:
http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1328496

Dave, if you want to take up the research on this again, I'd be more than
happy...

As soon as Joel gets finished adding the optional (default) argument
support, we can make the standalone def() functions which allow the module
class to be deprecated altogether.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From dave at boost-consulting.com  Tue Aug 20 02:52:50 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Aug 2002 20:52:50 -0400
Subject: [C++-sig] Issue with str()
Message-ID: <015201c247e3$e9b49730$6501a8c0@boostconsulting.com>

We have a naming conflict: the str() function used in
boost/python/operators.hpp to automatically define an extension class'
__str__ method is (obviously) not the same as the str class available in
boost/python/str.hpp. While the str() function is in a nested namespace
(self_ns) and can be accessed explicitly, that fact was never meant to be
exposed to users.

Options:

    1. rename class str to class string
    2. rename str() to str_()
    3. expose self_ns to users
    4. Something else?

I lean towards #2. Opinions?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From david.abrahams at rcn.com  Tue Aug 20 05:23:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 19 Aug 2002 23:23:16 -0400
Subject: [C++-sig] Re: Python 2.2.1 C API - Error Handling
Message-ID: <01a801c247f8$fd913a50$6501a8c0@boostconsulting.com>

<cseymour at thrush.eos.ubc.ca> wrote in message
news:kvr8gu2x71.fsf at thrush.eos.ubc.ca...
> The compiler is gcc 3.0.4. We switched from 2.95 to 3.0.4 between 2.1 and
2.2.1.

That explains everything.

The GCC 3.x ABI compares typeinfo addressesinstead of typeinfo name strings
to do exception matching, with bad results for code that throws across
shared library boundaries (please complain to the GCC developers
http://gcc.gnu.org/cgi-bin/gnatsweb.pl about this move -- a very premature
"optimization" IMO).

Have you updated your Boost installation recently?
The current Boost release helps with some workarounds for this problem.

Instead of writing "throw boost::python::argument_error()" you can write
"boost::python::throw_argument_error()" and then the exception will be
thrown in the same shared library where it is eventually rethrown and caught
by boost::python::handle_exception().

HTH,
Dave

P.S. and in future, really do post to http://www.python.org/sigs/c++-sig/; I
don't always watch this newsgroup.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com







From gideon at computer.org  Tue Aug 20 17:59:26 2002
From: gideon at computer.org (gideon may)
Date: Tue, 20 Aug 2002 17:59:26 +0200
Subject: [C++-sig] implicit converter from enum to int problem
Message-ID: <3150960.1029866366@dyn151.snm-hgkz.ch>

Dear Dave,

I've been running into the same problem which Achim had regarding
the use of enumeration types (see 
http://mail.python.org/pipermail/c++-sig/2002-May/001077.html). He wasn't 
able to compile the code which you posted.
I tried something along the same line, which gave the following compiler 
error (osg::Material::Face is an enum):

C:\cvs_rep\boost\boost\boost\python\converter\implicit.hpp(43) : error 
C2440: '=' : cannot convert from 'int' to 'osg::Material:
:Face'
        Conversion to enumeration type requires an explicit cast 
(static_cast, C-style cast or function-style cast)
        C:\cvs_rep\boost\boost\boost\python\converter\implicit.hpp(28) : 
while compiling class-template member function 'void bo
ost::python::converter::implicit<Source,Target>::construct(PyObject 
*,boost::python::converter::rvalue_from_python_stage1_data *
)'
        with
        [
            Source=int,
            Target=osg::Material::Face
        ]

In the mail from may you mentioned that you forgot the rule for converting 
ints to enums. Has this been
implemented ?

I changed python/converter/implicit.h @ line 43 to the following :
        // new (storage) 
Target(*static_cast<Source*>(intermediate_data.stage1.convertible));
        new (storage) 
Target((Target)*static_cast<Source*>(intermediate_data.stage1.convertible));

and now I'm able to compile and run my code. Is it right what I did ? It 
seems to work for me.

ciao,

gideon



From dave at boost-consulting.com  Tue Aug 20 18:42:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 Aug 2002 12:42:12 -0400
Subject: [C++-sig] implicit converter from enum to int problem
References: <3150960.1029866366@dyn151.snm-hgkz.ch>
Message-ID: <045501c24868$d75efb40$6501a8c0@boostconsulting.com>

From: "gideon may" <gideon at computer.org>


> Dear Dave,
>
> I've been running into the same problem which Achim had regarding
> the use of enumeration types (see
> http://mail.python.org/pipermail/c++-sig/2002-May/001077.html). He wasn't
> able to compile the code which you posted.
> I tried something along the same line, which gave the following compiler
> error (osg::Material::Face is an enum):

Please in future post the code you're trying to compile along with the
compiler error. I think I understand what's happening in this case, though.

> C:\cvs_rep\boost\boost\boost\python\converter\implicit.hpp(43) : error
> C2440: '=' : cannot convert from 'int' to 'osg::Material:
> :Face'
>         Conversion to enumeration type requires an explicit cast
> (static_cast, C-style cast or function-style cast)
>         C:\cvs_rep\boost\boost\boost\python\converter\implicit.hpp(28) :
> while compiling class-template member function 'void bo
> ost::python::converter::implicit<Source,Target>::construct(PyObject
> *,boost::python::converter::rvalue_from_python_stage1_data *
> )'
>         with
>         [
>             Source=int,
>             Target=osg::Material::Face
>         ]
>
> In the mail from may you mentioned that you forgot the rule for
converting
> ints to enums. Has this been
> implemented ?

Uh, no.

> I changed python/converter/implicit.h @ line 43 to the following :
>         // new (storage)
> Target(*static_cast<Source*>(intermediate_data.stage1.convertible));
>         new (storage)
>
Target((Target)*static_cast<Source*>(intermediate_data.stage1.convertible))
;
>
> and now I'm able to compile and run my code. Is it right what I did ? It
> seems to work for me.

Well, that's a bit dicey since the C-style cast can work unintentionally in
so many situations, though I'm not really sure it's any worse than the
alternatives.

The real problem here is that your fix places additional requirements on
Target, namely that it's copy-constructible.

I'm truly not sure what to do about this one; it appears that the rules are
complicated. For example, just because you can write:

    enum Foo { foo = 42; }
    int y = 3;
    Foo x1 = Foo(y);

doesn't mean you can write:

    Foo* x2 = new Foo(y);

I've always found that the rules for fundamental types are abominably
confusing. Hell, I'm not even sure what the right formal name for these
things (which includes the scalars and enums) is. I'm going to try to get
some expert feedback about this. It's possible that the only good fix for
implicit.hpp is to do something which detects that the target type is one
of the builtins (or enum) that's known to be copy-constructible and
dispatches to a different implementation.

I'll let you know what I find out.

-Dave




From leo at hiper.com.br  Tue Aug 20 18:53:04 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 20 Aug 2002 13:53:04 -0300
Subject: [C++-sig] packaging and distribution
Message-ID: <1029862384.5421.1.camel@spitfire>

Hi,

I was looking for a way to move stuff around after boost.build builds them, and
so I found the 'stage' rule for bjam. However, I didn't find a way to
reference a built extension module.

For instance, in libs/python/build/Jamfile, the rule: 'dll boost_python'
builds, libboost_python.so in unix, which can then be referenced by the
stage rule 'bin-stage', in that same Jamfile, as <dll>boost_python.

So, when I use an 'extension someextension' rule, how do I reference the
resulting someextension.so file in a 'stage' rule? I tried
'<extension>someextension', but this doesn't seem to work.

The reason for this question is that I'm looking for an equivalent of
'make install'. More to the point, I want to move libboost_python.so
into some ld.so.conf sanctioned area and the extensions that depend on
it to the appropriate site-packages directory, so that I don't have to
keep munging LD_LIBRARY_PATH or PYTHONPATH variables to test stuff.

Maybe what I really need is to know how to integrate boost.build with
distutils...

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From grafik666 at redshift-software.com  Tue Aug 20 19:06:56 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Tue, 20 Aug 2002 12:06:56 -0500
Subject: [C++-sig] packaging and distribution
In-Reply-To: <1029862384.5421.1.camel@spitfire>
Message-ID: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43>

[2002-08-20] Leonardo Rochael Almeida wrote:

>Hi,
>
>I was looking for a way to move stuff around after boost.build builds them,
and
>so I found the 'stage' rule for bjam. However, I didn't find a way to
>reference a built extension module.
>
>For instance, in libs/python/build/Jamfile, the rule: 'dll boost_python'
>builds, libboost_python.so in unix, which can then be referenced by the
>stage rule 'bin-stage', in that same Jamfile, as <dll>boost_python.
>
>So, when I use an 'extension someextension' rule, how do I reference the
>resulting someextension.so file in a 'stage' rule? I tried
>'<extension>someextension', but this doesn't seem to work.

Try: <pyd>someextension -- It should/might work as "PYD" is what python.jam
uses for building the extensions.

>The reason for this question is that I'm looking for an equivalent of
>'make install'. More to the point, I want to move libboost_python.so
>into some ld.so.conf sanctioned area and the extensions that depend on
>it to the appropriate site-packages directory, so that I don't have to
>keep munging LD_LIBRARY_PATH or PYTHONPATH variables to test stuff.

I'm not sure "stage" will help you with that. Or at least I didn't write it
to handle things like that ;-)

It might work if you specify an absolute path for the stage, as in
"/usr/local/somepath", but I wouldn't count on it.

>Maybe what I really need is to know how to integrate boost.build with
>distutils...

To "integrate" it you'd have to do a two step process. First using "stage"
to move the file to someplace within the build hierarchy... and then
writting your own distutils scripts to "install" the files. Can't help you
in the disutils script though.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From leo at hiper.com.br  Tue Aug 20 21:06:53 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 20 Aug 2002 16:06:53 -0300
Subject: [C++-sig] packaging and distribution
In-Reply-To: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43>
References: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43>
Message-ID: <1029870413.5422.5.camel@spitfire>

On Tue, 2002-08-20 at 14:06, Rene Rivera wrote:
> [2002-08-20] Leonardo Rochael Almeida wrote:
> 
> >I was looking for a way to move stuff around after boost.build builds them,
> and
> >so I found the 'stage' rule for bjam. However, I didn't find a way to
> >reference a built extension module.
> >
> >[...]
> >
> >So, when I use an 'extension someextension' rule, how do I reference the
> >resulting someextension.so file in a 'stage' rule? I tried
> >'<extension>someextension', but this doesn't seem to work.
> 
> Try: <pyd>someextension -- It should/might work as "PYD" is what python.jam
> uses for building the extensions.

Thanks! that did work.

> [...]
> 
> >Maybe what I really need is to know how to integrate boost.build with
> >distutils...
> 
> To "integrate" it you'd have to do a two step process. First using "stage"
> to move the file to someplace within the build hierarchy... and then
> writting your own distutils scripts to "install" the files.

That's what I had in mind.

Now I have another problem though. The extension module is being created
with a dll dependency on libboost_python.so.1.28.0, but the boost rule
'dll boost_python' (and the boost target '<dll>boost_python generages')
generates only libboost_python.so, with no reference to the version
number.

I can manually solve this problem with a symlink, but I don't think I
should be doing this in jam rules. I think boost.build should be doing
it the other way around, creating libboost_python.so.1.28.0, or else
making the extension module depend on the unversioned dll (probably a
bad idea).

To make this less abstract, lemme show part of my Jamfile:

>>>
# Declare a Python extension called dummy
extension dummy
:  # sources
   dummy.cpp

   # dependencies
   <dll>../build/boost_python
  ;

stage deploy/site-packages
:  # move extensions to site-packages
   <pyd>dummy ;

stage deploy/lib
:  # move dlls to lib
   <dll>../build/boost_python ;
<<<

this generates the following tree under deploy:

deploy/
   site-packages/
      dummy.so
   lib/
      libboost_python.so

however:

$ ldd deploy/site-packages/dummy.so
	(...)
        libboost_python.so.1.28.0 => not found
        (...)

the fact that it was not found is not important, but the fact that it's
expecting a version number in the .so name, when no such file was
generated, is. What I don't get is why the <dll> target used in the
'extension' dependency generates an extension that depends in a
versioned .so name while the same target in the 'stage' dependency
doesn't create/copy a .so with the versioned name.

So, how do you guys suggest I deal with that?

Is it a boost v1 problem only? I'm using v1 just because it's the
released version and (it seems to me) has more complete docs.

For the curious, I'm using boost.python to make the bindings to a
largish C++ GIS library that was released recently:

http://www.terralib.org/

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From dave at boost-consulting.com  Tue Aug 20 22:08:52 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 Aug 2002 16:08:52 -0400
Subject: [C++-sig] packaging and distribution
References: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43> <1029870413.5422.5.camel@spitfire>
Message-ID: <065c01c24885$713b30f0$6501a8c0@boostconsulting.com>

From: "Leonardo Rochael Almeida" <leo at hiper.com.br>

> Now I have another problem though. The extension module is being created
> with a dll dependency on libboost_python.so.1.28.0, but the boost rule
> 'dll boost_python' (and the boost target '<dll>boost_python generages')
> generates only libboost_python.so, with no reference to the version
> number.
>
> I can manually solve this problem with a symlink, but I don't think I
> should be doing this in jam rules. I think boost.build should be doing
> it the other way around, creating libboost_python.so.1.28.0, or else
> making the extension module depend on the unversioned dll (probably a
> bad idea).

<snip>

> So, how do you guys suggest I deal with that?

I'll have to leave those answers to Rene; I think there's a pretty simple
answer, but he wrote all the SOVERSION stuff...

> Is it a boost v1 problem only? I'm using v1 just because it's the
> released version and (it seems to me) has more complete docs.

Not really, Boost.Python v1 and v2 use basically the same strategy for
building.
However, if you haven't got very far into v1 I'd like to strongly suggest
you try using v2.
The docs, though not yet complete, are probably better and more complete in
the formal sense than those for v1. Though there's no tutorial section,
there's a lot of reference documentation which covers most of the important
stuff. Also, v1 is going to be retired (very) soon. Furthermore, v2 is just
better in nearly every way. One major problem with v1 is that it won't
build on conforming compilers.

> For the curious, I'm using boost.python to make the bindings to a
> largish C++ GIS library that was released recently:
>
> http://www.terralib.org/

Wow, I bet Beman would be curious about that. His background is in mapping
software.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From leo at hiper.com.br  Wed Aug 21 00:43:46 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 20 Aug 2002 19:43:46 -0300
Subject: [C++-sig] approaching a new library
In-Reply-To: <065c01c24885$713b30f0$6501a8c0@boostconsulting.com>
References: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43>
	<1029870413.5422.5.camel@spitfire> 
	<065c01c24885$713b30f0$6501a8c0@boostconsulting.com>
Message-ID: <1029883426.5422.9.camel@spitfire>

On Tue, 2002-08-20 at 17:08, David Abrahams wrote:
> [...]
> However, if you haven't got very far into v1 I'd like to strongly suggest
> you try using v2.
> The docs, though not yet complete, are probably better and more complete in
> the formal sense than those for v1. Though there's no tutorial section,
> there's a lot of reference documentation which covers most of the important
> stuff. Also, v1 is going to be retired (very) soon. Furthermore, v2 is just
> better in nearly every way. One major problem with v1 is that it won't
> build on conforming compilers.

It was working for me, AFAIK, with a gcc-3.0 toolchain on Linux (Debian
and Mandrake), but have it working on Windows is a pretty important
goal, which we haven't tested yet.

My only fear is, since there isn't any released tarball of it yet, that
v2 would be a moving target, making it hard to use it for development.
but since "you strongly suggest" it, it probably means that grabbing it
from cvs will be stable enough :-)

I'll try it tonight

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From leo at hiper.com.br  Wed Aug 21 02:39:10 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 20 Aug 2002 21:39:10 -0300
Subject: [C++-sig] approaching a new library
In-Reply-To: <1029883426.5422.9.camel@spitfire>
References: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43>
	<1029870413.5422.5.camel@spitfire> 
	<065c01c24885$713b30f0$6501a8c0@boostconsulting.com> 
	<1029883426.5422.9.camel@spitfire>
Message-ID: <1029890350.5421.13.camel@spitfire>

Dang, I changed the subject just to send an e-mail that doesn't match
said subject...

I meant (but forgot) to ask, do you guys have suggestions regarding how
to approach a large C++ library with the intent of creating Boost.Python
bindings for it? any war stories :-)? Since we will be in a position to
influence changes in the library itself, do you have any suggestions in
that area? What can a C++ library author do to make it easier to make
Boost.Python bindings for it?

Cheers, Leo

On Tue, 2002-08-20 at 19:43, Leonardo Rochael Almeida wrote:
> On Tue, 2002-08-20 at 17:08, David Abrahams wrote:
> > [...]
> > However, if you haven't got very far into v1 I'd like to strongly suggest
> > you try using v2.
> > The docs, though not yet complete, are probably better and more complete in
> > the formal sense than those for v1. Though there's no tutorial section,
> > there's a lot of reference documentation which covers most of the important
> > stuff. Also, v1 is going to be retired (very) soon. Furthermore, v2 is just
> > better in nearly every way. One major problem with v1 is that it won't
> > build on conforming compilers.
> 
> It was working for me, AFAIK, with a gcc-3.0 toolchain on Linux (Debian
> and Mandrake), but have it working on Windows is a pretty important
> goal, which we haven't tested yet.
> 
> My only fear is, since there isn't any released tarball of it yet, that
> v2 would be a moving target, making it hard to use it for development.
> but since "you strongly suggest" it, it probably means that grabbing it
> from cvs will be stable enough :-)
> 
> I'll try it tonight
> 
> Cheers, Leo
> 
> -- 
> Ideas don't stay in some minds very long because they don't like
> solitary confinement.
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 
-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From dave at boost-consulting.com  Wed Aug 21 04:03:13 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 Aug 2002 22:03:13 -0400
Subject: [C++-sig] approaching a new library
References: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43><1029870413.5422.5.camel@spitfire> <065c01c24885$713b30f0$6501a8c0@boostconsulting.com> <1029883426.5422.9.camel@spitfire> <1029890350.5421.13.camel@spitfire>
Message-ID: <084501c248b7$9b5529e0$6501a8c0@boostconsulting.com>

From: "Leonardo Rochael Almeida" <leo at hiper.com.br>


> Dang, I changed the subject just to send an e-mail that doesn't match
> said subject...
>
> I meant (but forgot) to ask, do you guys have suggestions regarding how
> to approach a large C++ library with the intent of creating Boost.Python
> bindings for it? any war stories :-)? Since we will be in a position to
> influence changes in the library itself, do you have any suggestions in
> that area? What can a C++ library author do to make it easier to make
> Boost.Python bindings for it?


Fortunately, Boost.Python is designed to be non-intrusive. In general, you
shoudn't need to touch the internals of the library you're wrapping --
that's a design goal.

There are a few areas which can make a difference, however:

1. If you have non-pure virtual functions which you want to be overridable
from Python, make them protected rather than private. It's an unfortunate
limitation that we can't generate a call to the default implementation if
it's private.

2. Exercise some discipline in your use of raw pointers in interfaces. This
is actually much less of an issue with v2 since CallPolicies allows users
to say something about the meaning of pointer arguments and returns, but in
general you're better off if you can work with smart pointers rather than
raw pointers. That's pretty much true of all good C++ code anyway, so it
shouldn't be much of a burden ;-)

HTH,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Aug 21 14:59:20 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 08:59:20 -0400
Subject: [C++-sig] approaching a new library
References: <20020820120657-r01010800-296f36cc-0860-0108@12.100.89.43><1029870413.5422.5.camel@spitfire> <065c01c24885$713b30f0$6501a8c0@boostconsulting.com> <1029883426.5422.9.camel@spitfire>
Message-ID: <0abf01c24913$278ccb60$6501a8c0@boostconsulting.com>

From: "Leonardo Rochael Almeida" <leo at hiper.com.br>

> My only fear is, since there isn't any released tarball of it yet, that
> v2 would be a moving target, making it hard to use it for development.
> but since "you strongly suggest" it, it probably means that grabbing it
> from cvs will be stable enough :-)

Yeah, we're converging rapidly and what's already there isn't changing
much. We're mostly adding new things which don't intrude on existing code.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From dave at boost-consulting.com  Wed Aug 21 19:43:25 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 13:43:25 -0400
Subject: [C++-sig] PySTL
References: <19125031984.20020808184109@UltimateG.com>
Message-ID: <0e6701c2493a$93f25be0$6501a8c0@boostconsulting.com>

Mark,

I guess it's not too closely related.

-Dave


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message ----- 
From: "Mark Evans" <lists at UltimateG.com>
To: <c++-sig at python.org>
Sent: Thursday, August 08, 2002 7:41 PM
Subject: [C++-sig] PySTL


> Anyone seen this Python wrapper for the C++ Standard Template Library?
> How does it relate, if at all, to the work of Boost and this group?
> 
> http://www.malcolmson.com/pystl/
> 
> Mark
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From Peter.Schoen1 at epost.de  Thu Aug 22 01:23:02 2002
From: Peter.Schoen1 at epost.de (Peter Schoen)
Date: Thu, 22 Aug 2002 01:23:02 +0200
Subject: [C++-sig] bpl v2: changing ownership of c++ objects
Message-ID: <200208220120.20152.Peter.Schoen1@web.de>

Dear y'all,

I am currently trying to wrap a Tree/Graph-API using Boost.Python v2. It's my 
goal to embed the Python interpreter into the main application to let the user 
assemble and change the tree/graph interactively using Python. The user 
should be able to create nodes and add them to the graph.

Problem: Each node of the graph has a:

	void Node::addChild(Node* child);

method. Once a child node or a subtree is added using this method, 
the father node becomes responsible for the life-cycle management of its 
children. No Python reference counting should interfere from this moment on. 
Even if the Python wrapper objects are destroyed, the subtree should still 
live on.

Is there a way to do this in Boost.Python v2? Is with_custodian_and_ward<> a 
means to do this?

Thanks & very best wishes

-Peter-





From cseymour at interchange.ubc.ca  Thu Aug 22 01:36:33 2002
From: cseymour at interchange.ubc.ca (cseymour at interchange.ubc.ca)
Date: Wed, 21 Aug 2002 16:36:33 -0700
Subject: [C++-sig] more boost v1 problems
Message-ID: <7727888.1029972993041.JavaMail.portal@portal1.itservices.ubc.ca>

Hello again,

sorry for posting about this again but i can't figure it out...
I had boost working yesterday, but today (the computer it was working on is fried) it refuses to work.

I'm using the linux gcc makefile. I've tried g++ 2.96 (which it worked with before) and python 2.2.1 compiled with g++ 2.96, and also g++ 3.0.4 and python 2.2.1 compiled with g++ 3.0.4 (which the boost python webpage says should work). in both cases, when running comprehensive.py it fails like so:

1
2
3
Running comprehensive.__doc__
Trying:
try:
    ext = Foo()
except TypeError, err:
    assert re.match(r'function .* exactly 1 argument;? \(?0 given\)?',
                    str(err))
else:
    print 'no exception'
Expecting: nothing
Aborted

and i assume this is because of the ABI / exception handling problems. my extension modules seem to work, except when they try to throw exceptions.

the only difference i can think of between computers is that the computer I was working on before had glibc version 2.2.5 installed, while the rest have 2.2.4 (it was in changing glibc back that the computer died)

does anyone have any ideas on what i could do? again, sorry for sort of re-posting but i've worked at this and can't figure it out



From Peter.Schoen1 at epost.de  Thu Aug 22 01:54:28 2002
From: Peter.Schoen1 at epost.de (Peter Schoen)
Date: Thu, 22 Aug 2002 01:54:28 +0200
Subject: [C++-sig] bpl v2: classes with private constructors
Message-ID: <200208220153.06796.Peter.Schoen1@epost.de>

Dear y'all,

the constructors of some classes I am trying to wrap are private because 
instances must be created by using a factory. Is it possible to wrap such 
classes using bpl v2?

Any links to examples, etc. would be highly appreciated.

In an older mail I read something about specifying the HeldType template 
argument of the class_<> template to solve such a problem, but I did not 
really understand this solution, yet, sorry.

Very best wishes

-Peter-




From dave at boost-consulting.com  Thu Aug 22 02:25:30 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 20:25:30 -0400
Subject: [C++-sig] more boost v1 problems
References: <7727888.1029972993041.JavaMail.portal@portal1.itservices.ubc.ca>
Message-ID: <11bb01c24972$81ca1880$6501a8c0@boostconsulting.com>

1. Are you using the current boost CVS state, or something earlier?
2. Have you rebuilt everything from scratch since changing your glibc?
3. Have you rebuilt/reinstalled your GCC since changing your glibc?

I have to admit, glibc compatibility issues are black magic to me, but #3
sounds like the sort of thing that could be an issue.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com

From: <cseymour at interchange.ubc.ca>


> Hello again,
>
> sorry for posting about this again but i can't figure it out...
> I had boost working yesterday, but today (the computer it was working on
is fried) it refuses to work.
>
> I'm using the linux gcc makefile. I've tried g++ 2.96 (which it worked
with before) and python 2.2.1 compiled with g++ 2.96, and also g++ 3.0.4
and python 2.2.1 compiled with g++ 3.0.4 (which the boost python webpage
says should work). in both cases, when running comprehensive.py it fails
like so:
>
> 1
> 2
> 3
> Running comprehensive.__doc__
> Trying:
> try:
>     ext = Foo()
> except TypeError, err:
>     assert re.match(r'function .* exactly 1 argument;? \(?0 given\)?',
>                     str(err))
> else:
>     print 'no exception'
> Expecting: nothing
> Aborted
>
> and i assume this is because of the ABI / exception handling problems. my
extension modules seem to work, except when they try to throw exceptions.
>
> the only difference i can think of between computers is that the computer
I was working on before had glibc version 2.2.5 installed, while the rest
have 2.2.4 (it was in changing glibc back that the computer died)
>
> does anyone have any ideas on what i could do? again, sorry for sort of
re-posting but i've worked at this and can't figure it out





From cseymour at interchange.ubc.ca  Thu Aug 22 02:53:25 2002
From: cseymour at interchange.ubc.ca (cseymour at interchange.ubc.ca)
Date: Wed, 21 Aug 2002 17:53:25 -0700
Subject: [C++-sig] more boost v1 problems
Message-ID: <3836623.1029977605100.JavaMail.portal@portal1.itservices.ubc.ca>

1) boost 1.28.0
2) no. the glibc was just changed by changing the RPM on the dead computer. only the dead computer was affected. Python was built with gcc 2.96 and 3.0.4 on a different computer using glibc 2.2.4.
3) n/a. the computer i'm working on now has always had glibc 2.2.4.

i don't think its a glibc thing, but thats the only variable i can think of.

-----Original Message-----

> Date: Wed Aug 21 17:25:30 PDT 2002
> From: David Abrahams <dave at boost-consulting.com>
> Subject: Re: [C++-sig] more boost v1 problems
> To: c++-sig at python.org
>
> 1. Are you using the current boost CVS state, or something earlier?
> 2. Have you rebuilt everything from scratch since changing your glibc?
> 3. Have you rebuilt/reinstalled your GCC since changing your glibc?
> 
> I have to admit, glibc compatibility issues are black magic to me, but #3
> sounds like the sort of thing that could be an issue.
> 
> -Dave
> 
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
> 
> From: <cseymour at interchange.ubc.ca>
> 
> 
> > Hello again,
> >
> > sorry for posting about this again but i can't figure it out...
> > I had boost working yesterday, but today (the computer it was working on
> is fried) it refuses to work.
> >
> > I'm using the linux gcc makefile. I've tried g++ 2.96 (which it worked
> with before) and python 2.2.1 compiled with g++ 2.96, and also g++ 3.0.4
> and python 2.2.1 compiled with g++ 3.0.4 (which the boost python webpage
> says should work). in both cases, when running comprehensive.py it fails
> like so:
> >
> > 1
> > 2
> > 3
> > Running comprehensive.__doc__
> > Trying:
> > try:
> >     ext = Foo()
> > except TypeError, err:
> >     assert re.match(r'function .* exactly 1 argument;? \(?0 given\)?',
> >                     str(err))
> > else:
> >     print 'no exception'
> > Expecting: nothing
> > Aborted
> >
> > and i assume this is because of the ABI / exception handling problems. my
> extension modules seem to work, except when they try to throw exceptions.
> >
> > the only difference i can think of between computers is that the computer
> I was working on before had glibc version 2.2.5 installed, while the rest
> have 2.2.4 (it was in changing glibc back that the computer died)
> >
> > does anyone have any ideas on what i could do? again, sorry for sort of
> re-posting but i've worked at this and can't figure it out
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From dave at boost-consulting.com  Thu Aug 22 02:57:13 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 20:57:13 -0400
Subject: [C++-sig] bpl v2: changing ownership of c++ objects
References: <200208220120.20152.Peter.Schoen1@web.de>
Message-ID: <11e501c24977$698ba310$6501a8c0@boostconsulting.com>

From: "Peter Schoen" <Peter.Schoen1 at epost.de>
> I am currently trying to wrap a Tree/Graph-API using Boost.Python v2.
It's my
> goal to embed the Python interpreter into the main application to let the
user
> assemble and change the tree/graph interactively using Python. The user
> should be able to create nodes and add them to the graph.
>
> Problem: Each node of the graph has a:
>
> void Node::addChild(Node* child);
>
> method. Once a child node or a subtree is added using this method,
> the father node becomes responsible for the life-cycle management of its
> children. No Python reference counting should interfere from this moment
on.
> Even if the Python wrapper objects are destroyed, the subtree should
still
> live on.
>
> Is there a way to do this in Boost.Python v2? Is
with_custodian_and_ward<> a
> means to do this?

If you use with_custodian_and_ward<1,2>, that will bind the lifetime
of the Python object which manages the child to the lifetime of the
Python 'self' object which manages the *this object. That doesn't
completely remove the Python lifetime management of the C++ child
object -- when you release the last reference to the Python 'self'
object *and* the last reference to the Python child object, the C++
child object will be destroyed.

If the C++ *this object is actually going to delete the child node
(say, in its destructor), you'll need to do something else to prevent
the Python object from destroying the object a 2nd time.

Well, the best way to handle this, if you can do it, is to change the
interface to the library by using smart pointers to illustrate
transfer-of-ownership. For example, passing a std::auto_ptr<Node>
by-value means "the function is taking ownership of this dynamically
allocated Node", and Boost.Python understands that. In order to make
that possible, you'd also want to pass auto_ptr<Node> as the Holder
parameter to class_ (
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/class.html
):

    class_<Node, std::auto_ptr<Node> >("Node")
         .def("addChild", &Node::addChild) // accepting a std::auto_ptr
now.
         ;

Passing std::auto_ptr<> as the Holder parameter causes Node objects
constructed from Python (via __init__ functions) to be held by
std::auto_ptr. Well, I suppose if I had total control over the C++
interface I'd use boost::shared_ptr here, allowing for shared lifetime
management.

Anyway, if you can't change the argument to Node::addChild, you would
have to use std::auto_ptr, with an added wrapper function:

   void add_child(Node& n, std::auto_ptr<Node>& child)
   {
       n.addChild(child.get());
       child.release(); // assumes that addChild may throw
                        // before taking ownership.
   }

Note however that in either of these transfer-of-ownership cases using
std::auto_ptr<> the source Python object becomes a sort of "zombie",
since its former C++ innards become inaccessible to it -- no crashes,
but you can't really do anything with it either -- using
boost::shared_ptr<> doesn't cause that problem, which is why I
suggested changing the C++ interface.

HTH,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From dave at boost-consulting.com  Thu Aug 22 03:16:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 21:16:07 -0400
Subject: [C++-sig] more boost v1 problems
References: <3836623.1029977605100.JavaMail.portal@portal1.itservices.ubc.ca>
Message-ID: <11ed01c24979$7ed2a640$6501a8c0@boostconsulting.com>

All I can tell you offhand is:

0. 2.96 is not an official GCC release version
1. it is working for me here with GCC 3.2 on Debian.
2. This crash might well be due to a problem with C++ exception-handling.

Hmm, how did you configure your GCCs? I have it on good authority that for
GCCs prior to 3.1 need to be configured with

    --prefix=... --enable-version-specific-runtime-libs

if you have an existing GCC installation. For versions 3.1 and greater,

    --prefix=...

is sufficient.

HTH,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: <cseymour at interchange.ubc.ca>
To: "David Abrahams" <dave at boost-consulting.com>
Cc: <c++-sig at python.org>
Sent: Wednesday, August 21, 2002 8:53 PM
Subject: Re: Re: [C++-sig] more boost v1 problems


> 1) boost 1.28.0
> 2) no. the glibc was just changed by changing the RPM on the dead
computer. only the dead computer was affected. Python was built with gcc
2.96 and 3.0.4 on a different computer using glibc 2.2.4.
> 3) n/a. the computer i'm working on now has always had glibc 2.2.4.
>
> i don't think its a glibc thing, but thats the only variable i can think
of.
>
> -----Original Message-----
>
> > Date: Wed Aug 21 17:25:30 PDT 2002
> > From: David Abrahams <dave at boost-consulting.com>
> > Subject: Re: [C++-sig] more boost v1 problems
> > To: c++-sig at python.org
> >
> > 1. Are you using the current boost CVS state, or something earlier?
> > 2. Have you rebuilt everything from scratch since changing your glibc?
> > 3. Have you rebuilt/reinstalled your GCC since changing your glibc?
> >
> > I have to admit, glibc compatibility issues are black magic to me, but
#3
> > sounds like the sort of thing that could be an issue.
> >
> > -Dave
> >
> > -----------------------------------------------------------
> >            David Abrahams * Boost Consulting
> > dave at boost-consulting.com * http://www.boost-consulting.com
> >
> > From: <cseymour at interchange.ubc.ca>
> >
> >
> > > Hello again,
> > >
> > > sorry for posting about this again but i can't figure it out...
> > > I had boost working yesterday, but today (the computer it was working
on
> > is fried) it refuses to work.
> > >
> > > I'm using the linux gcc makefile. I've tried g++ 2.96 (which it
worked
> > with before) and python 2.2.1 compiled with g++ 2.96, and also g++
3.0.4
> > and python 2.2.1 compiled with g++ 3.0.4 (which the boost python
webpage
> > says should work). in both cases, when running comprehensive.py it
fails
> > like so:
> > >
> > > 1
> > > 2
> > > 3
> > > Running comprehensive.__doc__
> > > Trying:
> > > try:
> > >     ext = Foo()
> > > except TypeError, err:
> > >     assert re.match(r'function .* exactly 1 argument;? \(?0
given\)?',
> > >                     str(err))
> > > else:
> > >     print 'no exception'
> > > Expecting: nothing
> > > Aborted
> > >
> > > and i assume this is because of the ABI / exception handling
problems. my
> > extension modules seem to work, except when they try to throw
exceptions.
> > >
> > > the only difference i can think of between computers is that the
computer
> > I was working on before had glibc version 2.2.5 installed, while the
rest
> > have 2.2.4 (it was in changing glibc back that the computer died)
> > >
> > > does anyone have any ideas on what i could do? again, sorry for sort
of
> > re-posting but i've worked at this and can't figure it out
> >
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
>
>





From dave at boost-consulting.com  Thu Aug 22 03:50:58 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 21:50:58 -0400
Subject: [C++-sig] more boost v1 problems
References: <3836623.1029977605100.JavaMail.portal@portal1.itservices.ubc.ca> <11ed01c24979$7ed2a640$6501a8c0@boostconsulting.com>
Message-ID: <124301c2497e$5f441700$6501a8c0@boostconsulting.com>

One more data point:

From: "David Abrahams" <dave at boost-consulting.com>


> All I can tell you offhand is:
>
> 0. 2.96 is not an official GCC release version
> 1. it is working for me here with GCC 3.2 on Debian.
> 2. This crash might well be due to a problem with C++ exception-handling.

3. It works fine for me here with GCC 3.0.4 on Debian


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From dave at boost-consulting.com  Thu Aug 22 04:02:18 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 Aug 2002 22:02:18 -0400
Subject: [C++-sig] bpl v2: classes with private constructors
References: <200208220153.06796.Peter.Schoen1@epost.de>
Message-ID: <124901c2497f$f4018610$6501a8c0@boostconsulting.com>

From: "Peter Schoen" <Peter.Schoen1 at epost.de>


> the constructors of some classes I am trying to wrap are private because
> instances must be created by using a factory. Is it possible to wrap such
> classes using bpl v2?

Sure. Of course you can only create the instances using the factory...

> Any links to examples, etc. would be highly appreciated.

if you look at libs/python/test/test_pointer_adoption.cpp you'll see the
factory function "create" is being used to generate new instances of class
A. It uses return_value_policy<manage_new_object> to instruct Python to
adopt the A* to hold the instance.

> In an older mail I read something about specifying the HeldType template
> argument of the class_<> template to solve such a problem, but I did not
> really understand this solution, yet, sorry.

Factory functions really ought to be generating smart pointers instead of
raw pointers. If you pass the smart pointer type as the HeldType parameter
to class_<> it ought to allow them to be returned from wrapped functions
such that the appropriate Python object gets built around them... however,
I'm not sure whether that's actually implemented yet...

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From dave at boost-consulting.com  Thu Aug 22 15:59:16 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 Aug 2002 09:59:16 -0400
Subject: [C++-sig] ANN: make_tuple()
Message-ID: <13f901c249e4$6a6350e0$6501a8c0@boostconsulting.com>

I've just added a family of boost::python::make_tuple(...) functions to
Boost.Python v2.
See libs/python/test/tuple.[py/cpp] for examples.

Note that if you've been using boost::make_tuple without qualification in
the past with using-directives for boost::python, you may need to add
qualification in order to avoid ambiguities.

Regards,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From achim.domma at syynx.de  Thu Aug 22 16:38:12 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Thu, 22 Aug 2002 16:38:12 +0200
Subject: [C++-sig] Documentation
Message-ID: <FCEMIEFBFOIDAOJDEPIAEENPDLAA.achim.domma@syynx.de>

Hi Dave,

I will have some time to contribute to boost.python, but I don't think that
I'm able to implement functionality or write documentation. I thought it
might be helpfull to prepare at least the html code for the docs. Do you
think it would be usefull, if I create files like the attached one where
somebody else could fill out the missing parts. So you would at least not
waste time with copy and paste and don't have to care about layout.

Achim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: list.zip
Type: application/x-zip-compressed
Size: 1465 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020822/14237b6b/attachment.bin>

From achim.domma at syynx.de  Thu Aug 22 17:29:16 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Thu, 22 Aug 2002 17:29:16 +0200
Subject: [C++-sig] missing throw_exception.hpp
Message-ID: <FCEMIEFBFOIDAOJDEPIACEOADLAA.achim.domma@syynx.de>

After an cvs update, shared_ptr.hpp is missing throw_exception.hpp. Is it my
mistake or is something wrong in CVS?

Achim





From dave at boost-consulting.com  Thu Aug 22 17:29:38 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 Aug 2002 11:29:38 -0400
Subject: [C++-sig] Documentation
References: <FCEMIEFBFOIDAOJDEPIAEENPDLAA.achim.domma@syynx.de>
Message-ID: <144c01c249f1$165ffa90$6501a8c0@boostconsulting.com>

Hi Achim,

Yes, those would be incredibly useful, thanks! Header docs should be based
on the template at libs/python/doc/v2/header.html, though, and should use
the other header docs I've already written as examples. In other words,
header.html does not include some things like descriptions of template
parameters, but you can find examples of those in some of my docs. If you
could manage to make templates for all of the v2 files matching
<boost/python/*.hpp> which don't already have docs, I'd be in heaven (but I
realize I may be dreaming)!

Thanks for the offer,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: "C++-Sig at Python. Org" <c++-sig at python.org>
Sent: Thursday, August 22, 2002 10:38 AM
Subject: [C++-sig] Documentation


> Hi Dave,
>
> I will have some time to contribute to boost.python, but I don't think
that
> I'm able to implement functionality or write documentation. I thought it
> might be helpfull to prepare at least the html code for the docs. Do you
> think it would be usefull, if I create files like the attached one where
> somebody else could fill out the missing parts. So you would at least not
> waste time with copy and paste and don't have to care about layout.
>
> Achim
>




From dave at boost-consulting.com  Thu Aug 22 18:09:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 Aug 2002 12:09:47 -0400
Subject: [C++-sig] List of Boost.Python projects?
Message-ID: <149201c249f6$5bb18be0$6501a8c0@boostconsulting.com>

If you have a project or product which uses Boost.Python, I would
appreciate it if you'd send me a link for the Boost.Python documentation.

Thanks,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From koning at pobox.com  Thu Aug 22 19:27:59 2002
From: koning at pobox.com (Joe Koning)
Date: Thu, 22 Aug 2002 10:27:59 -0700 (PDT)
Subject: [C++-sig] List of Boost.Python projects?
In-Reply-To: <149201c249f6$5bb18be0$6501a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.44.0208221025300.27221-100000@dhcp-37-2.attbi.com>

We are trying out the boost v2 functionality in our computational 
electrodynamics code:
http://www.llnl.gov/casc/emsolve


Joe

On Thu, 22 Aug 2002, David Abrahams wrote:

> If you have a project or product which uses Boost.Python, I would
> appreciate it if you'd send me a link for the Boost.Python documentation.
> 
> Thanks,
> Dave
> 
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 




From achim.domma at syynx.de  Thu Aug 22 23:21:45 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Thu, 22 Aug 2002 23:21:45 +0200
Subject: [C++-sig] cannot_convert_raw_PyObject
Message-ID: <FCEMIEFBFOIDAOJDEPIAOEOKDLAA.achim.domma@syynx.de>

Hi,

I get the following errors:

E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(168) : error
C2027: use of undefined type 'cannot_convert_raw_PyObject<struct _object *>'
        E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(167) :
while compiling class-template member function 'void __cdecl
boost::python::converter::detail::reject_raw_object_helper<struct
_object,char *>::error(char *)'
E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(168) : error
C2065: 'to_python_use_handle_instead' : undeclared identifier
        E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(167) :
while compiling class-template member function 'void __cdecl
boost::python::converter::detail::reject_raw_object_helper<struct
_object,char *>::error(char *)'

the only place where raw PyObject* is used is in Ralfs bpl_utils.h, but I
have no idea how to fix it (if that's the real problem). If I replace
PyObject* with handle<> the call of
boost::python::converter::registry::push_back fails. I looked at
boost/python/converter/implicit.hpp and saw, that there is also PyObject
used!? Any hint?

Achim





From dave at boost-consulting.com  Thu Aug 22 23:16:00 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 Aug 2002 17:16:00 -0400
Subject: [C++-sig] cannot_convert_raw_PyObject
References: <FCEMIEFBFOIDAOJDEPIAOEOKDLAA.achim.domma@syynx.de>
Message-ID: <16d501c24a21$21231a40$6501a8c0@boostconsulting.com>

Achim: there's not enough info here for me to help you.
Please go back and apply what you learned in "support requests 101" ;-)

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: "C++-Sig at Python. Org" <c++-sig at python.org>
Sent: Thursday, August 22, 2002 5:21 PM
Subject: [C++-sig] cannot_convert_raw_PyObject


> Hi,
>
> I get the following errors:
>
> E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(168) : error
> C2027: use of undefined type 'cannot_convert_raw_PyObject<struct _object
*>'
>         E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(167) :
> while compiling class-template member function 'void __cdecl
> boost::python::converter::detail::reject_raw_object_helper<struct
> _object,char *>::error(char *)'
> E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(168) : error
> C2065: 'to_python_use_handle_instead' : undeclared identifier
>         E:\cvsroot\boost\boost/python/converter/arg_to_python.hpp(167) :
> while compiling class-template member function 'void __cdecl
> boost::python::converter::detail::reject_raw_object_helper<struct
> _object,char *>::error(char *)'
>
> the only place where raw PyObject* is used is in Ralfs bpl_utils.h, but I
> have no idea how to fix it (if that's the real problem). If I replace
> PyObject* with handle<> the call of
> boost::python::converter::registry::push_back fails. I looked at
> boost/python/converter/implicit.hpp and saw, that there is also PyObject
> used!? Any hint?
>
> Achim
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From rwgk at yahoo.com  Fri Aug 23 01:47:11 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 22 Aug 2002 16:47:11 -0700 (PDT)
Subject: [C++-sig] cannot_convert_raw_PyObject
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAOEOKDLAA.achim.domma@syynx.de>
Message-ID: <20020822234711.9595.qmail@web20210.mail.yahoo.com>

--- Achim Domma <achim.domma at syynx.de> wrote:
> the only place where raw PyObject* is used is in Ralfs bpl_utils.h, but I

FWIW: I haven't updated the bpl_utils in a while and would not be surprised if
something is broken. Will get back to this in a few days.
Ralf


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com



From cseymour at interchange.ubc.ca  Fri Aug 23 02:50:02 2002
From: cseymour at interchange.ubc.ca (cseymour at interchange.ubc.ca)
Date: Thu, 22 Aug 2002 17:50:02 -0700
Subject: [C++-sig] more boost v1 problems
Message-ID: <8012116.1030063801992.JavaMail.portal@portal1.itservices.ubc.ca>

Okay this is weird

I have a small little sample shared library I use to test if exceptions are being handled correctly.

In building it, I used an old boost (1.25.1) library compiled with the Python 2.2.1 includes, the Python 2.2.1 includes, and libpython2.2.a. Then I ran it on another of our computers, using Python 2.1. And the sample exception worked perfectly (even though the Python API was newer ).

On my computer and others, in Python 2.2.1, when I try the sample exception (using the shared library built on the old computer, nothing has been rebuilt), it segfaults Python out.

So I think this means that my boost libraries aren't at fault, seeing as one of them built for 2.2.1 works fine with 2.1. The only difference between the old computer and the rest is that the old computer uses libm.so.6 and libc.so.6 pointing to 2.2.2 versions, while the rest of the computers are 2.2.4, and the old computer is running Python 2.1 while the others run Python 2.2.1.

Maybe someone at Mandrake put a weird configuration into the RPM's I've been using? I tried building gcc 3.0.4 on my own and it didn't help.

-----Original Message-----

> Date: Thu Aug 22 16:37:32 PDT 2002
> From: David Abrahams <dave at boost-consulting.com>
> Subject: Re: Re: Re: Re: [C++-sig] more boost v1 problems
> To: cseymour at interchange.ubc.ca
>
> Yup
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
> 
> 
> ----- Original Message -----
> From: <cseymour at interchange.ubc.ca>
> To: "David Abrahams" <dave at boost-consulting.com>
> Sent: Thursday, August 22, 2002 7:23 PM
> Subject: Re: Re: Re: Re: [C++-sig] more boost v1 problems
> 
> 
> > lol, the other i meant to say was /lib/libc.so.6, but i suppose thats
> 2.2.5 too...
> >
> >
> > -----Original Message-----
> >
> > > Date: Thu Aug 22 15:58:56 PDT 2002
> > > From: David Abrahams <dave at boost-consulting.com>
> > > Subject: Re: Re: Re: [C++-sig] more boost v1 problems
> > > To: cseymour at interchange.ubc.ca
> > >
> > >
> > >
> > > From: <cseymour at interchange.ubc.ca>
> > >
> > > > With your working copies... could you tell me what version of
> > > /lib/libm.so.6 and /lib/libm.so.6 you are using (eg, what they are
> > > symlinked to)?
> > >
> > > /lib/libm.so.6 and /lib/libm.so.6 are both linked to libm-2.2.5.so
> (since
> > > they have identical pathnames!)
> > >
> > > -----------------------------------------------------------
> > >            David Abrahams * Boost Consulting
> > > dave at boost-consulting.com * http://www.boost-consulting.com
> > >
> >
> >
> 





From achim.domma at syynx.de  Fri Aug 23 09:21:25 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Fri, 23 Aug 2002 09:21:25 +0200
Subject: [C++-sig] List of Boost.Python projects?
In-Reply-To: <149201c249f6$5bb18be0$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEPBDLAA.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
> If you have a project or product which uses Boost.Python, I would
> appreciate it if you'd send me a link for the Boost.Python documentation.

I'm using Boost.Python for a wrapper around ImageMagick:
pythonmagick.procoders.net

Achim





From dave at boost-consulting.com  Sat Aug 24 15:14:22 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Aug 2002 09:14:22 -0400
Subject: [C++-sig] convertibility and "Pythonicity"
Message-ID: <00ba01c24b70$304035d0$6501a8c0@boostconsulting.com>

[Is "Pythonicity" the right word?]

I'm interested in getting some qualitative feedback about something I'm
doing in Boost.Python. The questions are,
    1. How well does this behavior match up with what Python users have
probably come to expect?
    2. (related, I hope!) How close is it to the intended design of Python?


When wrapping a C++ function that expects a float argument, I thought it
would be bizarre if people couldn't pass a Python int. Well, Python ints
have a lovely __float__ function which can be used to convert them to
floats. Following that idea to its "logical" conclusion led me to where I
am today: when matching a formal argument corresponding to one of the
built-in Python types, first use the corresponding conversion slot.

That could lead to some surprising behaviors:

    char index(const char* s, int n); // wrapped using Boost.Python

    >>> index('foobar', 2)    # ok
    'o'

    >>> index(3.14, 1.2)      # Wierd (floats have __str__)
    '.'
    >>> index([1, 3, 5], 0.0) # Super wierd (everything has __str__)
    '['

So I went back and tried some "obvious" test in Python 2.2.1:

    >>> 'foobar'[3.0]
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: sequence index must be integer

Well, I had expected this to work, so I'm beginning to re-think my "liberal
conversion" policy. It seems like Python itself isn't using these slots to
do "implicit conversion". But then:

    >>> 'foobar'[3L]
    'b'

[The int/long unification I've heard about hasn't happened yet, has it?]

Furthermore:

    >>> range(3.3, 10.3)
    [3, 4, 5, 6, 7, 8, 9]

But:

    >>> range('1', '5')
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: an integer is required

Now I note that strings don't have __int__, so I guess the int type handles
int('42') itself using special knowledge about strings. I suppose that's to
keep strings from seeming to be numbers, since the nb_int slot fills in the
number_methods.

And:

    >>> class zero(object):
    ...     def __int__(self): return 0
    ...
    >>> range(zero(), 5)
    [0, 1, 2, 3, 4]

So, is there any general practice, (even if it's not universal)? Do Python
functions usually tend to coerce their arguments into the types they're
expecting? I'm guessing the answer is no...

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From dave at boost-consulting.com  Sat Aug 24 18:09:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Aug 2002 12:09:28 -0400
Subject: [C++-sig] Re: [Python-Dev] convertibility
References: <00b901c24b76$9aa4a220$6d94fea9@newmexico> <auto-000000027425@stlport.com>
Message-ID: <013b01c24b89$4c1d8140$6501a8c0@boostconsulting.com>

From: "Alex Martelli" <aleax at aleax.it>


> On Saturday 24 August 2002 04:00 pm, Samuele Pedroni wrote:
> ...
> > [yes with type categories or adapt we could do better,
> > but the design prefers to minimize unexpected behaviour,
> > and in practice is not too much constraining]
>
> As a happy user of Jython (albeit, so far, in modest amounts,
> and not yet in production-code), I want to add an unsolicited
> testimonial -- most of the time, the rules Jython applies "do
> what feels right" and prove (to me) unsurprising and unconstraining.
>
> After studying the rules in detail, particularly with overload resolution
in
> mind, I was afraid of many possible mishaps.  In practice, I find that
> it seems the rules don't get in my way and don't trip me up either.
> Whatever it is, there IS something right in those rules (perhaps just
> in conjunction with typical Java libraries, or perhaps more generally).

Hmm. When did Java acquire overload resolution?

I was surprised to see it here:
http://developer.java.sun.com/developer/TechTips/2000/tt0314.html

I was thinking of taking advantage of these rules for Boost.Python (and
Python itself), but I'm a little worried about the applicability of the
final part of the rules:

    if any method still under consideration has parameter
    types that are assignable to another method that's also still in
    play, then the other method is removed from consideration. This
    process is repeated until no other method can be eliminated. If the
    result is a single "most specific" method, then that method is
    called. If there's more than one method left, the call is ambiguous.

This rule is similar to the one used in C++ for partial ordering of
function templates. The problem is that my convertibility criteria examine
the actual objects involved in a conversion, not just their types. This
allows us to overload on sequence-of-float vs. sequence-of-string, for
example. Substitutability of argument types can't be tested without
exemplars of those types to work with.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Sun Aug 25 05:43:05 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 24 Aug 2002 20:43:05 -0700 (PDT)
Subject: [C++-sig] adding types to module A from modules B, C, etc.
Message-ID: <20020825034305.67775.qmail@web20203.mail.yahoo.com>

I have made good progress with exposing a family of C++ array types to
Python (of course via Boost.Python). At the Python level it works like
this:

from somewhere import flex
d = flex.double() # one-dimensional
d.append(3)
c = flex.complex_double(flex.grid((10,20,30))) # three-dimensional
# etc. for bool int, long, float and a few other types

I also need a number of arrays with custom element types. E.g. this
simple one:

t = flex.triple() # one-dimensional array of triples
t.append((1,2,3)) # append one triple

To make this generally usable, I'd like to separate the array toolbox
from the rest of my (crystallographic) application. At the same time
I'd like to avoid this:

from somewhere import standard_flex # with int, double, etc.
from somewhere_else import custom_flex # with triple and other custom types

In other words, I'd like to add additional types to a central module
flex from a number of other modules: the modules that expose the custom
types.

Isn't this related to Dave Hawke's ideas? Could I do it right now in V2?
If not, how difficult would it be do get there?

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From gideon at computer.org  Mon Aug 26 10:36:39 2002
From: gideon at computer.org (gideon may)
Date: Mon, 26 Aug 2002 10:36:39 +0200
Subject: [C++-sig] List of Boost.Python projects?
In-Reply-To: <149201c249f6$5bb18be0$6501a8c0@boostconsulting.com>
References: <149201c249f6$5bb18be0$6501a8c0@boostconsulting.com>
Message-ID: <2191120.1030358199@[10.0.0.1]>

I'm creating a wrapper around the OpenSceneGraph library: 
http://www.openscenegraph.org/
should have an alpha version in a couple of days.

gideon




From hugo at adept.co.za  Mon Aug 26 14:32:19 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Mon, 26 Aug 2002 14:32:19 +0200
Subject: [C++-sig] List of Boost.Python projects?
In-Reply-To: <2191120.1030358199@[10.0.0.1]>
References: <149201c249f6$5bb18be0$6501a8c0@boostconsulting.com> <2191120.1030358199@[10.0.0.1]>
Message-ID: <20020826123219.GB22620@vervet.localnet>

> I'm creating a wrapper around the OpenSceneGraph library: 
> http://www.openscenegraph.org/
> should have an alpha version in a couple of days.

Ah! Excellent! I created a wrapper for the Demeter terrain engine back
in December, but this has suffered tremendous bit rot (both Demeter has
changed a lot, and Boost.Python v2 is now a reality). I've started on a
Boost.Python v2 wrapper recently, and am hoping to get that in a usable
state three weeks from now. (For the next two weeks studies take
precedence.)

Reason I'm so happy about your OSG wrapper: Demeter is designed to be
used with OSG, so I was hoping to eventually get the Python wrapper to
work with OSG as well, but didn't yet feel up to the task of tackling
OSG myself. Further, I was worried someone will do a python wrapper of
OSG, but not use Boost.Python, resulting in incompatible wrappers, and
much less chance of a Boost.Python one happening. ;)

http://www.terrainengine.com/

Now very eager to yet again neglect studies,
Hugo van der Merwe



From rwgk at yahoo.com  Thu Aug 29 00:14:19 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 Aug 2002 15:14:19 -0700 (PDT)
Subject: [C++-sig] tuple::size()
Message-ID: <20020828221419.86314.qmail@web20204.mail.yahoo.com>

If I want to know the length of a tuple, list or dict, currently I have to
#include a certain file with a long path. On top of that, if I am not in
namespace boost::python, I have to type "boost::python::len(o)".

Points:

- Having to #include <boost/python/whatever.hpp> is cumbersome and brings more
code into scope than I really need.

- boost::python::len() is quite a bit of clutter.

- .size() is what one expects to have in C++.

- .size() could directly look at sq_length and thus generate less code.

David, would you be very upset if I added .size() to tuple.hpp, list.hpp and
dict.hpp?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From dave at boost-consulting.com  Thu Aug 29 07:58:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 Aug 2002 01:58:12 -0400
Subject: [C++-sig] tuple::size()
References: <20020828221419.86314.qmail@web20204.mail.yahoo.com>
Message-ID: <02a801c24f21$1a973f30$1c86db41@boostconsulting.com>

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


> If I want to know the length of a tuple, list or dict, currently I have
to
> #include a certain file with a long path.


Which file? I didn't think that was in the public library interfacee yet.
And, BTW:

    x.attr("__len__")()


> On top of that, if I am not in
> namespace boost::python, I have to type "boost::python::len(o)".

Is Koenig lookup broken on your compiler?
For MSVC, those names should be imported into std::

> Points:
>
> - Having to #include <boost/python/whatever.hpp> is cumbersome and brings
more
> code into scope than I really need.

How much stuff comes into scope all depends on how much stuff is in
whatever.hpp

> - boost::python::len() is quite a bit of clutter.

So don't use qualification.

> - .size() is what one expects to have in C++.
>
> - .size() could directly look at sq_length and thus generate less code.
>
> David, would you be very upset if I added .size() to tuple.hpp, list.hpp
and
> dict.hpp?

A little. I don't think that

    len(x)

is too cumbersome.

I want the interface for using those objects to look like the Python
interface. I don't think it's a good idea to use the C++ idioms. The next
thing you know, people will want mutable random-access iterators for
python::list, to make it act like std::vector... which would be fine if it
were possiblee (but it isn't).

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From camelo at esss.com.br  Thu Aug 29 14:33:14 2002
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Thu, 29 Aug 2002 09:33:14 -0300
Subject: [C++-sig] Pointers in boost::python 1.28
In-Reply-To: <02a801c24f21$1a973f30$1c86db41@boostconsulting.com>
Message-ID: <000001c24f58$3f259860$0d00000a@esss.com.br>

Hi all!

I'm using boost to expose a c++ framework to python, but I hit a wall
when trying to wrap a struct with pointer attributes (to a wrapped
type). Is it possible to do this?

I've tried to work around this by changing my design not to need the
pointer attribute any more. Now I've got a method that receives the
pointer as argument. Exporting this method goes fine unless I try to
make it virtual: the compiler complains that there isn't an appropriated
overloaded method for converting the pointer to python (sorry for not
having the exact error message at hand, It's a home project). Am I doing
something wrong?

Any help is welcome.

Camelo




From camelo at esss.com.br  Thu Aug 29 14:42:47 2002
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Thu, 29 Aug 2002 09:42:47 -0300
Subject: [C++-sig] Pointers in boost::python 1.28
In-Reply-To: <000001c24f58$3f259860$0d00000a@esss.com.br>
Message-ID: <000101c24f59$946a8e10$0d00000a@esss.com.br>

Just to clarify, the compiler complains when trying to instantiate
"callback<std::string>::call_method" on the overridden virtual method in
the derived callback class.

Cheers,

Camelo

-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of Marcelo A. Camelo
Sent: quinta-feira, 29 de agosto de 2002 09:33
To: c++-sig at python.org
Subject: [C++-sig] Pointers in boost::python 1.28

Hi all!

I'm using boost to expose a c++ framework to python, but I hit a wall
when trying to wrap a struct with pointer attributes (to a wrapped
type). Is it possible to do this?

I've tried to work around this by changing my design not to need the
pointer attribute any more. Now I've got a method that receives the
pointer as argument. Exporting this method goes fine unless I try to
make it virtual: the compiler complains that there isn't an appropriated
overloaded method for converting the pointer to python (sorry for not
having the exact error message at hand, It's a home project). Am I doing
something wrong?

Any help is welcome.

Camelo


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




From Peter.Schoen1 at web.de  Thu Aug 29 23:13:34 2002
From: Peter.Schoen1 at web.de (Peter Schoen)
Date: Thu, 29 Aug 2002 23:13:34 +0200
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
Message-ID: <200208292313.34491.Peter.Schoen1@web.de>

Dear y'all,

is it possible to compile Boost.Python v2 using the gcc 2.95.3 compiler (I am 
using SuSE 8)?

I tried to find the answer in the archive, but didn't succeed.

When I try to compile the lib with: "bjam -sTOOLS=gcc test", I get many 
template related erros. If others were able to compile the lib using 2.95.3, 
I can also post the error messages.

Many thanks & very best wishes

Peter







From djowel at gmx.co.uk  Fri Aug 30 11:06:54 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Fri, 30 Aug 2002 17:06:54 +0800
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
References: <200208292313.34491.Peter.Schoen1@web.de>
Message-ID: <000d01c25004$99e33210$0100a8c0@kim>

----- Original Message -----
From: "Peter Schoen" <Peter.Schoen1 at web.de>


Dear y'all,

is it possible to compile Boost.Python v2 using the gcc 2.95.3 compiler (I am
using SuSE 8)?

I tried to find the answer in the archive, but didn't succeed.

When I try to compile the lib with: "bjam -sTOOLS=gcc test", I get many
template related erros. If others were able to compile the lib using 2.95.3,
I can also post the error messages.

Many thanks & very best wishes

--------------------------------------------------------
Is this the error?

C:/dev/boost/boost/python/tuple.hpp:45: explicit specialization of non-template
`boost::python::converter::object_manager_traits<boost::python::tuple>'

If so, I have a fix. Just move the specialization before the instantiation:

//
// Converter Specializations    // $$$ JDG $$$ moved here to prevent
//                              // G++ bug complaining specialization
                                // provided after instantiation
namespace converter
{
  template <>
  struct object_manager_traits<tuple>
      : pytype_object_manager_traits<&PyTuple_Type,tuple>
  {
  };
}

// for completeness
inline tuple make_tuple() { return tuple(); }

# define BOOST_PP_ITERATION_PARAMS_1 (3, (1, BOOST_PYTHON_MAX_ARITY,
<boost/python/detail/make_tuple.hpp>))
# include BOOST_PP_ITERATE()

I hope this helps.
--Joel






From dave at boost-consulting.com  Fri Aug 30 16:00:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Aug 2002 10:00:40 -0400
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
References: <200208292313.34491.Peter.Schoen1@web.de>
Message-ID: <05fb01c2502d$d9e15990$1c86db41@boostconsulting.com>

----- Original Message -----
From: "Peter Schoen" <Peter.Schoen1 at web.de>


<<is it possible to compile Boost.Python v2 using the gcc 2.95.3 compiler
(I am
using SuSE 8)?>>

Yes, I test with that front-end regularly.

<<When I try to compile the lib with: "bjam -sTOOLS=gcc test", I get many
template related erros. If others were able to compile the lib using
2.95.3,
I can also post the error messages.>>

I'd be interested to see those.



-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From dave at boost-consulting.com  Fri Aug 30 17:01:24 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Aug 2002 11:01:24 -0400
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
References: <200208292313.34491.Peter.Schoen1@web.de> <05fb01c2502d$d9e15990$1c86db41@boostconsulting.com>
Message-ID: <06c001c25036$49c330a0$1c86db41@boostconsulting.com>

From: "David Abrahams" <dave at boost-consulting.com>
> From: "Peter Schoen" <Peter.Schoen1 at web.de>

> <<When I try to compile the lib with: "bjam -sTOOLS=gcc test", I get many
> template related erros. If others were able to compile the lib using
> 2.95.3,
> I can also post the error messages.>>
>
> I'd be interested to see those.

I see that the fix Joel posted (and checked into CVS) was also sitting on
my hard disk, waiting to be checked in. Everything *should* be fine now.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From psteenwinkel at caucasus.net  Fri Aug 30 16:14:22 2002
From: psteenwinkel at caucasus.net (Peter Steenwinkel)
Date: Fri, 30 Aug 2002 19:14:22 +0500
Subject: [C++-sig] offer-invitation
Message-ID: <008301c2502f$a63e9740$0100007f@user>

Helllo,
First, let me talk one joke-parable:
Once, a man was perishing in a river and wanting a help he had begun to cry the heavens ? God! Save me! ...
Continuation  see http://www.geocities.com/makeincome2002 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020830/163cc53f/attachment.htm>

From dave at boost-consulting.com  Fri Aug 30 19:11:25 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Aug 2002 13:11:25 -0400
Subject: [C++-sig] Pointers in boost::python 1.28
References: <000001c24f58$3f259860$0d00000a@esss.com.br>
Message-ID: <082201c25048$b97bc940$1c86db41@boostconsulting.com>

From: "Marcelo A. Camelo" <camelo at esss.com.br>


> Hi all!
>
> I'm using boost to expose a c++ framework to python, but I hit a wall
> when trying to wrap a struct with pointer attributes (to a wrapped
> type). Is it possible to do this?

I'm not sure. What do you expect the result to be, in Python, when you
access these attributes?

Also, which version of Boost.Python are you using (v1 or v2?)

> I've tried to work around this by changing my design not to need the
> pointer attribute any more. Now I've got a method that receives the
> pointer as argument. Exporting this method goes fine unless I try to
> make it virtual: the compiler complains that there isn't an appropriated
> overloaded method for converting the pointer to python (sorry for not
> having the exact error message at hand, It's a home project). Am I doing
> something wrong?

We'll need a lot more data to be able to give you a useful answer.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From Peter.Schoen1 at web.de  Fri Aug 30 20:41:05 2002
From: Peter.Schoen1 at web.de (Peter Schoen)
Date: Fri, 30 Aug 2002 20:41:05 +0200
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
Message-ID: <200208302041.10213.Peter.Schoen1@web.de>

Hi!

From: "David Abrahams" <dave at boost-consulting.com>
> From: "Peter Schoen" <Peter.Schoen1 at web.de>

>> When I try to compile the lib with: "bjam -sTOOLS=gcc test", I get many
>> template related erros. If others were able to compile the lib using
>> 2.95.3, I can also post the error messages.

>I see that the fix Joel posted (and checked into CVS) was also sitting on
>my hard disk, waiting to be checked in. Everything *should* be fine now.

Yes, that solved the problem, many thanks.

-Peter-



From rwgk at yahoo.com  Fri Aug 30 23:00:25 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 30 Aug 2002 14:00:25 -0700 (PDT)
Subject: [C++-sig] "bpl_utils" reorganized
Message-ID: <20020830210025.67159.qmail@web20210.mail.yahoo.com>

For those who are using the "bpl_utils":

The name has changed, and the code has been reorganized. It is now
part of the "scitbx" module (under the old "cctbx" cvs project).
The container conversions can be found in this directory:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/boost_python/

File name:
  container_conversions.h 

The regression test is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/

File names:
  regression_test_module.cpp
  regression_test.py

Example usage:

    scitbx::boost_python::container_conversions::from_python_sequence<
      std::vector<double>,
      scitbx::boost_python::container_conversions::variable_capacity_policy>();

Fragment from regression_test.py to illustrate how it works from Python:

  assert rt.std_vector((8,9,10)) == 27
  assert rt.std_vector([7,9,10]) == 26
  assert rt.std_vector(iter(xrange(10,13))) == 33
  assert rt.std_vector((8,9,10,11)) == 38

Tested against the latest boost cvs.

Ralf

P.S.: To check out the scitbx module for convenient access to the files:

cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx co scitbx
boa:/net/cci/rwgk % 
boa:/net/cci/rwgk % 
boa:/net/cci/rwgk % cat zmsg
For those who are using the "bpl_utils":

The name has changed, and the code has been reorganized. It is now
part of the "scitbx" module (under the old "cctbx" cvs project).
The container conversions can be found in this directory:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/boost_python/

File name:
  container_conversions.h 

The regression test is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/

File names:
  regression_test_module.cpp
  regression_test.py

Example usage:

    scitbx::boost_python::container_conversions::from_python_sequence<
      std::vector<double>,
      scitbx::boost_python::container_conversions::variable_capacity_policy>();

Fragment from regression_test.py to illustrate how it works from Python:

  assert rt.std_vector((8,9,10)) == 27
  assert rt.std_vector([7,9,10]) == 26
  assert rt.std_vector(iter(xrange(10,13))) == 33
  assert rt.std_vector((8,9,10,11)) == 38

Tested against the latest boost cvs.

Ralf

P.S.: To check out the scitbx module for convenient access to the files:

cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx co scitbx


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From rwgk at yahoo.com  Sat Aug 31 00:03:09 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 30 Aug 2002 15:03:09 -0700 (PDT)
Subject: [C++-sig] lvalue converter (and other) questions
Message-ID: <20020830220309.81290.qmail@web20202.mail.yahoo.com>

I have questions (for David), but first the

Context:

I have made a new cvs module scitbx that contains an "array_family"
incl. Python bindings. At the C++ level there is the type

  shared<ElementType>

which is just like std::vector, but reference counted or IOW with
shallow copy semantics. Then there is the type

  versa<ElementType, AccessorType>

to cover multi-dimensional arrays (or arrays with any other method
for accessing the elements). versa inherits<> from shared<>.
At the C++ level I have two general accessor types (among others):

  grid<N> // number of dimensions N known at compile-time
  flex_grid<> // number of dimensions determined at run-time

To minimize the memory footprint for the Python bindings, only
one array type is visible in Python:

  C++: versa<ElementType, flex_grid<> >
  Python: flex.int, flex.double, etc.

shared<T> and versa<T, grid<N> > are automatically mapped (two-way) to
versa<ElementType, flex_grid<> >/flex.xxx: only the accessor is
changed, the actual data are not copied or modified. The shared<->flex
mappings are achieved with the code in this file:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/array_family/boost_python/shared_flex_conversions.h?rev=1.1&content-type=text/vnd.viewcvs-markup

First question:

Fragment from the file referenced above:

    static void* convertible(PyObject* obj_ptr)
    {
      using namespace boost::python;
      object obj(borrowed(obj_ptr));
      extract<flex_type const&> flex_proxy(obj);
      if (!flex_proxy.check()) return 0;
      //...
    }

Am I using extract<> in the intended way?
Is there a more direct way to just check the type? Something similar
to PyInt_Check(), e.g.

      if (!boost::python::class_check<flex_type>(obj_ptr)) return 0;

Would using this make sense as an optimization: extract<> is only
called after this test?

Second question:

If I understand correctly, struct shared_from_flex in the reference
code implements an rvalue converter only. However, I am also interested
in a similar lvalue converter. Here is an example of what I am doing at
the moment (btw: the C++ language /really/ needs template typedefs):

    static void
    push_back(versa<ElementType, flex_grid<> >& a, ElementType const& x)
    {
      // first check that "a" is a 0-based, 1-dimensional, unpadded array
      // and then convert "a" to a shared<ElementType>
      base_array_type b = flex_as_base_array(a);
      b.push_back(x);
      // make a new (1-dimensional) accessor for "a".
      a.resize(flex_grid<>(b.size()));
    }

Could I do it like this if I had an lvalue converter?

    static void
    push_back(shared<ElementType>& a, ElementType const& x)
    {
      a.push_back(x);
    }

This would require that the lvalue converter can do the a.resize()
after push_back() returns. Is this possible (and where can I find an
example for creating a lvalue converter)?

Another question, related to the previous one:

Since push_back() is .def'ed as a member function of a wrapped
versa<T,A> there is an additional concern: the first argument is a
shared<T>& instead of a versa<T,A>& . Will this work/is it safe?

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From dave at boost-consulting.com  Sat Aug 31 01:14:03 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Aug 2002 19:14:03 -0400
Subject: [C++-sig] lvalue converter (and other) questions
References: <20020830220309.81290.qmail@web20202.mail.yahoo.com>
Message-ID: <0acc01c2507a$f09eb400$1c86db41@boostconsulting.com>

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

> First question:
>
> Fragment from the file referenced above:
>
>     static void* convertible(PyObject* obj_ptr)
>     {
>       using namespace boost::python;
>       object obj(borrowed(obj_ptr));
>       extract<flex_type const&> flex_proxy(obj);
>       if (!flex_proxy.check()) return 0;
>       //...
>     }
>
> Am I using extract<> in the intended way?

Yes.

> Is there a more direct way to just check the type? Something similar
> to PyInt_Check(), e.g.
>
>       if (!boost::python::class_check<flex_type>(obj_ptr)) return 0;

We could write one. However, this check would fail for some C++ wrapped
class derived from flex_type, whereas the one above would not.

> Would using this make sense as an optimization: extract<> is only
> called after this test?

No, extract<> will still do the check when you ask it to convert the source
object, so your class_check would be wasted effort.

> Second question:
>
> If I understand correctly, struct shared_from_flex in the reference
> code implements an rvalue converter only.

Yup.

> However, I am also interested
> in a similar lvalue converter. Here is an example of what I am doing at
> the moment (btw: the C++ language /really/ needs template typedefs):

(btw: it's pretty hard to see why from your example)

>     static void
>     push_back(versa<ElementType, flex_grid<> >& a, ElementType const& x)
>     {
>       // first check that "a" is a 0-based, 1-dimensional, unpadded array
>       // and then convert "a" to a shared<ElementType>
>       base_array_type b = flex_as_base_array(a);
>       b.push_back(x);
>       // make a new (1-dimensional) accessor for "a".
>       a.resize(flex_grid<>(b.size()));
>     }
>
> Could I do it like this if I had an lvalue converter?
>
>     static void
>     push_back(shared<ElementType>& a, ElementType const& x)
>     {
>       a.push_back(x);
>     }
>
> This would require that the lvalue converter can do the a.resize()
> after push_back() returns. Is this possible (and where can I find an
> example for creating a lvalue converter)?

If shared<E> is already exposed via class_<>, it's already done.
In which case, consider:

    static void
    push_back(back_reference<shared<ElementType>&> b, ElementType const& x)
    {
        b.get().push_back(x);
        extract<versa<ElementType, flex_grid<> >&> x(b.source());
        ... // use x to get at the outer versa object.
    }

> Another question, related to the previous one:
>
> Since push_back() is .def'ed as a member function of a wrapped
> versa<T,A> there is an additional concern: the first argument is a
> shared<T>& instead of a versa<T,A>& . Will this work/is it safe?

It's safe. It'll work if shared<T> is declared in a bases<...> clause for
class_<versa<T>, ...>

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Sat Aug 31 01:58:16 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 30 Aug 2002 16:58:16 -0700 (PDT)
Subject: [C++-sig] lvalue converter (and other) questions
In-Reply-To: <0acc01c2507a$f09eb400$1c86db41@boostconsulting.com>
Message-ID: <20020830235816.89739.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > the moment (btw: the C++ language /really/ needs template typedefs):
> 
> (btw: it's pretty hard to see why from your example)

Isn't

flex<ElementType>

a lot nicer than repeating

versa<ElementType, flex_grid<> >

all the time? With:

template <typename ElementType>
typedef versa<ElementType, flex_grid<> > flex;

> If shared<E> is already exposed via class_<>, it's already done.
> In which case, consider:

Note what this struct in the referenced code is doing:

  template <typename ElementType>
  struct shared_to_flex
  {
    static PyObject* convert(shared_plain<ElementType> const& a)
    {
      using namespace boost::python;
      versa<ElementType, flex_grid<> > result(a, flex_grid<>(a.size()));
      return incref(object(result).ptr());
    }
  };

It constructs a flex<E> from a shared<E> and then uses object() to wrap it up
for Python.
Can I have a class_<shared<E> > at the same time? How could bpl.so decide what
pops up the the Python layer? I want the flex<E>. flex<E> has a large number of
associated member/regular functions that I do not wish to bind another time for
shared<E>. Look at this file to see the damage:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/array_family/boost_python/flex_wrapper.h?rev=1.5&content-type=text/vnd.viewcvs-markup

Note that the entire file is one large template (well, one small and one
large). In addition there is the pickle suite (file names flex_pickle_*.h in
the same directory). Currently I use this to define eight Python types (bool,
std::size_t, int, long, float, double, std::complex<double>, std::string).
Sizes of the resulting flex.so/.pyd modules:

vc70, 800k
tru64 cxx, -O2, 12M unstripped, 11M stripped
linux gcc 3.0.4, -g, 80M unstripped, 6M stripped

And that is just the beginning. I still have a bunch of custom types to wrap.
While vc70 is very tame, I will have to buy an extra harddisk for my Linux
compilations if I duplicate everything for shared<E> and flex<E>. In addition,
at the Python level there is no point at all in having the two types. One is
better.

Thanks,
Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From dave at boost-consulting.com  Sat Aug 31 02:45:25 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Aug 2002 20:45:25 -0400
Subject: [C++-sig] lvalue converter (and other) questions
References: <20020830235816.89739.qmail@web20207.mail.yahoo.com>
Message-ID: <0b3901c25088$2d4d4c10$1c86db41@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > > the moment (btw: the C++ language /really/ needs template typedefs):
> >
> > (btw: it's pretty hard to see why from your example)
>
> Isn't
>
> flex<ElementType>
>
> a lot nicer than repeating
>
> versa<ElementType, flex_grid<> >
>
> all the time? With:
>
> template <typename ElementType>
> typedef versa<ElementType, flex_grid<> > flex;

Sure. For now you can do it with:

    typename flex<ElementType>::type

FWIW.

> > If shared<E> is already exposed via class_<>, it's already done.
> > In which case, consider:
>
> Note what this struct in the referenced code is doing:
>
>   template <typename ElementType>
>   struct shared_to_flex
>   {
>     static PyObject* convert(shared_plain<ElementType> const& a)
>     {
>       using namespace boost::python;
>       versa<ElementType, flex_grid<> > result(a, flex_grid<>(a.size()));
>       return incref(object(result).ptr());
>     }
>   };
>
> It constructs a flex<E> from a shared<E> and then uses object() to wrap
it up
> for Python.

Ah. I thought you said that versa<> was derived from shared<>, but it
appears now to just be a handle (as shared<> is the body in the handle/body
idiom).

This seems to be very similar to what happens with all of the object
manager types in Boost.Python: e.g., object, list, tuple, dict...

Each of these, though not contained in the corresponding Python object, can
bind to a non-const reference argument since it is merely a wrapper around
some other value. I'm not sure what it would take to generalize this
mechanism to handle cases like yours.

> Can I have a class_<shared<E> > at the same time?

Sure (why not?), but I'm not sure any longer that it will help you.

> How could bpl.so decide what
> pops up the the Python layer?

I don't understand the question.

> I want the flex<E>. flex<E> has a large number of
> associated member/regular functions that I do not wish to bind another
time for
> shared<E>. Look at this file to see the damage:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/
array_family/boost_python/flex_wrapper.h?rev=1.5&content-type=text/vnd.view
cvs-markup
>
> Note that the entire file is one large template (well, one small and one
> large). In addition there is the pickle suite (file names flex_pickle_*.h
in
> the same directory). Currently I use this to define eight Python types
(bool,
> std::size_t, int, long, float, double, std::complex<double>,
std::string).
> Sizes of the resulting flex.so/.pyd modules:
>
> vc70, 800k
> tru64 cxx, -O2, 12M unstripped, 11M stripped
> linux gcc 3.0.4, -g, 80M unstripped, 6M stripped

Surely these are not the numbers with full optimization and inlining?!?

> And that is just the beginning. I still have a bunch of custom types to
wrap.
> While vc70 is very tame, I will have to buy an extra harddisk for my
Linux
> compilations if I duplicate everything for shared<E> and flex<E>. In
addition,
> at the Python level there is no point at all in having the two types. One
is
> better.

Ralf, this is clearly a non-trivial problem, and I clearly don't yet
understand it at a deep level. The best I can do is to point you at
boost/python/converter/obj_mgr_arg_from_python.hpp and
boost/python/converter/object_manager_traits.hpp. A generalized mechanism
to deal with handle/body designs is a worthy goal.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Sat Aug 31 06:47:20 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 30 Aug 2002 21:47:20 -0700 (PDT)
Subject: [C++-sig] lvalue converter (and other) questions
In-Reply-To: <0b3901c25088$2d4d4c10$1c86db41@boostconsulting.com>
Message-ID: <20020831044720.37093.qmail@web20203.mail.yahoo.com>

> > Can I have a class_<shared<E> > at the same time?
> 
> Sure (why not?), but I'm not sure any longer that it will help you.
> 
> > How could bpl.so decide what
> > pops up the the Python layer?
> 
> I don't understand the question.

Say I have a function

shared<double> return_shared();

In Python:

a = return_shared()
type(a) # what will I get here?

As said, I want to see flex.double, not shared.double.

> Ralf, this is clearly a non-trivial problem, and I clearly don't yet
> understand it at a deep level.

Here is an idea for an implementation that would work for me.
It is a generalized version of the rvalue converter:

  template <typename WrappedType>
  struct lvalue_conversion_policy
  {
    BOOST_STATIC_CONSTANT(bool, enable_lvalue_conversion = false);

    // This is meant to be called after the function that uses the
    // lvalue returned, but before we get back to the Python interpreter.
    static void post_call(
      PyObject* obj_ptr,
      converter::rvalue_from_python_stage1_data* data)
    {
      // do nothing by default; should optimize away
    }
  };

  // Now the full specialization for a particular type.
  // Since we have to do without partial specialization I could
  // use inheritance to make this easy to use with multiple types.
  template <>
  struct lvalue_conversion_policy<shared<double> >
  {
    // Tell the registry that this should participate in lvalue conversions.
    BOOST_STATIC_CONSTANT(bool, enable_lvalue_conversion = true);

    typedef shared<double> shared_type;
    typedef versa<double, flex_grid<> > flex_type;

    static void post_call(
      PyObject* obj_ptr,
      converter::rvalue_from_python_stage1_data* data)
    {
      object obj(borrowed(obj_ptr));
      flex_type& a = extract<flex_type&>(obj)();
      assert(a.accessor().nd() == 1);
      assert(a.accessor().is_0_based());
      assert(!a.accessor().is_padded());
      shared_type& b = *(reinterpret_cast<shared_type*>(data->convertible));
      a.resize(flex_grid<>(b.size());
    }
  };

  template <typename SharedType>
  struct shared_from_flex
  {
    typedef typename SharedType::value_type element_type;
    typedef versa<element_type, flex_grid<> > flex_type;

    shared_from_flex()
    {
      converter::registry::push_back(
        &convertible,
        &construct,
        type_id<SharedType>());
    }

    static void* convertible(PyObject* obj_ptr)
    {
      using namespace boost::python;
      object obj(borrowed(obj_ptr));
      extract<flex_type&> flex_proxy(obj);
      if (!flex_proxy.check()) return 0;
      flex_type& a = flex_proxy();
      if (a.accessor().nd() != 1) return 0;
      if (!a.accessor().is_0_based()) return 0;
      if (a.accessor().is_padded()) return 0;
      return obj_ptr;
    }

    static void construct(
      PyObject* obj_ptr,
      converter::rvalue_from_python_stage1_data* data)
    {
      using namespace boost::python;
      object obj(borrowed(obj_ptr));
      flex_type& a = extract<flex_type&>(obj)();
      assert(a.accessor().nd() == 1);
      assert(a.accessor().is_0_based());
      assert(!a.accessor().is_padded());
      void* storage = (
        (converter::rvalue_from_python_storage<SharedType>*)
          data)->storage.bytes;
      new (storage) SharedType(a);
      data->convertible = storage;
    }
  };

Is there hope that this or something similar could be done?
Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com