From rwgk at yahoo.com  Sun Sep  1 09:09:44 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 1 Sep 2002 00:09:44 -0700 (PDT)
Subject: [C++-sig] "bpl_utils" reorganized
In-Reply-To: <15729.31819.782499.729350@gull.eos.ubc.ca>
Message-ID: <20020901070944.96264.qmail@web20201.mail.yahoo.com>

For David Abrahams: please see question at end. Thanks.

--- Philip Austin <paustin at eos.ubc.ca> wrote:
> FYI the array_family tests run fine using: gcc version 3.0.4 (Mandrake
> Linux 8.2 3.0.4-2mdk) (save for multiple warnings in tst_af_1 like:
> /nfs/roc/home/phil/scitbx/include/scitbx/array_family/small_plain.h:67:
> warning: comparison between signed and unsigned integer expressions

I am aware of this, and a while ago I asked in a gcc forum if it is
possible to disable this warning specifically. Eventually I fell back
to using -w for all my gcc compilation.
Note that I am also using VC7, Metrowerks 7 & 8, and various
EDG front-ends. gcc is the only compiler that warns about the
comparison.

> (plus the spelling typo:
> array_excercise<ArrayType>)

Thanks for spotting this! It is fixed in cvs.

> and a warning in tst_af_4:
> 
> tst_af_4.cpp:223: warning: passing `const double' for argument 1 of `void 
>    <unnamed>::a_value<ValueType>::m_init(const ValueType&) [with ValueType = 
>    int]'

Hm. This doesn't show up when using -w. Again, none of the other
compilers complains. Unfortunately I don't have time right now to
massage the regression test to make gcc happy.

> But the tests fail to compile with gcc version 3.2. Typical 
> errors for tst_af_1 are:

I just bumped up the gcc version number in an #ifdef clause. On my
platform (RH 7.3) gcc 3.2 with the -w option compiles the entire scitbx
(and -lbpl) without a glitch.
The long-term plan is to use the alignment calculator that comes with
boost (wasn't there when I started the array_family).
David A.: is the boost alignment calculator connected
to the meta-programming library? If not, is it "stable?"

Ralf


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



From dave at boost-consulting.com  Sun Sep  1 15:22:31 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 1 Sep 2002 09:22:31 -0400
Subject: [C++-sig] "bpl_utils" reorganized
References: <20020901070944.96264.qmail@web20201.mail.yahoo.com>
Message-ID: <0ead01c251ba$c729fda0$1c86db41@boostconsulting.com>

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

> boost (wasn't there when I started the array_family).
> David A.: is the boost alignment calculator connected
> to the meta-programming library? If not, is it "stable?"

boost::alignof<T> has been available and stable as part of the type traits
library for at least a couple of releases.

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





From dave at boost-consulting.com  Mon Sep  2 04:26:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 1 Sep 2002 22:26:07 -0400
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
Message-ID: <111201c25228$1c9a29f0$1c86db41@boostconsulting.com>

Currently, Boost.Python v2 registers from_python converters for the
following categories of builtin C++ target types:

  integer (e.g. signed char,      use the source type's
  unsigned short, int, long...)   __int__() method, if any

  floating (e.g. float,           use the source type's
  double, long double)            __float__ method, if any

  long (e.g. long long,           use the source type's
  unsigned long long)             __long__ method, if any

  boolean (bool)                  checks PyObject_IsTrue

  string (e.g. const char*,       use the source type's
  std::string, char...)           __str__() method, if any

[The rules are actually slightly more sophisticated: see
libs/python/src/converter/builtin_converters.cpp for details]

These facts lead to some unpleasant truths. For example, if you overload
these two functions, only one of them can be called using the built-in
python types as arguments:

  void f(int);        // case 1
  void f(double);

The reason is that Python int has a __float__ method, and Python float has
an __int__ method. Whichever one you def() first will be called, whether
you pass a Python int or a float. Perhaps just as bad is the fact that you
can pass almost anything to this function:

  void g(char const*);   // case 2

Of course the reason is that almost everything has a __str__ method.

After some generous prompting from David Beazly (the man behind SWIG) about
overload resolution, I think I'm ready to change these rules. Our
conversation convinced me that although a more-sophisticated conversion
mechanism which uses the closest matching signature is probably "more
correct", simply making the conversion rules a bit less liberal will cover
99% of all cases.

There are two different problems illustrated above:

- case 1: a cycle in the convertibility graph between floats and ints. It
seems as though many systems (including SWIG and Jython) solve this problem
by breaking the cycle so that an int can be converted to a float, but not
vice-versa. I think the intention is that conversions should not be lossy,
though of course there's no guarantee that you can convert from int to
float without at least losing precision.

- case 2: just plain "too liberal". It would be better to get an error than
silent misbehavior if you pass an integer where a string is expected.

The current scheme gets us some nice generality: any numeric type is likely
to have a __float__ method, so a user who implements a rational number
class in Python doesn't have to do anything special to allow it to be
passed where a C++ double is expected. However, IMO, the cost for this
generality is simply too high.

So, I propose to change the built-in conversion rules for the C++ builtin
types as follows (note that users can explicitly add new conversions to any
of these target types):

  integer/long  require Python int or Python long (or subtype)
  floating      use the source type's __float__ method, if any
  boolean       require Python int (or subtype)
  string        require Python str (or subtype)

It looks like we can actually get away with keeping the same rule for
floating types, though please speak up if you see some actual danger here.
I'm also interested in opinions on whether Python unicode should be
convertible to C++ string types.

Opinions?

Dave

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






From pearu at cens.ioc.ee  Mon Sep  2 12:30:58 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 2 Sep 2002 13:30:58 +0300 (EEST)
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
In-Reply-To: <111201c25228$1c9a29f0$1c86db41@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0209021316570.25298-100000@cens.kybi>

On Sun, 1 Sep 2002, David Abrahams wrote:

<snip>

> So, I propose to change the built-in conversion rules for the C++ builtin
> types as follows (note that users can explicitly add new conversions to any
> of these target types):
> 
>   integer/long  require Python int or Python long (or subtype)
>   floating      use the source type's __float__ method, if any
>   boolean       require Python int (or subtype)
>   string        require Python str (or subtype)
> 
> It looks like we can actually get away with keeping the same rule for
> floating types, though please speak up if you see some actual danger here.
> I'm also interested in opinions on whether Python unicode should be
> convertible to C++ string types.
> 
> Opinions?

I am all +1 for this rule change. It will solve the problem, caused
exactly by the current "too liberal" behaviour, that I described few
months ago. Namely, I was trying to wrap GiNaC library that has numeric
class representing arbitrary long integers and arbitrary precision floats.
Then I could not use constructors
  numeric(int)
  numeric(double)
(in that order) that would convert any Python float to integer (and
loosing information by this) or
  numeric(double)
  numeric(int)
that would convert any Python int or long to float (and loosing precision 
by this). I solved it by introducing the wrapper for GiNaC::numeric so
that
  numeric(PyObject*)
would take care of suitable conversation. However, this introduced many
other problems and the interface code were becoming too big so that I
stilled the project. After this rule change I might finalize wrapping
GiNaC...

Thanks,
	Pearu




From dave at boost-consulting.com  Mon Sep  2 14:39:20 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 2 Sep 2002 08:39:20 -0400
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
References: <Pine.LNX.4.21.0209021316570.25298-100000@cens.kybi>
Message-ID: <11bb01c2527e$6ded7270$1c86db41@boostconsulting.com>

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


>
> On Sun, 1 Sep 2002, David Abrahams wrote:
>
> <snip>
>
> > So, I propose to change the built-in conversion rules for the C++
builtin
> > types as follows (note that users can explicitly add new conversions to
any
> > of these target types):
> >
> >   integer/long  require Python int or Python long (or subtype)
> >   floating      use the source type's __float__ method, if any
> >   boolean       require Python int (or subtype)
> >   string        require Python str (or subtype)
> >
> > It looks like we can actually get away with keeping the same rule for
> > floating types, though please speak up if you see some actual danger
here.
> > I'm also interested in opinions on whether Python unicode should be
> > convertible to C++ string types.
> >
> > Opinions?
>
> I am all +1 for this rule change. It will solve the problem, caused
> exactly by the current "too liberal" behaviour, that I described few
> months ago. Namely, I was trying to wrap GiNaC library that has numeric
> class representing arbitrary long integers and arbitrary precision
floats.
> Then I could not use constructors
>   numeric(int)
>   numeric(double)
> (in that order) that would convert any Python float to integer (and
> loosing information by this) or
>   numeric(double)
>   numeric(int)
> that would convert any Python int or long to float (and loosing precision
> by this). I solved it by introducing the wrapper for GiNaC::numeric so
> that
>   numeric(PyObject*)
> would take care of suitable conversation. However, this introduced many
> other problems and the interface code were becoming too big so that I
> stilled the project. After this rule change I might finalize wrapping
> GiNaC...

Fabulous, Pearu! Any chance you'd like to submit a patch for
libs/python/src/converter/builtin_converters.cpp which implements the
change?

-Dave

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





From pearu at cens.ioc.ee  Mon Sep  2 15:02:08 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 2 Sep 2002 16:02:08 +0300 (EEST)
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
In-Reply-To: <11bb01c2527e$6ded7270$1c86db41@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0209021552060.31949-100000@cens.kybi>

On Mon, 2 Sep 2002, David Abrahams wrote:

> Fabulous, Pearu! Any chance you'd like to submit a patch for
> libs/python/src/converter/builtin_converters.cpp which implements the
> change?

I am afraid it is not so Fabulous, Pearu. I am currently way too
overloaded with my daily work and as well with other OS projects that I
could not take this challenge at this moment. Sorry.

Pearu




From dave at boost-consulting.com  Mon Sep  2 16:28:20 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 2 Sep 2002 10:28:20 -0400
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
References: <Pine.LNX.4.21.0209021552060.31949-100000@cens.kybi>
Message-ID: <120a01c2528c$fe9398a0$1c86db41@boostconsulting.com>

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


>
> On Mon, 2 Sep 2002, David Abrahams wrote:
>
> > Fabulous, Pearu! Any chance you'd like to submit a patch for
> > libs/python/src/converter/builtin_converters.cpp which implements the
> > change?
>
> I am afraid it is not so Fabulous, Pearu.

No, it really is fabulous. I always like it when a simple change makes it
possible for someone to use the library where it would otherwise have been
too difficult.

> I am currently way too
> overloaded with my daily work and as well with other OS projects that I
> could not take this challenge at this moment. Sorry.

Well, I'm sorry to hear that. However, it's not so terrible; it just means
that it might take a little longer to get it into the library.

-Dave

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





From dave at boost-consulting.com  Tue Sep  3 01:19:58 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 2 Sep 2002 19:19:58 -0400
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
References: <Pine.LNX.4.21.0209021552060.31949-100000@cens.kybi> <120a01c2528c$fe9398a0$1c86db41@boostconsulting.com>
Message-ID: <136401c252d7$43346a30$1c86db41@boostconsulting.com>

As it turns out, I couldn't stand the status quo, so I impulsively changed
the built-in conversion rules in the CVS. The new rules are as follows:

C++ target type       built-in conversions from Python types
---------------       --------------------------------------
signed/unsigned       int,long
char,short,int,long,
long long

float,double,        int,long,float
long double

complex<float>,      int,long,float,complex
complex<double>,
complex<long double>

bool                 int, NoneType (=>false)

std::string          str
char

char const*          str, NoneType (=>NULL)

-------

One thing notably no longer handled automatically is the conversion of
user-defined Python classes to built-in C++ numeric types.

Please let me know if this change causes any upheaval. I've attached a diff
of the Python test files I had to change in order to keep all the tests
passing.

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020902/5ab1bc83/attachment.txt>

From dave at boost-consulting.com  Tue Sep  3 08:01:36 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 3 Sep 2002 02:01:36 -0400
Subject: [C++-sig] Boost.Python v2: module objects deprecated
Message-ID: <149101c2530f$5e0d4ce0$1c86db41@boostconsulting.com>

Boost.Python v2 now supports a free-function version of def which defines
its function in the current scope:

  #include <boost/python/def.hpp>
  #include <boost/python/module_init.hpp>

  BOOST_PYTHON_MODULE_INIT(my_module)
  {
    def("name", function_ptr);
    def("name", function_ptr, call_policies);
    def("name", function_ptr, "documentation string");
    def("name", function_ptr, call_policies, "documentation string");

    def("name", function_ptr, default_stubs);
  }

etc.

Accordingly, the module class is deprecated. I think it still works, but
we're not going to continue to support it, and it will eventually wither
and die. To get access to the current module, you can declare the current
scope:

  #include <boost/python/scope.hpp>

  BOOST_PYTHON_MODULE_INIT(my_module)
  {
    // set the docstring of the current module scope
    scope().attr("__doc__") = "my module's docstring";
    ...

    scope current;
    current.attr("x") = 1; // my_module.x = 1
  }

Of course, you can also set the current scope to any object:

  object some_obj;
  scope within(some_obj);
  def("foo", &foo); // define a function within some_obj as a namespace

Be warned, however, that although you can set the current scope from a
class_<> instance, the class_<>'s def() member function will work properly
in some cases where the free-function def() cannot, since the latter is
missing information about the class type being wrapped.

Enjoy,
Dave

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






From rwgk at yahoo.com  Tue Sep  3 22:11:29 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 3 Sep 2002 13:11:29 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
In-Reply-To: <136401c252d7$43346a30$1c86db41@boostconsulting.com>
Message-ID: <20020903201129.52901.qmail@web20205.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> As it turns out, I couldn't stand the status quo, so I impulsively changed
> the built-in conversion rules in the CVS. The new rules are as follows:
> 
> C++ target type       built-in conversions from Python types
> ---------------       --------------------------------------
> signed/unsigned       int,long
> char,short,int,long,
> long long
> 
> float,double,        int,long,float
> long double

This is great. However, for this to work for Pearu he still needs a predictable
overload resolution order. If there is both foo(double) and foo(int), he will
want the foo(int) looked at first. What order should the foo's be def'ed in?

Ralf


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



From dave at boost-consulting.com  Tue Sep  3 23:05:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 3 Sep 2002 17:05:28 -0400
Subject: [C++-sig] Boost.Python v2: float <==> int, anything ==> str
References: <20020903201129.52901.qmail@web20205.mail.yahoo.com>
Message-ID: <17cf01c2538d$f801b1f0$1c86db41@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > As it turns out, I couldn't stand the status quo, so I impulsively
changed
> > the built-in conversion rules in the CVS. The new rules are as follows:
> >
> > C++ target type       built-in conversions from Python types
> > ---------------       --------------------------------------
> > signed/unsigned       int,long
> > char,short,int,long,
> > long long
> >
> > float,double,        int,long,float
> > long double
>
> This is great. However, for this to work for Pearu he still needs a
predictable
> overload resolution order. If there is both foo(double) and foo(int), he
will
> want the foo(int) looked at first. What order should the foo's be def'ed
in?

First come, first served.


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





From ftian at cs.wisc.edu  Wed Sep  4 07:05:29 2002
From: ftian at cs.wisc.edu (Feng Tian)
Date: Wed, 4 Sep 2002 00:05:29 -0500 (CDT)
Subject: [C++-sig] install a boost module
Message-ID: <Pine.LNX.4.21.0209040004150.768-100000@cobra.cs.wisc.edu>

Hi,

I compiled boost (1.28.0, python 2.2.1, gcc 3.0.2), it seems
fine.  I also did a bjam test in boost/libs/python/build, 
which also seems OK.  Now my problem is how do I build/release 
my own module?  For some certain reason, I have to put my c++ 
code outside of boost installation dir.

The following is what I have done.

1. Use/modify Jamfile in project.zip, I can compile my code.  
The result is a .so file in
    myproject/bin/dsms_common.so/gcc/debug/runtime-link-dynamic/
    shared-linkable-true/dsms_common.so

2. Since dsms_common.so is not in python's library path, I cd to 
the directory, invoke python, however, 
	import dsms_common
   reports
	libboost_python.so.1.28.0 cannot open, no such file.

3. I found the libboost_python.so.1.28.0 is in a really deep
directory located in boost/libs/python/build/bin/....
so I copied the file to the directory with dsms_common.so,
however, still, import fails.

4. Now in python, i do
	import libboost_python
   it reports error
	ImportError: dynamic module does not define init function
   but now I do
        import dsms_common
   it worked!!

So questions,
1. Did I missed some 'make install' step in building/installing boost?
   It does not seems like the libboost_python.so.1.28.0 is installed in
   the right place.
2. Is there any 'make install' step after I use bjam in my own module?
   So that a simple 
	import dsms_common
   in python will be all that I need to do.

Thank you. 

Feng





From rwgk at yahoo.com  Wed Sep  4 09:51:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 4 Sep 2002 00:51:42 -0700 (PDT)
Subject: [C++-sig] scope() rules?
Message-ID: <20020904075142.31198.qmail@web20207.mail.yahoo.com>

I have just converted one of my extension modules to work without the
deprecated module object. The result clearly looks nicer than the previous
version. But how does it work? What determines scope()? Is the
BOOST_PYTHON_MODULE_INIT macro involved?
Is there a guarantee that only one module is dlopen'ed by Python at any given
time? Have threading issues be considered in the design? Or are these quesions
not relevant?
Thanks,
        Ralf


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



From dave at boost-consulting.com  Wed Sep  4 14:42:45 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 4 Sep 2002 08:42:45 -0400
Subject: [C++-sig] scope() rules?
References: <20020904075142.31198.qmail@web20207.mail.yahoo.com>
Message-ID: <1aaf01c25410$923d8370$1c86db41@boostconsulting.com>

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


> I have just converted one of my extension modules to work without the
> deprecated module object. The result clearly looks nicer than the
previous
> version. But how does it work? What determines scope()? Is the
> BOOST_PYTHON_MODULE_INIT macro involved?

Yes.

> Is there a guarantee that only one module is dlopen'ed by Python at any
given
> time? Have threading issues be considered in the design? Or are these
quesions
> not relevant?

I'm pretty sure that Python only imports one module at a time. That's what
I remember, anyway.

If that weren't the case we'd have lots more problems than just the global
current scope().

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






From rwgk at yahoo.com  Thu Sep  5 00:04:28 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 4 Sep 2002 15:04:28 -0700 (PDT)
Subject: [C++-sig] scope() rules?
In-Reply-To: <1aaf01c25410$923d8370$1c86db41@boostconsulting.com>
Message-ID: <20020904220428.97579.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Is there a guarantee that only one module is dlopen'ed by Python at any
> given
> > time? Have threading issues be considered in the design? Or are these
> quesions
> > not relevant?
> 
> I'm pretty sure that Python only imports one module at a time. That's what
> I remember, anyway.
> 
> If that weren't the case we'd have lots more problems than just the global
> current scope().

Following your advice from a while ago I use PyImport_ImportModule() to import
a module with Python bindings for array types (flex.so) while importing other
modules that make use of these bindings (e.g. fftpack.so). I have strong
evidence that Python dlopen's the flex.so module before the initialization of
fftpack.so is finished, using print statements at the beginning and the end of
the extern "C" init functions.

from scitbx import fftpack
/net/cci/rwgk/bpl2/scitbx/fftpack/boost_python/fftpack_module.cpp(380)
/net/cci/rwgk/bpl2/scitbx/array_family/boost_python/flex_module.cpp(138)
/net/cci/rwgk/bpl2/scitbx/array_family/boost_python/flex_module.cpp(141)
/net/cci/rwgk/bpl2/scitbx/fftpack/boost_python/fftpack_module.cpp(382)

Right now, fftpack.so does not use the deprecated module object, but uses the
free def() functions. However, flex_module.cpp still uses the old module
object. My regression tests work just fine. What will happen if I convert
flex.so over to the free def() functions?

Thanks,
        Ralf


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



From dave at boost-consulting.com  Thu Sep  5 00:28:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 4 Sep 2002 18:28:10 -0400
Subject: [C++-sig] scope() rules?
References: <20020904220428.97579.qmail@web20201.mail.yahoo.com>
Message-ID: <019501c25462$f7444590$6401a8c0@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > > Is there a guarantee that only one module is dlopen'ed by Python at
any
> > given
> > > time? Have threading issues be considered in the design? Or are these
> > quesions
> > > not relevant?
> >
> > I'm pretty sure that Python only imports one module at a time. That's
what
> > I remember, anyway.
> >
> > If that weren't the case we'd have lots more problems than just the
global
> > current scope().
>
> Following your advice from a while ago I use PyImport_ImportModule() to
import
> a module with Python bindings for array types (flex.so) while importing
other
> modules that make use of these bindings (e.g. fftpack.so). I have strong
> evidence that Python dlopen's the flex.so module before the
initialization of
> fftpack.so is finished, using print statements at the beginning and the
end of
> the extern "C" init functions.

Sorry, I should have said that all imports are synchronized through the
GIL.

> from scitbx import fftpack
> /net/cci/rwgk/bpl2/scitbx/fftpack/boost_python/fftpack_module.cpp(380)
> /net/cci/rwgk/bpl2/scitbx/array_family/boost_python/flex_module.cpp(138)
> /net/cci/rwgk/bpl2/scitbx/array_family/boost_python/flex_module.cpp(141)
> /net/cci/rwgk/bpl2/scitbx/fftpack/boost_python/fftpack_module.cpp(382)
>
> Right now, fftpack.so does not use the deprecated module object, but uses
the
> free def() functions. However, flex_module.cpp still uses the old module
> object. My regression tests work just fine. What will happen if I convert
> flex.so over to the free def() functions?

It should work without problems. If it doesn't give me a small use case and
I'll fix it.


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





From rwgk at yahoo.com  Thu Sep  5 21:17:29 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 5 Sep 2002 12:17:29 -0700 (PDT)
Subject: [C++-sig] Boost.Python V2 & Mac OS 10?
Message-ID: <20020905191729.65823.qmail@web20208.mail.yahoo.com>

Has anybody recently tried to compile Boost.Python V2 under Mac OS 10?

Related questions:

What is Apple's latest version of the "native" C++ compiler?

Has anybody tried a gcc 3.2 installation from scratch?

Has anybody on this list used the Metrowerks compiler under OS 10?

Thanks,
        Ralf


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



From dave at boost-consulting.com  Thu Sep  5 21:55:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 5 Sep 2002 15:55:40 -0400
Subject: [C++-sig] install a boost module
References: <Pine.LNX.4.21.0209040004150.768-100000@cobra.cs.wisc.edu>
Message-ID: <06ae01c25516$93c30bf0$6401a8c0@boostconsulting.com>

From: "Feng Tian" <ftian at cs.wisc.edu>

> I compiled boost (1.28.0, python 2.2.1, gcc 3.0.2), it seems
> fine.  I also did a bjam test in boost/libs/python/build, 
> which also seems OK.  Now my problem is how do I build/release 
> my own module?  For some certain reason, I have to put my c++ 
> code outside of boost installation dir.



> The following is what I have done.
> 
> 1. Use/modify Jamfile in project.zip, I can compile my code.  
> The result is a .so file in
>     myproject/bin/dsms_common.so/gcc/debug/runtime-link-dynamic/
>     shared-linkable-true/dsms_common.so
> 
> 2. Since dsms_common.so is not in python's library path, I cd to 
> the directory, invoke python, however, 
> import dsms_common
>    reports
> libboost_python.so.1.28.0 cannot open, no such file.
> 
> 3. I found the libboost_python.so.1.28.0 is in a really deep
> directory located in boost/libs/python/build/bin/....
> so I copied the file to the directory with dsms_common.so,
> however, still, import fails.

You need to help the OS to find libboost_python.so.1.28.0 
Usually, that means putting its directory in some environment variable.
If you're running on Linux, that's called LD_LIBRARY_PATH:

    #!/bin/sh
    LD_LIBRARY_PATH=directory/containing/libbpl:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH


> 4. Now in python, i do
> import libboost_python
>    it reports error
> ImportError: dynamic module does not define init function

That's because libboost_python is not a python module.

>    but now I do
>         import dsms_common
>    it worked!!
> 
> So questions,
> 1. Did I missed some 'make install' step in building/installing boost?
>    It does not seems like the libboost_python.so.1.28.0 is installed in
>    the right place.

No, we don't have an official installation procedure (yet).

> 2. Is there any 'make install' step after I use bjam in my own module?
>    So that a simple 
> import dsms_common
>    in python will be all that I need to do.

Same answer. Sorry.

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




From dave at boost-consulting.com  Thu Sep  5 23:16:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 5 Sep 2002 17:16:40 -0400
Subject: [C++-sig] Boost.Python V2 & Mac OS 10?
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com>
Message-ID: <07b401c25521$c8c8f4d0$6401a8c0@boostconsulting.com>

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


> Has anybody recently tried to compile Boost.Python V2 under Mac OS 10?

Some people have tried, with little success. Building shared libraries
under OS X was an twisty maze of little passages, last time I looked. I'd
love to know what command-lines I need to spit out to accomplish this, so
that I could make Boost.Build do the job.

Here's a thought: I think somebody out there was building BPL with
distutils. I wonder if the distutils approach would "just work" on OS X?

> Related questions:
>
> What is Apple's latest version of the "native" C++ compiler?

Some kind of GCC 3.1 alpha variant, I think.

> Has anybody tried a gcc 3.2 installation from scratch?
>
> Has anybody on this list used the Metrowerks compiler under OS 10?

I don't know these things.

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





From agurtovoy at meta-comm.com  Fri Sep  6 00:21:08 2002
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Thu, 5 Sep 2002 17:21:08 -0500 
Subject: [C++-sig] Boost.Python V2 & Mac OS 10?
Message-ID: <4034600A4760D411B8720001031D84FB010963E0@postoffice.office.meta>

Ralf W. Grosse-Kunstleve wrote:
> Has anybody on this list used the Metrowerks compiler under OS 10?

Metrowerks CodeWarrior 8.2 on MacOS X.

Aleksey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020905/078f3423/attachment.htm>

From rwgk at yahoo.com  Fri Sep  6 00:50:22 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 5 Sep 2002 15:50:22 -0700 (PDT)
Subject: [C++-sig] Boost.Python V2 & Mac OS 10?
In-Reply-To: <4034600A4760D411B8720001031D84FB010963E0@postoffice.office.meta>
Message-ID: <20020905225022.7540.qmail@web20201.mail.yahoo.com>

Can this compiler be used from the command line? -- The last time I looked (CW
7) I had difficulties finding the relevant information. Pointers to a script
for setting up the compiler for command line use are highly appreciated.

With c++ (the g++ 2.95 derivative) I had to use options like -bundle
-flat_namespace to build Python extension modules (but the BPL V1 link failed
:-( ). On OS X there seems to be a distinction between "bundles" (linked at
run-time with a dlopen() equivalent) and "regular shared libraries" (linked
with, e.g. c++ or ld). Would you know if both "regular shared libraries" and
"bundles" are supported by CodeWarrior?

Thanks,
        Ralf

--- Aleksey Gurtovoy <agurtovoy at meta-comm.com> wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > Has anybody on this list used the Metrowerks compiler under OS 10?
> 
> Metrowerks CodeWarrior 8.2 on MacOS X.
> 
> Aleksey



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



From rwgk at yahoo.com  Fri Sep  6 01:34:58 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 5 Sep 2002 16:34:58 -0700 (PDT)
Subject: [C++-sig] scope() rules?
In-Reply-To: <019501c25462$f7444590$6401a8c0@boostconsulting.com>
Message-ID: <20020905233458.64789.qmail@web20210.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Right now, fftpack.so does not use the deprecated module object, but uses
> the
> > free def() functions. However, flex_module.cpp still uses the old module
> > object. My regression tests work just fine. What will happen if I convert
> > flex.so over to the free def() functions?
> 
> It should work without problems. If it doesn't give me a small use case and
> I'll fix it.

I have changed all my modules. I am happy to report that there is nothing to
fix. All my regression tests work just like they did before.

Ralf


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



From bmccandl at llnl.gov  Fri Sep  6 03:49:28 2002
From: bmccandl at llnl.gov (Brian McCandless)
Date: Thu, 05 Sep 2002 18:49:28 -0700
Subject: [C++-sig] Default argument and return policies
Message-ID: <3D7809A8.9CDA49E8@llnl.gov>

I have a function that uses default arguments and also needs a call policy.
But I was not able to get this to work.  I last grabbed the code from
CVS yesterday.
Am I doing something wrong or is this an omission in the library?

Here is my example:

#include <boost/python/class.hpp>
#include <boost/python/return_value_policy.hpp>
#include <boost/python/manage_new_object.hpp>
#include <boost/python/module_init.hpp>
#include <boost/python/def.hpp>

using namespace boost::python;

struct Data {
  Data(double d) : val(d) {}
  double val;
};

Data* makeData1(double f, double d = 1.0) {
  return new Data(f * d);
}

Data makeData2(double f, double d = 1.0) {
  return Data(f * d);
}

BOOST_PYTHON_FUNCTION_GENERATOR(makeData1_stubs, makeData1, 1, 2)
BOOST_PYTHON_FUNCTION_GENERATOR(makeData2_stubs, makeData2, 1, 2)

BOOST_PYTHON_MODULE_INIT(defaults)
{
  // works, but you have to pass in two arguments
  def("makeData1", makeData1,
      return_value_policy<manage_new_object>());

  // works with default arguments as expected.
  def("makeData2", makeData2, makeData2_stubs());

#if 0
  // Does not compile!
  def("makeData1_with_defaults", makeData1, makeData1_stubs(),
      return_value_policy<manage_new_object>());
#endif

  class_<Data> data("Data", args<double>());
  data.def_readwrite("val", &Data::val);
}


--
 Brian McCandless     bmccandl at llnl.gov     925/424-2690






From djowel at gmx.co.uk  Fri Sep  6 04:33:16 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Fri, 6 Sep 2002 10:33:16 +0800
Subject: [C++-sig] Default argument and return policies
References: <3D7809A8.9CDA49E8@llnl.gov>
Message-ID: <058a01c2554d$c5225700$0100a8c0@kim>

Hi,

No, you're not doing anything wrong.

Whoops.... Call policies for the default function generators 
are not implemented yet. Ok, I'll get this working as soon
as possible. Shouldn't be difficult to implement. I'll keep
you posted.

Pardon the confusion.

--Joel

----- Original Message ----- 
From: "Brian McCandless" <bmccandl at llnl.gov>


> 
> I have a function that uses default arguments and also needs a call policy.
> But I was not able to get this to work.  I last grabbed the code from
> CVS yesterday.
> Am I doing something wrong or is this an omission in the library?
> 
> Here is my example:
> 
> #include <boost/python/class.hpp>
> #include <boost/python/return_value_policy.hpp>
> #include <boost/python/manage_new_object.hpp>
> #include <boost/python/module_init.hpp>
> #include <boost/python/def.hpp>
> 
> using namespace boost::python;
> 
> struct Data {
>   Data(double d) : val(d) {}
>   double val;
> };
> 
> Data* makeData1(double f, double d = 1.0) {
>   return new Data(f * d);
> }
> 
> Data makeData2(double f, double d = 1.0) {
>   return Data(f * d);
> }
> 
> BOOST_PYTHON_FUNCTION_GENERATOR(makeData1_stubs, makeData1, 1, 2)
> BOOST_PYTHON_FUNCTION_GENERATOR(makeData2_stubs, makeData2, 1, 2)
> 
> BOOST_PYTHON_MODULE_INIT(defaults)
> {
>   // works, but you have to pass in two arguments
>   def("makeData1", makeData1,
>       return_value_policy<manage_new_object>());
> 
>   // works with default arguments as expected.
>   def("makeData2", makeData2, makeData2_stubs());
> 
> #if 0
>   // Does not compile!
>   def("makeData1_with_defaults", makeData1, makeData1_stubs(),
>       return_value_policy<manage_new_object>());
> #endif
> 
>   class_<Data> data("Data", args<double>());
>   data.def_readwrite("val", &Data::val);
> }
> 
> 
> --
>  Brian McCandless     bmccandl at llnl.gov     925/424-2690
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 




From minxu at sci.ccny.cuny.edu  Fri Sep  6 05:15:00 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: Thu, 5 Sep 2002 23:15:00 -0400
Subject: [C++-sig] Wrap class without a default constructor
In-Reply-To: <20020905191729.65823.qmail@web20208.mail.yahoo.com>
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com>
Message-ID: <200209052315.00605.minxu@sci.ccny.cuny.edu>

It used to work to wrap a class which does define a default constructor in v2 
and it does not work any more from the current CVS version. What's right way 
now?  Thanks.

--- snip ---
    python::class_<geometry >("geometry")
	.def_init(args<const grid*>()
		  // Keep the grid alive as long as the geometry is.
		  , python::with_custodian_and_ward<1,2>())
	.def_init(args<double, double, const grid*>())
	.def_init(args<double, const grid*, geometryType>());

geometry does have a default constructor.
---snip ---


Min Xu



From dave at boost-consulting.com  Fri Sep  6 05:28:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 5 Sep 2002 23:28:39 -0400
Subject: [C++-sig] Wrap class without a default constructor
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com> <200209052315.00605.minxu@sci.ccny.cuny.edu>
Message-ID: <0b1101c25555$817206b0$6401a8c0@boostconsulting.com>

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

HTH,
Dave

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


----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Thursday, September 05, 2002 11:15 PM
Subject: [C++-sig] Wrap class without a default constructor


It used to work to wrap a class which does define a default constructor in
v2
and it does not work any more from the current CVS version. What's right
way
now?  Thanks.

--- snip ---
    python::class_<geometry >("geometry")
.def_init(args<const grid*>()
  // Keep the grid alive as long as the geometry is.
  , python::with_custodian_and_ward<1,2>())
.def_init(args<double, double, const grid*>())
.def_init(args<double, const grid*, geometryType>());

geometry does have a default constructor.
---snip ---


Min Xu

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




From agurtovoy at meta-comm.com  Fri Sep  6 00:37:59 2002
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Thu, 5 Sep 2002 22:37:59 +0000
Subject: [C++-sig] Boost.Python V2 & Mac OS 10?
In-Reply-To: <20020905225022.7540.qmail@web20201.mail.yahoo.com>
Message-ID: <20FDDAE8-C120-11D6-B593-0003935A40A0@meta-comm.com>

On Thursday, September 5, 2002, at 10:50 PM, Ralf W. Grosse-Kunstleve 
wrote:
> Can this compiler be used from the command line?

Yes.

> -- The last time I looked (CW
> 7) I had difficulties finding the relevant information. Pointers to a 
> script
> for setting up the compiler for command line use are highly appreciated.

If installed, the command line tools are located in your '<home>/bin' 
directory. The reference documentation contains a whole section devoted 
to setup and usage of command line compiler/linker.

> With c++ (the g++ 2.95 derivative) I had to use options like -bundle
> -flat_namespace to build Python extension modules (but the BPL V1 link 
> failed
> :-( ). On OS X there seems to be a distinction between "bundles" 
> (linked at
> run-time with a dlopen() equivalent) and "regular shared libraries" 
> (linked
> with, e.g. c++ or ld). Would you know if both "regular shared 
> libraries" and
> "bundles" are supported by CodeWarrior?

I _think_ they are, but don't know for sure.

Aleksey



From minxu at sci.ccny.cuny.edu  Fri Sep  6 16:24:06 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: Fri, 6 Sep 2002 10:24:06 -0400
Subject: [C++-sig] Wrap class without a default constructor
In-Reply-To: <0b1101c25555$817206b0$6401a8c0@boostconsulting.com>
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com> <200209052315.00605.minxu@sci.ccny.cuny.edu> <0b1101c25555$817206b0$6401a8c0@boostconsulting.com>
Message-ID: <200209061024.08215.minxu@sci.ccny.cuny.edu>

It works now. Thanks.

What is the relation between this no_init and boost::noncopyable? Can the 
boost::noncopyable be omitted if a) no_init is used b) no other def_init is 
defined for a class?

Min Xu

On Thursday 05 September 2002 23:28, David Abrahams wrote:
> See http://mail.python.org/pipermail/c++-sig/2002-August/001928.html
>
> HTH,
> Dave
>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
> ----- Original Message -----
> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> To: <c++-sig at python.org>
> Sent: Thursday, September 05, 2002 11:15 PM
> Subject: [C++-sig] Wrap class without a default constructor
>
>
> It used to work to wrap a class which does define a default constructor in
> v2
> and it does not work any more from the current CVS version. What's right
> way
> now?  Thanks.
>
> --- snip ---
>     python::class_<geometry >("geometry")
> .def_init(args<const grid*>()
>   // Keep the grid alive as long as the geometry is.
>   , python::with_custodian_and_ward<1,2>())
> .def_init(args<double, double, const grid*>())
> .def_init(args<double, const grid*, geometryType>());
>
> geometry does have a default constructor.
> ---snip ---
>
>
> Min Xu
>
> _______________________________________________
> 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 Sep  6 16:28:55 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 6 Sep 2002 10:28:55 -0400
Subject: [C++-sig] Wrap class without a default constructor
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com> <200209052315.00605.minxu@sci.ccny.cuny.edu> <0b1101c25555$817206b0$6401a8c0@boostconsulting.com> <200209061024.08215.minxu@sci.ccny.cuny.edu>
Message-ID: <0c2501c255b1$f93de270$6401a8c0@boostconsulting.com>

The only relationship is that they both deal with constructors.

    no_init means "do not try to define a Python __init__ function"

    noncopyable means "do not try to register a converter which can
    convert C++ T return values to python".

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Friday, September 06, 2002 10:24 AM
Subject: Re: [C++-sig] Wrap class without a default constructor


It works now. Thanks.

What is the relation between this no_init and boost::noncopyable? Can the
boost::noncopyable be omitted if a) no_init is used b) no other def_init is
defined for a class?

Min Xu

On Thursday 05 September 2002 23:28, David Abrahams wrote:
> See http://mail.python.org/pipermail/c++-sig/2002-August/001928.html
>
> HTH,
> Dave
>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
> ----- Original Message -----
> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> To: <c++-sig at python.org>
> Sent: Thursday, September 05, 2002 11:15 PM
> Subject: [C++-sig] Wrap class without a default constructor
>
>
> It used to work to wrap a class which does define a default constructor
in
> v2
> and it does not work any more from the current CVS version. What's right
> way
> now?  Thanks.
>
> --- snip ---
>     python::class_<geometry >("geometry")
> .def_init(args<const grid*>()
>   // Keep the grid alive as long as the geometry is.
>   , python::with_custodian_and_ward<1,2>())
> .def_init(args<double, double, const grid*>())
> .def_init(args<double, const grid*, geometryType>());
>
> geometry does have a default constructor.
> ---snip ---
>
>
> Min Xu
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig

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




From okuda1 at llnl.gov  Fri Sep  6 22:42:44 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Fri, 06 Sep 2002 13:42:44 -0700
Subject: [C++-sig] Unable to create bjam
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com> <200209052315.00605.minxu@sci.ccny.cuny.edu> <0b1101c25555$817206b0$6401a8c0@boostconsulting.com> <200209061024.08215.minxu@sci.ccny.cuny.edu> <0c2501c255b1$f93de270$6401a8c0@boostconsulting.com>
Message-ID: <3D791344.2D4AA5C3@llnl.gov>

I have been getting pre-build Boost.Jam executables from the web site.
But I could not build bjam by using make YACC= in
.../tools/build/jam_src.
It builds on OSF1 platform works, but not on AIX platform. Any helpful
suggestion of building bjam on IBM platform is appreciated...

frost067(215) make YACC=
cc -o jam0  command.c compile.c execnt.c execunix.c execvms.c expand.c
filent.c
fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c
jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c
pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c
timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c
command.c:
compile.c:
execnt.c:
execunix.c:
execvms.c:
expand.c:
filent.c:
fileos2.c:
fileunix.c:
filevms.c:
glob.c:
hash.c:
hdrmacro.c:
headers.c:
jam.c:
jambase.c:
jamgram.c:
lists.c:
make.c:
make1.c:
"make1.c", line 306.17: 1506-046 (S) Syntax error.
"make1.c", line 306.20: 1506-045 (S) Undeclared identifier using.
"make1.c", line 506.25: 1506-046 (S) Syntax error.
"make1.c", line 506.28: 1506-045 (S) Undeclared identifier must.
"make1.c", line 509.28: 1506-045 (S) Undeclared identifier using.
newstr.c:
option.c:
parse.c:
pathunix.c:
pathvms.c:
regexp.c:
rules.c:
scan.c:
search.c:
subst.c:
timestamp.c:
variable.c:
modules.c:
strings.c:
filesys.c:
builtins.c:
pwd.c:
make: *** [jam0] Error 1



From toon.knapen at si-lab.com  Fri Sep  6 23:08:30 2002
From: toon.knapen at si-lab.com (Toon Knapen)
Date: Fri, 6 Sep 2002 23:08:30 +0200
Subject: [C++-sig] Unable to create bjam
In-Reply-To: <3D791344.2D4AA5C3@llnl.gov>
References: <20020905191729.65823.qmail@web20208.mail.yahoo.com> <0c2501c255b1$f93de270$6401a8c0@boostconsulting.com> <3D791344.2D4AA5C3@llnl.gov>
Message-ID: <E17nQHU-0000YQ-00@bigglesworth.mail.be.easynet.net>

On Friday 06 September 2002 22:42, chuzo okuda wrote:
> I have been getting pre-build Boost.Jam executables from the web site.
> But I could not build bjam by using make YACC= in
> .../tools/build/jam_src.
> It builds on OSF1 platform works, but not on AIX platform. Any helpful
> suggestion of building bjam on IBM platform is appreciated...

> "make1.c", line 306.17: 1506-046 (S) Syntax error.
> "make1.c", line 306.20: 1506-045 (S) Undeclared identifier using.
> "make1.c", line 506.25: 1506-046 (S) Syntax error.
> "make1.c", line 506.28: 1506-045 (S) Undeclared identifier must.
> "make1.c", line 509.28: 1506-045 (S) Undeclared identifier using.

The problem is that the IBM cc does not understand C++-style comments 
(leading //) so I changed to comments to C-style (/* */).

Please do a 'cvs update' and it will compile fine on IBM.

toon



From toon.knapen at si-lab.org  Fri Sep  6 23:09:27 2002
From: toon.knapen at si-lab.org (Toon Knapen)
Date: Fri, 6 Sep 2002 23:09:27 +0200
Subject: Fwd: Re: [C++-sig] Unable to create bjam
Message-ID: <E17nQIO-0000Zd-00@bigglesworth.mail.be.easynet.net>

On Friday 06 September 2002 22:42, chuzo okuda wrote:
> I have been getting pre-build Boost.Jam executables from the web site.
> But I could not build bjam by using make YACC= in
> .../tools/build/jam_src.
> It builds on OSF1 platform works, but not on AIX platform. Any helpful
> suggestion of building bjam on IBM platform is appreciated...
>
> "make1.c", line 306.17: 1506-046 (S) Syntax error.
> "make1.c", line 306.20: 1506-045 (S) Undeclared identifier using.
> "make1.c", line 506.25: 1506-046 (S) Syntax error.
> "make1.c", line 506.28: 1506-045 (S) Undeclared identifier must.
> "make1.c", line 509.28: 1506-045 (S) Undeclared identifier using.

The problem is that the IBM cc does not understand C++-style comments
(leading //) so I changed to comments to C-style (/* */).

Please do a 'cvs update' and it will compile fine on IBM.

toon




From lists at UltimateG.com  Sat Sep  7 00:20:22 2002
From: lists at UltimateG.com (Mark Evans)
Date: Fri, 6 Sep 2002 15:20:22 -0700
Subject: [C++-sig] Re: Boost.Python v2: float <==> int, anything ==> str (David Abrahams)
In-Reply-To: <20020903160009.17077.16036.Mailman@mail.python.org>
References: <20020903160009.17077.16036.Mailman@mail.python.org>
Message-ID: <1389013150.20020906152022@UltimateG.com>

David

I choke every time I see "float" because if there is going to be a
default floating-point type, it should always be "double," which is the
maximum standard precision.

Beyond double, there are extendeds and long doubles, but these vary from
one machine to the next so double is a good choice for common ground.

Whether this comment is apropos I do not know, but please take note.
We engineers will love you for it.

Mark




From dave at boost-consulting.com  Sat Sep  7 00:28:48 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 6 Sep 2002 18:28:48 -0400
Subject: [C++-sig] Re: Boost.Python v2: float <==> int, anything ==> str (David Abrahams)
References: <20020903160009.17077.16036.Mailman@mail.python.org> <1389013150.20020906152022@UltimateG.com>
Message-ID: <0e5c01c255f5$21d8a5b0$6401a8c0@boostconsulting.com>

From: "Mark Evans" <lists at UltimateG.com>


> David
>
> I choke every time I see "float" because if there is going to be a
> default floating-point type, it should always be "double," which is the
> maximum standard precision.
>
> Beyond double, there are extendeds and long doubles, but these vary from
> one machine to the next so double is a good choice for common ground.
>
> Whether this comment is apropos I do not know, but please take note.
> We engineers will love you for it.

Fortunately, it ain't. I'm talking about Python's float type here, which
incidentally holds a C++ double. There is no such thing as double or long
double in Python ;-)

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





From minxu at sci.ccny.cuny.edu  Sat Sep  7 05:06:49 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: Fri, 6 Sep 2002 23:06:49 -0400
Subject: [C++-sig] Need help on enum--a concrete example
In-Reply-To: <1389013150.20020906152022@UltimateG.com>
References: <20020903160009.17077.16036.Mailman@mail.python.org> <1389013150.20020906152022@UltimateG.com>
Message-ID: <200209062306.49659.minxu@sci.ccny.cuny.edu>

Hi, 

I understand that the questions about enum had been asked before. I read 
through them to no vail to solve my small problem at hand. From my impression 
of the document implicit.html, I wrote the following code:

#include <boost/python/module_init.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/implicit.hpp>

enum choice {red, blue};

class A
{
public:
	A() : x(0), y(0) {}
	A(double x, choice c) : x(x), y(c) {}
	double get() { return x; }
	double get1(double x) { return x; }
private:
	double x, y;
};


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

	implicitly_convertible<int, enum choice>();

	class_<A>("A")
     	      .def_init(args<double, choice>())
	      .def("get", &A::get)
	      .def("get1", &A::get1);
}


The compilation gave me:
g++ -I/usr/local/include -I/usr/include/python2.2  -c -Wall 
-ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2  -fPIC 
AA.C
/usr/local/include/boost/python/converter/implicit.hpp: In function `static 
void boost::python::converter::implicit<int,choice>::construct(PyObject *, 
boost::python::converter::rvalue_from_python_stage1_data *)':
/usr/local/include/boost/python/implicit.hpp:23:   instantiated from 
`boost::python::implicitly_convertible<int, choice>(boost::type<int> *, 
boost::type<choice> *)'
AA.C:24:   instantiated from here
/usr/local/include/boost/python/converter/implicit.hpp:43: conversion from 
`int' to `enum choice'
make: *** [AA.so] Error 1

Thanks!!!


By the way, I have also tried the alternative:
// namespace boost { namespace python {

//     template <class T>
//     struct enum_to_int_converter
//     {
//	static PyObject* convert(T const& x)
//	    {
//		return PyInt_FromLong(x);
//	    }
//     };

//     template <class T>
//     void enum_as_int(T* = 0)
//     {
//	to_python_converter<T, enum_to_int_converter<T> >();
//	implicitly_convertible<int, T>();
//     };

//     // position1:
//     void enum_as_int<choice>();
// }};

It doesnot work either.

Min Xu





From dave at boost-consulting.com  Sat Sep  7 05:20:30 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 6 Sep 2002 23:20:30 -0400
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <1389013150.20020906152022@UltimateG.com> <200209062306.49659.minxu@sci.ccny.cuny.edu>
Message-ID: <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com>

Hi Min,

You are right that there's a problem with enum conversions.
Implicitly_convertible<> does not work for this job as one might have
hoped. Unfortunately, I don't think I'll be able to work on code for
solving this problem before 10/1. In the meantime, my best suggestion is to
use "thin wrapper" functions which take ints in place of the enum
parameters, and then forward the arguments on. To deal with class
constructors, you'll need to wrap a derived class:

struct A_wrap : A
{
   A_wrap() {}
   A_wrap(double x, int c) : A(x, (choice)c) {}
};

    ...

    class_<A, A_wrap>("A")
        .def(init<double,int>())
        ...
        ;


Tedious but effective.

HTH,
Dave

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


----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Friday, September 06, 2002 11:06 PM
Subject: [C++-sig] Need help on enum--a concrete example


Hi,

I understand that the questions about enum had been asked before. I read
through them to no vail to solve my small problem at hand. From my
impression
of the document implicit.html, I wrote the following code:

#include <boost/python/module_init.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/implicit.hpp>

enum choice {red, blue};

class A
{
public:
A() : x(0), y(0) {}
A(double x, choice c) : x(x), y(c) {}
double get() { return x; }
double get1(double x) { return x; }
private:
double x, y;
};


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

implicitly_convertible<int, enum choice>();

class_<A>("A")
           .def_init(args<double, choice>())
      .def("get", &A::get)
      .def("get1", &A::get1);
}


The compilation gave me:
g++ -I/usr/local/include -I/usr/include/python2.2  -c -Wall
-ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2  -fPIC
AA.C
/usr/local/include/boost/python/converter/implicit.hpp: In function `static
void boost::python::converter::implicit<int,choice>::construct(PyObject *,
boost::python::converter::rvalue_from_python_stage1_data *)':
/usr/local/include/boost/python/implicit.hpp:23:   instantiated from
`boost::python::implicitly_convertible<int, choice>(boost::type<int> *,
boost::type<choice> *)'
AA.C:24:   instantiated from here
/usr/local/include/boost/python/converter/implicit.hpp:43: conversion from
`int' to `enum choice'
make: *** [AA.so] Error 1

Thanks!!!


By the way, I have also tried the alternative:
// namespace boost { namespace python {

//     template <class T>
//     struct enum_to_int_converter
//     {
// static PyObject* convert(T const& x)
//     {
// return PyInt_FromLong(x);
//     }
//     };

//     template <class T>
//     void enum_as_int(T* = 0)
//     {
// to_python_converter<T, enum_to_int_converter<T> >();
// implicitly_convertible<int, T>();
//     };

//     // position1:
//     void enum_as_int<choice>();
// }};

It doesnot work either.

Min Xu



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




From dave at boost-consulting.com  Sat Sep  7 05:33:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 6 Sep 2002 23:33:28 -0400
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <1389013150.20020906152022@UltimateG.com> <200209062306.49659.minxu@sci.ccny.cuny.edu> <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com>
Message-ID: <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com>

I wrote:

> 
> struct A_wrap : A
> {
>    A_wrap() {}
>    A_wrap(double x, int c) : A(x, (choice)c) {}

Whoops, that should be:

    A_wrap(PyObject*) {}
    A_wrap(PyObject*, double x, int c) : A(x, (choice)c) {}


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





From dave at boost-consulting.com  Sat Sep  7 06:46:13 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 7 Sep 2002 00:46:13 -0400
Subject: [C++-sig] Boost.Python v2: object embedding/lazy dict creation
Message-ID: <0f2c01c25629$80c92930$6401a8c0@boostconsulting.com>

I've just checked in changes to CVS which cause most wrapped C++ objects to
be stored directly in the memory allocated to their corresponding Python
objects. This should cut down on memory fragmentation and
locality-of-reference issues. A related change causes the instance __dict__
of your wrapped classes to be allocated only when you access the __dict__
attribute or write the first attribute on your class, further reducing
memory overhead.

Enjoy,
Dave

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






From niki at vintech.bg  Sat Sep  7 09:25:19 2002
From: niki at vintech.bg (Niki Spahiev)
Date: Sat, 07 Sep 2002 10:25:19 +0300
Subject: [C++-sig] convertibility and "Pythonicity"
References: <00ba01c24b70$304035d0$6501a8c0@boostconsulting.com>
Message-ID: <3D79A9DF.1080605@vintech.bg>

David Abrahams wrote:
> [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?
> 

about __int__, __float__, __str__

IMHO __str__ is for 'print'. Any object has some to_string conversion, 
while __int__ and __float__ are for numbers only.

HTH
Niki Spahiev




From minxu at sci.ccny.cuny.edu  Sat Sep  7 13:44:10 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: Sat, 7 Sep 2002 07:44:10 -0400
Subject: [C++-sig] Need help on enum--a concrete example
In-Reply-To: <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com>
References: <20020903160009.17077.16036.Mailman@mail.python.org> <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com> <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com>
Message-ID: <200209070744.11148.minxu@sci.ccny.cuny.edu>

Hi, 

Thanks for the quick reply. I compiled the code with your changes. The 
compilation failed.

#include <boost/python/module_init.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
//#include <boost/python/implicit.hpp>

enum choice {red, blue};

class A
{
public:
	A() : x(0), y(0) {}
	A(double x, choice c) : x(x), y(c) {}
	double get() { return x; }
	double get1(double x) { return x; }
private:
	double x, y;
};

struct A_wrap : A
{
    A_wrap(PyObject*) : A() {}
    A_wrap(PyObject*, double x, int c) : A(x, (choice)c) {}
};


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

	//implicitly_convertible<int, enum choice>();

	class_<A, A_wrap>("A")
	      .def(init<double, int>())
     	      //.def_init(args<double, choice>())
	      .def("get", &A::get)
	      .def("get1", &A::get1);
}

The compiler complains:
g++ ...
/usr/local/include/boost/python/class.hpp:173:   instantiated from here
/usr/local/include/boost/python/object/value_holder.hpp:120: no matching 
function for call to `A_wrap::A_wrap (PyObject *&, double &)'
AA.C:21: candidates are: A_wrap::A_wrap(PyObject *)
AA.C:22:                 A_wrap::A_wrap(PyObject *, double, int)
AA.C:23:                 A_wrap::A_wrap(const A_wrap &)
make: *** [AA.so] Error 1

Min


On Friday 06 September 2002 23:33, David Abrahams wrote:
> I wrote:
> > struct A_wrap : A
> > {
> >    A_wrap() {}
> >    A_wrap(double x, int c) : A(x, (choice)c) {}
>
> Whoops, that should be:
>
>     A_wrap(PyObject*) {}
>     A_wrap(PyObject*, double x, int c) : A(x, (choice)c) {}
>
>
> -----------------------------------------------------------
>            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 hugo at adept.co.za  Sun Sep  8 12:57:01 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Sun, 8 Sep 2002 12:57:01 +0200
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
In-Reply-To: <000d01c25004$99e33210$0100a8c0@kim>
References: <200208292313.34491.Peter.Schoen1@web.de> <000d01c25004$99e33210$0100a8c0@kim>
Message-ID: <20020908105701.GA13598@vervet.localnet>

On Fri, Aug 30, 2002 at 05:06:54PM +0800, Joel de Guzman wrote:
<SNIP>
> # define BOOST_PP_ITERATION_PARAMS_1 (3, (1, BOOST_PYTHON_MAX_ARITY,
> <boost/python/detail/make_tuple.hpp>))
> # include BOOST_PP_ITERATE()

I'm getting compile errors on lines like that last one:

`#include' expects "FILENAME" or <FILENAME>

... ideas?

I currently have gcc 2.95.4 installed as default gcc, but I also have
gcc 3.1 and 3.2 on my system - how do I tell bjam to use gcc3.2 instead
of straight /usr/bin/gcc ? (Will this fix my problem above, or am I
missing something else?)

Am I right in thinking that if I've done the "cvs update -dRP
-rmpl-development boost/mpl" thing once, I don't have to do it again:
doing a cvs update -dRP in the boost root directory should update
everything?

Thanks,
Hugo van der Merwe



From dave at boost-consulting.com  Sun Sep  8 14:32:31 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 8 Sep 2002 08:32:31 -0400
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
References: <200208292313.34491.Peter.Schoen1@web.de> <000d01c25004$99e33210$0100a8c0@kim> <20020908105701.GA13598@vervet.localnet>
Message-ID: <004501c25734$4e8c2b00$6401a8c0@boostconsulting.com>

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

> On Fri, Aug 30, 2002 at 05:06:54PM +0800, Joel de Guzman wrote:
> <SNIP>
> > # define BOOST_PP_ITERATION_PARAMS_1 (3, (1, BOOST_PYTHON_MAX_ARITY,
> > <boost/python/detail/make_tuple.hpp>))
> > # include BOOST_PP_ITERATE()
>
> I'm getting compile errors on lines like that last one:
>
> `#include' expects "FILENAME" or <FILENAME>
>
> ... ideas?

What platform are you compiling on/targeting?
So far, we've been testing with various gcc versions from 2.95.4 to 3.2
without problems.

> I currently have gcc 2.95.4 installed as default gcc, but I also have
> gcc 3.1 and 3.2 on my system - how do I tell bjam to use gcc3.2 instead
> of straight /usr/bin/gcc ?

Just follow the directions at:
http://www.boost.org/tools/build/gcc-tools.html

If you want to build with multiple GCC versions, you could add an
additional toolset to your BOOST_BUILD_PATH. For example, I have added a
gcc-3.0.4-tools.jam on my local machine which looks like:

# gcc-3.0.4-tools.jam
{
    local GCC_ROOT_DIRECTORY = c:/cygnus/usr/local/gcc-3.0.4 ;
    local GCC_STDLIB_DIRECTORY =
c:/cygnus/usr/local/gcc-3.0.4/lib/gcc-lib/i686-pc-cygwin/3.0.4 ;
    extends-toolset gcc ;
}

> (Will this fix my problem above

probably not

> , or am I
> missing something else?)

probably, but I don't know what it is. There seems to be some issue with
your preprocessor.

> Am I right in thinking that if I've done the "cvs update -dRP
> -rmpl-development boost/mpl" thing once, I don't have to do it again:
> doing a cvs update -dRP in the boost root directory should update
> everything?

Yep.

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




From dave at boost-consulting.com  Sun Sep  8 16:20:26 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 8 Sep 2002 10:20:26 -0400
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com> <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com> <200209070744.11148.minxu@sci.ccny.cuny.edu>
Message-ID: <00b701c25742$e2e12860$6401a8c0@boostconsulting.com>

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

<<
Hi,

Thanks for the quick reply. I compiled the code with your changes. The
compilation failed.
>>

Sorry, Min. Please make the following change:

   class_<A, A_wrap>("A")
      // .def(init<double,int>()) // ******
      .def_init(args<double, int>())
      .def("get", &A::get)
      .def("get1", &A::get1);

Joel, I think this bug is one of yours; uncomment the indicated line to
reproduce it.


-Dave


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






From hugo at adept.co.za  Sun Sep  8 22:34:00 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Sun, 8 Sep 2002 22:34:00 +0200
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
In-Reply-To: <004501c25734$4e8c2b00$6401a8c0@boostconsulting.com>
References: <200208292313.34491.Peter.Schoen1@web.de> <000d01c25004$99e33210$0100a8c0@kim> <20020908105701.GA13598@vervet.localnet> <004501c25734$4e8c2b00$6401a8c0@boostconsulting.com>
Message-ID: <20020908203400.GA2526@vervet.localnet>

> > I'm getting compile errors on lines like that last one:
> >
> > `#include' expects "FILENAME" or <FILENAME>
> >
> > ... ideas?
> 
> What platform are you compiling on/targeting?

Debian sid (unstable), let me try on Debian woody (stable) as well... ..
nope, same problem. Maybe I should try a clean checkout of the
boost/boost.python stuff.

> So far, we've been testing with various gcc versions from 2.95.4 to 3.2
> without problems.

> Just follow the directions at:
> http://www.boost.org/tools/build/gcc-tools.html

Thanks.

I have now also tried -sGXX=g++-3.2, that gives me parse errors...
something like this:

/home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:47: parse error
   before `(' token
/home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:62: parse error
   before `}' token
/home/hugo/Programming/boost/boost/mpl/aux_/none.hpp:20: confused by earlier errors, bailing out


/home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:47: parse error
   before `(' token
/home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:62: parse error
   before `}' token
/home/hugo/Programming/boost/boost/mpl/aux_/none.hpp:20: confused by earlier errors, bailing out


Strange...

> probably, but I don't know what it is. There seems to be some issue with
> your preprocessor.

amongst other things...

My command line was:

bjam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr -sTOOLS=gcc -sBUILD=release -sGXX=/usr/bin/g++-3.2


Would these instructions still be "up to date":

$ cvs -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost login
$ cvs -z3 -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost co boost
$ cd boost/
$ cvs update -dRP -rmpl-development boost/mpl

trying it all from scratch.

Thanks,
Hugo



From dave at boost-consulting.com  Sun Sep  8 22:40:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 8 Sep 2002 16:40:47 -0400
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
References: <200208292313.34491.Peter.Schoen1@web.de> <000d01c25004$99e33210$0100a8c0@kim> <20020908105701.GA13598@vervet.localnet> <004501c25734$4e8c2b00$6401a8c0@boostconsulting.com> <20020908203400.GA2526@vervet.localnet>
Message-ID: <01a701c25778$3c6a32c0$6401a8c0@boostconsulting.com>

Hugo,

The current CVS state seems to be broken due to some work Paul is doing on
the preprocessor library. Stay tuned for updates.

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


----- Original Message -----
From: "Hugo van der Merwe" <hugo at adept.co.za>
To: <c++-sig at python.org>
Sent: Sunday, September 08, 2002 4:34 PM
Subject: Re: [C++-sig] Boost.Pyton v2 & gcc 2.95.3


> > > I'm getting compile errors on lines like that last one:
> > >
> > > `#include' expects "FILENAME" or <FILENAME>
> > >
> > > ... ideas?
> >
> > What platform are you compiling on/targeting?
>
> Debian sid (unstable), let me try on Debian woody (stable) as well... ..
> nope, same problem. Maybe I should try a clean checkout of the
> boost/boost.python stuff.
>
> > So far, we've been testing with various gcc versions from 2.95.4 to 3.2
> > without problems.
>
> > Just follow the directions at:
> > http://www.boost.org/tools/build/gcc-tools.html
>
> Thanks.
>
> I have now also tried -sGXX=g++-3.2, that gives me parse errors...
> something like this:
>
> /home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:47: parse
error
>    before `(' token
> /home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:62: parse
error
>    before `}' token
> /home/hugo/Programming/boost/boost/mpl/aux_/none.hpp:20: confused by
earlier errors, bailing out
>
>
> /home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:47: parse
error
>    before `(' token
> /home/hugo/Programming/boost/boost/mpl/aux_/count_if_not.hpp:62: parse
error
>    before `}' token
> /home/hugo/Programming/boost/boost/mpl/aux_/none.hpp:20: confused by
earlier errors, bailing out
>
>
> Strange...
>
> > probably, but I don't know what it is. There seems to be some issue
with
> > your preprocessor.
>
> amongst other things...
>
> My command line was:
>
>
bjam -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr -sTOOLS=gcc -sBUILD=release -s
GXX=/usr/bin/g++-3.2
>
>
> Would these instructions still be "up to date":
>
> $ cvs -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost login
> $ cvs -z3 -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
co boost
> $ cd boost/
> $ cvs update -dRP -rmpl-development boost/mpl
>
> trying it all from scratch.
>
> Thanks,
> Hugo
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From djowel at gmx.co.uk  Mon Sep  9 04:26:34 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Mon, 9 Sep 2002 10:26:34 +0800
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com> <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com> <200209070744.11148.minxu@sci.ccny.cuny.edu> <00b701c25742$e2e12860$6401a8c0@boostconsulting.com>
Message-ID: <009d01c257a8$57bf9210$0100a8c0@kim>

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


> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> 
> <<
> Hi,
> 
> Thanks for the quick reply. I compiled the code with your changes. The
> compilation failed.
> >>
> 
> Sorry, Min. Please make the following change:
> 
>    class_<A, A_wrap>("A")
>       // .def(init<double,int>()) // ******
>       .def_init(args<double, int>())
>       .def("get", &A::get)
>       .def("get1", &A::get1);
> 
> Joel, I think this bug is one of yours; uncomment the indicated line to
> reproduce it.

Yep. This is a bug indeed. 
Fixed and committed to CVS. Added a test case in test/defaults.cpp.
Thanks for spotting this.

Regards,
--Joel




From dave at boost-consulting.com  Mon Sep  9 05:28:51 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 8 Sep 2002 23:28:51 -0400
Subject: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
References: <200208292313.34491.Peter.Schoen1@web.de> <000d01c25004$99e33210$0100a8c0@kim> <20020908105701.GA13598@vervet.localnet> <004501c25734$4e8c2b00$6401a8c0@boostconsulting.com> <20020908203400.GA2526@vervet.localnet> <01a701c25778$3c6a32c0$6401a8c0@boostconsulting.com>
Message-ID: <018301c257b1$0b96df20$6401a8c0@boostconsulting.com>

I think everything is back to normal now.
Sorry for the interruption in service!

-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>
Cc: "Paul Mensonides" <pmenso57 at attbi.com>
Sent: Sunday, September 08, 2002 4:40 PM
Subject: Re: [C++-sig] Boost.Pyton v2 & gcc 2.95.3


> Hugo,
>
> The current CVS state seems to be broken due to some work Paul is doing
on
> the preprocessor library. Stay tuned for updates.
>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
> ----- Original Message -----
> From: "Hugo van der Merwe" <hugo at adept.co.za>
> To: <c++-sig at python.org>
> Sent: Sunday, September 08, 2002 4:34 PM
> Subject: Re: [C++-sig] Boost.Pyton v2 & gcc 2.95.3
>
>
> > > > I'm getting compile errors on lines like that last one:
> > > >
> > > > `#include' expects "FILENAME" or <FILENAME>
> > > >
> > > > ... ideas?





From dave at boost-consulting.com  Mon Sep  9 05:41:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 8 Sep 2002 23:41:12 -0400
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com> <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com> <200209070744.11148.minxu@sci.ccny.cuny.edu> <00b701c25742$e2e12860$6401a8c0@boostconsulting.com>
Message-ID: <018e01c257b2$c378e330$6401a8c0@boostconsulting.com>

Nevermind all that; I implemented real enum support ;-).

Now given Min's example enum:

    enum choice { red, blue };

the construct:

    enum_<choice>("choice")
        .value("red", red)
        .value("blue", blue)
        ;

can be used to expose it to Python. The new enum type is created in the
current scope(), which is usually the current module.

You can access those values in Python as

    >>> extension_module.choice.red
    extension_module.choice.red


Remember that you can create a new scope around a class:

    scope in_X(class_<X>("X")
                    .def( ... )
                    .def( ... )
                );

    // Expose X::nested as X.nested
    enum_<X::nested>("nested")
        .value("red", red)
        .value("blue", blue)
        ;

Enjoy!

-----------------------------------------------------------
           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>
Cc: "Joel de Guzman" <joel at boost-consulting.com>
Sent: Sunday, September 08, 2002 10:20 AM
Subject: Re: [C++-sig] Need help on enum--a concrete example


> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
>
> <<
> Hi,
>
> Thanks for the quick reply. I compiled the code with your changes. The
> compilation failed.
> >>
>
> Sorry, Min. Please make the following change:
>
>    class_<A, A_wrap>("A")
>       // .def(init<double,int>()) // ******
>       .def_init(args<double, int>())
>       .def("get", &A::get)
>       .def("get1", &A::get1);
>
> Joel, I think this bug is one of yours; uncomment the indicated line to
> reproduce it.
>
>
> -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 djowel at gmx.co.uk  Mon Sep  9 08:59:08 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Mon, 9 Sep 2002 14:59:08 +0800
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <0ee501c2561e$369ea750$6401a8c0@boostconsulting.com> <0ef501c2561f$9f206330$6401a8c0@boostconsulting.com> <200209070744.11148.minxu@sci.ccny.cuny.edu> <00b701c25742$e2e12860$6401a8c0@boostconsulting.com> <018e01c257b2$c378e330$6401a8c0@boostconsulting.com>
Message-ID: <013501c257ce$6acfadb0$0100a8c0@kim>

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


> Nevermind all that; I implemented real enum support ;-).
> 

Gee, it's hard to catch up with you man! ;-P
--Joel




From gideon at computer.org  Mon Sep  9 19:06:47 2002
From: gideon at computer.org (gideon may)
Date: Mon, 09 Sep 2002 19:06:47 +0200
Subject: [C++-sig] missing enum_base.hpp in cvs
Message-ID: <11284376.1031598407@dyn151.snm-hgkz.ch>

Dear Dave,

Just updated my boost cvs and tried to compile bpl v2.
Now I get a compile error on MSVS .Net :

src\object\enum.cpp(7) : fatal error C1083: Cannot open include file: 
'boost/python/object/enum_base.hpp': No such file or directory

forgot to add ?

ciao,
gideon



From dave at boost-consulting.com  Mon Sep  9 19:14:19 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 9 Sep 2002 13:14:19 -0400
Subject: [C++-sig] missing enum_base.hpp in cvs
References: <11284376.1031598407@dyn151.snm-hgkz.ch>
Message-ID: <041b01c25824$57378b00$6401a8c0@boostconsulting.com>


----- Original Message ----- 
From: "gideon may" <gideon at computer.org>
To: "pysig" <c++-sig at python.org>
Sent: Monday, September 09, 2002 1:06 PM
Subject: [C++-sig] missing enum_base.hpp in cvs


> Dear Dave,
> 
> Just updated my boost cvs and tried to compile bpl v2.
> Now I get a compile error on MSVS .Net :
> 
> src\object\enum.cpp(7) : fatal error C1083: Cannot open include file: 
> 'boost/python/object/enum_base.hpp': No such file or directory
> 
> forgot to add ?

Picky, picky! ;-)

Sorry, it's there now.

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




From Peter.Bienstman at rug.ac.be  Tue Sep 10 16:33:20 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Tue, 10 Sep 2002 10:33:20 -0400
Subject: [C++-sig] Need help on enum--a concrete example
In-Reply-To: <018e01c257b2$c378e330$6401a8c0@boostconsulting.com>
References: <20020903160009.17077.16036.Mailman@mail.python.org> <00b701c25742$e2e12860$6401a8c0@boostconsulting.com> <018e01c257b2$c378e330$6401a8c0@boostconsulting.com>
Message-ID: <200209101033.23991.Peter.Bienstman@rug.ac.be>

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

On Sunday 08 September 2002 23:41, David Abrahams wrote:
> Nevermind all that; I implemented real enum support ;-).
>
> Now given Min's example enum:
>
>     enum choice { red, blue };
>
> the construct:
>
>     enum_<choice>("choice")
>         .value("red", red)
>         .value("blue", blue)
>         ;
>
> can be used to expose it to Python. The new enum type is created in the
> current scope(), which is usually the current module.
>
> You can access those values in Python as
>
>     >>> extension_module.choice.red
>
>     extension_module.choice.red

Small question: is there a trick to pollute the global namespace with the 
constants, such that one can write just 'red' in Python, rather than 
'choice.red'?

I know it's less clean, but it's easier for the user and ties in better with 
Python's weak typing.

Cheers,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9fgKz4dgPAIjyquoRAh0CAJ45JBhd5ztlZXL8NIyHPbN/zkdKuwCfT+fJ
p8as3LXKccOgzO0LpVObl2k=
=h7Kt
-----END PGP SIGNATURE-----




From dave at boost-consulting.com  Tue Sep 10 14:04:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 10 Sep 2002 08:04:28 -0400
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <00b701c25742$e2e12860$6401a8c0@boostconsulting.com> <018e01c257b2$c378e330$6401a8c0@boostconsulting.com> <200209101033.23991.Peter.Bienstman@rug.ac.be>
Message-ID: <089401c258c2$daeab5f0$6401a8c0@boostconsulting.com>

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

Small question: is there a trick to pollute the global namespace with the
constants, such that one can write just 'red' in Python, rather than
'choice.red'?

I know it's less clean, but it's easier for the user and ties in better
with
Python's weak typing.
>>

It doesn't tie in well with Python's "strong namespaceing".
There is no global namespace in Python. Do you mean that you'd like the
constants to be in the enclosing scope?

prompt>python -c "import this"
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


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




From Peter.Bienstman at rug.ac.be  Tue Sep 10 21:27:57 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Tue, 10 Sep 2002 15:27:57 -0400
Subject: [C++-sig] Need help on enum--a concrete example
In-Reply-To: <089401c258c2$daeab5f0$6401a8c0@boostconsulting.com>
References: <20020903160009.17077.16036.Mailman@mail.python.org> <200209101033.23991.Peter.Bienstman@rug.ac.be> <089401c258c2$daeab5f0$6401a8c0@boostconsulting.com>
Message-ID: <200209101528.00906.Peter.Bienstman@rug.ac.be>

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

On Tuesday 10 September 2002 08:04, David Abrahams wrote:
> <<
> From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>
>
> Small question: is there a trick to pollute the global namespace with the
> constants, such that one can write just 'red' in Python, rather than
> 'choice.red'?
>
> I know it's less clean, but it's easier for the user and ties in better
> with
> Python's weak typing.
>
>
> It doesn't tie in well with Python's "strong namespaceing".
> There is no global namespace in Python. Do you mean that you'd like the
> constants to be in the enclosing scope?

Yep, point taken, that's what I mean.

For backwards compatibility and ease of use, I'd like my users to be able to 
write:

set_polarisation(TE)

rather than

set_polarisation(polarisation.TE)

Is this possible? I'm perfectly fine with being burnt on the stake for being a 
namespace heretic ;-)

Cheers,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9fkfA4dgPAIjyquoRAuZBAKDyiOdbn6QLtJEBf1M1znLOe2AGugCfcOdC
cWUZu8uT+Yr/uhSkLg0T6XY=
=6vnf
-----END PGP SIGNATURE-----




From dave at boost-consulting.com  Tue Sep 10 15:42:29 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 10 Sep 2002 09:42:29 -0400
Subject: [C++-sig] Need help on enum--a concrete example
References: <20020903160009.17077.16036.Mailman@mail.python.org> <200209101033.23991.Peter.Bienstman@rug.ac.be> <089401c258c2$daeab5f0$6401a8c0@boostconsulting.com> <200209101528.00906.Peter.Bienstman@rug.ac.be>
Message-ID: <098401c258d0$2faa5890$6401a8c0@boostconsulting.com>

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

<<
For backwards compatibility and ease of use, I'd like my users to be able
to
write:

set_polarisation(TE)

rather than

set_polarisation(polarisation.TE)

Is this possible? I'm perfectly fine with being burnt on the stake for
being a
namespace heretic ;-)
>>

I don't want to move them out of the enum's namespace completely. But what
if we add an "export()" member function to the enum_<> class which dumps
all of its values into the enclosing scope?

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





From Peter.Bienstman at rug.ac.be  Tue Sep 10 21:58:20 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Tue, 10 Sep 2002 15:58:20 -0400
Subject: [C++-sig] Need help on enum--a concrete example
In-Reply-To: <098401c258d0$2faa5890$6401a8c0@boostconsulting.com>
References: <20020903160009.17077.16036.Mailman@mail.python.org> <200209101528.00906.Peter.Bienstman@rug.ac.be> <098401c258d0$2faa5890$6401a8c0@boostconsulting.com>
Message-ID: <200209101558.27334.Peter.Bienstman@rug.ac.be>

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

> I don't want to move them out of the enum's namespace completely. But what
> if we add an "export()" member function to the enum_<> class which dumps
> all of its values into the enclosing scope?

Sounds good!

Thanks,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9fk7i4dgPAIjyquoRArxdAJ9TXLsXddhjxA2d40BpS4d9Ha2QxgCcCNS2
dWt/5TgNze4h6cZ/SxXL93w=
=zihs
-----END PGP SIGNATURE-----




From robertoschler at hotmail.com  Tue Sep 10 20:13:07 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Tue, 10 Sep 2002 14:13:07 -0400
Subject: [C++-sig] Linux?
Message-ID: <OE45pH71yEXUIEAOeIi0000000f@hotmail.com>

Does BoostPython work on Linux?  If so I'm going to try giving it a whirl with Kylix 3 Pro on the C++ side and Python2 on the Python side.  Nothing on the spam side.

thx

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

From gideon at computer.org  Thu Sep 12 12:47:17 2002
From: gideon at computer.org (gideon may)
Date: Thu, 12 Sep 2002 12:47:17 +0200
Subject: [C++-sig] compilation problems with mingw v2.0
Message-ID: <7625665.1031834837@dyn151.snm-hgkz.ch>

Hi,

Has anyone succeeded in compiling bpl v1 or v2 with the
current mingw compiler (v2.0) under windows ? This
version is based on gcc 3.2. The rest of the boost libraries
compile cleanly.

When I try to compile bpl v2 I get the following message :

...found 585 targets...
...updating 24 targets...
mingw-C++-action 
..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj
In file included from src/list.cpp:6:
C:/cvs_rep/boost/boost/python/list.hpp:17: declaration does not declare
   anything
C:/cvs_rep/boost/boost/python/list.hpp:17: parse error before `)' token
src/list.cpp:19: parse error before `)' token
src/list.cpp:23: parse error before `)' token

    c:\SDKs\MinGW\bin\g++  -c -Wall -ftemplate-depth-100 
-DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE  -g
 -O0 -fno-inline   -I"..\..\libs\python"  -isystem "C:\cvs_rep\boost" 
-isystem "c:\Python22\include" -isystem "c:\SDKs\MinGW\inc
lude"  -o 
"..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj" 
"src\list.cpp"

...failed mingw-C++-action 
..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj...

My environment :

Win2K
Python 2.2.1 (ActiveState)
Latest CVS update of Boost

COMSPEC=C:\WINNT\system32\cmd.exe
MINGW_ROOT_DIRECTORY=c:\SDKs\MinGW
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
PYTHON_ROOT=c:\Python22
PYTHON_VERSION=2.2
SYSTEMROOT=C:\WINNT
TMP=/cygdrive/c/DOCUME~1/gideon/LOCALS~1/Temp
WINDIR=C:\WINNT

bjam command : bjam -sTOOLS=mingw

ciao,

gideon



From rwgk at yahoo.com  Thu Sep 12 16:24:41 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 12 Sep 2002 07:24:41 -0700 (PDT)
Subject: [C++-sig] wrapping a custom C++ iterator
Message-ID: <20020912142441.17364.qmail@web20203.mail.yahoo.com>

I have just wrapped my first custom C++ iterator with Boost.Python V2.
The C++ interface is minimal, there is just a default constructor and
a member function next(). In C++, end of iteration is determined by
inspecting the state of the result of next().
Attached is my code for the Python bindings. I feel quite confident
about my implementation of the binding for next(), but I am a bit
uncertain about the __iter__ hook:

1.
    static w_t& iter(w_t& o) { return o; }

2.
        .def("__iter__", iter, return_internal_reference<>())

This works, but is it the right approach?

Thanks!
        Ralf


  struct space_group_symbol_iterator_wrappers
  {
    typedef space_group_symbol_iterator w_t;

    static space_group_symbols
    next(w_t& o)
    {
      space_group_symbols result = o.next();
      if (result.sg_number() == 0) {
        PyErr_SetString(PyExc_StopIteration, "At end of table.");
        boost::python::throw_error_already_set();
      }
      return result;
    }

    static w_t& iter(w_t& o) { return o; }

    static void
    wrap()
    {
      using namespace boost::python;
      class_<w_t>("space_group_symbol_iterator",
        args<>())
        .def("next", next)
        .def("__iter__", iter, return_internal_reference<>())
      ;
    }
  };


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From leo at hiper.com.br  Thu Sep 12 23:09:11 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 12 Sep 2002 18:09:11 -0300
Subject: [C++-sig] convertibility and "Pythonicity"
In-Reply-To: <00ba01c24b70$304035d0$6501a8c0@boostconsulting.com>
References: <00ba01c24b70$304035d0$6501a8c0@boostconsulting.com>
Message-ID: <1031864951.22345.3.camel@spitfire>

I just found out that some smtp server decided not to forward the
message below, which I sent on August 25th.

On Sat, 2002-08-24 at 10:14, David Abrahams wrote:
> [Is "Pythonicity" the right word?]

I don't know, but I like it :-)

> 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'

This fails in Python 1.5, works in 2.x

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


From leo at hiper.com.br  Thu Sep 12 23:35:12 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 12 Sep 2002 18:35:12 -0300
Subject: [C++-sig] stage rule and version in .so name
Message-ID: <1031866512.22389.5.camel@spitfire>

Hi,

I'm trying to make it easier to test stuff I built with boost python, so
I created some stage rules to gather all stuff I need so that I could,
say, just copy them over to /usr/local and have them work. For instance,
I added the following snipped to boost/libs/python/example/Jamfile:

stage distrib/lib/python$(PYTHON_VERSION)/site-packages
:  # extensions
   <pyd>getting_started1
   ;

stage distrib/lib
:  # needed libraries
   <dll>../build/boost_python
   ;

This same Jamfile has this extension rule:

# Declare a Python extension called getting_started1
extension getting_started1
:  # sources
   getting_started1.cpp

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


The stage rules above generate the following directory tree:

distrib/
distrib/lib
distrib/lib/python2.1
distrib/lib/python2.1/site-packages
distrib/lib/python2.1/site-packages/getting_started1.so
distrib/lib/libboost_python.so

which is mostly what I expected, except that:

$ ldd distrib/lib/python2.1/site-packages/getting_started1.so 
	libboost_python.so.1.29.0 => not found
	libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40021000)
	libm.so.6 => /lib/libm.so.6 (0x4006a000)
	libc.so.6 => /lib/libc.so.6 (0x4008b000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

The "not found" above is not important, what's important is that the
same <dll>../build/boost_python, when in the "stage" rule, generates a
libboost_python.so, but in the "extension" rule, makes the extesion
depend on libboost_python.so.1.29.0 which I think is a bug.

I believe the correct behaviour would be for the "stage" rule to
copy/generate the same thing that the extension rule make
getting_started1.so depend on, that is, to generate a
libboost_python.so.1.29.0 in the distrib/lib directory. But I have no
idea how to go about it.

Any thoughts?

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




From dave at boost-consulting.com  Thu Sep 12 16:45:21 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Sep 2002 10:45:21 -0400
Subject: [C++-sig] compilation problems with mingw v2.0
References: <7625665.1031834837@dyn151.snm-hgkz.ch>
Message-ID: <08ba01c25aa5$30430f00$6401a8c0@boostconsulting.com>

Gideon,

I just reproduced the problem you cite. As far as I can tell, this is
simply a bug in this version of GCC, since previous versions of MinGW (and
numerous other compilers) have no problems with that code. If you will
report the problem to the appropriate GCC/MinGW developers, I'll be happy
to attempt a workaround on this end. A good bug report would at least
include a preprocessed copy of the offending source file, but even better
would be a minimal reproducible case.

Regards,
Dave

-----------------------------------------------------------
           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: Thursday, September 12, 2002 6:47 AM
Subject: [C++-sig] compilation problems with mingw v2.0


> Hi,
>
> Has anyone succeeded in compiling bpl v1 or v2 with the
> current mingw compiler (v2.0) under windows ? This
> version is based on gcc 3.2. The rest of the boost libraries
> compile cleanly.
>
> When I try to compile bpl v2 I get the following message :
>
> ...found 585 targets...
> ...updating 24 targets...
> mingw-C++-action
> ..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj
> In file included from src/list.cpp:6:
> C:/cvs_rep/boost/boost/python/list.hpp:17: declaration does not declare
>    anything
> C:/cvs_rep/boost/boost/python/list.hpp:17: parse error before `)' token
> src/list.cpp:19: parse error before `)' token
> src/list.cpp:23: parse error before `)' token
>
>     c:\SDKs\MinGW\bin\g++  -c -Wall -ftemplate-depth-100
> -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE  -g
>  -O0 -fno-inline   -I"..\..\libs\python"  -isystem "C:\cvs_rep\boost"
> -isystem "c:\Python22\include" -isystem "c:\SDKs\MinGW\inc
> lude"  -o
> "..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj"
> "src\list.cpp"
>
> ...failed mingw-C++-action
>
..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj...
>
> My environment :
>
> Win2K
> Python 2.2.1 (ActiveState)
> Latest CVS update of Boost
>
> COMSPEC=C:\WINNT\system32\cmd.exe
> MINGW_ROOT_DIRECTORY=c:\SDKs\MinGW
> NUMBER_OF_PROCESSORS=1
> OS=Windows_NT
> PYTHON_ROOT=c:\Python22
> PYTHON_VERSION=2.2
> SYSTEMROOT=C:\WINNT
> TMP=/cygdrive/c/DOCUME~1/gideon/LOCALS~1/Temp
> WINDIR=C:\WINNT
>
> bjam command : bjam -sTOOLS=mingw
>
> ciao,
>
> gideon
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From grafik666 at redshift-software.com  Thu Sep 12 23:49:14 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Thu, 12 Sep 2002 16:49:14 -0500
Subject: [C++-sig] stage rule and version in .so name
In-Reply-To: <1031866512.22389.5.camel@spitfire>
Message-ID: <20020912164915-r01010800-9a75d52b-0860-0108@12.100.89.43>

I know, I know :-) I guess I can look into finally fixing this. No promises
though, getting the real target names generated is not easy.

[2002-09-12] Leonardo Rochael Almeida wrote:
>
>Hi,
>
>I'm trying to make it easier to test stuff I built with boost python, so
>I created some stage rules to gather all stuff I need so that I could,
>say, just copy them over to /usr/local and have them work. For instance,
>I added the following snipped to boost/libs/python/example/Jamfile:
>
>stage distrib/lib/python$(PYTHON_VERSION)/site-packages

I see someone else noticed that subdir trick :-)

>I believe the correct behaviour would be for the "stage" rule to
>copy/generate the same thing that the extension rule make
>getting_started1.so depend on, that is, to generate a
>libboost_python.so.1.29.0 in the distrib/lib directory. But I have no
>idea how to go about it.
>
>Any thoughts?

I wish it where only as easy as just generating the *.1.29.0 file. But Linux
SONAME loading is way more anoying than that. I have to replicate both the
bare and versioned files for linking and cross loading to work correctly.


-- 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  Fri Sep 13 00:20:43 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Sep 2002 18:20:43 -0400
Subject: [C++-sig] wrapping a custom C++ iterator
References: <20020912142441.17364.qmail@web20203.mail.yahoo.com>
Message-ID: <093601c25aaa$b63741d0$6401a8c0@boostconsulting.com>

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


> I have just wrapped my first custom C++ iterator with Boost.Python V2.
> The C++ interface is minimal, there is just a default constructor and
> a member function next(). In C++, end of iteration is determined by
> inspecting the state of the result of next().
> Attached is my code for the Python bindings. I feel quite confident
> about my implementation of the binding for next(), but I am a bit
> uncertain about the __iter__ hook:
>
> 1.
>     static w_t& iter(w_t& o) { return o; }
>
> 2.
>         .def("__iter__", iter, return_internal_reference<>())
>
> This works, but is it the right approach?

I guess it's fine, but it doesn't use the built-in support for C++
iterators.
If you had a C++ iterator you could turn it into a Python iterator
automatically using the facilities described in
libs/python/doc/v2/iterator.html.

Well, technically it's not quite right, since __iter__ on an iterator type
is supposed to return the same object, and what you're doing returns a new
object (which wraps a reference to the same C++ object).

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






From dave at boost-consulting.com  Fri Sep 13 01:18:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Sep 2002 19:18:47 -0400
Subject: [C++-sig] compilation problems with mingw v2.0
References: <7625665.1031834837@dyn151.snm-hgkz.ch> <08ba01c25aa5$30430f00$6401a8c0@boostconsulting.com>
Message-ID: <0a1301c25ab3$287f4370$6401a8c0@boostconsulting.com>

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


> Gideon,
>
> I just reproduced the problem you cite. As far as I can tell, this is
> simply a bug in this version of GCC, since previous versions of MinGW
(and
> numerous other compilers) have no problems with that code. If you will
> report the problem to the appropriate GCC/MinGW developers, I'll be happy
> to attempt a workaround on this end. A good bug report would at least
> include a preprocessed copy of the offending source file, but even better
> would be a minimal reproducible case.


And now I have the compilation workaround on my disk, but there are
inexplicable errors linking to Python-22.lib: it's having no problem
linking to functions, but data objects like PyList_Type aare choking it.
Can you build and link a simple "C" extension module with this compiler? It
seems like something is very wrong here!

c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
obj: In function `ZN5boost6python4list4callERKNS0_3api6objectE':
c:/boost/libs/python/test/../../../libs/python/src/list.cpp:12: undefined
reference to `_imp__PyList_Type'
c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
obj: In function `ZN5boost6python4list6appendERKNS0_3api6objectE':
c:/boost/libs/python/test/../../../libs/python/src/list.cpp:29: undefined
reference to `_imp__PyList_Type'
c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
obj: In function `ZN5boost6python4list6insertEiRKNS0_3api6objectE':
c:/boost/libs/python/test/../../../libs/python/src/list.cpp:65: undefined
reference to `_imp__PyList_Type'
c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
obj: In function `ZN5boost6python4list7reverseEv':
c:/boost/libs/python/test/../../../libs/python/src/list.cpp:106: undefined
reference to `_imp__PyList_Type'
c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
obj: In function `ZN5boost6python4list4sortEv':
c:/boost/libs/python/test/../../../libs/python/src/list.cpp:119: undefined
reference to `_imp__PyList_Type'
c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\long.
obj: In function `ZN5boost6python5long_4callERKNS0_3api6objectE':
c:/boost/libs/python/test/../../../libs/python/src/long.cpp:12: undefined
reference to `_imp__PyLong_Type'
...


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





From dave at boost-consulting.com  Fri Sep 13 01:55:18 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Sep 2002 19:55:18 -0400
Subject: [C++-sig] compilation problems with mingw v2.0
References: <7625665.1031834837@dyn151.snm-hgkz.ch> <08ba01c25aa5$30430f00$6401a8c0@boostconsulting.com> <0a1301c25ab3$287f4370$6401a8c0@boostconsulting.com>
Message-ID: <0a6201c25ab7$d9d0ccd0$6401a8c0@boostconsulting.com>

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

> And now I have the compilation workaround on my disk, but there are
> inexplicable errors linking to Python-22.lib: it's having no problem
> linking to functions, but data objects like PyList_Type aare choking it.
> Can you build and link a simple "C" extension module with this compiler?
It
> seems like something is very wrong here!

These changes are now checked into CVS, so you can reproduce them at will.


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




From gideon at computer.org  Fri Sep 13 17:49:17 2002
From: gideon at computer.org (gideon may)
Date: Fri, 13 Sep 2002 17:49:17 +0200
Subject: [C++-sig] compilation problems with mingw v2.0
Message-ID: <3013413.1031939357@[10.0.0.11]>

Thanks Dave,

I'll do some more investigating on my side. Got the same problems
as you mentioned. I'll get back on it when I know more.

Another support topic, not that important though. Is it forseeable
that there is going to be support for the SGI Mips compilers ?
I'm currently using version 7.3.1.1m and unfortunately without support.
Getting many errors, even ICE :)
/mount/l1/people/gideon/cvs/boost/boost/boost/operators.hpp:794: Internal 
compiler error 382.
/mount/l1/people/gideon/cvs/boost/boost/boost/operators.hpp:794: Please 
submit a full bug report to `egcs-bugs at egcs.cygnus.com'.
/mount/l1/people/gideon/cvs/boost/boost/boost/operators.hpp:794: See 
<URL:http://egcs.cygnus.com/faq.html#bugreport> for details.

Would just be nice to see SGI as a viable platform, have some very nice 
memories with these boxes.

ciao,

gideon




From grafik666 at redshift-software.com  Fri Sep 13 18:11:52 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Fri, 13 Sep 2002 11:11:52 -0500
Subject: [C++-sig] stage rule and version in .so name
In-Reply-To: <20020912164915-r01010800-9a75d52b-0860-0108@12.100.89.43>
Message-ID: <20020913111153-r01010800-f42cf40b-0860-0108@12.100.89.43>

[2002-09-12] Rene Rivera wrote:
>[2002-09-12] Leonardo Rochael Almeida wrote:
>>I believe the correct behaviour would be for the "stage" rule to
>>copy/generate the same thing that the extension rule make
>>getting_started1.so depend on, that is, to generate a
>>libboost_python.so.1.29.0 in the distrib/lib directory. But I have no
>>idea how to go about it.
>>
>>Any thoughts?
>
>I wish it where only as easy as just generating the *.1.29.0 file. But
Linux
>SONAME loading is way more anoying than that. I have to replicate both the
>bare and versioned files for linking and cross loading to work correctly.

OK, I just put in some changes which attempt to clone the exact state of the
files actually generated by the SONAME support. It's not totally working as
it should, and it never will in V1. But for now it should be reasonable, as
long as you don't use the "tag" features of stage for SONAMEd files.

Try it and tell me if it works for your needs.


-- 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  Fri Sep 13 18:09:41 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 13 Sep 2002 12:09:41 -0400
Subject: [C++-sig] compilation problems with mingw v2.0
References: <3013413.1031939357@[10.0.0.11]>
Message-ID: <0d6501c25b40$7b991620$6401a8c0@boostconsulting.com>

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


> Thanks Dave,
>
> I'll do some more investigating on my side. Got the same problems
> as you mentioned. I'll get back on it when I know more.
>
> Another support topic, not that important though. Is it forseeable
> that there is going to be support for the SGI Mips compilers ?
> I'm currently using version 7.3.1.1m and unfortunately without support.
> Getting many errors, even ICE :)
> /mount/l1/people/gideon/cvs/boost/boost/boost/operators.hpp:794: Internal
> compiler error 382.
> /mount/l1/people/gideon/cvs/boost/boost/boost/operators.hpp:794: Please
> submit a full bug report to `egcs-bugs at egcs.cygnus.com'.
> /mount/l1/people/gideon/cvs/boost/boost/boost/operators.hpp:794: See
> <URL:http://egcs.cygnus.com/faq.html#bugreport> for details.
>
> Would just be nice to see SGI as a viable platform, have some very nice
> memories with these boxes.

It is currently working on SGI. Well, maybe the last test run was
problematic for some reason, but the last build run seemed to go OK. In
general it's hard to keep this compiler happy, but Ralf has been trying to
maintain it:

http://cci.lbl.gov/boost/

Shows the current status.

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





From rwgk at yahoo.com  Fri Sep 13 18:32:32 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 13 Sep 2002 09:32:32 -0700 (PDT)
Subject: [C++-sig] wrapping a custom C++ iterator
In-Reply-To: <093601c25aaa$b63741d0$6401a8c0@boostconsulting.com>
Message-ID: <20020913163232.88974.qmail@web20202.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > 1.
> >     static w_t& iter(w_t& o) { return o; }
> >
> > 2.
> >         .def("__iter__", iter, return_internal_reference<>())
> >
> > This works, but is it the right approach?
> 
> I guess it's fine, but it doesn't use the built-in support for C++
> iterators.
> If you had a C++ iterator you could turn it into a Python iterator
> automatically using the facilities described in
> libs/python/doc/v2/iterator.html.

I looked at this before and came to the conclusion that I'd have to refactor my
class to make it suitable for use with the built-in iterator support (I have no
iterator typedefs, no begin, no end, no operator++). This is not really
something I'd like to do.

> Well, technically it's not quite right, since __iter__ on an iterator type
> is supposed to return the same object, and what you're doing returns a new
> object (which wraps a reference to the same C++ object).

OK, thanks for pointing this out! I changed my code:

1.
    static boost::python::object iter(boost::python::object const& o)
    {
      return o;
    }

2.
        .def("__iter__", iter)
    
In Python this works now:

  i = sgtbx.space_group_symbol_iterator()
  assert id(i) == id(iter(i))

Is this approach technically OK?

Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From dave at boost-consulting.com  Fri Sep 13 18:38:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 13 Sep 2002 12:38:56 -0400
Subject: [C++-sig] wrapping a custom C++ iterator
References: <20020913163232.88974.qmail@web20202.mail.yahoo.com>
Message-ID: <0d7301c25b44$7e8e1660$6401a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> OK, thanks for pointing this out! I changed my code:
> 
> 1.
>     static boost::python::object iter(boost::python::object const& o)
>     {
>       return o;
>     }
> 
> 2.
>         .def("__iter__", iter)
>     
> In Python this works now:
> 
>   i = sgtbx.space_group_symbol_iterator()
>   assert id(i) == id(iter(i))
> 
> Is this approach technically OK?

I guess so. It seems like it should be.

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






From rwgk at yahoo.com  Fri Sep 13 19:10:00 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 13 Sep 2002 10:10:00 -0700 (PDT)
Subject: [C++-sig] compilation problems with mingw v2.0
In-Reply-To: <0d6501c25b40$7b991620$6401a8c0@boostconsulting.com>
Message-ID: <20020913171000.98859.qmail@web20204.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Would just be nice to see SGI as a viable platform, have some very nice
> > memories with these boxes.

You're showing your age here ;-)

> It is currently working on SGI. Well, maybe the last test run was
> problematic for some reason, but the last build run seemed to go OK. In
> general it's hard to keep this compiler happy, but Ralf has been trying to
> maintain it:
> 
> http://cci.lbl.gov/boost/
> 
> Shows the current status.

We are using

MIPSpro Compilers: Version 7.3.1.2m
MIPSpro Compilers: Version 7.3.1.3m

There is a gcc 3.0.4 binary in the SGI freeware section that worked for us a
while ago. Maybe they have more recent gcc versions now.

Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From rwgk at yahoo.com  Fri Sep 13 19:19:50 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 13 Sep 2002 10:19:50 -0700 (PDT)
Subject: [C++-sig] char '\0' -> "\0" or ""?
Message-ID: <20020913171950.65231.qmail@web20206.mail.yahoo.com>

Consider

char foo() { return '\0'; }

def("foo", foo);

Python with Boost.Python V1: foo() == ""
Python with Boost.Python V2: foo() == "\0"

Is this difference intentional?
I'd prefer the V1 result.
Opinions?

Thanks,
        Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From gideon at computer.org  Fri Sep 13 19:23:40 2002
From: gideon at computer.org (gideon may)
Date: Fri, 13 Sep 2002 19:23:40 +0200
Subject: [C++-sig] compilation problems with mingw v2.0
In-Reply-To: <20020913171000.98859.qmail@web20204.mail.yahoo.com>
References: <20020913171000.98859.qmail@web20204.mail.yahoo.com>
Message-ID: <8675474.1031945020@[10.0.0.11]>

> You're showing your age here ;-)

Good old times when the only library you needed to know was iris gl and
had the feeling you understood whatever was going on inside your system :O

>> Shows the current status.
>
> We are using
>
> MIPSpro Compilers: Version 7.3.1.2m
> MIPSpro Compilers: Version 7.3.1.3m

Guess my compiler version is a bit out of date (7.3.1.1m). I'll see if I 
can
hunt down a newer version.

> There is a gcc 3.0.4 binary in the SGI freeware section that worked for
> us a while ago. Maybe they have more recent gcc versions now.

I'm afraid that trying to compile the boost library with gcc 3.x would
be a bit too much for the sgi box I have (O2 180MHz SC).
Just linking the wrapper which I'm working on (OpenSceneGraph) takes already
about 20 mins on a 1GHz Pentium running Linux.

For me the irix version is more a proof of concept than a necessity.
Still, I'll give it a try with gcc 3.2

ciao,

gideon



From dave at boost-consulting.com  Fri Sep 13 21:16:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 13 Sep 2002 15:16:07 -0400
Subject: [C++-sig] compilation problems with mingw v2.0
References: <3013413.1031939357@[10.0.0.11]>
Message-ID: <0dad01c25b5b$f2625f80$6401a8c0@boostconsulting.com>

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


> Thanks Dave,
>
> I'll do some more investigating on my side. Got the same problems
> as you mentioned. I'll get back on it when I know more.

Remember the bargain: you're gonna submit full bug reports to the
appropriate parties, right?
I know, you never agreed to that, but I'm hoping you will!

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




From sashang at ihug.co.nz  Sat Sep 14 10:37:50 2002
From: sashang at ihug.co.nz (sashan)
Date: Sat, 14 Sep 2002 20:37:50 +1200
Subject: [C++-sig] Cross-extension-module dependencies
Message-ID: <3D82F55E.7060706@ihug.co.nz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020914/3e6eaa70/attachment.htm>

From sashang at ihug.co.nz  Sat Sep 14 12:06:18 2002
From: sashang at ihug.co.nz (sashan)
Date: Sat, 14 Sep 2002 22:06:18 +1200
Subject: [C++-sig] Cross-extension-module dependencies
References: <3D82F55E.7060706@ihug.co.nz>
Message-ID: <3D830A1A.2020709@ihug.co.nz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020914/a53b694b/attachment.htm>

From dave at boost-consulting.com  Sat Sep 14 13:19:26 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 14 Sep 2002 07:19:26 -0400
Subject: [C++-sig] Cross-extension-module dependencies
References: <3D82F55E.7060706@ihug.co.nz>
Message-ID: <0f7a01c25be0$9e8f2b60$6401a8c0@boostconsulting.com>

From: "sashan" <sashang at ihug.co.nz>


> Hi
>
> After about a week of part-time fiddling I found that the info in the
Cross-extension-module dependencies document helped solve my problem. So I
set it up so that the Quaternion class I'm working with knows about the
Vector class (i.e stuck the appropriate export_converters and
import_converters in the right place). Now I can make use of Quaternion
member functions that take a Vector as an argument.  Problem is I've got a
function like this:
>
>  void Quaternion::ToAngleAxis (float& rfAngle, Vector3& rkAxis) const;
>
> that the compiler (VC++ 6.0) refuses to deal with because of the float&.
It basically says
>
> error C2665: 'from_python' : none of the 74 overloads can convert
parameter 2 from type 'struct boost::python::type<float &>'
>
> The other functions like
> void FromAngleAxis (const Real& rfAngle, const Vector3& rkAxis);
> compile fine.
>
> I don't know what to do. I don't understand why it's complaining about
float&? float is a primitive type so it shouldn't complain. I downloaded
the latest boost source today (14th September 2002).
>
> Any help appreciated. Thanks in advance.

Python has no type which contains a mutable C++ float, so the library
refuses to let you bind a non-const reference to one. Actually, Python has
no type which contains a float at all. The python float type contains an
immutable C++ double.

HTH,
Dave

BTW, if you're not too far along in your project, you should consider
switching to Boost.Python v2, since it is going to be released within a
month and v1 will then be retired. It also imports/exports all converters
automatically.

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




From dave at boost-consulting.com  Sat Sep 14 14:29:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 14 Sep 2002 08:29:40 -0400
Subject: [C++-sig] ANN: use of MPL v2
Message-ID: <0fd401c25bea$be3c6860$6401a8c0@boostconsulting.com>

This is an advance warning:

Boost.Python v2 has been converted to internally use what will be the
release version of the Boost Metaprogramming Library. This version of
Boost.Python v2 is currently on a branch in the CVS tree, but will be moved
to the main trunk soon. These changes don't affect the user interface of
Boost.Python, just the implementation. To begin working with the new
version now:

    cd <boost-root-directory>
    cvs update -P -d               # in case you're not up-to-date
    cvs update -P -d -rmpl_v2 boost/python boost/mpl boost/type_traits
boost/type_traits.hpp

Soon, all this will be on the main trunk of CVS, though we'll probably go
in stages with Boost.Python moving first.

Regards,
Dave

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






From lists at UltimateG.com  Sat Sep 14 21:15:58 2002
From: lists at UltimateG.com (Mark Evans)
Date: Sat, 14 Sep 2002 12:15:58 -0700
Subject: [C++-sig] Weave Scipy Inline C++
Message-ID: <161892220.20020914121558@UltimateG.com>

http://www.scipy.org/site_content/weave

Can Boost do anything like this?  These folks are planning to use SCXX
while I am trying to get them to use Boost Python for C++ interfacing.
They keep talking about Pythonic C++ classes, but I think that
limiting inline C++ to such classes will severely limit Weave.

Their statement is:

Message: 5
From: "eric jones" <eric at enthought.com>
To: <scipy-dev at scipy.net>
Subject: RE: [SciPy-dev] Boost vs CXX and SCXX
Date: Fri, 13 Sep 2002 14:53:26 -0500
Reply-To: scipy-dev at scipy.net

Hey Mark,

Like you, I'd pick boost or SWIG (which has made *huge* leaps in the
last year for C++ stuff) for wrapping a C++ library.  But that isn't
what we're choosing here.  Weave allows you to inline C++ code within
Python.  It is nice to have a representation of Python objects in the
C++ code that look Pythonic.  C++ classes allow this sort of thing.

CXX wrappers allowed this sort of thing:

>>> import weave
>>> a= [1,2]
>>> weave.inline('a[0] = Py::Int(3)',['a'])
>>> a[0]
[3, 2]

Now with SCXX, we have:

>>> import weave
>>> a = [1,2]
>>> weave.inline('a[0] = PWONumber(3);',['a'])
>>> a
[3, 2]

I doubt boost would be much different or superior to either of these
in terms of readability or use.

As I said before, most of the tools boost provides help with wrapping
code and aren't beneficial in the context of weave.  All we're looking
for is a few measly classes for wrapping lists, dicts, and tuples --
although callable objects, files, and modules are other potential
targets.  If we can extract these easily from boost, they compile
easily on everything, and they offer some benefits over these other two
approachs *in the context of weave*, then its worth considering a
change.  I'm happy to look at an experimental patch. :-)

eric




From lists at UltimateG.com  Sat Sep 14 21:32:48 2002
From: lists at UltimateG.com (Mark Evans)
Date: Sat, 14 Sep 2002 12:32:48 -0700
Subject: [C++-sig] Re: Weave Scipy Inline C++
In-Reply-To: <161892220.20020914121558@UltimateG.com>
References: <161892220.20020914121558@UltimateG.com>
Message-ID: <972901922.20020914123248@UltimateG.com>

See also
http://pyinline.sourceforge.net/




From dave at boost-consulting.com  Sat Sep 14 23:28:03 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 14 Sep 2002 17:28:03 -0400
Subject: [C++-sig] Weave Scipy Inline C++
References: <161892220.20020914121558@UltimateG.com>
Message-ID: <113501c25c35$b319a6a0$6401a8c0@boostconsulting.com>

From: "Mark Evans" <lists at UltimateG.com>


>
> http://www.scipy.org/site_content/weave
>
> Can Boost do anything like this?  These folks are planning to use SCXX
> while I am trying to get them to use Boost Python for C++ interfacing.

Boost doesn't provide any facilities for on-demand compilation of C++ code
from Python, if that's what you're getting at.

> They keep talking about Pythonic C++ classes, but I think that
> limiting inline C++ to such classes will severely limit Weave.

Sorry, I don't understand what you're saying.

> Their statement is:
>
> Message: 5
> From: "eric jones" <eric at enthought.com>
> To: <scipy-dev at scipy.net>
> Subject: RE: [SciPy-dev] Boost vs CXX and SCXX
> Date: Fri, 13 Sep 2002 14:53:26 -0500
> Reply-To: scipy-dev at scipy.net
>
> Hey Mark,
>
> Like you, I'd pick boost or SWIG (which has made *huge* leaps in the
> last year for C++ stuff) for wrapping a C++ library.  But that isn't
> what we're choosing here.  Weave allows you to inline C++ code within
> Python.  It is nice to have a representation of Python objects in the
> C++ code that look Pythonic.  C++ classes allow this sort of thing.

Well, Boost.Python v2 does let you have a reasonably Pythonic
representation of Python objects from C++. See the June progress report at

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

for details...but I don't see how that relates the the examples below.


> CXX wrappers allowed this sort of thing:
>
> >>> import weave
> >>> a= [1,2]
> >>> weave.inline('a[0] = Py::Int(3)',['a'])
> >>> a[0]
> [3, 2]
>
> Now with SCXX, we have:
>
> >>> import weave
> >>> a = [1,2]
> >>> weave.inline('a[0] = PWONumber(3);',['a'])
> >>> a
> [3, 2]
>
> I doubt boost would be much different or superior to either of these
> in terms of readability or use.
>
> As I said before, most of the tools boost provides help with wrapping
> code and aren't beneficial in the context of weave.  All we're looking
> for is a few measly classes for wrapping lists, dicts, and tuples --
> although callable objects, files, and modules are other potential
> targets.  If we can extract these easily from boost, they compile
> easily on everything, and they offer some benefits over these other two
> approachs *in the context of weave*, then its worth considering a
> change.  I'm happy to look at an experimental patch. :-)

Are you trying to change what the weave folks are doing?
Hmm, why?


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





From eric at enthought.com  Sun Sep 15 01:01:05 2002
From: eric at enthought.com (eric jones)
Date: Sat, 14 Sep 2002 18:01:05 -0500
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <161892220.20020914121558@UltimateG.com>
Message-ID: <000001c25c42$9bc7ba70$777ba8c0@ericlaptop>

Hey Mark,

> http://www.scipy.org/site_content/weave
> 
> Can Boost do anything like this?  These folks are planning to use SCXX
> while I am trying to get them to use Boost Python for C++ interfacing.
> They keep talking about Pythonic C++ classes, but I think that
> limiting inline C++ to such classes will severely limit Weave.

What is this "severe limitation"?  I just don't understand.  Do you have
a use case to help me out here?

We have a very light weight need -- making dicts, tuples, and lists easy
to use in C++ so that inline C++ code looks as much like Python as
possible.  This is about 0.3% of boost's capabilities.  On the other
hand, it uses about 95% of SCXX capabilities which means it is a good
fit.  SCXX is 900 lines of code and easy to port anywhere.

If you need the other 99.7% of boost's capabilities, then you probably
need to be using boost instead of weave anyhow.  They serve different
purposes.  Weave is generally suited for light weight wrapping and
speeding up computational kernels with minimum hassle -- especially in
numeric codes where Numeric isn't fast enough.  

Oh, and I'm happy to except patches that allow for boost type converters
in weave (they should, after all, be easy to write).  Then you can use
boost instead of SCXX.

Regards,
eric

> 
> Their statement is:
> 
> Message: 5
> From: "eric jones" <eric at enthought.com>
> To: <scipy-dev at scipy.net>
> Subject: RE: [SciPy-dev] Boost vs CXX and SCXX
> Date: Fri, 13 Sep 2002 14:53:26 -0500
> Reply-To: scipy-dev at scipy.net
> 
> Hey Mark,
> 
> Like you, I'd pick boost or SWIG (which has made *huge* leaps in the
> last year for C++ stuff) for wrapping a C++ library.  But that isn't
> what we're choosing here.  Weave allows you to inline C++ code within
> Python.  It is nice to have a representation of Python objects in the
> C++ code that look Pythonic.  C++ classes allow this sort of thing.
> 
> CXX wrappers allowed this sort of thing:
> 
> >>> import weave
> >>> a= [1,2]
> >>> weave.inline('a[0] = Py::Int(3)',['a'])
> >>> a[0]
> [3, 2]
> 
> Now with SCXX, we have:
> 
> >>> import weave
> >>> a = [1,2]
> >>> weave.inline('a[0] = PWONumber(3);',['a'])
> >>> a
> [3, 2]
> 
> I doubt boost would be much different or superior to either of these
> in terms of readability or use.
> 
> As I said before, most of the tools boost provides help with wrapping
> code and aren't beneficial in the context of weave.  All we're looking
> for is a few measly classes for wrapping lists, dicts, and tuples --
> although callable objects, files, and modules are other potential
> targets.  If we can extract these easily from boost, they compile
> easily on everything, and they offer some benefits over these other
two
> approachs *in the context of weave*, then its worth considering a
> change.  I'm happy to look at an experimental patch. :-)
> 
> eric
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From dave at boost-consulting.com  Sun Sep 15 01:22:36 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 14 Sep 2002 19:22:36 -0400
Subject: [C++-sig] Weave Scipy Inline C++
References: <000001c25c42$9bc7ba70$777ba8c0@ericlaptop>
Message-ID: <11a901c25c45$a0f7ac00$6401a8c0@boostconsulting.com>

From: "eric jones" <eric at enthought.com>


> Hey Mark,
>
> > http://www.scipy.org/site_content/weave
> >
> > Can Boost do anything like this?  These folks are planning to use SCXX
> > while I am trying to get them to use Boost Python for C++ interfacing.
> > They keep talking about Pythonic C++ classes, but I think that
> > limiting inline C++ to such classes will severely limit Weave.
>
> What is this "severe limitation"?  I just don't understand.  Do you have
> a use case to help me out here?
>
> We have a very light weight need -- making dicts, tuples, and lists easy
> to use in C++ so that inline C++ code looks as much like Python as
> possible.  This is about 0.3% of boost's capabilities.

I agreed with that at first, but on second thought, well, maybe not. The
capability draws on Boost.Python's core C++<=>Python conversion mechanism,
which accounts for most of the hard stuff in the library.

> On the other
> hand, it uses about 95% of SCXX capabilities which means it is a good
> fit.  SCXX is 900 lines of code and easy to port anywhere.

If that's true, I doubt it's accomplishing the job as well as Boost.Python
does. Note that you never have to explicitly convert C++ objects to Python
when they are interacting with a Python object:

  object f(boost::python::object x)
  {
    x[1] = "hello";
    return x(1,2,3,4,5,6,x); // __call__
    ...

not

    x[Py::Int(1)] = Py::Str("hello");
    // ??? what does __call__ look like?

or whatever. Getting this code to work everywhere was one of the harder
porting jobs I've ever faced. Compilers seem to have lots of bugs in the
areas I was exercising.

However, you may still be right that it's not an appropriate solution for
weave.

> If you need the other 99.7% of boost's capabilities, then you probably
> need to be using boost instead of weave anyhow.  They serve different
> purposes.  Weave is generally suited for light weight wrapping and
> speeding up computational kernels with minimum hassle -- especially in
> numeric codes where Numeric isn't fast enough.
>
> Oh, and I'm happy to except patches that allow for boost type converters
> in weave (they should, after all, be easy to write).  Then you can use
> boost instead of SCXX.

What did you have in mind?

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





From rwgk at yahoo.com  Sun Sep 15 04:17:12 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 14 Sep 2002 19:17:12 -0700 (PDT)
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <113501c25c35$b319a6a0$6401a8c0@boostconsulting.com>
Message-ID: <20020915021712.48163.qmail@web20209.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Boost doesn't provide any facilities for on-demand compilation of C++ code
> from Python, if that's what you're getting at.

Boost.Python is a high-throughput factory for Python "built-in" types. Instead
of using the few native types (list, tuple, dict) you can easily make types
that are tailored for specific needs.

I am using Boost.Python in combination with SCons, which is much more mature
than the version number suggests. SCons is suitable as a "compilation on
demand" tool.

I am wondering how much of a run-time difference it can make if some trivial
pieces of compiled code working on objects through the (slow b/o dynamic
typing) Python API are embedded in Python. If speed is a premium you can gain
much more if the C++ code operates on native C++ types, without the overhead of
the Python API for accessing data items. This is precisely what Boost.Python
gives you. Typically, I cross the language boundary only once to do an
"expensive", non trivial operation in pure C++, and the result is a wrapped C++
object that can conveniently be inspected from Python.

Does it make sense to put Weave and Boost.Python together? Let me try an
analogy: if you choose Weave you are choosing a bicycle, and if you choose
Boost.Python you are choosing a car. Obviously the world needs both bicycles
and cars, but would you use a car as a building block for a bicycle?

Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From dave at boost-consulting.com  Sun Sep 15 04:31:51 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 14 Sep 2002 22:31:51 -0400
Subject: [C++-sig] Weave Scipy Inline C++
References: <20020915021712.48163.qmail@web20209.mail.yahoo.com>
Message-ID: <122c01c25c60$0e8e0740$6401a8c0@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > Boost doesn't provide any facilities for on-demand compilation of C++
code
> > from Python, if that's what you're getting at.
>
> Boost.Python is a high-throughput factory for Python "built-in" types.
Instead
> of using the few native types (list, tuple, dict) you can easily make
types
> that are tailored for specific needs.
>
> I am using Boost.Python in combination with SCons, which is much more
mature
> than the version number suggests. SCons is suitable as a "compilation on
> demand" tool.
>
> I am wondering how much of a run-time difference it can make if some
trivial
> pieces of compiled code working on objects through the (slow b/o dynamic
> typing) Python API are embedded in Python. If speed is a premium you can
gain
> much more if the C++ code operates on native C++ types, without the
overhead of
> the Python API for accessing data items. This is precisely what
Boost.Python
> gives you. Typically, I cross the language boundary only once to do an
> "expensive", non trivial operation in pure C++, and the result is a
wrapped C++
> object that can conveniently be inspected from Python.
>
> Does it make sense to put Weave and Boost.Python together? Let me try an
> analogy: if you choose Weave you are choosing a bicycle, and if you
choose
> Boost.Python you are choosing a car. Obviously the world needs both
bicycles
> and cars, but would you use a car as a building block for a bicycle?


Ralf, let me stop you before you piss some weave people off ;-). Whether
you intend it or not, this sounds like a potshot against weave.

IIUC, Weave can be used for embedding nontrivial C++ code, if you're
willing to stick it all inside one function body. Furthermore, tools like
weave.blitz() can make an enormous difference by compiling an entire C++
expression template corresponding to an arbitrarily complicated Python
expression. Surely that's nontrivial. It's definitely *cool*.

Though I love bicycles and often hate cars, most people don't see it that
way: they think of the former as less powerful and less robust. What you've
written could easily sound as though it's trivializing weave. I think weave
offers enormous power to the person who's programming mostly in Python.

Actually, it might not be a bad idea to think about merging them, if you
consider weave.blitz. Blitz++ was a pioneering effort in metaprogramming.
Boost.Python is a next-generation metaprogramming framework. There are
definitely some interesting possibilities here.

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





From rwgk at yahoo.com  Sun Sep 15 04:58:46 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 14 Sep 2002 19:58:46 -0700 (PDT)
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <122c01c25c60$0e8e0740$6401a8c0@boostconsulting.com>
Message-ID: <20020915025846.81232.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Ralf, let me stop you before you piss some weave people off ;-). Whether
> you intend it or not, this sounds like a potshot against weave.

OK, OK, I retract my analogy. Thanks for your posting!
Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From eric at enthought.com  Sun Sep 15 07:00:48 2002
From: eric at enthought.com (eric jones)
Date: Sun, 15 Sep 2002 00:00:48 -0500
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <11a901c25c45$a0f7ac00$6401a8c0@boostconsulting.com>
Message-ID: <000101c25c74$dc213240$777ba8c0@ericlaptop>

> > Hey Mark,
> >
> > > http://www.scipy.org/site_content/weave
> > >
> > > Can Boost do anything like this?  These folks are planning to use
SCXX
> > > while I am trying to get them to use Boost Python for C++
interfacing.
> > > They keep talking about Pythonic C++ classes, but I think that
> > > limiting inline C++ to such classes will severely limit Weave.
> >
> > What is this "severe limitation"?  I just don't understand.  Do you
have
> > a use case to help me out here?
> >
> > We have a very light weight need -- making dicts, tuples, and lists
easy
> > to use in C++ so that inline C++ code looks as much like Python as
> > possible.  This is about 0.3% of boost's capabilities.
> 
> I agreed with that at first, but on second thought, well, maybe not.
The
> capability draws on Boost.Python's core C++<=>Python conversion
mechanism,
> which accounts for most of the hard stuff in the library.
> 
> > On the other
> > hand, it uses about 95% of SCXX capabilities which means it is a
good
> > fit.  SCXX is 900 lines of code and easy to port anywhere.
> 
> If that's true, I doubt it's accomplishing the job as well as
Boost.Python
> does. Note that you never have to explicitly convert C++ objects to
Python
> when they are interacting with a Python object:
> 
>   object f(boost::python::object x)
>   {
>     x[1] = "hello";
>     return x(1,2,3,4,5,6,x); // __call__
>     ...

This is definitely visually cleaner, and I like it better.  Maybe a few
overloads in SCXX would make 

	x[1] = "hello";

work though for ints, floats, strings, etc.  I'll look at this and
report back...  Yep, worked fine.

Also, I understand the first line, but not what the second is doing.  Is
x like a UserList that has a __call__ method defined?

Note also that boost has more work to do in this case than weave does.
Boost::python::object can be pretty much anything I'm guessing.  When we
get to the 'x[1] = "hello";' line in weave, the code is explicitly
compiled again each time for a list or a tuple or a dict.  The following
happens at the command line:

>>> a = [1]
>>> weave.inline('a[0] = "hello";',['a'])
<compile a function that takes 'a' as a list>
>>> a[0]
"hello"
>>> a = {}
>>> weave.inline('a[0] = "hello";',['a'])
<compile a function that takes 'a' as a dict>

So I'm guessing the cleverness you probably had to go through to get
things working in C++ is handled by the dynamic typing mechanism in
weave. 

> 
> not
> 
>     x[Py::Int(1)] = Py::Str("hello");
>     // ??? what does __call__ look like?

Currently I just use the Python API for calling functions -- although
SCXX does have a callable class that could be used.  Also, nothing
special is done to convert instances that flow from Python into C++
unless a special converter has been written for them (such as for
wxPython objects).  Things weave doesn't explicitly know about are left
as PyObject* which can be manipulated in C code.

> 
> or whatever. Getting this code to work everywhere was one of the
harder
> porting jobs I've ever faced. Compilers seem to have lots of bugs in
the
> areas I was exercising.

The porting comment scares me.  Is it still ticklish? C++ bugs pop in
areas where they shouldn't -- even in the same compiler but on separate
platform.  There is currently some very silly code in weave explicitly
to work around exception handling bugs on Mandrake with gcc.  Since
spending a couple of days on this single issue, I've tried to avoid
anything potentially fragile (hence the move to SCXX).  CXX compile
issues also pushed me that direction.  The compilers I really care about
are gcc 2.95.x (mingw and linux), gcc 3.x, MSVC, MIPSPro, SunCC, DEC,
and xlc.  How is boost doing on this set? Weave isn't tested all these
places yet, but needs to run on all of them eventually (and shouldn't
have a problem now).
 
There is some other compiler intensive stuff in weave, but its use is
optional.  I include alternate converters for use blitz++ converters for
Numeric arrays because they also make code cleaner and are used in the
blitz() routine for automatically converting Numeric expressions to C++.
Up to now, this stuff has just worked with gcc, and I've been satisfied
to leave it at that.
  
> 
> However, you may still be right that it's not an appropriate solution
for
> weave.

I think boost would work fine -- maybe even better.  I really like that
boost project is active -- SCXX and CXX aren't very.  The beauty of SCXX
is it takes about 20 minutes to understand its entire code base.  The
worries I have with boost are:

1) How much of boost do I have to carry around for the simple
functionality I mentioned.
2) How persnickety is compiling the code on new platforms?
3) Would people have to understand much of boost to use this
functionality?
4) How ugly are the error reports from the compiler when code is
malformed?  Blitz++ reports are incomprehensible to anyone except
template gurus.
5) How steep is my learning curve on the code? (I know, only I can
answer that by looking at it for a while which I haven't yet.)

Note that I'm really looking for the prettiest and fastest solution
*with the least possible headaches*.  For weave, least headaches trumps
pretty and fast in a major way.  I've even considered moving weave back
to generating pure C code to make sure it works everywhere and leaving
the user to wrestle with refcounts and the Python API.  I think C++ is
getting far enough along though that this shouldn't be necessary (and
allows the "pretty").  Note though, that I was extremely disappointed
with CXX's speed when manipulating lists, etc.  It was *much* slower
than calling the raw Python API.  For computationally intense stuff on
lists, etc., you had to revert to API calls.  I haven't benchmarked SCXX
yet, but I'm betting the story is the same.  Most things I care about
are in Numeric arrays, but that isn't true for everyone else.

One other thought is that once we understand each others technologies
better, we may see other places where synergy is beneficial.

> 
> > If you need the other 99.7% of boost's capabilities, then you
probably
> > need to be using boost instead of weave anyhow.  They serve
different
> > purposes.  Weave is generally suited for light weight wrapping and
> > speeding up computational kernels with minimum hassle -- especially
in
> > numeric codes where Numeric isn't fast enough.
> >
> > Oh, and I'm happy to except patches that allow for boost type
converters
				 ^^^^^^ err... accept :-|

> > in weave (they should, after all, be easy to write).  Then you can
use
> > boost instead of SCXX.
> 
> What did you have in mind?

The code for a new type converter class that handles translating Python
code to C++ is rather trivial after the latest factoring of weave.  Here
is an example of a weave expression and the underlying C++ code that is
generated on the fly:

#python
>>> a = {}
>>> weave.inline('a["hello"] = 1;',['a'])

# underlying ext func
static PyObject* compiled_func(PyObject*self, PyObject* args)
{
    PyObject *return_val = NULL;
    int exception_occured = 0;
    PyObject *py__locals = NULL;
    PyObject *py__globals = NULL;
    PyObject *py_a;
    py_a = NULL;
    
 
if(!PyArg_ParseTuple(args,"OO:compiled_func",&py__locals,&py__globals))
        return NULL;
    try                              
    {                                
        PyObject* raw_locals = py_to_raw_dict(py__locals,"_locals");
        PyObject* raw_globals = py_to_raw_dict(py__globals,"_globals");
        /* argument conversion code */     
        py_a = get_variable("a",raw_locals,raw_globals);
        PWODict a = convert_to_dict(py_a,"a");
        /* inline code */                   
        a["hello"] = 1;        
    }                                       
    catch(...)                       
    {                                
        return_val =  NULL;    
        exception_occured = 1;       
    }                                
    /* cleanup code */                   
    if(!return_val && !exception_occured)
    {                                  
        Py_INCREF(Py_None);              
        return_val = Py_None;            
    }                                  
    return return_val;           
}                                

So the line that has to change is:

        PWODict a = convert_to_dict(py_a,"a");

and the convert_to_dict function -- but it is automatically generated by
the converter class (although you could customize it if needed).

And here is the pertinent code out of weave/c_spec.py
#-----------------------------------------------------------------------
----
#
# List, Tuple, and Dict converters.
#
# Based on SCXX by Gordon McMillan
#-----------------------------------------------------------------------
----
import os, c_spec # yes, I import myself to find out my __file__
location.
local_dir,junk = os.path.split(os.path.abspath(c_spec.__file__))   
scxx_dir = os.path.join(local_dir,'scxx')

class scxx_converter(common_base_converter):
    def init_info(self):
        common_base_converter.init_info(self)
        self.headers = ['"scxx/PWOBase.h"','"scxx/PWOSequence.h"',
                        '"scxx/PWOCallable.h"','"scxx/PWOMapping.h"',
                        '"scxx/PWOSequence.h"','"scxx/PWOMSequence.h"',
                        '"scxx/PWONumber.h"','<iostream>']
        self.include_dirs = [local_dir,scxx_dir]
        self.sources = [os.path.join(scxx_dir,'PWOImp.cpp'),]

class list_converter(scxx_converter):
    def init_info(self):
        scxx_converter.init_info(self)
        self.type_name = 'list'
        self.check_func = 'PyList_Check'    
        self.c_type = 'PWOList'
        self.to_c_return = 'PWOList(py_obj)'
        self.matching_types = [ListType]
        # ref counting handled by PWOList
        self.use_ref_count = 0

I think the only things that need changing to boost types are the header
list, the source file list, and self.c_type and self.to_c_return for a
first cut.

Hmmm.  Guess I'll show the template that these values fill in:

py_to_c_template = \
"""
class %(type_name)s_handler
{
public:    
    %(c_type)s convert_to_%(type_name)s(PyObject* py_obj, const char*
name)
    {
        %(inc_ref_count)s
        if (!py_obj || !%(check_func)s(py_obj))
            handle_conversion_error(py_obj,"%(type_name)s", name);    
        return %(to_c_return)s;
    }
    
};

%(type_name)s_handler x__%(type_name)s_handler =
%(type_name)s_handler();
#define convert_to_%(type_name)s(py_obj,name) \\
        x__%(type_name)s_handler.convert_to_%(type_name)s(py_obj,name)
"""

The class and #define stuff is the silliness required for Mandrake --
really only the convert_to_xxx function is needed.

Regards,
eric




From eric at enthought.com  Sun Sep 15 08:24:17 2002
From: eric at enthought.com (eric jones)
Date: Sun, 15 Sep 2002 01:24:17 -0500
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <20020915021712.48163.qmail@web20209.mail.yahoo.com>
Message-ID: <000201c25c80$85527c60$777ba8c0@ericlaptop>

> --- David Abrahams <dave at boost-consulting.com> wrote:
> > Boost doesn't provide any facilities for on-demand compilation of
C++
> > code from Python, if that's what you're getting at.
> 
> Boost.Python is a high-throughput factory for Python "built-in" types.
> Instead of using the few native types (list, tuple, dict) you can
easily 
> make types that are tailored for specific needs.

I think there is a key difference that needs to be understood here.  You
may understand this already, but it will help in the overall discussion.


Weave's current incarnation is roughly divided into four parts:

0. Fancy translation of Python->C/C++ code in blitz() or accelerate()
1. Extension function and module code generation for C/C++ snippets
2. On demand compilation machinery.
3. A "Catalog" that keeps track of extension functions and handles
dynamic typing issues.

(0) is not used by inline() which is the most heavily used part of weave
currently.  (0) is the really hard part and is getting attention from
Pat Miller at LLNL.  Also, I'd like to look at rolling some of Pyrex in
for this sort of thing.

The semi-overlapping portions of weave and boost are in (1), but they
definitely have different purposes.  Boost wraps existing C++ code and
exposes the classes as Python types.  Weave allows you to inline C/C++
in Python with the variables in Python automatically converted to
meaningful C++ types (when possible).  Based on this the type mapping
process for weave is to map Python types/classes into C++ types/classes.
This is the opposite of what boost or SWIG which map C/C++ code types to
Python types.  Most of the machinery in boost is explicitly for this
purpose.  Weave *might* be augmented to handling the task of wrapping an
existing C++ class to be exposed as a Python type/class, but it would be
some serious work (as yall know) and the task is already well handled by
boost and SWIG.  So isn't the niche it is trying to fill.

So, to be more explicit.  You would never wrap wxWindows with weave.
However, since weave is wxPython aware (on windows anyway), you can
inline  snippets of C/C++ code that manipulate wxWindows objects passed
from Python into your C/C++ snippet.  For example, we needed a faster
method of drawing Numeric arrays to the screen on windows.  If you don't
want to go in and rebuild all of wxPython, so weave is an option.  The
following does it at about 10 times the speed of the standard wxPython
method:

def polyline(dc,line):
    shp = line.shape
    assert(len(shp)==2 and shp[1] == 2)
    if (line.typecode() != Int or not line.iscontiguous()):
        line = line.astype(Int)
    
    polyline_code = """
                    HDC hdc = (HDC) dc->GetHDC();                    
                    Polyline(hdc,(POINT*)line,Nline[0]);
                    """
    # call the weave version of the function.
    weave.inline(polyline_code,['dc','line'])

This sort of thing and, writing computational kernels, is where weave
excels.  The user doesn't have to know much about Python's API to get
this to work.

> I am using Boost.Python in combination with SCons, which is much more
> mature than the version number suggests. SCons is suitable as a 
> "compilation on demand" tool.

This is part (2) of what weave does.  We currently use distutils, and it
works fine.  Weave actually does very little work here... Well, it does
some work with managing what extra files etc. need to be compiled/linked
to support special types such as wxPython, but distutils does the actual
compiling.   Hopefully distutils will get
re-implemented/refactored/reworked with SCons as the underpinnings at
some point.  

> I am wondering how much of a run-time difference it can make if some
> trivial
> pieces of compiled code working on objects through the (slow b/o
dynamic
> typing) Python API are embedded in Python. 

Not much for stuff that has to go through the API -- maybe a factor of
2-4 if you're really lucky.  Where you win is when you know the C/C++
format of a Python object.  Numeric arrays are a key example where one
or two orders of magnitude speed up are common.

> If speed is a premium you can
> gain
> much more if the C++ code operates on native C++ types, without the
> overhead of
> the Python API for accessing data items. This is precisely what
> Boost.Python
> gives you. Typically, I cross the language boundary only once to do an
> "expensive", non trivial operation in pure C++, and the result is a
> wrapped C++
> object that can conveniently be inspected from Python.

The same is true in weave if it is aware of your type.  Here is how you
might use it.  Say create a class called Particle in C++.  Further, you
have a C++ container called Vector<Particle> or something like that.
Boost is used to wrap this and expose it Python.  You make the extension
module and distribute it to your users.  Now, a user comes along and
needs to calculate a weighted centroid of a group of particles, but you
didn't define that function.  Their options are to learn how to
recompile your module (perhaps daunting), or, if you send along weave
aware type converters (simple to make), the could do something like the
following:

def weighted_centroid(particles):
    centroid = zeros(3,Float32) # Numeric array
    code = """
           float sum = 0;
           for(int i=0; i < particles.length(); i++)
           {
               Particle p = particles[i];
               float w = p.weight;
               sum += w; 
               centroid[0] = w * p.x;
               centroid[1] = w * p.y;
               centroid[2] = w * p.z;
           }
           centroid[0] /= sum; centroid[1] /= sum; centroid[2] /= sum;
           """
    weave.inline(code,['particles','centroid'])
    return centroid

<hope I got the code right, but you get the idea>

Now the end user can extend your boost library without needing to have
or know how to use boost and without fear of breaking the library .
After prototyping the function, they might send it back to you for
incorporation in the main library and they can get rid of weave snippet,
but while they are waiting they have something that works and runs at
the speed of C -- the same speed as anything else in your library.  

Hopefully this shows that boost and weave serve different but related
purposes and can work together.
     
> 
> Does it make sense to put Weave and Boost.Python together? Let me try
an
> analogy: if you choose Weave you are choosing a bicycle, and if you
choose
> Boost.Python you are choosing a car. Obviously the world needs both
> bicycles
> and cars, but would you use a car as a building block for a bicycle?

<David alludes to potential offense caused by analogy>

No offense taken.

I asked a similar question on this list a year or so ago when weave was
released.  This is a much livelier discussion than that one was.

As I said earlier, there are some areas where the two tools overlap, but
there are many regions where they do not.  I'm not sure merging them (at
least at this point) buys a whole lot.  The code re-use would be
minimal.

On the other hand, the synergy might be really nice.  I think boost is
probably about 80-90% of the way to its goal (is this correct?).  Weave
also does (1)-(3) fairly well in the list above.  However, there is a
*huge* amount of work that can happen in (0), and its potential is
exciting much like Pyrex and psyco are exciting.  (0) is more compiler
stuff.  I'm not sure how boost fits, but it may -- I haven't spent
enough time with boost yet to know.

I guess the other thing that would be really nice is a boost_converter
base class in weave that others who want to expose there boost wrapped
classes to weave can sub-class.  I already have this for SWIG (at least
the old SWIG).  Again, doing so is likely to be trivial.

Regards,
eric





From eric at enthought.com  Sun Sep 15 08:56:22 2002
From: eric at enthought.com (eric jones)
Date: Sun, 15 Sep 2002 01:56:22 -0500
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <122c01c25c60$0e8e0740$6401a8c0@boostconsulting.com>
Message-ID: <000301c25c85$00c9b4e0$777ba8c0@ericlaptop>

> Ralf, let me stop you before you piss some weave people off ;-).
Whether
> you intend it or not, this sounds like a potshot against weave.
> 
> IIUC, Weave can be used for embedding nontrivial C++ code, if you're
> willing to stick it all inside one function body. Furthermore, tools
like
> weave.blitz() can make an enormous difference by compiling an entire
C++
> expression template corresponding to an arbitrarily complicated Python
                                          ^^^^^^^^^^^^^^^^^^^^^^^  
> expression. Surely that's nontrivial. It's definitely *cool*.

Blitz() only handles Numeric expressions, so it isn't quite that cool.
:-)  Still, it is useful and provides a starting point for handling
arbitrarily complicated code.  Pat Miller is working on that.  Hopefully
we'll have some of his really neat (and kinda sick...) work in weave
within a month or so.  It is tailored to Numeric and is akin to writing
a compiler for Python.  The speed-up on computational stuff is huge and
the calling overhead is very small.  Also, using some of Pyrex's
machinery into weave might get us pretty close to your statement.

> 
> Though I love bicycles and often hate cars, most people don't see it
that
> way: they think of the former as less powerful and less robust. What
> you've
> written could easily sound as though it's trivializing weave. I think
> weave
> offers enormous power to the person who's programming mostly in
Python.
> 
> Actually, it might not be a bad idea to think about merging them, if
you
> consider weave.blitz. Blitz++ was a pioneering effort in
metaprogramming.
> Boost.Python is a next-generation metaprogramming framework. There are
> definitely some interesting possibilities here.

I look forward to the discussion on this.

eric





From dave at boost-consulting.com  Sun Sep 15 16:57:49 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 15 Sep 2002 10:57:49 -0400
Subject: [C++-sig] Weave Scipy Inline C++
References: <000101c25c74$dc213240$777ba8c0@ericlaptop>
Message-ID: <003101c25cc8$5e8f7630$6701a8c0@boostconsulting.com>

From: "eric jones" <eric at enthought.com>


> >   object f(boost::python::object x)
> >   {
> >     x[1] = "hello";
> >     return x(1,2,3,4,5,6,x); // __call__
> >     ...
>
> This is definitely visually cleaner, and I like it better.  Maybe a few
> overloads in SCXX would make
>
> x[1] = "hello";
>
> work though for ints, floats, strings, etc.  I'll look at this and
> report back...  Yep, worked fine.
>
> Also, I understand the first line, but not what the second is doing.  Is
> x like a UserList that has a __call__ method defined?

Hypothetically, yes.

> Note also that boost has more work to do in this case than weave does.
> Boost::python::object can be pretty much anything I'm guessing.  When we
> get to the 'x[1] = "hello";' line in weave, the code is explicitly
> compiled again each time for a list or a tuple or a dict.

That sounds like a lot more work than what Boost.Python is doing!

> The following
> happens at the command line:
>
> >>> a = [1]
> >>> weave.inline('a[0] = "hello";',['a'])
> <compile a function that takes 'a' as a list>
> >>> a[0]
> "hello"
> >>> a = {}
> >>> weave.inline('a[0] = "hello";',['a'])
> <compile a function that takes 'a' as a dict>
>
> So I'm guessing the cleverness you probably had to go through to get
> things working in C++ is handled by the dynamic typing mechanism in
> weave.

Wow, that could result in a huge amount of bloat. What if you /want/ some
runtime polymorphism in your C++ code?
Furthermore, without special knowledge of the internals of every type that
might be passed, you can't generate code that's any more-optimized for T1
than for T2:

    >>> class T1(dict): pass
    >>> class T2(dict): pass
    >>> a = T1()
    >>> weave.inline('a[0] = "hello";', ['a'])
    >>> a = T2()
    >>> weave.inline('a[0] = "hello";', ['a'])

We can generate any number of distinct types for which x[0] = "hello" is a
valid expression...

> >
> > not
> >
> >     x[Py::Int(1)] = Py::Str("hello");
> >     // ??? what does __call__ look like?
>
> Currently I just use the Python API for calling functions -- although
> SCXX does have a callable class that could be used.  Also, nothing
> special is done to convert instances that flow from Python into C++
> unless a special converter has been written for them (such as for
> wxPython objects).  Things weave doesn't explicitly know about are left
> as PyObject* which can be manipulated in C code.

Boost.Python is designed with the idea in mind that users never touch a
PyObject*.

> > or whatever. Getting this code to work everywhere was one of the
> harder
> > porting jobs I've ever faced. Compilers seem to have lots of bugs in
> the
> > areas I was exercising.
>
> The porting comment scares me.  Is it still ticklish?

Not too ticklish with modern compilers (though one recent release had a
codegen bug this stimulated). The big problem is that there are lots of old
compilers out there that people still use. VC6, for example.

> C++ bugs pop in
> areas where they shouldn't -- even in the same compiler but on separate
> platform.  There is currently some very silly code in weave explicitly
> to work around exception handling bugs on Mandrake with gcc.  Since
> spending a couple of days on this single issue, I've tried to avoid
> anything potentially fragile (hence the move to SCXX).  CXX compile
> issues also pushed me that direction.  The compilers I really care about
> are gcc 2.95.x (mingw and linux), gcc 3.x, MSVC, MIPSPro, SunCC, DEC,
> and xlc.  How is boost doing on this set?

Fine on gcc 2.95.x, 3.1, 3.2, msv6/7, MIPSPro, Dec CXX 6.5 and a whole
bunch of others.
I haven't tested xlc recently. I anticipate some issues with SunCC.

> Weave isn't tested all these
> places yet, but needs to run on all of them eventually (and shouldn't
> have a problem now).

No conforming code "should have a problem". But you know how in theory
there's no difference between theory and practice...

> > However, you may still be right that it's not an appropriate solution
> for
> > weave.
>
> I think boost would work fine -- maybe even better.  I really like that
> boost project is active -- SCXX and CXX aren't very.  The beauty of SCXX
> is it takes about 20 minutes to understand its entire code base.  The
> worries I have with boost are:
>
> 1) How much of boost do I have to carry around for the simple
> functionality I mentioned.

Boost.Python depends on quite a few of the other boost libraries:

    type_traits
    bind
    function
    mpl - currently in prerelease
    smart_ptr

possibly a few others. These are all in header files.

> 2) How persnickety is compiling the code on new platforms?

Fairly persnickety, unless you're a C++ generic/metaprogramming expert.

> 3) Would people have to understand much of boost to use this
> functionality?

They wouldn't have to understand much of Boost as a whole. They'd only need
to understand the components of Boost.Python that they're using. There is
also a template called extract<> which would be useful to know about.

> 4) How ugly are the error reports from the compiler when code is
> malformed?  Blitz++ reports are incomprehensible to anyone except
> template gurus.

You get a long instantiation backtrace as usual. However, we've applied
some tricks which cause error messages to contain a plain english
description of what the user did wrong in many cases.

> 5) How steep is my learning curve on the code? (I know, only I can
> answer that by looking at it for a while which I haven't yet.)

I have no idea how to answer that.

> Note that I'm really looking for the prettiest and fastest solution
> *with the least possible headaches*.  For weave, least headaches trumps
> pretty and fast in a major way.

Then use the Python "C" API.

> I've even considered moving weave back
> to generating pure C code to make sure it works everywhere and leaving
> the user to wrestle with refcounts and the Python API.  I think C++ is
> getting far enough along though that this shouldn't be necessary (and
> allows the "pretty").  Note though, that I was extremely disappointed
> with CXX's speed when manipulating lists, etc.  It was *much* slower
> than calling the raw Python API.  For computationally intense stuff on
> lists, etc., you had to revert to API calls.  I haven't benchmarked SCXX
> yet, but I'm betting the story is the same.  Most things I care about
> are in Numeric arrays, but that isn't true for everyone else.

Boost.Python's object wrappers are not generally designed for maximum
speed. For example, the list class knows that it might hold a class derived
from list, so it does PyList_CheckExact() before calling any PyList_
functions directly. If it's been subclassed it goes through the general
Python API. Also, none of the operators such as [] have been set up to use
the PyList_xxx functions in this way. It could be done; it's just a lot of
work.

> One other thought is that once we understand each others technologies
> better, we may see other places where synergy is beneficial.

Hopefully, yes.

> >
> > > If you need the other 99.7% of boost's capabilities, then you
> probably
> > > need to be using boost instead of weave anyhow.  They serve
> different
> > > purposes.  Weave is generally suited for light weight wrapping and
> > > speeding up computational kernels with minimum hassle -- especially
> in
> > > numeric codes where Numeric isn't fast enough.
> > >
> > > Oh, and I'm happy to except patches that allow for boost type
> converters
> ^^^^^^ err... accept :-|
>
> > > in weave (they should, after all, be easy to write).  Then you can
> use
> > > boost instead of SCXX.
> >
> > What did you have in mind?
>
> The code for a new type converter class that handles translating Python
> code to C++ is rather trivial after the latest factoring of weave.  Here
> is an example of a weave expression and the underlying C++ code that is
> generated on the fly:
>
> #python
> >>> a = {}
> >>> weave.inline('a["hello"] = 1;',['a'])
>
> # underlying ext func
> static PyObject* compiled_func(PyObject*self, PyObject* args)
> {
>     PyObject *return_val = NULL;
>     int exception_occured = 0;
>     PyObject *py__locals = NULL;
>     PyObject *py__globals = NULL;
>     PyObject *py_a;
>     py_a = NULL;
>
>
> if(!PyArg_ParseTuple(args,"OO:compiled_func",&py__locals,&py__globals))
>         return NULL;

Isn't there a way to check for dict/int args right here?^^^^^^^^^^^^^^^^

>     try
>     {
>         PyObject* raw_locals = py_to_raw_dict(py__locals,"_locals");
>         PyObject* raw_globals = py_to_raw_dict(py__globals,"_globals");
>         /* argument conversion code */
>         py_a = get_variable("a",raw_locals,raw_globals);
>         PWODict a = convert_to_dict(py_a,"a");
>         /* inline code */
>         a["hello"] = 1;
>     }
>     catch(...)
>     {
>         return_val =  NULL;
>         exception_occured = 1;
>     }
>     /* cleanup code */
>     if(!return_val && !exception_occured)
>     {
>         Py_INCREF(Py_None);
>         return_val = Py_None;
>     }
>     return return_val;
> }
>
> So the line that has to change is:
>
>         PWODict a = convert_to_dict(py_a,"a");
>
> and the convert_to_dict function -- but it is automatically generated by
> the converter class (although you could customize it if needed).

That would look something like this in Boost.Python:

    handle<> py_a = borrowed(get_variable("a", raw_locals, raw_globals));
    dict x = extract<dict>(object(py_a));

You could generate slightly more-efficient code using some of the
implementation details of Boost.Python, but I'd rather not expose those to
anyone.


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






From dave at boost-consulting.com  Sun Sep 15 17:12:06 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 15 Sep 2002 11:12:06 -0400
Subject: [C++-sig] Weave Scipy Inline C++
References: <000201c25c80$85527c60$777ba8c0@ericlaptop>
Message-ID: <003b01c25cca$78cb8c30$6701a8c0@boostconsulting.com>

From: "eric jones" <eric at enthought.com>

> Weave's current incarnation is roughly divided into four parts:
>
> 0. Fancy translation of Python->C/C++ code in blitz() or accelerate()
> 1. Extension function and module code generation for C/C++ snippets
> 2. On demand compilation machinery.
> 3. A "Catalog" that keeps track of extension functions and handles
> dynamic typing issues.
>
> (0) is not used by inline() which is the most heavily used part of weave
> currently.  (0) is the really hard part and is getting attention from
> Pat Miller at LLNL.  Also, I'd like to look at rolling some of Pyrex in
> for this sort of thing.
>
> The semi-overlapping portions of weave and boost are in (1), but they
> definitely have different purposes.  Boost wraps existing C++ code and
> exposes the classes as Python types.  Weave allows you to inline C/C++
> in Python with the variables in Python automatically converted to
> meaningful C++ types (when possible).  Based on this the type mapping
> process for weave is to map Python types/classes into C++ types/classes.
> This is the opposite of what boost or SWIG which map C/C++ code types to
> Python types.

I don't understand what you mean here. Boost maps bidirectionally between
Python and C++ AFAICT.

> Most of the machinery in boost is explicitly for this
> purpose.  Weave *might* be augmented to handling the task of wrapping an
> existing C++ class to be exposed as a Python type/class, but it would be
> some serious work (as yall know) and the task is already well handled by
> boost and SWIG.  So isn't the niche it is trying to fill.
>
> So, to be more explicit.  You would never wrap wxWindows with weave.
> However, since weave is wxPython aware (on windows anyway), you can
> inline  snippets of C/C++ code that manipulate wxWindows objects passed
> from Python into your C/C++ snippet.  For example, we needed a faster
> method of drawing Numeric arrays to the screen on windows.  If you don't
> want to go in and rebuild all of wxPython, so weave is an option.

I don't understand why you are saying that to add functionality which use
components from a library (e.g. wxPython) you need to modify the library.
If weave can generate a piece of non-intrusive C++ which uses the library
components, the user can do that, too.

> This sort of thing and, writing computational kernels, is where weave
> excels.  The user doesn't have to know much about Python's API to get
> this to work.

That, I think, is the key advantage. You could do the same thing with
Boost.Python /and/ get a useful C++ interface for the same functionality
out of it. However, if you don't care about that, weave might end up being
easier.

> As I said earlier, there are some areas where the two tools overlap, but
> there are many regions where they do not.  I'm not sure merging them (at
> least at this point) buys a whole lot.  The code re-use would be
> minimal.
>
> On the other hand, the synergy might be really nice.  I think boost is
> probably about 80-90% of the way to its goal (is this correct?).

First release is in roughly 3 weeks.

>  Weave
> also does (1)-(3) fairly well in the list above.  However, there is a
> *huge* amount of work that can happen in (0), and its potential is
> exciting much like Pyrex and psyco are exciting.  (0) is more compiler
> stuff.  I'm not sure how boost fits, but it may -- I haven't spent
> enough time with boost yet to know.

We're not trying to fill that niche.

> I guess the other thing that would be really nice is a boost_converter
> base class in weave that others who want to expose there boost wrapped
> classes to weave can sub-class.  I already have this for SWIG (at least
> the old SWIG).  Again, doing so is likely to be trivial.

Maybe. I have no idea what's involved on your end.


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






From lists at UltimateG.com  Sun Sep 15 21:48:44 2002
From: lists at UltimateG.com (Mark Evans)
Date: Sun, 15 Sep 2002 12:48:44 -0700
Subject: [C++-sig] Re: Weave Scipy Inline C++
Message-ID: <812438336.20020915124844@UltimateG.com>

David and Eric,

I have little to add in a technical sense, except

Compilers
  http://www.comeaucomputing.com/
  Comeau C++ can handle *very* advanced C++, and costs only $50.
  One of the best C++ compilers available.
  http://www.DigitalMars.com/
  Almost as good by a hair, FREE, but not quite Boost-capable yet;
  will be once Walter gets the namespace support up to
  the very latest STL standards (couple months?); can serve
  as a fast back-end for Comeau.  The virtue of DM is ultra
  high compilation speed and code optimization.

I am very glad to see this discussion taking place and thank you both.

Mark




From dave at boost-consulting.com  Sun Sep 15 22:47:25 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 15 Sep 2002 16:47:25 -0400
Subject: [C++-sig] Re: Weave Scipy Inline C++
References: <812438336.20020915124844@UltimateG.com>
Message-ID: <015401c25cf9$7e27e0f0$6701a8c0@boostconsulting.com>

From: "Mark Evans" <lists at UltimateG.com>


> David and Eric,
>
> I have little to add in a technical sense, except
>
> Compilers
>   http://www.comeaucomputing.com/
>   Comeau C++ can handle *very* advanced C++, and costs only $50.
>   One of the best C++ compilers available.

Thanks, I have it already, but Greg's installation instructions are such a
pain to deal with that I haven't had time to install it. Fortunately, the
tru64 CXX Ralf is testing with is using the same EDG front-end, so it
really doesn't matter if I set up Comeau here.

>   http://www.DigitalMars.com/
>   Almost as good by a hair, FREE, but not quite Boost-capable yet;
>   will be once Walter gets the namespace support up to
>   the very latest STL standards (couple months?); can serve
>   as a fast back-end for Comeau.  The virtue of DM is ultra
>   high compilation speed and code optimization.

Comeau doesn't need a fast back-end. It needs a fast front end ;-)
Anyway, I don't think I can invest in supporting a relatively unpopular
compiler which doesn't support namespaces well.
At least, not right now.


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





From eric at enthought.com  Mon Sep 16 02:52:02 2002
From: eric at enthought.com (eric jones)
Date: Sun, 15 Sep 2002 19:52:02 -0500
Subject: [C++-sig] Re: Weave Scipy Inline C++
In-Reply-To: <812438336.20020915124844@UltimateG.com>
Message-ID: <000001c25d1b$459c5a50$777ba8c0@ericlaptop>

> David and Eric,
> 
> I have little to add in a technical sense, except
> 
> Compilers
>   http://www.comeaucomputing.com/
>   Comeau C++ can handle *very* advanced C++, and costs only $50.
>   One of the best C++ compilers available.
>   http://www.DigitalMars.com/
>   Almost as good by a hair, FREE, but not quite Boost-capable yet;
>   will be once Walter gets the namespace support up to
>   the very latest STL standards (couple months?); can serve
>   as a fast back-end for Comeau.  The virtue of DM is ultra
>   high compilation speed and code optimization.

Do these guys support something that gcc doesn't?  

eric 






From dave at boost-consulting.com  Mon Sep 16 02:55:04 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 15 Sep 2002 20:55:04 -0400
Subject: [C++-sig] Re: Weave Scipy Inline C++
References: <000001c25d1b$459c5a50$777ba8c0@ericlaptop>
Message-ID: <025801c25d1c$2eb07960$6701a8c0@boostconsulting.com>

From: "eric jones" <eric at enthought.com>
> > David and Eric,
> >
> > I have little to add in a technical sense, except
> >
> > Compilers
> >   http://www.comeaucomputing.com/
> >   Comeau C++ can handle *very* advanced C++, and costs only $50.
> >   One of the best C++ compilers available.
> >   http://www.DigitalMars.com/
> >   Almost as good by a hair, FREE, but not quite Boost-capable yet;
> >   will be once Walter gets the namespace support up to
> >   the very latest STL standards (couple months?); can serve
> >   as a fast back-end for Comeau.  The virtue of DM is ultra
> >   high compilation speed and code optimization.
>
> Do these guys support something that gcc doesn't?

Comeau does: 2-phase name lookup, export (not that I care), and it's
generally less buggy.

DigitalMars has only just acquired many of the template features neccessary
to be able to call it a C++ compiler. I would be *very* surprised if it was
anywhere nearly as conformant as Comeau *or* GCC.


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





From dave at boost-consulting.com  Mon Sep 16 06:39:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Sep 2002 00:39:28 -0400
Subject: [C++-sig] Boost.Python v2: ** important **
Message-ID: <031701c25d3b$0bf8bee0$6701a8c0@boostconsulting.com>

* Boost.Python v2 and MPL have both been moved completely to the main trunk
of Boost CVS. To get a CVS snapshot that reflects the current state of the
world:

    cd <boost-root-directory>
    cvs update -P -d -A .

If you've been using Boost.Python v2, you've been using the mpl-development
branch of boost/mpl. That will no longer work. If you don't take the steps
above the next time you update you will get lots of errors and no happy
success with compilation ;-)

* Joel has just finished adding what I hope will be the final code-breaking
changes to Boost.Python v2 before its release early next month. These are
still on a branch in the CVS for the time being (just to give you time to
test your code with the current CVS state), but they will be merged
sometime on Tuesday.

Summary:

1. When specifying constructors, there is a new format:

     init<...args..., optional< ...args...> >("docstring")[call_policies()]

Of course any of args, optional, "docstring" and [call_policies()] may be
ommitted.

2. The def_init() function is going away. It is replaced by a def()
overload which accepts init<...>. Thus:

    // default constructor with docstring
    class_<Y>("Y", init<>("doc of Y init"))
        .def("get_state", &Y::get_state)
        .def(init<int, optional<char, std::string, double> >("doc of
init"))
        .def(init<X*>()[with_custodian_and_ward<1,2>()])
        ;

3. A similar interface applies to the default argument feature:

  X* foo(Y& y, char b = 'D', std::string c = "default", double d = 0.0);

  // Generate overloads for 1-4 parameters
  BOOST_PYTHON_FUNCTION_OVERLOADS(foo_overloads, foo, 1, 4)

    ...
    def("foo", foo, foo_overloads("about
foo")[return_internal_reference<>()])

-Dave

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







From rwgk at yahoo.com  Mon Sep 16 08:32:25 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 15 Sep 2002 23:32:25 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: ** important **
In-Reply-To: <031701c25d3b$0bf8bee0$6701a8c0@boostconsulting.com>
Message-ID: <20020916063225.7263.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> * Joel has just finished adding what I hope will be the final code-breaking
> changes to Boost.Python v2 before its release early next month. These are
> still on a branch in the CVS for the time being (just to give you time to
> test your code with the current CVS state), but they will be merged
> sometime on Tuesday.

What are these changes? Are they related to the points of your Summary?

> 1. When specifying constructors, there is a new format:
> 2. The def_init() function is going away. It is replaced by a def()
> 3. A similar interface applies to the default argument feature:

Thanks,
        Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



From eric at enthought.com  Mon Sep 16 12:29:02 2002
From: eric at enthought.com (eric jones)
Date: Mon, 16 Sep 2002 05:29:02 -0500
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <003b01c25cca$78cb8c30$6701a8c0@boostconsulting.com>
Message-ID: <000001c25d6b$e0ea98f0$777ba8c0@ericlaptop>

> From: "eric jones" <eric at enthought.com>
> 
> > Weave's current incarnation is roughly divided into four parts:
> >
> > 0. Fancy translation of Python->C/C++ code in blitz() or
accelerate()
> > 1. Extension function and module code generation for C/C++ snippets
> > 2. On demand compilation machinery.
> > 3. A "Catalog" that keeps track of extension functions and handles
> > dynamic typing issues.
> >
> > (0) is not used by inline() which is the most heavily used part of
weave
> > currently.  (0) is the really hard part and is getting attention
from
> > Pat Miller at LLNL.  Also, I'd like to look at rolling some of Pyrex
in
> > for this sort of thing.
> >
> > The semi-overlapping portions of weave and boost are in (1), but
they
> > definitely have different purposes.  Boost wraps existing C++ code
and
> > exposes the classes as Python types.  Weave allows you to inline
C/C++
> > in Python with the variables in Python automatically converted to
> > meaningful C++ types (when possible).  Based on this the type
mapping
> > process for weave is to map Python types/classes into C++
types/classes.
> > This is the opposite of what boost or SWIG which map C/C++ code
types to
> > Python types.
> 
> I don't understand what you mean here. Boost maps bidirectionally
between
> Python and C++ AFAICT.

Hmmm.  Perhaps it does (more on that in a second).  The point I'm making
is that weave has access to the Python version of the object and decides
on the fly what type of C++ type/class to instantiate based on the
Python type.  In boost, on the other hand, you have C++ classes and you
wrap and expose to Python.decide what things will look like in Python
based on what the class looked like in C++.

Maybe the following would be easy to do if weave used boost:
 
class foo:
    def __init__(self,x):
        self.x = x
    def inc(self):
        return x + 1

a = foo(2)
code = """
       int b = a.x;
       int c = a.inc();
       """
weave.inline(code,['a'])

This would be a mapping from Python into C++.  Weave doesn't currently
try to handle this automatically, by generating a wrapper C++ object,
but that sort of thing is in the future (with additional type
information taken from comments).  This is sorta Pyrex-ish.  My bet is
that boost might be the underpinnings of the code generator that builds
this code, but that weave would be responsible for the code generation.
  
> 
> > Most of the machinery in boost is explicitly for this
> > purpose.  Weave *might* be augmented to handling the task of
wrapping an
> > existing C++ class to be exposed as a Python type/class, but it
would be
> > some serious work (as yall know) and the task is already well
handled by
> > boost and SWIG.  So isn't the niche it is trying to fill.
> >
> > So, to be more explicit.  You would never wrap wxWindows with weave.
> > However, since weave is wxPython aware (on windows anyway), you can
> > inline  snippets of C/C++ code that manipulate wxWindows objects
passed
> > from Python into your C/C++ snippet.  For example, we needed a
faster
> > method of drawing Numeric arrays to the screen on windows.  If you
don't
> > want to go in and rebuild all of wxPython, so weave is an option.
> 
> I don't understand why you are saying that to add functionality which
use
> components from a library (e.g. wxPython) you need to modify the
library.
> If weave can generate a piece of non-intrusive C++ which uses the
library
> components, the user can do that, too.

You are right.  The point I should be making is that, while it is simple
for you guys, it is non-trivial for an end user to modify an existing or
generate a new extension module.  When a person needs to modify a few
functions or try a few things out, the idea of making an extension
module to do that is rarely an option.  With weave, and for supported
types and external libraries, the process is about as simple as it can
be made.
 
> 
> > This sort of thing and, writing computational kernels, is where
weave
> > excels.  The user doesn't have to know much about Python's API to
get
> > this to work.
> 
> That, I think, is the key advantage. You could do the same thing with
> Boost.Python /and/ get a useful C++ interface for the same
functionality
> out of it. However, if you don't care about that, weave might end up
being
> easier.
> 
> > As I said earlier, there are some areas where the two tools overlap,
but
> > there are many regions where they do not.  I'm not sure merging them
(at
> > least at this point) buys a whole lot.  The code re-use would be
> > minimal.
> >
> > On the other hand, the synergy might be really nice.  I think boost
is
> > probably about 80-90% of the way to its goal (is this correct?).
> 
> First release is in roughly 3 weeks.
> 
> >  Weave
> > also does (1)-(3) fairly well in the list above.  However, there is
a
> > *huge* amount of work that can happen in (0), and its potential is
> > exciting much like Pyrex and psyco are exciting.  (0) is more
compiler
> > stuff.  I'm not sure how boost fits, but it may -- I haven't spent
> > enough time with boost yet to know.
> 
> We're not trying to fill that niche.

I didn't think that was boost's purpose.
 
> 
> > I guess the other thing that would be really nice is a
boost_converter
> > base class in weave that others who want to expose there boost
wrapped
> > classes to weave can sub-class.  I already have this for SWIG (at
least
> > the old SWIG).  Again, doing so is likely to be trivial.
> 
> Maybe. I have no idea what's involved on your end.

I think just a specification of the files needed is about it, but I
haven't looked into it much.  I will soon.

Regards,
eric





From eric at enthought.com  Mon Sep 16 13:57:08 2002
From: eric at enthought.com (eric jones)
Date: Mon, 16 Sep 2002 06:57:08 -0500
Subject: [C++-sig] Weave Scipy Inline C++
In-Reply-To: <003101c25cc8$5e8f7630$6701a8c0@boostconsulting.com>
Message-ID: <000101c25d78$2f5df2a0$777ba8c0@ericlaptop>

> > >   object f(boost::python::object x)
> > >   {
> > >     x[1] = "hello";
> > >     return x(1,2,3,4,5,6,x); // __call__
> > >     ...
> >
> > This is definitely visually cleaner, and I like it better.  Maybe a
few
> > overloads in SCXX would make
> >
> > x[1] = "hello";
> >
> > work though for ints, floats, strings, etc.  I'll look at this and
> > report back...  Yep, worked fine.
> >
> > Also, I understand the first line, but not what the second is doing.
Is
> > x like a UserList that has a __call__ method defined?
> 
> Hypothetically, yes.
> 
> > Note also that boost has more work to do in this case than weave
does.
> > Boost::python::object can be pretty much anything I'm guessing.
When we
> > get to the 'x[1] = "hello";' line in weave, the code is explicitly
> > compiled again each time for a list or a tuple or a dict.
> 
> That sounds like a lot more work than what Boost.Python is doing!

But the work is at the Python level, not at the C++ level.  Python
determines the object types, generates the correct C++ code.  This means
that the C++ code can use simple constructs.

> 
> > The following
> > happens at the command line:
> >
> > >>> a = [1]
> > >>> weave.inline('a[0] = "hello";',['a'])
> > <compile a function that takes 'a' as a list>
> > >>> a[0]
> > "hello"
> > >>> a = {}
> > >>> weave.inline('a[0] = "hello";',['a'])
> > <compile a function that takes 'a' as a dict>
> >
> > So I'm guessing the cleverness you probably had to go through to get
> > things working in C++ is handled by the dynamic typing mechanism in
> > weave.
> 
> Wow, that could result in a huge amount of bloat.

The behavior is much like templates in C++ (vector<int> and
vector<float>) in C++ code. Right?  

Also, how would you propose handling dynamic typing for code that is
generated on the fly?  Everything is done at run time in weave.  Nothing
is compiled until the inline() call is made for the first time with a
given argument type.  

Also, if the code is the following:

a = zeros(1000000),Float64)
<fill in a with some values>
code = """ 
       double sum=0;
       For(int i=0;i<N;i++)
           sum += a[i];
       return_val = PyFloat_FromDouble(sum);
       """
N = shape(a)
sum = weave.inline(code,['a','N'])

I want the code generated to convert 'a' to a double* so the compiler
can generate optimized code for this case.  instead of trying using
polymorphism.

In practice, I've never noticed a problem with weave's approach to
dynamic typing.  If inline is used *a lot*, your program will certainly
grow, and on small machines, this could be a problem.  But, the dll/so
files are generally quite small (20-30 KB) for code that uses standard
types, so the biggest problem on memory limited machines is probably the
compilation process.

> What if you /want/ some runtime polymorphism in your C++ code?

As far as I know, nothing in weave precludes using polymorphism in
places you want to.  I'm not sure what the benefit is though on the data
conversion step, as you already know the data type of the object coming
in.  You might as well generate code explicitly for that type.

> Furthermore, without special knowledge of the internals of every type
that
> might be passed, you can't generate code that's any more-optimized for
T1
> than for T2:
> 
>     >>> class T1(dict): pass
>     >>> class T2(dict): pass
>     >>> a = T1()
>     >>> weave.inline('a[0] = "hello";', ['a'])
>     >>> a = T2()
>     >>> weave.inline('a[0] = "hello";', ['a'])

weave converts instances it doesn't know about to PyObject*.  So, to
work with these instances, you'd have to use the Python C API.  The
above code would not work.  And, I think it would take quite a bit more
than just using boost to get this code to work.  It is possible to
inspect Python objects on the fly and try and generate classes for them,
but it will be very tricky to get it right.  And, since Python objects
can change on the fly, correct and fast are probably mutually exclusive.
Every method call and attribute access would have to call back into
Python.  On the other hand, if the class is defined in C++, wrapped with
boost or SWIG, and weave is told about it, the code can be very fast.

> 
> We can generate any number of distinct types for which x[0] = "hello"
is a
> valid expression...
> 
> > >
> > > not
> > >
> > >     x[Py::Int(1)] = Py::Str("hello");
> > >     // ??? what does __call__ look like?
> >
> > Currently I just use the Python API for calling functions --
although
> > SCXX does have a callable class that could be used.  Also, nothing
> > special is done to convert instances that flow from Python into C++
> > unless a special converter has been written for them (such as for
> > wxPython objects).  Things weave doesn't explicitly know about are
left
> > as PyObject* which can be manipulated in C code.
> 
> Boost.Python is designed with the idea in mind that users never touch
a
> PyObject*.

Much of weave is too, but in places where it isn't able to figure out
types, instead of keeling over, it exposes the raw PyObject and lets the
user deal with it.  This seems a reasonable approach...

> 
> > > or whatever. Getting this code to work everywhere was one of the
> > harder
> > > porting jobs I've ever faced. Compilers seem to have lots of bugs
in
> > the
> > > areas I was exercising.
> >
> > The porting comment scares me.  Is it still ticklish?
> 
> Not too ticklish with modern compilers (though one recent release had
a
> codegen bug this stimulated). The big problem is that there are lots
of
> old
> compilers out there that people still use. VC6, for example.
> 
> > C++ bugs pop in
> > areas where they shouldn't -- even in the same compiler but on
separate
> > platform.  There is currently some very silly code in weave
explicitly
> > to work around exception handling bugs on Mandrake with gcc.  Since
> > spending a couple of days on this single issue, I've tried to avoid
> > anything potentially fragile (hence the move to SCXX).  CXX compile
> > issues also pushed me that direction.  The compilers I really care
about
> > are gcc 2.95.x (mingw and linux), gcc 3.x, MSVC, MIPSPro, SunCC,
DEC,
> > and xlc.  How is boost doing on this set?
> 
> Fine on gcc 2.95.x, 3.1, 3.2, msv6/7, MIPSPro, Dec CXX 6.5 and a whole
> bunch of others.
> I haven't tested xlc recently. I anticipate some issues with SunCC.
> 
> > Weave isn't tested all these
> > places yet, but needs to run on all of them eventually (and
shouldn't
> > have a problem now).
> 
> No conforming code "should have a problem". But you know how in theory
> there's no difference between theory and practice...

Right.  But limiting ourselves in the amount of fancy stuff we use
mitigates the problem.  The C++ tools that weave still uses in its basic
configuration are exceptions, std::string, and std::complex.  The rest
is dirt simple C++ code.  So if the listed items give a compiler
problems, weave probably won't work.  I think these are fairly minimal
requirements.

> 
> > > However, you may still be right that it's not an appropriate
solution
> > for
> > > weave.
> >
> > I think boost would work fine -- maybe even better.  I really like
that
> > boost project is active -- SCXX and CXX aren't very.  The beauty of
SCXX
> > is it takes about 20 minutes to understand its entire code base.
The
> > worries I have with boost are:
> >
> > 1) How much of boost do I have to carry around for the simple
> > functionality I mentioned.
> 
> Boost.Python depends on quite a few of the other boost libraries:
> 
>     type_traits
>     bind
>     function
>     mpl - currently in prerelease
>     smart_ptr
> 
> possibly a few others. These are all in header files.
> 
> > 2) How persnickety is compiling the code on new platforms?
> 
> Fairly persnickety, unless you're a C++ generic/metaprogramming
expert.
> 
> > 3) Would people have to understand much of boost to use this
> > functionality?
> 
> They wouldn't have to understand much of Boost as a whole. They'd only
> need
> to understand the components of Boost.Python that they're using. There
is
> also a template called extract<> which would be useful to know about.
> 
> > 4) How ugly are the error reports from the compiler when code is
> > malformed?  Blitz++ reports are incomprehensible to anyone except
> > template gurus.
> 
> You get a long instantiation backtrace as usual. However, we've
applied
> some tricks which cause error messages to contain a plain english
> description of what the user did wrong in many cases.
> 
> > 5) How steep is my learning curve on the code? (I know, only I can
> > answer that by looking at it for a while which I haven't yet.)
> 
> I have no idea how to answer that.
> 
> > Note that I'm really looking for the prettiest and fastest solution
> > *with the least possible headaches*.  For weave, least headaches
trumps
> > pretty and fast in a major way.
> 
> Then use the Python "C" API.

Did you say that while throughing your hands in the air? :-)  Seriously,
boost is very powerful but also fairly hefty.  It looks to me like I
would need at least 30K lines of code (probably more) to include all of
boost::python and its dependencies.  Probably only a subset of it is
needed for weave, but I have no idea what that subset is. Also, the list
above is not for the faint of heart.  

On the other hand SCXX is extremely light weight and seems to fit the
bill?  It actually reduces headaches compared to the C API, because like
boost, it handles the ref-count issues and makes the code prettier. 

> 
> > I've even considered moving weave back
> > to generating pure C code to make sure it works everywhere and
leaving
> > the user to wrestle with refcounts and the Python API.  I think C++
is
> > getting far enough along though that this shouldn't be necessary
(and
> > allows the "pretty").  Note though, that I was extremely
disappointed
> > with CXX's speed when manipulating lists, etc.  It was *much* slower
> > than calling the raw Python API.  For computationally intense stuff
on
> > lists, etc., you had to revert to API calls.  I haven't benchmarked
SCXX
> > yet, but I'm betting the story is the same.  Most things I care
about
> > are in Numeric arrays, but that isn't true for everyone else.
> 
> Boost.Python's object wrappers are not generally designed for maximum
> speed. For example, the list class knows that it might hold a class
> derived
> from list, so it does PyList_CheckExact() before calling any PyList_
> functions directly. If it's been subclassed it goes through the
general
> Python API. Also, none of the operators such as [] have been set up to
use
> the PyList_xxx functions in this way. It could be done; it's just a
lot of
> work.

OK.

> 
> > One other thought is that once we understand each others
technologies
> > better, we may see other places where synergy is beneficial.
> 
> Hopefully, yes.

I still feel there is a disconnect in the discussion.  I'm working to
get blitz installed on my system in hopes of getting more versed in how
it might mesh with and improve weave.  

> 
> > >
> > > > If you need the other 99.7% of boost's capabilities, then you
> > probably
> > > > need to be using boost instead of weave anyhow.  They serve
> > different
> > > > purposes.  Weave is generally suited for light weight wrapping
and
> > > > speeding up computational kernels with minimum hassle --
especially
> > in
> > > > numeric codes where Numeric isn't fast enough.
> > > >
> > > > Oh, and I'm happy to except patches that allow for boost type
> > converters
> > ^^^^^^ err... accept :-|
> >
> > > > in weave (they should, after all, be easy to write).  Then you
can
> > use
> > > > boost instead of SCXX.
> > >
> > > What did you have in mind?
> >
> > The code for a new type converter class that handles translating
Python
> > code to C++ is rather trivial after the latest factoring of weave.
Here
> > is an example of a weave expression and the underlying C++ code that
is
> > generated on the fly:
> >
> > #python
> > >>> a = {}
> > >>> weave.inline('a["hello"] = 1;',['a'])
> >
> > # underlying ext func
> > static PyObject* compiled_func(PyObject*self, PyObject* args)
> > {
> >     PyObject *return_val = NULL;
> >     int exception_occured = 0;
> >     PyObject *py__locals = NULL;
> >     PyObject *py__globals = NULL;
> >     PyObject *py_a;
> >     py_a = NULL;
> >
> >
> >
if(!PyArg_ParseTuple(args,"OO:compiled_func",&py__locals,&py__globals))
> >         return NULL;
> 
> Isn't there a way to check for dict/int args right
here?^^^^^^^^^^^^^^^^

You can, but it made the code generation hairier.  It was much easier to
have the converter objects inject the code in the code template.  It is
also in preparation for an alternative method of accessing the
variables.  In the future, we're just going to access the variables in
the calling stack frame directly.  This approach coupled with some ugly
things that Pat is doing now will reduce the overhead of calling
inline() substantially.  Right now, you pay a little for getting the
stack frame, the locals, and globals at the Python level as well as an
extra function call.  The newer approach makes inline() calls equivalent
to the cost of about 16 integer adds, which makes inlining even fairly
small snippets beneficial.

> 
> >     try
> >     {
> >         PyObject* raw_locals = py_to_raw_dict(py__locals,"_locals");
> >         PyObject* raw_globals =
py_to_raw_dict(py__globals,"_globals");
> >         /* argument conversion code */
> >         py_a = get_variable("a",raw_locals,raw_globals);
> >         PWODict a = convert_to_dict(py_a,"a");
> >         /* inline code */
> >         a["hello"] = 1;
> >     }
> >     catch(...)
> >     {
> >         return_val =  NULL;
> >         exception_occured = 1;
> >     }
> >     /* cleanup code */
> >     if(!return_val && !exception_occured)
> >     {
> >         Py_INCREF(Py_None);
> >         return_val = Py_None;
> >     }
> >     return return_val;
> > }
> >
> > So the line that has to change is:
> >
> >         PWODict a = convert_to_dict(py_a,"a");
> >
> > and the convert_to_dict function -- but it is automatically
generated by
> > the converter class (although you could customize it if needed).
> 
> That would look something like this in Boost.Python:
> 
>     handle<> py_a = borrowed(get_variable("a", raw_locals,
raw_globals));
>     dict x = extract<dict>(object(py_a));
> 
> You could generate slightly more-efficient code using some of the
> implementation details of Boost.Python, but I'd rather not expose
those to
> anyone.

So that part is simple.  It looks like getting boost converters into
weave is really a matter of getting the support code (headers,
libraries, etc.) straightened out so that distutils links the code
correctly.

eric





From dave at boost-consulting.com  Mon Sep 16 14:36:27 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Sep 2002 08:36:27 -0400
Subject: [C++-sig] Boost.Python v2: ** important **
References: <20020916063225.7263.qmail@web20207.mail.yahoo.com>
Message-ID: <036f01c25d7e$08441fe0$6701a8c0@boostconsulting.com>

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > * Joel has just finished adding what I hope will be the final
code-breaking
> > changes to Boost.Python v2 before its release early next month. These
are
> > still on a branch in the CVS for the time being (just to give you time
to
> > test your code with the current CVS state), but they will be merged
> > sometime on Tuesday.
>
> What are these changes? Are they related to the points of your Summary?

Yes, exactly. Joel's code-breaking changes are the points below.
However, they live only on a branch for the next couple of days.

> > 1. When specifying constructors, there is a new format:
> > 2. The def_init() function is going away. It is replaced by a def()
> > 3. A similar interface applies to the default argument feature:


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





From dave at boost-consulting.com  Mon Sep 16 15:00:23 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Sep 2002 09:00:23 -0400
Subject: [C++-sig] Weave Scipy Inline C++
References: <000001c25d6b$e0ea98f0$777ba8c0@ericlaptop>
Message-ID: <03ce01c25d81$0b916ec0$6701a8c0@boostconsulting.com>

From: "eric jones" <eric at enthought.com>

> Maybe the following would be easy to do if weave used boost:
>
> class foo:
>     def __init__(self,x):
>         self.x = x
>     def inc(self):
>         return x + 1
>
> a = foo(2)
> code = """
>        int b = a.x;
>        int c = a.inc();
>        """
> weave.inline(code,['a'])
>
> This would be a mapping from Python into C++.

It would look like:

        int b = extract<int>(a.attr("x"));
        int c = extract<int>(a.attr("inc")());

You don't need to write the extract stuff when there's a wrapped function
boundary taking int arguments, though.

> Weave doesn't currently
> try to handle this automatically, by generating a wrapper C++ object,
> but that sort of thing is in the future (with additional type
> information taken from comments).  This is sorta Pyrex-ish.  My bet is
> that boost might be the underpinnings of the code generator that builds
> this code, but that weave would be responsible for the code generation.

Oh, I see. Yeah, you could do that with Boost.

> > I don't understand why you are saying that to add functionality which
> use
> > components from a library (e.g. wxPython) you need to modify the
> library.
> > If weave can generate a piece of non-intrusive C++ which uses the
> library
> > components, the user can do that, too.
>
> You are right.  The point I should be making is that, while it is simple
> for you guys, it is non-trivial for an end user to modify an existing or
> generate a new extension module.  When a person needs to modify a few
> functions or try a few things out, the idea of making an extension
> module to do that is rarely an option.  With weave, and for supported
> types and external libraries, the process is about as simple as it can
> be made.

I'd be a little worried about the differences in C++ ABIs here.  You really
need to make sure that distutils is using the same compiler and compiler
options that the original library was built with. Same goes for the manual
extender, of course.


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





From eric at enthought.com  Mon Sep 16 16:35:01 2002
From: eric at enthought.com (eric jones)
Date: Mon, 16 Sep 2002 09:35:01 -0500
Subject: [C++-sig] Summary: Weave SciPy Inline C++
Message-ID: <000001c25d8e$3daa10d0$6b01a8c0@ericlaptop>

Here is a summary of what I've gotten from the discussion:

1.  Boost has some niceties that would beautify inline code in weave.

2.  However, Boost's library size and complexity are overkill for the
limited role it would currently play in weave type conversions.

3.  It is desirable to have Boost based converters for weave so that
those who prefer conversions to boost objects for the standard types can
have them.  This would be called using:

	weave.inline(code, args, converters=converters.boost)

4.  More importantly, it is desirable to have docs and examples of how
to write weave type converters for Boost wrapped libraries so that end
users can easily and efficiently manipulate the underlying classes in
C++ using weave.

If anyone tackles (3) or (4), please send your results my way.

I look forward to learning more about boost had how weave can benefit
from it as both tools progress.

Thanks,
eric




From praveen.patil at silver-software.com  Mon Sep 16 17:06:37 2002
From: praveen.patil at silver-software.com (Praveen Patil)
Date: Mon, 16 Sep 2002 16:06:37 +0100
Subject: [C++-sig] Please help solving the problem
In-Reply-To: <NFBBLJFBNMKMLGNLJMFCCENBCCAA.praveen.patil@silver-software.com>
Message-ID: <NFBBLJFBNMKMLGNLJMFCOENDCCAA.praveen.patil@silver-software.com>

Hi ,


Please help me in solving the problem below.


step 1: I have written three dlls :  a.dll , b.dll , c.dll.
                 a.dll contains  funct_A();
                 b.dll contains  funct_B();
                 c.dll contains  funct_C();

step 2: I am copying a.dll to directory C:\Program Files\Python\DLLs  and
renaming as a.pyd
        similarly
           I am copying b.dll to directory C:\Program Files\Python\DLLs. I
am not renaming as b.pyd
           I am copying c.dll to directory C:\Program Files\Python\DLLs and
renaming as c.pyd
        So my  C:\Program Files\Python\DLLs  directory contain
                         a.pyd , b.dll , c.pyd

step 3: a)Python function func_pyA() calls funct_A()
        b)funct_A() call funct_B()
        c)funct_B() call funct_C()
        d)funct_C() call python  fuction  func_pyC()

step 4: I am importing a.pyd and c.pyd in python program.
             import a
             import c

step 5: I am having problem in importing 'a' because  'a' need to load b.dll
and c.dll. But I copied c.dll as c.pyd.
        Please suggest me some solution.


here is my code :

 1)a.c (a.dll)
   ----------
         void func_A();


 2)b.c (b.dll)
   -----------
          void func_B();

 3)c.c( c.dll)
   -----------
          void func_C();

 4) example.py
    ---------
   import a
   import c

   G_Logfile  = None
   def TestFunction():
     G_Logfile = open('Pytestfile.txt', 'w')
     G_Logfile.write("%s \n"%'I am writing python created text file')
     G_Logfile.close
     G_Logfile = None

   if __name__ == "__main__":
   a.func_A();
   .....
   .....


Please help me in solving the problem.


Cheers,


Praveen.


[ The information contained in this e-mail is confidential and is intended for the named recipient only. If you are not the named recipient, please notify us by telephone on +44 (0)1249 442 430 immediately, destroy the message and delete it from your computer. Silver Software has taken every reasonable precaution to ensure that any attachment to this e-mail has been checked for viruses. However, we cannot accept liability for any damage sustained as a result of any such software viruses and advise you to carry out your own virus check before opening any attachment. Furthermore, we do not accept responsibility for any change made to this message after it was sent by the sender.]



From okuda1 at llnl.gov  Tue Sep 17 00:09:35 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Mon, 16 Sep 2002 15:09:35 -0700
Subject: [C++-sig] Boost.Python v2: ** important **
References: <031701c25d3b$0bf8bee0$6701a8c0@boostconsulting.com>
Message-ID: <3D86569F.362DB288@llnl.gov>

David Abrahams wrote:
> 
> * Boost.Python v2 and MPL have both been moved completely to the main trunk
> of Boost CVS. To get a CVS snapshot that reflects the current state of the
> world:
> 
>     cd <boost-root-directory>
>     cvs update -P -d -A .
> 
> If you've been using Boost.Python v2, you've been using the mpl-development
> branch of boost/mpl. That will no longer work. If you don't take the steps

I followed exactly above and I got a lot of compiling errors when
building bpl lib. Does it work on KCC? (It was buiilding ok for AIX and
OSF1 platforms with debug option and KCC compiler prior to the major
update of Boost.Python...)
Chuzo



tc43(67) buildBPL
...found 818 targets...
...updating 23 targets...
kcc-C++-action ../../libs/python/bin/libbpl.so/kcc/debug/list.o
"/usr/dnta/kull/workspaces/okuda/boostPython/boost/boost/mpl/integral_c.hpp",
line 35: error:
          non-integral operation not allowed in nontype template
argument
      typedef integral_c<T, value + 1> next;
                                  ^

"/usr/dnta/kull/workspaces/okuda/boostPython/boost/boost/mpl/integral_c.hpp",
line 36: error:
          non-integral operation not allowed in nontype template
argument
      typedef integral_c<T, value - 1> prior;
                                  ^

2 errors detected in the compilation of "src/list.cpp".
KCC: Compilation failed.

     KCC  -c  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2
-DBOOST_PYTHON_SOURCE  -g +K0   -I"../../libs/python" 
-I"/usr/dnta/kull/developers/libraries/v2/2/tru64_5/debug/include/python2.2"
-I"/usr/dnta/kull/workspaces/okuda/boostPython/boost"  -o
"../../libs/python/bin/libbpl.so/kcc/debug/list.o"  "src/list.cpp"

**** snips *****



From okuda1 at llnl.gov  Tue Sep 17 00:22:41 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Mon, 16 Sep 2002 15:22:41 -0700
Subject: [C++-sig] Boost.Python v2: ** important **
References: <031701c25d3b$0bf8bee0$6701a8c0@boostconsulting.com> <3D86569F.362DB288@llnl.gov>
Message-ID: <3D8659B1.12A7E018@llnl.gov>

It appears to be working fine for cxx (but this is not our platform of
choice for our code development):


tc43(84) ../../../buildBPL.cxx
...found 818 targets...
...updating 25 targets...
MkDir1 ../../libs/python/bin/libbpl.so/tru64cxx65
MkDir1 ../../libs/python/bin/libbpl.so/tru64cxx65/debug
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/list.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/long.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/dict.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/tuple.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/str.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/aix_init_module.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/from_python.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/registry.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/type_id.o
tru64cxx65-C++-action
../../libs/python/bin/libbpl.so/tru64cxx65/debug/enum.o

***** snips *****


chuzo okuda wrote:
> 
> David Abrahams wrote:
> >
> > * Boost.Python v2 and MPL have both been moved completely to the main trunk
> > of Boost CVS. To get a CVS snapshot that reflects the current state of the
> > world:
> >
> >     cd <boost-root-directory>
> >     cvs update -P -d -A .
> >
> > If you've been using Boost.Python v2, you've been using the mpl-development
> > branch of boost/mpl. That will no longer work. If you don't take the steps
> 
> I followed exactly above and I got a lot of compiling errors when
> building bpl lib. Does it work on KCC? (It was buiilding ok for AIX and
> OSF1 platforms with debug option and KCC compiler prior to the major
> update of Boost.Python...)
> Chuzo
> 
> tc43(67) buildBPL
> ...found 818 targets...
> ...updating 23 targets...
> kcc-C++-action ../../libs/python/bin/libbpl.so/kcc/debug/list.o
> "/usr/dnta/kull/workspaces/okuda/boostPython/boost/boost/mpl/integral_c.hpp",
> line 35: error:
>           non-integral operation not allowed in nontype template
> argument
>       typedef integral_c<T, value + 1> next;
>                                   ^
> 
> "/usr/dnta/kull/workspaces/okuda/boostPython/boost/boost/mpl/integral_c.hpp",
> line 36: error:
>           non-integral operation not allowed in nontype template
> argument
>       typedef integral_c<T, value - 1> prior;
>                                   ^
> 
> 2 errors detected in the compilation of "src/list.cpp".
> KCC: Compilation failed.
> 
>      KCC  -c  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2
> -DBOOST_PYTHON_SOURCE  -g +K0   -I"../../libs/python"
> -I"/usr/dnta/kull/developers/libraries/v2/2/tru64_5/debug/include/python2.2"
> -I"/usr/dnta/kull/workspaces/okuda/boostPython/boost"  -o
> "../../libs/python/bin/libbpl.so/kcc/debug/list.o"  "src/list.cpp"
> 
> **** snips *****
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From dave at boost-consulting.com  Tue Sep 17 00:14:50 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Sep 2002 18:14:50 -0400
Subject: [C++-sig] Boost.Python v2: ** important **
References: <031701c25d3b$0bf8bee0$6701a8c0@boostconsulting.com> <3D86569F.362DB288@llnl.gov>
Message-ID: <072501c25dce$e9cb34d0$6701a8c0@boostconsulting.com>

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


> David Abrahams wrote:
> >
> > * Boost.Python v2 and MPL have both been moved completely to the main
trunk
> > of Boost CVS. To get a CVS snapshot that reflects the current state of
the
> > world:
> >
> >     cd <boost-root-directory>
> >     cvs update -P -d -A .
> >
> > If you've been using Boost.Python v2, you've been using the
mpl-development
> > branch of boost/mpl. That will no longer work. If you don't take the
steps
>
> I followed exactly above and I got a lot of compiling errors when
> building bpl lib. Does it work on KCC? (It was buiilding ok for AIX and
> OSF1 platforms with debug option and KCC compiler prior to the major
> update of Boost.Python...)
> Chuzo

Argh! I forgot how old your KCCs are.
OK, I'll try to patch these things up. Hang on...

-Dave

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




From dave at boost-consulting.com  Tue Sep 17 20:50:46 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 17 Sep 2002 14:50:46 -0400
Subject: [C++-sig] Boost.Python v2: Stabilization, iterators
Message-ID: <0a7a01c25e7b$809f5830$6701a8c0@boostconsulting.com>

OK, the CVS state has mostly settled down. There's currently a problem with
iterator support caused by a recent change to Boost.Bind. To work around it
for the time being, you could check out version 1.20 of boost/bind.hpp.

Thanks for your patience,
Dave

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






From dave at boost-consulting.com  Tue Sep 17 22:39:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 17 Sep 2002 16:39:07 -0400
Subject: [C++-sig] Iterator problem now fixed
Message-ID: <0b4b01c25e8a$f7084f90$6701a8c0@boostconsulting.com>

The bugs caused by changes to Boost.Bind have now been worked around in
Boost.Python. You can now go back to using the main trunk version:

    cvs update -A

Enjoy,
Dave

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






From gideon at computer.org  Wed Sep 18 18:58:11 2002
From: gideon at computer.org (gideon may)
Date: Wed, 18 Sep 2002 18:58:11 +0200
Subject: [C++-sig] bjam keeps linking bpl.dll on win2k when there is no need to
Message-ID: <11476973.1032375491@[192.168.1.88]>

Dear Dave,

I've noticed the following fenomenon with bjam.

Each time when I run bjam, the target dll's are being
linked even when they are uptodate.  I'm using the
latest bjam
Boost.Jam  Version 3.1.2. OS=NT.
   Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
   Copyright 2001 David Turner.
   Copyright 2001-2002 David Abrahams.
and the most recent boost cvs version.

I've attached the output of bjam -d+3 when running bjam in the libs\python
directory (after a clean build!).

Secondly, when I try to run the tests I get the following errors:

<--------------------
C:\cvs_rep\boost\libs\python\test>bjam test
...found 2966 targets...
...updating 548 targets...
vc-Link 
..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\bpl.dll 
..\..\..\libs\python\bin\bpl.dll\vc7\debug\runti
me-link-dynamic\bpl.lib
LINK : fatal error LNK1181: cannot open input file 
'..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\list.obj'


    "link"  /nologo /INCREMENTAL:NO  /DEBUG /DLL /subsystem:console 
/out:"..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-l
ink-dynamic\bpl.dll" 
/IMPLIB:"..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\bp
l.lib"  /LIBPATH:"C:\Python22\l
ibs"  /LIBPATH:"C:\Program Files\Microsoft Visual Studio .NET\VC7\lib" 
@"..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-li
nk-dynamic\bpl.CMD"

...failed vc-Link 
..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\bpl.dll 
..\..\..\libs\python\bin\bpl.dll\vc7\d
ebug\runtime-link-dynamic\bpl.lib...
------------------------->

After running bjam in the test directory the bpl.dll is gone.

ciao,

Gideon

BTW,

I didn't forget about your request to file a bugreport on the mingw 2.0 
compiler. Will do
when I've some spare time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bjamdump.gz
Type: application/x-gzip
Size: 40217 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020918/85ea6c0a/attachment.bin>

From dave at boost-consulting.com  Wed Sep 18 19:18:33 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 18 Sep 2002 13:18:33 -0400
Subject: [C++-sig] bjam keeps linking bpl.dll on win2k when there is no need to
References: <11476973.1032375491@[192.168.1.88]>
Message-ID: <0fb501c25f37$a70a8640$6701a8c0@boostconsulting.com>

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

> Dear Dave,
>
> I've noticed the following fenomenon with bjam.
>
> Each time when I run bjam, the target dll's are being
> linked even when they are uptodate.  I'm using the
> latest bjam
> Boost.Jam  Version 3.1.2. OS=NT.
>    Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
>    Copyright 2001 David Turner.
>    Copyright 2001-2002 David Abrahams.
> and the most recent boost cvs version.

Hmm, yes, I see that. I'll see if I can figure it out.
It could be really hard to fix; I'll see.

> I've attached the output of bjam -d+3 when running bjam in the
libs\python
> directory (after a clean build!).
>
> Secondly, when I try to run the tests I get the following errors:
>
> <--------------------
> C:\cvs_rep\boost\libs\python\test>bjam test
> ...found 2966 targets...
> ...updating 548 targets...
> vc-Link
> ..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\bpl.dll
> ..\..\..\libs\python\bin\bpl.dll\vc7\debug\runti
> me-link-dynamic\bpl.lib
> LINK : fatal error LNK1181: cannot open input file
> '..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\list.obj'

Works for me...is the file there? Is it being used by something?

>     "link"  /nologo /INCREMENTAL:NO  /DEBUG /DLL /subsystem:console
> /out:"..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-l
> ink-dynamic\bpl.dll"
>
/IMPLIB:"..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\bp
> l.lib"  /LIBPATH:"C:\Python22\l
> ibs"  /LIBPATH:"C:\Program Files\Microsoft Visual Studio .NET\VC7\lib"
> @"..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-li
> nk-dynamic\bpl.CMD"
>
> ...failed vc-Link
> ..\..\..\libs\python\bin\bpl.dll\vc7\debug\runtime-link-dynamic\bpl.dll
> ..\..\..\libs\python\bin\bpl.dll\vc7\d
> ebug\runtime-link-dynamic\bpl.lib...
> ------------------------->
>
> After running bjam in the test directory the bpl.dll is gone.
>
> ciao,
>
> Gideon
>
> BTW,
>
> I didn't forget about your request to file a bugreport on the mingw 2.0
> compiler. Will do
> when I've some spare time.

*Please* just take a coupla minutes to do it ASAP. If these things don't
get reported quickly they never get fixed.

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




From dave at boost-consulting.com  Wed Sep 18 19:30:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 18 Sep 2002 13:30:39 -0400
Subject: [C++-sig] bjam keeps linking bpl.dll on win2k when there is no need to
References: <11476973.1032375491@[192.168.1.88]> <0fb501c25f37$a70a8640$6701a8c0@boostconsulting.com>
Message-ID: <0fd401c25f39$215c0ad0$6701a8c0@boostconsulting.com>

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

> Hmm, yes, I see that. I'll see if I can figure it out.
> It could be really hard to fix; I'll see.

Yeah, it's too hard. This falls into the category of stuff that has to wait
for Boost.Build v2.

Sorry,
Dave

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





From dave at boost-consulting.com  Thu Sep 19 19:02:49 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 19 Sep 2002 13:02:49 -0400
Subject: [C++-sig] bjam keeps linking bpl.dll on win2k when there is no need to
References: <11476973.1032375491@[192.168.1.88]>
Message-ID: <12ec01c25ffe$67802b20$6701a8c0@boostconsulting.com>

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


> Dear Dave,
> 
> I've noticed the following fenomenon with bjam.
> 
> Each time when I run bjam, the target dll's are being
> linked even when they are uptodate.  I'm using the
> latest bjam
> Boost.Jam  Version 3.1.2. OS=NT.
>    Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
>    Copyright 2001 David Turner.
>    Copyright 2001-2002 David Abrahams.
> and the most recent boost cvs version.

Fixed in CVS.

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







From djowel at gmx.co.uk  Sat Sep 21 04:51:52 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Sat, 21 Sep 2002 10:51:52 +0800
Subject: [C++-sig] Boost.Python v2: ** important **
References: <031701c25d3b$0bf8bee0$6701a8c0@boostconsulting.com> <3D86569F.362DB288@llnl.gov> <072501c25dce$e9cb34d0$6701a8c0@boostconsulting.com>
Message-ID: <011101c26119$d9e8e230$574ca7cb@kim>

Hi Y'all,

I should have posted this a few days ago. Pardon the delay.
Dave has already integrated my latest changes to the codebase
It has been committed to CVS since Tuesday. Everything is
humming along nicely in all compilers supported by Boost.Python.

These changes have been discussed before. Here's a refresher:

You can see a sample in the test directory named "defaults.cpp"
that tests and demonstrates these new capabilities. Most importantly,
when you want to wrap functions (or member functions) that are
either 1) overloaded or 2) has default arguments, there is a facility
now to make it easy to do this. 

For instance, given a function:

    int foo(int a, char b = 1, unsigned c = 2, double d = 3);

Before, you needed to write thin wrappers to make Python
recognize foo(int), foo(int, char), foo(int, char, unsigned)
and foo(int, char, unsigned, double). Then tediously inform 
Boost.Python of each of the thin-wrapped functions corresponding
to variations of the function foo.

Now, The macro invocation:

    BOOST_PYTHON_FUNCTION_OVERLOADS(foo_overloads, foo, 1, 4)

Will create the thin wrappers for us. This macro will create a class
"foo_overloads" that can be passed on to def(...) and automatically add
all the foo variants for us. For example:

        .def("foo", foo, foo_overloads());

You may *optionally* specify a docstring:

        .def("foo", foo, foo_overloads("my doc string"));

You may also *optionally* specify a call policy:

        .def("foo", foo, foo_overloads("my doc string")[my_call_policy]);

A similar facility is provided for class constructors, again, with or
without default arguments or overloads. For example, given a class X
with a constructor:

    X::X(int a, char b = 'D', std::string c = "constructor", double d = 0.0)

You can now easily add this constructor to Boost.Python:

    .def(init<int, optional<char, std::string, double> >())

Notice the use of init<...> and optional<...> to signify the default (optional
arguments). 

You may *optionally* specify a docstring:

    .def(init<int, optional<char, std::string, double> >("my doc string"))

You may also *optionally* specify a call policy:

    .def(init<int, optional<char, std::string, double> >("my doc string")[my_policy])

Here are the summary of the changes

1. When specifying constructors, there is a new format:

     init<...args..., optional< ...args...> >("docstring")[call_policies()]

Of course any of args, optional, "docstring" and [call_policies()] may be
ommitted (as shown above).

2. The def_init() function is ***obsolete***. It is replaced by a def()
overload which accepts init<...>. Thus:

    // default constructor with docstring
    class_<Y>("Y", init<>("doc of Y init"))
        .def("get_state", &Y::get_state)
        .def(init<int, optional<char, std::string, double> >("doc of
init"))
        .def(init<X*>()[with_custodian_and_ward<1,2>()])
        ;

3. A similar interface applies to the default argument feature:

  X* foo(Y& y, char b = 'D', std::string c = "default", double d = 0.0);

  // Generate overloads for 1-4 parameters
  BOOST_PYTHON_FUNCTION_OVERLOADS(foo_overloads, foo, 1, 4)

    ...
    def("foo", foo, foo_overloads("about
foo")[return_internal_reference<>()])

Here is a list of the possible arguments to def:

    The arguments may be:

        def(name, function)
        def(name, function, policy)
        def(name, function, doc_string)
        def(name, signature, overloads)
        def(name, function, policy, doc_string)
        def(name, function, doc_string, policy)

Where signature and overloads are the new kids in the block as explained above.

Finally, be reminded that ***module is obsolete****. It is dead and has 
been for some time now. 

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

Have fun!

--Joel














From dave at boost-consulting.com  Mon Sep 23 14:54:05 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 23 Sep 2002 08:54:05 -0400
Subject: [C++-sig] Re: [Python-Dev] ATTENTION!  Releasing Python 2.2.2 in a few weeks
References: <200209202126.g8KLQVI24554@pcp02138704pcs.reston01.va.comcast.net> <2m1y7kyi70.fsf@starship.python.net>
Message-ID: <0a0201c26300$924fd350$6701a8c0@boostconsulting.com>


> Guido van Rossum <guido at python.org> writes:
>
> > I'd like to release something called Python 2.2.2 in a few weeks (say,
> > around Oct 8; I like Tuesday release dates).


I've been planning to release Boost.Python v2 around the same time. Is
there any chance we can coordinate this so that we Boost.Python people can
test against all of the backported changes before either of these products
"goes final"?

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




From guido at python.org  Mon Sep 23 15:22:14 2002
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Sep 2002 09:22:14 -0400
Subject: [C++-sig] Re: [Python-Dev] ATTENTION! Releasing Python 2.2.2 in a few weeks
In-Reply-To: Your message of "Mon, 23 Sep 2002 08:54:05 EDT."
             <0a0201c26300$924fd350$6701a8c0@boostconsulting.com> 
References: <200209202126.g8KLQVI24554@pcp02138704pcs.reston01.va.comcast.net> <2m1y7kyi70.fsf@starship.python.net>  
            <0a0201c26300$924fd350$6701a8c0@boostconsulting.com> 
Message-ID: <200209231322.g8NDMGX06641@pcp02138704pcs.reston01.va.comcast.net>

> > > I'd like to release something called Python 2.2.2 in a few weeks (say,
> > > around Oct 8; I like Tuesday release dates).
> 
> I've been planning to release Boost.Python v2 around the same
> time. Is there any chance we can coordinate this so that we
> Boost.Python people can test against all of the backported changes
> before either of these products "goes final"?

If you check out the release22-maint branch of Python from CVS and
subscribe to the python-checkins list
(http://mail.python.org/mailman/listinfo/python-checkins) you should
be able to track the work leading up to 2.2.2 pretty closely.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From robertoschler at hotmail.com  Mon Sep 23 15:33:37 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Mon, 23 Sep 2002 09:33:37 -0400
Subject: [C++-sig] Any chance of Kylix/C++ support in the future?
Message-ID: <OE20oFK8onzvMMl6Dcu0000274c@hotmail.com>

Just my vote to see support for the Kylix/C++ environment in the future.  I'm a Kylix 3 Pro user and I really like it.  In the meantime which is better for a Windows to Linux convert to use with BoostPython on Linux.  Intel's C++ compiler or gcc?

thx

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

From rwgk at yahoo.com  Tue Sep 24 00:29:13 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 23 Sep 2002 15:29:13 -0700 (PDT)
Subject: [C++-sig] Re: [boost] fft
In-Reply-To: <20020922.185549.3992.0.jd.schmidt@juno.com>
Message-ID: <20020923222913.39584.qmail@web20203.mail.yahoo.com>

Cross-posted to the boost list and the Python C++ SIG.

--- Jason D Schmidt <jd.schmidt at juno.com> wrote:
> Think about this:
> 
> a = fft(b);        // a is complex, b could be either real or complex
>                       // easy to do, just overload the function
> 
> fft(b);             // b could either real or complex
>                      // however the ft of real input MUST be a real
> result
> 
> I think the most common use of the ft is to transform real data, which
> returns a complex result (in general).

A generic, pure C++ FFT library derived from FFTPACK is available in
this CVS tree:

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

The FFT code is fully documented:

scitbx/include/scitbx/fftpack/*.h

The boost header files are required.

Using scitbx as a pure C++ library does /not/ require a compiled
support library.

On a recent RedHat system it should be possible to run the two commands
below to get boost, scitbx, scons and then compile the regression tests
and the Boost.Python (Version 2) bindings for everything.

wget http://cci.lbl.gov/~rwgk/scitbx/cold_start_redhat_73_csh
csh cold_start_redhat_73_csh

It was quite tricky to work out a nice method for handling the in-place
real-to-complex transforms. I ended up writing an entire "array_family"
to support this (and many other things). I hope to have documentation
for the array_family before the end of the year. Until then, the
regression tests (scitbx/fftpack/timing/*.cpp,
scitbx/array_family/tst_*.cpp) and the code for the Python bindings
(scitbx/fftpack/boost_python/*.cpp) can be used as examples.

FFTW is a truly amazing library and it will require years of effort to
develop a serious competition. One possible way to work around the
restrictive (GPL) FFTW license is to use scitbx/fftpack as a "generic"
solution. If SCons finds a certain environmental variable it uses FFTW
for the 1D transforms, and scitbx/fftpack otherwise (for a proof of
concept search for FFTW_BUILD in scitbx/fftpack/timing SConscript).
This will work particularly well if the FFT library is used mainly
from Python.

I view FFTW's restriction to one floating point type per running
process as a serious limitation only for ND transforms since the arrays
involved are potentially huge. Here I see the biggest opportunity for
generic programming to make a difference sooner rather than later:

Inspection of FFTW's ND-array transforms shows that sophisticated
buffering is used to achieve maximum runtime performance. Therefore a
C++ ND transform interface could be templated on the floating point
type of the ND arrays but (if FFTW is to be used for the underlying 1D
transforms) the implementation would always use buffers of a certain type
(double). This could be hidden from the user and will most likely involve
only a negligible runtime penalty compared to a hypothetical FFT library
with generic 1D transforms that compares favorably with FFTW.

scitbx is unrestricted open source. Contributions are most welcome.
I'd support moving parts over to boost as much as my time permits,
if anyone is interested in getting a fast start that way.

Ralf

P.S.:

The cold_start command checks out the /most current/ CVS trees, so I am
taking my chances here. It worked great an hour ago (using the
SourceForge compile farm),

Depending on the speed of the CPU, compilation will take a while
(10-30 minutes). Note that almost all the time is spent at compiling
the Python bindings, in particular the bindings for the array_family.

cold_start_redhat_73_csh requirements:
  python2 == python 2.2 or higher (default on RedHat 7.3)
  g++ == 2.96 or higher (default on RedHat 7.3)


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From rwgk at yahoo.com  Tue Sep 24 01:52:24 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 23 Sep 2002 16:52:24 -0700 (PDT)
Subject: [C++-sig] Re: [Python-Dev] ATTENTION! Releasing Python 2.2.2 in a few weeks
In-Reply-To: <200209231322.g8NDMGX06641@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20020923235224.76315.qmail@web20208.mail.yahoo.com>

--- Guido van Rossum <guido at python.org> wrote:
> If you check out the release22-maint branch of Python from CVS and
> subscribe to the python-checkins list
> (http://mail.python.org/mailman/listinfo/python-checkins) you should
> be able to track the work leading up to 2.2.2 pretty closely.

Apparently the bug report

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470

has not yet lead to any changes in the release22-maint branch. The
worst problem are missing extern "C" in descrobject.h and iterobject.h.
This is compounded by missing include guards. We struggled quite a bit
to find a workaround for Boost.Python.

It will also be helpful if include guards are added to pymactoolbox.h.

Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From guido at python.org  Tue Sep 24 02:53:44 2002
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Sep 2002 20:53:44 -0400
Subject: [C++-sig] Re: [Python-Dev] ATTENTION! Releasing Python 2.2.2 in a few weeks
In-Reply-To: Your message of "Mon, 23 Sep 2002 16:52:24 PDT."
             <20020923235224.76315.qmail@web20208.mail.yahoo.com> 
References: <20020923235224.76315.qmail@web20208.mail.yahoo.com> 
Message-ID: <200209240053.g8O0riW20237@pcp02138704pcs.reston01.va.comcast.net>

> > If you check out the release22-maint branch of Python from CVS and
> > subscribe to the python-checkins list
> > (http://mail.python.org/mailman/listinfo/python-checkins) you should
> > be able to track the work leading up to 2.2.2 pretty closely.
> 
> Apparently the bug report
> 
> https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470
> 
> has not yet lead to any changes in the release22-maint branch. The
> worst problem are missing extern "C" in descrobject.h and iterobject.h.
> This is compounded by missing include guards. We struggled quite a bit
> to find a workaround for Boost.Python.

Please submit patches.  Not being a C++ user myself I find it hard to
guess exactly what needs to be done based upon your terse description.

> It will also be helpful if include guards are added to pymactoolbox.h.

I suppose you mean in the 2.2 branch?  Jack added them two weeks ago,
according to the bug report.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From nbecker at hns.com  Tue Sep 24 14:03:53 2002
From: nbecker at hns.com (Neal D. Becker)
Date: 24 Sep 2002 08:03:53 -0400
Subject: [C++-sig] Re: [boost] fft
In-Reply-To: <20020923222913.39584.qmail@web20203.mail.yahoo.com>
References: <20020923222913.39584.qmail@web20203.mail.yahoo.com>
Message-ID: <x88adm7bnme.fsf@rpppc1.md.hns.com>

Wow!  Scons, boost, python - so much power.  It will probably take me
weeks to figure out what all this is, but it sure looks cool!



From rwgk at yahoo.com  Tue Sep 24 23:54:51 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 24 Sep 2002 14:54:51 -0700 (PDT)
Subject: [C++-sig] copy_const_reference or return_internal_reference?
Message-ID: <20020924215451.67640.qmail@web20207.mail.yahoo.com>

I have an object composed of 12 double. A const& to this object is returned by
a member function of another class. From the viewpoint of using the returned
object in Python I do not care if I get a copy or a reference to the returned
object. In Boost.Python Version 2 I have the choice of using
copy_const_reference or return_internal_reference. Are there considerations
that would lead me to prefer one over the other, such as size of generated code
or memory overhead?

Thanks,
        Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Wed Sep 25 03:02:27 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 24 Sep 2002 21:02:27 -0400
Subject: [C++-sig] copy_const_reference or return_internal_reference?
References: <20020924215451.67640.qmail@web20207.mail.yahoo.com>
Message-ID: <0e2101c2642f$cb1cfbb0$6701a8c0@boostconsulting.com>

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


> I have an object composed of 12 double. A const& to this object is
returned by
> a member function of another class. From the viewpoint of using the
returned
> object in Python I do not care if I get a copy or a reference to the
returned
> object. In Boost.Python Version 2 I have the choice of using
> copy_const_reference or return_internal_reference. Are there
considerations
> that would lead me to prefer one over the other, such as size of
generated code
> or memory overhead?

copy_const_reference will make an instance with storage for one of your
objects, size = base_size + 12 * sizeof(double). return_internal_reference
will make an instance with storage for a pointer to one of your objects,
size = base_size + sizeof(void*). However, it will also create a weak
reference object which goes in the source object's weakreflist and a
special callback object to manage the lifetime of the internally-referenced
object. My guess? copy_const_reference is your friend here, resulting in
less overall memory use and less fragmentation, also probably fewer total
cycles.


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




From hugo at adept.co.za  Wed Sep 25 07:39:07 2002
From: hugo at adept.co.za (Hugo van der Merwe)
Date: Wed, 25 Sep 2002 07:39:07 +0200
Subject: [C++-sig] copy_const_reference or return_internal_reference?
In-Reply-To: <0e2101c2642f$cb1cfbb0$6701a8c0@boostconsulting.com>
References: <20020924215451.67640.qmail@web20207.mail.yahoo.com> <0e2101c2642f$cb1cfbb0$6701a8c0@boostconsulting.com>
Message-ID: <20020925053907.GC12436@vervet.localnet>

Can things like this go into some documentation somewhere, or maybe a
FAQ? (Wiki?)

It really helps to understand Boost.Python, while I find the current
documentation a little hard to fully comprehend. I suppose once a
tutorial is written, or the documentation finished, things will tend to
be a lot clearer...

Thanks,
Hugo van der Merwe

On Tue, Sep 24, 2002 at 09:02:27PM -0400, David Abrahams wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> 
> > I have an object composed of 12 double. A const& to this object is
> returned by
> > a member function of another class. From the viewpoint of using the
> returned
<SNIP>
> copy_const_reference will make an instance with storage for one of your
> objects, size = base_size + 12 * sizeof(double). return_internal_reference
> will make an instance with storage for a pointer to one of your objects,
<SNIP>



From dave at boost-consulting.com  Wed Sep 25 13:11:05 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 25 Sep 2002 07:11:05 -0400
Subject: [C++-sig] copy_const_reference or return_internal_reference?
References: <20020924215451.67640.qmail@web20207.mail.yahoo.com> <0e2101c2642f$cb1cfbb0$6701a8c0@boostconsulting.com> <20020925053907.GC12436@vervet.localnet>
Message-ID: <0e8c01c26484$c274a440$6701a8c0@boostconsulting.com>

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

> Can things like this go into some documentation somewhere, or maybe a
> FAQ? (Wiki?)
>
> It really helps to understand Boost.Python, while I find the current
> documentation a little hard to fully comprehend. I suppose once a
> tutorial is written, or the documentation finished, things will tend to
> be a lot clearer...

Yes, I'll be spending most of the next week-and-a-half on docs. Anyone
wanting to help with FAQ or tutorial entries will be richly praised
therein.

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





From rwgk at yahoo.com  Wed Sep 25 15:29:37 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 25 Sep 2002 06:29:37 -0700 (PDT)
Subject: [C++-sig] C++ const -> Python immutable?
Message-ID: <20020925132937.86646.qmail@web20207.mail.yahoo.com>

Consider a simple C++ array type, e.g. boost::array, and member functions of
some class that return such arrays.

boost::array<int, 3>& by_reference();
boost::array<int, 3> const& by_const_reference() const;

Now:

.def("by_reference", &w_t::by_reference, return_internal_reference<>())
.def("by_const_reference", &w_t::by_const_reference,
return_internal_reference<>())

Of course, what I was hoping for naively is that the "by_reference" array
behaves similar to a Python list (is mutable) and the "by_const_reference"
array behaves similar to a Python tuple (is immutable). However, my limited
experiments only resulted in "bad argument type for built-in operation" for
"by_const_reference." Is there a return_internal_const_reference policy that I
have overlooked?

Thanks,
        Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From rwgk at yahoo.com  Wed Sep 25 15:32:59 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 25 Sep 2002 06:32:59 -0700 (PDT)
Subject: [C++-sig] C++ const -> Python immutable?
In-Reply-To: <20020925132937.86646.qmail@web20207.mail.yahoo.com>
Message-ID: <20020925133259.18800.qmail@web20201.mail.yahoo.com>

Wait, I take that back, I was using a type that goes through a custom rvalue
converter... I will try again.
Ralf

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> However, my limited
> experiments only resulted in "bad argument type for built-in operation" for
> "by_const_reference."

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From rwgk at yahoo.com  Wed Sep 25 15:47:10 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 25 Sep 2002 06:47:10 -0700 (PDT)
Subject: [C++-sig] C++ const -> Python immutable?
In-Reply-To: <20020925133259.18800.qmail@web20201.mail.yahoo.com>
Message-ID: <20020925134710.68719.qmail@web20210.mail.yahoo.com>

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> Wait, I take that back, I was using a type that goes through a custom rvalue
> converter... I will try again.

Now it seems to me that both by_reference and by_const_reference work, but that
the "const" is lost. Is this correct?
Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Wed Sep 25 15:31:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 25 Sep 2002 09:31:47 -0400
Subject: [C++-sig] C++ const -> Python immutable?
References: <20020925134710.68719.qmail@web20210.mail.yahoo.com>
Message-ID: <0f7901c26498$104689a0$6701a8c0@boostconsulting.com>

Yep. Implementing a notion of immutability is on the list for "someday".

However, I don't yet have plans to make a wrapper around a const reference
to T different from a wrapper around a reference to T. Python doesn't have
the notion of a const reference to a mutable object (though of course
proxies are possible). In python, objects are either mutable or immutable;
end-of-story.

However #2, I don't think it's impossible to implement that distinction.
Let's talk about it again after Boost.Python is released.

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


----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, September 25, 2002 9:47 AM
Subject: Re: [C++-sig] C++ const -> Python immutable?


> --- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> > Wait, I take that back, I was using a type that goes through a custom
rvalue
> > converter... I will try again.
>
> Now it seems to me that both by_reference and by_const_reference work,
but that
> the "const" is lost. Is this correct?
> Ralf
>
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From mike at bindkey.com  Wed Sep 25 21:19:40 2002
From: mike at bindkey.com (Mike Rovner)
Date: Wed, 25 Sep 2002 12:19:40 -0700
Subject: [C++-sig] Re: Documentation
References: <FCEMIEFBFOIDAOJDEPIAEENPDLAA.achim.domma@syynx.de>
Message-ID: <amt27l$les$1@main.gmane.org>

"Achim Domma" <achim.domma at syynx.de> wrote in message
news:FCEMIEFBFOIDAOJDEPIAEENPDLAA.achim.domma at 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
>

I created a page on MoinMoin Wiki for boost.python v2.
It seems like a good place to assemble v2 intro and tutorial.
http://www.python.org/cgi-bin/moinmoin/boost_2epython?action=show







From paustin at eos.ubc.ca  Wed Sep 25 22:41:26 2002
From: paustin at eos.ubc.ca (Philip Austin)
Date: Wed, 25 Sep 2002 13:41:26 -0700
Subject: [C++-sig] C++ const -> Python immutable?
In-Reply-To: <20020925134710.68719.qmail@web20210.mail.yahoo.com>
References: <20020925133259.18800.qmail@web20201.mail.yahoo.com>
	<20020925134710.68719.qmail@web20210.mail.yahoo.com>
Message-ID: <15762.8054.532889.853870@gull.eos.ubc.ca>

Ralf W. Grosse-Kunstleve writes:
 > 
 > Now it seems to me that both by_reference and by_const_reference
 > work, but that the "const" is lost. Is this correct?  Ralf


This is one step further than I've managed to get, and I'm wondering
whether someone could point out the errors in the following program,
or suggest another approach.  The goal is to have a simple wrapper
(numhandle) that holds an object containing a PyArrayObject*.  Given
any python sequence, numpy can produce a deep copy with:

a) PyArray_CopyFromObject(o,PyArray_NOTYPE,0,0)))

and  either an incremented reference or a deep
copy with:

b) PyArray_ContiguousFromObject(o,PyArray_NOTYPE,0,0)))

Below I try to invoke a) with the function:

numhandle pass_by_value(numhandle theArray)

and b) with 

numhandle pass_by_reference(numhandle& theArray)

(I also try to return a reference, but instantiating
numhandle_to_python_reference() causes the compiler
to complain as noted on the line tagged Error: below).

The code compiles, but the results aren't what
I expect viz:

In python:

import Numeric as N
import num_test_ext as nt
thearray=N.arange(3,typecode=N.Float32)
print "python calls pass by value"
print nt.pass_by_value(thearray)

produces:

python calls pass by value
inside reference constructor
inside pass_by_value[ 999.    1.    2.]

i.e.  the reference constructor is called, even though
the signature is:

numhandle pass_by_value(numhandle theArray)

Next I try calling:

numhandle pass_by_reference(numhandle& theArray)

in python:

print "python calls pass by reference"
print nt.pass_by_reference(thearray)

which yields:

python calls pass by reference
Traceback (most recent call last):
  File "<stdin>", line 12, in ?
TypeError: bad argument type for built-in operation


Many thanks, Phil Austin


numhandle.cpp:__________________________________

#include <boost/python/def.hpp>
#include <boost/python/module_init.hpp>
#include <boost/python/object_core.hpp>
#include <iostream>
#include <Numeric/arrayobject.h>


using namespace boost::python;

struct numhandle {
  object pyholder;
};

struct register_numhandle_from_python_by_value
{
  register_numhandle_from_python_by_value()
  {
    converter::registry::insert(&convertible, 
                       &construct, type_id<numhandle>());
  }

  static void* convertible(PyObject* o)
  {
    std::cout << "inside value convertible check" << std::endl;
    if (!PySequence_Check(o)){
      return NULL;
    }
    return o;
  }

  static void construct (PyObject* o, 
                          converter::rvalue_from_python_stage1_data* data)
  {  
    std::cout << "inside value constructor" << std::endl;
    void* storage = ((converter::rvalue_from_python_storage<numhandle>*)
                                data)->storage.bytes;
    
    object newo(detail::new_reference(
                    PyArray_CopyFromObject(o,PyArray_NOTYPE,0,0)));
    new (storage) numhandle();
    data->convertible = storage;
    numhandle& result = *((numhandle*) storage);
    result.pyholder=newo;
  }

};

struct register_numhandle_from_python_by_reference
{
  register_numhandle_from_python_by_reference()
  {
    converter::registry::insert(&convertible, 
                    &construct, type_id<numhandle&>());
  }

  static void* convertible(PyObject* o)
  {
    if (!PySequence_Check(o)){
      return NULL;
    }
    return o;
  }

  static void construct (PyObject* o, 
                          converter::rvalue_from_python_stage1_data* data)
  {  
    std::cout << "inside reference constructor" << std::endl;
    void* storage = ((converter::rvalue_from_python_storage<numhandle>*)
                                data)->storage.bytes;
    
    object newo(detail::new_reference(
                    PyArray_ContiguousFromObject(o,PyArray_NOTYPE,0,0)));
    new (storage) numhandle();
    data->convertible = storage;
    numhandle& result = *((numhandle*) storage);
    result.pyholder=newo;
  }

};


struct numhandle_to_python_value : 
                to_python_converter<numhandle, numhandle_to_python_value>
{
  static PyObject*
  convert(numhandle x)
  {
    return incref(x.pyholder.ptr());
  }
};

struct numhandle_to_python_reference : 
                to_python_converter<numhandle&, numhandle_to_python_reference>
{
  static PyObject*
  convert(numhandle& x)
  {
    return incref(x.pyholder.ptr());
  }
};

numhandle pass_by_reference(numhandle& theArray){
  float* thedata= (float*)  ((PyArrayObject*) theArray.pyholder.ptr())->data;
  thedata[0]=888.;
  std::cout << "inside pass_by_reference";
  return theArray;
}

numhandle pass_by_value(numhandle theArray){
  float* thedata= (float*)  ((PyArrayObject*) theArray.pyholder.ptr())->data;
  std::cout << "inside pass_by_value";
  thedata[0]=999.;
  return theArray;
}


numhandle& return_a_reference(numhandle& theArray){
  float* thedata= (float*)  ((PyArrayObject*) theArray.pyholder.ptr())->data;
  std::cout << "return a reference";
  thedata[0]=777.;
  return theArray;
}

BOOST_PYTHON_MODULE_INIT(num_test_ext)
{ 
  using namespace boost::python;
  import_array();
  register_numhandle_from_python_by_value();
  register_numhandle_from_python_by_reference();
  numhandle_to_python_value();

  //Error: the following won't compile, error 
  // message says  "forming
  //   pointer to reference type `numhandle& const"

  //numhandle_to_python_reference();

  def("pass_by_reference", pass_by_reference);
  def("pass_by_value", pass_by_value);
}





From dave at boost-consulting.com  Wed Sep 25 22:34:08 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 25 Sep 2002 16:34:08 -0400
Subject: [C++-sig] C++ const -> Python immutable?
References: <20020925133259.18800.qmail@web20201.mail.yahoo.com><20020925134710.68719.qmail@web20210.mail.yahoo.com> <15762.8054.532889.853870@gull.eos.ubc.ca>
Message-ID: <112f01c264d2$e80d9830$6701a8c0@boostconsulting.com>

Phil,

I'm currently implementing NumPy support, but I'm taking an entirely
different approach which will allow it to interoperate with numarray as
well. Downside: it's probably going to be a little less-efficient from the
C++ side than your approach, since it goes through the Python 'C' api to
access all functionality.

From: "Philip Austin" <paustin at eos.ubc.ca>


> Ralf W. Grosse-Kunstleve writes:
>  >
>  > Now it seems to me that both by_reference and by_const_reference
>  > work, but that the "const" is lost. Is this correct?  Ralf
>
>
> This is one step further than I've managed to get, and I'm wondering
> whether someone could point out the errors in the following program,
> or suggest another approach.  The goal is to have a simple wrapper
> (numhandle) that holds an object containing a PyArrayObject*.  Given
> any python sequence, numpy can produce a deep copy with:
>
> a) PyArray_CopyFromObject(o,PyArray_NOTYPE,0,0)))
>
> and  either an incremented reference or a deep
> copy with:
>
> b) PyArray_ContiguousFromObject(o,PyArray_NOTYPE,0,0)))
>
> Below I try to invoke a) with the function:
>
> numhandle pass_by_value(numhandle theArray)
>
> and b) with
>
> numhandle pass_by_reference(numhandle& theArray)

Hmmm; that doesn't seem right.
Taking the approach used for list, tuple, et. al for consistency would mean
that you never copy the object and only match python arguments of the
correct numpy type. If you want a generic object, a boost::python::object
argument will do the job just fine.

> (I also try to return a reference, but instantiating
> numhandle_to_python_reference() causes the compiler
> to complain as noted on the line tagged Error: below).
>
> The code compiles, but the results aren't what
> I expect viz:
>
> In python:
>
> import Numeric as N
> import num_test_ext as nt
> thearray=N.arange(3,typecode=N.Float32)
> print "python calls pass by value"
> print nt.pass_by_value(thearray)
>
> produces:
>
> python calls pass by value
> inside reference constructor
> inside pass_by_value[ 999.    1.    2.]
>
> i.e.  the reference constructor is called, even though
> the signature is:
>
> numhandle pass_by_value(numhandle theArray)

Your numhandle object has these constructors?

    numhandle(numhandle)
    numhandle(numhandle&)

Or do you mean something else??

> Next I try calling:
>
> numhandle pass_by_reference(numhandle& theArray)
>
> in python:
>
> print "python calls pass by reference"
> print nt.pass_by_reference(thearray)
>
> which yields:
>
> python calls pass by reference
> Traceback (most recent call last):
>   File "<stdin>", line 12, in ?
> TypeError: bad argument type for built-in operation
>
>
> Many thanks, Phil Austin


No time to look at your code this instant, but I'll have my new stuff
checked in before the day's end. Why don't you hang on?

-Dave






From dave at boost-consulting.com  Wed Sep 25 22:35:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 25 Sep 2002 16:35:28 -0400
Subject: [C++-sig] Re: Documentation
References: <FCEMIEFBFOIDAOJDEPIAEENPDLAA.achim.domma@syynx.de> <amt27l$les$1@main.gmane.org>
Message-ID: <113c01c264d3$72c93060$6701a8c0@boostconsulting.com>


"Mike Rovner" <mike at bindkey.com> wrote in message
news:amt27l$les$1 at main.gmane.org...

> I created a page on MoinMoin Wiki for boost.python v2.
> It seems like a good place to assemble v2 intro and tutorial.
> http://www.python.org/cgi-bin/moinmoin/boost_2epython?action=show

Cool, Mike!

Are you planning on adding material there?


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




From mike at bindkey.com  Wed Sep 25 23:06:24 2002
From: mike at bindkey.com (Mike Rovner)
Date: Wed, 25 Sep 2002 14:06:24 -0700
Subject: [C++-sig] Re: Re: Documentation
References: <FCEMIEFBFOIDAOJDEPIAEENPDLAA.achim.domma@syynx.de> <amt27l$les$1@main.gmane.org> <113c01c264d3$72c93060$6701a8c0@boostconsulting.com>
Message-ID: <amt8fo$dvs$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:113c01c264d3$72c93060$6701a8c0 at boostconsulting.com...
>
>
> "Mike Rovner" <mike at bindkey.com> wrote in message
> news:amt27l$les$1 at main.gmane.org...
>
> > I created a page on MoinMoin Wiki for boost.python v2.
> > It seems like a good place to assemble v2 intro and tutorial.
> > http://www.python.org/cgi-bin/moinmoin/boost_2epython?action=show
>
> Cool, Mike!
>
> Are you planning on adding material there?

In order to grasp an understanding of v2 realm I'm scanning this group
(archives) and dropping collected materials there. Of cause, it's highly
fragmented or even wrong (hope, not ;)) but I'd like to collect useful
examples/overview there to fill the gap of absent (at the moment) tutorial.








From paustin at eos.ubc.ca  Thu Sep 26 00:06:55 2002
From: paustin at eos.ubc.ca (Philip Austin)
Date: Wed, 25 Sep 2002 15:06:55 -0700
Subject: [C++-sig] C++ const -> Python immutable?
In-Reply-To: <112f01c264d2$e80d9830$6701a8c0@boostconsulting.com>
References: <20020925133259.18800.qmail@web20201.mail.yahoo.com>
	<20020925134710.68719.qmail@web20210.mail.yahoo.com>
	<15762.8054.532889.853870@gull.eos.ubc.ca>
	<112f01c264d2$e80d9830$6701a8c0@boostconsulting.com>
Message-ID: <15762.13183.250200.757824@gull.eos.ubc.ca>

David Abrahams writes:
 > Phil,
 > 
 > I'm currently implementing NumPy support, but I'm taking an entirely
 > different approach which will allow it to interoperate with numarray as
 > well. Downside: it's probably going to be a little less-efficient from the
 > C++ side than your approach, since it goes through the Python 'C' api to
 > access all functionality.

That's great news, we'll look forward to it -- Phil







From dave at boost-consulting.com  Thu Sep 26 02:40:27 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 25 Sep 2002 20:40:27 -0400
Subject: [C++-sig] Boost.Python v2: Numeric/numarray support
Message-ID: <121401c264f5$510b10c0$6701a8c0@boostconsulting.com>

I've just checked in changes which give some support for Numeric and
numarray arrays.

Summary:

    #include <boost/python/numeric.hpp>
    using namespace boost::python;

    // a function accepting a numeric array argument
    object f(numeric::array x)
    {
        return x + x[make_tuple(3,3,4)]; // return x + x[3,3,4];
    }

    numeric::array g(object sequence)
    {
        // numeric::array() constructor maps to the 'array'
        // factory function.
        return numeric::array(sequence);
    }

Since numeric::array derives from boost::python::object, all the usual
operators are defined by default.

The default is to use the facilities of the numarray module, if it is
installed. Otherwise, we fall back to the Numeric module. If you have both
installed, and you want Numeric, or one of them is installed elsewhere in
your package path, you can tell Boost.Python which one to use explicitly:

    numeric::set_module_and_type("Numeric", "ArrayType");
    numeric::set_module_and_type("numarray", "NDArray");

I implemented all of the interface of numarray.NumArray, except that the
constructor is replaced by the interface of the array() factory function.
That means the C++ class has lots of interface that will just throw
exceptions if you try to use it with Numeric, e.g:

    x.diagonal(1, 2); // works with numarray, throws with Numeric

It seems as though Numeric users will probably want C++ wrappers for all of
the regular Numeric free functions and ufuncs, but that will probably have
to wait until after release (unless some kindly volunteer shows up who
wants to do it).

Enjoy,
Dave

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






From Lieven.Vanholme at rug.ac.be  Fri Sep 27 13:35:48 2002
From: Lieven.Vanholme at rug.ac.be (lieven vanholme)
Date: Fri, 27 Sep 2002 13:35:48 +0200 (MEST)
Subject: [C++-sig] bjam gcc3.2 boost_python compile problem
Message-ID: <Pine.GSO.4.31.0209271234130.12330-100000@allserv.rug.ac.be>

Hi,

I tried to compile boost_python(latest CVS) with gcc3.2 using bjam3.1.0
(os=linux)
invoking with;
 bjam -sBUILD=release -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/home/lvholme


got first this kind of error:
-------------------------------------------------
...found 818 targets...
...updating 31 targets...
MkDir1 ../../libs/python/bin
: command not found
MkDir1 ../../libs/python/bin/libbpl.so
: is a directory
mkdir: cannot create directory `\r': File exists

    mkdir  ../../libs/python/bin/libbpl.so

...failed MkDir1 ../../libs/python/bin/libbpl.so...
...skipped <directory-grist>../../libs/python/bin/libbpl.so/gcc for lack
of <directory-grist>.
./../libs/python/bin/libbpl.so...
...
--------------------------------------------------

and after repeating the command for about five times (directory structure
got finally build), i got another list of errors, looking all the same:
--------------------------------------------------
gcc-C++-action
../../libs/python/bin/libbpl.so/gcc/release/inlining-on/runtime-link-dynamic/sh
ared-linkable-true/numeric.o
: is a directory
g++: cannot specify -o with -c or -S and multiple compilations
...
--------------------------------------------------


Is this a gcc3.2-compiler problem?


thanx!


Lieven






From dave at boost-consulting.com  Fri Sep 27 13:28:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 27 Sep 2002 07:28:56 -0400
Subject: [C++-sig] bjam gcc3.2 boost_python compile problem
References: <Pine.GSO.4.31.0209271234130.12330-100000@allserv.rug.ac.be>
Message-ID: <039801c26619$bf6a3760$6501a8c0@boostconsulting.com>


----- Original Message -----
From: "lieven vanholme" <Lieven.Vanholme at rug.ac.be>


> Hi,
>
> I tried to compile boost_python(latest CVS) with gcc3.2 using bjam3.1.0
> (os=linux)
> invoking with;
>  bjam -sBUILD=release -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/home/lvholme
>
>
> got first this kind of error:
> -------------------------------------------------
> ...found 818 targets...
> ...updating 31 targets...
> MkDir1 ../../libs/python/bin
> : command not found
> MkDir1 ../../libs/python/bin/libbpl.so
> : is a directory
> mkdir: cannot create directory `\r': File exists
>
>     mkdir  ../../libs/python/bin/libbpl.so
>
> ...failed MkDir1 ../../libs/python/bin/libbpl.so...
> ...skipped <directory-grist>../../libs/python/bin/libbpl.so/gcc for lack
> of <directory-grist>.
> ./../libs/python/bin/libbpl.so...
> ...
> --------------------------------------------------
>
> and after repeating the command for about five times (directory structure
> got finally build), i got another list of errors, looking all the same:
> --------------------------------------------------
> gcc-C++-action
>
../../libs/python/bin/libbpl.so/gcc/release/inlining-on/runtime-link-dynami
c/sh
> ared-linkable-true/numeric.o
> : is a directory
> g++: cannot specify -o with -c or -S and multiple compilations
> ...
> --------------------------------------------------
>
>
> Is this a gcc3.2-compiler problem?

No, I think this is a problem with the line-ending convention in one of the
Jamfiles or the .jam files in the boost tools/build directory. It looks
like somehow you got a Windows checkout. Are you using a cross-mounted
disk? If not, do you think you could investigate which of these files
contains the offending '\r' line ending? Unfortunately my linux machine is
dead at the moment so I can't easily check this out.

-Dave

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




From Greg.Hawkins at softwire.co.uk  Fri Sep 27 14:13:37 2002
From: Greg.Hawkins at softwire.co.uk (Greg Hawkins)
Date: Fri, 27 Sep 2002 13:13:37 +0100
Subject: [C++-sig] py_interface in v2?
Message-ID: <616BE6A276E3714788D2AC35C40CD18D7CFD7E@whale.softwire.co.uk>

Dave,

I've just had occasion to use the Python api wrapping code in py_interface.[h|cpp] for the first time and realised that it isn't being built at the moment.

What's happening with this stuff? Is it going to be in before the release? Are there outstanding issues with it?

best,
Greg



From dave at boost-consulting.com  Fri Sep 27 14:13:43 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 27 Sep 2002 08:13:43 -0400
Subject: [C++-sig] py_interface in v2?
References: <616BE6A276E3714788D2AC35C40CD18D7CFD7E@whale.softwire.co.uk>
Message-ID: <03bc01c2661f$f2c9b580$6501a8c0@boostconsulting.com>

From: "Greg Hawkins" <Greg.Hawkins at softwire.co.uk>


<<I've just had occasion to use the Python api wrapping code in
py_interface.[h|cpp] for the first time and realised that it isn't being
built at the moment.

What's happening with this stuff?
>>

Nothing at the moment.

<<Is it going to be in before the release?>>

At this point, definitely not. Too much radio silence from the author
recently to be able to get it ready.

<<Are there outstanding issues with it?>>

I think there are lots, but I don't remember for sure. It hasn't been
tested (by me) in so long that there's surely some bitrot. The biggest
problem it used to have was that it came together with a set of very
intrusive changes that I wasn't happy with. I don't know whether they were
tightly bound or not, so it might not be a very big job to re-introduce it.

-Dave

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




From Lieven.Vanholme at rug.ac.be  Fri Sep 27 15:22:25 2002
From: Lieven.Vanholme at rug.ac.be (lieven vanholme)
Date: Fri, 27 Sep 2002 15:22:25 +0200 (MEST)
Subject: [C++-sig] bjam gcc3.2 boost_python compile problem
In-Reply-To: <039801c26619$bf6a3760$6501a8c0@boostconsulting.com>
Message-ID: <Pine.GSO.4.31.0209271519470.12330-100000@allserv.rug.ac.be>


On Fri, 27 Sep 2002, David Abrahams wrote:

> >
> > Is this a gcc3.2-compiler problem?
>
> No, I think this is a problem with the line-ending convention in one of the
> Jamfiles or the .jam files in the boost tools/build directory. It looks
> like somehow you got a Windows checkout. Are you using a cross-mounted
> disk? If not, do you think you could investigate which of these files
> contains the offending '\r' line ending? Unfortunately my linux machine is
> dead at the moment so I can't easily check this out.
>
> -Dave


Indeed, i was working with files i got via windows-cvs. I just tried the
same with real unix-files and everything worked properly!

thanx a lot for your fast and correct answer!


lieven







From dave at boost-consulting.com  Sat Sep 28 10:04:00 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 28 Sep 2002 04:04:00 -0400
Subject: [C++-sig] Boost.Python v2: keyword arguments
Message-ID: <073701c266c5$b2432310$6501a8c0@boostconsulting.com>

I have just checked in keyword argument support for Boost.Python v2

Boost.Python v2 is now feature-complete for release!

Synopsis:

Keywords are specified as:

    args("param1", "param2", "param3")

If N keywords are supplied, they specify the argument names of the last N
parameters to the function.

The following interfaces:

    def("function_name", function, ... )

    class_<T>()
        .def("method_name", &T::method, ... )

Now accept up to 3 arguments in any order in place of ...

    docstring (a string literal)
    call policies
    keywords

Keywords can also be supplied in:

    init<T1, T2...>("docstring", keywords)
    init<T1, T2...>(keywords, "docstring")
    init<T1, T2...>(keywords)

and likewise in the constructor of overload dispatchers defined with

    BOOST_PYTHON_FUNCTION_OVERLOADS(...)
  and
    BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(...)

See libs/python/test/args.[py/cpp] for examples.

Note that keyword arguments are really useful for cases like this:

    >>> def f(a = 1, b = 2, c = 3, d = 4, e = 5, f = 6):
        ...

    >>> f(1, 2, f = 99)  # **

But we can't support that with the BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS
mechanism. It's a limitation of C++. Our current default argument mechanism
creates overloaded Python functions which invoke a C++ function call
expression, and they have no access to the expressions used for any default
arguments to the C++ function. So:

 void ff(int a = 1, int b = 2, int c = 3, int d = 4, int e = 5, int f = 6)

Challenge: now write down a piece of valid C++ code which corresponds to
**. You can't do it without knowing and using the default argument
expressions for c, d, e. But remember, the library has no access to those.

We can allow you to specify any initial section of the total argument set
in any order, but how useful is that?

So, I plan to allow this instead:

    def("f", &f, (arg("a") = 1, arg("b") = 2, arg("c") = 3, ...)); // ***

which gets around that problem by supplying defaults up-front. The
downside, of course, is that you have to keep those expressions in-synch
with your C++ code. This feature will be added shortly after the first
release. All the infrastructure is already there.

Enjoy,
Dave

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






From dave at boost-consulting.com  Sat Sep 28 17:33:17 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 28 Sep 2002 11:33:17 -0400
Subject: [C++-sig] Preparations for release
Message-ID: <07ff01c26704$a30948e0$6501a8c0@boostconsulting.com>

Ladies & Gentlemen,

I'm working on the Boost.Python v2 docs now, and not touching the code
until further notice.

If you want to help get Boost.Python v2 ready for release, aid with any or
all of the following would be greatly appreciated (some of these jobs seem
to require CVS write permission, but actually you can do everything up to
the commit without write permission, and that would still be highly
valuable):

1. Merge everything that's happened on the main trunk of libs/python and
boost/python into the RC_1_29_0 branch and test it. I think this just
amounts to:

    cd $BOOST_ROOT
    cvs up -P -d -rRC_1_29_0
    cvs up -P -d -jHEAD libs/python boost/python

    # Run tests and let me know if there are any problems

    cvs commit
    cvs tag -F RC_1_29_0_last_merge libs/python boost/python

  1a. You could also start testing the merged RC_1_29_0 branch against
  the Python release22-maint cvs branch. Quoth Guido:

    If you check out the release22-maint branch of Python from CVS and
    subscribe to the python-checkins list
    (http://mail.python.org/mailman/listinfo/python-checkins) you should
    be able to track the work leading up to 2.2.2 pretty closely.

    (2.2.2 will be released approximately concurrently with Boost 1.29.0)

2. Sort out which files are only part of Boost.Python v1 and create two
archives, .zip and .tgz, then

    cvs remove the v1-only files
    test Boost.Python v2 to make sure it still works
    cvs commit

3. Think about providing some alternate approaches to building
Boost.Python.

 I have really mixed feelings about this since I don't want to maintain
 multiple build systems, but I also think:

   1. Windows users really expect a MS Visual studio project file that
   generates a differently-named lib/dll for debug-python builds, and the
   current Boost.Build strategy of renaming the libraries doesn't actually
   work because the original name of the dll gets encoded in the object
file
   dynamic linking fails.

   2. Some of the platforms we don't currently support in Boost.Build might
   be handled automatically by distutils. I'm thinking, for example of
   MacOS X. I seem to recall someone sending me distutils scripts for
building
   Boost.Python as part of a bug report long ago but I don't know where
they
   went :(. Any distutils experts out there?

4. Help to prepare documentation. Achim Domma has generously contributed a
bunch of documentation templates available at
www.procoders.net/dave/boostdocs.zip. These include many more
automatically-generated pages than we have public headers, so you could
ignore most of it. Even if you can't fill in everything, there's a lot of
structure and rote editing which you could do to prepare these for
inclusion into the distro. Let me know if you'd like to help and we can
negotiate a task.

Thanks,
Dave

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






From achim.domma at syynx.de  Sun Sep 29 19:03:17 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 29 Sep 2002 19:03:17 +0200
Subject: [C++-sig] Container support
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEMKDOAA.achim.domma@syynx.de>

Hi Dave,

what's the current status of container support (something like the
functionality implemented in Ralfs bplutils)? Is it currently available or
will it be available in the future? What's currently the best way to return
a std::vector<T>, where T is some class already wrapped by boost.python?

Achim





From dave at boost-consulting.com  Sun Sep 29 18:29:09 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 29 Sep 2002 12:29:09 -0400
Subject: [C++-sig] Container support
References: <FCEMIEFBFOIDAOJDEPIAEEMKDOAA.achim.domma@syynx.de>
Message-ID: <0a8e01c267d5$57d7a340$6501a8c0@boostconsulting.com>

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


> Hi Dave,
>
> what's the current status of container support (something like the
> functionality implemented in Ralfs bplutils)? Is it currently available


From ssmith at magnet.fsu.edu  Sun Sep 29 19:15:33 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Sun, 29 Sep 2002 13:15:33 -0400
Subject: [C++-sig] Container support
In-Reply-To: <0a8e01c267d5$57d7a340$6501a8c0@boostconsulting.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLEEEDCAAA.ssmith@magnet.fsu.edu>

Hello Dave, Achim,

Coincidentally, I was looking at the docs and wondering the exact
same thing. But I am a bit slower than Achim.

Are more common things such as std::vector<double> already exported into
Boost.Python?
If so, where can I read about them?
Where can I have a look at Ralf's bplutils?

Thanks,
Scott




From robertoschler at hotmail.com  Sun Sep 29 19:19:33 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Sun, 29 Sep 2002 13:19:33 -0400
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
Message-ID: <OE39ZwulnVKdplu89em000041c9@hotmail.com>

Anybody been adventurous enough to try the Boost Graph Library with Boost Python v 2?  Just wondering what I might be getting myself into (difficulty-wise).

thx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020929/7f6207e2/attachment.htm>

From dave at boost-consulting.com  Sun Sep 29 19:08:17 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 29 Sep 2002 13:08:17 -0400
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
References: <OE39ZwulnVKdplu89em000041c9@hotmail.com>
Message-ID: <0af601c267da$d214dfb0$6501a8c0@boostconsulting.com>

People asked about this with Boost.Python v1, too. I think the biggest
problem you'll find is that BGL is about compile-time genericity and Python
is about runtime genericity. You could easily  map the BGL's genericity
into Python, but that'd be best done by rewriting it in Python. Of course,
then you'd give up most of the speed.

Wrapping individual algorithms specialized to operate on specific graph
structures with Boost.Python should be easy, of course, and the algorithms
would run fast. You could think about building graphs with internal
property maps that contain a boost::python::object for each edge/vertex.
That might be an approach which allows some compromises.

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


----- Original Message -----
From: "Robert Oschler" <robertoschler at hotmail.com>


Anybody been adventurous enough to try the Boost Graph Library with Boost
Python v 2?  Just wondering what I might be getting myself into
(difficulty-wise).

thx






From dave at boost-consulting.com  Sun Sep 29 19:45:16 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 29 Sep 2002 13:45:16 -0400
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
References: <OE39ZwulnVKdplu89em000041c9@hotmail.com> <0af601c267da$d214dfb0$6501a8c0@boostconsulting.com>
Message-ID: <0b2c01c267e0$10a85e00$6501a8c0@boostconsulting.com>

> From: "Robert Oschler" <robertoschler at hotmail.com>
>> Anybody been adventurous enough to try the Boost Graph Library with
Boost
>> Python v 2?  Just wondering what I might be getting myself into
>> (difficulty-wise).
>>
>> thx

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


> People asked about this with Boost.Python v1, too. I think the biggest
> problem you'll find is that BGL is about compile-time genericity and
Python
> is about runtime genericity. You could easily  map the BGL's genericity
> into Python, but that'd be best done by rewriting it in Python. Of
course,
> then you'd give up most of the speed.
>
> Wrapping individual algorithms specialized to operate on specific graph
> structures with Boost.Python should be easy, of course, and the
algorithms
> would run fast. You could think about building graphs with internal
> property maps that contain a boost::python::object for each edge/vertex.
> That might be an approach which allows some compromises.

Another interesting area to explore might be some kind of weave-like
arrangement where C++ code for specific graph configurations is generated
and compiled on-the-fly as different Python graph structures are passed to
BGL algorithms.

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





From robertoschler at hotmail.com  Sun Sep 29 20:20:28 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Sun, 29 Sep 2002 14:20:28 -0400
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
References: <OE39ZwulnVKdplu89em000041c9@hotmail.com> <0af601c267da$d214dfb0$6501a8c0@boostconsulting.com>
Message-ID: <OE52nAU3qt2gx4csMCM00004f3e@hotmail.com>

----- Original Message -----
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Sunday, September 29, 2002 1:08 PM
Subject: Re: [C++-sig] Anyone tried BGL with BoostPython 2 yet?


> People asked about this with Boost.Python v1, too. I think the biggest
> problem you'll find is that BGL is about compile-time genericity and
Python
> is about runtime genericity. You could easily  map the BGL's genericity
> into Python, but that'd be best done by rewriting it in Python. Of course,
> then you'd give up most of the speed.
>
> Wrapping individual algorithms specialized to operate on specific graph
> structures with Boost.Python should be easy, of course, and the algorithms
> would run fast. You could think about building graphs with internal
> property maps that contain a boost::python::object for each edge/vertex.
> That might be an approach which allows some compromises.
>

My question was poorly phrased.  I'm going to write a specific data
structure "housing module" that will use graph structures for encoding
complex data structures.  I will use the BGL for managing the data structure
queries, but Python will only see the "housing module" classes and method
calls which I hope to expose via the Boost Python wrappers.  Python will not
talk to the BGL directly at all.  My question was more to do with someone
using the BGL within a Boost extensions module, and any possible conflicts
or caveats that may come from attempting that, not with trying to wrap the
BGL itself for general Python access.  Sorry for the confusion.

thx



From dave at boost-consulting.com  Sun Sep 29 20:05:03 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 29 Sep 2002 14:05:03 -0400
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
References: <OE39ZwulnVKdplu89em000041c9@hotmail.com> <0af601c267da$d214dfb0$6501a8c0@boostconsulting.com> <OE52nAU3qt2gx4csMCM00004f3e@hotmail.com>
Message-ID: <0b3c01c267e2$de834590$6501a8c0@boostconsulting.com>

From: "Robert Oschler" <robertoschler at hotmail.com>
> From: "David Abrahams" <dave at boost-consulting.com>

>
> > People asked about this with Boost.Python v1, too. I think the biggest
> > problem you'll find is that BGL is about compile-time genericity and
> Python
> > is about runtime genericity. You could easily  map the BGL's genericity
> > into Python, but that'd be best done by rewriting it in Python. Of
course,
> > then you'd give up most of the speed.
> >
> > Wrapping individual algorithms specialized to operate on specific graph
> > structures with Boost.Python should be easy, of course, and the
algorithms
> > would run fast. You could think about building graphs with internal
> > property maps that contain a boost::python::object for each
edge/vertex.
> > That might be an approach which allows some compromises.
> >
>
> My question was poorly phrased.  I'm going to write a specific data
> structure "housing module" that will use graph structures for encoding
> complex data structures.

Out of curiosity: what are you doing, large-scale architecture?

> I will use the BGL for managing the data structure
> queries, but Python will only see the "housing module" classes and method
> calls which I hope to expose via the Boost Python wrappers.  Python will
not
> talk to the BGL directly at all.  My question was more to do with someone
> using the BGL within a Boost extensions module, and any possible
conflicts
> or caveats that may come from attempting that, not with trying to wrap
the
> BGL itself for general Python access.  Sorry for the confusion.

It shouldn't cause any problems, as I am using BGL within the Boost.Python
library implementation.


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






From robertoschler at hotmail.com  Sun Sep 29 21:30:12 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Sun, 29 Sep 2002 15:30:12 -0400
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
References: <OE39ZwulnVKdplu89em000041c9@hotmail.com> <0af601c267da$d214dfb0$6501a8c0@boostconsulting.com> <OE52nAU3qt2gx4csMCM00004f3e@hotmail.com> <0b3c01c267e2$de834590$6501a8c0@boostconsulting.com>
Message-ID: <OE490OM3G80cEeyD2MD0000433c@hotmail.com>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Sunday, September 29, 2002 2:05 PM
Subject: Re: [C++-sig] Anyone tried BGL with BoostPython 2 yet?


> From: "Robert Oschler" <robertoschler at hotmail.com>
> > From: "David Abrahams" <dave at boost-consulting.com>
> 
> >
> Out of curiosity: what are you doing, large-scale architecture?
> 

No I'm using BGL for packet traffic routing analysis.

thx




From koning at pobox.com  Sun Sep 29 04:44:56 2002
From: koning at pobox.com (Joseph Koning)
Date: Sat, 28 Sep 2002 19:44:56 -0700
Subject: [C++-sig] Preparations for release - linux report
References: <07ff01c26704$a30948e0$6501a8c0@boostconsulting.com>
Message-ID: <3D966928.8060406@pobox.com>

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



David Abrahams wrote:

|
|
|1. Merge everything that's happened on the main trunk of libs/python and
|boost/python into the RC_1_29_0 branch and test it. I think this just
|amounts to:
|
|    cd $BOOST_ROOT
|    cvs up -P -d -rRC_1_29_0
|    cvs up -P -d -jHEAD libs/python boost/python
|
|    # Run tests and let me know if there are any problems
|
|  1a. You could also start testing the merged RC_1_29_0 branch against
|  the Python release22-maint cvs branch. Quoth Guido:
|
|    If you check out the release22-maint branch of Python from CVS and
|    subscribe to the python-checkins list
|    (http://mail.python.org/mailman/listinfo/python-checkins) you should
|    be able to track the work leading up to 2.2.2 pretty closely.
|
|    (2.2.2 will be released approximately concurrently with Boost 1.29.0)
|
I tested the RC_1_29_0 branch against the release22-maint branch on 
linux with the gcc version 3.1 20020619 (Red Hat Linux Rawhide 3.1-6.1) 
compiler.  Here are the results for test:

...failed updating 1 target...
...skipped 2 targets...
...updated 81 targets...

The failed target is numpy:
gcc-C++-action 
../../../libs/python/test/bin/numpy_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/numpy.o
/var/tmp/boost/boost/preprocessor/iteration/detail/local.hpp: In constructor
~   `boost::python::numeric::array::array(const T0&) [with T0 =
~   boost::python::tuple]':
numpy.cpp:23:   instantiated from here
/var/tmp/boost/boost/preprocessor/iteration/detail/local.hpp:38: `
~   BOOST_PYTHON_ENUM_AS_OBJECT' undeclared (first use this function)
/var/tmp/boost/boost/preprocessor/iteration/detail/local.hpp:38: (Each
~   undeclared identifier is reported only once for each function it appears
~   in.)
/var/tmp/boost/boost/preprocessor/iteration/detail/local.hpp:38: `x' 
undeclared
~   (first use this function)
/var/tmp/boost/boost/preprocessor/iteration/detail/local.hpp:38: `
~   BOOST_PP_ENUM_1' undeclared (first use this function)

~    g++  -c -Wall -ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB 
-DBOOST_PYTHON_V2  -g -O0 -fno-inline -fPIC   
-I"../../../libs/python/test"  -isystem 
"/usr/local/python2.2rel/include/python2.2" -isystem "/var/tmp/boost"  
-o 
"../../../libs/python/test/bin/numpy_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/numpy.o"  
"numpy.cpp"

...failed gcc-C++-action 
../../../libs/python/test/bin/numpy_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/numpy.o...
...skipped 
<libs!python!test/numpy_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true>numpy_ext.so 
for lack of 
<libs!python!test/numpy_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true>numpy.o...
...skipped 
<libs!python!test/numpy.test/gcc/debug/runtime-link-dynamic>numpy.test 
for lack of 
<libs!python!test/numpy_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true>numpy_ext.so...

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9lmdErCniwiUDQt8RAhWDAJwLRcRVu64bEODYVuj0jvqUhpKEBgCfUl4t
XanaLbuVB9gQgiNOznOr79w=
=Lgzr
-----END PGP SIGNATURE-----






From dave at boost-consulting.com  Mon Sep 30 01:01:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 29 Sep 2002 19:01:44 -0400
Subject: [C++-sig] Preparations for release - linux report
References: <07ff01c26704$a30948e0$6501a8c0@boostconsulting.com> <3D966928.8060406@pobox.com>
Message-ID: <0c4b01c2680c$314580d0$6501a8c0@boostconsulting.com>


----- Original Message -----
From: "Joseph Koning" <koning at pobox.com>
To: <c++-sig at python.org>
Sent: Saturday, September 28, 2002 10:44 PM
Subject: Re: [C++-sig] Preparations for release - linux report


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> David Abrahams wrote:
>
> |
> |
> |1. Merge everything that's happened on the main trunk of libs/python and
> |boost/python into the RC_1_29_0 branch and test it. I think this just
> |amounts to:
> |
> |    cd $BOOST_ROOT
> |    cvs up -P -d -rRC_1_29_0
> |    cvs up -P -d -jHEAD libs/python boost/python
> |
> I tested the RC_1_29_0 branch against the release22-maint branch on
> linux with the gcc version 3.1 20020619 (Red Hat Linux Rawhide 3.1-6.1)
> compiler.  Here are the results for test:

Joe,

Thanks for testing, but there must be something wrong with your CVS tree,
since there is no file named numpy.cpp in the RC_1_29_0 branch.

...

> ~    g++  -c -Wall -ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB
> -DBOOST_PYTHON_V2  -g -O0 -fno-inline -fPIC
> -I"../../../libs/python/test"  -isystem
> "/usr/local/python2.2rel/include/python2.2" -isystem "/var/tmp/boost"
> -o
>
"../../../libs/python/test/bin/numpy_ext.so/gcc/debug/runtime-link-dynamic/
shared-linkable-true/numpy.o"
> "numpy.cpp"
  ^^^^^^^^^^


Or are you saying you have also done the merge step (the line with the -j
option above)?

This doesn't appear to be specific to release22-maint. Do you get the same
error when testing the main trunk of the boost CVS tree?

    cd $BOOST_ROOT
    cvs up -P -d -A
    cd libs/python/test
    bjam ... numpy.obj


Thanks,
Dave


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




From rwgk at yahoo.com  Mon Sep 30 05:58:17 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 29 Sep 2002 20:58:17 -0700 (PDT)
Subject: [C++-sig] Container support
In-Reply-To: <PCEJJPDHEECNEKDDLPNLEEEDCAAA.ssmith@magnet.fsu.edu>
Message-ID: <20020930035817.23985.qmail@web20208.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> Are more common things such as std::vector<double> already exported into
> Boost.Python?
> If so, where can I read about them?
> Where can I have a look at Ralf's bplutils?

It is the file

scitbx/include/scitbx/boost_python/container_conversions.h

in the "scitbx" (scientific toolbox) module of the SourceForge cctbx project
(and no longer called bpl_utils). The easistest way to get the file is to
simply check out the entire scitbx tree (small, compared to boost):

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

I believe you just need that one file. Simple regression tests with
std::vector, std::list, boost::array and some of the scitbx container types can
be found here:

scitbx/array_family/boost_python/regression_test_module.cpp

Ralf

P.S.: To get and compile everything on a RedHat 7.3 system try this:
    wget http://cci.lbl.gov/~rwgk/scitbx/cold_start_redhat_73_csh
    # look at the script to see what it will be doing
    csh cold_start_redhat_73_csh
But it will take a while!


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From leo at hiper.com.br  Mon Sep 30 20:21:05 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 30 Sep 2002 15:21:05 -0300
Subject: [C++-sig] stage rule and version in .so name
In-Reply-To: <20020913111153-r01010800-f42cf40b-0860-0108@12.100.89.43>
References: <20020913111153-r01010800-f42cf40b-0860-0108@12.100.89.43>
Message-ID: <1033410065.17710.0.camel@spitfire>

This one took long for me to reply :-)

On Fri, 2002-09-13 at 13:11, Rene Rivera wrote:
> 
> [...] I just put in some changes which attempt to clone the exact state of the
> files actually generated by the SONAME support. It's not totally working as
> it should, and it never will in V1. But for now it should be reasonable, as
> long as you don't use the "tag" features of stage for SONAMEd files.

Well, after looking up what "tag" requirements are, I definetly don't
plan to use them anytime soon.

> Try it and tell me if it works for your needs.

The one test I did works fairly well for me. Thanks a lot. It'll make my
life much easier :-)

Cheers, Leo

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




From grafik666 at redshift-software.com  Mon Sep 30 23:10:34 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon, 30 Sep 2002 16:10:34 -0500
Subject: [C++-sig] stage rule and version in .so name
In-Reply-To: <1033410065.17710.0.camel@spitfire>
Message-ID: <20020930161036-r01010800-2907707a-0860-0108@12.100.89.43>

[2002-09-30] Leonardo Rochael Almeida wrote:

>
>This one took long for me to reply :-)
>
>On Fri, 2002-09-13 at 13:11, Rene Rivera wrote:
>> 
>> [...] I just put in some changes which attempt to clone the exact state
of the
>> files actually generated by the SONAME support. It's not totally working
as
>> it should, and it never will in V1. But for now it should be reasonable,
as
>> long as you don't use the "tag" features of stage for SONAMEd files.
>
>Well, after looking up what "tag" requirements are, I definetly don't
>plan to use them anytime soon.
>
>> Try it and tell me if it works for your needs.
>
>The one test I did works fairly well for me. Thanks a lot. It'll make my
>life much easier :-)

Cool, I'm glad... as it turns out my above statement, of it never working
for V1 with tags is no longer true. Over the weekend I implemented the
correct support for tags. So don't be scared to use them either ;-)


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