From david.abrahams at rcn.com  Wed May  1 02:04:21 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 30 Apr 2002 19:04:21 -0500
Subject: [C++-sig] V2: to_python/from_python questions
References: <Pine.LNX.4.21.0204222222460.32358-100000@cens.ioc.ee>
Message-ID: <063401c1f0a3$e2cb6300$6401a8c0@boostconsulting.com>

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

> Hi Dave,

> > The upshot is that you can ignore coerce and just overload your
__add__
> > and __radd__ method to work with floats.
>
> Instead of defining a punch of add methods like
>
> const GiNaC::ex ex_add(const GiNaC::ex&,double);
> const GiNaC::ex ex_add(const GiNaC::ex&,int);
> const GiNaC::ex ex_add(const GiNaC::ex&,const GiNaC::ex&);
> const GiNaC::ex ex_add(const GiNaC::ex&,const GiNaC::basic&);
> const GiNaC::ex ex_add(const GiNaC::ex&,complex);
>
> I am thinking of having a single one
>
> const GiNaC::ex ex_add(const GiNaC::ex&,PyObject*);
>
> It ignores V2 overloading stuff. Is there any downside of doing this
> except having my own bugs?

Not that I can think of offhand.

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

Unfortunately not. The v2 facilities are more sophisticated, and thus
(unfortunately) more complicated.

> In V2 I have used, for example
>
>   boost::python::to_python_value<const GiNaC::ex&>()(e)
>
> to construct a PyObject of e. Is this the correct way?

Not exactly. I haven't provided a nice mechanism for users yet. In v2,
we don't use exceptions to implement overloading anymore, which means
that conversions used in wrapped function calls explicitly check whether
the conversion can succeed (basically, it tests whether such a
conversion has been registered).

So the first problem is that you need to call the to_python_value<>
object's convertible() member function and "throw a Python exception" if
it returns false. That means, for the time being, setting the Python
exception information through the usual Python "C" API, and calling
boost::python::throw_error_already_set(). You can see the checking in
action in boost/python/preprocessed/returning_non_void.hpp, though
there's no exception thrown since we might be doing overload resolution:

...
    if(!cr.convertible())return 0;
    if(!policies->precall(args_))return 0;
    PyObject*result=cr(((
                       c0(PyTuple_GET_ITEM(args_,0)))->*pmf)());
...

Where cr might be an instance of to_python_value<>, depending on the
type of pmf and the policies class used.

The second problem is that how references are converted depends on
context. You can see this in boost/python/preprocessed/call.hpp:

...
    converter::callback_from_python<R>converter;
    return converter(
        PyEval_CallFunction(
            callable,const_cast<char*>("(" "O" ")")
            ,converter::callback_to_python<A0>(a0).get()));
...

This is code used to call *into* Python, so callback_to_python<> acts
differently from to_python_value. First, it /does/ throw C++ exceptions
when no converter can be found. Secondly, callback_from_python's
behavior w.r.t. references and pointers is determined by the logic in
select_callback_to_python<> (see boost/python/converter/callback.hpp).
The rationale is outlined in libs/python/doc/v2/callbacks.txt.

After all of this, maybe you can see why I haven't settled on a simple
mechanism for general use yet. I'm not sure what the best behavior for
users is, but I'm inclined to think that callback_to_python<T> is pretty
close to being the right mechanism. Perhaps just wrapping it in a simple
function is enough.

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

these are detailed in libs/python/doc/v2/to_python_indirect.html and
libs/python/doc/v2/to_python_converter.html; does that material answer
your question?

> Also I have used
>
>   boost::python::converter::reference_from_python<const
GiNaC::basic&>(obj)(obj)
>
> to get GiNaC::basic& from PyObject obj. This looks clumsy (using two
> times obj). Is there a more appropriate way for getting C++ objects
for
> Python objects?

I guess I would tend to direct you toward
converter::callback_from_python<>, since that will throw a C++ exception
upon failure. It seems to match user needs pretty well.

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

I'm not sure from_python is directly appropriate for users. from_python
hides a large quantity of converter selection logic (see
select_from_python in boost/python/converter/from_python.hpp), and you
can see examples of its use in
boost/python/preprocessed/returning_non_void.hpp.

I don't see value_from_python anywhere (?)

I think that answering this post is pushing me in the direction of
renaming the existing to_python/from_python so the names can be used for
the user-friendly functions based on the callback_* functionality.

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

I hope the above helps, and isn't too much to wade through.

-Dave






From geh at itga.com.au  Wed May  1 02:07:02 2002
From: geh at itga.com.au (Gary Hughes)
Date: Wed, 01 May 2002 10:07:02 +1000
Subject: [C++-sig] linking problem
Message-ID: <3CCF31A6.2040607@itga.com.au>

Hi,

I posted this question of comp.lang.python but I haven't received any 
response, hopefully someone here can point me in the right direction.

I have written an extension module that exposes a C++ class. I need to 
be able to build and run it on Solaris 2.6 and 2.8 with g++.

The 2.8 build works with no problems.

When I try to use it on 2.6 however I get the following error.

Traceback (most recent call last):
 File "./t_py_configuration.py", line 30, in ?
   from configuration import *
ImportError: ld.so.1: /usr/local/bin/python: fatal: relocation error: 
file ./.libs/configuration.so: symbol __ti7ostream: referenced symbol 
not found

I am using the same compiler version on both platforms. 2.95.3.

I have found a multitude of linking problems on the net all relating to 
people not using PIC etc. Everything is compiled with PIC and it all 
works on the 2.8 machine so I am at a loss to explain what is happening. 
I compile and build everything cleanly on each machine.

Has anyone seen this problem or kind of problem?

Any help is greatly appreciated.

Gary.






From david.abrahams at rcn.com  Wed May  1 02:25:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 30 Apr 2002 19:25:41 -0500
Subject: [C++-sig] linking problem
References: <3CCF31A6.2040607@itga.com.au>
Message-ID: <066701c1f0a7$661d85a0$6401a8c0@boostconsulting.com>

Two things to check:

1. (Likely problem) Is your C++ standard library .so in your
LD_LIBRARY_PATH?
2. (Possible non-issue) Which compiler was your python built with?

-Dave

----- Original Message -----
From: "Gary Hughes" <geh at itga.com.au>


> Hi,
>
> I posted this question of comp.lang.python but I haven't received any
> response, hopefully someone here can point me in the right direction.
>
> I have written an extension module that exposes a C++ class. I need to
> be able to build and run it on Solaris 2.6 and 2.8 with g++.
>
> The 2.8 build works with no problems.
>
> When I try to use it on 2.6 however I get the following error.
>
> Traceback (most recent call last):
>  File "./t_py_configuration.py", line 30, in ?
>    from configuration import *
> ImportError: ld.so.1: /usr/local/bin/python: fatal: relocation error:
> file ./.libs/configuration.so: symbol __ti7ostream: referenced symbol
> not found
>
> I am using the same compiler version on both platforms. 2.95.3.
>
> I have found a multitude of linking problems on the net all relating
to
> people not using PIC etc. Everything is compiled with PIC and it all
> works on the 2.8 machine so I am at a loss to explain what is
happening.
> I compile and build everything cleanly on each machine.
>
> Has anyone seen this problem or kind of problem?
>
> Any help is greatly appreciated.
>
> Gary.
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Wed May  1 03:38:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 30 Apr 2002 20:38:29 -0500
Subject: [C++-sig] V2: wrapping int/double bug(?)
References: <Pine.LNX.4.21.0204272023330.23424-100000@cens.ioc.ee>
Message-ID: <06f501c1f0b1$35eb8670$6401a8c0@boostconsulting.com>

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

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

That's almost true, but not quite.

> For example, if one defines (note the ordering of int and double
methods)
>
>   m.add(
>     boost::python::class_<GiNaC::ex>("ex")
>
>     .def_init(boost::python::args<int>())
>     .def_init(boost::python::args<double const>())

"const" is unneccessary above, and has no effect, FWIW.

>
> .def("__add__",ex_add_double)
> .def("__add__",ex_add_int)
>   );
>
> where
>
>   const GiNaC::ex ex_add_int(const GiNaC::ex& lh,int const rh);
>   const GiNaC::ex ex_add_double(const GiNaC::ex& lh,double const rh);
>
> then in python:
>
> >>> ex(2)
> ex(numeric('2'))
> >>> ex(2.3)
> ex(numeric('2'))   <--- bug: float was converted to int
> >>> ex(0)+2
> ex(numeric('2.0')) <--- bug: int was converted to float
> >>> ex(0)+2.3
> ex(numeric('2.2999999999999998224'))
>
> That is, definitions
>      .def_init(boost::python::args<double const>())
> and
>      .def("__add__",ex_add_int)
> are ignored.

They're not ignored, but the effect ends up being the same. The built-in
numeric type converters will convert any Python object whose type
implements __float__ to a double, and any object whose type implements
__int__ to an int. The builtin numeric types all implement these
methods:

>>> 3.14.__int__()
3
>>> x = 3
>>> x.__float__()
3.0

The overloading mechanism in Boost.Python is quite simple-minded: rather
than searching for some kind of "best match", it calls the first
function whose signature can match the argument list. In Boost.Python v1
this was never a problem, but the conversion rules were less-liberal.
It's possible that liberal conversion rules are just a mistake here, but
I'm inclined to think that a more-sophisticated overloading approach
akin to multimethods would be more appropriate, as I suggest in
libs/python/doc/v2/Mar2002.html#implicit_conversions. However, that
would be a nontrivial change and I'm not prepared to put it in my
development schedule at this time.

Would it be acceptable to simply use the versions of those functions
which accept double parameters, and skip the "int" versions?

-Dave







From terry at beam.demon.co.uk  Wed May  1 18:10:18 2002
From: terry at beam.demon.co.uk (Terry Barnaby)
Date: Wed, 01 May 2002 17:10:18 +0100
Subject: [C++-sig] How to create an arbitary Python Object from C/C++
Message-ID: <3CD0136A.3B5717CB@beam.demon.co.uk>

Hi,

I am trying to create a Python wrapper for a C++ class.
Most of this is working, but I am stumped on how to create an arbitary Python Object
of a Python user defined class.

I can create a Python object from a C++ class definition with "PyObject_New()", but
how do I create a Python object of class "PyRect" whoose definition and implemnation
is in Python ?

I cannot find this in any of the C/C++ interface documentation.

Any help would be appreciated.

Terry



--
  Dr Terry Barnaby                     BEAM Ltd
  Phone: +44 1454 324512               Northavon Business Center, Dean Rd
  Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
  Email: terry at beam.demon.co.uk        Web: www.beam.demon.co.uk
  BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev
                         "Tandems are twice the fun !"







From david.abrahams at rcn.com  Wed May  1 18:51:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 1 May 2002 11:51:28 -0500
Subject: [C++-sig] How to create an arbitary Python Object from C/C++
References: <3CD0136A.3B5717CB@beam.demon.co.uk>
Message-ID: <0f9901c1f130$a4a44dc0$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Terry Barnaby" <terry at beam.demon.co.uk>


> Hi,
>
> I am trying to create a Python wrapper for a C++ class.
> Most of this is working, but I am stumped on how to create an arbitary
Python Object
> of a Python user defined class.
>
> I can create a Python object from a C++ class definition with
"PyObject_New()", but
> how do I create a Python object of class "PyRect" whoose definition
and implemnation
> is in Python ?
>
> I cannot find this in any of the C/C++ interface documentation.

The usual method is to get the class object out of the module and "call"
it with the appropriate arguments for its __init__ function. If you're
using Boost.Python v1, you'll want to use
    boost::python::callback<PyObject*>::call(the_class, arg1, arg2...);

Regards,
Dave





From geh at itga.com.au  Thu May  2 00:55:28 2002
From: geh at itga.com.au (Gary Hughes)
Date: Thu, 02 May 2002 08:55:28 +1000
Subject: [C++-sig] linking problem
References: <3CCF31A6.2040607@itga.com.au> <066701c1f0a7$661d85a0$6401a8c0@boostconsulting.com>
Message-ID: <3CD07260.5000006@itga.com.au>

Thanks David,

No Luck yet, however, I have found some 'interesting' things on the 2.6 
machine in regards to the compiler and linker versions etc. I'll let you 
know how I go.

Gary.

David Abrahams wrote:

>Two things to check:
>
>1. (Likely problem) Is your C++ standard library .so in your
>LD_LIBRARY_PATH?
>2. (Possible non-issue) Which compiler was your python built with?
>
>-Dave
>
>----- Original Message -----
>From: "Gary Hughes" <geh at itga.com.au>
>
>
>>Hi,
>>
>>I posted this question of comp.lang.python but I haven't received any
>>response, hopefully someone here can point me in the right direction.
>>
>>I have written an extension module that exposes a C++ class. I need to
>>be able to build and run it on Solaris 2.6 and 2.8 with g++.
>>
>>The 2.8 build works with no problems.
>>
>>When I try to use it on 2.6 however I get the following error.
>>
>>Traceback (most recent call last):
>> File "./t_py_configuration.py", line 30, in ?
>>   from configuration import *
>>ImportError: ld.so.1: /usr/local/bin/python: fatal: relocation error:
>>file ./.libs/configuration.so: symbol __ti7ostream: referenced symbol
>>not found
>>
>>I am using the same compiler version on both platforms. 2.95.3.
>>
>>I have found a multitude of linking problems on the net all relating
>>
>to
>
>>people not using PIC etc. Everything is compiled with PIC and it all
>>works on the 2.8 machine so I am at a loss to explain what is
>>
>happening.
>
>>I compile and build everything cleanly on each machine.
>>
>>Has anyone seen this problem or kind of problem?
>>
>>Any help is greatly appreciated.
>>
>>Gary.
>>
>>
>>
>>
>>_______________________________________________
>>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 terry at beam.demon.co.uk  Thu May  2 10:34:43 2002
From: terry at beam.demon.co.uk (Terry Barnaby)
Date: Thu, 02 May 2002 09:34:43 +0100
Subject: [C++-sig] How to create an arbitary Python Object from C/C++
References: <3CD0136A.3B5717CB@beam.demon.co.uk> <0f9901c1f130$a4a44dc0$6401a8c0@boostconsulting.com>
Message-ID: <3CD0FA23.CABFCC07@beam.demon.co.uk>

Hi David,

Thanks for the response.
How do I get the class object out of the module.
Say the module is "bdb" and the class is "BDatabase" ?

Cheers

Terry

David Abrahams wrote:

> ----- Original Message -----
> From: "Terry Barnaby" <terry at beam.demon.co.uk>
>
> > Hi,
> >
> > I am trying to create a Python wrapper for a C++ class.
> > Most of this is working, but I am stumped on how to create an arbitary
> Python Object
> > of a Python user defined class.
> >
> > I can create a Python object from a C++ class definition with
> "PyObject_New()", but
> > how do I create a Python object of class "PyRect" whoose definition
> and implemnation
> > is in Python ?
> >
> > I cannot find this in any of the C/C++ interface documentation.
>
> The usual method is to get the class object out of the module and "call"
> it with the appropriate arguments for its __init__ function. If you're
> using Boost.Python v1, you'll want to use
>     boost::python::callback<PyObject*>::call(the_class, arg1, arg2...);
>
> Regards,
> Dave
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig

--
  Dr Terry Barnaby                     BEAM Ltd
  Phone: +44 1454 324512               Northavon Business Center, Dean Rd
  Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
  Email: terry at beam.demon.co.uk        Web: www.beam.demon.co.uk
  BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev
                         "Tandems are twice the fun !"







From david.abrahams at rcn.com  Thu May  2 12:58:12 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 2 May 2002 05:58:12 -0500
Subject: [C++-sig] How to create an arbitary Python Object from C/C++
References: <3CD0136A.3B5717CB@beam.demon.co.uk> <0f9901c1f130$a4a44dc0$6401a8c0@boostconsulting.com> <3CD0FA23.CABFCC07@beam.demon.co.uk>
Message-ID: <138901c1f1c8$67af4ee0$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Terry Barnaby" <terry at beam.demon.co.uk>


> Hi David,
>
> Thanks for the response.
> How do I get the class object out of the module.
> Say the module is "bdb" and the class is "BDatabase" ?

This is straightforward Python "C" API. RTFM for how to get ahold of a
loaded module object. Then:

    PyObject* bdb = Py_SomeCallWhichLoadsAModule("bdb");
    PyObject* BDatabase = PyObject_GetAttrString(bdb, "BDatabase");
    ...

HTH,
Dave






From david.abrahams at rcn.com  Sat May  4 00:18:11 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 3 May 2002 17:18:11 -0500
Subject: [C++-sig] Boost.Python: April 2002 Progress Report
Message-ID: <088101c1f2f1$03c7cb30$6401a8c0@boostconsulting.com>

The April 2002 Progress report is available in the boost CVS at
libs/python/doc/v2/Apr2002.html, or online at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/li
bs/python/doc/v2/Apr2002.html?rev=HEAD&content-type=text/html.

Regards,
Dave

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





From david.abrahams at rcn.com  Sun May  5 23:30:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 5 May 2002 16:30:39 -0500
Subject: [C++-sig] Re: python and C++?
Message-ID: <00e901c1f47c$30cc4520$6501a8c0@boostconsulting.com>

"Totte Karlsson" <mtk at u.washington.edu> wrote in message
news:ab42mt$2ati$1 at nntp6.u.washington.edu...
> Thanks I'll test boost,
> How about SWIG? is boost preferable? any opinions?

SWIG's approach is very different. Being the designer of Boost.Python, I'll
let others comment on what's preferable. My sense is that SWIG has very
different strengths.

> I read that you can't wrap C++ functions which return pointers? sounds
like
> a big limitation to me. My classes return pointers all the time.. is there
a
> workaround?
> I want to use the simplest and most versatile..

Boost.Python v2 supports pointer return types, but that's still in a
pre-release phase, mostly due to missing documentation. Several people are
using it successfully to wrap major C++ projects. I can help you get started
with that, if you like.

To look at Boost.Python v2, get the current boost CVS state and examine

$(BOOST_ROOT)/libs/python/doc/v2

Examples are available in the following files located at

$(BOOST_ROOT)/libs/python/test

newtest.py m1.cpp m2.cpp
test_builtin_converters.py test_builtin_converters.cpp
test_pointer_adoption.[py/cpp]
callbacks.[py/cpp]
virtual_functions.[py/cpp]
bpl-test back_reference.[py/cpp]
bpl-test implicit.[py/cpp]
bpl-test data_members.[py/cpp]

In Boost.Python v2, the object referenced by a returned pointer is copied by
default, but you can instead create a Python object which holds a reference
to any of the wrapped function's arguments to keep the pointee alive.

-Dave

> /totte
>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:ab3mgb$mgc$1 at bob.news.rcn.net...
> >
> > "Totte Karlsson" <mtk at u.washington.edu> wrote in message
> > news:ab1r85$1u8s$1 at nntp6.u.washington.edu...
> > > Hi,
> > > Is there any good texts about how to interface to a windows dll with
> > python?
> > > I'm a total beginner of python.
> > > I'm a C++ programmer and what I want is to make a DLL and interface to
> > that
> > > one with python.
> > > Say for example, I have a C++ class, called mtkMatrix. Is it then
> possible
> > > to allocate a mtkMatrix in a python script and acess its class member
> > > functions?
> > > thanks
> > > /totte
> >
> > Boost.Python was specifically designed to address your needs
> > (www.boost.org/libs/python/doc/). If you need help getting started,
please
> > direct further questions to the C++-sig:
> > http://www.python.org/sigs/c++-sig/.
> >
> > HTH,
> > Dave
> >
> > P.S. I strongly recommend using the latest boost CVS state
> > (http://sourceforge.net/cvs/?group_id=7586) rather than the current
> release
> > version.
> >
> >
>
>







From rwgk at yahoo.com  Mon May  6 11:53:12 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 May 2002 02:53:12 -0700 (PDT)
Subject: [C++-sig] Problems with Python's default dlopen flags
Message-ID: <20020506095312.54743.qmail@web20201.mail.yahoo.com>

There has been a lively discussion under the subject

"Problems with Python's default dlopen flags"

on the python-dev mailing list:
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/python-dev

This discussion seems more relevant for the Python C++ SIG
and I suggest to move it there.

There are some new findings. The context:

RedHat 7.1 on Intel
gcc 3.0.4
Python 2.2.1
boost cvs snapshot from a few minutes ago (~2AM PDT)
using a *shared* library libboost_python.so
     ((earlier postings referred to a statically linked library;
       however, in the future only the shared library situation is
       relevant))

I made two very simple extension modules ext1.so and ext2.so that both
link against libboost_python.so. Each extension module has exactly one
simple function, "accept_positive" and "accept_negative", respectively.
If the integer value passed is not positive or negative, respectively,
an IndexError is thrown. One complete example (ext1.cpp) is attached,
as well as the details about compilation and runtime behavior.

An illustration of the dependencies (thanks, David):

        python
       /      \
   (dlopen) (dlopen)
     /          \
    |           |
    V           V
  ext1.so   ext2.so
     \         /
     (ld)    (ld)
       \     /
        \   /
        |  |
        V  V
   libboost_python.so

Findings:

1. Using RTLD_LOCAL:
   An exception thrown in ext1.so is only caught correctly in
   libboost_python.so if ext1.so is imported first.
   An exception thrown in ext2.so is only caught correctly in
   libboost_python.so if ext2.so is imported first.

2. Using RTLD_GLOBAL:
   Exception handling works as desired.

Questions:

Does that mean we have to use RTLD_GLOBAL for modules compiled with
gcc 3.0.4, or is there an alternative?

What can we expect from gcc 2.95.4?

What can we expect from gcc 3.1?

If we have to work with RTLD_GLOBAL, are there user-friendly approaches?
I am thinking of something that is not more cumbersome than, e.g.:
from package.subpackage import ext1 as e1 # using RTLD_LOCAL
from package.subpackage import_global ext1 as e1 # using RTLD_GLOBAL

Any insight is very much appreciated. Special thanks to MvL for the
very helpful messages.

Ralf
   

Details:

I have compiled the modules with the Boost.Build system.
Here are simplified compile and link lines that produce identical
runtime behavior:

g++ -fPIC -ftemplate-depth-50 -DNDEBUG -DBOOST_PYTHON_DYNAMIC_LIB -w -g
-I<snip>/boost -I<snip>/python2.2 -c classes.cpp

g++ -shared -Wl,-E -o libboost_python.so classes.o <snip> cross_module.o
g++ -shared -Wl,-E -o ext1.so ext1module.o -L<snip>/lib -lboost_python -lm

The runtime behavior does not change if I omit -Wl,-E.

Consider this simple Python script:

import sys
sys.setdlopenflags(0x100|0x2)
import ext1
import ext2
try: ext1.accept_positive(-1)
except IndexError:
  print "OK 1"
try: ext2.accept_negative(+1)
except IndexError:
  print "OK 2"

Output from the script as shown:

OK 1
OK 2

Output if the setdlopenflags statement is removed:

OK 1
Traceback (most recent call last):
  File "tst_exts.py", line 8, in ?
    try: ext2.accept_negative(+1)
RuntimeError: unidentifiable C++ exception

Output if the setdlopenflags statement is removed and the order
of the import statements is reversed:

Traceback (most recent call last):
  File "tst_exts.py", line 5, in ?
    try: ext1.accept_positive(-1)
RuntimeError: unidentifiable C++ exception



ext1.cpp:

#include <boost/python/class_builder.hpp>
namespace {
  void accept_positive(int i) {
    if (i < 0) {
      PyErr_SetString(PyExc_IndexError, "Not positive.");
      throw boost::python::error_already_set();
    }
  }
}
BOOST_PYTHON_MODULE_INIT(ext1)
{
  boost::python::module_builder this_module("ext1");
  this_module.def(accept_positive, "accept_positive");
}


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com




From david.abrahams at rcn.com  Tue May  7 19:19:00 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 7 May 2002 12:19:00 -0500
Subject: [C++-sig] Re: python and C++?
References: <ELEPIPGJIHFDDPCNLOEJIEDKCIAA.mtk50@home.com>
Message-ID: <085601c1f5eb$c4eb7710$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Totte Karlsson" <mtk50 at home.com>


> Hi,
> Help with getting started wrapping the library with boost would be very
much
> appreciated!

Please ask your questions on the C++-sig, as I requested earlier
(www.python.org/sigs/c++-sig).

> However, before that I have some additional questions. Maybe I need to
> change some stuff in my library.
>
> 1) My libraries links to some other rather big C++ libraries. How will
that
> be handled? I have the headers and dll.s and lib files for these
libraries.
> Is that enough?

Yes, provided the interfaces are adequately documented.

> 2) I use templates in my code, is that supported?

You can't expose a template directly, since a template is just a recipe for
a class or function: all wrapping systems have this limitation.

> Which lead to the next question. Is STL supported?

The library interoperates well with STL, but there's no /specific/ support
that's directed at the STL. By 5/9 I'll have added some support for
*easily* exposing STL-style containers to Python so that they support the
new Python iterators. That means convenient access to:

    for x in my_container:
        ...

You can do that right now by defining the usual Python special functions
which enable it, but it's going to get more convenient.

> I use that a lot..(maybe this is answered
> somewhere in the documentation?)

I think others on the C++-sig who have experience with this may be able to
help you.

> 3) Documentation? will there be better documentation in the future? I
have
> looked at SWIG and it seems to be pretty well documented.

Yes, SWIG is /very/ well-documented. I am working mostly on the docs this
week, so the Boost.Python docs are going to be improving soon.

> 4) I'm using the Borland compiler. Is that OK?

No, if you're wedded to Borland you'd better stick with SWIG (or figure out
how to port Boost.Python). Borland's template engine is so broken that it
wasn't worth my effort to support it.

> regards
> totte
> ps: I'm kind of excited getting a python (or tcl or perl) interface. I
> realize I should have done that years ago! but I did not know that python
is
> pretty easy to learn.. which is nice!

;-D







From david.abrahams at rcn.com  Wed May  8 01:12:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 7 May 2002 18:12:46 -0500
Subject: [C++-sig] Boost.Python v2: char const*, char, and array conversions
Message-ID: <096b01c1f61d$54f8cac0$6501a8c0@boostconsulting.com>

Because of the importance of char const* as a representation for C-style
strings, we currently have a built-in lvalue converter from Python strings
to char const*. Reviewing Boost.Python's standard conversion rules at
www.boost.org/libs/python/doc/v2/feb2002.html#conversion, it's easy to see
that to get a char const* or char const* const&, we need to find an lvalue
converter for char. However, there are a few messy consequences:

1. a function which accepts char* (non-const) can accept arguments
   which are immutable Python strings. The C++ code can then modify
   the contents of the Python string.

2. a function which accepts char or char const& can also accept
   arguments which are Python strings. That's fine as far as it
   goes; we /do/ have a char lvalue there. However, there's no
   checking for value truncation. In other words, if I wrap:

      char g(char x) { return x; }

   I can call it thus from Python:

      >>> g('foobar')
      'f'

   This is not in keeping with the behavior of conversion to
   integral types, for example, which causes an exception when
   a floating point source value overflows.

The first problem above makes it clear to me that my prior conception that
"Python doesn't understand const-ness" was just wrong. What it doesn't
understand is the notion of a const reference to a non-const object: either
an object is mutable or it isn't. To solve it I propose to create the
notion of a "const lvalue converter". The new from_python table would then
look like:

Argument Type             Eligible Converters
-------------             -------------------
T                         T rvalue, T [const] lvalue
T const
T volatile
T const volatile
T const&

T const*                  T [const] lvalue
T const volatile*
T const volatile&
T const* const&
T const volatile*const&

T*                        T non-const lvalue
T volatile*
T&
T volatile&
T* const&
T volatile*const&

[const] means both const and non-const above

I'm not sure what the best approach for problem #2 is. The issue here is
that char is unlike other types: the availability of a char lvalue (at
least an immutable one) usually means there's an array, and further that
the length of the array can be determined by looking at its elements! One
possibility would be to special-case the rule for char, so that when the
C++ argument doesn't require an lvalue we explicitly check to see that it
is not a Python string whose length != 1.

However, the above approach is specific to the combination C++ char/Python
string. It wouldn't even work with a user-defined type containing
null-terminated char* strings. Thinking a little further, it could be
generalized to add a new kind of lvalue converter: the sequence converter.
A sequence converter would have to be able to report the end of the
sequence. A T sequence converter would only be eligible for matching a T
argument from the first group if the sequence's length were 1. That would
prevent the 'foobar'->'f' truncation above in a more general way. It could
also form the basis of a future feature which allows us to wrap functions
accepting iterator ranges and (iterator,length) pairs by converting a
single Python sequence argument into multiple C++ arguments. As I learned
to my utter "oh, cool!"-ness at the Python10 conference, SWIG supports this
sort of thing.

So then the table becomes:

Argument Type             Eligible Converters
-------------             -------------------
T                         T rvalue, T [const] lvalue, T [const] seq(1)
T const
T volatile
T const volatile
T const&

T const*                  T [const] lvalue, T [const] seq
T const volatile*
T const volatile&
T const* const&
T const volatile*const&

T volatile*               T non-const lvalue, T non-const seq
T&
T volatile&
T* const&
T volatile*const&


Thoughts?

-Dave


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





From martin at v.loewis.de  Wed May  8 07:22:16 2002
From: martin at v.loewis.de (Martin v. Loewis)
Date: 08 May 2002 07:22:16 +0200
Subject: [C++-sig] Re: Problems with Python's default dlopen flags
In-Reply-To: <20020506095312.54743.qmail@web20201.mail.yahoo.com>
References: <20020506095312.54743.qmail@web20201.mail.yahoo.com>
Message-ID: <m3r8kn6won.fsf@mira.informatik.hu-berlin.de>

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

> Any insight is very much appreciated.

Looking at your example gcc_dl_eh: Can you please try to not define
the worker_error dtor inline? I.e. implement it in libcore.cpp
instead; I'd be curious whether this changes anything.

Regards,
Martin





From rwgk at yahoo.com  Wed May  8 20:23:02 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 8 May 2002 11:23:02 -0700 (PDT)
Subject: [C++-sig] Re: other/6602: GCC/Linux shared lib + EH bug example
Message-ID: <20020508182302.57515.qmail@web20210.mail.yahoo.com>

Martin v. Loewis wrote:
> Looking at your example gcc_dl_eh: Can you please try to not define
> the worker_error dtor inline? I.e. implement it in libcore.cpp
> instead; I'd be curious whether this changes anything.

It does not change the outcome. See attached.
Thanks,
        Ralf

% make
gcc -g -c master.c
gcc -o master master.o -ldl
g++ -g -c ext1.cpp
g++ -g -c libcore.cpp
g++ -shared -Wl,-E -o libcore.so libcore.o
g++ -shared -Wl,-E -o ext1.so ext1.o libcore.so
g++ -g -c ext2.cpp
g++ -shared -Wl,-E -o ext2.so ext2.o libcore.so
*********************************************************
LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master G 1
dlopen flag: RTLD_GLOBAL
init_ext1
init_ext2
run1
  mycore::dispatcher
    ext1::worker
      now throwing worker_error()
    success catching worker_error
run2
  mycore::dispatcher
    ext2::worker
      now throwing worker_error()
    success catching worker_error

*********************************************************
LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master G 2
dlopen flag: RTLD_GLOBAL
init_ext2
init_ext1
run1
  mycore::dispatcher
    ext1::worker
      now throwing worker_error()
    success catching worker_error
run2
  mycore::dispatcher
    ext2::worker
      now throwing worker_error()
    success catching worker_error

*********************************************************
LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master L 1
dlopen flag: RTLD_LOCAL
init_ext1
init_ext2
run1
  mycore::dispatcher
    ext1::worker
      now throwing worker_error()
    success catching worker_error
run2
  mycore::dispatcher
    ext2::worker
      now throwing worker_error()
    #################################
    #                               #
    # FAILURE catching worker_error #
    #                               #
    #################################

*********************************************************
LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master L 2
dlopen flag: RTLD_LOCAL
init_ext2
init_ext1
run1
  mycore::dispatcher
    ext1::worker
      now throwing worker_error()
    #################################
    #                               #
    # FAILURE catching worker_error #
    #                               #
    #################################
run2
  mycore::dispatcher
    ext2::worker
      now throwing worker_error()
    success catching worker_error


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com




From whisper at oz.net  Thu May  9 18:07:20 2002
From: whisper at oz.net (David LeBlanc)
Date: Thu, 9 May 2002 09:07:20 -0700
Subject: [C++-sig] Where to start...
Message-ID: <GCEDKONBLEFPPADDJCOEAEOMDAAA.whisper@oz.net>

I have the latest CVS Boost (5.9.2002 @ 09:00 PDT). I have python 2.2.1. I
have a C++ static library that i'd like to control from python, ideally by
creating a dll wrapping the C++ static library. I'd like to do all of this
on Windows with MSVC 6.0 sp3.

Where do I start?

Also, one bit that has me concerned is that some of the methods have
call-back arguments. Is it within the realm of possibility to structure
things such that those call-backs can be written in Python?

TIA,

David LeBlanc
Seattle, WA USA





From david.abrahams at rcn.com  Thu May  9 20:13:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 13:13:23 -0500
Subject: [C++-sig] Where to start...
References: <GCEDKONBLEFPPADDJCOEAEOMDAAA.whisper@oz.net>
Message-ID: <041e01c1f785$3675b7c0$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>


> I have the latest CVS Boost (5.9.2002 @ 09:00 PDT). I have python 2.2.1.
I
> have a C++ static library that i'd like to control from python, ideally
by
> creating a dll wrapping the C++ static library. I'd like to do all of
this
> on Windows with MSVC 6.0 sp3.

No guarantees with sp3. Sp4 probably works (earlier versions of the library
were tested with it), but SP5 is what we're testing with.

> Where do I start?

You have two options:

Boost.Python v1 - mature, but a dead branch. Depends on the presence of a
common bug in C++ many implementations. There will be no further
development after the upcoming boost release. If you build the "test"
target in libs/python/build using Boost.Build it will build and run some
tests for your platform. Docs are in libs/python/doc.

Boost.Python v2 - Still officially prerelease, but already in use for some
large projects. Better handling of references and pointers, better
cross-module support, nicer syntax, fully-conforming code. Build the "test"
target in libs/python/test to see it in operation. Docs are in
libs/python/doc/v2.

> Also, one bit that has me concerned is that some of the methods have
> call-back arguments. Is it within the realm of possibility to structure
> things such that those call-backs can be written in Python?

Definitely. For v1, see libs/python/doc/overriding.html. For v2, see
libs/python/doc/v2/callbacks.html (you'll need to update your CVS again).

HTH,
Dave






From david.abrahams at rcn.com  Thu May  9 21:38:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 14:38:02 -0500
Subject: [C++-sig] Boost release candidate branch
Message-ID: <04ec01c1f791$0f5fa6d0$8f01a8c0@boostconsulting.com>

Boost has now branched for the 1.28.0 release. This will be the last
official release of Boost.Python v1., targeted for Wednesday, May 15th.

During the time between now and the release date, Ralf and I will be making
v1 documentation updates on the RC_1_28_0 branch in libs/python/doc. We
will be concentrating on build instructions and a status update which
announces the upcoming replacement of v1 with v2. Links to the Boost.Build
documentation will be required; that development is /also/ proceeding on
the RC_1_28_0 branch during this period.

A tentative release date for Boost.Python v2 is Monday, June 3rd. At that
point we expect to have implemented all of the v1 features in v2. After the
v1 release I will create a branch tag in the CVS, and will remove the v1
source from the main trunk.

Regards,
Dave


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





From whisper at oz.net  Thu May  9 22:15:08 2002
From: whisper at oz.net (David LeBlanc)
Date: Thu, 9 May 2002 13:15:08 -0700
Subject: [C++-sig] Where to start...
In-Reply-To: <041e01c1f785$3675b7c0$8f01a8c0@boostconsulting.com>
Message-ID: <GCEDKONBLEFPPADDJCOEEEAGDBAA.whisper@oz.net>

David;

Thanks for your reply.

I would like some sort of guidance on where to actually start doing the
work... headers, python wrapper classes... ?

Also, I belatedly realized (right after copying CVS over the boost 2.0 d/l
install) that i'm not using any kind of tag when getting stuff out of CVS.
What do I need to do to get 2.0? It looks as though Win-CVS is using "HEAD"
as the -r tag, but i'm not positive of that.

I hope you won't mind my asking a bunch of questions - this thing i'm doing
is for a free/open source library.

TIA,

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Thursday, May 09, 2002 11:13
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Where to start...
>
>
>
> ----- Original Message -----
> From: "David LeBlanc" <whisper at oz.net>
>
>
> > I have the latest CVS Boost (5.9.2002 @ 09:00 PDT). I have python 2.2.1.
> I
> > have a C++ static library that i'd like to control from python, ideally
> by
> > creating a dll wrapping the C++ static library. I'd like to do all of
> this
> > on Windows with MSVC 6.0 sp3.
>
> No guarantees with sp3. Sp4 probably works (earlier versions of
> the library
> were tested with it), but SP5 is what we're testing with.
>
> > Where do I start?
>
> You have two options:
>
> Boost.Python v1 - mature, but a dead branch. Depends on the presence of a
> common bug in C++ many implementations. There will be no further
> development after the upcoming boost release. If you build the "test"
> target in libs/python/build using Boost.Build it will build and run some
> tests for your platform. Docs are in libs/python/doc.
>
> Boost.Python v2 - Still officially prerelease, but already in use for some
> large projects. Better handling of references and pointers, better
> cross-module support, nicer syntax, fully-conforming code. Build
> the "test"
> target in libs/python/test to see it in operation. Docs are in
> libs/python/doc/v2.
>
> > Also, one bit that has me concerned is that some of the methods have
> > call-back arguments. Is it within the realm of possibility to structure
> > things such that those call-backs can be written in Python?
>
> Definitely. For v1, see libs/python/doc/overriding.html. For v2, see
> libs/python/doc/v2/callbacks.html (you'll need to update your CVS again).
>
> HTH,
> Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Thu May  9 22:28:48 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 15:28:48 -0500
Subject: [C++-sig] Where to start...
References: <GCEDKONBLEFPPADDJCOEEEAGDBAA.whisper@oz.net>
Message-ID: <053401c1f798$74674860$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>

> Thanks for your reply.

Sure!

> I would like some sort of guidance on where to actually start doing the
> work... headers, python wrapper classes... ?

Not sure what you mean by this. Boost.Python is designed to be
non-intrusive on your design, so your wrapping code should not usually
require you to change anything about the code you're wrapping.

> Also, I belatedly realized (right after copying CVS over the boost 2.0
d/l
> install) that i'm not using any kind of tag when getting stuff out of
CVS.
> What do I need to do to get 2.0? It looks as though Win-CVS is using
"HEAD"
> as the -r tag, but i'm not positive of that.

Boost.Python v2 is mixed into the main trunk of CVS (==HEAD) alongside v1,
though as I mentioned elsewhere you'll need the mpl-development branch of
boost/mpl.

> I hope you won't mind my asking a bunch of questions - this thing i'm
doing
> is for a free/open source library.

I don't mind; I'll do my best to answer. I hope anyone else who's watching
will also feel free to pipe up with answers, though ;-)

-Dave






From david.abrahams at rcn.com  Thu May  9 22:32:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 15:32:08 -0500
Subject: [C++-sig] C++-sig newsgroup!
Message-ID: <abemht$mhq$1@main.gmane.org>

I just discovered that this list is carried as a newsgroup at www.gmane.com!
See news://news.gmane.org/gmane.comp.python.c++

Regards,
Dave

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








From whisper at oz.net  Thu May  9 23:52:03 2002
From: whisper at oz.net (David LeBlanc)
Date: Thu, 9 May 2002 14:52:03 -0700
Subject: [C++-sig] Where to start...
In-Reply-To: <053401c1f798$74674860$8f01a8c0@boostconsulting.com>
Message-ID: <GCEDKONBLEFPPADDJCOEOEBBDBAA.whisper@oz.net>

Ok, sorry for being dense. I'll read some more doc and see if that inspires
me.

Firstly, I am using VC6sp5.

I don't recall your having mentioned boost/mpl; what is it?
"mpl-development" is not one of the -r tags listed by WinCVS for boost (I
assume that WinCVS gets the list of tags out of CVS). The listed tags are
HEAD, "branch-release-1-0", 1.6.2.4, and 1.1. Usually, I just click on
"update" without selecting any -r tag at all.

As for where to start, I'll get back to you after I figure out which version
of boost i'm using or supposed to be using etc. and get it recompiled
(hopefully, I can remember how I did it the first time).

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Thursday, May 09, 2002 13:29
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Where to start...
>
>
>
> ----- Original Message -----
> From: "David LeBlanc" <whisper at oz.net>
>
> > Thanks for your reply.
>
> Sure!
>
> > I would like some sort of guidance on where to actually start doing the
> > work... headers, python wrapper classes... ?
>
> Not sure what you mean by this. Boost.Python is designed to be
> non-intrusive on your design, so your wrapping code should not usually
> require you to change anything about the code you're wrapping.
>
> > Also, I belatedly realized (right after copying CVS over the boost 2.0
> d/l
> > install) that i'm not using any kind of tag when getting stuff out of
> CVS.
> > What do I need to do to get 2.0? It looks as though Win-CVS is using
> "HEAD"
> > as the -r tag, but i'm not positive of that.
>
> Boost.Python v2 is mixed into the main trunk of CVS (==HEAD) alongside v1,
> though as I mentioned elsewhere you'll need the mpl-development branch of
> boost/mpl.
>
> > I hope you won't mind my asking a bunch of questions - this thing i'm
> doing
> > is for a free/open source library.
>
> I don't mind; I'll do my best to answer. I hope anyone else who's watching
> will also feel free to pipe up with answers, though ;-)
>
> -Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Thu May  9 23:56:19 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 16:56:19 -0500
Subject: [C++-sig] Where to start...
References: <GCEDKONBLEFPPADDJCOEOEBBDBAA.whisper@oz.net>
Message-ID: <05bf01c1f7a4$5c1d8420$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>


> Ok, sorry for being dense. I'll read some more doc and see if that
inspires
> me.
>
> Firstly, I am using VC6sp5.
>
> I don't recall your having mentioned boost/mpl; what is it?

Uh, it looks like the message didn't get posted yet.
MPL is the pre-release Boost MetaProgramming Library.

> "mpl-development" is not one of the -r tags listed by WinCVS for boost (I
> assume that WinCVS gets the list of tags out of CVS). The listed tags are
> HEAD, "branch-release-1-0", 1.6.2.4, and 1.1. Usually, I just click on
> "update" without selecting any -r tag at all.

Don't listen to WinCVS, then. Trust me, I know what I'm talking about. You
may need to learn to use command-line cvs in order to get this. From the
boost root directory:

    cvs update -rmpl-development boost/mpl

-Dave





From david.abrahams at rcn.com  Thu May  9 20:46:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 13:46:26 -0500
Subject: [C++-sig] Where to start...
References: <GCEDKONBLEFPPADDJCOEAEOMDAAA.whisper@oz.net> <041e01c1f785$3675b7c0$8f01a8c0@boostconsulting.com>
Message-ID: <045d01c1f789$d736d640$8f01a8c0@boostconsulting.com>

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

> Definitely. For v1, see libs/python/doc/overriding.html. For v2, see
> libs/python/doc/v2/callbacks.html (you'll need to update your CVS again).

I almost forgot,

for v2, you'll also want to get the mpl-development branch of
$(BOOST_ROOT)/boost/mpl from CVS. You'll need that to compile anything.

Regards,
Dave






From whisper at oz.net  Fri May 10 00:58:16 2002
From: whisper at oz.net (David LeBlanc)
Date: Thu, 9 May 2002 15:58:16 -0700
Subject: [C++-sig] Where to start...
In-Reply-To: <05bf01c1f7a4$5c1d8420$8f01a8c0@boostconsulting.com>
Message-ID: <GCEDKONBLEFPPADDJCOEMEBIDBAA.whisper@oz.net>

Using CVS 1.11 command line client:

I set cvsroot.

I did cvs login with no password and it came back without compliant.

I did cvs update -rmpl-development boost/mpl in l:\cvs\boost as you
specified, and it came back virtually instantly without doing anything.

I also tried again to update the boost project with "create missing
directories that exist in the repository" checked, and that didn't do
anything either. I deleted the local boost repository and re-got it. Then I
re-updated it with "create missing directories that exist in the repository"
checked. Nadda.

I do notice that WinCVS is entering the l:\cvs\boost\boost\mpl directories,
but it's not getting anything out of them.

Aaaaaah! ... added "-d" to the above command line to "Build directories,
like checkout does" (as the cvs help said) and viola! t'worked!

(Also turns out that I could have entered the tag in the "-r" box in WinCVS
in lieu of picking one of the presented ones... <sigh>.)

Now if I can just get it to compile...

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Thursday, May 09, 2002 14:56
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Where to start...
>
>
>
> ----- Original Message -----
> From: "David LeBlanc" <whisper at oz.net>
>
>
> > Ok, sorry for being dense. I'll read some more doc and see if that
> inspires
> > me.
> >
> > Firstly, I am using VC6sp5.
> >
> > I don't recall your having mentioned boost/mpl; what is it?
>
> Uh, it looks like the message didn't get posted yet.
> MPL is the pre-release Boost MetaProgramming Library.
>
> > "mpl-development" is not one of the -r tags listed by WinCVS
> for boost (I
> > assume that WinCVS gets the list of tags out of CVS). The
> listed tags are
> > HEAD, "branch-release-1-0", 1.6.2.4, and 1.1. Usually, I just click on
> > "update" without selecting any -r tag at all.
>
> Don't listen to WinCVS, then. Trust me, I know what I'm talking about. You
> may need to learn to use command-line cvs in order to get this. From the
> boost root directory:
>
>     cvs update -rmpl-development boost/mpl
>
> -Dave
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From whisper at oz.net  Fri May 10 01:30:49 2002
From: whisper at oz.net (David LeBlanc)
Date: Thu, 9 May 2002 16:30:49 -0700
Subject: [C++-sig] 2 Problems in build
Message-ID: <GCEDKONBLEFPPADDJCOEAEBLDBAA.whisper@oz.net>

Jam does not seem to find the environment variables I set in the console
where I was trying to build boost. I found (as I recall finding before) that
I have to hand edit the python.jam and msvc-tools.jam files to point to the
actual location(s) of vc and python root directories before jam will do it's
thing.

I guess I did remember enough, since I got the debug version built and the
release version is building as I type. I'm curious to know what the fuss
is/was about mpl, since I don't see anything built with that name... ?

Regards,

David LeBlanc
Seattle, WA USA





From david.abrahams at rcn.com  Fri May 10 01:30:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 18:30:47 -0500
Subject: [C++-sig] 2 Problems in build
References: <GCEDKONBLEFPPADDJCOEAEBLDBAA.whisper@oz.net>
Message-ID: <05eb01c1f7b1$8dd47e30$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>


> Jam does not seem to find the environment variables I set in the console
> where I was trying to build boost.

That's a misdiagnosis of whatever problem you are having.

> I found (as I recall finding before) that
> I have to hand edit the python.jam and msvc-tools.jam files to point to
the
> actual location(s) of vc and python root directories before jam will do
it's
> thing.

I can't give you any support with building if you do it that way, though.

> I guess I did remember enough, since I got the debug version built and
the
> release version is building as I type. I'm curious to know what the fuss
> is/was about mpl, since I don't see anything built with that name... ?

What fuss?





From whisper at oz.net  Fri May 10 02:02:53 2002
From: whisper at oz.net (David LeBlanc)
Date: Thu, 9 May 2002 17:02:53 -0700
Subject: [C++-sig] 2 Problems in build
In-Reply-To: <05eb01c1f7b1$8dd47e30$8f01a8c0@boostconsulting.com>
Message-ID: <GCEDKONBLEFPPADDJCOEKEBNDBAA.whisper@oz.net>

mpl fuss: only that you said I needed it.

WRT the build problems, I did set all the environment variables as indicated
and yet, the defaults from the jam file where what jam displayed before it
massively failed on all the targets due to tools not being found. That
problem went away when I changed the defaults in the python and msvc-tools
jam files. I didn't/don't know what else to try.

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Thursday, May 09, 2002 16:31
> To: c++-sig at python.org
> Subject: Re: [C++-sig] 2 Problems in build
>
>
>
> ----- Original Message -----
> From: "David LeBlanc" <whisper at oz.net>
>
>
> > Jam does not seem to find the environment variables I set in the console
> > where I was trying to build boost.
>
> That's a misdiagnosis of whatever problem you are having.
>
> > I found (as I recall finding before) that
> > I have to hand edit the python.jam and msvc-tools.jam files to point to
> the
> > actual location(s) of vc and python root directories before jam will do
> it's
> > thing.
>
> I can't give you any support with building if you do it that way, though.
>
> > I guess I did remember enough, since I got the debug version built and
> the
> > release version is building as I type. I'm curious to know what the fuss
> > is/was about mpl, since I don't see anything built with that name... ?
>
> What fuss?
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Fri May 10 02:19:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 9 May 2002 19:19:22 -0500
Subject: [C++-sig] 2 Problems in build
References: <GCEDKONBLEFPPADDJCOEKEBNDBAA.whisper@oz.net>
Message-ID: <060601c1f7b8$8c382f20$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>


> mpl fuss: only that you said I needed it.

You do. If you don't have it, the build will fail.

> WRT the build problems, I did set all the environment variables as
indicated

as indicated where?

> and yet, the defaults from the jam file where what jam displayed before
it
> massively failed on all the targets due to tools not being found. That
> problem went away when I changed the defaults in the python and
msvc-tools
> jam files. I didn't/don't know what else to try.

My settings for MSVC are:

    set VISUALC=c:\tools\msvc6\vc98

You could also use the MSVC_ROOT variable for this purpose.

If MSVCDir is set, the toolset will assume that the MSVC bin directory is
in your path.

-Dave






From whisper at oz.net  Fri May 10 19:48:39 2002
From: whisper at oz.net (David LeBlanc)
Date: Fri, 10 May 2002 10:48:39 -0700
Subject: [C++-sig] 2 Problems in build
In-Reply-To: <060601c1f7b8$8c382f20$8f01a8c0@boostconsulting.com>
Message-ID: <GCEDKONBLEFPPADDJCOECEFEDBAA.whisper@oz.net>

I gather that mpl is something that is newly needed, since I didn't have it
a week ago when I last built Boost from CVS source.

I'm not able to find the exact information I used to decide which env vars
to set and i've also erased and reinstalled my build tree from CVS as of
yesterday, but iirc, they where JAM_TOOLSET=VISUALC and
VISUALC=/path/to/visualstudio/vc98. From the info put up by jam during a
build attempt and reading the relevent .jam files, I also figured out that
python_root and python_version are needed to be set as well. BTW, the
current build instructions on
http://www.boost.org/tools/build/index.html#Building don't mention either of
the python variables.


David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Thursday, May 09, 2002 17:19
> To: c++-sig at python.org
> Subject: Re: [C++-sig] 2 Problems in build
>
>
>
> ----- Original Message -----
> From: "David LeBlanc" <whisper at oz.net>
>
>
> > mpl fuss: only that you said I needed it.
>
> You do. If you don't have it, the build will fail.
>
> > WRT the build problems, I did set all the environment variables as
> indicated
>
> as indicated where?
>
> > and yet, the defaults from the jam file where what jam displayed before
> it
> > massively failed on all the targets due to tools not being found. That
> > problem went away when I changed the defaults in the python and
> msvc-tools
> > jam files. I didn't/don't know what else to try.
>
> My settings for MSVC are:
>
>     set VISUALC=c:\tools\msvc6\vc98
>
> You could also use the MSVC_ROOT variable for this purpose.
>
> If MSVCDir is set, the toolset will assume that the MSVC bin directory is
> in your path.
>
> -Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Fri May 10 22:18:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 10 May 2002 15:18:42 -0500
Subject: [C++-sig] 2 Problems in build
References: <GCEDKONBLEFPPADDJCOECEFEDBAA.whisper@oz.net>
Message-ID: <097601c1f860$5077ec70$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>
To: <c++-sig at python.org>
Sent: Friday, May 10, 2002 12:48 PM
Subject: RE: [C++-sig] 2 Problems in build


> I gather that mpl is something that is newly needed, since I didn't have
it
> a week ago when I last built Boost from CVS source.

You don't need it today, unless you're trying to build from the libs/python
or libs/python/test subdirectories. It's only needed for Boost.Python v2,
which is prerelease code.

> I'm not able to find the exact information I used to decide which env
vars
> to set and i've also erased and reinstalled my build tree from CVS as of
> yesterday, but iirc, they where JAM_TOOLSET=VISUALC and
> VISUALC=/path/to/visualstudio/vc98. From the info put up by jam during a
> build attempt and reading the relevent .jam files, I also figured out
that
> python_root and python_version are needed to be set as well.

I'm not sure what your aim is in posting the above info: are you asking for
help? Trying to help others?

> BTW, the
> current build instructions on
> http://www.boost.org/tools/build/index.html#Building don't mention either
of
> the python variables.

I realize that; we plan to update all of the build system docs before
1.28.0 goes out.

Thanks,
Dave






From whisper at oz.net  Fri May 10 22:44:49 2002
From: whisper at oz.net (David LeBlanc)
Date: Fri, 10 May 2002 13:44:49 -0700
Subject: [C++-sig] 2 Problems in build
In-Reply-To: <097601c1f860$5077ec70$8f01a8c0@boostconsulting.com>
Message-ID: <GCEDKONBLEFPPADDJCOEKEGGDBAA.whisper@oz.net>

> I'm not sure what your aim is in posting the above info: are you
> asking for
> help? Trying to help others?

You asked.

Re: build doc enhancements. Yes, please. I found it confusing to say the
least.

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Friday, May 10, 2002 13:19
> To: c++-sig at python.org
> Subject: Re: [C++-sig] 2 Problems in build
>
>
>
> ----- Original Message -----
> From: "David LeBlanc" <whisper at oz.net>
> To: <c++-sig at python.org>
> Sent: Friday, May 10, 2002 12:48 PM
> Subject: RE: [C++-sig] 2 Problems in build
>
>
<snip>

> > I'm not able to find the exact information I used to decide which env
> vars
> > to set and i've also erased and reinstalled my build tree from CVS as of
> > yesterday, but iirc, they where JAM_TOOLSET=VISUALC and
> > VISUALC=/path/to/visualstudio/vc98. From the info put up by jam during a
> > build attempt and reading the relevent .jam files, I also figured out
> that
> > python_root and python_version are needed to be set as well.
>
> I'm not sure what your aim is in posting the above info: are you
> asking for
> help? Trying to help others?
>
> > BTW, the
> > current build instructions on
> > http://www.boost.org/tools/build/index.html#Building don't
> mention either
> of
> > the python variables.
>
> I realize that; we plan to update all of the build system docs before
> 1.28.0 goes out.
>
> Thanks,
> Dave
>





From achim.domma at syynx.de  Sat May 11 16:57:07 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 11 May 2002 16:57:07 +0200
Subject: [C++-sig] version confusion
Message-ID: <abjb0m$20a$1@main.gmane.org>

Hi,

some weeks bevor, I gave up using the new version of boost.python due to
problems using jam. Today I started from scratch and was able to build the
cvs version of boost. But now I'm confused about which version I have !?
There is only one library, but it must be version 1, so how/where do I get
version 2 ? What are my next steps to play with version 2 ?

greetings
Achim

These are the steps to my success (hopefully helpfull to other windows user,
also not familiar with cvs, buildsystems and such things):

1. Using the cvs commands documented on the boost page I got a folder,
containing a (which ?) boost version. Here are the commands:
cvs -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost login
[Hit <return> when it asks for a password]
cvs -z3 -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
checkout boost
cvs -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost logout

2. I used vcvars32.bat to set the environment variables for the microsoft
compiler.

3. In boost_root/tools/build I build a new version of jam with: nmake -f
builds\win32-visualc.mk
I copied the executables together with the jam files to a folder which is in
my path.

4. I set PYTHON_VERSION and PYTHON_ROOT according to my system (2.2 and
c:\python2.2).

5. Calling bjam -sTOOLS=msvc -sBUILD=release I was finally able to build
boost !

After writing it down it looks quite easy, but for me it was hard to get the
single parts together. Thanks to Dave for all his help !!!








From david.abrahams at rcn.com  Sat May 11 17:23:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 11 May 2002 10:23:07 -0500
Subject: [C++-sig] version confusion
References: <abjb0m$20a$1@main.gmane.org>
Message-ID: <0a8901c1f8ff$c2ec2790$8f01a8c0@boostconsulting.com>

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

> Hi,
>
> some weeks bevor, I gave up using the new version of boost.python due to
> problems using jam. Today I started from scratch and was able to build
the
> cvs version of boost. But now I'm confused about which version I have !?

You have (most of) both. V1 and V2 coexist in the Boost CVS at the moment.

> There is only one library, but it must be version 1, so how/where do I
get
> version 2 ? What are my next steps to play with version 2 ?

update the boost/mpl directory on the mpl-development branch. From the
boost root:

  cvs update -rmpl-development boost/mpl

To build/run v2 and its tests, in libs/python/test invoke:

  bjam -sTOOLS=msvc test

The source files used in the tests show some examples of how the library
works. Look for the bpl-test rule invocations in libs/python/test/Jamfile,
from which the source file names should be obvious. The docs under
development are in libs/python/doc/v2.

HTH,
-Dave








From hidayet at candledreams.net  Sat May 11 18:22:38 2002
From: hidayet at candledreams.net (Okan AKALIN)
Date: Sat, 11 May 2002 19:22:38 +0300
Subject: [C++-sig] (no subject)
Message-ID: <003c01c1f908$1634d3e0$171762d4@blacklotus>

        Hi,
    Today I have downloaded Boost and compiled the Python
lib with MSVC++. The bpl_static.lib was successfuly built but when I try
to compile the examples, linker gave two 'unresolved external' errors. I 
noticed that I needed two functions from errors.cpp but when I included 
it in the project, it wouldn't compile. If you have any ideas [actually you
should have as there are so many people using it without any problems :)]
please help. Thanks!
    Okan AKALIN





From david.abrahams at rcn.com  Sat May 11 18:29:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 11 May 2002 11:29:17 -0500
Subject: [C++-sig] (no subject)
References: <003c01c1f908$1634d3e0$171762d4@blacklotus>
Message-ID: <0aa701c1f909$0eee6190$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "Okan AKALIN" <hidayet at candledreams.net>
To: <c++-sig at python.org>
Sent: Saturday, May 11, 2002 11:22 AM
Subject: [C++-sig] (no subject)


>         Hi,
>     Today I have downloaded Boost and compiled the Python
> lib with MSVC++. The bpl_static.lib was successfuly built but when I try
> to compile the examples, linker gave two 'unresolved external' errors. I
> noticed that I needed two functions from errors.cpp but when I included
> it in the project, it wouldn't compile. If you have any ideas [actually
you
> should have as there are so many people using it without any problems :)]
> please help. Thanks!
>     Okan AKALIN

bpl_static is no longer supported; Boost.Python is now a dynamic library.
Complete instructions for building in your configuration are here:

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







From achim.domma at syynx.de  Sat May 11 18:59:47 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 11 May 2002 18:59:47 +0200
Subject: [C++-sig] version confusion
In-Reply-To: <0a8901c1f8ff$c2ec2790$8f01a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEEGDFAA.achim.domma@syynx.de>

> To build/run v2 and its tests, in libs/python/test invoke:
>
>   bjam -sTOOLS=msvc test

It works fine so far, but I get one error. SP5 should be installed, but I
will checkt it again. Here's the error message:

vc-C++
..\..\..\libs\python\test\bin\select_from_python_test.exe\msvc\debug\runtime
-link-dynamic\select_from_python_test.obj
select_from_python_test.cpp
E:\cvsroot\boost\boost/python/converter/from_python.hpp(23) : error C2904:
'from_python' : template-name already defined as '<Unknown>'


    "cl"  /Zm400 -nologo -GX -c  -DBOOST_PYTHON_STATIC_LIB  /Z7 /Od /Ob0 /GX
/GR
/MDd   -I"..\..\..\libs\python\test" -I"." -I"E:\cvsroot\boost" -I"c:\python
22\include" -I"c:\python22\PC"  -I"D:\PROGRA~1\MICROS~2\VC98\include"   -Fo"
..\..\..\libs\python\test\bin\select_from_python_test.exe\msvc\debug\runtime
-link-dynamic\select_from_python_test.obj"  -Tp"select_from_python_test.cpp"

...failed vc-C++
..\..\..\libs\python\test\bin\select_from_python_test.exe\msvc\debug\runtime
-link-dynamic\select_from_python_test.obj...
...skipped
<libs!python!test\select_from_python_test.exe\msvc\debug\runtime-link-dynami
c>select_from_python_test.CMD for lack of
<libs!python!test\select_from_python_test.exe\msvc\debug\runtime-link-dynami
c>select_from_python_test.obj...
...skipped
<libs!python!test\select_from_python_test.exe\msvc\debug\runtime-link-dynami
c>select_from_python_test.exe for lack of
<libs!python!test\select_from_python_test.exe\msvc\debug\runtime-link-dynami
c>select_from_python_test.CMD...
...failed updating 1 target...
...skipped 2 targets...
...updated 12 targets...






From david.abrahams at rcn.com  Sat May 11 19:11:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 11 May 2002 12:11:07 -0500
Subject: [C++-sig] version confusion
References: <FCEMIEFBFOIDAOJDEPIAMEEGDFAA.achim.domma@syynx.de>
Message-ID: <0ac301c1f90e$e5ad1af0$8f01a8c0@boostconsulting.com>

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


> > To build/run v2 and its tests, in libs/python/test invoke:
> >
> >   bjam -sTOOLS=msvc test
>
> It works fine so far, but I get one error. SP5 should be installed, but I
> will checkt it again. Here's the error message:

...
Thanks for the report; that was a bug in the Jamfile. Now fixed in CVS.

-Dave





From achim.domma at syynx.de  Sun May 12 11:12:45 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 12 May 2002 11:12:45 +0200
Subject: [C++-sig] version confusion
In-Reply-To: <0ac301c1f90e$e5ad1af0$8f01a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIACEEMDFAA.achim.domma@syynx.de>

> > > To build/run v2 and its tests, in libs/python/test invoke:
> > >
> > >   bjam -sTOOLS=msvc test
> >
> > It works fine so far, but I get one error. SP5 should be 
> installed, but I
> > will checkt it again. Here's the error message:
> 
> ...
> Thanks for the report; that was a bug in the Jamfile. Now fixed in CVS.

It works fine now, thanks !

Achim






From achim.domma at syynx.de  Mon May 13 16:41:10 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Mon, 13 May 2002 16:41:10 +0200
Subject: [C++-sig] version confusion
In-Reply-To: <0a8901c1f8ff$c2ec2790$8f01a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIACEGDDFAA.achim.domma@syynx.de>

Hi Dave,

> The source files used in the tests show some examples of how the library
> works. Look for the bpl-test rule invocations in libs/python/test/Jamfile,
> from which the source file names should be obvious. The docs under
> development are in libs/python/doc/v2.

could you please provide a minimal (hello world like) example on how to
build an extension with jam ? I usually build my projects using an IDE, but
I would realy like to learn jam. But I think the bpl-test rule is not the
best place to start.

greetings
Achim






From david.abrahams at rcn.com  Mon May 13 16:58:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 13 May 2002 09:58:56 -0500
Subject: [C++-sig] Re: Python and debug STLport (was: Re: nocygwin toolset)
References: <001301c1f805$91a8faa0$0100a8c0@albert> <078801c1f80d$0fa8ab60$8f01a8c0@boostconsulting.com> <001e01c1fa70$93c70760$0100a8c0@albert>
Message-ID: <0fae01c1fa8f$13c94770$8f01a8c0@boostconsulting.com>

----- Original Message -----
From: "Raoul Gough" <RaoulGough at yahoo.co.uk>

...continued from an earlier jamboost posting...

> > > There is one remaining problem with python, but it only occurs in the
> > debug
> > > build. The module is question is
libs\python\example\simple_vector.cpp.
> > > Could it be something to do with vector iterator not being a pointer?
> > It's
> > > being compiled with STLport's debug STL via -D_STLP_DEBUG and
produces:
> > >
> > > d:/boost/CVS/boost/boost/python/caller.hpp: In function `static
struct
> > > PyObject * boost::python::caller<unsigned
> > > int>::call<_STL::__vector<double,_STL::allocator<double> > >(size_t
> > > (_STL::__vector<double,_STL::allocator<double> >::*)() const,
PyObject
> *,
> > > PyObject *)':
> > > d:/boost/CVS/boost/boost/python/detail/functions.hpp:73:
instantiated
> > from
> > > `boost::python::detail::wrapped_function_pointer<unsigned
int,unsigned
> > int
> > > (_STL::__vector<double,_STL:
> > > :allocator<double> >::*)() const>::do_call(PyObject *, PyObject *)
> const'
> > > f:/stlport/STLport-4.5.3/stlport/stl/debug/_iterator.h:153:
> > instantiated
> > > from hered:/boost/CVS/boost/boost/python/caller.hpp:232: no matching
> > > function for call to `from_python (PyObject *&,
> > > boost::python::type<_STL::__vector<double,_STL::allocator<double> >
&>)'
> >
> > I don't think so. Not sure what the problem is there.
>
> I think I've tracked this problem down. Here's an example which
demonstrates
> the limitation that is causing the problem with the STLport debug STL:
>
> -------------------
>
> #include <boost/python/class_builder.hpp>
> namespace python = boost::python;
>
> struct base
> {
>   int foo () const { return 0; }
> };
>
> struct derived : public base { };
>
> BOOST_PYTHON_MODULE_INIT(simple_vector)
> {
>   python::module_builder this_module("simple_vector");
>   python::class_builder<derived> builder (this_module, "derived");
>
>   builder.def (&derived::foo, "foo");   // Boom
> }
>
> --------------
>
> The type of &derived::foo is pointer to *base* member function - ummm, I
> guess you'd write this int (base::*)() const. Anyway, the compiler seems
to
> barf on this because class_builder was instantiated with derived, and it
> won't deal with a call to the base class member function (even with
public
> derivation). I don't understand enough about boost::python to say why
this
> should be.

Yep, I actually fixed this problem for Boost.Python v2. Doing it for all
the compilers I'm supporting proved to be really awful. See
boost/python/class.hpp and boost/python/detail/member_function_cast.hpp.
However, there are limitations to this approach: for one thing it means
that whenever a member function is being wrapped, the target class has to
be available. I sort of gave on this when it came to the new-style Python
iterator support I'm about to check in for v2, mostly because it would
complicate things too much.

> Now, the really unfortunate thing about this is that, when _STLP_DEBUG is
> defined, the STLport vector (_STL::vector) is actually derived from the
> otherwise non-existant _STL::__vector (these are the real identifiers
after
> macro expansions). This base class defines all the handy member
functions,
> so their types don't match the class builder which is, of course,
> instantiated with _STL::vector.

Yeah, I'm familiar with how that works, having written parts of it ;-)

> Close attention to the original error message actually does identify the
> problem: the "no matching function" error indicates that the actual type
> involves __vector and the long list of candidate functions has entries
> only for vector without the underscores. There seems to be an inherent
> incompatability between boost::python and at least some of the STLport
> containers in debug mode.

Naah, users can't portably take the address of standard library member
functions, in part so implementors can do things like this. However, you
can /non-portably/ do it with a cast to the appropriate target function
type (member function pointers implicitly convert down the inheritance
hierachy, so the cast is legal).

-Dave






From david.abrahams at rcn.com  Mon May 13 17:32:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 13 May 2002 10:32:34 -0500
Subject: [C++-sig] version confusion
References: <FCEMIEFBFOIDAOJDEPIACEGDDFAA.achim.domma@syynx.de>
Message-ID: <0fc801c1fa93$736fae40$8f01a8c0@boostconsulting.com>

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


> Hi Dave,
>
> > The source files used in the tests show some examples of how the
library
> > works. Look for the bpl-test rule invocations in
libs/python/test/Jamfile,
> > from which the source file names should be obvious. The docs under
> > development are in libs/python/doc/v2.
>
> could you please provide a minimal (hello world like) example on how to
> build an extension with jam ? I usually build my projects using an IDE,
but
> I would realy like to learn jam. But I think the bpl-test rule is not the
> best place to start.

Sure, Achim. The bpl-test rule does a lot of extra stuff. At the core of it
things are reall simple, though:

            extension $(m) : $(f) <dll>../bpl ;

Builds the extension named $(m) with the given files $(f), using the
Boost.Python v2 dynamic lib. The invocation:


    boost-python-runtest $(name) : $(py) <pyd>$(modules) ;

Builds an automated test for the extension(s) called $(modules) using the
python driver file called $(py).


A minimal Jamfile which does this sort of thing for v2 might be:

subproject libs/python/test ;

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

extension my_ext : my_cpp1.cpp my_cpp2.cpp <dll>../bpl
    : # any additional requirements, e.g. <define>MY_LIB
    ;

boost-python-runtest my_test : test_driver.py <pyd>my_ext ;

HTH,
Dave






From david.abrahams at rcn.com  Mon May 13 18:41:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 13 May 2002 11:41:44 -0500
Subject: [C++-sig] Boost.Python v2: iterator support
Message-ID: <101501c1fa9d$83962830$8f01a8c0@boostconsulting.com>

I have just checked in support for wrapping C++ iterators as Python
iterators to the Boost.Python v2 codebase. Please see
libs/python/test/iterator.[cpp/py] for some examples. Documentation will be
forthcoming.

-Dave

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





From pearu at cens.ioc.ee  Tue May 14 00:05:01 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 14 May 2002 01:05:01 +0300 (EEST)
Subject: [C++-sig] V2: wrapping int/double bug(?)
In-Reply-To: <06f501c1f0b1$35eb8670$6401a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205132230190.5773-100000@cens.ioc.ee>

On Tue, 30 Apr 2002, David Abrahams wrote:

<snip>

> > That is, definitions
> >      .def_init(boost::python::args<double const>())
> > and
> >      .def("__add__",ex_add_int)
> > are ignored.
> 
> They're not ignored, but the effect ends up being the same. The built-in
> numeric type converters will convert any Python object whose type
> implements __float__ to a double, and any object whose type implements
> __int__ to an int. The builtin numeric types all implement these
> methods:
> 
> >>> 3.14.__int__()
> 3
> >>> x = 3
> >>> x.__float__()
> 3.0
> 
> The overloading mechanism in Boost.Python is quite simple-minded: rather
> than searching for some kind of "best match", it calls the first
> function whose signature can match the argument list. In Boost.Python v1
> this was never a problem, but the conversion rules were less-liberal.

Actually, it was also a problem in Boost.Python v1 and then I solved this
issue by not using methods with int or float arguments but using
methods with PyObject* arguments and so avoiding the "smart" behaviour of
BPL and implementing conversion rules to my particular needs explicitly.

> It's possible that liberal conversion rules are just a mistake here, but

I think so too. At least there should be a way to disable them (see also
below).

> I'm inclined to think that a more-sophisticated overloading approach
> akin to multimethods would be more appropriate, as I suggest in
> libs/python/doc/v2/Mar2002.html#implicit_conversions. However, that
> would be a nontrivial change and I'm not prepared to put it in my
> development schedule at this time.

I don't know what is "CLOS-style multimethod.." (and therefore what
follows may be irrelevant) but I don't see how your suggestion would solve 
the problem in hand. That is, if a wrapped class A defines methods

 .foo(int)
 .foo(float)

and a class B has both __int__ and __float__ methods, then in Python

 A().foo(B())

how can you tell which method, __int__ or __float__, should be called when
doing conversion? E.g. take B=int and then take B=float.

In order to do it properly, at some point the responsible mechanism in BPL 
should check whether an instance B() has more an "int nature" or more a
"float nature". This is easy, in principle, if B is int or float (or
a subclass of int or float) but not obvious at all if B is, for example,
str or an user defined class that defines both __int__ and __float__
methods.

In addition, I would expect an exception in cases when there are
multiple choices in doing implicit conversions. Then, users are forced
to call, for example,

  A().foo(int(B()))

or

  A().foo(float(B()))

depending on their intention, explicitly.


Currently, I can workaround this by defining a single method

  .foo(PyObject*)

and explicitly checking whether an object is int or float and doing
the appropiate conversion in that method. This approach works fine with
methods with int/float arguments and I am happy with that.
 
BUT, there is a real problem with constructors. Namely, one cannot define
an additional constructor (that is needed for being more explicit with
conversions for the same reasons as discussed above for methods)

  A(PyObject*)

without introducing a lightweighted wrapper to a library class A.
And that approach is unacceptable because it would mean that all methods
(that I would like to use from Python) of A, must be re-wrapped as
well. In my particular case the number of relevant methods can be more
than 50 and therefore this lightweighted wrapper would get quite
"heavy". In addition, there are about ten additional classes from the same
library that I would like to wrap to Python. All these classes define
methods with arguments of each others instances and these methods may
return different instances, etc...

So, you can imagine that this approach (of introducing additional wrapper
classes for library classes because one needs a constructor
A(PyObject*) to work around the implicit conversion mechanism of
BPL, for instance, but not only -- see below about __init__
proposal) will lead to too complex interface.

Now, the question is whether it is possible to introduce additional
constructors to library classes without deriving a new class for that?
For example, if one has the following library class

class A {
  public:
    A(int);
    A(float);
}

then instead of the problematic case

 m.add(boost::python::class_<A>("A")
  .def_init(boost::python::args<int>())
  .def_init(boost::python::args<float>())
 );

one could define

 m.add(boost::python::class_<A>("A")
  .def("__init__",my_A_init)
 );

where

  A my_A_init(PyObject*);

What do you think? Would the above be possible in principle?

Notice that having an option of defining additional __init__ methods can
be useful in general, not only for this specific workaround of
the int/float issue.


> Would it be acceptable to simply use the versions of those functions
> which accept double parameters, and skip the "int" versions?

Unfortunatelly no. The library that I am trying to wrap does symbolic
algebraic calculations and it is crucial to keep "exact" and
"inexact" (but arbitrary precision) numbers separate.

Regards,
	Pearu

PS: Sorry for the late response.





From david.abrahams at rcn.com  Tue May 14 06:40:33 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 13 May 2002 23:40:33 -0500
Subject: [C++-sig] V2: wrapping int/double bug(?)
References: <Pine.LNX.4.21.0205132230190.5773-100000@cens.ioc.ee>
Message-ID: <00db01c1fb01$7cd64200$6601a8c0@boostconsulting.com>

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

> On Tue, 30 Apr 2002, David Abrahams wrote:
>
> <snip>
>
> > > That is, definitions
> > >      .def_init(boost::python::args<double const>())
> > > and
> > >      .def("__add__",ex_add_int)
> > > are ignored.
> >
> > They're not ignored, but the effect ends up being the same. The
built-in
> > numeric type converters will convert any Python object whose type
> > implements __float__ to a double, and any object whose type implements
> > __int__ to an int. The builtin numeric types all implement these
> > methods:
> >
> > >>> 3.14.__int__()
> > 3
> > >>> x = 3
> > >>> x.__float__()
> > 3.0
> >
> > The overloading mechanism in Boost.Python is quite simple-minded:
rather
> > than searching for some kind of "best match", it calls the first
> > function whose signature can match the argument list. In Boost.Python
v1
> > this was never a problem, but the conversion rules were less-liberal.
>
> Actually, it was also a problem in Boost.Python v1 and then I solved this
> issue by not using methods with int or float arguments but using
> methods with PyObject* arguments and so avoiding the "smart" behaviour of
> BPL and implementing conversion rules to my particular needs explicitly.

So, I take it there is a reason that a single overload using a double
argument doesn't suit your needs? I ask because in general it would seem
like a bad idea to implement different semantics for f(4) and f(4.0), and
doubles tend to be able to represent all the values of an integer.

> > It's possible that liberal conversion rules are just a mistake here,
but
>
> I think so too. At least there should be a way to disable them (see also
> below).

I'm not sure what I think, yet, but I'm leaning towards keeping them and
providing more-discriminating overload selection.

> > I'm inclined to think that a more-sophisticated overloading approach
> > akin to multimethods would be more appropriate, as I suggest in
> > libs/python/doc/v2/Mar2002.html#implicit_conversions. However, that
> > would be a nontrivial change and I'm not prepared to put it in my
> > development schedule at this time.
>
> I don't know what is "CLOS-style multimethod.." (and therefore what
> follows may be irrelevant)

Maybe. See http://www.sff.net/people/neelk/open-source/Multimethod.py for a
Python-oriented take.

> but I don't see how your suggestion would solve
> the problem in hand. That is, if a wrapped class A defines methods
>
>  .foo(int)
>  .foo(float)
>
> and a class B has both __int__ and __float__ methods, then in Python
>
>  A().foo(B())
>
> how can you tell which method, __int__ or __float__, should be called
when
> doing conversion? E.g. take B=int and then take B=float.

I assume you mean the cases where B() returns int or float. That's easy:
Python int would correspond most-closely to C++ int, and Python float would
correspond most-closely to C++ double.

> In order to do it properly, at some point the responsible mechanism in
BPL
> should check whether an instance B() has more an "int nature" or more a
> "float nature". This is easy, in principle, if B is int or float (or
> a subclass of int or float) but not obvious at all if B is, for example,
> str

neither the built-in function str() nor built-in strings have __int__ or
__float__ methods, so in that case there would be no match at all.

> or an user defined class that defines both __int__ and __float__
> methods.

In that case I would consider the call ambiguous.

> In addition, I would expect an exception in cases when there are
> multiple choices in doing implicit conversions. Then, users are forced
> to call, for example,
>
>   A().foo(int(B()))
>
> or
>
>   A().foo(float(B()))
>
> depending on their intention, explicitly.

I don't think it's neccessary to throw an exception any time there are
multiple choices, but in some cases I agree that it's the right solution.

> Currently, I can workaround this by defining a single method
>
>   .foo(PyObject*)
>
> and explicitly checking whether an object is int or float and doing
> the appropiate conversion in that method. This approach works fine with
> methods with int/float arguments and I am happy with that.

I'm not, though ;-)

> BUT, there is a real problem with constructors. Namely, one cannot define
> an additional constructor (that is needed for being more explicit with
> conversions for the same reasons as discussed above for methods)
>
>   A(PyObject*)
>
> without introducing a lightweighted wrapper to a library class A.

Well, of course there is a way, but it's not in the library's public
interface.

> And that approach is unacceptable because it would mean that all methods
> (that I would like to use from Python) of A, must be re-wrapped as
> well.

No, I don't think so. You only need to wrap them once in
class_<A,A_wrapper>. It's only constructors which need to be duplicated in
A_wrapper.

> In my particular case the number of relevant methods can be more
> than 50 and therefore this lightweighted wrapper would get quite
> "heavy".

I don't understand that part.

> In addition, there are about ten additional classes from the same
> library that I would like to wrap to Python. All these classes define
> methods with arguments of each others instances and these methods may
> return different instances, etc...

And I really don't understand what the problem is there.

> So, you can imagine that this approach (of introducing additional wrapper
> classes for library classes because one needs a constructor
> A(PyObject*) to work around the implicit conversion mechanism of
> BPL, for instance, but not only -- see below about __init__
> proposal) will lead to too complex interface.

I don't see, but I do feel that users shouldn't have to use PyObject* just
to properly resolve int/float overloads.

> Now, the question is whether it is possible to introduce additional
> constructors to library classes without deriving a new class for that?
> For example, if one has the following library class
>
> class A {
>   public:
>     A(int);
>     A(float);
> }
>
> then instead of the problematic case
>
>  m.add(boost::python::class_<A>("A")
>   .def_init(boost::python::args<int>())
>   .def_init(boost::python::args<float>())
>  );
>
> one could define
>
>  m.add(boost::python::class_<A>("A")
>   .def("__init__",my_A_init)
>  );
>
> where
>
>   A my_A_init(PyObject*);
>
> What do you think? Would the above be possible in principle?

In principle. my_A_init has to build and install a Holder; it can't just
return a new A copy... at least, that's the way the library works now.

> Notice that having an option of defining additional __init__ methods can
> be useful in general, not only for this specific workaround of
> the int/float issue.

Understood.

> > Would it be acceptable to simply use the versions of those functions
> > which accept double parameters, and skip the "int" versions?
>
> Unfortunatelly no. The library that I am trying to wrap does symbolic
> algebraic calculations and it is crucial to keep "exact" and
> "inexact" (but arbitrary precision) numbers separate.

I understand.






From pearu at cens.ioc.ee  Tue May 14 12:14:04 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 14 May 2002 13:14:04 +0300 (EEST)
Subject: [C++-sig] V2: wrapping int/double bug(?)
In-Reply-To: <00db01c1fb01$7cd64200$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205141122340.25998-100000@cens.ioc.ee>

On Mon, 13 May 2002, David Abrahams wrote:

> ----- Original Message -----
> From: "Pearu Peterson" <pearu at cens.ioc.ee>
>
> > Actually, it was also a problem in Boost.Python v1 and then I solved this
> > issue by not using methods with int or float arguments but using
> > methods with PyObject* arguments and so avoiding the "smart" behaviour of
> > BPL and implementing conversion rules to my particular needs explicitly.
> 
> So, I take it there is a reason that a single overload using a double
> argument doesn't suit your needs? 

Yes, there is. As I mentioned in my previous message, the library that I
am wrapping is a symbolic algebra library where floats are inexact and
ints are exact numbers, roughly speaking. Trivial example: if I'd used
only double argument constructor:

  numeric(double)

then in Python

  numeric(2)/3

becomes inexact

  0.66666666666666663

while the library is designed to handle the above ratio as an exact 
rational number

  2/3

If I'd used only int argument constructor

  numeric(int)

then in python

  numeric(2.4)

becomes wrong

  2

without any complaints.

> I ask because in general it would seem
> like a bad idea to implement different semantics for f(4) and f(4.0), and
> doubles tend to be able to represent all the values of an integer.

It depends on the application, I guess. In numerical applications
nobody represents integers by doubles for various reasons (efficiency,
accuracy, etc). I understand this can be feasible for a number of
applications that hardly deal with numerics or if they do then only with
floating point numerics. And therefore they don't care if int becomes
float.

> > I don't know what is "CLOS-style multimethod.." (and therefore what
> > follows may be irrelevant)
> 
> Maybe. See http://www.sff.net/people/neelk/open-source/Multimethod.py for a
> Python-oriented take.

Thanks for the reference.

> > but I don't see how your suggestion would solve
> > the problem in hand. That is, if a wrapped class A defines methods
> >
> >  .foo(int)
> >  .foo(float)
> >
> > and a class B has both __int__ and __float__ methods, then in Python
> >
> >  A().foo(B())
> >
> > how can you tell which method, __int__ or __float__, should be called
> when
> > doing conversion? E.g. take B=int and then take B=float.
> 
> I assume you mean the cases where B() returns int or float. 

No. I mean that B() is an instance of the class B that represents either
int or float, or can be transformed to one. Take, for example, B is
Rational, or an arbitrary precision number.

> That's easy: Python int would correspond most-closely to C++ int, and
> Python float would correspond most-closely to C++ double.

I agree. But BPL does not seem to agree with that ;-)

> > In order to do it properly, at some point the responsible mechanism in
> BPL
> > should check whether an instance B() has more an "int nature" or more a
> > "float nature". This is easy, in principle, if B is int or float (or
> > a subclass of int or float) but not obvious at all if B is, for example,
> > str
> 
> neither the built-in function str() nor built-in strings have __int__ or
> __float__ methods, so in that case there would be no match at all.

And yet

>>> float("2.3")
2.2999999999999998
>>> int("2")
2

so I didn't look in to details of how these numbers are constructed.
str was a bad example. Forget it.

> > or an user defined class that defines both __int__ and __float__
> > methods.
> 
> In that case I would consider the call ambiguous.

Which is exactly the case for Python int and float:

>>> int.__int__ 
<slot wrapper '__int__' of 'int' objects>
>>> int.__float__ 
<slot wrapper '__float__' of 'int' objects>
>>> float.__float__ 
<slot wrapper '__float__' of 'float' objects>
>>> float.__int__ 
<slot wrapper '__int__' of 'float' objects>

> > Currently, I can workaround this by defining a single method
> >
> >   .foo(PyObject*)
> >
> > and explicitly checking whether an object is int or float and doing
> > the appropiate conversion in that method. This approach works fine with
> > methods with int/float arguments and I am happy with that.
> 
> I'm not, though ;-)

Good.

> > BUT, there is a real problem with constructors. Namely, one cannot define
> > an additional constructor (that is needed for being more explicit with
> > conversions for the same reasons as discussed above for methods)
> >
> >   A(PyObject*)
> >
> > without introducing a lightweighted wrapper to a library class A.
> 
> Well, of course there is a way, but it's not in the library's public
> interface.

And that way might be far over my C++ head ;-)

> > And that approach is unacceptable because it would mean that all methods
> > (that I would like to use from Python) of A, must be re-wrapped as
> > well.
> 
> No, I don't think so. You only need to wrap them once in
> class_<A,A_wrapper>. It's only constructors which need to be duplicated in
> A_wrapper.

I tried that, but it didn't work out. I'll try to sketch the real
situation from my memory: the GiNaC library contains the following class
tree (only partially exposed here, see
  http://www.ginac.de/reference/hierarchy.html
for a complete tree):

class basic
  class symbol(basic)
  class numeric(basic)
  class expairseq(basic)
    class add(expairseq)
  ..

class ex /* this is an holder of basic's pointer and used to
            pass different basic instances to various methods
            as well as to return the results of calculations
          */

In the BPL based wrapper I did

  boost::python::module m("_ginac");
  m
    .add(
    	 boost::python::class_<GiNaC::ex>("ex")
	 .def_init(boost::python::args<const GiNaC::ex &>())
	 .def_init(boost::python::args<const GiNaC::basic &>())
         /* snip number of methods */
    )
    .add(boost::python::class_<GiNaC::basic>("_basic")
	 .def_init(boost::python::args<const GiNaC::basic &>())
         /* snip number of methods */
   );
   m
    .add(boost::python::class_<GiNaC::numeric,
	 boost::python::bases<GiNaC::basic> >("numeric")
	 .def_init(boost::python::args<const numeric &>())
         /* Wished to have
          .def_init(boost::python::args<int>())
          .def_init(boost::python::args<double>())
         */
         /* snip methods */
   )

It is not clear to me how to include

  class numeric_wrapper: public GiNaC::numeric {
    numeric_wrapper(PyObject*);
  }

into this tree. If I remember correctly then

    .add(boost::python::class_<GiNaC::numeric,
         boost::python::bases<GiNaC::basic, numeric_wrapper> >("numeric")
         .def_init(boost::python::args<const numeric &>())
         ...

didn't work because the constructor of numeric_wrapper was never called -
BPL seemed to forget the constructors of the parent classes (or again
choosed the first found match).

If the above still does not make sense, I'll try to produce a working
example of the above demonstrating my situation.

> > In my particular case the number of relevant methods can be more
> > than 50 and therefore this lightweighted wrapper would get quite
> > "heavy".
> 
> I don't understand that part.

I meant that I ended up with implementing methods like

  basic_add_basic
  basic_add_pyobj
  basic_add_ex
  basic_add_numeric
  ex_add_basic
  ex_add_pyobj
  ex_add_ex
  ex_add_numeric
  numeric_add_basic    /* Though numeric is derived from basic, its
  numeric_add_numeric     arithmetics is done in a different route */
  numeric_add_ex        
  numeric_add_py

Similarly for mul,div,sub,pow,etc.

And then I noticed that the size of the wrapper was becoming close to the
size of the library itself, which stopped me and made me doubt if
this approach is a good one.

> > Now, the question is whether it is possible to introduce additional
> > constructors to library classes without deriving a new class for that?
< snip >
> > What do you think? Would the above be possible in principle?
> 
> In principle. my_A_init has to build and install a Holder; it can't just
> return a new A copy... at least, that's the way the library works now.

Thanks for the hint. I'll try to figure out that if nothing else works.

still-not-convinced-that-bpl-cannot-wrap-real-libraries'ly yours

Pearu





From david.abrahams at rcn.com  Tue May 14 14:26:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 14 May 2002 07:26:56 -0500
Subject: [C++-sig] V2: wrapping int/double bug(?)
References: <Pine.LNX.4.21.0205141122340.25998-100000@cens.ioc.ee>
Message-ID: <013801c1fb42$a99a2770$6601a8c0@boostconsulting.com>

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

> Yes, there is. As I mentioned in my previous message, the library that I
> am wrapping is a symbolic algebra library where floats are inexact and
> ints are exact numbers, roughly speaking. Trivial example: if I'd used
> only double argument constructor:
>
<snip>

Thanks for the nice explanation. It always helps to understand the domain
my users are operating in.

> > I ask because in general it would seem
> > like a bad idea to implement different semantics for f(4) and f(4.0),
and
> > doubles tend to be able to represent all the values of an integer.
>
> It depends on the application, I guess. In numerical applications
> nobody represents integers by doubles for various reasons (efficiency,
> accuracy, etc).

I understand why you need this distinction in your application, but for
most I think efficiency of int->float conversion is a misplaced concern at
the Python/C++ boundary> I guess that on 64-bit machines an int doesn't fit
in the mantissa of a double.

> I understand this can be feasible for a number of
> applications that hardly deal with numerics or if they do then only with
> floating point numerics. And therefore they don't care if int becomes
> float.

Yeah, it's a pretty common model.

> > > but I don't see how your suggestion would solve
> > > the problem in hand. That is, if a wrapped class A defines methods
> > >
> > >  .foo(int)
> > >  .foo(float)
> > >
> > > and a class B has both __int__ and __float__ methods, then in Python
> > >
> > >  A().foo(B())
> > >
> > > how can you tell which method, __int__ or __float__, should be called
> > when
> > > doing conversion? E.g. take B=int and then take B=float.
> >
> > I assume you mean the cases where B() returns int or float.
>
> No. I mean that B() is an instance of the class B that represents either
> int or float

Oh, OK. But that case is easy.

> , or can be transformed to one.

As long as it can't be transformed into both, also easy. Even then, it's
easy because you just signal an ambiguity.

> Take, for example, B is
> Rational, or an arbitrary precision number.
>
> > That's easy: Python int would correspond most-closely to C++ int, and
> > Python float would correspond most-closely to C++ double.
>
> I agree. But BPL does not seem to agree with that ;-)

Yes; think of it as your next project ;-)

> > > In order to do it properly, at some point the responsible mechanism
in
> > BPL
> > > should check whether an instance B() has more an "int nature" or more
a
> > > "float nature". This is easy, in principle, if B is int or float (or
> > > a subclass of int or float) but not obvious at all if B is, for
example,
> > > str
> >
> > neither the built-in function str() nor built-in strings have __int__
or
> > __float__ methods, so in that case there would be no match at all.
>
> And yet
>
> >>> float("2.3")
> 2.2999999999999998
> >>> int("2")
> 2

Yes, that's the float/int types doing the work.

> so I didn't look in to details of how these numbers are constructed.
> str was a bad example. Forget it.

Done.

> > > or an user defined class that defines both __int__ and __float__
> > > methods.
> >
> > In that case I would consider the call ambiguous.
>
> Which is exactly the case for Python int and float:
>
> >>> int.__int__
> <slot wrapper '__int__' of 'int' objects>
> >>> int.__float__
> <slot wrapper '__float__' of 'int' objects>
> >>> float.__float__
> <slot wrapper '__float__' of 'float' objects>
> >>> float.__int__
> <slot wrapper '__int__' of 'float' objects>

When converting to integral argument types, I would use a rule which gave
priority to classes derived from Python int as arguments.


> > > And that approach is unacceptable because it would mean that all
methods
> > > (that I would like to use from Python) of A, must be re-wrapped as
> > > well.
> >
> > No, I don't think so. You only need to wrap them once in
> > class_<A,A_wrapper>. It's only constructors which need to be duplicated
in
> > A_wrapper.
>
> I tried that, but it didn't work out.

<snip>

> It is not clear to me how to include
>
>   class numeric_wrapper: public GiNaC::numeric {
>     numeric_wrapper(PyObject*);
>   }

You need an extra PyObject* argument in the constructor. The first one is
the self pointer, and you can ignore it if you like.

> into this tree. If I remember correctly then
>
>     .add(boost::python::class_<GiNaC::numeric,
>          boost::python::bases<GiNaC::basic, numeric_wrapper> >("numeric")
>          .def_init(boost::python::args<const numeric &>())
>          ...
>
> didn't work because the constructor of numeric_wrapper was never called -

Well, it also doesn't work because numeric_wrapper is not a base of
numeric, but a derived class!

You should follow the formula I described above:

    .add(boost::python::class_<GinaC::numeric, GiNaC::numeric_wrapper
                                >("numeric")
            .def_init(boost::python::args<PyObject*>())


See the documentation for class.hpp if you need an explanation of what's
happening here.


> I meant that I ended up with implementing methods like
>
>   basic_add_basic
>   basic_add_pyobj
>   basic_add_ex
>   basic_add_numeric
>   ex_add_basic
>   ex_add_pyobj
>   ex_add_ex
>   ex_add_numeric
>   numeric_add_basic    /* Though numeric is derived from basic, its
>   numeric_add_numeric     arithmetics is done in a different route */
>   numeric_add_ex
>   numeric_add_py
>
> Similarly for mul,div,sub,pow,etc.

Yikes. I am planning to implement simplified operator exposure this week; I
hope that helps you out.

> And then I noticed that the size of the wrapper was becoming close to the
> size of the library itself, which stopped me and made me doubt if
> this approach is a good one.

Yeah, if you have to mess around with PyObject*, the library isn't doing
you much good is it?

> > > Now, the question is whether it is possible to introduce additional
> > > constructors to library classes without deriving a new class for
that?
> < snip >
> > > What do you think? Would the above be possible in principle?
> >
> > In principle. my_A_init has to build and install a Holder; it can't
just
> > return a new A copy... at least, that's the way the library works now.
>
> Thanks for the hint. I'll try to figure out that if nothing else works.
>
> still-not-convinced-that-bpl-cannot-wrap-real-libraries'ly yours

Me neither, fortunately ;-)

-Dave





From pearu at cens.ioc.ee  Tue May 14 21:26:26 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 14 May 2002 22:26:26 +0300 (EEST)
Subject: [C++-sig] V2: wrapping int/double bug(?)
In-Reply-To: <013801c1fb42$a99a2770$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205142206570.4706-100000@cens.ioc.ee>

On Tue, 14 May 2002, David Abrahams wrote:

> You need an extra PyObject* argument in the constructor. The first one is
> the self pointer, and you can ignore it if you like.

Thanks! This was the detail that I was missing.

> > into this tree. If I remember correctly then
> >
> >     .add(boost::python::class_<GiNaC::numeric,
> >          boost::python::bases<GiNaC::basic, numeric_wrapper> >("numeric")
> >          .def_init(boost::python::args<const numeric &>())
> >          ...
> >
> > didn't work because the constructor of numeric_wrapper was never called -
> 
> Well, it also doesn't work because numeric_wrapper is not a base of
> numeric, but a derived class!
> 
> You should follow the formula I described above:
> 
>     .add(boost::python::class_<GinaC::numeric, GiNaC::numeric_wrapper
>                                 >("numeric")
>             .def_init(boost::python::args<PyObject*>())

Ok, that works. Thanks.

>>> numeric(2)
<ginac.numeric object at 0x81a0cfc>


But I also need that numeric has base class basic. So, I did

    .add(boost::python::class_<GiNaC::basic>("_basic")
	 //.def_init(boost::python::args<const GiNaC::basic &>())
	 .def("__repr__",basic_repr)
	 .def("__str__",basic_str)
	 ) //basic
    ;
       m
    .add(boost::python::class_<GiNaC::numeric
	 ,boost::python::bases<GiNaC::basic>    // <=== my addition
	 ,numeric_wrapper
	 >("numeric")
               .def_init(boost::python::args<PyObject*>())

but now I get

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

What I am missing here? Shouldn't derived classes overwrite the __init__
methods of base classes?

Pearu





From achim.domma at syynx.de  Fri May 17 09:23:33 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Fri, 17 May 2002 09:23:33 +0200
Subject: [C++-sig] version confusion
In-Reply-To: <0fc801c1fa93$736fae40$8f01a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEKEDFAA.achim.domma@syynx.de>

> A minimal Jamfile which does this sort of thing for v2 might be:
>
> subproject libs/python/test ;
>
> # bring in the rules for python
> SEARCH on <module@>python.jam = $(BOOST_BUILD_PATH) ;
> include <module@>python.jam ;
> local PYTHON_PROPERTIES = $(BOOST_PYTHON_V2_PROPERTIES) ;
>
> extension my_ext : my_cpp1.cpp my_cpp2.cpp <dll>../bpl
>     : # any additional requirements, e.g. <define>MY_LIB
>     ;

I just managed to build my first python extension with bpl and bjam, and of
course I have more questions now:

- How can I tell bjam to link with third party libraries, which are not
build with bjam ? The statement <dll>../bpl seems to rely on the bjam folder
structure.

- Is there an easy way to use bjam outside the boost source tree? As far as
I understand, bjam walks up the tree to find some jamfiles, but that would
fail if I invoke it outside the boost tree.

greetings
Achim

PS.: I crossposted to c++-sig at python.org and jamboost at yahoogroups.com
because the original thread started in c++-sig, but is becoming more and
more jamboost specific.







From david.abrahams at rcn.com  Fri May 17 13:54:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 17 May 2002 06:54:17 -0500
Subject: [jamboost] RE: [C++-sig] version confusion
References: <FCEMIEFBFOIDAOJDEPIAIEKEDFAA.achim.domma@syynx.de>
Message-ID: <039b01c1fd99$942aefb0$6601a8c0@boostconsulting.com>

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


> > A minimal Jamfile which does this sort of thing for v2 might be:
> >
> > subproject libs/python/test ;
> >
> > # bring in the rules for python
> > SEARCH on <module@>python.jam = $(BOOST_BUILD_PATH) ;
> > include <module@>python.jam ;
> > local PYTHON_PROPERTIES = $(BOOST_PYTHON_V2_PROPERTIES) ;
> >
> > extension my_ext : my_cpp1.cpp my_cpp2.cpp <dll>../bpl
> >     : # any additional requirements, e.g. <define>MY_LIB
> >     ;
>
> I just managed to build my first python extension with bpl and bjam, and
of
> course I have more questions now:
>
> - How can I tell bjam to link with third party libraries, which are not
> build with bjam ? The statement <dll>../bpl seems to rely on the bjam
folder
> structure.

You can use

    <library-file>path/to/library.lib
OR
    <library-path>path/to <find-library>library

in the requirements section of your bjam spec.

> - Is there an easy way to use bjam outside the boost source tree? As far
as
> I understand, bjam walks up the tree to find some jamfiles, but that
would
> fail if I invoke it outside the boost tree.

See http://www.boost.org/libs/python/doc/building.html, in particular the
link to http://www.boost.org/libs/python/example/project.zip


> greetings
> Achim
>
> PS.: I crossposted to c++-sig at python.org and jamboost at yahoogroups.com
> because the original thread started in c++-sig, but is becoming more and
> more jamboost specific.

HTH,
Dave






From achim.domma at syynx.de  Sat May 18 18:42:32 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 18 May 2002 18:42:32 +0200
Subject: [C++-sig] enums and structs
Message-ID: <FCEMIEFBFOIDAOJDEPIAOELJDFAA.achim.domma@syynx.de>

 Hi,
 
 in ./test/comprehensiv.cpp I found the following example for 
 exposing enums:
 
 namespace boost { namespace python {
   template class enum_as_int_converters<bpl_test::EnumOwner::enum_type>;
   using bpl_test::pow;
 }} // namespace boost::python
 
 in Daves progress report from march he mentioned a new interface 
 for exposing enums. Is the code above the right one or will the 
 interface change in V2 ? comprehensive.cpp was the only example 
 concerning enums I could find in the testfolder.
 
 I also have to expose structs with char* members. Is that 
 possible ? It would be no problem to make a copy of the string 
 passed from python, but how/when will this copy be destroyed ?
 
 greetings
 Achim
 
 PS.: I'm trying to make ImageMagick accessible from Python, which 
 is much more work than I expected, but I'm also learning much 
 more than I expected! ;-)





From prabhu at aero.iitm.ernet.in  Sat May 18 18:56:42 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 18 May 2002 22:26:42 +0530
Subject: [C++-sig] enums and structs
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAOELJDFAA.achim.domma@syynx.de>
References: <FCEMIEFBFOIDAOJDEPIAOELJDFAA.achim.domma@syynx.de>
Message-ID: <15590.34762.101820.566392@monster.linux.in>

>>>>> "AD" == Achim Domma <achim.domma at syynx.de> writes:

    AD>  PS.: I'm trying to make ImageMagick accessible from Python,
    AD> which is much more work than I expected, but I'm also learning
    AD> much more than I expected! ;-)

I know this is completely off topic but FYI Python wrappers for
ImageMagick are already available here:

  http://starship.python.net/crew/zack/pymagick/

prabhu




From achim.domma at syynx.de  Sat May 18 19:21:02 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 18 May 2002 19:21:02 +0200
Subject: [C++-sig] enums and structs
In-Reply-To: <15590.34762.101820.566392@monster.linux.in>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIELKDFAA.achim.domma@syynx.de>

Hi,

> I know this is completely off topic but FYI Python wrappers for
> ImageMagick are already available here:
>
>   http://starship.python.net/crew/zack/pymagick/

I had a look on this page bevor, but it seems not very well suported to me!?
Anyway, I try to write a script to convert the header files to boost.python
code, so it would be possible to expose the complete interface. But even if
I fail, it was a good exercise for me.

thanks
Achim






From david.abrahams at rcn.com  Sat May 18 20:49:45 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 18 May 2002 14:49:45 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAOELJDFAA.achim.domma@syynx.de>
Message-ID: <00c701c1fe9c$c7db0ee0$6501a8c0@boostconsulting.com>

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


> Hi,
>
>  in ./test/comprehensiv.cpp I found the following example for
>  exposing enums:
>
>  namespace boost { namespace python {
>    template class enum_as_int_converters<bpl_test::EnumOwner::enum_type>;
>    using bpl_test::pow;
>  }} // namespace boost::python
>
>  in Daves progress report from march he mentioned a new interface
>  for exposing enums.

Yes, as described in
http://mail.python.org/pipermail/c++-sig/2002-April/000907.html


> Is the code above the right one

No, the above is a v1 interface.

> or will the
>  interface change in V2 ?

The link tells all.

> comprehensive.cpp was the only example
>  concerning enums I could find in the testfolder.

You can always use the following until we get the nice interface:

    module("my_module")
        .setattr("enum_value_1", PyInt_FromLong(enum_value_1))
        ...

>  I also have to expose structs with char* members. Is that
>  possible ?

Why not?

> It would be no problem to make a copy of the string
>  passed from python, but how/when will this copy be destroyed ?

I don't understand what you mean, sorry. Are you concerned about how to
*construct* these structs, or is it something else?

-Dave

>  greetings
>  Achim
>
>  PS.: I'm trying to make ImageMagick accessible from Python, which
>  is much more work than I expected, but I'm also learning much
>  more than I expected! ;-)

Nifty!

-Dave






From achim.domma at syynx.de  Sun May 19 10:23:34 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 19 May 2002 10:23:34 +0200
Subject: [C++-sig] compiler limit : internal heap limit reached (msvc)
In-Reply-To: <00c701c1fe9c$c7db0ee0$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAAELODFAA.achim.domma@syynx.de>

Hi,

I got the following error, trying to compile a boost.python extension. How
can I increase the value for /Zm using bjam ?

greetings
Achim


E:\cvsroot\boost\boost/python/data_members.hpp(37) : fatal error C1076:
compiler limit : internal heap limit reached; use /Zm to specify a higher
limit
        E:\cvsroot\boost\boost/python/data_members.hpp(25) : while compiling
class-template member function 'struct _object *__cdecl
boost::python::detail::member<struct _iobuf *,struct
MagickLib::_BlobInfo,struct boost::python::return_value_policy<struct
boost::python::copy_non_const_reference,struct
boost::python::default_call_policies> >::get(struct _iobuf
*MagickLib::_BlobInfo::* ,struct _object *,struct _object *,const struct
boost::python::return_value_policy<struct
boost::python::copy_non_const_reference,struct
boost::python::default_call_policies> &)'


    "cl"

/Zm400 -nologo -GX -c  -DHAVE_IOSFWD -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTH
ON_V2  /Z7 /Od /Ob0 /GX /GR
/MDd   -I"..\..\..\libs\python\ImageMagick" -I"." -I"J:\ImageMagick-5.4.5-1.
tar\ImageMagick-5.4.5\Magick++\lib" -I"J:\ImageMagick-5.4.5-1.tar\ImageMagic
k-5.4.5" -I"E:\cvsroot\boost" -I"c:\python22\include" -I"c:\python22\PC"  -I
"D:\PROGRA~1\MICROS~2\VC98\include"   -Fo"..\..\..\libs\python\ImageMagick\b
in\ImageMagick.pyd\msvc\debug\runtime-link-dynamic\ImageMagickPython.obj"  -
Tp"ImageMagickPython.cpp"






From david.abrahams at rcn.com  Sun May 19 13:07:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 07:07:22 -0400
Subject: [C++-sig] compiler limit : internal heap limit reached (msvc)
References: <FCEMIEFBFOIDAOJDEPIAAELODFAA.achim.domma@syynx.de>
Message-ID: <024b01c1ff25$87a8e430$6501a8c0@boostconsulting.com>

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


> Hi,
>
> I got the following error, trying to compile a boost.python extension.
How
> can I increase the value for /Zm using bjam ?

Add <msvc><*><cxxflags>/ZmNNNN to your target's requirements section, which
follows the list of sources and target dependencies in the Jamfile. See
http://www.boost.org/tools/build/build_system.htm#main_targets

HTH,
Dave





From achim.domma at syynx.de  Sun May 19 16:17:43 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 19 May 2002 16:17:43 +0200
Subject: [C++-sig] enums and structs
In-Reply-To: <00c701c1fe9c$c7db0ee0$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAGELPDFAA.achim.domma@syynx.de>

> -----Original Message-----
> >  in Daves progress report from march he mentioned a new interface
> >  for exposing enums.
>
> Yes, as described in
> http://mail.python.org/pipermail/c++-sig/2002-April/000907.html
>
>
> > Is the code above the right one
>
> No, the above is a v1 interface.
>
> > or will the
> >  interface change in V2 ?
>
> The link tells all.

I don't understand which way I should go at the moment. The interface for V2
looks nice, but as far as I can see, it's not implemented yet. Trying to use
'enum_as_int_converters' I get the following errors  (not surprising me, if
I mix to implementations) :

E:\cvsroot\boost\boost/python/conversions.hpp(124) : error C2955:
'to_python' : use of class template requires template argument list
        E:\cvsroot\boost\boost/python/detail/caller.hpp(20) : see
declaration of 'to_python'
E:\cvsroot\boost\boost/python/conversions.hpp(125) : error C2955:
'from_python' : use of class template requires template argument list
        E:\cvsroot\boost\boost/python/from_python.hpp(19) : see declaration
of 'from_python'

> You can always use the following until we get the nice interface:
>
>     module("my_module")
>         .setattr("enum_value_1", PyInt_FromLong(enum_value_1))

I understand. This expose only the the enum-values, but how do I enable
enum<->int conversion? Should I implement to_python/from_python for all my
enums?

> > It would be no problem to make a copy of the string
> >  passed from python, but how/when will this copy be destroyed ?
>
> I don't understand what you mean, sorry. Are you concerned about how to
> *construct* these structs, or is it something else?

If I have something like

struct {
	char * member;
} myStruct;

and then try to do something like

class_<myStruct>("myStruct")
	.def_readwrite("member",&myStruct::member);

would it work? I could not imagine how memory management of the string
should work.

Achim



> >  PS.: I'm trying to make ImageMagick accessible from Python, which
> >  is much more work than I expected, but I'm also learning much
> >  more than I expected! ;-)
>
> Nifty!

I'm myself curious about wether I will get it done or not. (and surprised if
this was correct english :-) )






From david.abrahams at rcn.com  Sun May 19 17:39:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 11:39:14 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAGELPDFAA.achim.domma@syynx.de>
Message-ID: <034f01c1ff4b$5619b540$6501a8c0@boostconsulting.com>

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


> > -----Original Message-----
> > >  in Daves progress report from march he mentioned a new interface
> > >  for exposing enums.
> >
> > Yes, as described in
> > http://mail.python.org/pipermail/c++-sig/2002-April/000907.html
> >
> >
> > > Is the code above the right one
> >
> > No, the above is a v1 interface.
> >
> > > or will the
> > >  interface change in V2 ?
> >
> > The link tells all.
>
> I don't understand which way I should go at the moment. The interface for
V2
> looks nice, but as far as I can see, it's not implemented yet. Trying to
use
> 'enum_as_int_converters' I get the following errors  (not surprising me,
if
> I mix to implementations) :

Right, not surprising.

> > You can always use the following until we get the nice interface:
> >
> >     module("my_module")
> >         .setattr("enum_value_1", PyInt_FromLong(enum_value_1))
>
> I understand. This expose only the the enum-values, but how do I enable
> enum<->int conversion? Should I implement to_python/from_python for all
my
> enums?

Uhh... well, I guess that's what you'd need to do, until the new interface
is implemented. However, it's pretty easy to get the from_python converters
(http://www.boost.org/libs/python/doc/v2/implicit.html):

    implicitly_convertible<int, my_enum_type>();

As for the to_python converters,

    // use with to_python_converter
    // http://www.boost.org/libs/python/doc/v2/to_python_converter.html
    template <class T>
    struct enum_to_int_converter
    {
       static PyObject* convert(T const& x)
       {
          return PyInt_FromLong(x);
       }
    };

Putting it together:

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

Now:

    enum_as_int<my_enum_type>();

> > > It would be no problem to make a copy of the string
> > >  passed from python, but how/when will this copy be destroyed ?
> >
> > I don't understand what you mean, sorry. Are you concerned about how to
> > *construct* these structs, or is it something else?
>
> If I have something like
>
> struct {
> char * member;
> } myStruct;
>
> and then try to do something like
>
> class_<myStruct>("myStruct")
> .def_readwrite("member",&myStruct::member);
>
> would it work? I could not imagine how memory management of the string
> should work.

I suggest that you expose a class derived from myStruct which handles the
memory management, then use the property facility described in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/class.html?rev=HEAD&content-type=text/html#class_-spec-modifi
ers to get write access to the data from Python.

-Dave






From owensmk at earthlink.net  Sun May 19 18:53:08 2002
From: owensmk at earthlink.net (Michael Owens)
Date: Sun, 19 May 2002 11:53:08 -0500
Subject: [C++-sig] Segfaults in Pure Virtual Functions in Extension Module
Message-ID: <200205191153.08258.owensmk@earthlink.net>

I am writing an extension module on Linux and have run into a problem with 
receiving segmenation faults when calling classes with virtual functions. The 
function in question is reimplemented from a pure-virtual function in the 
base class.

gdb only shows that the attempt to call the function results in SIGSEV. The 
object is allocated, and I don't see any dangling pointers. I am at a loss as 
to how to even determine what is failing. I suspect it has something to do 
with the VTable, but don't know how to work around it. Non-virtual functions 
do not cause this problem.

Basically, it looks like this:

class A
{
	virtual bool connect() = 0;
};

class B : public A
{
	virtual bool connect();
};

When I instantiate B anywhere in the extention module and then call connect(), 
boom.

I was wondering if it was related to exporting the symbols of B, and tried 
building the library with -rdynamic, but that did not help.

Any suggestions would be greatly appreciated.





From david.abrahams at rcn.com  Sun May 19 18:59:32 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 12:59:32 -0400
Subject: [C++-sig] Segfaults in Pure Virtual Functions in Extension Module
References: <200205191153.08258.owensmk@earthlink.net>
Message-ID: <040201c1ff56$8cb902d0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Michael Owens" <owensmk at earthlink.net>


> I am writing an extension module on Linux and have run into a problem
with
> receiving segmenation faults when calling classes with virtual functions.
The
> function in question is reimplemented from a pure-virtual function in the
> base class.
>
> gdb only shows that the attempt to call the function results in SIGSEV.
The
> object is allocated, and I don't see any dangling pointers. I am at a
loss as
> to how to even determine what is failing. I suspect it has something to
do
> with the VTable, but don't know how to work around it. Non-virtual
functions
> do not cause this problem.
>
> Basically, it looks like this:
>
> class A
> {
> virtual bool connect() = 0;
> };
>
> class B : public A
> {
> virtual bool connect();
> };
>
> When I instantiate B anywhere in the extention module and then call
connect(),
> boom.

Hmm, did you supply a definition for B::connect anywhere?

> I was wondering if it was related to exporting the symbols of B, and
tried
> building the library with -rdynamic, but that did not help.
>
> Any suggestions would be greatly appreciated.

Please post the code you used to expose A and B to Python, and a snippet of
Python code which causes the crash.

Thanks,
Dave






From achim.domma at syynx.de  Sun May 19 19:34:01 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 19 May 2002 19:34:01 +0200
Subject: [C++-sig] enums and structs
In-Reply-To: <034f01c1ff4b$5619b540$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEMBDFAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Sunday, May 19, 2002 17:39
> To: c++-sig at python.org
> Cc: joel de guzman
> Subject: Re: [C++-sig] enums and structs

> Uhh... well, I guess that's what you'd need to do, until the new interface
> is implemented. However, it's pretty easy to get the from_python
> converters
> (http://www.boost.org/libs/python/doc/v2/implicit.html):
>
>     implicitly_convertible<int, my_enum_type>();

Because I only pass enums to functions, conversion from enum to int should
be enough. It works for me, if I use

	implicitly_convertible<my_enum_type, int>();

which makes sense to me, because I convert enum to int and not the other
way. Am I right? But now I get my next error:

E:\cvsroot\boost\boost/python/detail/arg_tuple_size.hpp(83) : error C2665:
'arg_tuple_size_helper' : none of the 4 overloads can convert parameter 1
from type 'void (__thiscall Magick::Image::*)(const MagickLib::NoiseType)'
        E:\cvsroot\boost\boost/python/make_function.hpp(26) : see reference
to class template instantiation 'boost::python::detail::arg_tuple_size<void
(__thiscall Magick::Image::*)(enum MagickLib::NoiseType)>' being compiled
        E:\cvsroot\boost\boost/python/detail/wrap_function.hpp(30) : see
reference to function template instantiation 'struct
boost::python::objects::function *__cdecl boost::python::make_function(void
(__thiscall Magick::Image::*)(const MagickLib::NoiseType))' being compiled

NoiseType is an enum which I made available via

	implicitly_convertible<MagickLib::NoiseType,int>();

and the function where the problem occures is defined as

	class_<Magick::Image> wrapper_of_Image("Image");
	//...
	wrapper_of_Image
		//some ctors ...
		.def_init(...)
		.def("addNoise",(void (Magick::Image::*)(const
NoiseType))&Magick::Image::addNoise)
		//...

I tried to look to the code, but I failed to understand what the
'sizeof-Magic' in arg_tuple_size.hpp is good for and how it works. Any hint
what's going wrong?

greetings
Achim







From owensmk at earthlink.net  Sun May 19 19:26:10 2002
From: owensmk at earthlink.net (Michael Owens)
Date: Sun, 19 May 2002 12:26:10 -0500
Subject: [C++-sig] Segfaults in Pure Virtual Functions in Extension Module
In-Reply-To: <040201c1ff56$8cb902d0$6501a8c0@boostconsulting.com>
References: <200205191153.08258.owensmk@earthlink.net> <040201c1ff56$8cb902d0$6501a8c0@boostconsulting.com>
Message-ID: <200205191226.10166.owensmk@earthlink.net>

I am having problems in a Python class called Session which holds a pointer
to an abstract C++ class (session --- little 's') which represents a generic 
connection to a database. The constructor will instantiate a derived session 
class (implementing a specific a database connection) call its connect() 
function, and assign the pointer to the p_session member of Session. It 
segfaults on connect() within Session's constructor. Now I know that 
session::connect() works fine as I have tested and debugged it in a regular 
C++ program.

Here are the relevent functions to create Session in the module (sdbc.cc):

static PyMethodDef sdbc_functions[] = 
{
	{ "session", NewSession, METH_VARARGS},
	{ "join", NewJoin, METH_VARARGS},
	{ NULL, NULL }
};

extern "C" void initsdbc()
{
	Py_InitModule("sdbc", sdbc_functions);
}

// Create a new Session object
PyObject* NewSession(PyObject *self, PyObject *args)
{
	const char* driver_name;
	const char* host_name;
	const char* user_name;
	const char* password;
	const char* database;

	if(!PyArg_ParseTuple(args,"sssss:Session",
						 &driver_name,
						 &host_name,
						 &user_name,
						 &password,
						 &database))
	{
		return NULL;
	}

	// Constructor will be instantiate a session object using these arguments
	return new Session(driver_name, host_name, user_name, password, database);
}



-------------------------------------------------------------------
Here is Session's declaration (from Session.h):
-------------------------------------------------------------------

// Session is an abstract C++ class representing a generic database session.
class session;

/** This class wraps the join C++ class.*/
class Session: public PyObject
{
  public:

	/** Default Constructor -- nothing special.*/
	Session( const char* dn,
			 const char* hn,
			 const char* un,
			 const char* pw,
			 const char* db );

	~Session();

	/** Python specific interfaces */
	static void dealloc(PyObject *obj);
	static PyObject *getattr(PyObject *obj, char *name);
	static int setattr(PyObject *obj, char *name, PyObject *value);
	
	static struct memberlist memberlist[];
	static PyMethodDef methodlist[];

	const char* driver_name;
	const char* host_name;
	const char* user_name;
	const char* password;
	const char* database;
	session* p_session;
}; 

-------------------------------------------------------------------
The constructor is as follows, Here is where the segfault occurs 
p_s->connect();
-------------------------------------------------------------------

Session::Session(const char* dn,
				 const char* hn,
				 const char* un,
				 const char* pw,
				 const char* db )
{
	driver_name = strdup(dn);
	host_name = strdup(hn);
	user_name = strdup(un);
	password = strdup(pw);
	database = strdup(db);

	// Instantiate a derived session class --- specific to sqlite_database.
	sqlite_session* p_s = new sqlite_session("db");


	// SEGFAULT here:
	if (p_s->connect() == false)
	{
		printf("Failed to connect to database: Error=%s\n", p_session->error());
	}
	else
	{
		printf("Connected to database.\n");
	}

	// Assign to base class pointer.
	p_session = p_s;

	ob_type = &Session_Type;

	_Py_NewReference(this);
}

Session::~Session()
{
	free((void*)driver_name);
	free((void*)host_name);
	free((void*)user_name);
	free((void*)password);
	free((void*)database);

	delete p_session;
}


-------------------------------------------------------------------
Here is Session's  memberlist and method list(Session.cc)
-------------------------------------------------------------------

#define OFF(x) offsetof(Session, x)

struct memberlist Session::memberlist[] =
{
	{"driver_name", T_STRING, OFF(driver_name)},
	{"host_name",   T_STRING, OFF(host_name)},
	{"user_name",   T_STRING, OFF(user_name)},
	{"password",    T_STRING, OFF(password)},
	{"database",    T_STRING, OFF(database)},
	{NULL}
};

PyMethodDef Session::methodlist[] =
{
	{ NULL, NULL}
};

-------------------------------------------------------------------
The python code is as follows:
-------------------------------------------------------------------

#!/usr/bin/python

import sdbc

s = sdbc.session("SQLite", "localhost", "root", "", "db")

# Crash. If I don't embed session within Session, there is not problem. It all
# pivots around the presence of session with Session and calling connect(). If 
I don't call connect, or call one of session's non-virtual function, there is 
no segfault here.
j = sdbc.join(s)




> Please post the code you used to expose A and B to Python, and a snippet of
> Python code which causes the crash.
>
> Thanks,
> Dave





From david.abrahams at rcn.com  Sun May 19 19:35:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 13:35:17 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAEEMBDFAA.achim.domma@syynx.de>
Message-ID: <042501c1ff5c$3658fc00$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams

> > Uhh... well, I guess that's what you'd need to do, until the new
interface
> > is implemented. However, it's pretty easy to get the from_python
> > converters
> > (http://www.boost.org/libs/python/doc/v2/implicit.html):
> >
> >     implicitly_convertible<int, my_enum_type>();
>
> Because I only pass enums to functions, conversion from enum to int
should
> be enough. It works for me, if I use
>
> implicitly_convertible<my_enum_type, int>();
>
> which makes sense to me,

Not to me; you really should trust that I know what I'm writing (and look
at the docs and examples if you have second thoughts).

> because I convert enum to int and not the other
> way. Am I right?

No. It's the library which must do the conversion. When it's trying to
match an argument of my_enum_type, it looks for conversions which can
produce int, because it knows int is convertible to my_enum_type. That's
why you should write it the way I did.

> But now I get my next error:
>
> E:\cvsroot\boost\boost/python/detail/arg_tuple_size.hpp(83) : error
C2665:
> 'arg_tuple_size_helper' : none of the 4 overloads can convert parameter 1
> from type 'void (__thiscall Magick::Image::*)(const
MagickLib::NoiseType)'
>         E:\cvsroot\boost\boost/python/make_function.hpp(26) : see
reference
> to class template instantiation
'boost::python::detail::arg_tuple_size<void
> (__thiscall Magick::Image::*)(enum MagickLib::NoiseType)>' being compiled
>         E:\cvsroot\boost\boost/python/detail/wrap_function.hpp(30) : see
> reference to function template instantiation 'struct
> boost::python::objects::function *__cdecl
boost::python::make_function(void
> (__thiscall Magick::Image::*)(const MagickLib::NoiseType))' being
compiled
>
> NoiseType is an enum which I made available via
>
> implicitly_convertible<MagickLib::NoiseType,int>();
>
> and the function where the problem occures is defined as
>
> class_<Magick::Image> wrapper_of_Image("Image");
> //...
> wrapper_of_Image
> //some ctors ...
> .def_init(...)
> .def("addNoise",(void (Magick::Image::*)(const
> NoiseType))&Magick::Image::addNoise)
> //...
>
> I tried to look to the code, but I failed to understand what the
> 'sizeof-Magic' in arg_tuple_size.hpp is good for and how it works. Any
hint
> what's going wrong?

Well, this is a VC bug: the argument type is not "const NoiseType", but
simply "NoiseType" - writing const on a function parameter is not supposed
to change the type of the function, only how the parameter behaves within
the definition - though it *does* change the function type in VC. In fact:

void f(int); // declaration
void f(int const x) {} // definition of the same function

So leave off the "const" and you'll be fine.

-Dave






From david.abrahams at rcn.com  Sun May 19 19:37:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 13:37:16 -0400
Subject: [C++-sig] Segfaults in Pure Virtual Functions in Extension Module
References: <200205191153.08258.owensmk@earthlink.net> <040201c1ff56$8cb902d0$6501a8c0@boostconsulting.com> <200205191226.10166.owensmk@earthlink.net>
Message-ID: <042601c1ff5c$3675f9e0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Michael Owens" <owensmk at earthlink.net>


> I am having problems in a Python class called Session which holds a
pointer
> to an abstract C++ class (session --- little 's') which represents a
generic
> connection to a database. The constructor will instantiate a derived
session
> class (implementing a specific a database connection) call its connect()
> function, and assign the pointer to the p_session member of Session. It
> segfaults on connect() within Session's constructor. Now I know that
> session::connect() works fine as I have tested and debugged it in a
regular
> C++ program.

<snip>

Oh, you're not using Boost.Python. I guess I can't help you, but maybe
someone else can.

Good Luck,
Dave






From achim.domma at syynx.de  Sun May 19 23:07:20 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 19 May 2002 23:07:20 +0200
Subject: [C++-sig] enums and structs
In-Reply-To: <042501c1ff5c$3658fc00$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAOEMEDFAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Sunday, May 19, 2002 19:35
> To: c++-sig at python.org
> Subject: Re: [C++-sig] enums and structs

> No. It's the library which must do the conversion. When it's trying to
> match an argument of my_enum_type, it looks for conversions which can
> produce int, because it knows int is convertible to my_enum_type. That's
> why you should write it the way I did.

Using your code, I tried the following:


-- code -->
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:
	enum_as_int<MagickLib::AlignType>();
}};


BOOST_PYTHON_MODULE_INIT(ImageMagick)
{
	using namespace boost::python;
	// position2:
	enum_as_int<MagickLib::AlignType>();
	//...
}
<-- code --

Registering the conversion at position 1 causes an internal compiler error
(with /Zm1600):

E:\cvsroot\boost\boost/type_traits/arithmetic_traits.hpp(31) : fatal error
C1204: compiler limit : internal structure overflow
        E:\cvsroot\boost\boost/type_traits/object_traits.hpp(184) : see
reference to class template instantiation 'boost::is_void<class
boost::_bi::bind_t<struct _object *,struct
boost::python::detail::caller,class boost::_bi::list4<class
boost::_bi::value<void (__thiscall Magick::Image::*)(enum
MagickLib::QuantumType,unsigned char const *)>,class boost::arg<1>,class
boost::arg<2>,class boost::_bi::value<struct
boost::python::default_call_policies> > > >' being compiled
...

At position 2 I get the following error:

E:\cvsroot\boost\boost/python/converter/implicit.hpp(41) : error C2440: '='
: cannot convert from 'int' to 'MagickLib::AlignType'
        Conversion to enumeration type requires an explicit cast
(static_cast, C-style cast or function-style cast)
        E:\cvsroot\boost\boost/python/converter/implicit.hpp(26) : while
compiling class-template member function 'void __cdecl
boost::python::converter::implicit<int,enum
MagickLib::AlignType>::construct(struct _object *,struct
boost::python::converter::rvalue_stage1_data *)'

greetings
Achim

PS.: I really appreciate your tireless support, and try not to waste your
time with stupid questions, but the inner working of boost.python is too
much for my C++ skills.






From info at chat4webmasters.com  Mon May 20 00:55:19 2002
From: info at chat4webmasters.com (Chat4Webmasters)
Date: Mon, 20 May 2002 00:55:19 +0200
Subject: [C++-sig] Get a free chat room for your website!
Message-ID: <011901c1ff88$4c9cbca0$d800a8c0@xe3>

Hi there, I found your website on the net and I thought you might be
interested in what we, Chat4Webmasters.com, have to offer you as a
webmaster - a free java chat room for your website.

You can sign up and be up and running in less than five minutes, just go to
the following address to get started:
http://www.chat4webmasters.com/start.cfm

A chat room is an interactive and fun addition to any type of website, it
creates a community atmosphere on your site and keeps your users coming
back, day after day.
You can use the chat room as a general discussion area for topics related to
your website, as a real-time support tool for products/services offered on
your site or just to interact with your visitors in a more efficient way
than email.

Our chat hosting service is among the best available, and while other
leading chat service providers charge you a monthly service fee we are able
to offer you this for free (our 50% banner revenue share makes this
possible).

Here are some of the most important features of our chat room / chat
hosting:
- Advanced multi-threaded java chat backend (you don't have to worry about
server performance or bandwidth usage).
- Fast & robust non-java frontend (works in all browsers, looks just like a
normal web page - i.e. not the typical "java look").
- Powerful user functions (profile registration, user status etc)
- Customize the chat room design (add your logo, change fonts and colors or
replace the entire interface/skin with your own).
- Chat moderator functionality available (allows you to moderate the chat or
assign others as moderators).

Go to our home page for more information:
http://www.chat4webmasters.com/home.cfm
...or just reply to this email and/or reach me online through instant
messaging (contact info below).

Thanks for your time, I hope you're interested in adding a chat room to your
website, if not I apologize for sending you this email and wish you luck
with your website in the future :)


Sincerely,

The Chat4Webmasters Team
info at chat4webmasters.com
ICQ: 158706102
AIM: chatforweb
MSN: chatforweb at hotmail.com
YAHOO: chat4webmasters






From david.abrahams at rcn.com  Mon May 20 00:50:34 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 18:50:34 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAOEMEDFAA.achim.domma@syynx.de>
Message-ID: <04b601c1ff88$453bb2e0$6501a8c0@boostconsulting.com>

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


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

> > No. It's the library which must do the conversion. When it's trying to
> > match an argument of my_enum_type, it looks for conversions which can
> > produce int, because it knows int is convertible to my_enum_type.
That's
> > why you should write it the way I did.
>
> Using your code, I tried the following:
>
<snip>

> Registering the conversion at position 1 causes an internal compiler
error
> (with /Zm1600):

I don't know what to say about that other than "there's a compiler bug".

> At position 2 I get the following error:
>
> E:\cvsroot\boost\boost/python/converter/implicit.hpp(41) : error C2440:
'='
> : cannot convert from 'int' to 'MagickLib::AlignType'
>         Conversion to enumeration type requires an explicit cast
> (static_cast, C-style cast or function-style cast)

This one's my fault; I forgot the rules for converting ints to enums.

Supporting this usage will require a Boost.Python library extension.
Probably the easiest thing to do is to give implicitly_convertible an
optional argument which allows an explicit conversion (in this case a
static_cast<>) to be specified.

Since Joel is doing some work with enums now, it might make sense for him
to implement this. What do you think, Joel?

> PS.: I really appreciate your tireless support, and try not to waste your
> time with stupid questions, but the inner working of boost.python is too
> much for my C++ skills.

No problem at all. However, I'm curious as to whether you're using is
understandable to you, at least in part. Did you read the documentation I
referenced? I ask because Boost.Python is a framework and I really want to
make it understandable and accessible. If you don't understand it yet, I at
least hope to make it learnable.

-Dave






From david.abrahams at rcn.com  Mon May 20 01:36:16 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 19:36:16 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAOEMEDFAA.achim.domma@syynx.de> <04b601c1ff88$453bb2e0$6501a8c0@boostconsulting.com>
Message-ID: <04c901c1ff8d$f9d43470$6501a8c0@boostconsulting.com>


oops...

I wrote:
> No problem at all. However, I'm curious as to whether you're using is
"the code"---------------------------------------------^
> understandable to you, at least in part. Did you read the documentation I
> referenced? I ask because Boost.Python is a framework and I really want
to
> make it understandable and accessible. If you don't understand it yet, I
at
> least hope to make it learnable.
>
> -Dave






From djowel at gmx.co.uk  Mon May 20 02:16:51 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Mon, 20 May 2002 08:16:51 +0800
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAOEMEDFAA.achim.domma@syynx.de> <04b601c1ff88$453bb2e0$6501a8c0@boostconsulting.com>
Message-ID: <004701c1ff93$af3efa20$20be8aca@asiagate.net>

Hi Dave,

You don't have to CC me here, I subscribed to the list.

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

> Since Joel is doing some work with enums now, it might make sense for him
> to implement this. What do you think, Joel?

Ok. I will. I was in fact thinking of a variation of the
syntax that you posted before. What do you think
about:

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

my_module.add(
    
    enum_<MyEnum>("MyEnum")
    [
        enum_val("one", one),
        enum_val("two", two),
        enum_val("three", three)
    ]
);

Kinda like Phoenix-ish. Tell me if it's too cute for your taste ;^/
Implementation wise, I'm still trying to grok the innards of
BPL. I'm not even close yet, but I'll be- surely ;-)

--Joel





From david.abrahams at rcn.com  Mon May 20 04:08:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 19 May 2002 22:08:57 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAOEMEDFAA.achim.domma@syynx.de> <04b601c1ff88$453bb2e0$6501a8c0@boostconsulting.com> <004701c1ff93$af3efa20$20be8aca@asiagate.net>
Message-ID: <052601c1ffa3$98b4c360$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "joel de guzman" <djowel at gmx.co.uk>
To: "David Abrahams" <david.abrahams at rcn.com>; <c++-sig at python.org>
Sent: Sunday, May 19, 2002 8:16 PM
Subject: Re: [C++-sig] enums and structs


> Hi Dave,
>
> You don't have to CC me here, I subscribed to the list.
>
> ----- Original Message -----
> From: "David Abrahams" :
>
> > Since Joel is doing some work with enums now, it might make sense for
him
> > to implement this. What do you think, Joel?
>
> Ok. I will. I was in fact thinking of a variation of the
> syntax that you posted before. What do you think
> about:
>
> enum MyEnum { one = 1, two, three };
>
> my_module.add(
>
>     enum_<MyEnum>("MyEnum")
>     [
>         enum_val("one", one),
>         enum_val("two", two),
>         enum_val("three", three)
>     ]
> );
>
> Kinda like Phoenix-ish. Tell me if it's too cute for your taste ;^/

I like the Phoenix-isms, and I even think it might make sense to re-do the
entire interface that way at some point:

module("my_module")
[
    def("x", x),
    def("y", y),
    ...

    class_<MyClass>("MyClass")
    [
        def("foo", &MyClass::foo),
        def("bar", &MyClass::bar),
        ...
    ],

    enum_<MyEnum>("MyEnum") [ ... ]
]

Whatever happens, classes, enums, and modules should probably all use a
consistent interface...
However, the above approach would complicate things quite a bit, since the
wrapped class type needs to interact with the member pointer type (see the
member_function_cast ugliness in the implementation). We'd need to switch
to a delayed evaluation scheme for the def() functions, and I don't think
it's time to do that right now.

Also, the interface direction from my email was supposed to produce a
different result than enums-as-ints... though I guess there's no reason we
couldn't start with as-int conversion and switch to int subclasses later,
using the same interface.

> Implementation wise, I'm still trying to grok the innards of
> BPL. I'm not even close yet, but I'll be- surely ;-)

I hope you've been watching the CVS documentation as it gets updated.
Things are getting better...

-Dave






From djowel at gmx.co.uk  Mon May 20 05:21:28 2002
From: djowel at gmx.co.uk (joel de guzman)
Date: Mon, 20 May 2002 11:21:28 +0800
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAOEMEDFAA.achim.domma@syynx.de> <04b601c1ff88$453bb2e0$6501a8c0@boostconsulting.com> <004701c1ff93$af3efa20$20be8aca@asiagate.net> <052601c1ffa3$98b4c360$6501a8c0@boostconsulting.com>
Message-ID: <001601c1ffad$865929e0$91be8aca@asiagate.net>

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

> I like the Phoenix-isms, and I even think it might make sense to re-do the
> entire interface that way at some point:

[snip]

> Whatever happens, classes, enums, and modules should probably all use a
> consistent interface...
> However, the above approach would complicate things quite a bit, since the
> wrapped class type needs to interact with the member pointer type (see the
> member_function_cast ugliness in the implementation). We'd need to switch
> to a delayed evaluation scheme for the def() functions, and I don't think
> it's time to do that right now.
> 
> Also, the interface direction from my email was supposed to produce a
> different result than enums-as-ints... though I guess there's no reason we
> couldn't start with as-int conversion and switch to int subclasses later,
> using the same interface.

The syntactic sugar can sit atop the current interface, possibly
in a sub-namespace to avoid name conflicts. The interface as 
it is need not be changed at all. I'm having some progress with 
deferred evaluation in Spirit/Phoenix and I think that this is an area 
where I can contribute to the Python code base. I agree though that 
this should be done later, especially when I get some more spare time. 
For now, I'll see if I can get a sufficient enum-interface up and running. 

> I hope you've been watching the CVS documentation as it gets updated.
> Things are getting better...

I'm enjoying the experience every single bit :-)

Regards,
--Joel







From achim.domma at syynx.de  Mon May 20 09:48:16 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Mon, 20 May 2002 09:48:16 +0200
Subject: [C++-sig] enums and structs
In-Reply-To: <04b601c1ff88$453bb2e0$6501a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAKEMIDFAA.achim.domma@syynx.de>

Hi Dave,

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> No problem at all. However, I'm curious as to whether you're using is
> understandable to you, at least in part. Did you read the documentation I
> referenced? I ask because Boost.Python is a framework and I really want to
> make it understandable and accessible. If you don't understand it
> yet, I at
> least hope to make it learnable.

I think boost.python will be a very powerfull, understandable framework.
What you explained to me or the documentation you referenced is very
understandable. At the current state the problems (for me) come from another
direction:

- First I tried to get a simple example up and running. I'm a windows
developer and never used jam or cvs befor, so I had to learn these tools
first. When I tried it, the jam documentation was somewhat outdated, which
made it even hard to use. These problems are solved now, but in case of an
error there is always a rest of uncertainty: 'Do I REALLY have the latest
version from cvs?'

- I usually first try to solve my problems by myself, befor I ask questions.
The userinterface of boost.python is very easy to understand in my opinion,
but if something goes wrong, you usually get template instantiation errors,
which are much less understandable. I'm familiar with basic template
metaprogramming technics, so I can follow the principles you are using, but
I know nothing about magic tricks to workaround compiler bugs. So it's often
very hard to estimate if it's my fault or not.

Because my english isn't the best, I would to make absolutly clear, that
this sould be no criticism in any way! I'm very happy using boost.python,
and most problems arise simply from missing knowledge of my own or the fact
that the software is still in development - but you asked!

greetings
Achim






From david.abrahams at rcn.com  Mon May 20 14:10:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 20 May 2002 08:10:39 -0400
Subject: [C++-sig] enums and structs
References: <FCEMIEFBFOIDAOJDEPIAKEMIDFAA.achim.domma@syynx.de>
Message-ID: <057d01c1fff7$b251b9f0$6501a8c0@boostconsulting.com>

Thanks for the feedback, Achim.

-Dave

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

> I think boost.python will be a very powerfull, understandable framework.
> What you explained to me or the documentation you referenced is very
> understandable. At the current state the problems (for me) come from
another
> direction:
>
> - First I tried to get a simple example up and running. I'm a windows
> developer and never used jam or cvs befor, so I had to learn these tools
> first. When I tried it, the jam documentation was somewhat outdated,
which
> made it even hard to use. These problems are solved now, but in case of
an
> error there is always a rest of uncertainty: 'Do I REALLY have the latest
> version from cvs?'
>
> - I usually first try to solve my problems by myself, befor I ask
questions.
> The userinterface of boost.python is very easy to understand in my
opinion,
> but if something goes wrong, you usually get template instantiation
errors,
> which are much less understandable. I'm familiar with basic template
> metaprogramming technics, so I can follow the principles you are using,
but
> I know nothing about magic tricks to workaround compiler bugs. So it's
often
> very hard to estimate if it's my fault or not.
>
> Because my english isn't the best, I would to make absolutly clear, that
> this sould be no criticism in any way! I'm very happy using boost.python,
> and most problems arise simply from missing knowledge of my own or the
fact
> that the software is still in development - but you asked!
>
> greetings
> Achim
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From achim.domma at syynx.de  Tue May 21 17:09:13 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Tue, 21 May 2002 17:09:13 +0200
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
Message-ID: <FCEMIEFBFOIDAOJDEPIAIENDDFAA.achim.domma@syynx.de>

Hi,

I have a very strang problem with boost.python V1 and V2: On Win2K I build
two extensions with boost.python, one with V1 and one with V2. Both compile
without problems, but fail to load. The problem is a missing dll called
'apphelp.dll' which is only available on WinXP. According to Microsofts
'depends' utility the dll is neede by python22.dll, but my python works
without problems.
Has anybody an idea ? I compiled working extensions some days befor, all on
this computer!?

greetings
Achim






From david.abrahams at rcn.com  Tue May 21 17:38:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 21 May 2002 11:38:43 -0400
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
References: <FCEMIEFBFOIDAOJDEPIAIENDDFAA.achim.domma@syynx.de>
Message-ID: <031901c200de$18b6ad40$6601a8c0@boostconsulting.com>

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


> Hi,
>
> I have a very strang problem with boost.python V1 and V2: On Win2K I
build
> two extensions with boost.python, one with V1 and one with V2. Both
compile
> without problems, but fail to load. The problem is a missing dll called
> 'apphelp.dll' which is only available on WinXP. According to Microsofts
> 'depends' utility the dll is neede by python22.dll, but my python works
> without problems.
> Has anybody an idea ? I compiled working extensions some days befor, all
on
> this computer!?

very strange. I'm developing on XP without any trouble. My apphelp.dll
lives in c:\Windows\System32. Perhaps you deleted yours, or you removed the
directory from your PATH?

-Dave






From achim.domma at syynx.de  Tue May 21 18:41:38 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Tue, 21 May 2002 18:41:38 +0200
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
In-Reply-To: <031901c200de$18b6ad40$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAMENFDFAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> > I have a very strang problem with boost.python V1 and V2: On Win2K I
> build
> > two extensions with boost.python, one with V1 and one with V2. Both
> compile
> > without problems, but fail to load. The problem is a missing dll called
> > 'apphelp.dll' which is only available on WinXP. According to Microsofts
> > 'depends' utility the dll is neede by python22.dll, but my python works
> > without problems.
> > Has anybody an idea ? I compiled working extensions some days befor, all
> on
> > this computer!?
>
> very strange. I'm developing on XP without any trouble. My apphelp.dll
> lives in c:\Windows\System32. Perhaps you deleted yours, or you
> removed the
> directory from your PATH?

No, I develop on Win2K and don't have an XP installation. But apphelp.dll is
XP specific, so I don't know how the dependency comes to my computer.
Searching on groups.google.com I found lots of posts from php-people having
the same problem.
I just used 'depends' on python22.dll (from ActiveState and from
python.org). Both version depend on apphelp.dll. Don't know why the problem
only arises when I try to load my extensions. Later I will try to compile a
version on my own.

Achim






From whisper at oz.net  Tue May 21 19:39:38 2002
From: whisper at oz.net (David LeBlanc)
Date: Tue, 21 May 2002 10:39:38 -0700
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAMENFDFAA.achim.domma@syynx.de>
Message-ID: <GCEDKONBLEFPPADDJCOEGENFDDAA.whisper@oz.net>

Just searched my C drive on Windows 2000 Professional and no apphelp.dll. I
wonder about it's being used on Python 2.2.1, at least the python.org
version - they don't use Windows help file like the ActiveState version...

FWIW, I also searched the AS python2.1 directory tree (not used actively
since I installed 2.2.1, but nothing deleted either) and also the python.org
Python2.2.1 directory tree and neither of them contains the apphelp.dll
either.

I've also built python 2.2.1 from sources, and no missing dependencies came
up...

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Achim Domma
> Sent: Tuesday, May 21, 2002 9:42
> To: c++-sig at python.org
> Subject: RE: [C++-sig] boost_python.dll depends on apphelp.dll ???
>
>
> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > > I have a very strang problem with boost.python V1 and V2: On Win2K I
> > build
> > > two extensions with boost.python, one with V1 and one with V2. Both
> > compile
> > > without problems, but fail to load. The problem is a missing
> dll called
> > > 'apphelp.dll' which is only available on WinXP. According to
> Microsofts
> > > 'depends' utility the dll is neede by python22.dll, but my
> python works
> > > without problems.
> > > Has anybody an idea ? I compiled working extensions some days
> befor, all
> > on
> > > this computer!?
> >
> > very strange. I'm developing on XP without any trouble. My apphelp.dll
> > lives in c:\Windows\System32. Perhaps you deleted yours, or you
> > removed the
> > directory from your PATH?
>
> No, I develop on Win2K and don't have an XP installation. But
> apphelp.dll is
> XP specific, so I don't know how the dependency comes to my computer.
> Searching on groups.google.com I found lots of posts from
> php-people having
> the same problem.
> I just used 'depends' on python22.dll (from ActiveState and from
> python.org). Both version depend on apphelp.dll. Don't know why
> the problem
> only arises when I try to load my extensions. Later I will try to
> compile a
> version on my own.
>
> Achim
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From david.abrahams at rcn.com  Tue May 21 20:41:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 21 May 2002 14:41:39 -0400
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
References: <GCEDKONBLEFPPADDJCOEGENFDDAA.whisper@oz.net>
Message-ID: <03ff01c200f7$2804f1d0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "David LeBlanc" <whisper at oz.net>
To: <c++-sig at python.org>
Sent: Tuesday, May 21, 2002 1:39 PM
Subject: RE: [C++-sig] boost_python.dll depends on apphelp.dll ???


> Just searched my C drive on Windows 2000 Professional and no apphelp.dll.
I
> wonder about it's being used on Python 2.2.1, at least the python.org
> version - they don't use Windows help file like the ActiveState
version...
>
> FWIW, I also searched the AS python2.1 directory tree (not used actively
> since I installed 2.2.1, but nothing deleted either) and also the
python.org
> Python2.2.1 directory tree and neither of them contains the apphelp.dll
> either.
>
> I've also built python 2.2.1 from sources, and no missing dependencies
came
> up...
>

Furthermore, this is from the guy who builds Python for release on Windows:

-----

The python22.dll distributed by PythonLabs was built on a Win98SE box.  It
doesn't depend on apphelp.dll.  I've never been on an XP box, and there is
no apphelp.dll on any machine I do use.  Here are the system DLLs it does
depend on:

ADVAPI32.DLL
KERNEL32.DLL
USER32.DLL
MSVCRT.DLL
SHELL32.DLL

Those in turn depend on (transitive closure):

COMCTL32.DLL
GDI32.DLL
NTDLL.DLL
RPCRT4.DLL
SHLWAPI.DLL

That's it.







From david.abrahams at rcn.com  Tue May 21 22:42:56 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 21 May 2002 16:42:56 -0400
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
References: <GCEDKONBLEFPPADDJCOEGENFDDAA.whisper@oz.net> <03ff01c200f7$2804f1d0$6601a8c0@boostconsulting.com>
Message-ID: <041b01c20108$228df510$6601a8c0@boostconsulting.com>

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

>
> Furthermore, this is from the guy who builds Python for release on
Windows:
>
> -----
>
> The python22.dll distributed by PythonLabs was built on a Win98SE box.
It
> doesn't depend on apphelp.dll.  I've never been on an XP box, and there
is
> no apphelp.dll on any machine I do use.  Here are the system DLLs it does
> depend on:
>
> ADVAPI32.DLL
> KERNEL32.DLL
> USER32.DLL
> MSVCRT.DLL
> SHELL32.DLL
>
> Those in turn depend on (transitive closure):
>
> COMCTL32.DLL
> GDI32.DLL
> NTDLL.DLL
> RPCRT4.DLL
> SHLWAPI.DLL
>
> That's it.

And he goes on to say:

"If he thinks there's a bug, he should open a bug report on SourceForge."

-Dave






From achim.domma at syynx.de  Wed May 22 07:51:27 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 22 May 2002 07:51:27 +0200
Subject: [C++-sig] boost_python.dll depends on apphelp.dll ???
In-Reply-To: <03ff01c200f7$2804f1d0$6601a8c0@boostconsulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIENKDFAA.achim.domma@syynx.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Those in turn depend on (transitive closure):
>
...
> SHLWAPI.DLL
...

Shlwapi.dll is the problem. The newest version of this dll introduces the
dependency to apphelp.dll, which should be no problem due to delayed
loading. I still don't know why an extension 'activates' the dependency to
apphelp.dll, but it's definitively a configuration problem of my system. So
it is a microsoft problem and I will try it in their newsgroups.

thanks for you help
Achim






From ssmith at magnet.fsu.edu  Wed May 22 18:03:43 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 22 May 2002 12:03:43 -0400
Subject: [C++-sig] export a constant
Message-ID: <NFBBINAMBILHLOCDJKAEEEPDCBAA.ssmith@magnet.fsu.edu>

Greetings,

I cannot find anything on how to export a constant from C++
into Python.  Yes, I know I could just define it in Python
directly, but my goal is to have most everything from my code
accessible.

In one of my files I have defined in the header

extern const double PLANK;		// Plancks constant (h)         (J-sec)

and in the cc file

const double PLANK   = 6.6260755e-34;	// Plancks constant (h)(J-sec)

Is there a way to just export this using Boost.Python so that
in Python I can just do 

h = PLANK

Thanks,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu




From david.abrahams at rcn.com  Wed May 22 18:10:31 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 12:10:31 -0400
Subject: [C++-sig] export a constant
References: <NFBBINAMBILHLOCDJKAEEEPDCBAA.ssmith@magnet.fsu.edu>
Message-ID: <076a01c201ab$80cd0370$6601a8c0@boostconsulting.com>

----- Original Message ----- 
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> const double PLANK   = 6.6260755e-34; // Plancks constant (h)(J-sec)
> 
> Is there a way to just export this using Boost.Python so that
> in Python I can just do 
> 
> h = PLANK

In Boost.Python v1, you can do:

#include <boost/python/reference.hpp>
my_module_builder.add(make_ref(PLANK), "PLANK");





From okuda1 at llnl.gov  Wed May 22 18:41:04 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Wed, 22 May 2002 09:41:04 -0700
Subject: [C++-sig] Re: operator[]
References: <3CC74FEF.40D33773@llnl.gov> <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com>
Message-ID: <3CEBCA20.EB2C3CAD@llnl.gov>

I am not sure how to fix the following compiler problem...

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

class Vector2d {
public:
   Vector2d():x(0.0),y(0.0) {}
   Vector2d(const double xval, const double yval): x(xval),y(yval) {}
   ~Vector2d() {}
   double& operator[](const int i) {return i==0 ? x : y;}

protected:
   double x, y;
};

BOOST_PYTHON_MODULE_INIT(simpleVector2)
{
   module Vect2dMod("simpleVector2");
   Vect2dMod
      .add(
           class_<Vector2d>("Vector2d")
           .def_init()
           .def_init(args<const double, const double>())
           //.def("__getitem__", &Vector2d::operator[])
           .def("__getitem__", (double& (Vector2d::*)(const int))
&Vector2d::operator[])
           )
      ;
}
-------------------------------------------------

Problem:
If I replace the class definition of operator[] in 
double& operator[](int i) const {return i==0 ? x : y;}
by either 
.def("__getitem__", &Vector2d::operator[])
or
.def("__getitem__", (double (Vector2d::*)(const int) const)
&Vector2d::operator[])
it compiled, but the above code issued error message:

"/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/preprocessed/returning_non_void.hpp",
line 35: error:
          class
         
"boost::python::detail::specify_a_result_policy_to_wrap_functions_ret
          urning<double &>" has no member "convertible"
      if(!cr.convertible())return 0;

AND

"/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/preprocessed/returning_non_void.hpp",
line 37: error:
          expression must have (pointer-to-) function type
      PyObject*result=cr(((

???
Does anyone have any idea how to fix this? 
Thank you
Chuzo





David Abrahams wrote:
> 
> __getitem__ can be used directly, but the signature for __setitem__ is:
> 
>     __setitem__(self, key, value):
> 
> so you need a wrapper function:
> 
>     template <class Self, class Key, class Value>
>     setitem(Self& self, Key const& key, Value const& value)
>     {
>         self[key] = value;
>     }
> 
>     ...
> 
>     .def("__setitem__", &setitem<Vector2d,int,double>)
> 
> ----- Original Message -----
> From: "chuzo okuda" <okuda1 at llnl.gov>
> To: "David Abrahams" <david.abrahams at rcn.com>
> Cc: "Martin Casado" <casado2 at llnl.gov>; "Susan Hazlett"
> <shazlett at llnl.gov>; "Kathleen McCandless" <mccandless2 at llnl.gov>
> Sent: Wednesday, April 24, 2002 7:38 PM
> Subject: operator[]
> 
> > Dave,
> > Now, I have problem with operator[].
> >
> > class Vector2d {
> > public:
> >    Vector2d():x(0.0),y(0.0) {}
> >    Vector2d(const double xval, const double yval): x(xval),y(yval) {}
> >    ~Vector2d() {}
> >    double getX() {return x;}
> >    double getY() {return y;}
> >    double& operator[](int i) {return i==0 ? x : y;}
> >
> > protected:
> >    double x, y;
> > };
> >
> > int main(int argc, char** argv) {
> >    Vector2d v = Vector2d(1.0,2.0);
> >    cout << v[0] << "; " << v[1] << endl;
> >    v[0] = 5.0; v[1] = 9.0;
> >    cout << v[0] << "; " << v[1] << endl;
> > }
> >
> > And operator[] in C++ support both read and write operation.
> > It is not clear how to write "__setitem__" and "__getitem__" like:
> >
> > .def("__setitem__", &Vector2d::operator[])
> > .def("__getitem__", &Vector2d::operator[])
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From casado2 at llnl.gov  Wed May 22 18:50:37 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Wed, 22 May 2002 09:50:37 -0700
Subject: [C++-sig] Re: operator[]
In-Reply-To: <3CEBCA20.EB2C3CAD@llnl.gov>
References: <3CC74FEF.40D33773@llnl.gov> <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com> <3CEBCA20.EB2C3CAD@llnl.gov>
Message-ID: <0205220950370U.21358@avalanche.llnl.gov>

> I am not sure how to fix the following compiler problem...
>
> ------------------------------------------------
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> using namespace boost::python;
>
> class Vector2d {
> public:
>    Vector2d():x(0.0),y(0.0) {}
>    Vector2d(const double xval, const double yval): x(xval),y(yval) {}
>    ~Vector2d() {}
>    double& operator[](const int i) {return i==0 ? x : y;}
>
> protected:
>    double x, y;
> };
>
> BOOST_PYTHON_MODULE_INIT(simpleVector2)
> {
>    module Vect2dMod("simpleVector2");
>    Vect2dMod
>       .add(
>            class_<Vector2d>("Vector2d")
>            .def_init()
>            .def_init(args<const double, const double>())
>            //.def("__getitem__", &Vector2d::operator[])
>            .def("__getitem__", (double& (Vector2d::*)(const int))
> &Vector2d::operator[])
>            )
>       ;
> }
> -------------------------------------------------
>
> Problem:
> If I replace the class definition of operator[] in
> double& operator[](int i) const {return i==0 ? x : y;}
> by either
> .def("__getitem__", &Vector2d::operator[])
> or
> .def("__getitem__", (double (Vector2d::*)(const int) const)
> &Vector2d::operator[])
> it compiled, but the above code issued error message:
>
> "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/pytho
>n/preprocessed/returning_non_void.hpp", line 35: error:
>           class
>
> "boost::python::detail::specify_a_result_policy_to_wrap_functions_ret
>           urning<double &>" has no member "convertible"
>       if(!cr.convertible())return 0;
>
> AND
>
> "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/pytho
>n/preprocessed/returning_non_void.hpp", line 37: error:
>           expression must have (pointer-to-) function type
>       PyObject*result=cr(((
>
> ???
> Does anyone have any idea how to fix this?

Chuzo,

  When returning an internal reference you must specify a return policy,
  such as return_internal_reference<>(). The compiler error gives
  you a hint to this in the second declaration..

 "boost::python::detail::specify_a_result_policy_to_wrap_functions_ret
           urning<double &>" has no member "convertible"
       if(!cr.convertible())return 0;

 Note the "specify_a_result_policy_to_wrap_functions_ret"

                    :-)
                    ~~m




From okuda1 at llnl.gov  Wed May 22 19:01:23 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Wed, 22 May 2002 10:01:23 -0700
Subject: [C++-sig] Re: operator[]
References: <3CC74FEF.40D33773@llnl.gov> <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com> <3CEBCA20.EB2C3CAD@llnl.gov>
Message-ID: <3CEBCEE3.82BCB96B@llnl.gov>

Sorry, I meant:

If I replace the class definition of operator[] in
double& operator[](const int i) {return i==0 ? x : y;}
by
double operator[](const int i) {return i==0 ? x : y;}

and the line
.def("__getitem__", (double& (Vector2d::*)(const int))
&Vector2d::operator[])
by either
.def("__getitem__", &Vector2d::operator[])
or
.def("__getitem__", (double (Vector2d::*)(const int) const)
&Vector2d::operator[])

Somehow I missed copying and pasting lines...
Chuzo




chuzo okuda wrote:
> 
> I am not sure how to fix the following compiler problem...
> 
> ------------------------------------------------
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> using namespace boost::python;
> 
> class Vector2d {
> public:
>    Vector2d():x(0.0),y(0.0) {}
>    Vector2d(const double xval, const double yval): x(xval),y(yval) {}
>    ~Vector2d() {}
>    double& operator[](const int i) {return i==0 ? x : y;}
> 
> protected:
>    double x, y;
> };
> 
> BOOST_PYTHON_MODULE_INIT(simpleVector2)
> {
>    module Vect2dMod("simpleVector2");
>    Vect2dMod
>       .add(
>            class_<Vector2d>("Vector2d")
>            .def_init()
>            .def_init(args<const double, const double>())
>            //.def("__getitem__", &Vector2d::operator[])
>            .def("__getitem__", (double& (Vector2d::*)(const int))
> &Vector2d::operator[])
>            )
>       ;
> }
> -------------------------------------------------
> 
> Problem:
> If I replace the class definition of operator[] in
> double& operator[](int i) const {return i==0 ? x : y;}
> by either
> .def("__getitem__", &Vector2d::operator[])
> or
> .def("__getitem__", (double (Vector2d::*)(const int) const)
> &Vector2d::operator[])
> it compiled, but the above code issued error message:
> 
> "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/preprocessed/returning_non_void.hpp",
> line 35: error:
>           class
> 
> "boost::python::detail::specify_a_result_policy_to_wrap_functions_ret
>           urning<double &>" has no member "convertible"
>       if(!cr.convertible())return 0;
> 
> AND
> 
> "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/preprocessed/returning_non_void.hpp",
> line 37: error:
>           expression must have (pointer-to-) function type
>       PyObject*result=cr(((
> 
> ???
> Does anyone have any idea how to fix this?
> Thank you
> Chuzo
> 
> David Abrahams wrote:
> >
> > __getitem__ can be used directly, but the signature for __setitem__ is:
> >
> >     __setitem__(self, key, value):
> >
> > so you need a wrapper function:
> >
> >     template <class Self, class Key, class Value>
> >     setitem(Self& self, Key const& key, Value const& value)
> >     {
> >         self[key] = value;
> >     }
> >
> >     ...
> >
> >     .def("__setitem__", &setitem<Vector2d,int,double>)
> >
> > ----- Original Message -----
> > From: "chuzo okuda" <okuda1 at llnl.gov>
> > To: "David Abrahams" <david.abrahams at rcn.com>
> > Cc: "Martin Casado" <casado2 at llnl.gov>; "Susan Hazlett"
> > <shazlett at llnl.gov>; "Kathleen McCandless" <mccandless2 at llnl.gov>
> > Sent: Wednesday, April 24, 2002 7:38 PM
> > Subject: operator[]
> >
> > > Dave,
> > > Now, I have problem with operator[].
> > >
> > > class Vector2d {
> > > public:
> > >    Vector2d():x(0.0),y(0.0) {}
> > >    Vector2d(const double xval, const double yval): x(xval),y(yval) {}
> > >    ~Vector2d() {}
> > >    double getX() {return x;}
> > >    double getY() {return y;}
> > >    double& operator[](int i) {return i==0 ? x : y;}
> > >
> > > protected:
> > >    double x, y;
> > > };
> > >
> > > int main(int argc, char** argv) {
> > >    Vector2d v = Vector2d(1.0,2.0);
> > >    cout << v[0] << "; " << v[1] << endl;
> > >    v[0] = 5.0; v[1] = 9.0;
> > >    cout << v[0] << "; " << v[1] << endl;
> > > }
> > >
> > > And operator[] in C++ support both read and write operation.
> > > It is not clear how to write "__setitem__" and "__getitem__" like:
> > >
> > > .def("__setitem__", &Vector2d::operator[])
> > > .def("__getitem__", &Vector2d::operator[])
> >
> > _______________________________________________
> > 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 ssmith at magnet.fsu.edu  Wed May 22 19:02:07 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 22 May 2002 13:02:07 -0400
Subject: [C++-sig] export a constant
In-Reply-To: <076a01c201ab$80cd0370$6601a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEOEPDCBAA.ssmith@magnet.fsu.edu>

Thanks David,

But this did not work. In MSVC++ it give the following error:

error C2065: 'make_ref' : undeclared identifier

The code had the following lines (amidst a multitude of others):

#include <boost/python/class_builder.hpp>               // Boost class stuff
#include <boost/python/reference.hpp>                   // Boost referencing
boost::python::module_builder pygamma("pygamma");       // Extension module
pygamma.add(make_ref(PLANCK), "PLANCK");                // Export constant
PLANCK

I am running MSVC++ 6.0 SP4 with Python 2.0.1 and Boost 1.25.0.
The build is on lots of code and works well enough to produce a dll.
Is there a place in the documentation where I should be looking?

> > const double PLANCK   = 6.6260755e-34; // Plancks constant (h)(J-sec)
> >
> > Is there a way to just export this using Boost.Python so that
> > in Python I can just do
> >
> > h = PLANCK
>
> In Boost.Python v1, you can do:
>
> #include <boost/python/reference.hpp>
> my_module_builder.add(make_ref(PLANCK), "PLANCK");

Regards,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu






From okuda1 at llnl.gov  Wed May 22 19:21:56 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Wed, 22 May 2002 10:21:56 -0700
Subject: [C++-sig] Re: operator[]
References: <3CC74FEF.40D33773@llnl.gov> <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com> <3CEBCA20.EB2C3CAD@llnl.gov> <0205220950370U.21358@avalanche.llnl.gov>
Message-ID: <3CEBD3B4.513BFE7D@llnl.gov>

Greeting Martin,
You are right, but I got different error this time...

I added:

#include <boost/python/return_internal_reference.hpp>
and added
return_internal_reference<>()
to the line becoming: 
.def("__getitem__", (double& (Vector2d::*)(const
int))&Vector2d::operator[],return_internal_reference<>())

and I get:

"/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/to_python_indirect.hpp",
line 66: error:
          incomplete type is not allowed
            BOOST_STATIC_ASSERT(is_class<T>::value);

:-(
Chuzo



Martin Casado wrote:
> 
> > I am not sure how to fix the following compiler problem...
> >
> > ------------------------------------------------
> > #include <boost/python/module.hpp>
> > #include <boost/python/class.hpp>
> > using namespace boost::python;
> >
> > class Vector2d {
> > public:
> >    Vector2d():x(0.0),y(0.0) {}
> >    Vector2d(const double xval, const double yval): x(xval),y(yval) {}
> >    ~Vector2d() {}
> >    double& operator[](const int i) {return i==0 ? x : y;}
> >
> > protected:
> >    double x, y;
> > };
> >
> > BOOST_PYTHON_MODULE_INIT(simpleVector2)
> > {
> >    module Vect2dMod("simpleVector2");
> >    Vect2dMod
> >       .add(
> >            class_<Vector2d>("Vector2d")
> >            .def_init()
> >            .def_init(args<const double, const double>())
> >            //.def("__getitem__", &Vector2d::operator[])
> >            .def("__getitem__", (double& (Vector2d::*)(const int))
> > &Vector2d::operator[])
> >            )
> >       ;
> > }
> > -------------------------------------------------
> >
> > Problem:
> > If I replace the class definition of operator[] in
> > double& operator[](int i) const {return i==0 ? x : y;}
> > by either
> > .def("__getitem__", &Vector2d::operator[])
> > or
> > .def("__getitem__", (double (Vector2d::*)(const int) const)
> > &Vector2d::operator[])
> > it compiled, but the above code issued error message:
> >
> > "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/pytho
> >n/preprocessed/returning_non_void.hpp", line 35: error:
> >           class
> >
> > "boost::python::detail::specify_a_result_policy_to_wrap_functions_ret
> >           urning<double &>" has no member "convertible"
> >       if(!cr.convertible())return 0;
> >
> > AND
> >
> > "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/pytho
> >n/preprocessed/returning_non_void.hpp", line 37: error:
> >           expression must have (pointer-to-) function type
> >       PyObject*result=cr(((
> >
> > ???
> > Does anyone have any idea how to fix this?
> 
> Chuzo,
> 
>   When returning an internal reference you must specify a return policy,
>   such as return_internal_reference<>(). The compiler error gives
>   you a hint to this in the second declaration..
> 
>  "boost::python::detail::specify_a_result_policy_to_wrap_functions_ret
>            urning<double &>" has no member "convertible"
>        if(!cr.convertible())return 0;
> 
>  Note the "specify_a_result_policy_to_wrap_functions_ret"
> 
>                     :-)
>                     ~~m
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From david.abrahams at rcn.com  Wed May 22 19:32:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 13:32:36 -0400
Subject: [C++-sig] Re: operator[]
References: <3CC74FEF.40D33773@llnl.gov> <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com> <3CEBCA20.EB2C3CAD@llnl.gov> <0205220950370U.21358@avalanche.llnl.gov> <3CEBD3B4.513BFE7D@llnl.gov>
Message-ID: <07af01c201b6$b6dfc870$6601a8c0@boostconsulting.com>

You can't return an internal reference to an object which isn't of class
type (a double in this case). C++ doubles are converted to Python floats by
copying; there's no Python type which can hold a reference to the
internally-held double. return_value_policy<copy_non_const_reference> is
your friend in this case.

-Dave

----- Original Message -----
From: "chuzo okuda" <okuda1 at llnl.gov>
To: <c++-sig at python.org>
Sent: Wednesday, May 22, 2002 1:21 PM
Subject: Re: [C++-sig] Re: operator[]


> Greeting Martin,
> You are right, but I got different error this time...
>
> I added:
>
> #include <boost/python/return_internal_reference.hpp>
> and added
> return_internal_reference<>()
> to the line becoming:
> .def("__getitem__", (double& (Vector2d::*)(const
> int))&Vector2d::operator[],return_internal_reference<>())
>
> and I get:
>
>
"/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/pytho
n/to_python_indirect.hpp",
> line 66: error:
>           incomplete type is not allowed
>             BOOST_STATIC_ASSERT(is_class<T>::value);
>
> :-(
> Chuzo






From david.abrahams at rcn.com  Wed May 22 19:50:45 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 13:50:45 -0400
Subject: [C++-sig] export a constant
References: <NFBBINAMBILHLOCDJKAEOEPDCBAA.ssmith@magnet.fsu.edu>
Message-ID: <07cc01c201b9$8472f8a0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Thanks David,
>
> But this did not work. In MSVC++ it give the following error:
>
> error C2065: 'make_ref' : undeclared identifier

Well, sorry, you need to qualify it as boost::python::make_ref...
...and I can't vouch for anything as old as Boost 1.25.0, but it should
work in 1.28.0

Good luck,
Dave






From david.abrahams at rcn.com  Wed May 22 20:07:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 14:07:55 -0400
Subject: [C++-sig] Re: Getting started with Boost.Python v2?
References: <3CEBBF8B.9030108@cynovad.com>
Message-ID: <07cd01c201bb$9e17d7b0$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Christian Hudon" <chrish at cynovad.com>

>
> we have a bunch of C++ code in-house that I'd like to be able to use
> from Python (for prototyping work, exploration, etc.). Since this will
> be for my personal use only (at least in the beginning), I thought I'd
> give Boost.Python v2 a try, to get all the benefits of the new-style
> classes (and generally so I don't have to port the thing from v1 to v2
> six months from now, if/when this get more widely used within the
> company).

Sounds like a good plan.

> Could you send me the instructions on getting started with
> Boost.Python v2?

Sure; but please in the future post questions to the C++-sig, where answers
will benefit everyone (and somebody else may answer them!)

1. Get the current boost CVS state from
http://sourceforge.net/cvs/?group_id=7586
2. Get the mpl-development branch of boost/mpl. From the boost root
directory:

    cvs update -d -rmpl-development boost/mpl

3. cd to the libs/python/test directory
4. bjam -sTOOLS=<my-toolset> test to build and run the tests

See documentation in libs/python/doc/v2/reference.html

To make your own Jamfile which builds an extension, use the following
template:

---
project-root ;

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

local PYTHON_PROPERTIES = $(BOOST_PYTHON_V2_PROPERTIES) ;

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

# declare a test
boost-python-runtest my_test : my_test_driver.py <pyd>my_module
    : <library-path>path-to-boost_python <findlibs>boost_python
    ;

----

> I also saw your summaries for March, April, etc. Thanks for writing
> these! I'd have a quick question and maybe a suggestion. The question
> is, would you say that Boost.Python v2 as it stands now it about on par
> (feature-wise, excluding the documentation) with v1?

Getting close. By early next month we'll be there, and I'll retire v1.

> The suggestion is,
> it's be really helpful in seeing how v2 is shaping up if you could add a
>    Done keyword to the items in the "Development Goals" list on
> http://www.python.org/sigs/c++-sig/ and update that when you write a new
> monthly summary. That way it's be easier than reading all the montly
> summaries for newbies to Boost.Python (like me) to get an overview of
> where v2 currently is.

A nice idea, but I don't control that page. Ralf runs C++-sig, and can only
get the page updated indirectly by making a request, so I don't think we'll
change it frequently. However, when v2 is released it will be updated.

> PS On http://www.boost.org/libs/python/doc/index.html, there's a typo in
> one of the URLs: "Boost.Python is known to have been tested
> against <a href="http://www.python/org/2.2.1">Python 2.2.1</a> using
> the following compilers"         ^^^ This should probably be a period,
> unless Python gets its own TLD soon. :-)


Hmm, thanks. I probably won't fix it, since it isn't long for this world
;-)

-Dave






From okuda1 at llnl.gov  Wed May 22 20:34:49 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Wed, 22 May 2002 11:34:49 -0700
Subject: [C++-sig] Re: operator[]
References: <3CC74FEF.40D33773@llnl.gov> <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com> <3CEBCA20.EB2C3CAD@llnl.gov> <0205220950370U.21358@avalanche.llnl.gov> <3CEBD3B4.513BFE7D@llnl.gov> <07af01c201b6$b6dfc870$6601a8c0@boostconsulting.com>
Message-ID: <3CEBE4C9.2AAFB266@llnl.gov>

Dave - It is working now. Thanks :-)  - Chuzo


David Abrahams wrote:
> 
> You can't return an internal reference to an object which isn't of class
> type (a double in this case). C++ doubles are converted to Python floats by
> copying; there's no Python type which can hold a reference to the
> internally-held double. return_value_policy<copy_non_const_reference> is
> your friend in this case.
> 
> -Dave
> 
> ----- Original Message -----
> From: "chuzo okuda" <okuda1 at llnl.gov>
> To: <c++-sig at python.org>
> Sent: Wednesday, May 22, 2002 1:21 PM
> Subject: Re: [C++-sig] Re: operator[]
> 
> > Greeting Martin,
> > You are right, but I got different error this time...
> >
> > I added:
> >
> > #include <boost/python/return_internal_reference.hpp>
> > and added
> > return_internal_reference<>()
> > to the line becoming:
> > .def("__getitem__", (double& (Vector2d::*)(const
> > int))&Vector2d::operator[],return_internal_reference<>())
> >
> > and I get:
> >
> >
> "/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/pytho
> n/to_python_indirect.hpp",
> > line 66: error:
> >           incomplete type is not allowed
> >             BOOST_STATIC_ASSERT(is_class<T>::value);
> >
> > :-(
> > Chuzo
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From ssmith at magnet.fsu.edu  Wed May 22 21:35:36 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 22 May 2002 15:35:36 -0400
Subject: [C++-sig] export a constant
In-Reply-To: <07cc01c201b9$8472f8a0$6601a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAECEPMCBAA.ssmith@magnet.fsu.edu>

> you need to qualify it as boost::python::make_ref...
> ...and I can't vouch for anything as old as Boost 1.25.0, but it should
> work in 1.28.0

For those who care, this worked fine in 1.25.0.

Thanks Dave,

Scott


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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From ssmith at magnet.fsu.edu  Wed May 22 21:41:19 2002
From: ssmith at magnet.fsu.edu (Scott Smith)
Date: Wed, 22 May 2002 15:41:19 -0400
Subject: [C++-sig] Link trouble on OS X
Message-ID: <E36F6E4D-6DBB-11D6-A01B-0050E460CF76@magnet.fsu.edu>

Hello,

In trying to educate myself on Boost I decided to try and build 
Boost.Python
on a fresh Mac OS X. I installed Python 2.2.1-1 and downloaded Boost
1.28.0. I then built Jam with seemingly no problems, set my environment 
variables,
and tried to build Boost.Python. It seemed fine (just the same warning 
about long doubles) until it hit the linking step:

gcc-Link-action 
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
runtime-link-dynamic/shared-linkable-true/libboost_python.so
/usr/bin/ld: can't locate file for: -lutil

I don't know where the util library is supposed to come from, but if I 
can find it
I think the build will complete. Anyone know what this is?

Thanks,
Scott





From achim.domma at syynx.de  Wed May 22 22:23:03 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 22 May 2002 22:23:03 +0200
Subject: [C++-sig] def_init required
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEODDFAA.achim.domma@syynx.de>

Hi,

see below a small test extension. If I don't call def_init on
class_<HelloWorld> I can load the extension and create an object, but if I
call 'showIt', I get the following error:

TypeError: bad argument type for built-in operation

Is def_init required for each class?

Achim

---- code -----

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

struct HelloWorld {
	HelloWorld(){};
	void showIt() {
		std::cout << "Hello World";
	}
};

BOOST_PYTHON_MODULE_INIT(HelloWorld)
{
    using namespace boost::python;
	module m("HelloWorld");

	m.add(
			class_<HelloWorld>("HelloWorld")
				.def_init()	// if missing -> type error
				.def("showIt",&HelloWorld::showIt)
		 );
}

---- code -----






From david.abrahams at rcn.com  Wed May 22 23:21:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 17:21:28 -0400
Subject: [C++-sig] Link trouble on OS X
References: <E36F6E4D-6DBB-11D6-A01B-0050E460CF76@magnet.fsu.edu>
Message-ID: <085201c201d6$b2822d20$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Wednesday, May 22, 2002 3:41 PM
Subject: [C++-sig] Link trouble on OS X


> Hello,
>
> In trying to educate myself on Boost I decided to try and build
> Boost.Python
> on a fresh Mac OS X. I installed Python 2.2.1-1 and downloaded Boost
> 1.28.0. I then built Jam with seemingly no problems, set my environment
> variables,
> and tried to build Boost.Python. It seemed fine (just the same warning
> about long doubles) until it hit the linking step:
>
> gcc-Link-action
>
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
> runtime-link-dynamic/shared-linkable-true/libboost_python.so
> /usr/bin/ld: can't locate file for: -lutil
>
> I don't know where the util library is supposed to come from, but if I
> can find it
> I think the build will complete. Anyone know what this is?

This was needed for GCC under cygwin and Linux, so I assumed it was a GCC
dependency, but I never built it on OS X. Try reproducing the command-line
by hand without -lutil and see if everything works. If it does, I'll edit
that out of the Jam file for the OS X case.

-Dave






From david.abrahams at rcn.com  Wed May 22 23:25:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 17:25:09 -0400
Subject: [C++-sig] def_init required
References: <FCEMIEFBFOIDAOJDEPIAMEODDFAA.achim.domma@syynx.de>
Message-ID: <087101c201d7$66195d90$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: "C++-Sig at Python. Org" <c++-sig at python.org>
Sent: Wednesday, May 22, 2002 4:23 PM
Subject: [C++-sig] def_init required


> Hi,
>
> see below a small test extension. If I don't call def_init on
> class_<HelloWorld> I can load the extension and create an object, but if
I
> call 'showIt', I get the following error:
>
> TypeError: bad argument type for built-in operation
>
> Is def_init required for each class?

If the instance is going to be created by calling the class, then yes.
That's what creates the C++ instance. I plan to try to do something which
will create a default def_init() if you don't declare one, but I'm not sure
whether it's possible.

-Dave






From okuda1 at llnl.gov  Thu May 23 00:38:46 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Wed, 22 May 2002 15:38:46 -0700
Subject: [C++-sig] default arguments
Message-ID: <3CEC1DF6.E9CC018@llnl.gov>

I cannot remember about reading any emails about default arguments, but
it seems that it does not work at present.

--- code ---
#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
using namespace boost::python;
#include <iostream>

/************************************************************/
/*                                                          */
/*             test of default arguments                    */
/*                                                          */
/************************************************************/

std::string testString(std::string s="Hello World") {return s;}
int testInteger(int i1, int i2, int i3=3, int i4=4, int i5=5) {
   return i1 + i2 + i3 + i4 + i5;
}

BOOST_PYTHON_MODULE_INIT(defaultArgTest)
{
   module("defaultArgTest")
      .def("testString", &testString)
      .def("testInteger", &testInteger)
      ;
}
-------

testString() should print "Hello World" and testInteger(0,0) should
print 12 like in C++ code, but instead I got TypeError message...


gps01(374) python
Adding parser accelerators ...
Done.
Python 2.2 (#1, Jan 22 2002, 14:39:03) [C] on osf1V5
Type "help", "copyright", "credits" or "license" for more information.
>>> from defaultArgTest import *
>>> testString("hi")
'hi'
>>> testString()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
>>> testInteger(0,0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
>>> testInteger(0,0,1,1,1)
3
>>>




From david.abrahams at rcn.com  Thu May 23 02:05:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 22 May 2002 20:05:23 -0400
Subject: [C++-sig] default arguments
References: <3CEC1DF6.E9CC018@llnl.gov>
Message-ID: <089201c201ee$0809f630$6601a8c0@boostconsulting.com>

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


> I cannot remember about reading any emails about default arguments, but
> it seems that it does not work at present.
>
> --- code ---
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> using namespace boost::python;
> #include <iostream>
>
> /************************************************************/
> /*                                                          */
> /*             test of default arguments                    */
> /*                                                          */
> /************************************************************/
>
> std::string testString(std::string s="Hello World") {return s;}
> int testInteger(int i1, int i2, int i3=3, int i4=4, int i5=5) {
>    return i1 + i2 + i3 + i4 + i5;
> }
>
> BOOST_PYTHON_MODULE_INIT(defaultArgTest)
> {
>    module("defaultArgTest")
>       .def("testString", &testString)
>       .def("testInteger", &testInteger)
>       ;
> }
> -------
>
> testString() should print "Hello World" and testInteger(0,0) should
> print 12 like in C++ code, but instead I got TypeError message...

It would be nice, wouldn't it? However, there's no way to make the C++ code
you wrote do that. Once you take the address of a function all information
about its default args is lost. Default argument support will take some
work from you, and some from me. In other words, there's no support for it
in the library yet, but even when it's there, you'll need to write some
more code to take advantage of it.

For the time being, you can use 3 thin wrapper functions which call
testInteger:

int testInteger1(int i1, int i2, int i3, int i4) {
    return testInteger(i1,i2,i3,i4);
}

int testInteger2(int i1, int i2, int i3) {
    return testInteger(i1,i2,i3);
}

int testInteger3(int i1, int i2) {
    return testInteger(i1,i2);
}


...

      .def("testInteger", &testInteger)
      .def("testInteger", &testInteger1)
      .def("testInteger", &testInteger2)

      .def("testInteger", &testInteger3)



-Dave





From ssmith at magnet.fsu.edu  Thu May 23 13:28:26 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 23 May 2002 07:28:26 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <085201c201d6$b2822d20$6601a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEAEPOCBAA.ssmith@magnet.fsu.edu>

Hi Dave,


> > gcc-Link-action
> >
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
> > runtime-link-dynamic/shared-linkable-true/libboost_python.so
> > /usr/bin/ld: can't locate file for: -lutil

> This was needed for GCC under cygwin and Linux, so I assumed it was a GCC
> dependency, but I never built it on OS X. Try reproducing the command-line
> by hand without -lutil and see if everything works. If it does, I'll edit
> that out of the Jam file for the OS X case.

I guess I need clarification. The command gcc-Link-action appears to be some
sort of macro that Jam uses and I don't know what that is. No where on any
build line echoed to the screen is -lutil written, only on the error line.
Nor can I find util in any of the mak files, or the definition of
gcc-Link-action.
In short, I don't know what/where I should be editing this. To me the output
appears significantly different than that from a makefile, or I could do
what you ask.
I did try running the subsequent command (gcc ...) without -lutil but this
produced
a lot of errors about undefined symbols such as _PyErr_* that don't look at
all related
to util.

Thanks,
Scott

P.S. I only tried to build 1.28.0 because you said 1.25.0 was so ancient!
     Even worse, I can't get the build to work under CygWin either so I'll
     have more questions for this group in short order.

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu


> > gcc-Link-action
> >
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
> > runtime-link-dynamic/shared-linkable-true/libboost_python.so
> > /usr/bin/ld: can't locate file for: -lutil

> This was needed for GCC under cygwin and Linux, so I assumed it was a GCC
> dependency, but I never built it on OS X. Try reproducing the command-line
> by hand without -lutil and see if everything works. If it does, I'll edit
> that out of the Jam file for the OS X case.
>
> -Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Thu May 23 13:45:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 23 May 2002 07:45:06 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEAEPOCBAA.ssmith@magnet.fsu.edu>
Message-ID: <007c01c2024f$ae336170$6501a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> I guess I need clarification. The command gcc-Link-action appears to be
some
> sort of macro that Jam uses and I don't know what that is. No where on
any
> build line echoed to the screen is -lutil written, only on the error
line.

Add -d+2 to your bjam command-line and you'll see all of the commands it
uses to build the targets.

> Nor can I find util in any of the mak files, or the definition of
> gcc-Link-action.
> In short, I don't know what/where I should be editing this. To me the
output
> appears significantly different than that from a makefile, or I could do
> what you ask.
> I did try running the subsequent command (gcc ...) without -lutil but
this
> produced
> a lot of errors about undefined symbols such as _PyErr_* that don't look
at
> all related
> to util.

Actually, that's the way Jam works if you don't specify -d+2: the command
used to build the target is hidden unless there's an error, in which case
it is printed following the error output. In other words, the command-line
you're seeing there following the error is the right one.

I'll tell you what; if you "hold my hand" with getting set up with OS X
development, I'll try to get the build working there. My wife has an ibook
I can use. What do I need to do to get the tools in place, including
Python?

> Thanks,
> Scott
>
> P.S. I only tried to build 1.28.0 because you said 1.25.0 was so ancient!
>      Even worse, I can't get the build to work under CygWin either so
I'll
>      have more questions for this group in short order.

bjam doesn't currently have a working Cygwin version. To build with your
cygwin compiler, you just use it from your regular command-shell; I do that
all the time.





From ssmith at magnet.fsu.edu  Thu May 23 14:16:09 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 23 May 2002 08:16:09 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <007c01c2024f$ae336170$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEAEPPCBAA.ssmith@magnet.fsu.edu>

Hi again Dave,

> Add -d+2 to your bjam command-line and you'll see all of the commands it
> uses to build the targets.
> Actually, that's the way Jam works if you don't specify -d+2: the command
> used to build the target is hidden unless there's an error, in which case
> it is printed following the error output. In other words, the command-line
> you're seeing there following the error is the right one.

OK, then it is a problem with knowing where the libraries are. There was an

                       export LD_LIBRARY_PATH

command issued prior to the linking which would no be accepted before I
tried
to do the linking with by hand. This must be the problem. I don't know what
that was set to, or I could just set and export it by hand too.

The build command

                  bjam -sTOOLS=gcc -sBUILD=release -d+2

pretty much echoed the same thing. It does the export command shown above
then tries to link all of the object files to generate an so library but
cannot find the util library.

> I'll tell you what; if you "hold my hand" with getting set up with OS X
> development, I'll try to get the build working there. My wife has an ibook
> I can use. What do I need to do to get the tools in place, including
> Python?

Well, I thought it would be the other way around! Here is what I did on
a fresh OS X machine (bear in mind that I am not a Mac expert)

1.) Installed the "Darwin Collection" which has the Gnu Tools in it.
    This is on the Apple Developer Tools CD or you can download it from

http://www.apple.com/downloads/macosx/unix_apps_utilities/thedarwincollectio
n.html

    if you have a good internet connection. If you already have all of this
    installed then you may not need this step.

2.) Next I installed both Fink and Fink Commander. The former is a package
    manager that ties into SourceForge and the latter is a nice GUI that
    you can run to simplify installation of packages. These are at

http://www.apple.com/downloads/macosx/unix_apps_utilities/fink.html
http://www.apple.com/downloads/macosx/unix_apps_utilities/finkcommander.html

    repectively.

3.) Using Fink Commander I installed (from sources) Python.

At this point I have a working GCC compiler and a working Python so I build
Jam and then tried BOOST.

I don't mind rebuilding Jam with some simple changes if you could give me a
clue as to what I might try changing. Perhaps this would be a good thing
for me to look over in light of the troubles I am having with the CygWin
build.

> bjam doesn't currently have a working Cygwin version. To build with your
> cygwin compiler, you just use it from your regular command-shell;
> I do that all the time.

For clarification: Are you saying I should rebuild jam/bjam with GCC under
                   CygWin (as I did with Mac OS X), then the Boost(.Python)
build
                   will work just fine?

At the moment, I tried the pre-build jam but the build of Boost.Python fails
because it never figures out where the Python includes are. It always looks
in /usr/local/include regardless of what environment variables are set.

Thanks a whole lot,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu

> bjam doesn't currently have a working Cygwin version. To build with your
> cygwin compiler, you just use it from your regular command-shell;
> I do that all the time.
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Thu May 23 14:40:28 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 23 May 2002 08:40:28 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEAEPPCBAA.ssmith@magnet.fsu.edu>
Message-ID: <00b401c20257$2338a3c0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> OK, then it is a problem with knowing where the libraries are. There was
an
>
>                        export LD_LIBRARY_PATH
>
> command issued prior to the linking

Yes.

> which would no be accepted before I tried to do the linking with by hand.

Huh? I can't understand what that means.

> This must be the problem. I don't know what
> that was set to, or I could just set and export it by hand too.

It gets set by the build command as it runs. If you're not seeing
LD_LIBRAY_PATH=... on the immediately preceding line, it's getting set to
something empty, which is probably a bug.

> The build command
>
>                   bjam -sTOOLS=gcc -sBUILD=release -d+2
>
> pretty much echoed the same thing. It does the export command shown above
> then tries to link all of the object files to generate an so library but
> cannot find the util library.


> > I'll tell you what; if you "hold my hand" with getting set up with OS X
> > development, I'll try to get the build working there. My wife has an
ibook
> > I can use. What do I need to do to get the tools in place, including
> > Python?
>
> Well, I thought it would be the other way around! Here is what I did on
> a fresh OS X machine (bear in mind that I am not a Mac expert)
>
> 1.) Installed the "Darwin Collection" which has the Gnu Tools in it.
>     This is on the Apple Developer Tools CD or you can download it from
>
>
http://www.apple.com/downloads/macosx/unix_apps_utilities/thedarwincollecti
o
> n.html
>
>     if you have a good internet connection. If you already have all of
this
>     installed then you may not need this step.
>
> 2.) Next I installed both Fink and Fink Commander. The former is a
package
>     manager that ties into SourceForge and the latter is a nice GUI that
>     you can run to simplify installation of packages. These are at
>
> http://www.apple.com/downloads/macosx/unix_apps_utilities/fink.html
>
http://www.apple.com/downloads/macosx/unix_apps_utilities/finkcommander.htm
l
>
>     repectively.
>
> 3.) Using Fink Commander I installed (from sources) Python.

What about CVS? I'd like to get the boost CVS state there.

> At this point I have a working GCC compiler and a working Python so I
build
> Jam and then tried BOOST.

> I don't mind rebuilding Jam with some simple changes if you could give me
a
> clue as to what I might try changing.

There's absolutely no need for rebuilding Jam. All of the logic is
happening in (interpreted) .jam files.

> Perhaps this would be a good thing
> for me to look over in light of the troubles I am having with the CygWin
> build.
>
> > bjam doesn't currently have a working Cygwin version. To build with
your
> > cygwin compiler, you just use it from your regular command-shell;
> > I do that all the time.
>
> For clarification: Are you saying I should rebuild jam/bjam with GCC
under
>                    CygWin (as I did with Mac OS X), then the
Boost(.Python)
> build
>                    will work just fine?

No, I'm saying that if you rebuild it under cygwin, the bjam executable
won't work (for some reason). If you want to build cygwin versions of your
other software, just use the prebuilt version of bjam you already have from
your regular Windows command-shell.

> At the moment, I tried the pre-build jam but the build of Boost.Python
fails
> because it never figures out where the Python includes are. It always
looks
> in /usr/local/include regardless of what environment variables are set.

I don't believe it. What environment variables are you setting?
(Note that the pre-built bjam won't see any cygwin bash environment
variables)

-Dave






From ssmith at magnet.fsu.edu  Thu May 23 15:21:35 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 23 May 2002 09:21:35 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <00b401c20257$2338a3c0$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEEEACCCAA.ssmith@magnet.fsu.edu>

Hi Dave,

> > It is a problem with knowing where the libraries are. There was
> an
> >
> >                        export LD_LIBRARY_PATH
> >
> > command issued prior to the linking

> It gets set by the build command as it runs. If you're not seeing
> LD_LIBRAY_PATH=... on the immediately preceding line, it's getting set to
> something empty, which is probably a bug.

Correct, there is no line that sets LD_LIBRARY_PATH prior to the command
to export it. Do you know what it should be set to? If so,  can set it
by hand and try things once more.

> > 3.) Using Fink Commander I installed (from sources) Python.
>
> What about CVS? I'd like to get the boost CVS state there.

Although I have not done this (opting for what I thought was a "safer"
route to getting Boost.Python running on OS X) but you can install CVS from
Fink Commander as well. Additionally, OS X has a terminal window (tsh) that
you can run unix commands in and you can install bash from F.C. too.

> There's absolutely no need for rebuilding Jam. All of the logic is
> happening in (interpreted) .jam files.

Point me to the one that sets things up for Boost.Python and I'll have
a look. The only thing I see is JamFile in libs/python/build.

> No, I'm saying that if you rebuild it under cygwin, the bjam executable
> won't work (for some reason). If you want to build cygwin versions of your
> other software, just use the prebuilt version of bjam you already
> have from your regular Windows command-shell.

I am using the prebuilt jam.

> > At the moment, I tried the pre-build jam but the build of Boost.Python
fails
> > because it never figures out where the Python includes are. It always
looks
> > in /usr/local/include regardless of what environment variables are set.

> I don't believe it. What environment variables are you setting?
> (Note that the pre-built bjam won't see any cygwin bash environment
> variables)

OK, then I must be doing something conceptually stupid. I am using the
pre-built bjam for Windows. I am working in a CygWin bash shell. When I have
bad or no environment variables set then running bjam just echoes a message
about how it cannot build Boost.Python with out them set. When I set them,
bjam attempts to build Boost.Python but cannot because it never sees the
Python includes. Here are the details:

I put Python 2.2.1 in C:\Program Files\Python22
I put Boost 1.28.0 in C:\Program Files\Boost\boost_1_28_0
I put the latest bjam in my path, C:\usr\local\bin
I opened a Cygwin bash shell and changed into directory
       C:\Program Files\Boost\boost_1_28_0\libs\python\build
I set the environment variables from the bash shell this way
       $ PYTHON_ROOT="C:\Program Files\Python22"
       $ export PYTHON_ROOT
       $ PYTHON_VERSION="2.2"
       $ export PYTHON_VERSION
I can see these are set in the environment via the command "env"
I believe something is set for Jam since it tries to build Boost.Python
I run bjam with the following
       bjam -sTOOLS=gcc -sBUILD=release
Here is part of the output from that

$ bjam -sTOOLS=gcc -sBUILD=release
...found 202 targets...
...updating 14 targets...
gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\types.obj
In file included from c:/Program
Files/Boost/boost_1_28_0/boost/python/errors.hpp:13,
                 from c:/Program
Files/Boost/boost_1_28_0/boost/python/detail/call_object.hpp:8,
                 from ../src\types.cpp:11:
c:/Program Files/Boost/boost_1_28_0/boost/python/detail/wrap_python.hpp:24:
patchlevel.h: No such file or directory
In file included from c:/Program
Files/Boost/boost_1_28_0/boost/python/errors.hpp:13,
                 from c:/Program
Files/Boost/boost_1_28_0/boost/python/detail/call_object.hpp:8,
                 from ../src\types.cpp:11:
c:/Program Files/Boost/boost_1_28_0/boost/python/detail/wrap_python.hpp:105:
Python.h: No such file or directory
In file included from c:/Program
Files/Boost/boost_1_28_0/boost/python/detail/cast.hpp:13,
                 from c:/Program
Files/Boost/boost_1_28_0/boost/python/detail/types.hpp:26,
                 from c:/Program
Files/Boost/boost_1_28_0/boost/python/detail/call_object.hpp:9,
                 from ../src\types.cpp:11:
.
.
.

Finally, here is why I mentioned /usr/local/include

g++  -c -Wall -ftemplate-depth-100  -DNDEBUG -DUSE_DL_IMPORT -DBOOST_PYTHON_
DYNAMIC_LIB  -O3 -Wno-inline  -fomit-frame-pointer -foptimize-sibling-calls 
 -I"..\..\..\libs\python\build" -I"." -I"c:\Program
Files\Boost\boost_1_28_0" -I"\usr\local\include\python2.2"   -o
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\types.obj"  "../src\types.cpp"

As you can see: -I"\usr\local\include\python2.2"

So, what in the above steps is wrong? Do I have to use CygWin's Python
rather
that that I downloaded? Do I need to use simpler install directories? Is it
true that the bash environment variables are not seen by Jam (It must see
something)?
I tried to alter the environment variables in case the space in "Program
Files" was
the problem, didn't work. I tried to move the Python directory to something
easy
(C:\Python22), didn't help. I tried copying the Python include directory to
/usr/local/inlcude
and that didn't work either.

My apologies for all the clutter, I'm sure you can help me overcome my
stupidiy.

Regards,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From david.abrahams at rcn.com  Thu May 23 16:12:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 23 May 2002 10:12:51 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEEEACCCAA.ssmith@magnet.fsu.edu>
Message-ID: <00e901c20264$82819230$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hi Dave,
>
> > > It is a problem with knowing where the libraries are. There was
> > an
> > >
> > >                        export LD_LIBRARY_PATH
> > >
> > > command issued prior to the linking
>
> > It gets set by the build command as it runs. If you're not seeing
> > LD_LIBRAY_PATH=... on the immediately preceding line, it's getting set
to
> > something empty, which is probably a bug.
>
> Correct, there is no line that sets LD_LIBRARY_PATH prior to the command
> to export it. Do you know what it should be set to? If so,  can set it
> by hand and try things once more.

Actually, I was wrong. In the case of building libboost_python, there are
in fact no dependencies so the simple export statement should be fine.

> > > 3.) Using Fink Commander I installed (from sources) Python.
> >
> > What about CVS? I'd like to get the boost CVS state there.
>
> Although I have not done this (opting for what I thought was a "safer"
> route to getting Boost.Python running on OS X) but you can install CVS
from
> Fink Commander as well.

OK.

> Additionally, OS X has a terminal window (tsh) that
> you can run unix commands in and you can install bash from F.C. too.

Sure; I don't know what bash has to do with it, though.

> > There's absolutely no need for rebuilding Jam. All of the logic is
> > happening in (interpreted) .jam files.
>
> Point me to the one that sets things up for Boost.Python and I'll have
> a look. The only thing I see is JamFile in libs/python/build.

You can look at tools/build/python.jam if you can understand it. However,
if you want me to help what I need from you is information about a link
command-line that works. For that, you can just do experiments by hand
until you find something that works.

> > No, I'm saying that if you rebuild it under cygwin, the bjam executable
> > won't work (for some reason). If you want to build cygwin versions of
your
> > other software, just use the prebuilt version of bjam you already
> > have from your regular Windows command-shell.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This means "cmd.exe"

> > > At the moment, I tried the pre-build jam but the build of
Boost.Python
> fails
> > > because it never figures out where the Python includes are. It always
> looks
> > > in /usr/local/include regardless of what environment variables are
set.
>
> > I don't believe it. What environment variables are you setting?
> > (Note that the pre-built bjam won't see any cygwin bash environment
> > variables)

Or maybe I'm wrong about that parenthesized statement.

> OK, then I must be doing something conceptually stupid. I am using the
> pre-built bjam for Windows. I am working in a CygWin bash shell.
>
> When I have
> bad or no environment variables set then running bjam just echoes a
message
> about how it cannot build Boost.Python with out them set. When I set
them,
> bjam attempts to build Boost.Python but cannot because it never sees the
> Python includes. Here are the details:

Ah; those instructions are incomplete, sorry. Please see
http://www.boost.org/libs/python/doc/building.html

You need GCC_PYTHON_ROOT

> So, what in the above steps is wrong? Do I have to use CygWin's Python
> rather
> that that I downloaded?

Yes. This is a Cygwin (not Boost) limitation. Also you may need to build
your own Cygwin version of Python from within cygwin to do this, if Cygwin
doesn't supply the version of Python you want.

> Do I need to use simpler install directories? Is it
> true that the bash environment variables are not seen by Jam (It must see
> something)?

No I was wrong about that.

> I tried to alter the environment variables in case the space in "Program
> Files" was
> the problem, didn't work. I tried to move the Python directory to
something
> easy
> (C:\Python22), didn't help. I tried copying the Python include directory
to
> /usr/local/inlcude
> and that didn't work either.
>
> My apologies for all the clutter, I'm sure you can help me overcome my
> stupidiy.

It's not stupidity. I hope this helps

-Dave






From ssmith at magnet.fsu.edu  Thu May 23 17:27:05 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 23 May 2002 11:27:05 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <00e901c20264$82819230$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEOEADCCAA.ssmith@magnet.fsu.edu>

Hi Dave,

I've clipped out the CygWin stuff and rewrite with a different Subject
when I have time to reattempt the build.

> You can look at tools/build/python.jam if you can understand it. However,
> if you want me to help what I need from you is information about a link
> command-line that works. For that, you can just do experiments by hand
> until you find something that works.

OK. Here is the exact output from jam when I do the build.

    export LD_LIBRARY_PATH
    c++   -s -fPIC -shared  -o
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
on2.2/config
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/types.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/classes.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/conversions.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/extension_class.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/functions.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/init_function.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/module_builder.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/objects.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/cross_module.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/errors.o"    -lutil


/usr/bin/ld: can't locate file for: -lutil

I looked around for any util library but cannot find it. I also just tried a
simpler version

export LD_LIBRARY_PATH

c++   -s -fPIC -shared  -o
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
on2.2/config
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/types.o"

but this left me with complaints that it could not find anything. Here is
the output from that.

/usr/bin/ld: Undefined symbols:
_main
_PyErr_SetObject
_PyErr_SetString
_PyExc_IndexError
_PyExc_RuntimeError
_PyExc_ValueError
___Q35boost6python6stringPCc
___apl__Q35boost6python6stringRCB0
___builtin_delete
___builtin_new
___cp_push_exception
___eh_alloc
___pure_virtual
___rtti_si
___rtti_user
___throw
___vt_9exception
_get__CQ35boost6python6object
_handle_exception_impl__Q25boost6pythonGQ25boostt9function04ZvZQ25boost21emp
ty_function_policyZQ25boost20empty_function_mixinZt9allocator1ZQ25boost13fun
ction_base
_terminate__Fv
___eprintf
___tf9exception
___ti9exception

If you can give me some clues as to what I should add in to the compilation
command or what
should be set for LD_LIBRARY_PATH I'll be happy to give it and variants a
try. In the meantime
I will look around for any known problems with OS X and builds of shared
libraries.

Best Regards,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From beazley at cs.uchicago.edu  Thu May 23 18:21:02 2002
From: beazley at cs.uchicago.edu (David Beazley)
Date: Thu, 23 May 2002 11:21:02 -0500 (CDT)
Subject: [C++-sig] Re: Link trouble on OS-X
In-Reply-To: <20020523160006.14311.25492.Mailman@mail.python.org>
References: <20020523160006.14311.25492.Mailman@mail.python.org>
Message-ID: <15597.5870.524411.232953@gargoyle.cs.uchicago.edu>

 > 
 > If you can give me some clues as to what I should add in to the compilation
 > command or what
 > should be set for LD_LIBRARY_PATH I'll be happy to give it and variants a
 > try. In the meantime
 > I will look around for any known problems with OS X and builds of shared
 > libraries.
 > 

For what it's worth, here are the compilation/linking options used by
SWIG on OS-X with GCC.  This does appear to produce working extension
modules (although with all of the discussion of C++ dynamic loading
these days, one is never quite sure anymore :-).

 % c++ -c $(SRCS) -I/sw/include/python2.2 -I/sw/lib/python2.2/config -DHAVE_CONFIG_H
 % c++ -bundle -undefined suppress -flat_namespace $(OBJS) -o somemodule.so

Replace $(SRCS) and $(OBJS) by whatever you are using for your
extension module.   

Cheers,

Dave






From rwgk at yahoo.com  Thu May 23 18:28:36 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 23 May 2002 09:28:36 -0700 (PDT)
Subject: [C++-sig] default arguments
In-Reply-To: <089201c201ee$0809f630$6601a8c0@boostconsulting.com>
Message-ID: <20020523162836.26595.qmail@web20209.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> It would be nice, wouldn't it? However, there's no way to make the C++ code
> you wrote do that. Once you take the address of a function all information
> about its default args is lost. Default argument support will take some
> work from you, and some from me. In other words, there's no support for it
> in the library yet, but even when it's there, you'll need to write some
> more code to take advantage of it.
> 
> For the time being, you can use 3 thin wrapper functions which call
> testInteger:
> 
> int testInteger1(int i1, int i2, int i3, int i4) {
>     return testInteger(i1,i2,i3,i4);
> }
> 
> int testInteger2(int i1, int i2, int i3) {
>     return testInteger(i1,i2,i3);
> }
> 
> int testInteger3(int i1, int i2) {
>     return testInteger(i1,i2);
> }

A large fraction of my Boost.Python V1 code consists of this kind of thin
wrappers. It is a real nuisance. What is the expected time of arrival for the
improved support for default arguments? Any chance this happens before next
week? <wink>
Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com




From david.abrahams at rcn.com  Thu May 23 18:32:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 23 May 2002 12:32:53 -0400
Subject: [C++-sig] default arguments
References: <20020523162836.26595.qmail@web20209.mail.yahoo.com>
Message-ID: <01bd01c20277$8d5e5a90$6501a8c0@boostconsulting.com>

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

> A large fraction of my Boost.Python V1 code consists of this kind of thin
> wrappers. It is a real nuisance. What is the expected time of arrival for
the
> improved support for default arguments? Any chance this happens before
next
> week? <wink>

Not much, unless you're going to do it yourself. I'm focusing on trying to
get all the v1 replacement functionality in there first.

-Dave






From randre at pppl.gov  Thu May 23 19:00:10 2002
From: randre at pppl.gov (Robert Andre)
Date: Thu, 23 May 2002 13:00:10 -0400
Subject: [C++-sig] Re: Link trouble on OS X
In-Reply-To: <20020523160006.14311.25492.Mailman@mail.python.org>
References: <20020523160006.14311.25492.Mailman@mail.python.org>
Message-ID: <200205231700.NAA04907@pppl.gov>

This is the best link that I know of for help in porting to Mac OSX.  Note
the environment variable is DYLD_LIBRARY_PATH

http://fink.sourceforge.net/doc/porting/shared.php

I tried porting boost python several months ago to Mac OSX with makefiles.
I got everything to compile and simple examples would work but more complex
ones left me with uninstantiated template classes.  You may have more luck.

rob




From rwgk at yahoo.com  Thu May 23 19:04:18 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 23 May 2002 10:04:18 -0700 (PDT)
Subject: [C++-sig] default arguments
In-Reply-To: <01bd01c20277$8d5e5a90$6501a8c0@boostconsulting.com>
Message-ID: <20020523170418.82708.qmail@web20203.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> ----- Original Message -----
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > A large fraction of my Boost.Python V1 code consists of this kind of thin
> > wrappers. It is a real nuisance. What is the expected time of arrival for
> the
> > improved support for default arguments? Any chance this happens before
> next
> > week? <wink>
> 
> Not much, unless you're going to do it yourself.

What is involved? Do you have an idea for an interface? A while ago I suggested
that the old V1 boost::python::constructor<T1, T2, ...> interface would be a
"good enough" solution. E.g. (old syntax):

void foo(int i, int j=1);

py_some_type.def(foo, boost::python::signature<int>(), "foo");
py_some_type.def(foo, boost::python::signature<int, int>(), "foo");

Hm, I guess that doesn't work for overloaded functions because current C++ does
not support taking a reference to a family of overloads.

How about (please forgive me if the casts are only approximations to the
correct syntax):

void foo(int i, int j=1);
void foo(const std::string& s, int j=1);

py_some_type.def((void (*)(int, int)) foo, boost::python::signature<int>(),
"foo");
py_some_type.def((void (*)(int, int)) foo, boost::python::signature<int,
int>(), "foo");
py_some_type.def((void (*)(const std::string&, int)) foo,
boost::python::signature<const std::string&>(), "foo");
py_some_type.def((void (*)(const std::string&, int)) foo,
boost::python::signature<const std::string&, int>(), "foo");

Something like this would be a good start. It would mean that I could
concentrate the bindings for a function in one.

Thanks,
        Ralf


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com




From david.abrahams at rcn.com  Thu May 23 18:04:52 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 23 May 2002 12:04:52 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEOEADCCAA.ssmith@magnet.fsu.edu>
Message-ID: <01a701c20273$a6d00360$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Thursday, May 23, 2002 11:27 AM
Subject: RE: [C++-sig] Link trouble on OS X


> Hi Dave,
>
> I've clipped out the CygWin stuff and rewrite with a different Subject
> when I have time to reattempt the build.
>
> > You can look at tools/build/python.jam if you can understand it.
However,
> > if you want me to help what I need from you is information about a link
> > command-line that works. For that, you can just do experiments by hand
> > until you find something that works.
>
> OK. Here is the exact output from jam when I do the build.
>
>     export LD_LIBRARY_PATH
>     c++   -s -fPIC -shared  -o
>
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
r
>
ntime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
<snip many lines>
> untime-link-dynamic/shared-linkable-true/errors.o"    -lutil
>
>
> /usr/bin/ld: can't locate file for: -lutil
>
> I looked around for any util library but cannot find it. I also just
tried a
> simpler version
>
> export LD_LIBRARY_PATH
>
> c++   -s -fPIC -shared  -o
>
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
r
>
ntime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
> on2.2/config
>
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
r
> untime-link-dynamic/shared-linkable-true/types.o"

I hope that's not the whole thing, you've left out most of the neccessary
.o files! You also left out the -L option which allows it to find the
Python library.


> but this left me with complaints that it could not find anything. Here is
> the output from that.
>
> /usr/bin/ld: Undefined symbols:
> _main
> _PyErr_SetObject
> _PyErr_SetString
> _PyExc_IndexError
> _PyExc_RuntimeError
> _PyExc_ValueError

OK, it looks like OS X might be one of those platforms which requires
linking against the Python library. Try adding -lpython to the command line

> ___Q35boost6python6stringPCc
> ___apl__Q35boost6python6stringRCB0

This is due to the fact that you left out some of the .o files, I'm pretty
sure

> ___builtin_delete
> ___builtin_new
> ___cp_push_exception
> ___eh_alloc
> ___pure_virtual
> ___rtti_si
> ___rtti_user
> ___throw
> ___vt_9exception

These are functions in your compiler's runtime library. Have you got
multiple versions of GCC installed? In particular, have you got a 2.95.x
and a 3.x version installed? If so, you may not have properly supplied
GCC_ROOT_DIRECTORY to let the build system know how to find the runtime.


> _get__CQ35boost6python6object
>
_handle_exception_impl__Q25boost6pythonGQ25boostt9function04ZvZQ25boost21em
p
>
ty_function_policyZQ25boost20empty_function_mixinZt9allocator1ZQ25boost13fu
n
> ction_base

More boost.python symbols probably due to missing .o files.

> _terminate__Fv
> ___eprintf
> ___tf9exception
> ___ti9exception

More missing symbols from the compiler's runtime.

> If you can give me some clues as to what I should add in to the
compilation
> command or what
> should be set for LD_LIBRARY_PATH

Don't worry about LD_LIBRARY_PATH; you don't need it for this part of the
build.

> I'll be happy to give it and variants a
> try. In the meantime
> I will look around for any known problems with OS X and builds of shared
> libraries.

HTH,
Dave





From randre at pppl.gov  Thu May 23 19:21:14 2002
From: randre at pppl.gov (Robert Andre)
Date: Thu, 23 May 2002 13:21:14 -0400
Subject: [C++-sig] dll?
In-Reply-To: <20020523160006.14311.25492.Mailman@mail.python.org>
References: <20020523160006.14311.25492.Mailman@mail.python.org>
Message-ID: <200205231721.NAA14179@pppl.gov>

What was the final conclusion to the dll thread which suggested using

  import sys
  sys.setdlopenflags(0x100|0x2)

to force sharing of symbols between extension modules?  I was quite 
appreciative of this since it fixed the two problems that I was having with 
boost python on linux/gcc 3.0.4.  The first problem was the loss of exception 
type information which was mentioned in the thread.  The other problem I had 
with a segfault deep in the stringstream class when using multiple dynamic 
libraries has also disappeared.  I tend to use a small wrapper python class 
where I put doctest documentation so I don't require the capability of forcing
this flag from within the C++ extension module.  If boost python acquires the 
feature of including docstrings then I would have less of a reason to have a 
wrapper class other then for setting the dlopen flags.

thanks,

rob




From rwgk at yahoo.com  Thu May 23 19:55:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 23 May 2002 10:55:42 -0700 (PDT)
Subject: [C++-sig] dll?
In-Reply-To: <200205231721.NAA14179@pppl.gov>
Message-ID: <20020523175542.10810.qmail@web20208.mail.yahoo.com>

--- Robert Andre <randre at pppl.gov> wrote:
> 
> What was the final conclusion to the dll thread which suggested using
> 
>   import sys
>   sys.setdlopenflags(0x100|0x2)
> 
> to force sharing of symbols between extension modules?  I was quite 
> appreciative of this since it fixed the two problems that I was having with 
> boost python on linux/gcc 3.0.4.  The first problem was the loss of exception
> 
> type information which was mentioned in the thread.  The other problem I had 
> with a segfault deep in the stringstream class when using multiple dynamic 
> libraries has also disappeared.  I tend to use a small wrapper python class 
> where I put doctest documentation so I don't require the capability of
> forcing
> this flag from within the C++ extension module.  If boost python acquires the
> 
> feature of including docstrings then I would have less of a reason to have a 
> wrapper class other then for setting the dlopen flags.

Currently my conclusion is to keep using the dlopenflags for the time being
(Linux only). There have been long discussions about this in several forums
(gcc, c++ standardization reflector) and I am hopeful that in a few years we
can do without the dlopenflags :-)

FWIW: All our extensions are part of packages. As you know, a Python package
must have a __init__.py file. If you set the dlopenflags in the __init__.py
files you can be sure that the dlopenflags are set before the C++ extension is
imported. Here is what we use:

% cat __init__.py

import sys
if (sys.platform == "linux2"):
  if (hasattr(sys, "setdlopenflags")):
    sys.setdlopenflags(0x100|0x2)

Unfortunately the dlopenflags are set globally. Potentially this could lead to
name clashes when subsequently importing "C" extension modules. For us this
does not present a problem, but one should keep this in mind.

Ralf


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com




From achim.domma at syynx.de  Thu May 23 21:13:08 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Thu, 23 May 2002 21:13:08 +0200
Subject: [C++-sig] apphelp.dll solved
Message-ID: <FCEMIEFBFOIDAOJDEPIAMEPFDFAA.achim.domma@syynx.de>

just for the records:
My apphelp.dll was simply a very stupid configuration chaos on my machine -
shame on me! Never accidentally mix differnet STL versions, it will produce
very random behavior and take days to find the error. :-(

thanks to all for your help
Achim






From achim.domma at syynx.de  Thu May 23 21:17:40 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Thu, 23 May 2002 21:17:40 +0200
Subject: [C++-sig] Codewarrior on Windows
Message-ID: <FCEMIEFBFOIDAOJDEPIAEEPGDFAA.achim.domma@syynx.de>

Is there a problem using boost.python with Codewarrior7 on Windows?
According to the documentation it is supported, but will the extension work
out-of-the-box with ActiveState Python or do I have to recompile something
from source?
Due to the C only interface of the python dll it should work, but I would
like to ask first ...

greetings
Achim






From david.abrahams at rcn.com  Thu May 23 22:09:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 23 May 2002 16:09:22 -0400
Subject: [C++-sig] Codewarrior on Windows
References: <FCEMIEFBFOIDAOJDEPIAEEPGDFAA.achim.domma@syynx.de>
Message-ID: <023901c20295$c5fed4b0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: "C++-Sig at Python. Org" <c++-sig at python.org>
Sent: Thursday, May 23, 2002 3:17 PM
Subject: [C++-sig] Codewarrior on Windows


> Is there a problem using boost.python with Codewarrior7 on Windows?

No; I test with it daily.

> According to the documentation it is supported, but will the extension
work
> out-of-the-box with ActiveState Python or do I have to recompile
something
> from source?

I don't test with AS Python, so I don't know. That said, I think it should
work.

> Due to the C only interface of the python dll it should work, but I would
> like to ask first ...

-Dave





From ssmith at magnet.fsu.edu  Fri May 24 17:25:42 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Fri, 24 May 2002 11:25:42 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <01bd01c20277$8d5e5a90$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEIEAHCCAA.ssmith@magnet.fsu.edu>

Greetings,

I am trying to build Boost.Python using Cygwin under Windows.
There are a couple of glitches that those of you who do this often
can probably easily show me how to solve.

Whether in a Cygwin bash shell or in a Windows command shell I always
get errors in the build because the Python headers are not found.
Specifically Python.h and patchlevel.h.

Here are the details of what I have on my system:

1.) GCC version is 2.95.3-5 and works just fine.
2.) Python comes up in a bash shell as Python 2.2
3.) I put bjam.exe, pre-built for Window, in /usr/local/bin
    relative to what Cygwin calls root (C:\cygwin).
4.) The directory /usr/include/python2.2 seems to have the headers
    Python.h and patchelevel.h
5.) I did not build Python (yet), I just have what came with Cygwin.
6.) I put Boost 1.28.0 in C:\Program Files\Boost\boost

Now, can anyone tell me what I need for the following environment
variables? The values to the right are those suggested in the build
directions and those in () are the ones I assume are correct.

  PYTHON_ROOT       /usr/local                (?)
  PYTHON_VERSION                              (2.2)
  CYGWIN_ROOT                                 (C:\cygwin)
  GCC_PYTHON_ROOT   $(CYGWIN_ROOT)/usr/local
(C:\cygwin\usr\include\python2.2)

Since I did not really install python, i.e. Cygwin did this, I do
not have any Python files in /usr/local (as default settings for the above
variables use).

Thanks,
Scott


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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu






From david.abrahams at rcn.com  Fri May 24 17:39:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 24 May 2002 11:39:58 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
References: <NFBBINAMBILHLOCDJKAEIEAHCCAA.ssmith@magnet.fsu.edu>
Message-ID: <012d01c20339$7eb11970$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> Here are the details of what I have on my system:
>
> 1.) GCC version is 2.95.3-5 and works just fine.
> 2.) Python comes up in a bash shell as Python 2.2
> 3.) I put bjam.exe, pre-built for Window, in /usr/local/bin
>     relative to what Cygwin calls root (C:\cygwin).
> 4.) The directory /usr/include/python2.2 seems to have the headers
>     Python.h and patchelevel.h
> 5.) I did not build Python (yet), I just have what came with Cygwin.
> 6.) I put Boost 1.28.0 in C:\Program Files\Boost\boost
>
> Now, can anyone tell me what I need for the following environment
> variables? The values to the right are those suggested in the build
> directions and those in () are the ones I assume are correct.
>
>   PYTHON_ROOT       /usr/local                (?)

The root directory of your regular Windows Python (not Cygwin)
installation; should contain a Lib/ subdirectory. I guess this is my
mistake -- I never set this up to work with Cygwin but no ordinary Python.

However, if you haven't installed that, you can get around the "no python
installation" message by setting PYTHON_STDLIB_PATH to point at your Cygwin
python's Lib/ directory.

In theory, you should be able to set PYTHON_ROOT to c:/cygwin/usr, but I
don't think it actually will make a difference if you set
PYTHON_STDLIB_PATH.

>   PYTHON_VERSION                              (2.2)

Should be 2.2

>   CYGWIN_ROOT                                 (C:\cygwin)

OK

>   GCC_PYTHON_ROOT   $(CYGWIN_ROOT)/usr/local
(C:\cygwin\usr\include\python2.2)

Should be c:/cygwin/usr

> Since I did not really install python, i.e. Cygwin did this, I do
> not have any Python files in /usr/local (as default settings for the
above
> variables use).

Sorry for any confusion,
Dave






From ssmith at magnet.fsu.edu  Fri May 24 18:49:23 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Fri, 24 May 2002 12:49:23 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <012d01c20339$7eb11970$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAECEAICCAA.ssmith@magnet.fsu.edu>

Hi Dave,

> > Now, can anyone tell me what I need for the following environment
> > variables? The values to the right are those suggested in the build
> > directions and those in () are the ones I assume are correct.
> >
> >   PYTHON_ROOT       /usr/local                (?)
>
> The root directory of your regular Windows Python (not Cygwin)
> installation; should contain a Lib/ subdirectory. I guess this is my
> mistake -- I never set this up to work with Cygwin but no ordinary Python.

In a previous e-mail you said that I needed to have Cygwin built Python,
not Windows Python!

================== Snipped from an earlier message ============

>> Do I have to use CygWin's Python rather than that I downloaded?

> Yes. This is a Cygwin (not Boost) limitation. Also you may need to build
> your own Cygwin version of Python from within cygwin to do this, if Cygwin
> doesn't supply the version of Python you want.

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

OK, I have both on the system anyway, so I'll switch back to using
the Windows Python directory.

> However, if you haven't installed that, you can get around the "no python
> installation" message by setting PYTHON_STDLIB_PATH to point at your
Cygwin
> python's Lib/ directory.

No, I don't think this is possible unless I install the Python sources
from CygWin. I don't think there is a Python directory will all of this
stuff
if one does a typical CygWin installation. I have downloaded the latest
sources from them (they do not build either however), so I could set this,
but I'll stick to the Windows flavor for now.

> In theory, you should be able to set PYTHON_ROOT to c:/cygwin/usr, but I
> don't think it actually will make a difference if you set
> PYTHON_STDLIB_PATH.

We'll see. Here is the next go through. A little closer to getting a
build. I will show two different attempts.... although you told me
(I think) that one needs to build in a Windows command shell, I still
give it a go in a CygWin bash shell too. I don't think there is any
problems with the latter.

I did the following in a Windows command shell:

set PYTHON_ROOT=C:\PROGRA~1\Python22
set PYTHON_VERSION=2.2
set CYGWIN_ROOT=C:\cywin
set GCC_PYTHON_ROOT=C:\cygwin\usr
set PATH=C:\cygwin\bin;C:\cygwin\usr\local\bin;%PATH%
cd C:\PROGRA~1\Boost\boost_1_28_0\libs\python\build
bjam -sTOOLS=gcc -sBUILD=release

I did the following in a Cygwin bash shell

PYTHON_ROOT="C:/Program Files/Python22"
export PYTHON_ROOT
PYTHON_VERSION="2.2"
export PYTHON_VERSION
CYGWIN_ROOT="C:/cywin"
export CYGWIN_ROOT
GCC_PYTHON_ROOT="C:/cygwin/usr"
export GCC_PYTHON_ROOT
cd c:/Prog*/Boost/boost*/libs/python/build
bjam -sTOOLS=gcc -sBUILD=release

Now, the output from both attempts is essentially the same.
Below is an excerpt, I hope you can make some sense out of
what is going wrong. Maybe it is just a bad compiler command.

$ bjam -sTOOLS=gcc -sBUILD=release
...found 260 targets...
...updating 14 targets...
gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\types.obj
cc1plus.exe: Invalid option `-foptimize-sibling-calls'





g++  -c -Wall -ftemplate-depth-100  -DNDEBUG -DUSE_DL_IMPORT -DBOOST_PYTHON_
DYNAMIC_LIB  -O3 -Wno-inline  -fomit-fra
me-pointer -foptimize-sibling-calls  -I"..\..\..\libs\python\build" -I"." -I
"c:\Program Files\Boost\boost_1_28_0" -I"C:\
cygwin\usr\include\python2.2"   -o
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link
-dynamic\types.obj"  "../src\types.cpp"

...failed gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\ty
pes.obj...
gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\classes.obj
cc1plus.exe: Invalid option `-foptimize-sibling-calls'
.
.
.




g++  -c -Wall -ftemplate-depth-100  -DNDEBUG -DUSE_DL_IMPORT -DBOOST_PYTHON_
DYNAMIC_LIB  -O3 -Wno-inline  -fomit-fr
me-pointer -foptimize-sibling-calls  -I"..\..\..\libs\python\build" -I"." -I
"c:\Program Files\Boost\boost_1_28_0" -I"C:
cygwin\usr\include\python2.2"   -o
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-lin
-dynamic\errors.obj"  "../src\errors.cpp"

...failed gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\e
rors.obj...
...skipped
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.lib for lack o

<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>types.obj...
...skipped
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.dll for lack o

<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>types.obj...
...skipped <!libs!python!build!bin-stage>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc\release\i
lining-on\runtime-link-dynamic>boost_python.dll...
...skipped <!libs!python!build!bin-stage>boost_python.lib for lack of
<libs!python!build\boost_python.dll\gcc\release\i
lining-on\runtime-link-dynamic>boost_python.lib...
...failed updating 10 targets...
...skipped 4 targets...

Any ideas?

Thanks for bearing with me Dave,
Scott


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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu>





From david.abrahams at rcn.com  Fri May 24 19:09:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 24 May 2002 13:09:41 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
References: <NFBBINAMBILHLOCDJKAECEAICCAA.ssmith@magnet.fsu.edu>
Message-ID: <01bf01c20346$6ba71020$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Friday, May 24, 2002 12:49 PM
Subject: RE: [C++-sig] Cygwin Boost.Python Build


> Hi Dave,
>
> > > Now, can anyone tell me what I need for the following environment
> > > variables? The values to the right are those suggested in the build
> > > directions and those in () are the ones I assume are correct.
> > >
> > >   PYTHON_ROOT       /usr/local                (?)
> >
> > The root directory of your regular Windows Python (not Cygwin)
> > installation; should contain a Lib/ subdirectory. I guess this is my
> > mistake -- I never set this up to work with Cygwin but no ordinary
Python.
>
> In a previous e-mail you said that I needed to have Cygwin built Python,
> not Windows Python!

Yes, you do. However, the helpful configuration checking is slightly
broken; if you're building with Cygwin your windows python will be largely
ignored, but it still expects to find the right material in the ordinary
Windows relationship to PYTHON_ROOT.

> OK, I have both on the system anyway, so I'll switch back to using
> the Windows Python directory.
>
> > However, if you haven't installed that, you can get around the "no
python
> > installation" message by setting PYTHON_STDLIB_PATH to point at your
> Cygwin
> > python's Lib/ directory.
>
> No, I don't think this is possible unless I install the Python sources
> from CygWin. I don't think there is a Python directory will all of this
> stuff
> if one does a typical CygWin installation.

There is at least a Lib/ directory; that contains the Python standard
library which is full of .py files.
However, for a Cygwin build you /will/ need the #includes as well (which
according to your previous message you already have).

> I have downloaded the latest
> sources from them (they do not build either however), so I could set
this,
> but I'll stick to the Windows flavor for now.
>
> > In theory, you should be able to set PYTHON_ROOT to c:/cygwin/usr, but
I
> > don't think it actually will make a difference if you set
> > PYTHON_STDLIB_PATH.
>
> We'll see. Here is the next go through. A little closer to getting a
> build. I will show two different attempts.... although you told me
> (I think) that one needs to build in a Windows command shell, I still
> give it a go in a CygWin bash shell too. I don't think there is any
> problems with the latter.
>
> I did the following in a Windows command shell:
>
> set PYTHON_ROOT=C:\PROGRA~1\Python22
> set PYTHON_VERSION=2.2
> set CYGWIN_ROOT=C:\cywin
> set GCC_PYTHON_ROOT=C:\cygwin\usr
> set PATH=C:\cygwin\bin;C:\cygwin\usr\local\bin;%PATH%
> cd C:\PROGRA~1\Boost\boost_1_28_0\libs\python\build
> bjam -sTOOLS=gcc -sBUILD=release
>
> I did the following in a Cygwin bash shell
>
> PYTHON_ROOT="C:/Program Files/Python22"
> export PYTHON_ROOT
> PYTHON_VERSION="2.2"
> export PYTHON_VERSION
> CYGWIN_ROOT="C:/cywin"
> export CYGWIN_ROOT
> GCC_PYTHON_ROOT="C:/cygwin/usr"
> export GCC_PYTHON_ROOT
> cd c:/Prog*/Boost/boost*/libs/python/build
> bjam -sTOOLS=gcc -sBUILD=release
>
> Now, the output from both attempts is essentially the same.
> Below is an excerpt, I hope you can make some sense out of
> what is going wrong. Maybe it is just a bad compiler command.
>
> $ bjam -sTOOLS=gcc -sBUILD=release
> ...found 260 targets...
> ...updating 14 targets...
> gcc-C++-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\types.obj
> cc1plus.exe: Invalid option `-foptimize-sibling-calls'

If you are seeing -foptimize-sibling-calls, something is wrong with the
Boost release. This was not supposed to be in the release and was fixed in
the right place, but I guess it crept in. Please find
tools/build/python.jam and change the line which reads:

      <inlining>on <cxxflags>-foptimize-sibling-calls

to read:

      <inlining>on






From okuda1 at llnl.gov  Fri May 24 21:06:16 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Fri, 24 May 2002 12:06:16 -0700
Subject: [C++-sig] union in C++ and BPL
Message-ID: <3CEE8F28.6FB6F571@llnl.gov>

I do not find any example of union, but does someone have any simple
example of union?

I have the following definition in our code:

typedef union {
   int ix;
   double dx;
} ListType;

typedef struct {
   bool isInt;
   std::vector<ListType> list;
} ItemList;

and if isInt is yes, then would like to push int value to ItemList,
otherwise to push double into ItemList.

Here is my simple BPL code, but I am not entirely sure how to wrap union
in python and pass the value to ItemList. (if you uncomment typedef int
ListType and comment out union definition part, the code works nicely,
though).
I am aware that push(lst,10.1) is wrong, but then how to wrap 10.1 in
ListType and pass as push(lst, ut)?

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

using namespace boost::python;
#include <iostream>
using std::cout;
using std::endl;
#include <vector>

//typedef int ListType;
union listType {
   int ix;
   double dx;
};
typedef union listType ListType;

struct itemList {
   bool isInt;
   std::vector<ListType> list;
};
typedef struct itemList ItemList;

void push(ItemList& l, ListType a) {
   l.list.push_back(a);
}

void show(ItemList l) {
   for (int i=0; i<l.list.size();i++) {
      if (l.isInt)
         cout << l.list[i].ix << ' ';
      else
         cout << l.list[i].dx << ' ';
   }
   cout << endl;
}

BOOST_PYTHON_MODULE_INIT(unionTest)
{
   using namespace boost::python;
   module ("unionTest")
      //.def_readwrite("ix", &listType.ix)
      //.def_readwrite("dx", &listType.dx)

      .def("push",push)
      .def("show",show)
      .add(
           class_<itemList>("itemList")
           .def_init()
           .def_readwrite("isInt", &itemList::isInt)
           )
      ;
}
-----------------------------------------------

gps02(223) python
Adding parser accelerators ...
Done.
Python 2.2 (#1, Jan 22 2002, 14:39:03) [C] on osf1V5
Type "help", "copyright", "credits" or "license" for more information.
>>> from unionTest import *
>>> lst=itemList()
>>> lst.isInt = 0
>>> push(lst,10.1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation

Thank you very much
Chuzo




From ssmith at magnet.fsu.edu  Fri May 24 21:13:41 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Fri, 24 May 2002 15:13:41 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <01bf01c20346$6ba71020$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEMEAICCAA.ssmith@magnet.fsu.edu>

Hi Dave,

Not sure if I am getting less confused or not. When and if this
build is ever working I'll redo the whole thing on a different machine
with CygWin to make sure it works!

Let me see if I fathom this so far:

1.) Need prebuilt jam for windows           (not cygwin built jam)
2.) Need to have Cygwin Python installed    (but not sources)
3.) It is convenient to have Windows Python (?, but in principle NOT?)
4.) Set the following variables
        PYTHON_ROOT                         (C:\PROGRA~1\Python22)
        PYTHON_VERSION                      (2.2)
        CYGWIN_ROOT                         (C:\cywin)
        GCC_PYTHON_ROOT                     (C:\cygwin\usr)

And the oddity is that I use Windows Python to set PYTHON_ROOT because
it contains the Python Lib subdirectory. To be sure, on a different
PC I installed Cygwin Python via their setup to see what was put on the
system. It placed files in /usr/lib/Python2.2 (py, pyo, etc.) and in
/usr/include/Python2.2 (headers). Neither of these has any Lib subdirectory
stemming off of it. In additon, /usr/lib is set one and the same with /lib.

> Yes, you do. However, the helpful configuration checking is slightly
> broken; if you're building with Cygwin your windows python will be largely
> ignored, but it still expects to find the right material in the ordinary
> Windows relationship to PYTHON_ROOT.

Yes I do meaning I need just cygwin build python, just windows built python,
or both?

> You can get around the "no python
> installation" message by setting PYTHON_STDLIB_PATH to point at your
> Cygwin python's Lib/ directory.

As I said, a Cygwin Python install (via their setup) does not produce any
Lib subdirectory. Maybe this is different if the sources are installed too
or if Python is built by the user.

> There is at least a Lib/ directory; that contains the Python standard
> library which is full of .py files.

I would guess this is /usr/lib/Python2.2 but it is not a Lib directory
off of Python. Yes, I compared its contents with the Windows Python Lib
subdirectory and they share many of the same files.

> For a Cygwin build you /will/ need the #includes as well (which
> according to your previous message you already have).

Yes these are in /usr/include/Python2.2

> In theory, you should be able to set PYTHON_ROOT to c:/cygwin/usr, but
> I don't think it actually will make a difference if you set
> PYTHON_STDLIB_PATH.

It looks to me as if only the Cygwin Python would suffice if it has the
proper directory structure that the Jam stuff expects. Maybe simple links
would work. One that set up some Lib subdirectory pointing to the where the
python files, e.g.   ln -s /usr/lib/Python2.2 /usr/Lib so that c:/cygwin/usr
If you think that might work I'll give it a try, but in the meantime there
is the bigger build problem I hoped you could comment on.

> If you are seeing -foptimize-sibling-calls, something is wrong with the
> Boost release. This was not supposed to be in the release and was fixed in
> the right place, but I guess it crept in. Please find
> tools/build/python.jam and change the line which reads:
>
>       <inlining>on <cxxflags>-foptimize-sibling-calls
>
> to read:
>
>       <inlining>on

Done and that did help. There was a warning and what appeared to be errors,
but a dll was created!!? But did this actually work even with errors?
Here is sections of the output:

bjam -sTOOLS=gcc -sBUILD=release
...found 260 targets...
...updating 14 targets...
.
.
gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\conversions.
obj
../src\conversions.cpp: In function `struct PyObject *
integer_to_python<signed char>(signed char)':
../src\conversions.cpp:153:   instantiated from here
../src\conversions.cpp:72: warning: `long int value_as_long' might be used
uninitialized in this function

.
.
gcc-C++-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\errors.obj
gcc-Link-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.dll
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.lib
g++: Files/Python22/libs: No such file or directory
g++: Files/Python22/PCBuild: No such file or directory

g++  -Wl,--export-all-symbols -Wl,--exclude-symbols,
.....  -lpython2.2.dll -lutil

...failed gcc-Link-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.dll
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.lib...
...skipped
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.lib...
...skipped <!libs!python!build!bin-stage>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.dll...
...skipped <!libs!python!build!bin-stage>boost_python.lib for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.lib...
...failed updating 1 target...
...skipped 3 targets...
...updated 10 targets...

The bin-stage directory contains boost-python.lib (~1MB) and
boost-python.dll (~330K). Hmm, then are the above fail messages
not of any consequence?

Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu>





From david.abrahams at rcn.com  Fri May 24 23:37:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 24 May 2002 17:37:02 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
References: <NFBBINAMBILHLOCDJKAEMEAICCAA.ssmith@magnet.fsu.edu>
Message-ID: <026e01c2036b$cd2cbb40$6501a8c0@boostconsulting.com>


----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hi Dave,
>
> Not sure if I am getting less confused or not. When and if this
> build is ever working I'll redo the whole thing on a different machine
> with CygWin to make sure it works!
>
> Let me see if I fathom this so far:
>
> 1.) Need prebuilt jam for windows           (not cygwin built jam)

check

> 2.) Need to have Cygwin Python installed    (but not sources)

check. Headers and libraries, but not sources

> 3.) It is convenient to have Windows Python (?, but in principle NOT?)

Convenient but probably not neccessary if you set PYTHON_STDLIB_PATH
properly.

> 4.) Set the following variables
>         PYTHON_ROOT                         (C:\PROGRA~1\Python22)
>         PYTHON_VERSION                      (2.2)
>         CYGWIN_ROOT                         (C:\cywin)
>         GCC_PYTHON_ROOT                     (C:\cygwin\usr)

Looks OK

> And the oddity is that I use Windows Python to set PYTHON_ROOT because
> it contains the Python Lib subdirectory.

Yes. Or set PYTHON_STDLIB_PATH to c:/cygwin/usr/lib/python2.2

> To be sure, on a different
> PC I installed Cygwin Python via their setup to see what was put on the
> system. It placed files in /usr/lib/Python2.2 (py, pyo, etc.) and in
> /usr/include/Python2.2 (headers). Neither of these has any Lib
subdirectory
> stemming off of it.

Right.

> In additon, /usr/lib is set one and the same with /lib.

Huh? You mean there's a link?

> > Yes, you do. However, the helpful configuration checking is slightly
> > broken; if you're building with Cygwin your windows python will be
largely
> > ignored, but it still expects to find the right material in the
ordinary
> > Windows relationship to PYTHON_ROOT.
>
> Yes I do meaning I need just cygwin build python, just windows built
python,
> or both?

Going back to look at the context which you snipped,

> In a previous e-mail you said that I needed to have Cygwin built Python,
> not Windows Python!

Yes, you do (need a Cygwin built Python)

> > You can get around the "no python
> > installation" message by setting PYTHON_STDLIB_PATH to point at your
> > Cygwin python's Lib/ directory.
>
> As I said, a Cygwin Python install (via their setup) does not produce any
> Lib subdirectory.

Sorry. whatever Directory contains the standard libs. In your installation
it will be c:/cygwin/usr/lib/python2.2

> Maybe this is different if the sources are installed too
> or if Python is built by the user.

No, I just mis-named it.

> > There is at least a Lib/ directory; that contains the Python standard
> > library which is full of .py files.
>
> I would guess this is /usr/lib/Python2.2 but it is not a Lib directory
> off of Python. Yes, I compared its contents with the Windows Python Lib
> subdirectory and they share many of the same files.

Yes, that's the one.

> It looks to me as if only the Cygwin Python would suffice if it has the
> proper directory structure that the Jam stuff expects. Maybe simple links
> would work.

Don't bother; just set PYTHON_STDLIB_PATH as described above.

> One that set up some Lib subdirectory pointing to the where the
> python files, e.g.   ln -s /usr/lib/Python2.2 /usr/Lib so that
c:/cygwin/usr
> If you think that might work I'll give it a try, but in the meantime
there
> is the bigger build problem I hoped you could comment on.

> Done and that did help. There was a warning and what appeared to be
errors,
> but a dll was created!!? But did this actually work even with errors?
> Here is sections of the output:
>
> bjam -sTOOLS=gcc -sBUILD=release
> ...found 260 targets...
> ...updating 14 targets...
> .
> .
> gcc-C++-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\conversions.
> obj
> ../src\conversions.cpp: In function `struct PyObject *
> integer_to_python<signed char>(signed char)':
> ../src\conversions.cpp:153:   instantiated from here
> ../src\conversions.cpp:72: warning: `long int value_as_long' might be
used
> uninitialized in this function

It's OK; get a newer GCC if you don't want to see that.

> .
> gcc-C++-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\errors.obj
> gcc-Link-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.dll
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.lib
> g++: Files/Python22/libs: No such file or directory
> g++: Files/Python22/PCBuild: No such file or directory

These are a consequence of my not having tested the build with just Cygwin
on my machine... and some missing quotes in tools/build/gcc-tools.jam.
Arrggh!

The enclosed patch fixes the problems.

> g++  -Wl,--export-all-symbols -Wl,--exclude-symbols,
> .....  -lpython2.2.dll -lutil
>
> ...failed gcc-Link-action

Really, it failed and still generated output? That's odd. Normally jam
removes the product when a build step fails.

>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.dll
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.lib...
> ...skipped
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.dll for lack of
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.lib...
> ...skipped <!libs!python!build!bin-stage>boost_python.dll for lack of
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.dll...
> ...skipped <!libs!python!build!bin-stage>boost_python.lib for lack of
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.lib...
> ...failed updating 1 target...
> ...skipped 3 targets...
> ...updated 10 targets...
>
> The bin-stage directory contains boost-python.lib (~1MB) and
> boost-python.dll (~330K). Hmm, then are the above fail messages
> not of any consequence?

Gee, I don't know. Why was it trying to build multiple versions of the
library, I wonder? What is your BUILD variable set to?

Sorry this is turning out to be so rough,

-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 622 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020524/4ab6ecdf/attachment.obj>

From achim.domma at syynx.de  Sat May 25 16:50:29 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 25 May 2002 16:50:29 +0200
Subject: [C++-sig] error C2904: 'from_python' : template-name already defined
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEALDGAA.achim.domma@syynx.de>

Hi,

still trying to wrap ImageMagick with boost.python I get the following
error:

e:\cvsroot\boost\boost/python/converter/from_python.hpp(24) : error C2904:
'from_python' : template-name already defined as '__restrict volatile const
signed  __fastcall boost::python::from_python'
e:\cvsroot\boost\boost/mpl/aux_/count_if_not.hpp(61) : fatal error C1506:
unrecoverable block scoping error

Here is the file I try to compile:

---->
#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <string>
#include <Magick++.h>
using namespace boost::python;

void add_class_Image_to_module(module& m) {
	m.add(class_<Magick::Image>("Image")
		.def_init()
		);
}
<----

I have such a file for each class, due to internal compiler errors if I put
all classes in one file. The module definition looks like this:

---->
void add_class_Image_to_module(boost::python::module& m);
BOOST_PYTHON_MODULE_INIT(ImageMagick)
{
    using namespace boost::python;
    module m("ImageMagick");
    add_class_Image_to_module(m);
}
<----

Is there something wrong with this code? I have no idea where the error
comes from.

greetings
Achim






From ssmith at magnet.fsu.edu  Sat May 25 21:27:23 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Sat, 25 May 2002 15:27:23 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <026e01c2036b$cd2cbb40$6501a8c0@boostconsulting.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLEEBBCAAA.ssmith@magnet.fsu.edu>

Hi Dave,

I have done a fresh install of Cygwin with Python on my home machine and
ready to reattempt the build. There is one difference in the directory
struction and I see that you asked about earlier.

>> In additon, (cygwin)/usr/lib is set one and the same with (cygwin)/lib.
> Huh? You mean there's a link?

On my other machine there is some sort of link, not visible in the Windows
file manager. That is, /usr/lib does not show up at all. In a bash shell
they are the same. Sorry I didn't look to see how they did that before
leaving work. On my home machine /usr/lib is just empty and separate from
/lib. The Python stuff is in the same places I mentioned before. None of
this matters at this point in the build.

>These (problems) are consequence of my not having tested the build with
just Cygwin
>on my machine... and some missing quotes in tools/build/gcc-tools.jam.
>Arrggh!

> The enclosed patch fixes the problems.

I used patch and your patch.dat to fix the file in tools\build\jam_src. Now
to I need to rebuild Jam? I assume that I need to, but again I am puzzled.
You mentioned that I had to use a prebuilt Windows jam to build
Boost.Python, not a Cygwin build Jam. If I use make to build a new Jam this
will be a Cygwin bjam.exe. Will that work? I see that Jam can also be used
to rebuild itself. I that a better way to go? If so I cannot find any
instructions on how to build Jam with Jam.

> Really, it failed and still generated output? That's odd. Normally jam
> removes the product when a build step fails.
> Gee, I don't know. Why was it trying to build multiple versions of the
> library, I wonder? What is your BUILD variable set to?

I thought this was strange too. As you can see from the previous message,
I used
                     bjam -sTOOLS=gcc -sBUILD=release

> Sorry this is turning out to be so rough

Well I'm just glad you are willing to suffer along with me. I know very well
how difficult it is to keep everything working for different
OS/Compiler(/Python/Boost) combinations.I think it is close to working, just
wish I understood the jam stuff better and could just patch things myself.
Let me know what to do about Jam after the patch and I'll give it another
try.

Regards,
Scott





From RaoulGough at yahoo.co.uk  Sun May 26 17:22:15 2002
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sun, 26 May 2002 16:22:15 +0100
Subject: [C++-sig] RE: Cygwin Boost.Python Build
References: <20020525144401.10829.66823.Mailman@mail.python.org>
Message-ID: <000901c204c9$4c3207c0$0100a8c0@albert>

If it's any help, here's my set-up script for building Boost with the Cygwin
Python:

export PYTHON='f:\cygwin\bin\python.exe'
export PYTHON_ROOT='f:\cygwin\lib\python2.1'
export PYTHON_VERSION='2.1'
export PYTHON_INCLUDES='f:\cygwin\usr\include\python2.1'
export PYTHON_LIB_PATH='f:\cygwin\lib\python2.1\config'
export PYTHON_STDLIB_PATH='f:\cygwin\lib\python2.1'
export GCC_PYTHON_ROOT='f:\cygwin\usr'

I remember it taking some time to arrive at this - maybe it will help
Scott get his set-up working (with appropriate replacements).

Regards,
Raoul Gough.



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





From david.abrahams at rcn.com  Sun May 26 17:34:46 2002
From: david.abrahams at rcn.com (david.abrahams at rcn.com)
Date: Sun, 26 May 2002 11:34:46 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
Message-ID: <E17C02g-0003cR-00@smtp02.mrf.mail.rcn.net>

> 
> From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> I used patch and your patch.dat to fix the file in tools\
build\jam_src. Now
> to I need to rebuild Jam? 

No, .jam files are interpreted. If they weren't we'd just 
write jam in C++.  End users like you should, in 
principle, never have to build or rebuild the jam 
executable.

-Dave






From ssmith at magnet.fsu.edu  Sun May 26 19:32:50 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Sun, 26 May 2002 13:32:50 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <E17C02g-0003cR-00@smtp02.mrf.mail.rcn.net>
Message-ID: <PCEJJPDHEECNEKDDLPNLMEBBCAAA.ssmith@magnet.fsu.edu>

Hi Dave,

Apparently nobody takes vacations in this group. Me either.
My next attempt (home machine) fails too, but with a new problem!
Thanks to Raoul for detailing how he set his environment up.

To recap-

Fresh Cygwin with Python 2.2, Windows pre-build bjam.exe, patch
from Dave applied, and the following environment variables set:

export PYTHON='C:\cygwin\bin\python.exe'
export PYTHON_ROOT='C:\cygwin\lib\python2.2'
export PYTHON_VERSION='2.2'
export PYTHON_INCLUDES='C:\cygwin\usr\include\python2.2'
export PYTHON_LIB_PATH='C:\cygwin\lib\python2.2\config'
export PYTHON_STDLIB_PATH='C:\cygwin\lib\python2.2'
export GCC_PYTHON_ROOT='C:\cygwin\usr'

In the directory libs/python I issued the command

bjam -sTOOLS=gcc -sBUILD=release

Now I get a problem with missing includes from mpl, for example

.
.
c:/Program
Files/Boost/boost_1_28_0/boost/python/converter/from_python_data.hpp:
10: boost/mpl/select_type.hpp: No such file or directory
.
.

Sure enough, these are not there. I dutifully looked over the mail archives
as I remember someone having similar problems (shame they are not
searchable)
I found this:

> I gather that mpl is something that is newly needed....

> You don't need it today, unless you're trying to build from the
libs/python
> or libs/python/test subdirectories. It's only needed for Boost.Python v2,
> which is prerelease code.

Since I am just using 1.28.0 taken from the Boost site, not from CVS and not
having anything to do with v2, I am again stuck....

Regards,
Scott





From david.abrahams at rcn.com  Sun May 26 23:54:35 2002
From: david.abrahams at rcn.com (david.abrahams at rcn.com)
Date: Sun, 26 May 2002 17:54:35 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
Message-ID: <E17C5yF-0003xE-00@smtp02.mrf.mail.rcn.net>

> > You don't need it today, unless you're trying to build from the
> libs/python
> > or libs/python/test subdirectories. It's only needed for Boost.Python v2,
> > which is prerelease code.
> 
> Since I am just using 1.28.0 taken from the Boost site, not from CVS and not
> having anything to do with v2, I am again stuck....

You're just not following the directions. The 1.28.0 release contains plently of v2 files. Start your build from the libs/python/build directory or from the boost root directory if you want to avoid them.






From ssmith at magnet.fsu.edu  Mon May 27 05:11:04 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Sun, 26 May 2002 23:11:04 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <E17C5yF-0003xE-00@smtp02.mrf.mail.rcn.net>
Message-ID: <PCEJJPDHEECNEKDDLPNLGEBCCAAA.ssmith@magnet.fsu.edu>

Hi Dave,

> You're just not following the directions.
> The 1.28.0 release contains plently of v2 files.
> Start your build from the libs/python/build directory
> or from the boost root directory if you want to avoid them.

Sorry. You are right or course, in my many attempts and haste
I just goofed up. Now everything compiles, but the linking step
fails. Here is the link command and what it produces:

g++ -Wl,--export-all-symbols -Wl,--exclude-symbols,_bss_end__:_bss_start__:_
data_end__:_data_start__ -Wl,--out-implib,..\..\..\libs\python\build\bin\boo
st_python.dll\gcc\release\inlining-on\runtime-link-dynamic\boost_python.lib 
 -s -shared  -o
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\boost_python.dll"  -LC:/cygwin/lib/python2.2/config -LC:/c
ygwin/usr/lib/python2.2/config
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\types.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\classes.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\conversions.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\extension_class.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\functions.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\init_function.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\module_builder.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\objects.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\cross_module.obj"
"..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
time-link-dynamic\errors.obj" -lpython2.2.dll -lutil

...failed gcc-Link-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.dll
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.lib...

...skipped
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic boost_python.lib...
...skipped <!libs!python!build!bin-stage>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.dll...
...skipped <!libs!python!build!bin-stage>boost_python.lib for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.lib...
...failed updating 1 target...
...skipped 3 targets...
...updated 10 targets...

This time the directory bin-stage was made, but it is empty. There are
object files in the bin (sub-sub-sub) directory. Any idea what to try next?

Scott

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





From ssmith at magnet.fsu.edu  Mon May 27 06:16:25 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Mon, 27 May 2002 00:16:25 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <E17C5yF-0003xE-00@smtp02.mrf.mail.rcn.net>
Message-ID: <PCEJJPDHEECNEKDDLPNLOEBCCAAA.ssmith@magnet.fsu.edu>

Dave,

I forgot one thing. There is (as with OS X) problems finding the
util library. Here is some more output:

$ bjam -sTOOLS=gcc -sBUILD=release -db1
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cann
ot find -lutil
collect2: ld returned 1 exit status
...skipped
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-l
ink-dynamic>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc
\release\inlining-on\runtime-link-dynamic>boost_python.lib...
...skipped <!libs!python!build!bin-stage>boost_python.dll for lack of
<libs!pyth
on!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dynamic>boost
_pyt
hon.dll...
...skipped <!libs!python!build!bin-stage>boost_python.lib for lack of
<libs!pyth
on!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dynamic>boost
_pyt
hon.lib...

If this is part of Cygwin, I cannot find it (execpt maybe in
Python/Lib/lib-old?)
Do you know what library this is and what it contains?

Scott






From david.abrahams at rcn.com  Mon May 27 15:11:20 2002
From: david.abrahams at rcn.com (david.abrahams at rcn.com)
Date: Mon, 27 May 2002 9:11:20 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
Message-ID: <E17CKHQ-0002Oh-00@smtp02.mrf.mail.rcn.net>

> 
> Now everything compiles, but the linking step
> fails. Here is the link command and what it produces:
> 
> g++ -Wl,--export-all-symbols -Wl,--exclude-
symbols,_bss_end__:_bss_start__:_
> data_end__:_data_start__ -Wl,--out-implib,..\..\..\libs\
python\build\bin\boo...

The link error message is missing from your post; it 
would appear above all this. I can't imagine what might 
be failing without that info.

-Dave





From ssmith at magnet.fsu.edu  Mon May 27 15:25:04 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Mon, 27 May 2002 09:25:04 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
In-Reply-To: <E17CKHQ-0002Oh-00@smtp02.mrf.mail.rcn.net>
Message-ID: <PCEJJPDHEECNEKDDLPNLGEBDCAAA.ssmith@magnet.fsu.edu>

Hi Dave,

>The link error message is missing from your post; it
>would appear above all this. I can't imagine what might
>be failing without that info.

Sorry, I think it is in my previous post. Here it is in full.

$ bjam -sTOOLS=gcc -sBUILD=release
...found 260 targets...
...updating 4 targets...
gcc-Link-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_pytho
n.dll
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.lib
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cannot find -lutil
collect2: ld returned 1 exit status





g++  -Wl,--export-all-symbols -Wl,--exclude-symbols,_bss_end__:_bss_start__:
_data_end__:_data_start__...

As with my attempted build under Mac OS X, it seems there is no util
library.
Maybe this is all that is currently wrong with the Mac build too.

Thanks,
Scott





From david.abrahams at rcn.com  Mon May 27 15:50:30 2002
From: david.abrahams at rcn.com (david.abrahams at rcn.com)
Date: Mon, 27 May 2002 9:50:30 -0400
Subject: [C++-sig] Cygwin Boost.Python Build
Message-ID: <E17CKtK-0007QN-00@smtp02.mrf.mail.rcn.net>

> 
> From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
> Date: 2002/05/27 Mon AM 12:16:25 EDT
> To: c++-sig at python.org
> Subject: RE: RE: [C++-sig] Cygwin Boost.Python Build
> 
> Dave,
> 
> I forgot one thing. There is (as with OS X) problems 
finding the
> util library. 

> If this is part of Cygwin, I cannot find it (execpt maybe 
in
> Python/Lib/lib-old?)
> Do you know what library this is and what it contains?

I don''t remember what it is; it must've been needed for 
a GCC build on some platform, or I never would have 
included it in the link line. On my cygwin installation, 
there's a /lib/libutil.a, but it doesn't seem to be needed 
for a cygwin build. As I said before, you could try to 
compile without -lutil in the link line. If you don't want to 
do that by hand, try commenting out the following line in 
tools/build/python.jam:

                 <$(gcc-compilers)><*><find-library>util

G'luck,
Dave






From ssmith at magnet.fsu.edu  Mon May 27 17:08:36 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Mon, 27 May 2002 11:08:36 -0400
Subject: [C++-sig] Cygwin Boost.Python Build Success
In-Reply-To: <E17CKtK-0007QN-00@smtp02.mrf.mail.rcn.net>
Message-ID: <PCEJJPDHEECNEKDDLPNLEEBECAAA.ssmith@magnet.fsu.edu>

Hi Dave,

Removal of the link to the util library worked fine.
The build looks as if it went to completion. I'll know
for certain when I try and link to it. Thanks for all
the help.

Attached are the final notes used to do the build if any
one cares to do the same or changes need to be made to
the Jam files on your end. 

Again, thanks for bearing with me. I'll likely be back
to annoy you some more as I plan to try the build under
MSVC++ (I'll follow Achim's recent post), RH Linux 7.3,
and Mac OS X. No promises, but perhaps I won't be as
dense in these next attempts.
               
Best regards,
Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BuildCygwin.zip
Type: application/x-zip-compressed
Size: 1876 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020527/3b9c5b2a/attachment.bin>

From franke at ableton.com  Mon May 27 20:01:36 2002
From: franke at ableton.com (Stefan Franke)
Date: Mon, 27 May 2002 20:01:36 +0200
Subject: [C++-sig] Wrapping pointer types in BPL 2
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B78B@exserver.ouroffice.de>

Dear David,

I have a library some colleagues wrote that I'd like to expose to 
Python. It uses some kind of pre-GC refcounting/smart pointer 
scheme for almost all classes; later on weak pointers were added, 
but there's a lot of code before the weak-ptr era that uses plain
pointers and relies on their validity.

My question: Does BPL 2.0 allow me to wrap classes that are accessed
by a mixture of plain, smart and weak pointers? Can I define the
necessary conversion policies myself where needed?

Thanks,
Stefan





From david.abrahams at rcn.com  Tue May 28 01:36:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 27 May 2002 19:36:08 -0400
Subject: [C++-sig] Wrapping pointer types in BPL 2
References: <6FB30F72F5FF9145B785936278BC25C802B78B@exserver.ouroffice.de>
Message-ID: <005401c205d7$b1af5300$6401a8c0@boostconsulting.com>

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


> Dear David,
>
> I have a library some colleagues wrote that I'd like to expose to
> Python. It uses some kind of pre-GC refcounting/smart pointer
> scheme for almost all classes; later on weak pointers were added,
> but there's a lot of code before the weak-ptr era that uses plain
> pointers and relies on their validity.
>
> My question: Does BPL 2.0 allow me to wrap classes that are accessed
> by a mixture of plain, smart and weak pointers? Can I define the
> necessary conversion policies myself where needed?

In principle, yes. The facilities of v2 are much richer than those of v1 in
this regard, and it's designed to be a framework so you can add customized
behaviors. However, the precise answer will surely depend on exactly what
you need and expect of the library.

-Dave






From david.abrahams at rcn.com  Tue May 28 01:45:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 27 May 2002 19:45:09 -0400
Subject: [C++-sig] Cygwin Boost.Python Build Success
References: <PCEJJPDHEECNEKDDLPNLEEBECAAA.ssmith@magnet.fsu.edu>
Message-ID: <00a201c205d9$18d48c20$6401a8c0@boostconsulting.com>


From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hi Dave,
>
> Removal of the link to the util library worked fine.
> The build looks as if it went to completion. I'll know
> for certain when I try and link to it. Thanks for all
> the help.
>
> Attached are the final notes used to do the build if any
> one cares to do the same or changes need to be made to
> the Jam files on your end.

If I sent you the patch mentioned there, I shouldn't have. You can remove
it from your directions, since you'd need to compile jam for it to take
effect (and all it does is suppress a warning in the building of jam
itself). The patch for you to apply was supposed to be what's enclosed
here.


-Dave

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

From david.abrahams at rcn.com  Tue May 28 16:22:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 28 May 2002 10:22:14 -0400
Subject: [C++-sig] error C2904: 'from_python' : template-name already defined
References: <FCEMIEFBFOIDAOJDEPIAIEALDGAA.achim.domma@syynx.de>
Message-ID: <033601c20653$80f187c0$6401a8c0@boostconsulting.com>

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

> 
> Is there something wrong with this code? I have no idea where the error
> comes from.

The error comes from the fact that you're not #defining BOOST_PYTHON_V2
You're not using bjam to build your extension module, are you?

-Dave






From david.abrahams at rcn.com  Tue May 28 16:38:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 28 May 2002 10:38:17 -0400
Subject: [C++-sig] union in C++ and BPL
References: <3CEE8F28.6FB6F571@llnl.gov>
Message-ID: <034401c20655$9a88ab30$6401a8c0@boostconsulting.com>

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


> I do not find any example of union, but does someone have any simple
> example of union?

There's no direct support for unions in Boost.Python.

> I have the following definition in our code:
>
> typedef union {
>    int ix;
>    double dx;
> } ListType;
>
> typedef struct {
>    bool isInt;
>    std::vector<ListType> list;
> } ItemList;
>
> and if isInt is yes, then would like to push int value to ItemList,
> otherwise to push double into ItemList.

Hmm. I think it would be better to consider the interface you'd like to see
from Python. You probably don't want to be creating ListType objects from
Python, do you? Wouldn't you rather just push python ints and floats onto
your vector?

> Here is my simple BPL code, but I am not entirely sure how to wrap union
> in python and pass the value to ItemList. (if you uncomment typedef int
> ListType and comment out union definition part, the code works nicely,
> though).
> I am aware that push(lst,10.1) is wrong, but then how to wrap 10.1 in
> ListType and pass as push(lst, ut)?

One way to handle this would be with the (undocumented) back_reference<T>
facility from boost/python/back_reference.hpp. You can wrap a function
which takes back_reference<int> (or back_reference<double>) as a parameter;
that will give you a reference to the source python object in addition to
the converted value.

void ItemList_push(ItemList& l, back_reference<double> x)
{
    ListType element;

    if (PyInt_Check(x.reference())) // was the source object an Int?
    {
        element.ix = PyInt_AsLong(x.reference().get());
    }
    else
    {
        element.dx = x.get();
    }
}

*** Pearu, I think this might be a way to work around some of your issues
as well ***

-Dave






From pearu at cens.ioc.ee  Tue May 28 17:04:33 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 28 May 2002 18:04:33 +0300 (EEST)
Subject: [C++-sig] union in C++ and BPL
In-Reply-To: <034401c20655$9a88ab30$6401a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205281757300.10283-100000@cens.ioc.ee>


On Tue, 28 May 2002, David Abrahams wrote:

> One way to handle this would be with the (undocumented) back_reference<T>
> facility from boost/python/back_reference.hpp. You can wrap a function
> which takes back_reference<int> (or back_reference<double>) as a parameter;
> that will give you a reference to the source python object in addition to
> the converted value.
> 
> void ItemList_push(ItemList& l, back_reference<double> x)
> {
>     ListType element;
> 
>     if (PyInt_Check(x.reference())) // was the source object an Int?
>     {
>         element.ix = PyInt_AsLong(x.reference().get());
>     }
>     else
>     {
>         element.dx = x.get();
>     }
> }
> 
> *** Pearu, I think this might be a way to work around some of your issues
> as well ***

Yes, I see it. However, currently my show stopper is how to insert
wrapped classes into a class inheritance tree in a 'natural' way :-(.
See the end of this message:

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

Pearu





From david.abrahams at rcn.com  Tue May 28 17:17:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 28 May 2002 11:17:14 -0400
Subject: [C++-sig] union in C++ and BPL
References: <Pine.LNX.4.21.0205281757300.10283-100000@cens.ioc.ee>
Message-ID: <000701c2065a$ea77ac90$6401a8c0@boostconsulting.com>

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

> Yes, I see it. However, currently my show stopper is how to insert
> wrapped classes into a class inheritance tree in a 'natural' way :-(.
> See the end of this message:
>
> http://mail.python.org/pipermail/c++-sig/2002-May/001058.html

Can you send me a minimal, complete example which demonstrates the problem
you're having?

Thanks,
Dave






From barnard at stat.harvard.edu  Tue May 28 20:39:57 2002
From: barnard at stat.harvard.edu (John Barnard)
Date: Tue, 28 May 2002 14:39:57 -0400 (EDT)
Subject: [C++-sig] BPL, Mingw g++, and MSVC Python
Message-ID: <Pine.LNX.4.44.0205281421090.21824-100000@stat.harvard.edu>

I'm trying to determine if it's possible to do the following under MS
Windows 2000:

(1) Compile a C++ class file into a DLL using Mingw g++ 2.95.3 or 3.1;

(2) Create a Python interface to the class using Boost.Python v2, again
using Mingw g++ 2.95.3 or 3.1

(3) Call the Python interface DLL from a MSVC++ compiled Python 2.2.

I'm mainly confused about the ability of a g++ compiled Python extension
to use g++ compiled DLLs (created from C++ source) when using a MSVC++
compiled version of Python. Given that only the DLL version of BPL is
being supported, if my above scenario can't be done, does that imply
you can't create wrappers to C++ code via BPL with g++ and use them with
MSVC++ compiled Python?

I've done this in the past with a static lib of Boost.Python v1 but I
would like to use v2.

Thanks,

John

-- 
* John Barnard, Ph.D.
* Senior Research Statistician
* deCODE genetics
* 1000 Winter Str., Suite 3100
* Waltham, MA 02451
* Phone (Direct)  : (781) 290-5771 Ext. 27
* Phone (General) : (781) 466-8833
* Fax             : (781) 466-8686
* Email: j.barnard at decode.com





From pearu at cens.ioc.ee  Tue May 28 21:24:56 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 28 May 2002 22:24:56 +0300 (EEST)
Subject: [C++-sig] An issue with wrapping class trees (BPL V2)
In-Reply-To: <000701c2065a$ea77ac90$6401a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205282153220.17411-400000@cens.ioc.ee>


Hi David,

On Tue, 28 May 2002, David Abrahams wrote:

> ----- Original Message -----
> From: "Pearu Peterson" <pearu at cens.ioc.ee>
> 
> > Yes, I see it. However, currently my show stopper is how to insert
> > wrapped classes into a class inheritance tree in a 'natural' way :-(.
> > See the end of this message:
> >
> > http://mail.python.org/pipermail/c++-sig/2002-May/001058.html
> 
> Can you send me a minimal, complete example which demonstrates the problem
> you're having?

Sure, please find attached three files:

  cltree.cpp, test_cltree.py, setup_cltree.py

When I run

  python setup_cltree.py build --build-platlib=.
  # I am not using jam as you may notice ;-)
  python test_cltree.py

I get

b= cltree.basic()
s= <__main__.symbol object at 0x80fcd64>
c= cltree.constant()
v= 
Traceback (most recent call last):
  File "test_cltree.py", line 36, in ?
    print 'v=',v
TypeError: bad argument type for built-in operation


Expected behaviour would be the following output

b= cltree.basic()
s= <__main__.symbol object at 0x80fcd64>
c= cltree.constant()
v= cltree.wrapped_variable()
ok


If you look cltree.cpp then I am basically interested in exposing classes 
`basic' and `variable' to Python under the following conditions:

1) class `variable' is a subclass of `basic' also in Python
2) class `variable' is exposed to Python using `variable_wrapper' (so that
   I can re-define constructors)

Classes `symbol' and `constant' are there only for testing, you can
ignore them. In some sense, exposing `variable' is a combination of
exposing `symbol' and `constant' so that different features
(conditions (1) and (2), respectively) of the latter ones are combined in
`variable'. 

There is another issue with the usage of boost::noncopyable (see
comments in cltree.cpp) but that is not important to me at this moment.

Pearu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cltree.cpp
Type: text/x-c++src
Size: 1930 bytes
Desc: 
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020528/d3d9e4c9/attachment.cpp>
-------------- next part --------------
#!/usr/bin/env python

from cltree import basic,symbol,constant,variable

b = basic()
c = constant()
s = symbol()
v = variable()

assert isinstance(b,basic)
assert not isinstance(b,symbol)
assert not isinstance(b,constant)
assert not isinstance(b,variable)

assert isinstance(c,basic)
assert isinstance(c,constant)
assert not isinstance(c,symbol)
assert not isinstance(c,variable)

assert not isinstance(s,basic)
assert isinstance(s,symbol)
assert not isinstance(s,constant)
assert not isinstance(s,variable)

assert isinstance(v,basic)
assert not isinstance(v,symbol)
assert not isinstance(v,constant)
assert isinstance(v,variable)

print 'b=',b
assert repr(b)=='cltree.basic()'
print 's=',s
assert repr(s)!='cltree.wrapped_symbol()' # because not isinstance(s,basic)
print 'c=',c
assert repr(c)=='cltree.constant()'
print 'v=',v
assert repr(v)=='cltree.wrapped_variable()'


print 'ok'
-------------- next part --------------
#!/usr/bin/env python2.2

boost_dir = 'boost' # /path/to/boost/dir
gcc_exe = 'gcc'
gpp_exe = 'g++'

import sys,os

if sys.version < '2.2':
    print 'Python >=2.2 is required but got '+sys.version[:6]
    sys.exit()

if not os.path.isdir(boost_dir):
    print 'No Boost directory',boost_dir
    sys.exit()

bpl_dir = os.path.join(boost_dir,'libs/python/src')
bpl_src = ['converter/from_python.cpp',
           'converter/registry.cpp',
           'converter/type_id.cpp',
           'object/class.cpp',
           'object/function.cpp',
           'object/inheritance.cpp',
           'object/life_support.cpp',
           'errors.cpp',
           'module.cpp',
           'objects.cpp',
           'converter/builtin_converters.cpp',
           'converter/callback.cpp',
           ]
bpl_src = [os.path.join(bpl_dir,s) for s in bpl_src]

from distutils.core import setup, Extension

ext = Extension('cltree',
                sources=bpl_src + ['cltree.cpp'],
                include_dirs=[boost_dir],
                define_macros = [('BOOST_PYTHON_DYNAMIC_LIB',None),
                                 ('BOOST_PYTHON_V2',None)],
                )

#+++HACK: replace linker gcc with g++ +++++++++++

from distutils import sysconfig
save_init_posix = sysconfig._init_posix
def my_init_posix():
    save_init_posix()
    g = sysconfig._config_vars
    for n,r in [('LDSHARED',gpp_exe),('CC',gcc_exe)]:
        if g[n][:3]=='gcc':
            print 'my_init_posix: changing %s = %r'%(n,g[n]),
            g[n] = r+g[n][3:]
            print 'to',`g[n]`
sysconfig._init_posix = my_init_posix

if __name__ == "__main__":
    setup (ext_modules = [ext])


From david.abrahams at rcn.com  Tue May 28 21:22:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 28 May 2002 15:22:06 -0400
Subject: [C++-sig] BPL, Mingw g++, and MSVC Python
References: <Pine.LNX.4.44.0205281421090.21824-100000@stat.harvard.edu>
Message-ID: <015c01c2067c$f7995e10$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "John Barnard" <barnard at stat.harvard.edu>


> I'm trying to determine if it's possible to do the following under MS
> Windows 2000:
>
> (1) Compile a C++ class file into a DLL using Mingw g++ 2.95.3 or 3.1;
>
> (2) Create a Python interface to the class using Boost.Python v2, again
> using Mingw g++ 2.95.3 or 3.1
>
> (3) Call the Python interface DLL from a MSVC++ compiled Python 2.2.
>
> I'm mainly confused about the ability of a g++ compiled Python extension
> to use g++ compiled DLLs (created from C++ source) when using a MSVC++
> compiled version of Python. Given that only the DLL version of BPL is
> being supported, if my above scenario can't be done, does that imply
> you can't create wrappers to C++ code via BPL with g++ and use them with
> MSVC++ compiled Python?
>
> I've done this in the past with a static lib of Boost.Python v1 but I
> would like to use v2.

I don't see any reason this should be a problem. The only limitations are
that

1. bpl.dll must be compiled with the same compiler as the extension module
and your "class DLL" (or one with a compatible C++ ABI, c.f. intel/msvc)

2. The compiler used to build Python must have a 'C' ABI which is
compatible with that of the compilers used for the DLLs. As far as I know,
all Windows compilers have compatible 'C' ABIs. I regularly test
MINGW-compiled extensions and bpl.dll with an MSVC6-compiled Python.

-Dave






From david.abrahams at rcn.com  Tue May 28 22:48:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 28 May 2002 16:48:02 -0400
Subject: [C++-sig] An issue with wrapping class trees (BPL V2)
References: <Pine.LNX.4.21.0205282153220.17411-400000@cens.ioc.ee>
Message-ID: <01ca01c20689$0e6b3b70$6401a8c0@boostconsulting.com>

You haven't told Boost.Python that variable and symbol are derived from
basic, so it can't convert the first argument to the exposed __repr__
function to basic*.

You need to use bases<basic> in the class_ argument lists, or you need to
re-expose repr() separately for each derived class.

-Dave

----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>
To: <c++-sig at python.org>
Sent: Tuesday, May 28, 2002 3:24 PM
Subject: [C++-sig] An issue with wrapping class trees (BPL V2)


>
> Hi David,
>
> On Tue, 28 May 2002, David Abrahams wrote:
>
> > ----- Original Message -----
> > From: "Pearu Peterson" <pearu at cens.ioc.ee>
> >
> > > Yes, I see it. However, currently my show stopper is how to insert
> > > wrapped classes into a class inheritance tree in a 'natural' way :-(.
> > > See the end of this message:
> > >
> > > http://mail.python.org/pipermail/c++-sig/2002-May/001058.html
> >
> > Can you send me a minimal, complete example which demonstrates the
problem
> > you're having?
>
> Sure, please find attached three files:
>
>   cltree.cpp, test_cltree.py, setup_cltree.py
>
> When I run
>
>   python setup_cltree.py build --build-platlib=.
>   # I am not using jam as you may notice ;-)
>   python test_cltree.py
>
> I get
>
> b= cltree.basic()
> s= <__main__.symbol object at 0x80fcd64>
> c= cltree.constant()
> v=
> Traceback (most recent call last):
>   File "test_cltree.py", line 36, in ?
>     print 'v=',v
> TypeError: bad argument type for built-in operation
>
>
> Expected behaviour would be the following output
>
> b= cltree.basic()
> s= <__main__.symbol object at 0x80fcd64>
> c= cltree.constant()
> v= cltree.wrapped_variable()
> ok
>
>
> If you look cltree.cpp then I am basically interested in exposing classes
> `basic' and `variable' to Python under the following conditions:
>
> 1) class `variable' is a subclass of `basic' also in Python
> 2) class `variable' is exposed to Python using `variable_wrapper' (so
that
>    I can re-define constructors)
>
> Classes `symbol' and `constant' are there only for testing, you can
> ignore them. In some sense, exposing `variable' is a combination of
> exposing `symbol' and `constant' so that different features
> (conditions (1) and (2), respectively) of the latter ones are combined in
> `variable'.
>
> There is another issue with the usage of boost::noncopyable (see
> comments in cltree.cpp) but that is not important to me at this moment.
>
> Pearu
>





From pearu at cens.ioc.ee  Tue May 28 23:09:18 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 29 May 2002 00:09:18 +0300 (EEST)
Subject: [C++-sig] An issue with wrapping class trees (BPL V2)
In-Reply-To: <01ca01c20689$0e6b3b70$6401a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205282354320.21085-100000@cens.ioc.ee>

On Tue, 28 May 2002, David Abrahams wrote:

> You haven't told Boost.Python that variable and symbol are derived from
> basic, so it can't convert the first argument to the exposed __repr__
> function to basic*.

Not telling that to `symbol' was intentional (as I also mentioned in
my comments) but I *did* tell that to variable:

    .add(boost::python::class_<variable
	 ,boost::python::bases<basic>  //    <<==== *** SEE THIS ***
	 ,variable_wrapper
	 //,boost::noncopyable // leads to compiler failure?!
	 >("variable")
	 .def_init(boost::python::args<>())
	 )
 
> You need to use bases<basic> in the class_ argument lists, 

Did that. See above.

> or you need to re-expose repr() separately for each derived class.

Really don't want to do that. In the real case the class `basic' has about
40 methods and the number of derived classes is about 20. So you suggest
writing about 800 method definitions. And I have not counted the
additional wrappers needed to solve the int/float argument issue...

:-(
	Pearu





From david.abrahams at rcn.com  Wed May 29 01:44:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 28 May 2002 19:44:23 -0400
Subject: [C++-sig] An issue with wrapping class trees (BPL V2)
References: <Pine.LNX.4.21.0205282354320.21085-100000@cens.ioc.ee>
Message-ID: <021801c206a1$b129e790$6401a8c0@boostconsulting.com>

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

> > You need to use bases<basic> in the class_ argument lists, 
> 
> Did that. See above.

Uh, whoops. That one was my bug.
Thanks for finding it; the fix is in CVS.

-Dave






From pearu at cens.ioc.ee  Wed May 29 14:41:55 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 29 May 2002 15:41:55 +0300 (EEST)
Subject: [C++-sig] An issue with wrapping class trees (BPL V2)
In-Reply-To: <021801c206a1$b129e790$6401a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205291515030.6624-100000@cens.ioc.ee>

On Tue, 28 May 2002, David Abrahams wrote:

> 
> ----- Original Message ----- 
> From: "Pearu Peterson" <pearu at cens.ioc.ee>
> 
> > > You need to use bases<basic> in the class_ argument lists, 
> > 
> > Did that. See above.
> 
> Uh, whoops. That one was my bug.
> Thanks for finding it; the fix is in CVS.

Thanks!

	Pearu






From pearu at cens.ioc.ee  Wed May 29 19:27:54 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 29 May 2002 20:27:54 +0300 (EEST)
Subject: [C++-sig] Compiling converter/registry.cpp with gcc-3.0.4 failure.
Message-ID: <Pine.LNX.4.21.0205292023130.17194-100000@cens.ioc.ee>

Hi Dave,

I just noticed that when using gcc-3.0.4 I get compilation error when
compiling converter/registry.cpp:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -Iboost
-I/home/peterson/opt/include/python2.2 -c
boost/libs/python/src/converter/registry.cpp -o
build/temp.linux-i686-2.2/registry.o
In file included from boost/boost/python/converter/registry.hpp:8,
                 from boost/libs/python/src/converter/registry.cpp:6:
boost/boost/python/type_id.hpp: In member function `bool 
   boost::python::type_info::operator<(const
boost::python::type_info&) const':
boost/boost/python/type_id.hpp:73: `strcmp' undeclared in namespace `std'
boost/boost/python/type_id.hpp: In member function `bool 
   boost::python::type_info::operator==(const boost::python::type_info&) 
   const':
boost/boost/python/type_id.hpp:82: `strcmp' undeclared in namespace `std'
error: command 'gcc' failed with exit status 1


but using gcc-3.1 is a success. 
Is gcc 3.1 now the required compiler for BPL V2?

Regards,
	Pearu





From david.abrahams at rcn.com  Wed May 29 19:33:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 29 May 2002 13:33:08 -0400
Subject: [C++-sig] Compiling converter/registry.cpp with gcc-3.0.4 failure.
References: <Pine.LNX.4.21.0205292023130.17194-100000@cens.ioc.ee>
Message-ID: <021501c20737$3b6e3830$6601a8c0@boostconsulting.com>

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


>
> Hi Dave,
>
> I just noticed that when using gcc-3.0.4 I get compilation error when
> compiling converter/registry.cpp:
>
>
> but using gcc-3.1 is a success.
> Is gcc 3.1 now the required compiler for BPL V2?

Not intentionally; I'll be checking in a fix for this problem today. Anyone
who gets it in the meantime can add #include <cstring> to
boost/python/type_id.hpp

Thanks for the report,
Dave






From rwgk at yahoo.com  Thu May 30 00:05:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 29 May 2002 15:05:42 -0700 (PDT)
Subject: [C++-sig] constructor wrappers?
Message-ID: <20020529220542.44781.qmail@web20210.mail.yahoo.com>

Would something like the following be possible/desirable?

struct any
{
  any(int a=0, int b=0, int c=0) { ... }
};

any any_from_python_list_or_tuple(PyObject* list_or_tuple)
{
  // extract between 0 and 3 int from a list or tuple and use to construct
  // an object any_instance.
  return any_instance;
}

BOOST_PYTHON_MODULE_INIT(any)
{
  boost::python::module this_module("any");

  this_module.add(
    boost::python::class_<any>("any")
      .def_init(any_from_python_list_or_tuple)
  );

}

I guess what I am after is an equivalent of the thin wrappers for member
functions, some easy-to-use flexible mechanism for "customizing" constructors
when they are exposed to Python.

Thanks,
        Ralf


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




From pearu at cens.ioc.ee  Thu May 30 00:14:11 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 30 May 2002 01:14:11 +0300 (EEST)
Subject: [C++-sig] constructor wrappers?
In-Reply-To: <20020529220542.44781.qmail@web20210.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0205300112370.21191-100000@cens.ioc.ee>

On Wed, 29 May 2002, Ralf W. Grosse-Kunstleve wrote:

> Would something like the following be possible/desirable?
<snip>

don't know/YES!

Pearu





From rwgk at yahoo.com  Thu May 30 01:44:32 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 29 May 2002 16:44:32 -0700 (PDT)
Subject: [C++-sig] V2 equivalent of make_ref
Message-ID: <20020529234432.77597.qmail@web20209.mail.yahoo.com>

What is the equivalent of make_ref in V2?
Here is what I would like to do:

boost::python::module("any")
  .add("__version__", boost::python::make_ref("1.2.3"));

I tried to find the documentation for boost::python::ref but the link to
reference_hpp.html is broken.

Thanks,
        Ralf


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




From rwgk at yahoo.com  Thu May 30 02:19:06 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 29 May 2002 17:19:06 -0700 (PDT)
Subject: [C++-sig] cannot return boost::python::tuple
Message-ID: <20020530001906.1173.qmail@web20207.mail.yahoo.com>

I am having trouble returning a boost::python::tuple.
This works (reports None when called from Python):

  void//boost::python::tuple
  UnitCell_getinitargs(const UnitCell& uc) {
    boost::python::tuple initargs;
    //return initargs;
  }

This is what I really want:

  boost::python::tuple
  UnitCell_getinitargs(const UnitCell& uc) {
    boost::python::tuple initargs;
    return initargs;
  }

But I get:

Traceback (most recent call last):
  File "dbg.py", line 6, in ?
    print u.__getinitargs__()
TypeError: bad argument type for built-in operation

What am I doing wrong?

Thanks,
        Ralf


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




From david.abrahams at rcn.com  Thu May 30 05:15:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 29 May 2002 23:15:10 -0400
Subject: [C++-sig] cannot return boost::python::tuple
References: <20020530001906.1173.qmail@web20207.mail.yahoo.com>
Message-ID: <045701c20788$3b5e55e0$6601a8c0@boostconsulting.com>

Ralf,

The user-friendly explicit conversions and conversions for the builtin type
wrappers are two of the areas where v2 lags behind v1. The documentation
also lags here, since the interface isn't complete yet.

make_ref is currently spelled:

    ref(boost::python::converter::callback_to_python<T>(x).get(),
ref::increment_count)

Though none of those interfaces are guaranteed to be stable. You could
write it thus, for the time being:

    template <class T>
    ref make_ref(T const& x)
    {
        return
ref(boost::python::converter::callback_to_python<T>(x).get(),
ref::increment_count);
    }


As for returing a tuple, for the time being you must return a PyObject*.
Adding the conversions will be relatively easy; it just has to get done.
So, for now:

    return initargs.reference().release();

HTH,
Dave

------

Ralf wrote:

> What is the equivalent of make_ref in V2?
> Here is what I would like to do:
>
> boost::python::module("any")
>   .add("__version__", boost::python::make_ref("1.2.3"));
>
> I tried to find the documentation for boost::python::ref but the link to
> reference_hpp.html is broken.

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


> I am having trouble returning a boost::python::tuple.
> This works (reports None when called from Python):
>
>   void//boost::python::tuple
>   UnitCell_getinitargs(const UnitCell& uc) {
>     boost::python::tuple initargs;
>     //return initargs;
>   }
>
> This is what I really want:
>
>   boost::python::tuple
>   UnitCell_getinitargs(const UnitCell& uc) {
>     boost::python::tuple initargs;
>     return initargs;
>   }
>
> But I get:
>
> Traceback (most recent call last):
>   File "dbg.py", line 6, in ?
>     print u.__getinitargs__()
> TypeError: bad argument type for built-in operation
>
> What am I doing wrong?






From rwgk at yahoo.com  Thu May 30 09:39:09 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 00:39:09 -0700 (PDT)
Subject: [C++-sig] cannot return boost::python::tuple
In-Reply-To: <045701c20788$3b5e55e0$6601a8c0@boostconsulting.com>
Message-ID: <20020530073909.17078.qmail@web20203.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
>     template <class T>
>     ref make_ref(T const& x)
>     {
>         return
> ref(boost::python::converter::callback_to_python<T>(x).get(),
> ref::increment_count);
>     }

This works great.

> As for returing a tuple, for the time being you must return a PyObject*.
> Adding the conversions will be relatively easy; it just has to get done.
> So, for now:
> 
>     return initargs.reference().release();

This works great, too.

And, cool, this works, too:

  boost::python::module("any")
    .setattr("__version__", boost::python::make_ref("1.2.3"));

What keeps you from including make_ref in reference.hpp?

Thanks,
        Ralf

P.S.: Did you notice my "constructor wrapper" question?


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




From rwgk at yahoo.com  Thu May 30 10:22:06 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 01:22:06 -0700 (PDT)
Subject: [C++-sig] same to_python_converter in multiple modules?
Message-ID: <20020530082206.27388.qmail@web20210.mail.yahoo.com>

Here is less contrived example for doc/v2/to_python_converter.html:

  template <typename ElementType, std::size_t N>
  struct boost_array_to_tuple
  {
    static PyObject* convert(boost::array<ElementType, N> const& a)
    {
      boost::python::tuple result(a.size());
      for(std::size_t i=0;i<a.size();i++) {
        result.set_item(i, boost::python::make_ref(a[i]));
      }
      return result.reference().release();
    }
  };

  boost::python::to_python_converter<
    boost::array<int, 3>, boost_array_to_tuple<int, 3> >();

If I have two independent modules that both need this converter,
where would I put the last statement. In both modules? What happens
if both modules are loaded at the same time? What if I have 30 modules
that need this converter (this will happen in our application)?

Thanks,
        Ralf


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




From ssmith at magnet.fsu.edu  Thu May 30 14:57:32 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 30 May 2002 08:57:32 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <01a701c20273$a6d00360$6501a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEKEALCCAA.ssmith@magnet.fsu.edu>

Hi Dave,

I had time to look at the Boost.Python build under OS X again.
Recall that the build dies in the linking step, complaining about
undefined symbols:

> > /usr/bin/ld: Undefined symbols:
> > _main
> > _PyErr_SetObject
> > _PyErr_SetString
> > _PyExc_IndexError
> > _PyExc_RuntimeError
> > _PyExc_ValueError
>
> OK, it looks like OS X might be one of those platforms which requires
> linking against the Python library. Try adding -lpython to the
> command line

That didn't work, but adding -lpython2.2 did remove this set. On the
Mac I have (Python installed using Fink), things reside in /sw/lib/python2.2
and there is a library libpython2.2.a in the config sub-directory from
there.

> > _main
> > ___builtin_delete
> > ___builtin_new
> > ___cp_push_exception
> > ___eh_alloc
> > ___pure_virtual
> > ___rtti_si
> > ___rtti_user
> > ___throw
> > ___vt_9exception
>
> These are functions in your compiler's runtime library. Have you got
> multiple versions of GCC installed? In particular, have you got a 2.95.x
> and a 3.x version installed? If so, you may not have properly supplied
> GCC_ROOT_DIRECTORY to let the build system know how to find the runtime.

No, I am pretty sure that there is only a single GCC on the system. It is
2.95.2 (which they call 934.2 in the OS X port) and invoked with "cc" not
"gcc". Similarly, g++ is invoked with c++. I had a look in /usr/lib and
found that this is were libstdc++.a lives, so I set the variable
GCC_ROOT_DIRECTORY to /usr. Unfortunately the above group of symbols are
still undefined. Any ideas?

Thanks,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From david.abrahams at rcn.com  Thu May 30 15:05:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 09:05:49 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEKEALCCAA.ssmith@magnet.fsu.edu>
Message-ID: <002301c207da$ffcc28b0$6601a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hi Dave,
>
> I had time to look at the Boost.Python build under OS X again.
> Recall that the build dies in the linking step, complaining about
> undefined symbols:
>
> > > /usr/bin/ld: Undefined symbols:
> > > _main
> > > _PyErr_SetObject
> > > _PyErr_SetString
> > > _PyExc_IndexError
> > > _PyExc_RuntimeError
> > > _PyExc_ValueError
> >
> > OK, it looks like OS X might be one of those platforms which requires
> > linking against the Python library. Try adding -lpython to the
> > command line
>
> That didn't work, but adding -lpython2.2 did remove this set. On the
> Mac I have (Python installed using Fink), things reside in
/sw/lib/python2.2
> and there is a library libpython2.2.a in the config sub-directory from
> there.

that sounds OK.

> > > _main
> > > ___builtin_delete
> > > ___builtin_new
> > > ___cp_push_exception
> > > ___eh_alloc
> > > ___pure_virtual
> > > ___rtti_si
> > > ___rtti_user
> > > ___throw
> > > ___vt_9exception
> >
> > These are functions in your compiler's runtime library. Have you got
> > multiple versions of GCC installed? In particular, have you got a
2.95.x
> > and a 3.x version installed? If so, you may not have properly supplied
> > GCC_ROOT_DIRECTORY to let the build system know how to find the
runtime.
>
> No, I am pretty sure that there is only a single GCC on the system. It is
> 2.95.2 (which they call 934.2 in the OS X port) and invoked with "cc" not
> "gcc". Similarly, g++ is invoked with c++. I had a look in /usr/lib and
> found that this is were libstdc++.a lives, so I set the variable
> GCC_ROOT_DIRECTORY to /usr. Unfortunately the above group of symbols are
> still undefined. Any ideas?

Hmm, if it's looking for _main, it seems as though it thinks you're trying
to build an executable. Are you using Boost.Build or are you trying to do
something else?

Also, are you building your own extension at this point, or just trying to
build bpl.so?

-Dave






From david.abrahams at rcn.com  Thu May 30 15:36:22 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 09:36:22 -0400
Subject: [C++-sig] cannot return boost::python::tuple
References: <20020530073909.17078.qmail@web20203.mail.yahoo.com>
Message-ID: <000d01c207df$157c8a20$6601a8c0@boostconsulting.com>

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

> This works great, too.
>
> And, cool, this works, too:
>
>   boost::python::module("any")
>     .setattr("__version__", boost::python::make_ref("1.2.3"));
>
> What keeps you from including make_ref in reference.hpp?

One reason is the best V2 interface to boost::python:;reference has not
been settled. A few of these things require just a little consideration.
For one thing, the name should change, at least to make_reference(), since
"ref" is going to be deprecated in favor of reference<>.

> P.S.: Did you notice my "constructor wrapper" question?

I did. I'll try to answer it later today.

-Dave






From david.abrahams at rcn.com  Thu May 30 15:42:51 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 09:42:51 -0400
Subject: [C++-sig] same to_python_converter in multiple modules?
References: <20020530082206.27388.qmail@web20210.mail.yahoo.com>
Message-ID: <001601c207e0$7c02eb30$6601a8c0@boostconsulting.com>

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


> Here is less contrived example for doc/v2/to_python_converter.html:
>
>   template <typename ElementType, std::size_t N>
>   struct boost_array_to_tuple
>   {
>     static PyObject* convert(boost::array<ElementType, N> const& a)
>     {
>       boost::python::tuple result(a.size());
>       for(std::size_t i=0;i<a.size();i++) {
>         result.set_item(i, boost::python::make_ref(a[i]));
>       }
>       return result.reference().release();
>     }
>   };
>
>   boost::python::to_python_converter<
>     boost::array<int, 3>, boost_array_to_tuple<int, 3> >();
>
> If I have two independent modules that both need this converter,
> where would I put the last statement. In both modules? What happens
> if both modules are loaded at the same time? What if I have 30 modules
> that need this converter (this will happen in our application)?

These are all good questions. Right now, I think the behavior is to assert
if you supply two to_python converters for the same type. Since conversions
go into a global registry and since there are no criteria upon which to
choose a to_python conversion other than the source type, it is treated as
an error to register two converters for the same type. What would the
most-useful behavior be? You can of course avoid multiple registrations by
creating a common shared library (or Python module if need be) which
registers the converter and sets a global variable to prevent multiple
registration.

-Dave






From ssmith at magnet.fsu.edu  Thu May 30 16:07:48 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 30 May 2002 10:07:48 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <002301c207da$ffcc28b0$6601a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEOEAOCCAA.ssmith@magnet.fsu.edu>

Hi again,

> Hmm, if it's looking for _main, it seems as though it thinks you're trying
> to build an executable. Are you using Boost.Build or are you trying to do
> something else?

I am just running bjam in the libs/python/build subdirectory, is that using
Boost.Build? What is Boost.Build, just the hierarchy of Jam files for Boost?

> Also, are you building your own extension at this point, or just trying to
> build bpl.so?

Just trying to build the Boost.Python library. This was
boost_python.(dll/lib)
on my PC with both Cygwin & MSVC++. Is this called bpl.so on Unix systems?
If so, then yes that is what I am trying to make.

Here is a recap:

1.) Max OS X, GCC 2.95.2, Python 2.2.1, Boost 1.28.0
2.) Build bjam.exe using plain "make", put it in my path
3.) Set PYTHON_ROOT and PYTHON_VERSION
4.) Ran bjam -sTOOLS=gcc -sBUILD=release in libs/python/build
5.) Hoped for the best

This made the object files fine but had trouble during the linking
step because there were may udefined symbols. At your suggestion
I ran that step by hand, adding in the python2.2 library explictly.
That cleared up some of the symbols, but not all. I then set the
GCC_ROOT_DIRECTORY variable hoping to get rid of more, but to no
avail.

Here is the full command and output, yuk.

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

export LD_LIBRARY_PATH
c++   -s -fPIC -shared  -o
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
on2.2/config
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/types.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/classes.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/conversions.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/extension_class.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/functions.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/init_function.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/module_builder.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/objects.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/cross_module.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/errors.o" -lpython2.2

/usr/bin/ld: Undefined symbols:
_main
___builtin_delete
___builtin_new
___cp_push_exception
___eh_alloc
___pure_virtual
___rtti_si
___rtti_user
___throw
___vt_9exception
_terminate__Fv
___cp_pop_exception
___rtti_func
___rtti_ptr
___start_cp_handler
___eh_rtime_match
___tf8bad_cast
___tfSc
___tfUc
___tfUi
___tfUl
___tfUs
___tfi
___tfs
___ti8bad_cast
___vt_8bad_cast
___eq__C9type_infoRCB0
___rtti_class
___tf9bad_alloc
___tf9exception
restFP
saveFP
___eprintf
___ti9exception

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

Note that the bjam command directly will also produce the problem
with _main (so it's less likely I goofed in copying the c++ command line).
Could this be a problem in the compilation/link flags set? I read that
they want users to insure that no pre-compiled headers are used and that
there is some special treatment of shared libraries, but since I don't
full comprehend the Boost.build process I am a bit leery to experiment.
Should I try messing with python.jam and/or gcc-tools.jam? Perhaps there
is just some problem is setting the appropriate directories to look,
although setting  GCC_ROOT_DIRECTORY expliclty didn't do any good.

Regards,
Scott


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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu






From david.abrahams at rcn.com  Thu May 30 16:20:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 10:20:41 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEOEAOCCAA.ssmith@magnet.fsu.edu>
Message-ID: <006301c207e5$afe59880$6601a8c0@boostconsulting.com>

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Thursday, May 30, 2002 10:07 AM
Subject: RE: [C++-sig] Link trouble on OS X


> Hi again,
>
> > Hmm, if it's looking for _main, it seems as though it thinks you're
trying
> > to build an executable. Are you using Boost.Build or are you trying to
do
> > something else?
>
> I am just running bjam in the libs/python/build subdirectory, is that
using
> Boost.Build?

Yes.

> What is Boost.Build, just the hierarchy of Jam files for Boost?

It's more the contents of the tools/build directory.

> > Also, are you building your own extension at this point, or just trying
to
> > build bpl.so?
>
> Just trying to build the Boost.Python library. This was
> boost_python.(dll/lib)
> on my PC with both Cygwin & MSVC++. Is this called bpl.so on Unix
systems?

Yes.

> If so, then yes that is what I am trying to make.
>
> Here is a recap:

<snip>

> Here is the full command and output, yuk.
>
> =================================================================
>
> export LD_LIBRARY_PATH
> c++   -s -fPIC -shared  -o
>
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
r
>
ntime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
> on2.2/config

<snip>

> untime-link-dynamic/shared-linkable-true/errors.o" -lpython2.2
>
> /usr/bin/ld: Undefined symbols:
> _main
  ...

Thanks, this stuff helps.

> =================================================================
>
> Note that the bjam command directly will also produce the problem
> with _main (so it's less likely I goofed in copying the c++ command
line).
> Could this be a problem in the compilation/link flags set?

Yes, it could be. What does it take to build a shared library on OS X?
Normally, -fPIC -shared is enough to do it on a Linux/ELF system, but GCC
running on OS X may have different requirements.

> I read that
> they want users to insure that no pre-compiled headers are used

That's a non-issue in our case.

> and that
> there is some special treatment of shared libraries

If you can find out what that is, it would help, since that's what you're
trying to build.

> , but since I don't
> full comprehend the Boost.build process I am a bit leery to experiment.
> Should I try messing with python.jam and/or gcc-tools.jam?

I don't think that's a good idea. You have the entire text of the build
commands we're currently using. Why don't you stick those in a shell script
and twiddle the flags until you get it to work? If you can tell us what the
command-lines should look like, we can modify the appropriate parts of
Boost.Build to make it work.

> Perhaps there
> is just some problem is setting the appropriate directories to look,
> although setting  GCC_ROOT_DIRECTORY expliclty didn't do any good.

It doesn't look like  a search path problem to me at this point.

-Dave






From david.abrahams at rcn.com  Thu May 30 18:05:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 12:05:43 -0400
Subject: [C++-sig] constructor wrappers?
References: <20020529220542.44781.qmail@web20210.mail.yahoo.com>
Message-ID: <00f601c207f4$4a019eb0$6601a8c0@boostconsulting.com>

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


> Would something like the following be possible/desirable?
>
> struct any
> {
>   any(int a=0, int b=0, int c=0) { ... }
> };
>
> any any_from_python_list_or_tuple(PyObject* list_or_tuple)
> {
>   // extract between 0 and 3 int from a list or tuple and use to
construct
>   // an object any_instance.
>   return any_instance;
> }
>
> BOOST_PYTHON_MODULE_INIT(any)
> {
>   boost::python::module this_module("any");
>
>   this_module.add(
>     boost::python::class_<any>("any")
>       .def_init(any_from_python_list_or_tuple)
>   );
>
> }
>
> I guess what I am after is an equivalent of the thin wrappers for member
> functions, some easy-to-use flexible mechanism for "customizing"
constructors
> when they are exposed to Python.

I understand the goal, but I'm not sure what you've got there is the best
solution, for two reasons:

1. It incurs the cost of copying "any"
2. It requires the ability to copy "any", and not all class types are
copyable.

Currently, the way to do this is with a class derived from any:

    boost::python::class_<any,any_wrapper>("any")
        .def_init(args<PyObject*>()) // could use args<tuple> soon


Where

    any_wrapper::any_wrapper(PyObject* ignored, PyObject* seq)

is defined.

However, I'm open to other interface suggestions. I suggest you take a look
at the documentation for make_constructor and the Holder concept to get
started.

Also, part of the formula may involve some extensions to the CallPolicies
concept. For example, we might want to make it possible to specify the
from_python converter that gets used for each argument.

-Dave






From ssmith at magnet.fsu.edu  Thu May 30 18:31:41 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 30 May 2002 12:31:41 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <006301c207e5$afe59880$6601a8c0@boostconsulting.com>
Message-ID: <NFBBINAMBILHLOCDJKAEIEBACCAA.ssmith@magnet.fsu.edu>

Hi Dave,

> You have the entire text of the build
> commands we're currently using. Why don't you stick those in a
> shell script
> and twiddle the flags until you get it to work? If you can tell
> us what the
> command-lines should look like, we can modify the appropriate parts of
> Boost.Build to make it work.

Du-oh! OK, I have done just that and been moving along. The reference
sent in by Robert Andre

http://fink.sourceforge.net/doc/porting/shared.php

helps and agrees with what David Beasley wrote

c++ -c
$(SRCS) -I/sw/include/python2.2 -I/sw/lib/python2.2/config -DHAVE_CONFIG_H
c++ -bundle -undefined suppress -flat_namespace $(OBJS) -o somemodule.so

For the source codes compiler commands, I removed the fPIC, added the
include of
the python config directory, and set the variable HAVE_CONFIG_H. I also
added a
-Wno-long-double to suppress those warnings. For the final
linking, I added -bundle and -flat_namespace but it would not
accept -undefined supress.

This leaves me with only one unresolved symbol during the link:

_environ

Any idea if this is supposed to come from Boost, a Python, or the System?

Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From rwgk at yahoo.com  Thu May 30 19:53:01 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 10:53:01 -0700 (PDT)
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <NFBBINAMBILHLOCDJKAEIEBACCAA.ssmith@magnet.fsu.edu>
Message-ID: <20020530175301.89115.qmail@web20206.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> c++ -c
> $(SRCS) -I/sw/include/python2.2 -I/sw/lib/python2.2/config -DHAVE_CONFIG_H
> c++ -bundle -undefined suppress -flat_namespace $(OBJS) -o somemodule.so
> 
> For the source codes compiler commands, I removed the fPIC, added the
> include of
> the python config directory, and set the variable HAVE_CONFIG_H. I also
> added a
> -Wno-long-double to suppress those warnings. For the final
> linking, I added -bundle and -flat_namespace but it would not
> accept -undefined supress.
> 
> This leaves me with only one unresolved symbol during the link:
> 
> _environ

I am not sure if this is helpful, but in my last attempt with V1 is was using
these flags:

c++ -fno-common -no-cpp-precomp -ftemplate-depth-50 -Wno-long-double -g -c

You might need to add -DBOOST_PYTHON_V2.

c++ -bundle -flat_namespace -undefined warning

The only undefined symbols I remember were missing template instantiations. I
am hoping that V2 does not suffer from this compiler/linker bug.

Ralf


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




From rwgk at yahoo.com  Thu May 30 20:06:40 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 11:06:40 -0700 (PDT)
Subject: [C++-sig] same to_python_converter in multiple modules?
In-Reply-To: <001601c207e0$7c02eb30$6601a8c0@boostconsulting.com>
Message-ID: <20020530180640.93387.qmail@web20208.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> These are all good questions. Right now, I think the behavior is to assert
> if you supply two to_python converters for the same type. Since conversions
> go into a global registry and since there are no criteria upon which to
> choose a to_python conversion other than the source type, it is treated as
> an error to register two converters for the same type. What would the
> most-useful behavior be? You can of course avoid multiple registrations by
> creating a common shared library (or Python module if need be) which
> registers the converter and sets a global variable to prevent multiple
> registration.

Common shared library sounds OK, but the global variable is redundant. How
about enriching the Boost.Python interface:

  boost::python::to_python_converter<
    boost::array<int, 3>, bpl::boost_array_to_tuple<int, 3> >(
      boost::python::do_nothing_if_already_registered());

If the alternative as an assert, even that is redundant, but makes it clear
what will happen and it leaves the door open for future more sophisticated
mechanisms.

Ralf


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




From rwgk at yahoo.com  Thu May 30 20:31:21 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 11:31:21 -0700 (PDT)
Subject: [C++-sig] constructor wrappers?
In-Reply-To: <00f601c207f4$4a019eb0$6601a8c0@boostconsulting.com>
Message-ID: <20020530183122.96975.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> I understand the goal, but I'm not sure what you've got there is the best
> solution, for two reasons:
> 
> 1. It incurs the cost of copying "any"
> 2. It requires the ability to copy "any", and not all class types are
> copyable.

In the vast majority of cases (and there were many) where I was craving for a
light-weight method of defining additional Python-specific constructors both 1.
and 2. are not a problem. (Almost all my types are tiny. For large arrays I use
a reference counted look-alike of std::vector.)

> Currently, the way to do this is with a class derived from any:
> 
>     boost::python::class_<any,any_wrapper>("any")
>         .def_init(args<PyObject*>()) // could use args<tuple> soon
> 
> 
> Where
> 
>     any_wrapper::any_wrapper(PyObject* ignored, PyObject* seq)
> 
> is defined.

This seems to resemble what I did in V1. I would call this the heavy-weight
alternative. In practice I have often shied away from this in favor of simpler
but more klunky approaches. IMO the average user would be much better served
with the light-weight alternative because it requires less code and, almost
more importantly, is easier to understand.

> However, I'm open to other interface suggestions. I suggest you take a look
> at the documentation for make_constructor and the Holder concept to get
> started.

I will have a look.

> Also, part of the formula may involve some extensions to the CallPolicies
> concept. For example, we might want to make it possible to specify the
> from_python converter that gets used for each argument.

For a start I would be happy with the famous "70% solution." Add more
sophistication depending on user demand.

Ralf


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




From david.abrahams at rcn.com  Thu May 30 21:35:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 15:35:04 -0400
Subject: [C++-sig] same to_python_converter in multiple modules?
References: <20020530180640.93387.qmail@web20208.mail.yahoo.com>
Message-ID: <01c201c20811$cb832130$6601a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > These are all good questions. Right now, I think the behavior is to
assert
> > if you supply two to_python converters for the same type. Since
conversions
> > go into a global registry and since there are no criteria upon which to
> > choose a to_python conversion other than the source type, it is treated
as
> > an error to register two converters for the same type. What would the
> > most-useful behavior be? You can of course avoid multiple registrations
by
> > creating a common shared library (or Python module if need be) which
> > registers the converter and sets a global variable to prevent multiple
> > registration.
>
> Common shared library sounds OK, but the global variable is redundant.

Only if you're using static initializers to register the converter, or if
the module load order is deterministic (but then, you could always register
the converter from the first module).

> How
> about enriching the Boost.Python interface:
>
>   boost::python::to_python_converter<
>     boost::array<int, 3>, bpl::boost_array_to_tuple<int, 3> >(
>       boost::python::do_nothing_if_already_registered());
>
> If the alternative as an assert, even that is redundant, but makes it
clear
> what will happen and it leaves the door open for future more
sophisticated
> mechanisms.

I'm not sure whether that's enriching or en-crufting the interface. It
certainly could encourage people to make lots of extension modules with
duplicate converters, which in turn could make their modules bigger and
compilation slower. I'd like to think about this some more and/or hear some
other ideas.

-Dave






From david.abrahams at rcn.com  Thu May 30 21:48:00 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 15:48:00 -0400
Subject: [C++-sig] constructor wrappers?
References: <20020530183122.96975.qmail@web20204.mail.yahoo.com>
Message-ID: <01df01c20813$324811e0$6601a8c0@boostconsulting.com>

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

> --- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> > I understand the goal, but I'm not sure what you've got there is
> > the best solution, for two reasons:
> > 
> > 1. It incurs the cost of copying "any"
> > 2. It requires the ability to copy "any", and not all class types
> > are copyable.
> 
> In the vast majority of cases (and there were many) where I was
> craving for a light-weight method of defining additional
> Python-specific constructors both 1.  and 2. are not a
> problem. (Almost all my types are tiny. For large arrays I use a
> reference counted look-alike of std::vector.)

I understand that your solution works for your problems.

> > Currently, the way to do this is with a class derived from any:
> > 
> >     boost::python::class_<any,any_wrapper>("any")
> >         .def_init(args<PyObject*>()) // could use args<tuple> soon
> > 
> > 
> > Where
> > 
> >     any_wrapper::any_wrapper(PyObject* ignored, PyObject* seq)
> > 
> > is defined.
> 
> This seems to resemble what I did in V1. I would call this the
> heavy-weight alternative. In practice I have often shied away from
> this in favor of simpler but more klunky approaches. IMO the average
> user would be much better served with the light-weight alternative
> because it requires less code and, almost more importantly, is
> easier to understand.

I think of the derived class wrapper approach as a kludgy workaround,
not a solution. I'm in favor of a lighter-weight alternative, but I
also want it to be efficient and flexible. In library design you often
have to be careful to get the interface right the first time, because
you're stuck with the results essentially forevermore.

> > However, I'm open to other interface suggestions. I suggest you
> > take a look at the documentation for make_constructor and the
> > Holder concept to get started.
> 
> I will have a look.
> 
> > Also, part of the formula may involve some extensions to the
> > CallPolicies concept. For example, we might want to make it
> > possible to specify the from_python converter that gets used for
> > each argument.
> 
> For a start I would be happy with the famous "70% solution." Add
> more sophistication depending on user demand.

Of course you would, but then you won't have to explain to other users
why lightweight constructor wrappers cause them to make a copy of the
std::vector<> they are wrapping ;-)

-Dave





From ssmith at magnet.fsu.edu  Thu May 30 21:53:02 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 30 May 2002 15:53:02 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <20020530175301.89115.qmail@web20206.mail.yahoo.com>
Message-ID: <NFBBINAMBILHLOCDJKAECEBBCCAA.ssmith@magnet.fsu.edu>

Greetings,

> I am not sure if this is helpful, but in my last attempt with V1
> is was using these flags:
>
> c++ -fno-common -no-cpp-precomp -ftemplate-depth-50 -Wno-long-double -g -c
>
> You might need to add -DBOOST_PYTHON_V2.
>
> c++ -bundle -flat_namespace -undefined warning
>
> The only undefined symbols I remember were missing template
> instantiations. I am hoping that V2 does not suffer from this
compiler/linker bug.

Thanks Ralf, I did not try -undefined warning before since it would not take
-undefined suppress. This build produced libboost_python.so, a rather large
one
(> 2.6 MB), with just a warning that it did not know _environ. The
definition of
BOOST_PYTHON_V2 really produced a lot of problems, so I did not use that.

I have no idea if  the library is any good. That will have to wait until
I try using it later.

Thanks for all the help,
Scott

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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu






From david.abrahams at rcn.com  Thu May 30 22:19:27 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 16:19:27 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAECEBBCCAA.ssmith@magnet.fsu.edu>
Message-ID: <023b01c20817$6d52d410$6601a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
> Thanks Ralf, I did not try -undefined warning before since it would not
take
> -undefined suppress. This build produced libboost_python.so, a rather
large
> one
> (> 2.6 MB), with just a warning that it did not know _environ. The
> definition of
> BOOST_PYTHON_V2 really produced a lot of problems, so I did not use that.

...Because you are building Boost.Python v1, not v2.







From rwgk at yahoo.com  Thu May 30 22:24:01 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 13:24:01 -0700 (PDT)
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <NFBBINAMBILHLOCDJKAECEBBCCAA.ssmith@magnet.fsu.edu>
Message-ID: <20020530202401.21644.qmail@web20206.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> Thanks Ralf, I did not try -undefined warning before since it would not take
> -undefined suppress. This build produced libboost_python.so, a rather large
> one
> (> 2.6 MB), with just a warning that it did not know _environ. The
> definition of
> BOOST_PYTHON_V2 really produced a lot of problems, so I did not use that.

Are you trying to build a V1 libbpl.so? IMO it is not worth investing time in
this. You should definitely try the V2 build. For that you have to use the
Jamfile in libs/python (not libs/python/build) to get a start, then try the Mac
specific options.
Ralf


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




From david.abrahams at rcn.com  Thu May 30 22:29:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 16:29:09 -0400
Subject: [C++-sig] Link trouble on OS X
References: <NFBBINAMBILHLOCDJKAEIEBACCAA.ssmith@magnet.fsu.edu>
Message-ID: <026001c20818$d3499f50$6601a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hi Dave,
>
> Du-oh! OK, I have done just that and been moving along. The reference
> sent in by Robert Andre
>
> http://fink.sourceforge.net/doc/porting/shared.php
>
> helps and agrees with what David Beasley wrote
>
> c++ -c
>
$(SRCS) -I/sw/include/python2.2 -I/sw/lib/python2.2/config -DHAVE_CONFIG_H
> c++ -bundle -undefined suppress -flat_namespace $(OBJS) -o somemodule.so

What is -DHAVE_CONFIG_H for? Doesn't compilation succeed without it?
I don't think -bundle sounds right for bpl.so, though you might want it for
your extension modules. From looking at the link above, bpl.so falls
squarely in the shared library category, NOT in the "module" category.

Since bpl.so uses symbols from the Python executable, -undefined suppress
looks like it might be needed. The link doesn't describe
what -flat_namespace does so I can't really say whether you want that or
not.

> For the source codes compiler commands, I removed the fPIC,

According to the link fPIC has no effect on PPC, so I guess that's
harmless.

> added the include of the python config directory

If everything was compiling into .o files, you probably didn't need that.
I'm guessing there's some interaction with HAVE_CONFIG_H, though. Is there
a header file in that directory?

-Dave





From rwgk at yahoo.com  Thu May 30 22:36:47 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 13:36:47 -0700 (PDT)
Subject: [C++-sig] same to_python_converter in multiple modules?
In-Reply-To: <01c201c20811$cb832130$6601a8c0@boostconsulting.com>
Message-ID: <20020530203647.24454.qmail@web20206.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > Common shared library sounds OK, but the global variable is redundant.
> 
> Only if you're using static initializers to register the converter

I do not understand this. Could you please explain?

> > How
> > about enriching the Boost.Python interface:
> >
> >   boost::python::to_python_converter<
> >     boost::array<int, 3>, bpl::boost_array_to_tuple<int, 3> >(
> >       boost::python::do_nothing_if_already_registered());
> >
> > If the alternative as an assert, even that is redundant, but makes it
> clear
> > what will happen and it leaves the door open for future more
> sophisticated
> > mechanisms.
> 
> I'm not sure whether that's enriching or en-crufting the interface. It
> certainly could encourage people to make lots of extension modules with
> duplicate converters, which in turn could make their modules bigger and
> compilation slower. I'd like to think about this some more and/or hear some
> other ideas.

I see your point. I can live with the global variable approach and I will try
it out.

Ralf


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




From david.abrahams at rcn.com  Thu May 30 22:50:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 16:50:53 -0400
Subject: [C++-sig] same to_python_converter in multiple modules?
References: <20020530203647.24454.qmail@web20206.mail.yahoo.com>
Message-ID: <02bb01c2081c$039d4460$6601a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > > Common shared library sounds OK, but the global variable is
redundant.
> >
> > Only if you're using static initializers to register the converter
>
> I do not understand this. Could you please explain?

If you're going to call the registration function from multiple modules,
you need some mechanism to ensure that the actual work only gets done once.

-Dave






From david.abrahams at rcn.com  Thu May 30 22:53:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 16:53:10 -0400
Subject: [C++-sig] Link trouble on OS X
References: <20020530202401.21644.qmail@web20206.mail.yahoo.com>
Message-ID: <02bc01c2081c$03cc91c0$6601a8c0@boostconsulting.com>

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


> Are you trying to build a V1 libbpl.so? IMO it is not worth investing
time
> in this.

That really depends on how much V1-dependent code he's already written.

-Dave






From rwgk at yahoo.com  Thu May 30 23:00:52 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 14:00:52 -0700 (PDT)
Subject: [C++-sig] constructor wrappers?
In-Reply-To: <01df01c20813$324811e0$6601a8c0@boostconsulting.com>
Message-ID: <20020530210052.23741.qmail@web20204.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> I understand that your solution works for your problems.

How about giving me some credit for being a heavy user of Boost.Python?
Don't you think that many of my experiences are representative?

> I think of the derived class wrapper approach as a kludgy workaround,
> not a solution. I'm in favor of a lighter-weight alternative, but I
> also want it to be efficient and flexible. In library design you often
> have to be careful to get the interface right the first time, because
> you're stuck with the results essentially forevermore.

Yes. But if you had taken that philosophy too far would there be Boost.Python
V1? (with the returned reference problem, the friend function hack, and the
incomplete cross-module support.) It still is a great, ground-breaking library.

> > For a start I would be happy with the famous "70% solution." Add
> > more sophistication depending on user demand.
> 
> Of course you would, but then you won't have to explain to other users
> why lightweight constructor wrappers cause them to make a copy of the
> std::vector<> they are wrapping ;-)

This is going in the wrong direction. Now let me be on the other side of the
fence (striving for ideal solutions): The combination of std::vector and
Boost.Python is a major PITB. It was so painful that I wrote a fully fledged
reference counted array type. This clearly is the right solution.

Under the assumption that the proposed 70% solution can be achieved in 20% of
the time required for the 100% solution, I am happy to explain that the
instances get copied.

Ralf


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




From david.abrahams at rcn.com  Thu May 30 23:27:15 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 17:27:15 -0400
Subject: [C++-sig] constructor wrappers?
References: <20020530210052.23741.qmail@web20204.mail.yahoo.com>
Message-ID: <02e201c20820$ec981240$6601a8c0@boostconsulting.com>

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


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > I understand that your solution works for your problems.
>
> How about giving me some credit for being a heavy user of Boost.Python?
> Don't you think that many of my experiences are representative?

Yes I do.

> > I think of the derived class wrapper approach as a kludgy workaround,
> > not a solution. I'm in favor of a lighter-weight alternative, but I
> > also want it to be efficient and flexible. In library design you often
> > have to be careful to get the interface right the first time, because
> > you're stuck with the results essentially forevermore.
>
> Yes. But if you had taken that philosophy too far would there be
Boost.Python
> V1?

I was doing the best I knew how with efficiency and flexibility at the
time.

> (with the returned reference problem, the friend function hack, and the
> incomplete cross-module support.) It still is a great, ground-breaking
library.

Well, thanks, I think ;-)

> > Of course you would, but then you won't have to explain to other users
> > why lightweight constructor wrappers cause them to make a copy of the
> > std::vector<> they are wrapping ;-)
>
> This is going in the wrong direction. Now let me be on the other side of
the
> fence (striving for ideal solutions): The combination of std::vector and
> Boost.Python is a major PITB. It was so painful that I wrote a fully
fledged
> reference counted array type. This clearly is the right solution.

Why is that clearly the right solution? Why should other users have to go
to all that effort? Personally, I don't think that it should be neccessary.

> Under the assumption that the proposed 70% solution can be achieved in
20% of
> the time required for the 100% solution, I am happy to explain that the
> instances get copied.

Why assume? Have you invested anything in thinking about what an efficient
and flexible solution would look like? I haven't.

To move this in a "constructive" (pun intended) direction, here's one
possibility. Suppose def_init() would accept any function returning a
boost::tuple of constructor arguments. The possible python argument
conversions would be determined by the function's signature, and the
elements of the resulting tuple would be used to construct the class. That
way, if you have a lightweight class like any you can freely return
tuple<any> from your function.

We could extend this so that if the function didn't return a tuple, the
return value would be used as a constructor argument directly, which would
get you exactly the interface you're asking for. I'm not sure if that's
worth it, but it might be.

Another question raised by this idea is whether (and how) it should be
applied to regular function wrapping. Carrying it a bit further could give
us a way to make thin wrappers unneccessary by using Boost.Lamda.

-Dave






From ssmith at magnet.fsu.edu  Fri May 31 00:08:02 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 30 May 2002 18:08:02 -0400
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <20020530202401.21644.qmail@web20206.mail.yahoo.com>
Message-ID: <NFBBINAMBILHLOCDJKAEOEBBCCAA.ssmith@magnet.fsu.edu>

Dave and Ralf,

> Are you trying to build a V1 libbpl.so? IMO it is not worth investing time
in
> this. You should definitely try the V2 build. For that you have to use the
> Jamfile in libs/python (not libs/python/build) to get a start, then try
the Mac
> specific options.

> That really depends on how much V1-dependent code he's already written.

Last summer we wrote a lot of stuff that was exported using Boost 1.21.0
and Python 2.1. It used MSVC++ and only worked on Windows. I am now thinking
about porting my entire project and joined this list to see what was going
on.
I then set about compiling what I had with the latest Boost release (1.28.0)
and that did not work in the MSVC++ IDE (at least the Boost part). Going
retro,
things worked fine with version 1.25.0 and old Python. So, I then tried
compiling 1.28.0 with
Jam on the platforms close at hand to see how that would fly (PC/MSVC++,
PC/Cygwin,
and Mac OS X) with Python 2.2.x.  Now I have at least been able to generate
Boost.Python libraries on all three, but cluttered up this list in doing so.

My goal is to use this terrific package and Python 2.2.x to get my stuff
running multi-platform. If that demands Boost 2.0 then I'll consider
altering
the port of my code and messing with the builds of that. But first I am just
trying to see if it is feasible to do this at all, or accept the original
premise of my co-workers who (last summer) claimed it would only work with
MSVC++/Windows. I figure you guys have no problems running on different
systems?

At present, I am taking a break from building Boost in order to see if
what I have built can be used.  Once I have any success I will return
to looking at OS X. But currently my stuff will not link propery (in MSVC++)
to the Boost.Python dll I built, so I cannot make a working dll of it yet.
Worse, I have not yet been able to get the libs/python/example to work
using jam and the Boost.Python libraries I built earlier, either they
are all bad or, more likely, I am a little too clueless to get it to
work. Are there any explicit instructions anywhere on how to run the
example(s)? I just invoke bjam in the same manner as when I built
Boost.Python and presto, a dll is built. That seems fine, but then
Python will not import it?

Best regards,
Scott

P.S. I am carefully writting down everything I do so that anyone will be
     able to reproduce it. That should make for a good set of instructions
     on how to start from ground zero. You are of course welcome to any of
it.


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

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu





From david.abrahams at rcn.com  Fri May 31 01:17:43 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 19:17:43 -0400
Subject: [C++-sig] Re: [jamboost] Re: 1_28_0 python2.2.1 gcc3.0.4 build on sparc-solaris-2.7 problem report
References: <ad60ik$i9s$1@main.gmane.org> <02ff01c20825$aa9440d0$6601a8c0@boostconsulting.com> <ad6add$82u$1@main.gmane.org>
Message-ID: <033e01c20833$5b7d7c60$6601a8c0@boostconsulting.com>

Moving this to the C++-sig, where it belongs...

----- Original Message -----
From: "Mike Rovner" <gclbb-jamboost at m.gmane.org>


>
> "David Abrahams" wrote...
> > Sounds like you're right. What's the proposed fix?
>
> Modify boost[.python] to use 64-bit file operations [in that case].

Boost.Python doesn't use any file operations.

> I.e. include wrap_python.hpp first, huh?

"huh", Huh?

Which file should #include wrap_python first?

> Or exclude <cstddef> from config.hpp - I see no use of it in that file.

It's needed for offsetof()... though it appears BOOST_OFFSETOF is not used
anywhere anymore, so we could just dispense with that.

What happens if you comment out the #include <cstddef> from config.hpp?

-Dave







From rwgk at yahoo.com  Fri May 31 02:31:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 17:31:48 -0700 (PDT)
Subject: [C++-sig] constructor wrappers?
In-Reply-To: <02e201c20820$ec981240$6601a8c0@boostconsulting.com>
Message-ID: <20020531003148.79179.qmail@web20201.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > This is going in the wrong direction. Now let me be on the other side of
> the
> > fence (striving for ideal solutions): The combination of std::vector and
> > Boost.Python is a major PITB. It was so painful that I wrote a fully
> fledged
> > reference counted array type. This clearly is the right solution.
> 
> Why is that clearly the right solution? Why should other users have to go
> to all that effort? Personally, I don't think that it should be neccessary.

What I mean is that people should be using a reference counted array type, not
write one. In other words, I believe that a reference counted array type is a
critical missing part in the standard library. But this is for a different
thread.
 
> To move this in a "constructive" (pun intended) direction, here's one
> possibility. Suppose def_init() would accept any function returning a
> boost::tuple of constructor arguments. The possible python argument
> conversions would be determined by the function's signature, and the
> elements of the resulting tuple would be used to construct the class.

This sounds interesting. (Classical approach: introduce an extra level of
indirection.)

> That
> way, if you have a lightweight class like any you can freely return
> tuple<any> from your function.

You lost me here. "My function" is the wrapper? Why would I want to return a
tuple<any>? -- Oh, just so I have a tuple<>? Eventually the copy constructor is
used?

Is boost::tuple available on all your target platforms?
Same question for boost::lambda.

> We could extend this so that if the function didn't return a tuple, the
> return value would be used as a constructor argument directly, which would
> get you exactly the interface you're asking for. I'm not sure if that's
> worth it, but it might be.

I don't think this shortcut is necessary.

> Another question raised by this idea is whether (and how) it should be
> applied to regular function wrapping. Carrying it a bit further could give
> us a way to make thin wrappers unneccessary by using Boost.Lamda.

I'd prefer a step-by-step approach.

I am wondering about the new member functions for class_. Do we need

  template <typename A1>
  def_init(boost::tuple<A1>);
  template <typename A1, typename A2>
  def_init(boost::tuple<A1, A2>);
  template <typename A1, typename A2, typename A3>
  def_init(boost::tuple<A1, A2, A3>);

etc. Is this a job for the preprocessor library?

Then what next? Do we have to build a bridge from boost::tuple<A1,...>
to boost::python::args<A1,...>, or copy-and-paste the processing
of args<> and then customize the code for dealing with boost::tuple<>?

Ralf


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




From rwgk at yahoo.com  Fri May 31 02:45:18 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 17:45:18 -0700 (PDT)
Subject: [C++-sig] Link trouble on OS X
In-Reply-To: <NFBBINAMBILHLOCDJKAEOEBBCCAA.ssmith@magnet.fsu.edu>
Message-ID: <20020531004518.307.qmail@web20203.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> My goal is to use this terrific package and Python 2.2.x to get my stuff
> running multi-platform.

That you could do with the old Boost.Python (V1 = version 1 or generation 1).
We are using Linux gcc, SunOS gcc, Tru64 cxx, Win32 Codewarrior, VC++6,
VC++7, MIPSpro C++ (SGI). However, I failed with Mac OS X c++ because of a
template instantiation problem mentioned before (I believe it is a linker or
compiler bug).

> At present, I am taking a break from building Boost in order to see if
> what I have built can be used.  Once I have any success I will return
> to looking at OS X.

I was hoping that you would bring the proof that V2 works under Mac OS X :-)
At the moment I only know that it should work in principle (a minimal test
modelling the Boost.Python V2 architecture works).

Ralf


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




From david.abrahams at rcn.com  Fri May 31 04:50:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 30 May 2002 22:50:17 -0400
Subject: [C++-sig] constructor wrappers?
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com>
Message-ID: <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com>

> What I mean is that people should be using a reference counted array
> type, not write one. In other words, I believe that a reference
> counted array type is a critical missing part in the standard
> library. But this is for a different thread.

OK. You said earlier that using std::vector with Boost.Python was a
major "PITB" (which I assume is bad), so I just want to re-emphasize
that I really hope that won't be the case with v2.

> > To move this in a "constructive" (pun intended) direction, here's
> > one possibility. Suppose def_init() would accept any function
> > returning a boost::tuple of constructor arguments. The possible
> > python argument conversions would be determined by the function's
> > signature, and the elements of the resulting tuple would be used to
> > construct the class.
> 
> This sounds interesting. (Classical approach: introduce an extra level
> of indirection.)

> > That way, if you have a lightweight class like any you can freely
> > return tuple<any> from your function.
> 
> You lost me here. "My function" is the wrapper? 

Your function is the "constructor argument preprocessor".

> Why would I want to
> return a tuple<any>? -- Oh, just so I have a tuple<>? 

Yes.

> Eventually the copy constructor is used?

The elements of the tuple would be distributed to the constructor of
the underlying class, so the constructor which accepts an any argument
would be used.

> Is boost::tuple available on all your target platforms?  

Yes.

> Same question for boost::lambda.

No (but so what?)

> > We could extend this so that if the function didn't return a tuple,
> > the return value would be used as a constructor argument directly,
> > which would get you exactly the interface you're asking for. I'm not
> > sure if that's worth it, but it might be.
> 
> I don't think this shortcut is necessary.

Good.

> > Another question raised by this idea is whether (and how) it should
> > be applied to regular function wrapping. Carrying it a bit further
> > could give us a way to make thin wrappers unneccessary by using
> > Boost.Lamda.
> 
> I'd prefer a step-by-step approach.

Cop out <0.01 wink>

> I am wondering about the new member functions for class_. Do we need
> 
>   template <typename A1>
>   def_init(boost::tuple<A1>);
>   template <typename A1, typename A2>
>   def_init(boost::tuple<A1, A2>);
>   template <typename A1, typename A2, typename A3>
>   def_init(boost::tuple<A1, A2, A3>);
> 
> etc. Is this a job for the preprocessor library?

No; think about it a bit and you'll see that it can't work that
way. tuple<> takes default arguments.

> Then what next? Do we have to build a bridge from boost::tuple<A1,...>
> to boost::python::args<A1,...>, or copy-and-paste the processing
> of args<> and then customize the code for dealing with boost::tuple<>?

I don't think I'm ready to figure out the entire implementation in
this email ;-)






From rwgk at yahoo.com  Fri May 31 08:23:43 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 May 2002 23:23:43 -0700 (PDT)
Subject: [C++-sig] constructor wrappers?
In-Reply-To: <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com>
Message-ID: <20020531062343.45066.qmail@web20210.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > Then what next? Do we have to build a bridge from boost::tuple<A1,...>
> > to boost::python::args<A1,...>, or copy-and-paste the processing
> > of args<> and then customize the code for dealing with boost::tuple<>?
> 
> I don't think I'm ready to figure out the entire implementation in
> this email ;-)

Oh, too bad. I thought I could start using the new feature before the
weekend :-)

Here is another idea:

  boost::python::module("any")

    .def("hello", custom_hello_factory)
    
    .add(boost::python::class_<hello>("hello")
      .def_init(boost::python::args<>())
      .def("foo", foo)
      )
  ;

This compiles and I can still instantiate any.hello(), but the
custom_hello_factory is not accessible ("TypeError: bad argument type
for built-in operation"). As I understand, you have overload resolution
for

  - module level functions
  - constructors for a given class name
  - member functions of a given class

Would it be possible to put module level functions and constructors into
one pool? The functions and constructors could be tried in the order in
which they are def'ed or add'ed. If that cannot easily be done, try the
module level functions first, then the regular constructors.
What do you think about this?
Ralf


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




From david.abrahams at rcn.com  Fri May 31 08:33:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 02:33:49 -0400
Subject: [C++-sig] constructor wrappers?
References: <20020531062343.45066.qmail@web20210.mail.yahoo.com>
Message-ID: <045001c2086d$b91edbe0$6601a8c0@boostconsulting.com>

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

> Would it be possible to put module level functions and constructors into
> one pool? The functions and constructors could be tried in the order in
> which they are def'ed or add'ed. If that cannot easily be done, try the
> module level functions first, then the regular constructors.
> What do you think about this?

Not doable for various reasons too complicated to mention. Plus, it doesn't
solve any of the copying issues I brought up earlier.





From ssmith at magnet.fsu.edu  Fri May 31 15:44:15 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Fri, 31 May 2002 09:44:15 -0400
Subject: [C++-sig] Problems Getting Started in Boost.Python
In-Reply-To: <033e01c20833$5b7d7c60$6601a8c0@boostconsulting.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLCEBGCAAA.ssmith@magnet.fsu.edu>

Hello,

I obtained the latest Boost from CVS and gave it a go.
The build of Boost.Python worked just fine on my PC
using both CygWin/GCC and MSVC++. Wow! At least I can
handle that much now. Now I am trying to follow along
what is written in libs\python\doc\example1.html, but
having some problems that one of you can probably rectify
quite easily.

In the directory libs\python\example I again ran (b)jam
and this produced a bin directory that, in the MSVC++ case,
contained in a buried sub-directory many getting_started1
files. Among them are an NT command script, an exp file,
a lib file, and a pyd file (no dll file though). In the
Cygwin case another subdirectory in bin is produced and
it contains only getting_started1.dll, getting_started1.lib,
and getting+started1.obj.

Now to use what I've built in Python.

In the Cygwin case I moved the dll and lib file into libs\python\example and
in that same directory started Python (from Cygwin). Here
is what happens next:

$ python
Python 2.2 (#1, Dec 31 2001, 15:21:18)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import getting_started1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dlopen: Win32 error 126
>>>

Apparently it sees the dll just fine but either there is something wrong
with it
or I need to import something more?

In the MSVC++ case, I copied everything I thought might actually be read
by Python (there was no dll produced, maybe the pyd file is what is used?)
into my Python/DLLs directory. Upon running Python (Windows) this happens:

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import getting_started1
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    import getting_started1
ImportError: DLL load failed: The specified module could not be found.
>>>

Well, that build did not produce a dll so it either failed or Python is
needing something else in this case.

Can someone please explain what form of stupidity I am plagued with now?
Should all of this be working?

Thanks,
Scott







From achim.domma at syynx.de  Fri May 31 16:16:51 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Fri, 31 May 2002 16:16:51 +0200
Subject: [C++-sig] Problems Getting Started in Boost.Python
In-Reply-To: <PCEJJPDHEECNEKDDLPNLCEBGCAAA.ssmith@magnet.fsu.edu>
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEEIDGAA.achim.domma@syynx.de>

Hi,

I don't know gcc for windows, but will try to help with VC++:

> In the MSVC++ case, I copied everything I thought might actually be read
> by Python (there was no dll produced, maybe the pyd file is what is used?)
> into my Python/DLLs directory. Upon running Python (Windows) this happens:
>
> Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> IDLE 0.8 -- press F1 for help
> >>> import getting_started1
> Traceback (most recent call last):
>   File "<pyshell#0>", line 1, in ?
>     import getting_started1
> ImportError: DLL load failed: The specified module could not be found.
> >>>
>
> Well, that build did not produce a dll so it either failed or Python is
> needing something else in this case.
>
> Can someone please explain what form of stupidity I am plagued with now?
> Should all of this be working?

the .pyd is the right file. There are two versions of boost.python, which
one are you using? If you are using boost.python V2 you also need bpl.dll.
You should copy this file also to your Dll folder. But to be sure, I would
copy the dlls to the folder where your script is.

Achim






From david.abrahams at rcn.com  Fri May 31 16:10:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 10:10:20 -0400
Subject: [C++-sig] Problems Getting Started in Boost.Python
References: <PCEJJPDHEECNEKDDLPNLCEBGCAAA.ssmith@magnet.fsu.edu>
Message-ID: <051c01c208ad$21ff9e80$6601a8c0@boostconsulting.com>

> Can someone please explain what form of stupidity I am plagued with now?

Your first mistake was right here:

> In the Cygwin case I moved the dll and lib file into libs\python\example
and
> in that same directory started Python (from Cygwin).

Bad idea. Everything was set up perfectly already. Running "bjam test"
would have run the test case. If you want to see what it does, run
    "bjam -d+2 test"

> Apparently it sees the dll just fine

Why do you think so? It's finding the extension module but missing bpl.dll

> but either there is something wrong
> with it or I need to import something more?
>
> In the MSVC++ case, I copied everything

Same problem here.

-Dave






From david.abrahams at rcn.com  Fri May 31 16:18:49 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 10:18:49 -0400
Subject: [C++-sig] Problems Getting Started in Boost.Python
References: <PCEJJPDHEECNEKDDLPNLCEBGCAAA.ssmith@magnet.fsu.edu> <051c01c208ad$21ff9e80$6601a8c0@boostconsulting.com>
Message-ID: <052501c208ae$1652c4d0$6601a8c0@boostconsulting.com>

From: "David Abrahams" <david.abrahams at rcn.com>
>
> Why do you think so? It's finding the extension module but missing
bpl.dll

Uhh, sorry: you're using Boost.Python v1, so it's missing
libboost_python.dll

names-have-been-changed-to-protect-the-innocent-ly y'rs,
dave





From ssmith at magnet.fsu.edu  Fri May 31 16:45:49 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Fri, 31 May 2002 10:45:49 -0400
Subject: [C++-sig] Problems Getting Started in Boost.Python
In-Reply-To: <052501c208ae$1652c4d0$6601a8c0@boostconsulting.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLKEBGCAAA.ssmith@magnet.fsu.edu>

Thanks Dave and Achim,

> it's missing libboost_python.dll

This did the job, now example1 runs in with both
Cygwin & MSVC based versions. I thought that by
downloading from CVS I would be working with V2 but
I see from an earlier post from Dave to Achim how to
move to V2 as well as how to run the tests.

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

Thanks again, this will allow me to look at a lot of things now.
I think that libs\python\doc\example1.html could benefit from
a couple of sentences containing what you just wrote me and I don't
find any dox about running the tests? If it is just me being that
dense, let me down easy.

Thanks again,
Scott




From rwgk at yahoo.com  Fri May 31 17:11:01 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 31 May 2002 08:11:01 -0700 (PDT)
Subject: [C++-sig] Problems Getting Started in Boost.Python
In-Reply-To: <PCEJJPDHEECNEKDDLPNLCEBGCAAA.ssmith@magnet.fsu.edu>
Message-ID: <20020531151101.48610.qmail@web20207.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> Can someone please explain what form of stupidity I am plagued with now?
> Should all of this be working?

The stupidity is not on your part.
Currently you get both V1 and V2 if you checkout cvs.
If you run bjam in the build or example directory, you are using V1.
If you run bjam in libs/python or libs/python/test, your are using V2.
Obvious?
David, a few lines of comment at the top of each Jam file would be
incredibly helpful.

The other unobvious step is that you have to also checkout the mbl
development branch. cd into your local boost cvs copy, then:
 
cvs update -APd
cvs update -Pd -rmpl-development boost/mpl

Then you have to build/get bjam somehow. Apparently you did this already.
Just in case, I cd to tools/build/jam_src, entered make and copied the
bjam that it puts in bin or bin-linux or some directory like that.

Here is what I used on Linux in libs/python/test to finally compile V2:

bjam -sBOOST_ROOT=/net/cci/rwgk/boost -sPYTHON_ROOT=/usr/local_cci/Python-2.2.1
-sTOOLS=gcc -sPYTHON_VERSION=2.2

The getting_started1 etc. examples in the "example" directory are all
for V2. Unfortunately I find the tests/examples in V2 not very helpful
to the end user. I am planning to "port" the old examples to V2 in the
next couple of weeks.

I am holding my breath to see what happens on Mac OS X. I'd run the bjam
command with the -d2 (or was it -d+2?) option under Linux or Cygwin or
whatever you have where it works out of the box, then emulate the
compile and link commands under Mac OS X. (I could give you a Makefile
that you could use as a start, modify, enter make, until you figure
out the magic combination of options that works.)

Ralf




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




From david.abrahams at rcn.com  Fri May 31 17:12:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 11:12:14 -0400
Subject: [C++-sig] Problems Getting Started in Boost.Python
References: <20020531151101.48610.qmail@web20207.mail.yahoo.com>
Message-ID: <057901c208b5$cd7b2e20$6601a8c0@boostconsulting.com>

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

> If you run bjam in the build or example directory, you are using V1.
> If you run bjam in libs/python or libs/python/test, your are using V2.


> Obvious?
> David, a few lines of comment at the top of each Jam file would be
> incredibly helpful.

Sure, but he's not having that problem. Why are you confusing matters by
talking about v2?

-Dave





From rwgk at yahoo.com  Fri May 31 18:42:56 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 31 May 2002 09:42:56 -0700 (PDT)
Subject: [C++-sig] Problems Getting Started in Boost.Python
In-Reply-To: <057901c208b5$cd7b2e20$6601a8c0@boostconsulting.com>
Message-ID: <20020531164256.41380.qmail@web20210.mail.yahoo.com>

--- David Abrahams <david.abrahams at rcn.com> wrote:
> 
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > If you run bjam in the build or example directory, you are using V1.
> > If you run bjam in libs/python or libs/python/test, your are using V2.
> 
> 
> > Obvious?
> > David, a few lines of comment at the top of each Jam file would be
> > incredibly helpful.
> 
> Sure, but he's not having that problem. Why are you confusing matters by
> talking about v2?

Because he is trying to use V2. That's why he got the cvs snapshot.
Since you will be retiring V1 in a few days, why should he try to
port that to Mac OS X? My tests from a few months ago suggest that
it will not work anyway.
Ralf


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




From rwgk at yahoo.com  Fri May 31 20:43:52 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 31 May 2002 11:43:52 -0700 (PDT)
Subject: [C++-sig] custom from_python
Message-ID: <20020531184352.46836.qmail@web20201.mail.yahoo.com>

I am really impressed by the nice mechanism for registering a custom
to_python conversion.
What is the best way to define and register an equivalent custom
from_python converter?
I am looking at the code in src/converter/from_python.cpp.
Most built-in types seem to go through slot_rvalue_from_python.
Should I use this, too?
Thanks,
        Ralf


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




From pearu at cens.ioc.ee  Fri May 31 21:21:17 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 31 May 2002 22:21:17 +0300 (EEST)
Subject: [C++-sig] V2: isinstance(obj,cls) equivalent
Message-ID: <Pine.LNX.4.21.0205312215340.22824-100000@cens.ioc.ee>

Hi,

What would be the best way to determine if

  PyObject *obj

is an instance of a Boost.Python V2 wrapped class, say A?

Hints where to look are most appreciated.

Thanks,
	Pearu





From okuda1 at llnl.gov  Fri May 31 21:33:17 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Fri, 31 May 2002 12:33:17 -0700
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com>
Message-ID: <3CF7CFFD.F2297EEF@llnl.gov>

I would like to know how to set correct return policy? It took me quite
a while to narrow down to where the problem was. So, my question is:

How do I determine which return policy should I be using???

In the example of test/test_pointer_adoption.cpp, it uses
return_internal_reference as in:

.def("get_inner", &A::get_inner, return_internal_reference<>())

and

struct A {
<snip>
    inner& get_inner() {return x;}
    inner x;
};

Initially I used return_internal_reference because of the above example
and if you replace inner with string in struct A, it made sense to me to
use return_internal_reference...
Here are codes that must use a specific return policy with my
comments...

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

class Tag {
public:
   Tag():mName("") {}
   Tag(const std::string& name):mName(name) {}
   ~Tag() {}
   const std::string& name() const {return mName;}
private:
   std::string mName;
};

BOOST_PYTHON_MODULE_INIT(Test2)
{
   using namespace boost::python;
   module TagMod("Test2");
   TagMod
      .add(
           class_<Tag> ("Tag")
           .def_init()
           .def_init(args<const std::string&>())
           // this line causes compiling errors
           //.def("show", &Tag::name)
           // return_internal_reference compiles, t=Tag("hello") creates
           // instances, but t.show() cause TypeError.
           //.def("show", &Tag::name, return_internal_reference<>())
           // this one works alright...
           .def("show", &Tag::name,
return_value_policy<copy_non_const_reference>())
           )
      ;
}




From rwgk at yahoo.com  Fri May 31 21:37:02 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 31 May 2002 12:37:02 -0700 (PDT)
Subject: [C++-sig] custom from_python
In-Reply-To: <20020531184352.46836.qmail@web20201.mail.yahoo.com>
Message-ID: <20020531193702.75918.qmail@web20203.mail.yahoo.com>

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> I am really impressed by the nice mechanism for registering a custom
> to_python conversion.
> What is the best way to define and register an equivalent custom
> from_python converter?
> I am looking at the code in src/converter/from_python.cpp.
                                            ^^^^^^^^^^^^^^^
                                  I mean    builtin_converters.cpp
> Most built-in types seem to go through slot_rvalue_from_python.
> Should I use this, too?
> Thanks,
>         Ralf


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




From david.abrahams at rcn.com  Fri May 31 21:58:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 15:58:30 -0400
Subject: [C++-sig] custom from_python
References: <20020531184352.46836.qmail@web20201.mail.yahoo.com>
Message-ID: <063e01c208dd$a63fd130$6601a8c0@boostconsulting.com>

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


> I am really impressed by the nice mechanism for registering a custom
> to_python conversion.
> What is the best way to define and register an equivalent custom
> from_python converter?

Have you looked at lvalue_from_pytype? The documentation is quite complete.

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

> I am looking at the code in src/converter/from_python.cpp.
> Most built-in types seem to go through slot_rvalue_from_python.
> Should I use this, too?

So far that's an implementation detail of the library; it's doing a very
specific job which involves looking at a slot in the Python type to see if
a conversion function is supported... so, probably not, unless it's an
exact fit. In that case, it need to be documented and moved to a
publicly-accessible place.

-Dave







From david.abrahams at rcn.com  Fri May 31 22:00:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 16:00:38 -0400
Subject: [C++-sig] V2: isinstance(obj,cls) equivalent
References: <Pine.LNX.4.21.0205312215340.22824-100000@cens.ioc.ee>
Message-ID: <064401c208de$598908b0$6601a8c0@boostconsulting.com>

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


>
> Hi,
>
> What would be the best way to determine if
>
>   PyObject *obj
>
> is an instance of a Boost.Python V2 wrapped class, say A?

The library does it by checking its metaclass. That is, does

    obj->ob_type->ob_type == boost::python::objects::class_metatype().get()

-Dave





From david.abrahams at rcn.com  Fri May 31 22:12:05 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 16:12:05 -0400
Subject: [C++-sig] How To Determine Return Policy???
References: <20020531003148.79179.qmail@web20201.mail.yahoo.com> <03a201c2084e$74237fb0$6601a8c0@boostconsulting.com> <3CF7CFFD.F2297EEF@llnl.gov>
Message-ID: <065101c208df$c04805f0$6601a8c0@boostconsulting.com>

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


> I would like to know how to set correct return policy? It took me quite
> a while to narrow down to where the problem was. So, my question is:
>
> How do I determine which return policy should I be using???

I realize that this one's a little subtle. You can't return an internal
reference to std::string because you haven't wrapped it using class_<>.

return_internal_reference defines its result_converter to be
to_python_indirect, which as you can see from the documentation is making
Boost.Python extension class instances containing an embedded pointer to
the actual C++ object, thereby avoiding making a copy.

Since you haven't created class_<std::string, ...>, the library fails to
find any way to create an extension class instance corresponding to
std::string. By-value conversions for std::string work because they've
already been registered by the library's initialization code. These
converters translate std::string <-> Python strings by copying the string
contents, so there's no Python class lying around which corresponds to
std::string.

I would recommend *against* trying to wrap std::string with class_<>. The
builtin conversions to and from Python strings are probably exactly what
you want.

HTH,
Dave


> In the example of test/test_pointer_adoption.cpp, it uses
> return_internal_reference as in:
>
> .def("get_inner", &A::get_inner, return_internal_reference<>())
>
> and
>
> struct A {
> <snip>
>     inner& get_inner() {return x;}
>     inner x;
> };
>
> Initially I used return_internal_reference because of the above example
> and if you replace inner with string in struct A, it made sense to me to
> use return_internal_reference...
> Here are codes that must use a specific return policy with my
> comments...
>
> ------------ source code ------------------
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/return_internal_reference.hpp>
> #include <boost/python/copy_non_const_reference.hpp>
> #include <boost/python/return_value_policy.hpp>
>
> class Tag {
> public:
>    Tag():mName("") {}
>    Tag(const std::string& name):mName(name) {}
>    ~Tag() {}
>    const std::string& name() const {return mName;}
> private:
>    std::string mName;
> };
>
> BOOST_PYTHON_MODULE_INIT(Test2)
> {
>    using namespace boost::python;
>    module TagMod("Test2");
>    TagMod
>       .add(
>            class_<Tag> ("Tag")
>            .def_init()
>            .def_init(args<const std::string&>())
>            // this line causes compiling errors
>            //.def("show", &Tag::name)
>            // return_internal_reference compiles, t=Tag("hello") creates
>            // instances, but t.show() cause TypeError.
>            //.def("show", &Tag::name, return_internal_reference<>())
>            // this one works alright...
>            .def("show", &Tag::name,
> return_value_policy<copy_non_const_reference>())
>            )
>       ;
> }
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From pearu at cens.ioc.ee  Fri May 31 22:23:51 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 31 May 2002 23:23:51 +0300 (EEST)
Subject: [C++-sig] V2: isinstance(obj,cls) equivalent
In-Reply-To: <064401c208de$598908b0$6601a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0205312316440.22824-100000@cens.ioc.ee>

On Fri, 31 May 2002, David Abrahams wrote:

> 
> From: "Pearu Peterson" <pearu at cens.ioc.ee>
> 
> > What would be the best way to determine if
> >
> >   PyObject *obj
> >
> > is an instance of a Boost.Python V2 wrapped class, say A?
> 
> The library does it by checking its metaclass. That is, does
> 
>     obj->ob_type->ob_type == boost::python::objects::class_metatype().get()

Thanks, though I don't understand how the above needs not to depend on the
class, A, but since I also need to extract the corresponding instance from
obj, I use from_python facility:

const A pyobj_to_A(PyObject* obj) {
  boost::python::from_python<const A &> c(obj);
  if (c.convertible()) return c(obj);
  ...
}

Pearu





From david.abrahams at rcn.com  Fri May 31 23:16:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 31 May 2002 17:16:39 -0400
Subject: [C++-sig] V2: isinstance(obj,cls) equivalent
References: <Pine.LNX.4.21.0205312316440.22824-100000@cens.ioc.ee>
Message-ID: <068101c208e8$a9f7a810$6601a8c0@boostconsulting.com>

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

>
> Thanks, though I don't understand how the above needs not to depend on
the
> class, A,

It does, in a way. obj->ob_type is the class. All extension classes are
instances of a common metaclass.

Oh, you want to find out if the object is an instance of a /particular/
wrapped class!

> but since I also need to extract the corresponding instance from
> obj, I use from_python facility:
>
> const A pyobj_to_A(PyObject* obj) {
>   boost::python::from_python<const A &> c(obj);
>   if (c.convertible()) return c(obj);
>   ...
> }

That's probably not quite right. Since rvalues bind to const references,
all that proves is that there is a way to convert obj to an object of type
A. For example, there might be an implicit conversion from B->A.

However, if you use from_python<A const*>, you're guaranteed that obj
contains an actual A instance if convertible() succeeds.

-Dave