From achim.domma at syynx.de  Sat Feb  1 19:01:55 2003
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 1 Feb 2003 19:01:55 +0100
Subject: [C++-sig] Docstring for overloaded method
Message-ID: <FCEMIEFBFOIDAOJDEPIAEECDEJAA.achim.domma@syynx.de>

Hi,

I have something like

class_<MyClass>("MyClass")
    .def("myFkt", (overloaded1)&MyClass::myFkt)
    .def("myFkt", (overloaded2)&MyClass::myFkt)
    ....;

where overloaded1 and overloaded2 are the different signatures for the
overloads. Now I want to specify a docstring for myFkt. Where should I do
that? On the first version, on the last or on both?

regards,
Achim





From dave at boost-consulting.com  Sat Feb  1 19:04:23 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 01 Feb 2003 13:04:23 -0500
Subject: [C++-sig] Docstring for overloaded method
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAEECDEJAA.achim.domma@syynx.de> ("Achim
 Domma"'s message of "Sat, 1 Feb 2003 19:01:55 +0100")
References: <FCEMIEFBFOIDAOJDEPIAEECDEJAA.achim.domma@syynx.de>
Message-ID: <uwukjnahk.fsf@boost-consulting.com>

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

> Hi,
>
> I have something like
>
> class_<MyClass>("MyClass")
>     .def("myFkt", (overloaded1)&MyClass::myFkt)
>     .def("myFkt", (overloaded2)&MyClass::myFkt)
>     ....;
>
> where overloaded1 and overloaded2 are the different signatures for the
> overloads. Now I want to specify a docstring for myFkt. Where should I do
> that? On the first version, on the last or on both?

Take your pick ;-)

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From dave at boost-consulting.com  Sun Feb  2 04:54:38 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 01 Feb 2003 22:54:38 -0500
Subject: [C++-sig] Re: python keyword arguments ?
In-Reply-To: <000801c2ca63$228c0550$ccbc3e3e@knar> ("Alex le grand"'s
 message of "Sun, 2 Feb 2003 03:31:02 +0100")
References: <000801c2ca63$228c0550$ccbc3e3e@knar>
Message-ID: <ur8ar9w1t.fsf@boost-consulting.com>

Alex,

Please in the future post your Boost.Python questions to the C++-sig:
http://mail.python.org/mailman/listinfo/c++-sig

"Alex le grand" <alex at glumol.com> writes:

> hi I saw on the index page of the boost.python
> documentation that version V2 now has support for the
> python "keyword arguments" but I can't find any
> documentation about it.  Is there any documentation or
> examples about wrapping the python keyword arguments
> function into C++ ?

The information you need is in the reference documentation for def().
Please see:

http://www.boost.org/libs/python/doc/v2/def.html#def-spec

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From nickm at sitius.com  Sat Feb  1 05:05:26 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 31 Jan 2003 23:05:26 -0500
Subject: [C++-sig] RE: Boost.Python v2: Keywords
Message-ID: <3E3B4786.B659380B@sitius.com>

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

From dave at boost-consulting.com  Sun Feb  2 11:58:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 02 Feb 2003 05:58:49 -0500
Subject: [C++-sig] RE: Boost.Python v2: Keywords
In-Reply-To: <3E3B4786.B659380B@sitius.com> (Nikolay Mladenov's message of
 "Fri, 31 Jan 2003 23:05:26 -0500")
References: <3E3B4786.B659380B@sitius.com>
Message-ID: <uwukj6j9y.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> Hi,
>
> I want to use keywords but I found that their behavior is not exactly what I need.
> So I searched the mailing list and found this old post of David Abrahams:
>
> http://aspn.activestate.com/ASPN/Mail/Message/1375620
>
> And I am interested in this:
>> We can allow you to specify any initial section of the total argument set
>> in any order, but how useful is that?
>>
>> So, I plan to allow this instead:
>>
>>?? def("f", &f, (arg("a") = 1, arg("b") = 2, arg("c") = 3, ...)); // ***
>
> or something like it. (when I was trying myself trough the source of
> BPL I was thinking that args() should take as arguments pairs of
> char * and python::object ?)

Not quite.

> So my question is: is something like that coming any soon?

At this point, I guess the answer is: probably not immediately, unless
someone else implements it.  I'll be happy to "hold your hand" (so to
speak) while you do it, though.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From nickm at sitius.com  Mon Feb  3 07:34:42 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Mon, 03 Feb 2003 01:34:42 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com> <uwukj6j9y.fsf@boost-consulting.com>
Message-ID: <3E3E0D82.C336C7AC@sitius.com>

Ok,

I'll tell you what I did so far:

1. added constructor keyword::keyword(char const *) and changed the arguments of args to
detail::keyword.
  My idea here is to allow args to construct keywords holding values while preserving
the name only option as well.
2. typedefed detail::keyword to arg and defined 2 assignment operators to keyword so now
it looks like that:

  struct keyword
  {
      char const* name;
      handle?> default_value;
      keyword(char const* n=0):name(n){}
      template ?class T>
          keyword ?operator = (T const ?value)
      {
          default_value = handle?>(object(value).ptr());
          return *this;
      }

      keyword ?operator = (keyword const ?k)
      {
          name = k.name;
          default_value = k.default_value;
          return *this;
      }
  };

Thus the expression arg("arg_name") = arg_value produces a keyword (does it have the
necessary life span?)
I left the "," overloading for later, I attempted an intervention in function::call.
I didn't have much success there, cause I have a lot of pieces missing in my
understending of the library.

Why did you use python api there instead of boost::python wrappers?
I have to figure out the python reference counting. They say it is explicit but seems
like some of the py api funcs do it for you.
I have to think about some overlapping that occurs now between the optional?>, and args.

I guess I'll have more questions tomorrow.

Regards,

Nikolay


David Abrahams wrote:

> Nikolay Mladenov ?nickm at sitius.com> writes:
>
> > Hi,
> >
> > I want to use keywords but I found that their behavior is not exactly what I need.
> > So I searched the mailing list and found this old post of David Abrahams:
> >
> > http://aspn.activestate.com/ASPN/Mail/Message/1375620
> >
> > And I am interested in this:
> >> We can allow you to specify any initial section of the total argument set
> >> in any order, but how useful is that?
> >>
> >> So, I plan to allow this instead:
> >>
> >>   def("f", ?f, (arg("a") = 1, arg("b") = 2, arg("c") = 3, ...)); // ***
> >
> > or something like it. (when I was trying myself trough the source of
> > BPL I was thinking that args() should take as arguments pairs of
> > char * and python::object ?)
>
> Not quite.
>
> > So my question is: is something like that coming any soon?
>
> At this point, I guess the answer is: probably not immediately, unless
> someone else implements it.  I'll be happy to "hold your hand" (so to
> speak) while you do it, though.
>
> --
>                        David Abrahams
>    dave at boost-consulting.com * http://www.boost-consulting.com
> Boost support, enhancements, training, and commercial distribution




From cyril_bonnard at hotmail.com  Mon Feb  3 15:03:33 2003
From: cyril_bonnard at hotmail.com (cyril bonnard)
Date: Mon, 03 Feb 2003 14:03:33 +0000
Subject: [C++-sig] (no subject)
Message-ID: <F168fq9kbzsSliPWU8f00006c58@hotmail.com>

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

From ssmith at magnet.fsu.edu  Mon Feb  3 15:02:27 2003
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Mon, 03 Feb 2003 09:02:27 -0500
Subject: [C++-sig] Boost.Python RPM
In-Reply-To: <20030129120104.6aae6cd6.bkoz@redhat.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLOEJFCAAA.ssmith@magnet.fsu.edu>

Bejamin,

> Scott, if you do this please let me know.

It appears someone has already done this. I have not yet
checked them, but it apears that all of Boost & Jam have
RPMs already built here:

http://www.starostik.de/malte/boost

Scott



From grafik666 at redshift-software.com  Mon Feb  3 16:43:10 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon,  3 Feb 2003 09:43:10 -0600
Subject: [C++-sig] Boost.Python RPM
In-Reply-To: <PCEJJPDHEECNEKDDLPNLOEJFCAAA.ssmith@magnet.fsu.edu>
Message-ID: <20030203094312-r01010800-e569e806-0860-0108@12.100.89.43>

[2003-02-03] Scott A. Smith wrote:

>Bejamin,
>
>> Scott, if you do this please let me know.
>
>It appears someone has already done this. I have not yet
>checked them, but it apears that all of Boost & Jam have
>RPMs already built here:
>
>http://www.starostik.de/malte/boost

I also just started putting up binaries/RPMs of Boost.Jam on the SourceForge
files distribution section.

http://sourceforge.net/project/showfiles.php?group_id=7586


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



From nickm at sitius.com  Mon Feb  3 21:25:27 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Mon, 03 Feb 2003 15:25:27 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com> <uwukj6j9y.fsf@boost-consulting.com>
Message-ID: <3E3ED037.6B8DC4ED@sitius.com>

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

From dave at boost-consulting.com  Mon Feb  3 21:33:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 03 Feb 2003 15:33:46 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
In-Reply-To: <3E3E0D82.C336C7AC@sitius.com> (Nikolay Mladenov's message of
 "Mon, 03 Feb 2003 01:34:42 -0500")
References: <3E3B4786.B659380B@sitius.com>
	<uwukj6j9y.fsf@boost-consulting.com> <3E3E0D82.C336C7AC@sitius.com>
Message-ID: <uu1flhzo5.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> Ok,
>
> I'll tell you what I did so far:
>
> 1. added constructor keyword::keyword(char const *) and changed the
> arguments of args to detail::keyword.

>   My idea here is to allow args to construct keywords holding values
> while preserving the name only option as well.

> 2. typedefed detail::keyword to arg and defined 2 assignment
> operators to keyword so now it looks like that:
>
>   struct keyword
>   {
>       char const* name;
>       handle?> default_value;
>       keyword(char const* n=0):name(n){}
>       template ?class T>
>           keyword ?operator = (T const ?value)
>       {
>           default_value = handle?>(object(value).ptr());
>           return *this;
>       }
>
>       keyword ?operator = (keyword const ?k)
>       {
>           name = k.name;
>           default_value = k.default_value;
>           return *this;
>       }
>   };

[Your mailer does something strange with '<' and '?'...]

Ah, brilliant!  The reason I said it wouldn't happen soon was that I'd
forgotten that all the groundwork was already laid, and how I'd do
it.  I think the above is almost exactly what I'd have done.  I think
I'd probably make the second assignment operator private, and not
define it, though.

> Thus the expression arg("arg_name") = arg_value produces a keyword
> (does it have the necessary life span?)

Yes it does.

> I left the "," overloading for later, I attempted an intervention in
> function::call.  I didn't have much success there, cause I have a
> lot of pieces missing in my understending of the library.

Ah. Obviously the default values need to be stored with the function
somehow.  Is that already provided for?

> Why did you use python api there instead of boost::python wrappers?

To be sure I was getting optimal efficiency, probably.  Also, the
wrappers have some implications for compilation dependencies when I
develop the library, and I don't want recompile all the time.

> I have to figure out the python reference counting. They say it is
> explicit but seems like some of the py api funcs do it for you.
>
> I have to think about some overlapping that occurs now between the
> optional?>, and args.

OK.

> I guess I'll have more questions tomorrow.

You've made a good start!

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From dave at boost-consulting.com  Mon Feb  3 21:34:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 03 Feb 2003 15:34:21 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
In-Reply-To: <3E3ED037.6B8DC4ED@sitius.com> (Nikolay Mladenov's message of
 "Mon, 03 Feb 2003 15:25:27 -0500")
References: <3E3B4786.B659380B@sitius.com>
	<uwukj6j9y.fsf@boost-consulting.com> <3E3ED037.6B8DC4ED@sitius.com>
Message-ID: <uptq9hzn6.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> I did that

Did what?

> but unfortunately I cannot dif the repository.
> Does anybody know somethong about that?

"cvs diff" doesn't work for you?

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From nickm at sitius.com  Mon Feb  3 21:54:47 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Mon, 03 Feb 2003 15:54:47 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com>
		<uwukj6j9y.fsf@boost-consulting.com> <3E3ED037.6B8DC4ED@sitius.com> <uptq9hzn6.fsf@boost-consulting.com>
Message-ID: <3E3ED717.1C43368A@sitius.com>

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

From dave at boost-consulting.com  Mon Feb  3 22:12:54 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 03 Feb 2003 16:12:54 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
In-Reply-To: <3E3ED717.1C43368A@sitius.com> (Nikolay Mladenov's message of
 "Mon, 03 Feb 2003 15:54:47 -0500")
References: <3E3B4786.B659380B@sitius.com>
	<uwukj6j9y.fsf@boost-consulting.com> <3E3ED037.6B8DC4ED@sitius.com>
	<uptq9hzn6.fsf@boost-consulting.com> <3E3ED717.1C43368A@sitius.com>
Message-ID: <u8ywxhxux.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> I wanna make a patch, but no, "cvs diff" does not work some how.
> I am getting:
> cvs server: Diffing .
> /#cvs.lock): No such file or directoryctory for `/cvsroot/boost/boost
>
> May be something wrong in my dir tree?

What happens if you supply the usual
"-d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost"?

You may need to login again.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From nickm at sitius.com  Mon Feb  3 22:38:39 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Mon, 03 Feb 2003 16:38:39 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com>
		<uwukj6j9y.fsf@boost-consulting.com> <3E3ED037.6B8DC4ED@sitius.com>
		<uptq9hzn6.fsf@boost-consulting.com> <3E3ED717.1C43368A@sitius.com> <u8ywxhxux.fsf@boost-consulting.com>
Message-ID: <3E3EE15F.36FEDF6A@sitius.com>

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

From dave at boost-consulting.com  Mon Feb  3 23:36:41 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 03 Feb 2003 17:36:41 -0500
Subject: [C++-sig] FW: Converting from SWIG to Boost.Python
In-Reply-To: <6D805D4C4567D411AF32009027B683510B307215@xvan02.vcd.hp.com> ("BHELLA,OPINDERJIT's
 message of "Thu, 30 Jan 2003 20:02:52 -0500")
References: <6D805D4C4567D411AF32009027B683510B307215@xvan02.vcd.hp.com>
Message-ID: <uwukhf0ue.fsf@boost-consulting.com>

Sorry it's taken so long to answer this...

"BHELLA,OPINDERJIT (HP-Vancouver,ex1)" <opinderjit.bhella at hp.com> writes:

> In the example below, every function is wrapped with in a
> Py_BEGIN_ALLOW_THREADS/ Py_END_ALLOW_THREADS macro.

Oh, I see.  That %except thing affects how every function is wrapped!

> This macro allows each function to be able to run in multiple
> threads in Python. Because Py_END_ALLOW_THREADS must be called to
> acquire the interpreter lock when the function is completed, the
> PyEval_RestoreThread(_save); is also called before each catch, if an
> excepting occurs and we return NULL.
>
> Thanks for your help David!

We don't currently have a solution for that, though it's possible to
add one fairly easily.  Yours is the second request for this basic
functionality in the past few months.  Now the question is, "how to
design it into the library?"

It seems to me that authors of individual extension modules should
have the choice about whether they want every wrapped call they
contain to release the interpreter lock, so that points towards
keeping the functionality out of the core shared library.  Do
extension module authors need interpreter lock control on a
function-by-function basis?

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution




From nickm at sitius.com  Tue Feb  4 17:01:23 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Tue, 04 Feb 2003 11:01:23 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com> <uwukj6j9y.fsf@boost-consulting.com>
Message-ID: <3E3FE3D3.FF77978B@sitius.com>

I can't get "cvs diff" to work, so I am posting individual difs:

Regards
-------------- next part --------------
57a58
>     unsigned m_nkeyword_values;
-------------- next part --------------
21a22
>       keyword(char const* n=0):name(n){}
-------------- next part --------------
44a45,51
>       keywords<size+1> operator , (const keywords<1> &k) const
>       {
>           python::detail::keywords<size+1> res;
>           std::copy(elements, elements+size, res.elements);
>           res.elements[size] = k.elements[0];
>           return res;
>       }
46a54,56
>       
> 
> 
98c108,120
< #  define BOOST_PYTHON_ASSIGN_NAME(z, n, _) result.elements[n].name = name##n;
---
> struct arg : detail::keywords<1>
> {
>   template <class T>
>       arg &operator = (T const &value)
>   {
>       elements[0].default_value = handle<>(python::borrowed(object(value).ptr()));
>       return *this;
>   }
>   arg (char const *name){elements[0].name = name;}
>   operator detail::keyword const &()const {return elements[0];}
> };
> 
> #  define BOOST_PYTHON_ASSIGN_NAME(z, n, _) result.elements[n] = kwd##n;
100c122
< inline detail::keywords<n> args(BOOST_PP_ENUM_PARAMS_Z(1, n, char const* name)) \
---
> inline detail::keywords<n> args(BOOST_PP_ENUM_PARAMS_Z(1, n, detail::keyword const& kwd)) \
-------------- next part --------------
35a36
>       , m_nkeyword_values(0)
42d42
<             
48a49,50
>             object tpl (handle<>(PyTuple_New(names_and_defaults[i].default_value?2:1)));
> 
50,51c52,53
<                 m_arg_names.ptr()
<                 , i + keyword_offset
---
>                 tpl.ptr()
>                 , 0
55a58,72
>             if(names_and_defaults[i].default_value){
>                 PyTuple_SET_ITEM(
>                     tpl.ptr()
>                     , 1
>                     , incref(names_and_defaults[i].default_value.get())
>                     );
>                 ++m_nkeyword_values;
>             }
> 
> 
>             PyTuple_SET_ITEM(
>                 m_arg_names.ptr()
>                 , i + keyword_offset
>                 , incref(tpl.ptr())
>                 );
82c99
<         if (total_args >= f->m_min_arity && total_args <= f->m_max_arity)
---
>         if (total_args+f->m_nkeyword_values >= f->m_min_arity && total_args <= f->m_max_arity)
85c102
<             if (nkeywords > 0)
---
>             if (nkeywords > 0 || total_args < f->m_min_arity)
94,95c111,112
<                     // build a new arg tuple
<                     args2 = handle<>(PyTuple_New(total_args));
---
>                     // build a new arg tuple, will adjust its size later
>                     args2 = handle<>(PyTuple_New(f->m_max_arity));
102c119,120
<                     for (std::size_t j = nargs; j < total_args; ++j)
---
>                     std::size_t j = nargs, k = nargs;
>                     for (; j < f->m_max_arity && k < total_args; ++j)
103a122,123
>                         handle<> kwd(PyTuple_GET_ITEM(f->m_arg_names.ptr(), j));
> 
105c125
<                             keywords, PyTuple_GET_ITEM(f->m_arg_names.ptr(), j));
---
>                             keywords, PyTuple_GET_ITEM(kwd.get(), 0));
108a129,131
>                             value = PyTuple_GET_ITEM(kwd.get(), 1);
>                             if (!value)
>                             {
112a136
>                         }else ++k;
114a139,154
>                     if(args2.get()){
>                         //check if we proccessed all the arguments
>                         if(k < total_args)
>                             args2 = handle<>();
> 
>                         //adjust the parameter tuple size
>                         if(j<f->m_max_arity){
>                             handle<> args3( PyTuple_New(j) );
>                             for(size_t l=0; l!=j; ++l)
>                             {
>                                 PyTuple_SET_ITEM(args3.get(), l, PyTuple_GET_ITEM(args3.get(), l));
>                                 PyTuple_SET_ITEM(args2.get(), l, 0);
>                             }
>                             args2 = args3;
>                         }
>                     }

From nickm at sitius.com  Tue Feb  4 17:01:23 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Tue, 04 Feb 2003 11:01:23 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com> <uwukj6j9y.fsf@boost-consulting.com>
Message-ID: <3E3FE3D3.FF77978B@sitius.com>

I can't get "cvs diff" to work, so I am posting individual difs:

Regards
-------------- next part --------------
57a58
>     unsigned m_nkeyword_values;
-------------- next part --------------
21a22
>       keyword(char const* n=0):name(n){}
-------------- next part --------------
44a45,51
>       keywords<size+1> operator , (const keywords<1> &k) const
>       {
>           python::detail::keywords<size+1> res;
>           std::copy(elements, elements+size, res.elements);
>           res.elements[size] = k.elements[0];
>           return res;
>       }
46a54,56
>       
> 
> 
98c108,120
< #  define BOOST_PYTHON_ASSIGN_NAME(z, n, _) result.elements[n].name = name##n;
---
> struct arg : detail::keywords<1>
> {
>   template <class T>
>       arg &operator = (T const &value)
>   {
>       elements[0].default_value = handle<>(python::borrowed(object(value).ptr()));
>       return *this;
>   }
>   arg (char const *name){elements[0].name = name;}
>   operator detail::keyword const &()const {return elements[0];}
> };
> 
> #  define BOOST_PYTHON_ASSIGN_NAME(z, n, _) result.elements[n] = kwd##n;
100c122
< inline detail::keywords<n> args(BOOST_PP_ENUM_PARAMS_Z(1, n, char const* name)) \
---
> inline detail::keywords<n> args(BOOST_PP_ENUM_PARAMS_Z(1, n, detail::keyword const& kwd)) \
-------------- next part --------------
35a36
>       , m_nkeyword_values(0)
42d42
<             
48a49,50
>             object tpl (handle<>(PyTuple_New(names_and_defaults[i].default_value?2:1)));
> 
50,51c52,53
<                 m_arg_names.ptr()
<                 , i + keyword_offset
---
>                 tpl.ptr()
>                 , 0
55a58,72
>             if(names_and_defaults[i].default_value){
>                 PyTuple_SET_ITEM(
>                     tpl.ptr()
>                     , 1
>                     , incref(names_and_defaults[i].default_value.get())
>                     );
>                 ++m_nkeyword_values;
>             }
> 
> 
>             PyTuple_SET_ITEM(
>                 m_arg_names.ptr()
>                 , i + keyword_offset
>                 , incref(tpl.ptr())
>                 );
82c99
<         if (total_args >= f->m_min_arity && total_args <= f->m_max_arity)
---
>         if (total_args+f->m_nkeyword_values >= f->m_min_arity && total_args <= f->m_max_arity)
85c102
<             if (nkeywords > 0)
---
>             if (nkeywords > 0 || total_args < f->m_min_arity)
94,95c111,112
<                     // build a new arg tuple
<                     args2 = handle<>(PyTuple_New(total_args));
---
>                     // build a new arg tuple, will adjust its size later
>                     args2 = handle<>(PyTuple_New(f->m_max_arity));
102c119,120
<                     for (std::size_t j = nargs; j < total_args; ++j)
---
>                     std::size_t j = nargs, k = nargs;
>                     for (; j < f->m_max_arity && k < total_args; ++j)
103a122,123
>                         handle<> kwd(PyTuple_GET_ITEM(f->m_arg_names.ptr(), j));
> 
105c125
<                             keywords, PyTuple_GET_ITEM(f->m_arg_names.ptr(), j));
---
>                             keywords, PyTuple_GET_ITEM(kwd.get(), 0));
108a129,131
>                             value = PyTuple_GET_ITEM(kwd.get(), 1);
>                             if (!value)
>                             {
112a136
>                         }else ++k;
114a139,154
>                     if(args2.get()){
>                         //check if we proccessed all the arguments
>                         if(k < total_args)
>                             args2 = handle<>();
> 
>                         //adjust the parameter tuple size
>                         if(j<f->m_max_arity){
>                             handle<> args3( PyTuple_New(j) );
>                             for(size_t l=0; l!=j; ++l)
>                             {
>                                 PyTuple_SET_ITEM(args3.get(), l, PyTuple_GET_ITEM(args3.get(), l));
>                                 PyTuple_SET_ITEM(args2.get(), l, 0);
>                             }
>                             args2 = args3;
>                         }
>                     }

From bruce_lowery at yahoo.com  Tue Feb  4 21:09:15 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Tue, 4 Feb 2003 12:09:15 -0800 (PST)
Subject: [C++-sig] Can ownership of a wrapped C++ object be transferred between python objects?
Message-ID: <20030204200915.26302.qmail@web10903.mail.yahoo.com>

Part of an API that I'm wrapping goes something like this:

struct A {}; struct B { void insert( A* ); }
where B::add() takes ownership of the pointer passed to it.

However:

a = mod.A()
b = mod.B()
b.add( a )
del a         
del b
# python interpreter crashes 
# later due to memory corruption.

Even binding the lifetime of 'a' to 'b' via with_custodian_and_ward doesn't
prevent the python object 'a' from ultimately trying to delete the object it's
pointing to (right? - I tried anyway and didn't see any improvement).  

Is there a way to accomplish a 'transfer-of-ownership' of a wrapped C++ object?

Bruce Lowery


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From bruce_lowery at yahoo.com  Tue Feb  4 21:13:09 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Tue, 4 Feb 2003 12:13:09 -0800 (PST)
Subject: [C++-sig] Can ownership of a wrapped C++ object be transferred between python objects?
In-Reply-To: <20030204200915.26302.qmail@web10903.mail.yahoo.com>
Message-ID: <20030204201309.31281.qmail@web10907.mail.yahoo.com>

Sorry - meant 'B::insert()' everywhere below instead of 'B::add()'.

--- Bruce Lowery <bruce_lowery at yahoo.com> wrote:
> Part of an API that I'm wrapping goes something like this:
> 
> struct A {}; struct B { void insert( A* ); }
> where B::add() takes ownership of the pointer passed to it.
> 
> However:
> 
> a = mod.A()
> b = mod.B()
> b.add( a )
> del a         
> del b
> # python interpreter crashes 
> # later due to memory corruption.
> 
> Even binding the lifetime of 'a' to 'b' via with_custodian_and_ward doesn't
> prevent the python object 'a' from ultimately trying to delete the object
> it's
> pointing to (right? - I tried anyway and didn't see any improvement).  
> 
> Is there a way to accomplish a 'transfer-of-ownership' of a wrapped C++
> object?
> 
> Bruce Lowery
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Tue Feb  4 21:23:38 2003
From: dave at boost-consulting.com (Dave Abrahams)
Date: Tue, 4 Feb 2003 15:23:38 -0500
Subject: [C++-sig] Can ownership of a wrapped C++ object be transferred between python objects?
References: <20030204200915.26302.qmail@web10903.mail.yahoo.com>
Message-ID: <024c01c2cc8b$f5a13b20$6501a8c0@penguin>

On Tuesday, February 04, 2003 3:09 PM [GMT+1=CET],
Bruce Lowery <bruce_lowery at yahoo.com> wrote:

> Part of an API that I'm wrapping goes something like this:
>
> struct A {}; struct B { void insert( A* ); }
> where B::add() takes ownership of the pointer passed to it.
>
> However:
>
> a = mod.A()
> b = mod.B()
> b.add( a )
> del a
> del b
> # python interpreter crashes
> # later due to memory corruption.
>
> Even binding the lifetime of 'a' to 'b' via with_custodian_and_ward
doesn't
> prevent the python object 'a' from ultimately trying to delete the object
> it's pointing to (right? - I tried anyway and didn't see any improvement).

Right.  with_custodian_and_ward adds more lifetime management from the
Python side, and you need less ;-)

> Is there a way to accomplish a 'transfer-of-ownership' of a wrapped C++
> object?

Yes: Make sure the C++ object is held by auto_ptr:

    class_<A, std::auto_ptr<A> >("A")
        ...
        ;

Then make a thin wrapper function which takes an auto_ptr parameter:

    void b_insert(B& b, std::auto_ptr<A> a)
    {
        b.insert(a.get());
        a.release();
    }

Wrap that as B.add.

HTH,
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From bruce_lowery at yahoo.com  Tue Feb  4 22:06:43 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Tue, 4 Feb 2003 13:06:43 -0800 (PST)
Subject: [C++-sig] Can ownership of a wrapped C++ object be transferred between python objects?
In-Reply-To: <024c01c2cc8b$f5a13b20$6501a8c0@penguin>
Message-ID: <20030204210643.41818.qmail@web10908.mail.yahoo.com>

It took much longer for me to compose the message than it did for you to solve
and answer it.   As always, Thanks.

Bruce lowery

--- Dave Abrahams <dave at boost-consulting.com> wrote:
> On Tuesday, February 04, 2003 3:09 PM [GMT+1=CET],
> Bruce Lowery <bruce_lowery at yahoo.com> wrote:
> 
> > Part of an API that I'm wrapping goes something like this:
> >
> > struct A {}; struct B { void insert( A* ); }
> > where B::add() takes ownership of the pointer passed to it.
> >
> > However:
> >
> > a = mod.A()
> > b = mod.B()
> > b.add( a )
> > del a
> > del b
> > # python interpreter crashes
> > # later due to memory corruption.
> >
> > Even binding the lifetime of 'a' to 'b' via with_custodian_and_ward
> doesn't
> > prevent the python object 'a' from ultimately trying to delete the object
> > it's pointing to (right? - I tried anyway and didn't see any improvement).
> 
> Right.  with_custodian_and_ward adds more lifetime management from the
> Python side, and you need less ;-)
> 
> > Is there a way to accomplish a 'transfer-of-ownership' of a wrapped C++
> > object?
> 
> Yes: Make sure the C++ object is held by auto_ptr:
> 
>     class_<A, std::auto_ptr<A> >("A")
>         ...
>         ;
> 
> Then make a thin wrapper function which takes an auto_ptr parameter:
> 
>     void b_insert(B& b, std::auto_ptr<A> a)
>     {
>         b.insert(a.get());
>         a.release();
>     }
> 
> Wrap that as B.add.
> 
> HTH,
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Wed Feb  5 04:36:55 2003
From: dave at boost-consulting.com (Dave Abrahams)
Date: Tue, 4 Feb 2003 22:36:55 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com> <uwukj6j9y.fsf@boost-consulting.com> <3E3FE3D3.FF77978B@sitius.com>
Message-ID: <022901c2ccc8$37b835e0$6501a8c0@penguin>

On Tuesday, February 04, 2003 11:01 AM [GMT+1=CET],
Nikolay Mladenov <nickm at sitius.com> wrote:

> > I can't get "cvs diff" to work, so I am posting individual difs:
> >
> > Regards

Nikolay,

I'm not ignoring you, but I just had a data-loss emergency, so it might be a
little while before I can evaluate your patches.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From nickm at sitius.com  Wed Feb  5 22:43:13 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Wed, 05 Feb 2003 16:43:13 -0500
Subject: [C++-sig] Re: Boost.Python v2: Keywords
References: <3E3B4786.B659380B@sitius.com> <uwukj6j9y.fsf@boost-consulting.com> <3E3FE3D3.FF77978B@sitius.com>
Message-ID: <3E418571.E3F01F2B@sitius.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030205/4d6885b4/attachment.htm>
-------------- next part --------------
35a36
>       , m_nkeyword_values(0)
42d42
<             
48a49,50
>             object tpl (handle<>(PyTuple_New(names_and_defaults[i].default_value?2:1)));
> 
50,51c52,53
<                 m_arg_names.ptr()
<                 , i + keyword_offset
---
>                 tpl.ptr()
>                 , 0
55a58,72
>             if(names_and_defaults[i].default_value){
>                 PyTuple_SET_ITEM(
>                     tpl.ptr()
>                     , 1
>                     , incref(names_and_defaults[i].default_value.get())
>                     );
>                 ++m_nkeyword_values;
>             }
> 
> 
>             PyTuple_SET_ITEM(
>                 m_arg_names.ptr()
>                 , i + keyword_offset
>                 , incref(tpl.ptr())
>                 );
82c99
<         if (total_args >= f->m_min_arity && total_args <= f->m_max_arity)
---
>         if (total_args+f->m_nkeyword_values >= f->m_min_arity && total_args <= f->m_max_arity)
85c102
<             if (nkeywords > 0)
---
>             if (nkeywords > 0 || total_args < f->m_min_arity)
94,95c111,112
<                     // build a new arg tuple
<                     args2 = handle<>(PyTuple_New(total_args));
---
>                     // build a new arg tuple, will adjust its size later
>                     args2 = handle<>(PyTuple_New(f->m_max_arity));
102c119,120
<                     for (std::size_t j = nargs; j < total_args; ++j)
---
>                     std::size_t j = nargs, k = nargs, size=PyTuple_GET_SIZE(f->m_arg_names.ptr());
>                     for (; j < f->m_max_arity && j<size ; ++j)
103a122,123
>                         PyObject* kwd=PyTuple_GET_ITEM(f->m_arg_names.ptr(), j);
> 
105c125
<                             keywords, PyTuple_GET_ITEM(f->m_arg_names.ptr(), j));
---
>                             keywords, PyTuple_GET_ITEM(kwd, 0));
108a129,132
>                             if(PyTuple_GET_SIZE(kwd)>1)
>                                 value = PyTuple_GET_ITEM(kwd, 1);
>                             if (!value)
>                             {
112a137
>                         }else ++k;
114a140,156
> 
>                     if(args2.get()){
>                         //check if we proccessed all the arguments
>                         if(k < total_args)
>                             args2 = handle<>();
> 
>                         //adjust the parameter tuple size
>                         if(j<f->m_max_arity){
>                             handle<> args3( PyTuple_New(j) );
>                             for(size_t l=0; l!=j; ++l)
>                             {
>                                 PyTuple_SET_ITEM(args3.get(), l, PyTuple_GET_ITEM(args3.get(), l));
>                                 PyTuple_SET_ITEM(args2.get(), l, 0);
>                             }
>                             args2 = args3;
>                         }
>                     }

From anthony at interlink.com.au  Thu Feb  6 08:45:24 2003
From: anthony at interlink.com.au (Anthony Baxter)
Date: Thu, 06 Feb 2003 18:45:24 +1100
Subject: [C++-sig] overloaded member functions in boost.python
Message-ID: <200302060745.h167jOe00576@localhost.localdomain>

[I initially sent this to python-list - I completely forgot about
c++-sig. Any help would be greatly appreciated...]


Does anyone have any examples using Boost::Python that are more complex
than the simple ones in the tutorial? I'm trying to wrap a large class
library (OpenH323) and I'm constantly banging my head against weird
errors that are more or less trial and error to figure out. The only 
chunks of code I can find are the bits in the "test" directory of the
distribution, and they're all a bit... artificial.

The specific case I'm trying to solve at the moment is that I have
a class (H323Connection) that defines a number of variants of a member
function MakeCall:

    H323Connection * MakeCall(
      const PString & remoteParty,  /// Remote party to call
      PString & token,              /// String to receive token for connection
      void * userData = NULL        /// user data to pass to CreateConnection
    );

    H323Connection * MakeCall(
      const PString & remoteParty,  /// Remote party to call
      H323Transport * transport,    /// Transport to use for call.
      PString & token,              /// String to receive token for connection
      void * userData = NULL        /// user data to pass to CreateConnection
    );

PString is the class library's own String class - I've already got 
functions working that accept them, and return them, fine (using converters).

It's really not clear to me how I'm supposed to specify which of these
methods I want to call. The BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro
seems to be more about the numbers of arguments, rather than choosing
from methods with different argument types.

BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(makecall_overloads, 
                                       H323EndPoint::MakeCall, 2, 3);
...
   class_<H323EndPoint>("H323EndPoint")
           .def("MakeCall", &H323EndPoint::MakeCall, 
                makecall_overloads(args("remoteParty", "token")))

produces 
h323.cpp:166: no matching function for call to 
   `boost::python::class_<H323EndPoint, boost::python::detail::not_specified, 
   boost::python::detail::not_specified, 
   boost::python::detail::not_specified>::def(const char[9], <unknown type>, 
   makecall_overloads)'

I've tried reading the reference documentation, to no avail. Is there another
source of information out there that I'm missing?

Thanks,
Anthony
--
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.




From dave at boost-consulting.com  Thu Feb  6 14:23:30 2003
From: dave at boost-consulting.com (Dave Abrahams)
Date: Thu, 6 Feb 2003 08:23:30 -0500
Subject: [C++-sig] overloaded member functions in boost.python
References: <200302060745.h167jOe00576@localhost.localdomain>
Message-ID: <103c01c2cde4$9f4f7f20$7901a8c0@penguin>

On Thursday, February 06, 2003 2:45 AM [GMT+1=CET],
Anthony Baxter <anthony at interlink.com.au> wrote:

> [I initially sent this to python-list - I completely forgot about
> c++-sig. Any help would be greatly appreciated...]
>
>
> Does anyone have any examples using Boost::Python that are more complex
> than the simple ones in the tutorial? I'm trying to wrap a large class
> library (OpenH323) and I'm constantly banging my head against weird
> errors that are more or less trial and error to figure out. The only
> chunks of code I can find are the bits in the "test" directory of the
> distribution, and they're all a bit... artificial.
>
> The specific case I'm trying to solve at the moment is that I have
> a class (H323Connection) that defines a number of variants of a member
> function MakeCall:
>
>     H323Connection * MakeCall(
>       const PString & remoteParty,  /// Remote party to call
>       PString & token,              /// String to receive token for
>       connection void * userData = NULL        /// user data to pass to
>     CreateConnection );
>
>     H323Connection * MakeCall(
>       const PString & remoteParty,  /// Remote party to call
>       H323Transport * transport,    /// Transport to use for call.
>       PString & token,              /// String to receive token for
>       connection void * userData = NULL        /// user data to pass to
>     CreateConnection );

What is "connection void*"?  That doesn't look like a legal type to me.

> PString is the class library's own String class - I've already got
> functions working that accept them, and return them, fine (using
> converters).
>
> It's really not clear to me how I'm supposed to specify which of these
> methods I want to call. The BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro
> seems to be more about the numbers of arguments, rather than choosing
> from methods with different argument types.

Exactly.  I keep thinking we should rename those macros somehow to indicate
that.

Dealing with a pair of overloaded functions like that is simple, yet
tedious.  You need to get a pointer to each of them.  The only way to do
that is to do something which discriminates the type.  The safest way is:

  H323Connect* (H323EndPoint::*f1)(const PString&,PString&,connection void*)
= MakeCall;
  H323Connect* (H323EndPoint::*f2)(const PString&,H323Transport*
PString&,connection void*) = MakeCall;

    ...

    class_<H323EndPoint>("H323EndPoint")
           .def("MakeCall", f1)
           .def("MakeCall", f2)
           ;

> I've tried reading the reference documentation, to no avail. Is there
> another source of information out there that I'm missing?

I'm going to try to get Joel to put this in the tutorial, since everyone
seems to ask all the time.

There are some Wiki pages here:
http://www.python.org/cgi-bin/moinmoin/boost_2epython, though I'm not sure
what condition they're in.

The latest on-line docs are always at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/index.html

HTH,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From bruce_lowery at yahoo.com  Fri Feb  7 17:09:18 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Fri, 7 Feb 2003 08:09:18 -0800 (PST)
Subject: [C++-sig] Inheritance with B/P
Message-ID: <20030207160918.54002.qmail@web10901.mail.yahoo.com>

The short tutorial section on inheritance seems very clear.  However, the
following doesn't work for me:

struct Base {};
struct Derived : Base {}
struct SomeOther { void someFunc( Base* o ); }

When wrapped (using bases<..> for Derived), the following gives a type error:

> d = mod.Derived()
> s = mod.SomeOther()
> s.someOther( d )
TypeError:  bad argument type for built-in operation
>

In reality, the wrappers "hold" Base and Derived using auto_ptr:

class_< Base, auto_ptr<Base> >(...) ...;
class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;

Any ideas?

Bruce Lowery


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Fri Feb  7 18:41:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 07 Feb 2003 12:41:49 -0500
Subject: [C++-sig] Inheritance with B/P
In-Reply-To: <20030207160918.54002.qmail@web10901.mail.yahoo.com> (Bruce
 Lowery's message of "Fri, 7 Feb 2003 08:09:18 -0800 (PST)")
References: <20030207160918.54002.qmail@web10901.mail.yahoo.com>
Message-ID: <ufzr0xa1u.fsf@boost-consulting.com>

Bruce Lowery <bruce_lowery at yahoo.com> writes:

> The short tutorial section on inheritance seems very clear.  However, the
> following doesn't work for me:
>
> struct Base {};
> struct Derived : Base {}
> struct SomeOther { void someFunc( Base* o ); }
>
> When wrapped (using bases<..> for Derived), the following gives a type error:
>
>> d = mod.Derived()
>> s = mod.SomeOther()
>> s.someOther( d )
> TypeError:  bad argument type for built-in operation
>>
>
> In reality, the wrappers "hold" Base and Derived using auto_ptr:
>
> class_< Base, auto_ptr<Base> >(...) ...;
> class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;
>
> Any ideas?

This looks small enough that you could post a complete reproducible
test case, no?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From bruce_lowery at yahoo.com  Fri Feb  7 19:13:55 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Fri, 7 Feb 2003 10:13:55 -0800 (PST)
Subject: [C++-sig] Inheritance with B/P
In-Reply-To: <ufzr0xa1u.fsf@boost-consulting.com>
Message-ID: <20030207181356.44716.qmail@web10902.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Bruce Lowery <bruce_lowery at yahoo.com> writes:
> 
> > The short tutorial section on inheritance seems very clear.  However, the
> > following doesn't work for me:
> >
> > struct Base {};
> > struct Derived : Base {}
> > struct SomeOther { void someFunc( Base* o ); }
> >
> > When wrapped (using bases<..> for Derived), the following gives a type
> error:
> >
> >> d = mod.Derived()
> >> s = mod.SomeOther()
> >> s.someOther( d )
> > TypeError:  bad argument type for built-in operation
> >>
> >
> > In reality, the wrappers "hold" Base and Derived using auto_ptr:
> >
> > class_< Base, auto_ptr<Base> >(...) ...;
> > class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;
> >
> > Any ideas?
> 
> This looks small enough that you could post a complete reproducible
> test case, no?
> 

The classes above are a vast simplification of my actual code - which I can't
post.  Obviously, it may be that there is some other mistake not exhibited in
the simple example above that is causing the error.

I had hoped someone would point out a false assumption or flawed thinking (I'm
still not a python 'expert') in the above.  If not, then I have to look for the
'other mistake' that causes python to miss the inheritance relationship between
'Derived' and 'Base' in the 'SomeOther.someFunc()' method call.

I suppose I should have first actually tested the problem on the simplified
case above before posting - was hoping, though, for a quick correction from the
more python-experienced...

Bruce Lowery

> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From mike at bindkey.com  Fri Feb  7 19:25:25 2003
From: mike at bindkey.com (Mike Rovner)
Date: Fri, 7 Feb 2003 10:25:25 -0800
Subject: [C++-sig] Re: Inheritance with B/P
References: <ufzr0xa1u.fsf@boost-consulting.com> <20030207181356.44716.qmail@web10902.mail.yahoo.com>
Message-ID: <b20ti9$nm2$1@main.gmane.org>

"Bruce Lowery" <bruce_lowery at yahoo.com> wrote in message
> > >> d = mod.Derived()
> > >> s = mod.SomeOther()
> > >> s.someOther( d )
> > > TypeError:  bad argument type for built-in operation
> > >>
> > >
> > > In reality, the wrappers "hold" Base and Derived using auto_ptr:
> > >
> > > class_< Base, auto_ptr<Base> >(...) ...;
> > > class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;
> > >
> > > Any ideas?

For me it's look like a C++ problem not a Python problem.
auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
there is no automatic conversion from former to later.

Just my .02

Mike






From bruce_lowery at yahoo.com  Fri Feb  7 20:20:02 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Fri, 7 Feb 2003 11:20:02 -0800 (PST)
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <b20ti9$nm2$1@main.gmane.org>
Message-ID: <20030207192002.97501.qmail@web10901.mail.yahoo.com>

--- Mike Rovner <mike at bindkey.com> wrote:
> For me it's look like a C++ problem not a Python problem.
> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
> there is no automatic conversion from former to later.
> 

You are right.

Turns out I left out another detail - the method that's being called with the
derived class instance, is itself wrapped by a function call.  For instance,

class SomeOther { void someFunc( Base* b ); }

void someFunc_wrap( SomeOther& self, auto_ptr<Base> b ) 
{ self.someFunc(b.get()); }

BOOST_PYTHON_MODULE(Foo){ class_<SomeOther>("SomeOther",...)
.def( "someFunc",someFunc_wrap ); }


Previously, I just had '.def("someFunc",&SomeOther::someFunc)'  which works,
evidently because b/p takes care of the conversion.


Bruce Lowery

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From bruce_lowery at yahoo.com  Fri Feb  7 19:56:57 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Fri, 7 Feb 2003 10:56:57 -0800 (PST)
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <b20ti9$nm2$1@main.gmane.org>
Message-ID: <20030207185657.44464.qmail@web10904.mail.yahoo.com>

--- Mike Rovner <mike at bindkey.com> wrote:
> "Bruce Lowery" <bruce_lowery at yahoo.com> wrote in message
> > > >> d = mod.Derived()
> > > >> s = mod.SomeOther()
> > > >> s.someOther( d )
> > > > TypeError:  bad argument type for built-in operation
> > > >>
> > > >
> > > > In reality, the wrappers "hold" Base and Derived using auto_ptr:
> > > >
> > > > class_< Base, auto_ptr<Base> >(...) ...;
> > > > class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;
> > > >
> > > > Any ideas?
> 
> For me it's look like a C++ problem not a Python problem.
> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
> there is no automatic conversion from former to later.
> 

Well, I've built the simplified version I gave previously, including the use of
auto_ptr to 'hold' the classes, and it appears to work.  So, it's something
else, likely screened from detection by its obviousness....

Thanks for wasting time thinking about this.

Bruce Lowery

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Fri Feb  7 23:37:29 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 07 Feb 2003 17:37:29 -0500
Subject: [C++-sig] Inheritance with B/P
In-Reply-To: <20030207181356.44716.qmail@web10902.mail.yahoo.com> (Bruce
 Lowery's message of "Fri, 7 Feb 2003 10:13:55 -0800 (PST)")
References: <20030207181356.44716.qmail@web10902.mail.yahoo.com>
Message-ID: <uk7gbvhsm.fsf@boost-consulting.com>

Bruce Lowery <bruce_lowery at yahoo.com> writes:

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> Bruce Lowery <bruce_lowery at yahoo.com> writes:
>> 

<snip>

>> > class_< Base, auto_ptr<Base> >(...) ...;
>> > class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;
>> >
>> > Any ideas?
>> 
>> This looks small enough that you could post a complete reproducible
>> test case, no?
>> 
>
> The classes above are a vast simplification of my actual code -
> which I can't post.  Obviously, it may be that there is some other
> mistake not exhibited in the simple example above that is causing
> the error.

It's not obvious to me.  I didn't test your simple case because what
you posted is incomplete.  Have you now verified that it doesn't work?

> I had hoped someone would point out a false assumption or flawed
> thinking (I'm still not a python 'expert') in the above.  If not,
> then I have to look for the 'other mistake' that causes python to
> miss the inheritance relationship between 'Derived' and 'Base' in
> the 'SomeOther.someFunc()' method call.

As I said, the example is incomplete, so it's hard to tell what
assumptions you may be making.

> I suppose I should have first actually tested the problem on the
> simplified case above before posting

You can learn a lot that way ;o)

>  - was hoping, though, for a quick correction from the more
> python-experienced...

And the more-experience were hoping to get an accurate picture of what
you're doing ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Fri Feb  7 23:38:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 07 Feb 2003 17:38:37 -0500
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <b20ti9$nm2$1@main.gmane.org> ("Mike Rovner"'s message of "Fri,
 7 Feb 2003 10:25:25 -0800")
References: <ufzr0xa1u.fsf@boost-consulting.com>
	<20030207181356.44716.qmail@web10902.mail.yahoo.com>
	<b20ti9$nm2$1@main.gmane.org>
Message-ID: <uhebfvhqq.fsf@boost-consulting.com>

"Mike Rovner" <mike at bindkey.com> writes:

> "Bruce Lowery" <bruce_lowery at yahoo.com> wrote in message
>> > >> d = mod.Derived()
>> > >> s = mod.SomeOther()
>> > >> s.someOther( d )
>> > > TypeError:  bad argument type for built-in operation
>> > >>
>> > >
>> > > In reality, the wrappers "hold" Base and Derived using auto_ptr:
>> > >
>> > > class_< Base, auto_ptr<Base> >(...) ...;
>> > > class_< Derived, auto_ptr<Derived>, bases<Base> >(...) ...;
>> > >
>> > > Any ideas?
>
> For me it's look like a C++ problem not a Python problem.
> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
> there is no automatic conversion from former to later.
>
> Just my .02

That's not the problem in the sample he posted, since he's not passing
them by auto_ptr, but by raw pointer.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Fri Feb  7 23:40:57 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 07 Feb 2003 17:40:57 -0500
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <20030207192002.97501.qmail@web10901.mail.yahoo.com> (Bruce
 Lowery's message of "Fri, 7 Feb 2003 11:20:02 -0800 (PST)")
References: <20030207192002.97501.qmail@web10901.mail.yahoo.com>
Message-ID: <uel6jvhmu.fsf@boost-consulting.com>

Bruce Lowery <bruce_lowery at yahoo.com> writes:

>> For me it's look like a C++ problem not a Python problem.
>> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
>> there is no automatic conversion from former to later.
>> 
>
> You are right.

That's not the problem in the sample you posted.

> Turns out I left out another detail - the method that's being called with the
> derived class instance, is itself wrapped by a function call.  For instance,
>
> class SomeOther { void someFunc( Base* b ); }
>
> void someFunc_wrap( SomeOther& self, auto_ptr<Base> b ) 
> { self.someFunc(b.get()); }
>
> BOOST_PYTHON_MODULE(Foo){ class_<SomeOther>("SomeOther",...)
> .def( "someFunc",someFunc_wrap ); }
>
>
> Previously, I just had '.def("someFunc",&SomeOther::someFunc)'  which works,
> evidently because b/p takes care of the conversion.

You've still left out a lot of detail.  How hard can it be to assemble
a reproducible case based on the code you're posting here?  You might
discover that your problem is elsewhere (if it works), which would
save both of us a lot of wasted effort ;o).  Otherwise, I'd be able to
check it out and tell you where the problem is.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From bruce_lowery at yahoo.com  Mon Feb 10 15:56:03 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Mon, 10 Feb 2003 06:56:03 -0800 (PST)
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <uel6jvhmu.fsf@boost-consulting.com>
Message-ID: <20030210145603.56688.qmail@web10903.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Bruce Lowery <bruce_lowery at yahoo.com> writes:
> 
> >> For me it's look like a C++ problem not a Python problem.
> >> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
> >> there is no automatic conversion from former to later.
> >> 
> >
> > You are right.
> 
> That's not the problem in the sample you posted.
> 

And yet, this was the root of the problem - as was indicated next.


> > Turns out I left out another detail - the method that's being called with
> the
> > derived class instance, is itself wrapped by a function call.  For
> instance,
> >
> > class SomeOther { void someFunc( Base* b ); }
> >
> > void someFunc_wrap( SomeOther& self, auto_ptr<Base> b ) 
> > { self.someFunc(b.get()); }
> >
> > BOOST_PYTHON_MODULE(Foo){ class_<SomeOther>("SomeOther",...)
> > .def( "someFunc",someFunc_wrap ); }
> >
> >
> > Previously, I just had '.def("someFunc",&SomeOther::someFunc)'  which
> works,
> > evidently because b/p takes care of the conversion.
> 
> You've still left out a lot of detail.  How hard can it be to assemble
> a reproducible case based on the code you're posting here?  You might
> discover that your problem is elsewhere (if it works), which would
> save both of us a lot of wasted effort ;o).  Otherwise, I'd be able to
> check it out and tell you where the problem is.
> 

There's hardly anything more to it.  Here's what I built and tested
(the use of auto_ptr appears unnecessary in this example, but is needed in the
real implementation):

#include <string>
#include <memory>
#include "boost/python.hpp"
using namespace boost::python;
struct Base { virtual ~Base() {} };
struct Derived : Base { virtual ~Derived() {} };
struct SomeOther {
	virtual ~SomeOther() {}
	std::string someFunc( Base* b ) { return "ok"; }
};
std::string someFunc_wrap( SomeOther& self, std::auto_ptr<Base> b )
{
	return self.someFunc( b.get() );
}
std::string someFunc_wrap( SomeOther& self, std::auto_ptr<Derived> d )
{
	return self.someFunc( d.get() );
}
BOOST_PYTHON_MODULE(Foo) {
class_< Base, std::auto_ptr<Base> >("Base", init<>() ) ;
class_< Derived, std::auto_ptr<Derived>, bases< Base > >("Derived", init<>() )
;
class_< SomeOther >("SomeOther", init<>() )
.def( "someFunc", (std::string(*)(SomeOther& self, std::auto_ptr<Base>))
someFunc_wrap )
.def( "someFunc", (std::string(*)(SomeOther& self, std::auto_ptr<Derived>))
someFunc_wrap )
;
}

And the python code to test it:

> import Foo
> d = Foo.Derived()
> s = Foo.SomeOther()
> ss = s.someFunc( d )
> print ss
ok
>


Notice that to fix the problem, I overloaded the wrapper function (for
SomeOther::someFunc) to take either auto_ptr<Derived> or auto_ptr<Base>.  

This compiles and executes successfully.

However, it's not an attractive solution since I have to add a function wrapper
for every subclass of Base that could be passed to SomeOther::someFunc().

Is there a better way to do this?

Bruce Lowery

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Mon Feb 10 16:38:20 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 10 Feb 2003 10:38:20 -0500
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <20030210145603.56688.qmail@web10903.mail.yahoo.com> (Bruce
 Lowery's message of "Mon, 10 Feb 2003 06:56:03 -0800 (PST)")
References: <20030210145603.56688.qmail@web10903.mail.yahoo.com>
Message-ID: <ud6m0gn83.fsf@boost-consulting.com>

Bruce Lowery <bruce_lowery at yahoo.com> writes:

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> Bruce Lowery <bruce_lowery at yahoo.com> writes:
>> 
>> >> For me it's look like a C++ problem not a Python problem.
>> >> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
>> >> there is no automatic conversion from former to later.
>> >> 
>> >
>> > You are right.
>> 
>> That's not the problem in the sample you posted.
>> 

I said that because at no point in your code were you passing
any auto_ptrs to functions.

> And yet, this was the root of the problem - as was indicated next.
>
>
>> > Turns out I left out another detail - the method that's being called with
>> the
>> > derived class instance, is itself wrapped by a function call.  For
>> instance,
>> >
>> > class SomeOther { void someFunc( Base* b ); }
>> >
>> > void someFunc_wrap( SomeOther& self, auto_ptr<Base> b ) 
                                          ^^^^^^^^^^^^^^
>> > { self.someFunc(b.get()); }

Ah, I missed that buried detail.

>> > BOOST_PYTHON_MODULE(Foo){ class_<SomeOther>("SomeOther",...)
>> > .def( "someFunc",someFunc_wrap ); }
>> >
>> >
>> > Previously, I just had '.def("someFunc",&SomeOther::someFunc)'
>> > which works, evidently because b/p takes care of the conversion.
>> 
>> You've still left out a lot of detail.  How hard can it be to
>> assemble a reproducible case based on the code you're posting here?
>> You might discover that your problem is elsewhere (if it works),
>> which would save both of us a lot of wasted effort ;o).  Otherwise,
>> I'd be able to check it out and tell you where the problem is.
>> 
>
> There's hardly anything more to it.  Here's what I built and tested
> (the use of auto_ptr appears unnecessary in this example, but is
> needed in the real implementation):

<snip>

> Notice that to fix the problem, I overloaded the wrapper function
> (for SomeOther::someFunc) to take either auto_ptr<Derived> or
> auto_ptr<Base>.
>
> This compiles and executes successfully.
>
> However, it's not an attractive solution since I have to add a
> function wrapper for every subclass of Base that could be passed to
> SomeOther::someFunc().
>
> Is there a better way to do this?

Does 

     implicitly_convertible<
         std::auto_ptr<Derived>
       , std::auto_ptr<Base>
     >();

, placed in your module init function, help?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From bruce_lowery at yahoo.com  Mon Feb 10 17:01:29 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Mon, 10 Feb 2003 08:01:29 -0800 (PST)
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <ud6m0gn83.fsf@boost-consulting.com>
Message-ID: <20030210160129.60228.qmail@web10901.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Bruce Lowery <bruce_lowery at yahoo.com> writes:
> 
> > --- David Abrahams <dave at boost-consulting.com> wrote:
> >> Bruce Lowery <bruce_lowery at yahoo.com> writes:
> >> 
> >> >> For me it's look like a C++ problem not a Python problem.
> >> >> auto_ptr<Derived> is not inherited from auto_ptr<Base> and/or
> >> >> there is no automatic conversion from former to later.
> >> >> 
> >> >
> >> > You are right.
> >> 
> >> That's not the problem in the sample you posted.
> >> 
> 
> I said that because at no point in your code were you passing
> any auto_ptrs to functions.
> 
> > And yet, this was the root of the problem - as was indicated next.
> >
> >
> >> > Turns out I left out another detail - the method that's being called
> with
> >> the
> >> > derived class instance, is itself wrapped by a function call.  For
> >> instance,
> >> >
> >> > class SomeOther { void someFunc( Base* b ); }
> >> >
> >> > void someFunc_wrap( SomeOther& self, auto_ptr<Base> b ) 
>                                           ^^^^^^^^^^^^^^
> >> > { self.someFunc(b.get()); }
> 
> Ah, I missed that buried detail.
> 
> >> > BOOST_PYTHON_MODULE(Foo){ class_<SomeOther>("SomeOther",...)
> >> > .def( "someFunc",someFunc_wrap ); }
> >> >
> >> >
> >> > Previously, I just had '.def("someFunc",&SomeOther::someFunc)'
> >> > which works, evidently because b/p takes care of the conversion.
> >> 
> >> You've still left out a lot of detail.  How hard can it be to
> >> assemble a reproducible case based on the code you're posting here?
> >> You might discover that your problem is elsewhere (if it works),
> >> which would save both of us a lot of wasted effort ;o).  Otherwise,
> >> I'd be able to check it out and tell you where the problem is.
> >> 
> >
> > There's hardly anything more to it.  Here's what I built and tested
> > (the use of auto_ptr appears unnecessary in this example, but is
> > needed in the real implementation):
> 
> <snip>
> 
> > Notice that to fix the problem, I overloaded the wrapper function
> > (for SomeOther::someFunc) to take either auto_ptr<Derived> or
> > auto_ptr<Base>.
> >
> > This compiles and executes successfully.
> >
> > However, it's not an attractive solution since I have to add a
> > function wrapper for every subclass of Base that could be passed to
> > SomeOther::someFunc().
> >
> > Is there a better way to do this?
> 
> Does 
> 
>      implicitly_convertible<
>          std::auto_ptr<Derived>
>        , std::auto_ptr<Base>
>      >();
> 
> , placed in your module init function, help?
> 

Although this would be an improvement over what I'm doing now, it still
requires a 'implicitly_convertible' for each derived class, doesn't it?  

The lib I'm wrapping has quite an (unfortunately) extensive class hierarchy
with ongoing work to add new business objects as derived types.

I could imagine having something (on my side) generate the
'implicitly_convertible' statements at build time, but obviously would like to
avoid that too.

Bruce Lowery

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Mon Feb 10 17:12:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 10 Feb 2003 11:12:21 -0500
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <20030210160129.60228.qmail@web10901.mail.yahoo.com> (Bruce
 Lowery's message of "Mon, 10 Feb 2003 08:01:29 -0800 (PST)")
References: <20030210160129.60228.qmail@web10901.mail.yahoo.com>
Message-ID: <usmuwf72y.fsf@boost-consulting.com>

Bruce Lowery <bruce_lowery at yahoo.com> writes:

>> > Is there a better way to do this?
>> 
>> Does 
>> 
>>      implicitly_convertible<
>>          std::auto_ptr<Derived>
>>        , std::auto_ptr<Base>
>>      >();
>> 
>> , placed in your module init function, help?
>> 
>
> Although this would be an improvement over what I'm doing now, it still
> requires a 'implicitly_convertible' for each derived class, doesn't it?  

Yep.  I could try to create auto_ptr conversions automatically, but
the system is designed to work on all kinds of smart pointer and
generalizing the mechanism would be very difficult.  Maybe I shouldn't
worry about that.

> The lib I'm wrapping has quite an (unfortunately) extensive class hierarchy
> with ongoing work to add new business objects as derived types.
>
> I could imagine having something (on my side) generate the
> 'implicitly_convertible' statements at build time, but obviously would like to
> avoid that too.

It looks like it would require some library extensions.
(un)fortunately I'm getting ready to go on vacation and probably won't
have time to do volunteer work on Boost.Python for a couple of weeks
at a minimum.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From bruce_lowery at yahoo.com  Mon Feb 10 17:49:41 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Mon, 10 Feb 2003 08:49:41 -0800 (PST)
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <usmuwf72y.fsf@boost-consulting.com>
Message-ID: <20030210164941.82316.qmail@web10907.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> 
> It looks like it would require some library extensions.
> (un)fortunately I'm getting ready to go on vacation and probably won't
> have time to do volunteer work on Boost.Python for a couple of weeks
> at a minimum.
> 

Bon voyage!

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From bruce_lowery at yahoo.com  Mon Feb 10 18:52:09 2003
From: bruce_lowery at yahoo.com (Bruce Lowery)
Date: Mon, 10 Feb 2003 09:52:09 -0800 (PST)
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <usmuwf72y.fsf@boost-consulting.com>
Message-ID: <20030210175210.83507.qmail@web10908.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Bruce Lowery <bruce_lowery at yahoo.com> writes:
> 
> >> > Is there a better way to do this?
> >> 
> >> Does 
> >> 
> >>      implicitly_convertible<
> >>          std::auto_ptr<Derived>
> >>        , std::auto_ptr<Base>
> >>      >();
> >> 
> >> , placed in your module init function, help?
> >> 
> >
> > Although this would be an improvement over what I'm doing now, it still
> > requires a 'implicitly_convertible' for each derived class, doesn't it?  
> 
> Yep.  I could try to create auto_ptr conversions automatically, but
> the system is designed to work on all kinds of smart pointer and
> generalizing the mechanism would be very difficult.  Maybe I shouldn't
> worry about that.
> 


Perhaps a better way is to avoid the use of auto_ptr altogether.  Recall that I
needed to use it because I'm wrapping some methods that take ownership of a
passed-in pointer.  Is it possible to invent a new policy to represent this
semantic information and that would cause b/p to set 'thisown=0' on the python
object wrapping the pointer?  


Bruce Lowery

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Tue Feb 11 01:54:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 10 Feb 2003 19:54:22 -0500
Subject: [C++-sig] Re: Inheritance with B/P
In-Reply-To: <20030210175210.83507.qmail@web10908.mail.yahoo.com> (Bruce
 Lowery's message of "Mon, 10 Feb 2003 09:52:09 -0800 (PST)")
References: <20030210175210.83507.qmail@web10908.mail.yahoo.com>
Message-ID: <uadh3bps1.fsf@boost-consulting.com>

Bruce Lowery <bruce_lowery at yahoo.com> writes:

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> Bruce Lowery <bruce_lowery at yahoo.com> writes:
>> 
>> >> > Is there a better way to do this?
>> >> 
>> >> Does 
>> >> 
>> >>      implicitly_convertible<
>> >>          std::auto_ptr<Derived>
>> >>        , std::auto_ptr<Base>
>> >>      >();
>> >> 
>> >> , placed in your module init function, help?
>> >> 
>> >
>> > Although this would be an improvement over what I'm doing now, it still
>> > requires a 'implicitly_convertible' for each derived class, doesn't it?  
>> 
>> Yep.  I could try to create auto_ptr conversions automatically, but
>> the system is designed to work on all kinds of smart pointer and
>> generalizing the mechanism would be very difficult.  Maybe I shouldn't
>> worry about that.
>> 
>
>
> Perhaps a better way is to avoid the use of auto_ptr altogether.
> Recall that I needed to use it because I'm wrapping some methods
> that take ownership of a passed-in pointer.  Is it possible to
> invent a new policy to represent this semantic information and that
> would cause b/p to set 'thisown=0' on the python object wrapping the
> pointer?

I don't think it's possible without replicating the same work as I
detailed above.  There is basically only one way a pointer ever gets
wrapped "raw", with no expectation that the referent's lifetime is
tied to that of a Python object, and that's when you use
reference_existing_object.

The _only_ way a Python object holds a pointer whose ownership it can
"give away" to your wrapped function, is when it holds that pointer by
auto_ptr.

Now, it's easy enough to find out that there is a Base* in the object,
even when the object holds an auto_ptr<Derived>.  The problem is
getting the object to release ownership.  To do that, I have to
somehow talk to the auto_ptr<Derived> object, i.e. to call its
release() function, or to copy it into an auto_ptr<Base> object.

I guess one possibility would be to hold owned pointers not by
auto_ptr, but by something like this:

    struct owner_base
    {
       owner_base(void* p) : m_p(p) {}
       void* release() { void* p = m_p; m_p = 0; return p; }
       void* get() const { return m_p; }
     private
       void* m_p;
    };

    template <class T>
    struct owner : owner_base
    {
       owner(T* p) : owner_base(p) {}
       ~owner() { delete get(); }
       T* get() const { return static_cast<T*>(this->owner_base::get()); }
     private:
       void operator=(owner const&);
       owner(owner const&);
    };

Then once you know there's a Base* and an owner_base in the object you
can ask the owner_base to release().  Whew, it's complicated, though.

Further, call policies don't currently control how conversions occur;
the stuff that handles ownership is currently just working on Python
objects in precall() and postcall() routines (look it up; you'll see
what I mean). This looks like an achievable but difficult
modification; not one I can see having time to do in the near future
as long as I have other paying work I can do ;-)

It looks like it would be easier to get the auto_ptr thing working,
though I realize that's not an ideal solution for you.

Sorry,
Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From jbrandmeyer at earthlink.net  Tue Feb 11 02:12:54 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: 10 Feb 2003 20:12:54 -0500
Subject: [C++-sig] Boost cold feet
Message-ID: <1044925975.705.43.camel@illuvatar>

I have an interest in an old Python extension module that was written in
C++.  The interface is managed by some old stuff that LLNL built in the
late 1990's (97?).  Since it predates the C++ standard, it is not
standard-compliant and I am looking for a modern replacement.  I see
that you folks have built up what looks like a much better interface to
Python, but I have some basic questions to ask.

1.  Is the entire Boost system required to be installed on an end-user's
machine to use a C++-based extension module that uses python-boost?  

2.  What is the bare minimum run-time support that a C++ module requires
using your extension system, exempting system libraries and python
itself?

3.  How painful is it to learn Boost's jam-based build system?

4.  Can the python->C++ extension library be built and used the
old-fashoned way (i.e. make)?

5.  Debian doesn't offer either Boost or python_boost in _any_
distribution.  Any ideas why?  This is a big source of doubt for me,
since I use Debian.

6.  Any idea about how significantly boost's jam system clashes with the
Debian Way?

7.  Do I /have/ to use the jam system to build my module for Python? 
How badly does Boost pin me into using their build system?


Basically, I'm worried about getting locked into a rare build system,
and I want to restrict my project's dependant codebase to the standard
system libraries to the maximum extent possible.

Thanks,
Jonathan




From hupp at upl.cs.wisc.edu  Tue Feb 11 02:58:29 2003
From: hupp at upl.cs.wisc.edu (Adam Hupp)
Date: Mon, 10 Feb 2003 19:58:29 -0600
Subject: [C++-sig] Boost cold feet
In-Reply-To: <1044925975.705.43.camel@illuvatar>
References: <1044925975.705.43.camel@illuvatar>
Message-ID: <20030211015829.GB17162@upl.cs.wisc.edu>

On Mon, Feb 10, 2003 at 08:12:54PM -0500, Jonathan Brandmeyer wrote:

> 1.  Is the entire Boost system required to be installed on an end-user's
> machine to use a C++-based extension module that uses python-boost?  

> 2.  What is the bare minimum run-time support that a C++ module requires
> using your extension system, exempting system libraries and python
> itself?

No, just libboost_python and your extension.

> 3.  How painful is it to learn Boost's jam-based build system?

It's not.
 

> 5.  Debian doesn't offer either Boost or python_boost in _any_
> distribution.  Any ideas why?  This is a big source of doubt for me,
> since I use Debian.

It does.  See libboost-python1.27 in stable, 1.28 in testing and 1.29
in unstable.  Neither bjam nor the Jamfiles are provided though so you
need to use make.

> 6.  Any idea about how significantly boost's jam system clashes with the
> Debian Way?

I'm not sure what you mean by the Debian Way.  Debian packages are not
tied to any particular build system.  You will have to use make though
since neither bjam nor the Jamfiles are included in the debian
packages.


> 4.  Can the python->C++ extension library be built and used the
> old-fashoned way (i.e. make)?
 
> 7.  Do I /have/ to use the jam system to build my module for Python? 
> How badly does Boost pin me into using their build system?

You don't have to.  I've used it in VC6 and make(1) with very few
problems.  If you do have problems though you will probably have to
build with bjam before getting much help.


-Adam



From rwgk at yahoo.com  Tue Feb 11 03:17:46 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 10 Feb 2003 18:17:46 -0800 (PST)
Subject: [C++-sig] Boost cold feet
In-Reply-To: <1044925975.705.43.camel@illuvatar>
Message-ID: <20030211021746.91859.qmail@web20204.mail.yahoo.com>

--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> 1.  Is the entire Boost system required to be installed on an end-user's
> machine to use a C++-based extension module that uses python-boost?  

You need the boost source code tree only to compile. Extension modules are
linked against libboost_python.so, so you have to distribute that.

> 2.  What is the bare minimum run-time support that a C++ module requires
> using your extension system, exempting system libraries and python
> itself?

Just libboost_python.so.
 
> 4.  Can the python->C++ extension library be built and used the
> old-fashoned way (i.e. make)?

Yes, but SCons is a much better build system that we use with great success.
We even have a SConscript that parses the libboost_python jam file with about
20 lines of Python code.

> 7.  Do I /have/ to use the jam system to build my module for Python? 
> How badly does Boost pin me into using their build system?

Not at all.

Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



From dave at boost-consulting.com  Tue Feb 11 03:27:38 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 10 Feb 2003 21:27:38 -0500
Subject: [C++-sig] Boost cold feet
In-Reply-To: <1044925975.705.43.camel@illuvatar> (Jonathan Brandmeyer's
 message of "10 Feb 2003 20:12:54 -0500")
References: <1044925975.705.43.camel@illuvatar>
Message-ID: <ur8afa6w5.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> I have an interest in an old Python extension module that was written in
> C++.  The interface is managed by some old stuff that LLNL built in the
> late 1990's (97?).  Since it predates the C++ standard, it is not
> standard-compliant and I am looking for a modern replacement.  I see
> that you folks have built up what looks like a much better interface to
> Python, but I have some basic questions to ask.
>
> 1.  Is the entire Boost system required to be installed on an end-user's
> machine to use a C++-based extension module that uses python-boost?  

No, just the Boost.Python runtime library, libboost_python.so.  For
that matter, if you're not interested in exchanging C++ objects with
other extension modules you can build libboost_python.a and link
to it statically.

> 2.  What is the bare minimum run-time support that a C++ module requires
> using your extension system, exempting system libraries and python
> itself?

libboost_python.so (if you choose to go the dynamic lib route) and
whatever is required by your C++ compiler (i.e. it's runtime and
standard lib).

> 3.  How painful is it to learn Boost's jam-based build system?

Depends what you want to do ;-)

It's actually a lot saner than make, but it's more complicated
internally because there's more going on.  The nice thing about it is
that if you write a build description (Jamfile) once, it will
automatically work on a wide variety of different compilers and
systems.  No need to think about compiler flags, different handling of
shared libs from system to system, etc.

> 4.  Can the python->C++ extension library be built and used the
> old-fashoned way (i.e. make)?

Sure, if you want to suffer ;-)

> 5.  Debian doesn't offer either Boost or python_boost in _any_
> distribution.  Any ideas why?  This is a big source of doubt for me,
> since I use Debian.

I think that was answered by someone else.

> 6.  Any idea about how significantly boost's jam system clashes with the
> Debian Way?

And that.  BTW, I used to have a Debian system here and was
building/testing Boost.Python on it.

> 7.  Do I /have/ to use the jam system to build my module for Python? 

No, but it is more likely to work right quickly if you do.

> How badly does Boost pin me into using their build system?

We don't.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From jbrandmeyer at earthlink.net  Tue Feb 11 04:35:54 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: 10 Feb 2003 22:35:54 -0500
Subject: [C++-sig] Boost cold feet
In-Reply-To: <20030211015829.GB17162@upl.cs.wisc.edu>
References: <1044925975.705.43.camel@illuvatar> 
	<20030211015829.GB17162@upl.cs.wisc.edu>
Message-ID: <1044934555.688.79.camel@illuvatar>

On Mon, 2003-02-10 at 20:58, Adam Hupp wrote:
> On Mon, Feb 10, 2003 at 08:12:54PM -0500, Jonathan Brandmeyer wrote:
> 
> > 1.  Is the entire Boost system required to be installed on an end-user's
> > machine to use a C++-based extension module that uses python-boost?  
> 
> > 2.  What is the bare minimum run-time support that a C++ module requires
> > using your extension system, exempting system libraries and python
> > itself?
> 
> No, just libboost_python and your extension.


Great!

> > 3.  How painful is it to learn Boost's jam-based build system?
> 
> It's not.

Better!
 
> > 5.  Debian doesn't offer either Boost or python_boost in _any_
> > distribution.  Any ideas why?  This is a big source of doubt for me,
> > since I use Debian.
> 
> It does.  See libboost-python1.27 in stable, 1.28 in testing and 1.29
> in unstable.  Neither bjam nor the Jamfiles are provided though so you
> need to use make.

Shame on me for not searching "libboost" vice "boost" or "*boost" in
debian's packages tree.  Thanks.

> 
> You don't have to.  I've used it in VC6 and make(1) with very few
> problems.  If you do have problems though you will probably have to
> build with bjam before getting much help.

I'm sold, thanks for yor help!

Jonathan






From pierre.barbier at cirad.fr  Wed Feb 12 12:14:48 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 12 Feb 2003 12:14:48 +0100
Subject: [C++-sig] Problem with derivation of abstract class
Message-ID: <3E4A2CA8.2040006@cirad.fr>

I'm learning how to wrap C++ classes in python. I'm following the (out 
of date ?) tutorial and I have this non-working example :

I have these very simple C++ class and function :

struct Base
{
   virtual int f() = 0;
};

int call_f(Base &b) {return b.f();}

To wrap it, I have to write a wrapper class deriving from the Base class :

struct BaseWrap : Base
{
   BaseWrap(PyObject *self_)
     : self(self_) {}
   int f () {return call_method<int>(self,"f");}
   PyObject *self;
};

and I have to define the python binding :

BOOST_PYTHON_MODULE(base_abs)
{
   class_<Base, BaseWrap , boost::noncopyable>("Base", no_init);
   def("call_f",call_f);
}

When I compile it using bjam, everything goes okay. But now, in the 
python interpreter, I try to derive the class Base like this :

 >>> from base_abs import *
 >>> class Derived(Base):
...	def f(self):
...		return 42
...

At this point, everything's still okay. But, if I want to instanciate an 
object of classe Derived, I obtain:

 >>> d = Derived()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
RuntimeError: This class cannot be instantiated from Python

The problem being apparently the __init__ method. Because if I redefine 
this __init__ method with something that does nothing, I can instanciate 
a Derived object :

 >>> def constructor(self):
...	pass
...
 >>> Derived.__init__=constructor
 >>> d=Derived()
 >>> d.f()
42

But still, if I now want to use the defined class_f function, I have an 
error :

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


Although, the derivation tree seems to be correct:

 >>> issubclass(Derived,Base)
1

So, is there any change in boost.python ? What do I have to do for that 
example to work ?

Thanks,

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68




From dave at boost-consulting.com  Thu Feb 13 18:44:31 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 13 Feb 2003 12:44:31 -0500
Subject: [C++-sig] Problem with derivation of abstract class
In-Reply-To: <3E4A2CA8.2040006@cirad.fr> (Pierre Barbier de Reuille's
 message of "Wed, 12 Feb 2003 12:14:48 +0100")
References: <3E4A2CA8.2040006@cirad.fr>
Message-ID: <uwuk4jcsg.fsf@boost-consulting.com>

Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:

> I'm learning how to wrap C++ classes in python. I'm following the (out
> of date ?) tutorial and I have this non-working example :

Pierre,

Please check out the updated tutorial in CVS at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/index.html
I think your problems will disappear.

Basically, the problem is no_init; it doesn't really work for abstract
bases and needs to be tuned.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From datafeed at SoftHome.net  Fri Feb 14 00:39:32 2003
From: datafeed at SoftHome.net (M. Evans)
Date: Thu, 13 Feb 2003 16:39:32 -0700
Subject: [C++-sig] PyPython
Message-ID: <1757205691.20030213163932@SoftHome.net>

http://codespeak.net/mailman/listinfo/pypy-dev




From horace_hdsl at seed.net.tw  Fri Feb 14 18:05:52 2003
From: horace_hdsl at seed.net.tw (horace(seednet))
Date: Sat, 15 Feb 2003 01:05:52 +0800
Subject: [C++-sig] MS Visual C++ integrated environment
Message-ID: <001101c2d44b$9cff2dc0$28504ad3@Hopersoft01p4>

I have built one small .pyd file using MS Visual C++ integrated environment, 
my code snippet looks like this :

#include <boost/python.hpp>
using namespace boost::python;
enum choice { red,green,blue};
BOOST_PYTHON_MODULE(_PyTest)
{
 enum_<choice>("choice")
  .value("red",red)
  .value("green",green)
  .value("blue",blue)
 ;
}

However the .pyd file won't work :

>>> import PyTest
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    import PyTest
ImportError: dynamic module does not define init function (initPyTest)
>>> 

What had gone wrong ? Do I have to use bjam to build it ?

I have one bigger project suffers the same error message. In the begining I thought it was something wrong inside the code, however, obviously it wasn't. Help !

Comfortable developing environment will always be my first choice, so do others, I believe. 

Horace


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

From nico_ml at mgdesign.org  Fri Feb 14 18:21:17 2003
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Fri, 14 Feb 2003 18:21:17 +0100
Subject: [C++-sig] MS Visual C++ integrated environment
References: <001101c2d44b$9cff2dc0$28504ad3@Hopersoft01p4>
Message-ID: <005e01c2d44d$7ccee7a0$cb00a8c0@nico>

    Hi,

    no time to check here, but here is my first thought :

> #include <boost/python.hpp>
> using namespace boost::python;
> enum choice { red,green,blue};
> BOOST_PYTHON_MODULE(_PyTest)

    I believe this should be 'BOOST_PYTHON_MODULE(PyTest)' [ no '_' ] if
python really looks after 'initPyTest'.

> {
>  enum_<choice>("choice")
...

    Otherwise, you should verify the symbols exported from your DLL (or
.pyd) and check that there are some symbols exported.
    Anyway, it works fine with VC :)

    Hope this helps,
    Nicolas




From jjl at pobox.com  Sat Feb 15 15:04:34 2003
From: jjl at pobox.com (John J Lee)
Date: Sat, 15 Feb 2003 14:04:34 +0000 (GMT)
Subject: [C++-sig] Wrong python found
Message-ID: <Pine.LNX.4.44.0302151330550.3359-100000@alice>

Would be nice if boost python could find the right python executable on
systems like mine -- I have 2.2 installed, but python is a link to 2.1, so
unless I hack python.jam to set PYTHON = /usr/bin/python2.2 I get link
errors on running the tests.

A PYTHON_BIN would do the trick, but I think if PYTHON_VERSION is set,
/usr/bin/python2.2 should be preferred over /usr/bin/python.


John




From dave at boost-consulting.com  Sat Feb 15 17:31:50 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 15 Feb 2003 11:31:50 -0500
Subject: [C++-sig] Wrong python found
In-Reply-To: <Pine.LNX.4.44.0302151330550.3359-100000@alice> (John J Lee's
 message of "Sat, 15 Feb 2003 14:04:34 +0000 (GMT)")
References: <Pine.LNX.4.44.0302151330550.3359-100000@alice>
Message-ID: <uel698pzd.fsf@boost-consulting.com>

John J Lee <jjl at pobox.com> writes:

> Would be nice if boost python could find the right python executable on
> systems like mine -- I have 2.2 installed, but python is a link to 2.1, so
> unless I hack python.jam to set PYTHON = /usr/bin/python2.2 I get link
> errors on running the tests.

You don't need to (and should not) hack python.jam.

If you have an executable called "python" which is python2.2, it is
probably installed in /usr/python2.2/bin or usr/local/python2.2/bin.
In that case all you need to do is to set PYTHON_ROOT as described
here:

      http://www.boost.org/libs/python/doc/building.html

You can set it in your environment, or you can set it on your bjam
command-line, e.g.:

      bjam -sPYTHON_ROOT=/usr/local/Python2.2 ...

Failing that, you can still set PYTHON on your command-line or in your
environment, e.g.

      bjam -sPYTHON=/usr/bin/python2.2

> A PYTHON_BIN would do the trick, but I think if PYTHON_VERSION is set,
> /usr/bin/python2.2 should be preferred over /usr/bin/python.

I guess so, but where should the smarts stop?  Eventually some
reasonable Python installations will be outside the system's ability
to automatically infer what to do.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From jjl at pobox.com  Sat Feb 15 20:27:05 2003
From: jjl at pobox.com (John J Lee)
Date: Sat, 15 Feb 2003 19:27:05 +0000 (GMT)
Subject: [C++-sig] Wrong python found
In-Reply-To: <uel698pzd.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.44.0302151924500.5941-100000@alice>

On Sat, 15 Feb 2003, David Abrahams wrote:
> John J Lee <jjl at pobox.com> writes:
> > Would be nice if boost python could find the right python executable on
[...]
> You don't need to (and should not) hack python.jam.
[...]
>       bjam -sPYTHON=/usr/bin/python2.2
[...]

Now, I should have guessed that...

Thanks


John




From horace_hdsl at seed.net.tw  Sun Feb 16 06:31:51 2003
From: horace_hdsl at seed.net.tw (horace(seednet))
Date: Sun, 16 Feb 2003 13:31:51 +0800
Subject: [C++-sig] Re: MS Visual C++ integrated environment
References: <20030215170007.24876.91937.Mailman@mail.python.org>
Message-ID: <000d01c2d57c$b5788270$1e514ad3@Hopersoft01p4>

Nicolas Lelong wrote :
>    I believe this should be 'BOOST_PYTHON_MODULE(PyTest)' [ no '_' ] if
>python really looks after 'initPyTest'.
-------------------------------

Yes, Nicolas, you are absolutely right, thanks alot. Finally, I can enojoy
the power of Boost.Python, as well as the comfortableness of MS Visual C++
integrated developing environment.

Regards

Horace






From jochen.heckl at novatrix.de  Mon Feb 17 11:16:28 2003
From: jochen.heckl at novatrix.de (Jochen Heckl)
Date: Mon, 17 Feb 2003 11:16:28 +0100
Subject: [C++-sig] class scope
Message-ID: <CF14EAA21406E746A413044D1F819A4218F906@ntxserv4.novatrix.de>

Hello everybody,
How can I leave a scope while exporting classes.
Entering a scope works fine, but I can't return ro global scope.
I'm using MSVC .net eith the latest version of boost_python.

I have the following code

scope InX = class_< X .....
	;

// from now on every declaration is in  scope X:: - works fine
....

// this should return to global scope - but  does not
scope();

class_< Y ....
	;

// Y is still defined in scope X::. What am I doing wrong ?
// can somebody help please....



Jochen Heckl
NovaTrix GmbH
 
Ettishofer Str. 10C
88250 Weingarten
 
EMail: jochen.heckl at novatrix.de <mailto:jochen.heckl at novatrix.de>
Phone: 0049 (0) 751 50921- 57
Fax: 0049 (0) 751 50921- 31




From nlelong at mgdesign.org  Mon Feb 17 11:29:31 2003
From: nlelong at mgdesign.org (Nicolas Lelong)
Date: Mon, 17 Feb 2003 11:29:31 +0100
Subject: [C++-sig] class scope
References: <CF14EAA21406E746A413044D1F819A4218F906@ntxserv4.novatrix.de>
Message-ID: <002d01c2d66f$75d39670$cb00a8c0@nico>

Hi,

> // this should return to global scope - but  does not
> scope();

Hum, from what I know, this accesses the current scope. When you create a
scope, it lasts as long as the object you created to declare it. So, to go
back in the global scope, you must destroy the scope object you created.

In your case, the follwing code should do it :

{
   scope InX = class_< X .....
   ;
   // from now on every declaration is in  scope X:: - works fine
   ....
}

// now back in global scope
class_< Y ....
;

Cheers,
Nicolas




From nico_ml at mgdesign.org  Tue Feb 18 16:56:41 2003
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Tue, 18 Feb 2003 16:56:41 +0100
Subject: [C++-sig] implicitly_convertible<> & auto_ptr
Message-ID: <00e701c2d766$54831cf0$cb00a8c0@nico>

Hi,

I came to have some needs to are similar to those of Bruce Lowery in
'Inheritance with B/P' thread.
In have a situation like this one:

----

class BigDataBase
{
};

class BigDataDerived : public BigDataBase
{
};

class BigDataStore
{
public:
  void addBigData(char const* name, std::auto_ptr<BigDataBase> data)
  {
  }
};

//[...]

  python::class_<BigDataBase, std::auto_ptr<BigDataBase>,
boost::noncopyable>("BigDataBase", python::no_init);

  python::class_<BigDataDerived, python::bases<BigDataBase>,
std::auto_ptr<BigDataDerived>, boost::noncopyable>("BigDataDerived");

  python::class_<BigDataStore, boost::noncopyable>("BigDataStore")
    .def("addBigData", &BigDataStore::addBigData,
python::with_custodian_and_ward<1,2>() );

----

Whenever I execute the python stuff below, I get the now famous 'bad
argument type for built-in operation' :

      big = BigDataDerived()
      bigstore = BigDataStore()
      bigstore.addBigData('dumb', big)

I catched the David's comment about adding in the module the following
statement, which I thought could save my life :

      'python::implicitly_convertible< std::auto_ptr<BigDataDerived>,
std::auto_ptr<BigDataBase> >();'

Alas, it doesn't compile here under VC7, the compiler complains about :

      'std::auto_ptr<_Ty>::auto_ptr(std::auto_ptr<BigDataDerived> &)' :
cannot convert parameter 1 from 'const std::auto_ptr<_Ty>' to
'std::auto_ptr<_Ty> &'
        with
        [
            _Ty=BigDataBase
        ]
        and
        [
            _Ty=BigDataDerived
        ]
        and
        [
            _Ty=BigDataDerived
        ]
        Conversion loses qualifiers

Can anyone tell me if this compile error is 'normal' or if it's another VC
bug ?
Can anyone point me in a direction that could help solving this transfer of
ownership problem ? I tried to implement
my own specialized type holder, without much success, i must admit...

Thanks in advance
Nicolas




From nickm at sitius.com  Tue Feb 18 17:28:58 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Tue, 18 Feb 2003 11:28:58 -0500
Subject: [C++-sig] Re: implicitly_convertible<> & auto_ptr
References: <00e701c2d766$54831cf0$cb00a8c0@nico>
Message-ID: <3E525F4A.BB0C405F@sitius.com>

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

From nico_ml at mgdesign.org  Tue Feb 18 17:48:58 2003
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Tue, 18 Feb 2003 17:48:58 +0100
Subject: [C++-sig] Re: implicitly_convertible<> & auto_ptr
References: <00e701c2d766$54831cf0$cb00a8c0@nico> <3E525F4A.BB0C405F@sitius.com>
Message-ID: <000501c2d76d$a2030830$cb00a8c0@nico>

> Can't you do it with a wrapper?
> addBigDataDerived(BigDataStore &store, char const* name,
std::auto_ptr<BigDataDerived> data){store.addBigData(name,data);}
>   python::class_<BigDataStore, boost::noncopyable>("BigDataStore")
>     .def("addBigData", &BigDataStore::addBigData,
python::with_custodian_and_ward<1,2>() )
>     .def("addBigData", &addBigDataDerived,
python::with_custodian_and_ward<1,2>() );

Ooops, by the way, it should be "python::with_custodian_and_ward<1,3>()" but
I do wonder if it's really useful because of the auto_ptr stuff already
stating a transfer of ownership.

>
> I know it isn't very convenient, but it may work;

Yep, thanks, that's a valid workaround that will suit my needs for the
moment. I'm still curious about the implicitly_convertible<> stuff.
I have to train to get the 'wrapper reflex' !

> BTW how is this supposed to work:
>       big = BigDataDerived()
>       bigstore = BigDataStore()
>       bigstore.addBigData('dumb', big)
>       big.doSomething()  ///// <- is it going to crash???

I'm not yet very confident with Python & BPL ownership rules, but it seems
that in the above the transfer of ownership is done, and 'big' is no longer
a 'valid reference' to the object transfered. I added a small 'doSomething'
method, and your test case leads to a friendly 'bad argument type for
built-in operation' which, I suppose, indicates the 'big' object is no
longer accessible via the 'big' symbol.





From dave at boost-consulting.com  Wed Feb 19 18:15:27 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 19 Feb 2003 12:15:27 -0500
Subject: [C++-sig] Re: implicitly_convertible<> & auto_ptr
In-Reply-To: <000501c2d76d$a2030830$cb00a8c0@nico> ("Nicolas Lelong"'s
 message of "Tue, 18 Feb 2003 17:48:58 +0100")
References: <00e701c2d766$54831cf0$cb00a8c0@nico>
	<3E525F4A.BB0C405F@sitius.com> <000501c2d76d$a2030830$cb00a8c0@nico>
Message-ID: <uy94c8a4w.fsf@boost-consulting.com>

"Nicolas Lelong" <nico_ml at mgdesign.org> writes:

>> Can't you do it with a wrapper?
>> addBigDataDerived(BigDataStore &store, char const* name,
> std::auto_ptr<BigDataDerived> data){store.addBigData(name,data);}
>>   python::class_<BigDataStore, boost::noncopyable>("BigDataStore")
>>     .def("addBigData", &BigDataStore::addBigData,
> python::with_custodian_and_ward<1,2>() )
>>     .def("addBigData", &addBigDataDerived,
> python::with_custodian_and_ward<1,2>() );
>
> Ooops, by the way, it should be "python::with_custodian_and_ward<1,3>()" but
> I do wonder if it's really useful because of the auto_ptr stuff already
> stating a transfer of ownership.

Not only un-useful, but mistaken.  with_custodian_and_ward<> manages
ownership of Python objects so that it matches non-owning reference
acquisition on the C++ side.  Perhaps it should be called
"acquires_internal_reference" instead.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From paterno at fnal.gov  Thu Feb 20 01:43:29 2003
From: paterno at fnal.gov (Marc Paterno)
Date: Wed, 19 Feb 2003 18:43:29 -0600
Subject: [C++-sig] Problem building boost.python for Cygwin
Message-ID: <PNEFLFGHFHGBIONBBKGCOEGICDAA.paterno@fnal.gov>

I have been attempting to build boost.python on Cygwin, and have
encountered trouble. I hope that someone may be able to diagnose my
problem.

I am using
 Windows 2000 SP3
 Cygwin v1.3.20-1
 GCC 3.2 20020927 (prerelease)
 python 2.2.2 (on Cygwin)
 bjam 3.1.3 for Cygwin


I am performing all builds from a Cygwin (bash) shell.

I have been able to build the thread, signals, and regex libraries, so
I am fairly sure that bjam and gcc are working properly. However, when
I attempt to build boost.python, the build fails.

Specifically, it seems that proper object files get built, in the
directory
  libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
   runtime-link-dynamic/shared-linkable-true/

(I split the directory name over two lines for readability; the name is
not really split.)

However, it seems that building of the dynamic library fails. Here is the
output from running bjam a second time, after the .o files had been
successfully built.

----------
$> bjam -sTOOLS=gcc -sBUILD=release
...patience...
...found 903 targets...
...updating 2 targets...
gcc-Link-action
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru
ntime-link-dynamic/shared-linkable-true/libboost_python.so
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru
ntime-link-dynamic/shared-linkable-true/numeric.o(.text+x320):numeric.cpp:
undefined reference to `_PyExc_ImportError'
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru
ntime-link-dynamic/shared-linkable-true/numeric.o(.text+x33d):numeric.cpp:
undefined reference to `_PyErr_Format'

 ... about 700 similar lines removed ...

../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru
ntime-link-dynamic/shared-linkable-true/object_operators.o(.text+x93f):objec
t_operators.cpp: undefined reference to `_PyNumber_InPlaceXor'
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru
ntime-link-dynamic/shared-linkable-true/object_operators.o(.text+x9ff):objec
t_operators.cpp: undefined reference to `_PyNumber_InPlaceOr'
collect2: ld returned 1 exit status

    export LD_LIBRARY_PATH
    g++   -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"/usr/lib/py
thon2.2/config"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/numeric.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/list.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/long.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/dict.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/tuple.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/str.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/aix_init_module.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/from_python.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/registry.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/type_id.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/enum.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/class.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/function.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/inheritance.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/life_support.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/pickle_support.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/errors.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/module.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/builtin_converters.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/arg_to_python_base.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/iterator.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/object_protocol.o"
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r
untime-link-dynamic/shared-linkable-true/object_operators.o"

...failed gcc-Link-action
../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru
ntime-link-dynamic/shared-linkable-true/libboost_python.so...
...skipped <!libs!python!build!bin-stage>libboost_python.so for lack of
<libs!python!build/libboost_python.so/gcc/release/inlining-on/runtime-link-d
ynamic/shared-linkable-true>libboost_python.so...
...failed updating 1 target...
...skipped 1 target...

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


Here are what I understand are the relevant environment variable
settings I have established:
   PYTHON_ROOT=/usr/lib/python2.2
   PYTHON_INCLUDES=/usr/include/python2.2
   PYTHON_LIB_PATH=/usr/lib/python2.2/config
   PYTHON_STDLIB_PATH=/usr/lib/python2.2
   PYTHON_VERSION=2.2

I am least sure about PYTHON_ROOT and PYTHON_LIB_PATH:
  PYTHON_ROOT is defined such that ${PYTHON_ROOT}/bin/python.exe is
     the full path to the Python executable;
  PYTHON_LIB_PATH is defined such that ${PYTHON_LIB_PATH}/libpython2.2.dll.a
     is the full path to the Python library supplied as a Cygwin 'package'.

I suspect I have one (or more) of these defined wrongly, but haven't been
able to find the right setting to make things go.

Suggestions would be most welcome.

best regards,
Marc




From rwgk at yahoo.com  Thu Feb 20 02:43:09 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 19 Feb 2003 17:43:09 -0800 (PST)
Subject: [C++-sig] Problem building boost.python for Cygwin
In-Reply-To: <PNEFLFGHFHGBIONBBKGCOEGICDAA.paterno@fnal.gov>
Message-ID: <20030220014309.69695.qmail@web20203.mail.yahoo.com>

I am not really familiar with bjam, and even less so with cygwin. But here is a
command line example that works for me under Linux:

bjam -sPYTHON_ROOT=/usr/local_cci/Python-2.2.1 -sPYTHON_VERSION=2.2
-sTOOLS=gcc -sBUILD=debug

Maybe you are just missing the -sPYTHON_* arguments?

Ralf


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com



From dave at boost-consulting.com  Thu Feb 20 18:36:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 20 Feb 2003 12:36:48 -0500
Subject: [C++-sig] Re: implicitly_convertible<> & auto_ptr
In-Reply-To: <uy94c8a4w.fsf@boost-consulting.com> (David Abrahams's message
 of "Wed, 19 Feb 2003 12:15:27 -0500")
References: <00e701c2d766$54831cf0$cb00a8c0@nico>
	<3E525F4A.BB0C405F@sitius.com> <000501c2d76d$a2030830$cb00a8c0@nico>
	<uy94c8a4w.fsf@boost-consulting.com>
Message-ID: <uisve97m7.fsf@boost-consulting.com>

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

> "Nicolas Lelong" <nico_ml at mgdesign.org> writes:
>
>>> Can't you do it with a wrapper?
>>> addBigDataDerived(BigDataStore &store, char const* name,
>> std::auto_ptr<BigDataDerived> data){store.addBigData(name,data);}
>>>   python::class_<BigDataStore, boost::noncopyable>("BigDataStore")
>>>     .def("addBigData", &BigDataStore::addBigData,
>> python::with_custodian_and_ward<1,2>() )
>>>     .def("addBigData", &addBigDataDerived,
>> python::with_custodian_and_ward<1,2>() );
>>
>> Ooops, by the way, it should be "python::with_custodian_and_ward<1,3>()" but
>> I do wonder if it's really useful because of the auto_ptr stuff already
>> stating a transfer of ownership.
>
> Not only un-useful, but mistaken.  with_custodian_and_ward<> manages
> ownership of Python objects so that it matches non-owning reference
> acquisition on the C++ side.  Perhaps it should be called
> "acquires_internal_reference" instead.

BTW, I'm working on a fix for this problem, but until I get there I
have to clear a few bugs that have crept into the CVS recently.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu Feb 20 18:39:24 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 20 Feb 2003 12:39:24 -0500
Subject: [C++-sig] Problem building boost.python for Cygwin
In-Reply-To: <PNEFLFGHFHGBIONBBKGCOEGICDAA.paterno@fnal.gov> (Marc Paterno's
 message of "Wed, 19 Feb 2003 18:43:29 -0600")
References: <PNEFLFGHFHGBIONBBKGCOEGICDAA.paterno@fnal.gov>
Message-ID: <ufzqi97hv.fsf@boost-consulting.com>

Marc Paterno <paterno at fnal.gov> writes:

> Here are what I understand are the relevant environment variable
> settings I have established:
>    PYTHON_ROOT=/usr/lib/python2.2
>    PYTHON_INCLUDES=/usr/include/python2.2
>    PYTHON_LIB_PATH=/usr/lib/python2.2/config
>    PYTHON_STDLIB_PATH=/usr/lib/python2.2
>    PYTHON_VERSION=2.2
>
> I am least sure about PYTHON_ROOT and PYTHON_LIB_PATH:
>   PYTHON_ROOT is defined such that ${PYTHON_ROOT}/bin/python.exe is
>      the full path to the Python executable;
>   PYTHON_LIB_PATH is defined such that ${PYTHON_LIB_PATH}/libpython2.2.dll.a
>      is the full path to the Python library supplied as a Cygwin 'package'.
>
> I suspect I have one (or more) of these defined wrongly, but haven't been
> able to find the right setting to make things go.

Marc,

Did you look at:
http://www.boost.org/libs/python/doc/building.html#configuration?  It
looks like you're missing the Cygwin-related definitions.

Also, are you using a Cygwin-built bjam?  If so, I have not tested
that configuration, and I can't vouch for it.  The one I know works is
to use a regular NT build of bjam and use the "gcc" toolset.

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From paterno at fnal.gov  Fri Feb 21 02:32:42 2003
From: paterno at fnal.gov (Marc Paterno)
Date: Thu, 20 Feb 2003 19:32:42 -0600
Subject: [C++-sig] Re: Problem building boost.python for Cygwin
Message-ID: <PNEFLFGHFHGBIONBBKGCMEGOCDAA.paterno@fnal.gov>

Hello,

Yes, I have read the documentation at
http://www.boost.org/libs/python/doc/building.html#configuration;
that's home I got as far as I did. I have built boost.python with no
problems on Linux. But building for Cygwin has turned out to be much harder.

Previously I was trying to use the Cygwin version of bjam to do the
build; I have now switched to using the Windows version of bjam.

I still do not understand the environment in which I am expected to
work. Should I be running the build from a (Cygwin) bash shell, or
from a Windows command prompt?

The second (working in a Windows command prompt) seems impossible,
because the GCC compiler version I have requires the Cygwin dll to
run; it must be used from a Cygwin command prompt.

If I try the first method, do I need to define the paths in the
environment variables in the Windows manner (because the Windows bjam
will be using them to find files and directories), or should they be
defined in the Cygwin path style, because g++ will be using them to
find files and directories? Or is there a mixture? Below detail my
best guesses, which are clearly still not right.

Finally, although I have read the instructions at the web page listed
above, I still have questions about where the environment variables
should point. This is distinct from, and in addition to, my questions
about *how* they should point there, via Cygwin-style or Windows-style
paths.

1) PYTHON_ROOT : "The root directory of your Python installation"

Is this the directory in which the Python interpreter executable is to
be found? The Windows filename for Cygwin's executable image for the
Python interpreter is c:\cygwin\bin\python2.2.exe. The Cygwin filename
for this file is /bin/python2.2.exe; it is also /usr/bin/python2.2.exe
(my understanding is that Cygwin's internal manipulations make /bin
and /usr/bin identical. When viewed from Windows, the directory
c:\cygwin\usr\bin exists, but is empty). Finally, under Cygwin,
/usr/bin/python is a symbolic link to /usr/bin/python2.2.exe.

I have tried both
  export PYTHON_ROOT=/bin
and
  export PYTHON_ROOT=c:/cygwin/bin
(forward slashes, not backward slashes).


2) PYTHON_VERSION -- even I understand this one. I used
  export PYTHON_VERSION=2.2

3) PYTHON_INCLUDES : "Path to Python #include directories". This
seemed clear, but again I'm not sure if we want a Cygwin or Windows
style path. I guessed Cygwin, because GCC will be passed the
translated value, and GCC needs the Cygwin style pathnames.

  export PYTHON_INCLUDES=/usr/include/python2.2

This is the directory that contains Python.h, as well as many other
headers.

4) PYTHON_LIB_PATH : "Path to Python library object".

I'm guessing that the "Python library object" for Cygwin's Python is
the file /usr/lib/python2.2/config/libpython2.2.dll.a. When I use
SWIG, under Cygwin, this is the file to which I link. My guess is that
GCC will be driving the linker, and that I need to use the Cygwin path
here, so that the linker can find the file. So:

  export PYTHON_LIB_PATH=/usr/lib/python2.2/config

5) PYTHON_STDLIB_PATH : "Path to Python standard library modules".

I'm guessing that this means the directory in which the many .py,
.pyc, and .pyo files for Python's standard library live; it also
contains subdirectories for other standard library modules. I guessed
that again I should use the Cygwin path, but this time is really a
guess, with not much of a reason -- only that so far all the others
have been Cygwin paths as well.

  export PYTHON_STDLIB_PATH=/usr/lib/python2.2

6) CYGWIN_ROOT : "Path to user's Cygwin installation"

Since the Cygwin path would always be trivially "/", it would seem
this must mean the Windows path to the Cygwin root directory.

  export CYGWIN_ROOT=c:/cygwin

I used the forward slash, rather than backward slash, following the
style in the default for PYTHON_ROOT under Windows.

7) GCC_PYTHON_ROOT : "Path to the user's Cygwin Python installation"

Guessing Cygwin or Windows style here was also a bit hard, but since
PYTHON_ROOT was already set to the Cygwin style path, I guessed the
reason for this environment variable was to have a Windows-path
equivalent. So:

  export GCC_PYTHON_ROOT=c:/cygwin/bin

This is the Windows path to the directory in which the Cygwin python
interpreter executable can be found.

8) GCC_DEBUG_PYTHON_ROOT : "Path to the users Cygwin pydebug build"

I have no debug build of Python; I did not build the Python executable
I'm using. I installed the pre-built package supplied by the good folk
at Cygnus.

I left this environment variable undefined, in the hopes that
specifying -sBUILD=release" at the bjam command line would not
actually require the use of this environment variable.

So, with this setup, from a Cygwin bash shell, using the Windows
version of bjam, I try:

  bjam -sTOOLS=gcc -sBUILD=release


As I noted above, I tried both PYTHON_ROOT=c:/cygwin/bin and
PYTHON_ROOT=/bin. Both attempts fail.

With PYTHON_ROOT=c:/cygwin/bin, I get:

build$ bjam -sTOOLS=gcc -sBUILD=release
---------------------------------------------------------------------
skipping Boost.Python library build due to missing or incorrect
configuration
You can configure the location of your python installation by setting:
PYTHON_ROOT    - currently "c:/cygwin/bin"
PYTHON_VERSION - The 2-part python Major.Minor version number (e.g.
                 "2.2", NOT "2.2.1")  - currently "2.2"

The following are automatically configured from PYTHON_ROOT if not
otherwise set:
    GCC_PYTHON_ROOT    - path to Cygwin Python installation; currently
                          "c:/cygwin/bin"
    GCC_PYTHON_DEBUG_ROOT - path to Cygwin debug-python installation
                            (configured --with-pydebug); currently
                          "c:/cygwin/usr/local/pydebug"
    PYTHON_LIB_PATH    - path to Python library; currently
                          "/usr/lib/python2.2/config"
    PYTHON_STDLIB_PATH - path to Python standard library modules; currently
                          "/usr/lib/python2.2"
---------------------------------------------------------------------
...found 8 targets...


and with PYTHON_ROOT=/bin I get the similar (not quite identical)

build$ bjam -sTOOLS=gcc -sBUILD=release
---------------------------------------------------------------------
skipping Boost.Python library build due to missing or incorrect
configuration
You can configure the location of your python installation by setting:
PYTHON_ROOT    - currently "/bin"
PYTHON_VERSION - The 2-part python Major.Minor version number (e.g.
                 "2.2", NOT "2.2.1")  - currently "2.2"

The following are automatically configured from PYTHON_ROOT if not
otherwise set:
    GCC_PYTHON_ROOT    - path to Cygwin Python installation; currently
                          "c:/cygwin/bin"
    GCC_PYTHON_DEBUG_ROOT - path to Cygwin debug-python installation
                            (configured --with-pydebug); currently
                          "c:/cygwin/usr/local/pydebug"
    PYTHON_LIB_PATH    - path to Python library; currently
                          "/usr/lib/python2.2/config"
    PYTHON_STDLIB_PATH - path to Python standard library modules; currently
                          "/usr/lib/python2.2"
---------------------------------------------------------------------
...found 8 targets...

So, clearly I am still doing something wrong. Can someone point out
the incorrect part(s) of my setup?


best regards,
Marc










From dholth at fastmail.fm  Fri Feb 21 06:23:44 2003
From: dholth at fastmail.fm (Daniel Holth)
Date: 21 Feb 2003 00:23:44 -0500
Subject: [C++-sig] special to_python for a particular function
Message-ID: <1045805024.1104.8.camel@Knoppix>

Hi.  I'm using C++ std::strings to hold my 8-bit clean data but the
default to_python converter does not use string.size() to find the
length.  This means I get only up to the first null character back into
Python.  I wound up editing the boost library to fix this and it works
great now, perhaps this bug is fixed in CVS Boost.Python already...

I tried adding a new to_python in my declaration (without editing
Boost.Python) but it seems to insist on using the old one.

How can I have a special to_python for a particular function?  Another
example I don't know how to do is functions that give and take char* and
int separately to mean a string and its length.

Thanks.

- Daniel Holth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030221/a1c6e18e/attachment.pgp>

From nicodemus at globalite.com.br  Fri Feb 21 06:30:58 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 21 Feb 2003 02:30:58 -0300
Subject: [C++-sig] special to_python for a particular function
In-Reply-To: <1045805024.1104.8.camel@Knoppix>
References: <1045805024.1104.8.camel@Knoppix>
Message-ID: <3E55B992.2040801@globalite.com.br>

To answer your second question:

Create a thin wrapper around your function:

void foo(const char* s, int len)
{
    ....
}

void foo_wrapper(std::string s)
{
    foo(s.c_str(), s.size());
}

BOOST_PYTHON_MODULE(foomodule)
{
    def("foo", &foo_wrapper);
}

Hope that helps,
Nicodemus.

Daniel Holth wrote:

>Hi.  I'm using C++ std::strings to hold my 8-bit clean data but the
>default to_python converter does not use string.size() to find the
>length.  This means I get only up to the first null character back into
>Python.  I wound up editing the boost library to fix this and it works
>great now, perhaps this bug is fixed in CVS Boost.Python already...
>
>I tried adding a new to_python in my declaration (without editing
>Boost.Python) but it seems to insist on using the old one.
>
>How can I have a special to_python for a particular function?  Another
>example I don't know how to do is functions that give and take char* and
>int separately to mean a string and its length.
>
>Thanks.
>
>- Daniel Holth
>





From dave at boost-consulting.com  Fri Feb 21 07:19:27 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 21 Feb 2003 01:19:27 -0500
Subject: [C++-sig] special to_python for a particular function
In-Reply-To: <1045805024.1104.8.camel@Knoppix> (Daniel Holth's message of
 "21 Feb 2003 00:23:44 -0500")
References: <1045805024.1104.8.camel@Knoppix>
Message-ID: <uy94aqhow.fsf@boost-consulting.com>

Daniel Holth <dholth at fastmail.fm> writes:

> Hi.  I'm using C++ std::strings to hold my 8-bit clean data but the
> default to_python converter does not use string.size() to find the
> length.  This means I get only up to the first null character back into
> Python.  I wound up editing the boost library to fix this and it works
> great now, perhaps this bug is fixed in CVS Boost.Python already...

Yes it is.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Fri Feb 21 09:11:18 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 21 Feb 2003 03:11:18 -0500
Subject: [C++-sig] Re: Problem building boost.python for Cygwin
In-Reply-To: <PNEFLFGHFHGBIONBBKGCMEGOCDAA.paterno@fnal.gov> (Marc Paterno's
 message of "Thu, 20 Feb 2003 19:32:42 -0600")
References: <PNEFLFGHFHGBIONBBKGCMEGOCDAA.paterno@fnal.gov>
Message-ID: <uu1eyqcih.fsf@boost-consulting.com>

Marc, you might want to skip to the end of this message, then come
back and re-read ;-)

Marc Paterno <paterno at fnal.gov> writes:

> Hello,
>
> Yes, I have read the documentation at
> http://www.boost.org/libs/python/doc/building.html#configuration;
> that's home I got as far as I did. I have built boost.python with no
> problems on Linux. But building for Cygwin has turned out to be much harder.
>
> Previously I was trying to use the Cygwin version of bjam to do the
> build; I have now switched to using the Windows version of bjam.
>
> I still do not understand the environment in which I am expected to
> work. Should I be running the build from a (Cygwin) bash shell, or
> from a Windows command prompt?

Windows command prompt, though bash may work.

> The second (working in a Windows command prompt) seems impossible,
> because the GCC compiler version I have requires the Cygwin dll to
> run; it must be used from a Cygwin command prompt.

Unless it's different from all the different Cygwin GCCs I've used
(and I've used every version from 2.95.3 on), it works just fine from
the NT command prompt.

> If I try the first method, do I need to define the paths in the
> environment variables in the Windows manner (because the Windows bjam
> will be using them to find files and directories), or should they be
> defined in the Cygwin path style, because g++ will be using them to
> find files and directories? Or is there a mixture? Below detail my
> best guesses, which are clearly still not right.

It doesn't matter; both bjam and g++ are insensitive to path style.

Here's what I do to build with the Python and the g++ (3.2) that's
currently installed by default with Cygwin:

    set PYTHON_ROOT=c:/tools/python-2.2.2
    set CYGWIN_ROOT=c:/cygwin
    set GCC_PYTHON_ROOT=/usr
    bjam -sTOOLS=gcc

The first line actually points to my regular Windows Python
installation, but when I'm building with GCC that's just there to keep
bjam happy; What's really important is that the PYTHON_STDLIB_PATH,
which defaults to $(PYTHON_ROOT)/Lib, has at least one .py file in it.

> Finally, although I have read the instructions at the web page listed
> above, I still have questions about where the environment variables
> should point. This is distinct from, and in addition to, my questions
> about *how* they should point there, via Cygwin-style or Windows-style
> paths.

This is really a mess for Cygwin-only users.  I'm sorry about it, but
I'll try to explain it well.

> 1) PYTHON_ROOT : "The root directory of your Python installation"
>
> Is this the directory in which the Python interpreter executable is to
> be found? 

Only if you also have a regular windows installation.  If you're just
building with Cygwin GCC it doesn't matter how you set this.

> 2) PYTHON_VERSION -- even I understand this one. I used
>   export PYTHON_VERSION=2.2

Yeah; the default also works so you can leave this one out.

> 3) PYTHON_INCLUDES : "Path to Python #include directories". This
> seemed clear, but again I'm not sure if we want a Cygwin or Windows
> style path. I guessed Cygwin, because GCC will be passed the
> translated value, and GCC needs the Cygwin style pathnames.
>
>   export PYTHON_INCLUDES=/usr/include/python2.2

It doesn't matter what style you use, and PYTHON_INCLUDES isn't used
when building from Windows.  For Cygwin, you want GCC_PYTHON_ROOT to
point two directories above this one.

> This is the directory that contains Python.h, as well as many other
> headers.
>
> 4) PYTHON_LIB_PATH : "Path to Python library object".
>
> I'm guessing that the "Python library object" for Cygwin's Python is
> the file /usr/lib/python2.2/config/libpython2.2.dll.a. When I use
> SWIG, under Cygwin, this is the file to which I link. My guess is that
> GCC will be driving the linker, and that I need to use the Cygwin path
> here, so that the linker can find the file. So:
>
>   export PYTHON_LIB_PATH=/usr/lib/python2.2/config

This will be derived from GCC_PYTHON_ROOT, but it's fine to set it
that way.

> 5) PYTHON_STDLIB_PATH : "Path to Python standard library modules".
>
> I'm guessing that this means the directory in which the many .py,
> .pyc, and .pyo files for Python's standard library live; it also
> contains subdirectories for other standard library modules. I guessed
> that again I should use the Cygwin path, but this time is really a
> guess, with not much of a reason -- only that so far all the others
> have been Cygwin paths as well.
>
>   export PYTHON_STDLIB_PATH=/usr/lib/python2.2

As I said, for Cygwin this just has to be any directory with a .py
file in it :(

> 6) CYGWIN_ROOT : "Path to user's Cygwin installation"
>
> Since the Cygwin path would always be trivially "/", it would seem
> this must mean the Windows path to the Cygwin root directory.
>
>   export CYGWIN_ROOT=c:/cygwin
>
> I used the forward slash, rather than backward slash, following the
> style in the default for PYTHON_ROOT under Windows.

Either way will work.

> 7) GCC_PYTHON_ROOT : "Path to the user's Cygwin Python installation"
>
> Guessing Cygwin or Windows style here was also a bit hard, but since
> PYTHON_ROOT was already set to the Cygwin style path, I guessed the
> reason for this environment variable was to have a Windows-path
> equivalent. So:
>
>   export GCC_PYTHON_ROOT=c:/cygwin/bin
>
> This is the Windows path to the directory in which the Cygwin python
> interpreter executable can be found.

stick with /usr or c:/cygwin/usr

> 8) GCC_DEBUG_PYTHON_ROOT : "Path to the users Cygwin pydebug build"
>
> I have no debug build of Python; I did not build the Python executable
> I'm using. I installed the pre-built package supplied by the good folk
> at Cygnus.
>
> I left this environment variable undefined, in the hopes that
> specifying -sBUILD=release" at the bjam command line would not
> actually require the use of this environment variable.

That's fine, and it also works for -sBUILD=debug.  Only if you do
-sBUILD=debug-python will it fail.

> So, with this setup, from a Cygwin bash shell, using the Windows
> version of bjam, I try:

   <snip>

As I said, I've suceeded with this only from an NT shell.  Well, hey,
let me try from a Cygwin shell:

$ cd $BOOST_ROOT/tools/build/jam_src
$ ./build.sh
  ...
$ export PATH=$BOOST_ROOT/tools/build/jam_src/bin.cygwinx86:$PATH
$ cd $BOOST_ROOT/libs/python/test
$ bjam test

<lots and lots of bugfixes, etc.>

It works!

You'll need to checkout the latest CVS; you might want to look at the
updated building docs as well.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From horace_hdsl at seed.net.tw  Fri Feb 21 13:50:02 2003
From: horace_hdsl at seed.net.tw (horace(seednet))
Date: Fri, 21 Feb 2003 20:50:02 +0800
Subject: [C++-sig] How to wrap this overloaded member function whose  return type is reference ?
Message-ID: <000701c2d9a7$c08e6b00$17703b3d@hopersoft.com.tw>

I have one trouble class need to be wrapped, the code snippet looks like
this :

class point3d
{
public:
    point3d();
    point3d(const point3d& pnt);
    point3d(double x, double y, double z);
    point3d&   set(double x, double y, double z);
    point3d&   set(const point3d& pnt);
    static const  point3d    origin;
    double x, y, z;
};

This is what I have done :

BOOST_PYTHON_MODULE(test)
{
 class_<point3d>("point3d")
    .def(init<>())    // compiles ok
    .def(init<const point3d&>() // compiles ok
    .def(init<double,double,double>(args("x", "y", "z"))) // compiles ok
// troublesome lines
    .def("set",(point3d& (point3d::*)(double, double, double))
point3d::set,args("x", "y", "z")) // this line doesn't compile
    .def("set",(point3d& (point3d::*)(const point3d& )) point3d::set) //
this line doesn't compile
    .def_readonly("origin",&point3d::origin)   // this line doesn't compile
//
    .def_readwrite("x",&point3d::x) // compiles ok
    .def_readwrite("y",&point3d::y) // compiles ok
    .def_readwrite("z",&point3d::z) // compiles ok
 ;
}
The code don't compile. I can locate lines that cause the trouble, as shown
above, but I don't know why.
If I just comment those troublesome lines out, everything is fine,  however
I don't like to play ostrich all the time.
Can anybody be so kind to tell me how to do it, or what's wrong in the code
I have written ?

Horace





From dave at boost-consulting.com  Fri Feb 21 19:31:18 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 21 Feb 2003 13:31:18 -0500
Subject: [C++-sig] How to wrap this overloaded member function whose 
 return type is reference ?
In-Reply-To: <000701c2d9a7$c08e6b00$17703b3d@hopersoft.com.tw> ("horace\'s
 message of "Fri, 21 Feb 2003 20:50:02 +0800")
References: <000701c2d9a7$c08e6b00$17703b3d@hopersoft.com.tw>
Message-ID: <u7kbtiiyx.fsf@boost-consulting.com>

"horace\(seednet\)" <horace_hdsl at seed.net.tw> writes:

> I have one trouble class need to be wrapped, the code snippet looks like
> this :
>

<snip>

> The code don't compile. I can locate lines that cause the trouble, as shown
> above, but I don't know why.

Can you post the error message(s) you get?  That would be a nice start.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From horace_hdsl at seed.net.tw  Sat Feb 22 18:05:33 2003
From: horace_hdsl at seed.net.tw (horace(seednet))
Date: Sun, 23 Feb 2003 01:05:33 +0800
Subject: [C++-sig] Re : How to wrap this overloaded member function whose  return type is reference ?
Message-ID: <000c01c2da94$9cd895d0$17703b3d@hopersoft.com.tw>

Dave Abrahams wrote :

> Can you post the error message(s) you get?  That would be a nice start.

Ok, Dave, If you want to see those error messages, here you go. Last time I thought it wasn't too polite to dump those lengthy error messages here.

for this line of code :

  .def_readonly("origin",&point3d::origin)

I got 

D:\test\point3d.cpp(6) : error C2784: 'class boost::python::class_<class point3d,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified> &__thiscall 
boost::python::class_<class point3d,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified>::def_readonly(const char *, point3d::*)' : could not deduce template argument for ' point3d::*' from 'const class point3d *'


for this line of code  :

  .def("set",(point3d& (point3d::*)(double, double, double)) point3d::set,args("x", "y", "z")) 

I got 

d:\boost_1_29_0\boost/python/detail/returning.hpp(175) : error C2079: 'cr' uses undefined struct 'specify_a_result_policy_to_wrap_functions_returning<class point3d &>'
        d:\boost_1_29_0\boost/python/detail/caller.hpp(100) : see reference to function template instantiation 'struct _object *__cdecl boost::python::detail::returning<class point3d &>::call(class point3d &(__thiscall point3d::*)(double
,double,double),struct _object *,struct _object *,const struct boost::python::default_call_policies *)' being compiled
d:\boost_1_29_0\boost/python/detail/returning.hpp(176) : error C2228: left of '.convertible' must have class/struct/union type
        d:\boost_1_29_0\boost/python/detail/caller.hpp(100) : see reference to function template instantiation 'struct _object *__cdecl boost::python::detail::returning<class point3d &>::call(class point3d &(__thiscall point3d::*)(double
,double,double),struct _object *,struct _object *,const struct boost::python::default_call_policies *)' being compiled
d:\boost_1_29_0\boost/python/detail/returning.hpp(181) : error C2064: term does not evaluate to a function
        d:\boost_1_29_0\boost/python/detail/caller.hpp(100) : see reference to function template instantiation 'struct _object *__cdecl boost::python::detail::returning<class point3d &>::call(class point3d &(__thiscall point3d::*)(double
,double,double),struct _object *,struct _object *,const struct boost::python::default_call_policies *)' being compiled
Error executing cl.exe.

I think my problem in using Boost.Python is that I don't know what I'm doing.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030223/d2709c49/attachment.htm>

From dave at boost-consulting.com  Sat Feb 22 18:42:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 22 Feb 2003 12:42:22 -0500
Subject: [C++-sig] Re : How to wrap this overloaded member function
 whose  return type is reference ?
In-Reply-To: <000c01c2da94$9cd895d0$17703b3d@hopersoft.com.tw> ("horace\'s
 message of "Sun, 23 Feb 2003 01:05:33 +0800")
References: <000c01c2da94$9cd895d0$17703b3d@hopersoft.com.tw>
Message-ID: <uof54dxfl.fsf@boost-consulting.com>

"horace\(seednet\)" <horace_hdsl at seed.net.tw> writes:

> Dave Abrahams wrote :
>
>> Can you post the error message(s) you get?  That would be a nice start.
>
> Ok, Dave, If you want to see those error messages, here you go. Last
> time I thought it wasn't too polite to dump those lengthy error
> messages here.

The ones you've got below aren't too lengthy ;-)

> for this line of code :
>
>   .def_readonly("origin",&point3d::origin)
>
> I got 
>
> D:\test\point3d.cpp(6) : error C2784: 'class
> boost::python::class_<class point3d,struct
> boost::python::detail::not_specified,struct
> boost::python::detail::not_specified,struct
> boost::python::detail::not_specified> &__thiscall
> boost::python::class_<class point3d,struct
> boost::python::detail::not_specified,struct
> boost::python::detail::not_specified,struct
> boost::python::detail::not_specified>::def_readonly(const char *,
> point3d::*)' : could not deduce template argument for ' point3d::*'
> from 'const class point3d *'

OK, the problem here is that point3d::origin is not a regular data
member.  A static data member acts just like an ordinary variable, so
the type of &point3d::origin is not

    point3d const point3d::*

but

    point3d const*

I don't have a way of enabling you to restrict modification, but one
easy way to deal with this is:

    object class_point3d
      = class_<point3d>("point3d")
         .def(init<>())    // compiles ok
         .def(init<const point3d&>() // compiles ok
         .def(init<double,double,double>(args("x", "y", "z")))
         ...
         ;

    class_point3d.attr("origin") = point3d::origin;


> for this line of code  :
>
>   .def("set",(point3d& (point3d::*)(double, double, double)) point3d::set,args("x", "y", "z")) 
>
> I got 
>
> d:\boost_1_29_0\boost/python/detail/returning.hpp(175) : error
> C2079: 'cr' uses undefined struct
> 'specify_a_result_policy_to_wrap_functions_returning<class point3d &>'
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That should be a big clue.  Have you read about CallPolicies?

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

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

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

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

> I think my problem in using Boost.Python is that I don't know what I'm doing.  

Possibly; If so I hope that my reply will help to correct that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Sat Feb 22 19:16:30 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 22 Feb 2003 13:16:30 -0500
Subject: [C++-sig] Re: implicitly_convertible<> & auto_ptr
In-Reply-To: <uisve97m7.fsf@boost-consulting.com> (David Abrahams's message
 of "Thu, 20 Feb 2003 12:36:48 -0500")
References: <00e701c2d766$54831cf0$cb00a8c0@nico>
	<3E525F4A.BB0C405F@sitius.com> <000501c2d76d$a2030830$cb00a8c0@nico>
	<uy94c8a4w.fsf@boost-consulting.com> <uisve97m7.fsf@boost-consulting.com>
Message-ID: <ulm08dvup.fsf@boost-consulting.com>

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

> BTW, I'm working on a fix for this problem, but until I get there I
> have to clear a few bugs that have crept into the CVS recently.

It's checked in now; please try it out and let me know how it goes.

Thanks,
Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Sat Feb 22 20:03:41 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 22 Feb 2003 16:03:41 -0300
Subject: [C++-sig] Re : How to wrap this overloaded member function whose
  return type is reference ?
In-Reply-To: <uof54dxfl.fsf@boost-consulting.com>
References: <000c01c2da94$9cd895d0$17703b3d@hopersoft.com.tw> <uof54dxfl.fsf@boost-consulting.com>
Message-ID: <3E57C98D.6010706@globalite.com.br>

Hi David,

David Abrahams wrote:

>OK, the problem here is that point3d::origin is not a regular data
>member.  A static data member acts just like an ordinary variable, so
>the type of &point3d::origin is not
>
>    point3d const point3d::*
>
>but
>
>    point3d const*
>
>I don't have a way of enabling you to restrict modification, but one
>easy way to deal with this is:
>
>    object class_point3d
>      = class_<point3d>("point3d")
>         .def(init<>())    // compiles ok
>         .def(init<const point3d&>() // compiles ok
>         .def(init<double,double,double>(args("x", "y", "z")))
>         ...
>         ;
>
>    class_point3d.attr("origin") = point3d::origin;
>

I will join the discussion, since I'm having a similar problem. 8)

I'm trying to do that to export static members, but it does not work 
correctly.

    struct C
    {
        static double x;
    };      
    double C::x = 10;

    double get_x()
    {
        return C::x;
    }

    // Module 
======================================================================
    BOOST_PYTHON_MODULE(boost)
    {
        object C_scope =
        class_< C >("C", init< const C & >())
            .def(init<  >())
        ;
        C_scope.attr("x") = C::x;
   
        def("get_x", &get_x);
    }


 From python:

    >>> from boost import *
    >>> C.x
    10.0
    >>> C.x = 3.4
    >>> C.x
    3.9999999999
    >>> get_x()
    10.0
   

The x static member is not being updated in the C++ side, which seems 
obvious, since the call
   
    C_scope.attr("x") = C::x;

is passing C::x by value. I tried this instead

    C_scope.attr("x") = &C::x;

in the hopes that it would now update the variable correctly, but from 
python:

    >>> from boost import *
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: No to_python (by-value) converter found for C++ type: double

which is also obvious: I am declaring the attribute x as a double*, and 
boost.python doesn't know how to handle a double*.

So, how can I get the correct behaviour?

Thanks,
Nicodemus.






From dave at boost-consulting.com  Sat Feb 22 23:40:17 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 22 Feb 2003 17:40:17 -0500
Subject: [C++-sig] Re : How to wrap this overloaded member function
 whose return type is reference ?
In-Reply-To: <3E57C98D.6010706@globalite.com.br> (Nicodemus's message of
 "Sat, 22 Feb 2003 16:03:41 -0300")
References: <000c01c2da94$9cd895d0$17703b3d@hopersoft.com.tw>
	<uof54dxfl.fsf@boost-consulting.com> <3E57C98D.6010706@globalite.com.br>
Message-ID: <uk7fsc52m.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Hi David,
>
<snip>

> I will join the discussion, since I'm having a similar problem. 8)
>
> I'm trying to do that to export static members, but it does not work
> correctly.
>
>     struct C
>     {
>         static double x;
>     };        double C::x = 10;
>
>     double get_x()
>     {
>         return C::x;
>     }
>
>     // Module
>     ======================================================================
>     BOOST_PYTHON_MODULE(boost)
>     {
>         object C_scope =
>         class_< C >("C", init< const C & >())
>             .def(init<  >())
>         ;
>         C_scope.attr("x") = C::x;
>          def("get_x", &get_x);
>     }
>
>
>  From python:
>
>     >>> from boost import *
>     >>> C.x
>     10.0
>     >>> C.x = 3.4
>     >>> C.x
>     3.9999999999
>     >>> get_x()
>     10.0
>    The x static member is not being updated in the C++ side, which
>    seems obvious, since the call
>      C_scope.attr("x") = C::x;
>
> is passing C::x by value. I tried this instead
>
>     C_scope.attr("x") = &C::x;
>
> in the hopes that it would now update the variable correctly, but from
> python:
>
>     >>> from boost import *
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     TypeError: No to_python (by-value) converter found for C++ type: double
>
> which is also obvious: I am declaring the attribute x as a double*,
> and boost.python doesn't know how to handle a double*.
>
> So, how can I get the correct behaviour?

Well, if x were a class you could do:

   C_scope.attr("x") = boost::ref(C::x);

Which would wrap a reference to x.  Unfortunately, you have another
problem: x is a double, and Python already has a type for
double... which is immutable.

The solution is to use a property to intercept attribute reads and
assignments, so that we can programmatically set C::x:

[ You should read http://www.python.org/2.2.2/descrintro.html and
  http://www.python.org/peps/pep-0252.html if you haven't already.
  Why they can't get this material into the regular Python docs is
  beyond me
]

  >>> #define a property class
  ... class Prop(object):
  ...     def __get__(self, obj, type=None):
  ...         print '__get__', (self, obj, type)
  ...         return 'value'
  ...
  ...     def __set__(self, obj, type=None):
  ...         print '__set__', (self, obj, type)
  ...
  ...     def __delete__(self, obj, type=None):
  ...         print '__delete__', (self, obj, type)
  ...
  >>> # use it in a class C
  ... class C(object):
  ...     x = Prop()
  ...
  >>> a = C()

  >>> a.x # all accesses to a.x are intercepted
  __get__ (<__main__.Prop object at 0x00877BC8>, <__main__.C object at 0x00878108>, <class '__main__.C'>)
  'value'
  >>> a.x = 42 
  __set__ (<__main__.Prop object at 0x00877BC8>, <__main__.C object at 0x00878108>, 42)

  >>> C.x # Prop intercepts reads of the class attribute
  __get__ (<__main__.Prop object at 0x00877BC8>, None, <class '__main__.C'>)
  'value'
  >>> C.x = 1 # But not assignments
  >>> C.x
  1

  >>> class mc(object.__class__): # to intercept C.x assignment
  ...     x = Prop()              # I have to define this
  ...
  >>> class C(object):
  ...     __metaclass__ = mc
  ...
  >>> C.x # now all accesses to C.x are intercepted
  __get__ (<__main__.Prop object at 0x00876AB8>, <class '__main__.C'>, <class '__main__.mc'>)
  'value'
  >>> C.x = 1
  __set__ (<__main__.Prop object at 0x00876AB8>, <class '__main__.C'>, 1)
  >>> a = C() # But not accesses to a.x
  >>> a.x
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  AttributeError: 'C' object has no attribute 'x'
  >>>

As you can see, the only way to intercept assignment to C.x is to
stick a property C's class, i.e. the metaclass (or to modify
__setattr__ in the metaclass, but it amounts to the same thing).  In
fact, to fully emulate the C++ syntaxes of:

      C::x = 1;
  and
      a.x = 1;

We need a property in both the metaclass and in the class.

This leaves us with two options, both of which involve changing
Boost.Python's C++ source:

  option 1:
    introduce a new metaclass for every wrapped class so that we have a
    place to stick a property object.

    option 1a:
        only do this if the user supplies a special extra template
        parameter to the class_<...> declaration

  option 2:
    Implement a special property type which allows us to easily
    identify property attributes which correspond to Boost.Python static
    data members

    Implement a special __setattr__ in the Boost.Python metaclass which
    looks up the attribute on the class to see if it has this special
    type; if so, it is called, and otherwise the default __setattr__
    behavior takes effect.

I guess I prefer option 1: it favors speed and code size over data
size.  The only downside I can see is that an extra object (the
metaclass object) is created for every wrapped class.  It's also
simpler to implement.

Thoughts?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nlelong at mgdesign.org  Mon Feb 24 11:13:01 2003
From: nlelong at mgdesign.org (Nicolas Lelong)
Date: Mon, 24 Feb 2003 11:13:01 +0100
Subject: [C++-sig] Re: implicitly_convertible<> & auto_ptr
References: <00e701c2d766$54831cf0$cb00a8c0@nico><3E525F4A.BB0C405F@sitius.com> <000501c2d76d$a2030830$cb00a8c0@nico><uy94c8a4w.fsf@boost-consulting.com> <uisve97m7.fsf@boost-consulting.com> <ulm08dvup.fsf@boost-consulting.com>
Message-ID: <006f01c2dbed$50123da0$cb00a8c0@nico>

Hi,

> David Abrahams <dave at boost-consulting.com> writes:
>
> > BTW, I'm working on a fix for this problem, but until I get there I
> > have to clear a few bugs that have crept into the CVS recently.
>
> It's checked in now; please try it out and let me know how it goes.

It's OK, the 'python::implicitly_convertible< std::auto_ptr<BigDataDerived>,
std::auto_ptr<BigDataBase> >();' now compiles fine under VC7,
and I can correctly transfer the ownership of Derived classes.

Thanks once more,
Regards,
Nicolas




From paterno at fnal.gov  Mon Feb 24 16:55:52 2003
From: paterno at fnal.gov (Marc Paterno)
Date: Mon, 24 Feb 2003 09:55:52 -0600
Subject: [C++-sig] Re: Problem building boost.python for Cygwin
In-Reply-To: <uu1eyqcih.fsf@boost-consulting.com>
Message-ID: <PNEFLFGHFHGBIONBBKGCKEHECDAA.paterno@fnal.gov>

Hi David et al.,

Success!

Thanks for dealing with this problem promptly. I now have
a purely-Cygwin build of boost.python, which has passed a
couple of (simple) usage tests.

David, the new instructions (from the head of CVS as of
Saturday) were much clearer. I think there is one typo
in the instructions. In the table in the section "Configuration",
the environment variable CYGWIN_PYTHON_ROOT appears in
the VARIABLE NAME column twice. I suspect the first should
be CYGWIN_PYTHON_INCLUDES instead; at least things worked when
I guessed this was the intended name.

Finally, I *think* I understand better at least one source of 
confusion between us. In my configuration, I can not use
g++ from a Windows command prompt. As soon as the compiler 
tries to open a file, it fails with a "can't find cygwin1.dll"
dialog box. I suspect that David's PATH, under Windows, includes
a directory that contains the Cygwin DLL, and perhaps it even
contains the Cygwin '/bin' directory.

However, following the most recent instructions, I was able to
build everything from a Cygwin bash shell, using the Cygwin build
of bjam, and Cygwin's distribution of Python.

Thanks again, David, for the prompt support.

best regards,
Marc



From dave at boost-consulting.com  Mon Feb 24 18:07:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 24 Feb 2003 12:07:59 -0500
Subject: [C++-sig] Re: Problem building boost.python for Cygwin
In-Reply-To: <PNEFLFGHFHGBIONBBKGCKEHECDAA.paterno@fnal.gov> (Marc Paterno's
 message of "Mon, 24 Feb 2003 09:55:52 -0600")
References: <PNEFLFGHFHGBIONBBKGCKEHECDAA.paterno@fnal.gov>
Message-ID: <u4r6tk3o0.fsf@boost-consulting.com>

Marc Paterno <paterno at fnal.gov> writes:

> Hi David et al.,
>
> Success!
>
> Thanks for dealing with this problem promptly. I now have
> a purely-Cygwin build of boost.python, which has passed a
> couple of (simple) usage tests.
>
> David, the new instructions (from the head of CVS as of
> Saturday) were much clearer. I think there is one typo
> in the instructions. In the table in the section "Configuration",
> the environment variable CYGWIN_PYTHON_ROOT appears in
> the VARIABLE NAME column twice. I suspect the first should
> be CYGWIN_PYTHON_INCLUDES instead; at least things worked when
> I guessed this was the intended name.

Thanks for noticing that!  Actually, the first one is correct and the
second one is just old flotsam I should've deleted.  Defining
CYGWIN_PYTHON_INCLUDES doesn't do anything at all.  Please check to be
sure that your CYGWIN_PYTHON_ROOT points to a directory containing
include/python$(PYTHON_VERSION)/python.h, and report back to me.

> Finally, I *think* I understand better at least one source of 
> confusion between us. In my configuration, I can not use
> g++ from a Windows command prompt. As soon as the compiler 
> tries to open a file, it fails with a "can't find cygwin1.dll"
> dialog box. I suspect that David's PATH, under Windows, includes
> a directory that contains the Cygwin DLL, and perhaps it even
> contains the Cygwin '/bin' directory.

Ah, yes it does.  I keep those things in my path because they're just
too useful to live without ;-)

> However, following the most recent instructions, I was able to
> build everything from a Cygwin bash shell, using the Cygwin build
> of bjam, and Cygwin's distribution of Python.

That was something I did explicitly, because it seemed like it should
be possible for people like you ;-)

> Thanks again, David, for the prompt support.

You're most welcome.

-Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From camelo at esss.com.br  Mon Feb 24 22:08:40 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Mon, 24 Feb 2003 18:08:40 -0300
Subject: [C++-sig] Problem compiling with Intel/VC7
In-Reply-To: <F129rf3yXvEbjkyqU7a0002ef09@hotmail.com>
Message-ID: <000001c2dc48$e9403350$0d00000a@esss.com.br>

Hi!!!

I've have just checked-out boost from the CVS repository
and I'm trying to build it with bjam for the first time.

I'm using the Intel 6.0 compiler, along with the VC7 
toolset.

This is the command line I am using:

bjam -sTOOLS=intel-win32 "-sINTEL_BASE_MSVC_TOOLSET=vc7"
"-sVC7_ROOT=C:\Program Files\Microsoft Visual Studio .NET\VC7"
"-sINTELC=C:\Program Files\Intel\Compiler60\IA32"
"-sPYTHON_ROOT=c:\Bin\Python22"

Despite of this, bjam is still trying to use the VC6 
include path (that doesn't exist in my machine):

 -I"C:\Program Files\Microsoft Visual Studio\VC98\include"

As expected, the icl isn't finding some basic include
files (limits.h, utility, etc). 

Can you see anything wrong or missing in the command line
I'm using? Is there any way to force bjam to add the correct 
VC7 include path?

Thank you,

Marcelo A. Camelo





From dave at boost-consulting.com  Mon Feb 24 22:44:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 24 Feb 2003 16:44:48 -0500
Subject: [C++-sig] Problem compiling with Intel/VC7
In-Reply-To: <000001c2dc48$e9403350$0d00000a@esss.com.br> ("Marcelo A.
 Camelo"'s message of "Mon, 24 Feb 2003 18:08:40 -0300")
References: <000001c2dc48$e9403350$0d00000a@esss.com.br>
Message-ID: <uwujpgxpr.fsf@boost-consulting.com>

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

> Hi!!!
>
> I've have just checked-out boost from the CVS repository
> and I'm trying to build it with bjam for the first time.
>
> I'm using the Intel 6.0 compiler, along with the VC7 
> toolset.
>
> This is the command line I am using:
>
> bjam -sTOOLS=intel-win32 "-sINTEL_BASE_MSVC_TOOLSET=vc7"
> "-sVC7_ROOT=C:\Program Files\Microsoft Visual Studio .NET\VC7"
> "-sINTELC=C:\Program Files\Intel\Compiler60\IA32"
> "-sPYTHON_ROOT=c:\Bin\Python22"
>
> Despite of this, bjam is still trying to use the VC6 
> include path (that doesn't exist in my machine):
>
>  -I"C:\Program Files\Microsoft Visual Studio\VC98\include"
>
> As expected, the icl isn't finding some basic include
> files (limits.h, utility, etc). 
>
> Can you see anything wrong or missing in the command line
> I'm using? Is there any way to force bjam to add the correct 
> VC7 include path?

Is MSVCDir set in your environment?  If so, it appears VC7_ROOT will
be ignored.  I think that's probably a mistake, but I don't want to
try to change it this close to branching for a release.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon Feb 24 23:03:23 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 24 Feb 2003 17:03:23 -0500
Subject: [C++-sig] Re: C++ object from PyObject pointer
In-Reply-To: <b3ao9k+kj5g@eGroups.com> ("mghiggins's message of "Sun, 23 Feb
 2003 15:10:44 -0000")
References: <b3ao9k+kj5g@eGroups.com>
Message-ID: <uptphgwus.fsf@boost-consulting.com>

The following message is a courtesy copy of an article
that has been posted to gmane.comp.lib.boost.user as well.

"mghiggins <mghiggins at yahoo.com>" <mghiggins at yahoo.com> writes:

> Excuse my newbiness if this question is too dumb... :)
>
> I've built a python extension from a C++ class using boost - it all
> seems to work fine.
>
> However, now another C++ function is receiving a pointer to a PyObject
> that represents an instance of this "boosted" python class. How do I
> pick off a pointer to the underlying C++ object from the PyObject
> pointer?

Boost.Python questions to the c++-sig, please!

  http://www.python.org/sigs/c++-sig/

Your answer:

  void f(PyObject* p)
  {
     handle<> ph(borrowed(p));
     MyObj* op = extract<MyObj*>(object(ph));
  }

HTH,
Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue Feb 25 06:45:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 25 Feb 2003 00:45:21 -0500
Subject: [C++-sig] Re: boost.python answer - thanks!
In-Reply-To: <b3eptk+8ahl@eGroups.com> ("mghiggins's message of "Tue, 25 Feb
 2003 04:03:00 -0000")
References: <b3eptk+8ahl@eGroups.com>
Message-ID: <uheasewwe.fsf@boost-consulting.com>

"mghiggins <mghiggins at yahoo.com>" <mghiggins at yahoo.com> writes:

> Thanks, that helped a lot!

As I asked you before, please post your Boost.Python questions to the
C++-sig.

> Another perhaps more basic question: how do I pass a python function
> object to a C++ method and use it internally? e.g., if I have a class
>
> class Passer
> {
>  public:
>    Passer() {};
>    void setx( dict x ) { this->m_x = x; };
>    void setf( object f ) { this->m_f = f; };
>    double val();
>    double xval() { return extract<double>( m_x['v'] ); };
>
>  private:
>    dict   m_x;
>    object m_f;
> };
>
> double Passer::val()
> {
>    PyObject * f   = m_f.ptr();
>    PyObject * ret = PyEval_CallObject( f, m_x.ptr() );


why not just

     object ret = m_f(m_x);

??

>    double RetVal;
>    if( ret )
>       RetVal = 1;
>    else
>       RetVal = -1;
>
>    PyArg_Parse( ret, "(f)", &RetVal );
>    return RetVal;
> }

I don't know what your PyArg_Parse thing is supposed to be doing. I'm
not really sure what all of that 1/-1 stuff is about either.  Is
RetVal a tuple of one element?  Maybe you want:

 double Passer::val()
 {
     return m_f(m_x)[0];
 }

> The setx method seems to work fine with a dictionary like {'v':4} and
> the xval method returns its 'v' element properly.
>
> But the setf method doesn't seem to work correctly... when I call
> val() from python after setting on a function, PyObject * ret comes
> back NULL (which I learn from getting RetVal == -1 as a return value).

That might just mean that f raised a Python exception.  You're
masking the problem by returning -1 instead of using the Boost.Python
facilities which propagate the Python exception through your C++ code
and back to Python.

> I'm sure I'm doing something dumb by making the type of setf's arg be
> "object" rather than something specifying a function, but I don't know
> what. :) Anything obvious I'm missing here?

The only dumb-ish thing is using the raw Python 'C' API instead of
what Boost.Python gives you.  Try the simple approach I outlined
above; it might be revealing.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From mghiggins at yahoo.com  Tue Feb 25 06:50:43 2003
From: mghiggins at yahoo.com (Mark Higgins)
Date: Mon, 24 Feb 2003 21:50:43 -0800 (PST)
Subject: [C++-sig] Re: boost.python answer - thanks!
In-Reply-To: <uheasewwe.fsf@boost-consulting.com>
Message-ID: <20030225055043.74546.qmail@web13902.mail.yahoo.com>

Yup, defining

double Passer::val()
{
   object ret = m_f( m_x );
   return extract<double>( ret );
}

works like a charm. Thanks! I didn't realise the boost API was
as clean and complete as it apparently is.


--- David Abrahams <dave at boost-consulting.com> wrote:
> "mghiggins <mghiggins at yahoo.com>" <mghiggins at yahoo.com>
> writes:
> 
> > Thanks, that helped a lot!
> 
> As I asked you before, please post your Boost.Python questions
> to the
> C++-sig.
> 
> > Another perhaps more basic question: how do I pass a python
> function
> > object to a C++ method and use it internally? e.g., if I
> have a class
> >
> > class Passer
> > {
> >  public:
> >    Passer() {};
> >    void setx( dict x ) { this->m_x = x; };
> >    void setf( object f ) { this->m_f = f; };
> >    double val();
> >    double xval() { return extract<double>( m_x['v'] ); };
> >
> >  private:
> >    dict   m_x;
> >    object m_f;
> > };
> >
> > double Passer::val()
> > {
> >    PyObject * f   = m_f.ptr();
> >    PyObject * ret = PyEval_CallObject( f, m_x.ptr() );
> 
> 
> why not just
> 
>      object ret = m_f(m_x);
> 
> ??
> 
> >    double RetVal;
> >    if( ret )
> >       RetVal = 1;
> >    else
> >       RetVal = -1;
> >
> >    PyArg_Parse( ret, "(f)", &RetVal );
> >    return RetVal;
> > }
> 
> I don't know what your PyArg_Parse thing is supposed to be
> doing. I'm
> not really sure what all of that 1/-1 stuff is about either. 
> Is
> RetVal a tuple of one element?  Maybe you want:
> 
>  double Passer::val()
>  {
>      return m_f(m_x)[0];
>  }
> 
> > The setx method seems to work fine with a dictionary like
> {'v':4} and
> > the xval method returns its 'v' element properly.
> >
> > But the setf method doesn't seem to work correctly... when I
> call
> > val() from python after setting on a function, PyObject *
> ret comes
> > back NULL (which I learn from getting RetVal == -1 as a
> return value).
> 
> That might just mean that f raised a Python exception.  You're
> masking the problem by returning -1 instead of using the
> Boost.Python
> facilities which propagate the Python exception through your
> C++ code
> and back to Python.
> 
> > I'm sure I'm doing something dumb by making the type of
> setf's arg be
> > "object" rather than something specifying a function, but I
> don't know
> > what. :) Anything obvious I'm missing here?
> 
> The only dumb-ish thing is using the raw Python 'C' API
> instead of
> what Boost.Python gives you.  Try the simple approach I
> outlined
> above; it might be revealing.
> 
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> 


=====
-------------------------------------------------------
Mark Higgins, mghiggins at yahoo.com
http://www.molala.net

Opinions expressed herein do not reflect my own views;
I haven't had free will since last year when aliens ate
my brain.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/



From camelo at esss.com.br  Tue Feb 25 14:44:02 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Tue, 25 Feb 2003 10:44:02 -0300
Subject: [C++-sig] Problem compiling with Intel/VC7
In-Reply-To: <uwujpgxpr.fsf@boost-consulting.com>
Message-ID: <000001c2dcd3$f8616da0$0d00000a@esss.com.br>

> Is MSVCDir set in your environment?  

Yep... pointing to the old VC6 dir...

> If so, it appears VC7_ROOT will be ignored.  
> I think that's probably a mistake, but I don't 
> want to try to change it this close to 
> branching for a release.

Unsetting %MSVCDir or setting it to the actual
VC7 dir also didin't worked. In the first case, 
no include dir was passed to the compiler. In 
the second, the PlatformSDK include dir (were 
some of the standard VC7 header files are 
located) isn't passed.

For the records: the solution I've adopted was
setting the INCLUDE environment variable to the
above mentioned directories. The INTEL compiler
also uses the contents of this variable when 
searching for header files. The compilation 
works just fine now.

Thank you for your prompt reply.

Marcelo A. Camelo

-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of David Abrahams
Sent: segunda-feira, 24 de fevereiro de 2003 18:45
To: c++-sig at python.org
Subject: Re: [C++-sig] Problem compiling with Intel/VC7


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

> Hi!!!
>
> I've have just checked-out boost from the CVS repository
> and I'm trying to build it with bjam for the first time.
>
> I'm using the Intel 6.0 compiler, along with the VC7
> toolset.
>
> This is the command line I am using:
>
> bjam -sTOOLS=intel-win32 "-sINTEL_BASE_MSVC_TOOLSET=vc7" 
> "-sVC7_ROOT=C:\Program Files\Microsoft Visual Studio .NET\VC7" 
> "-sINTELC=C:\Program Files\Intel\Compiler60\IA32" 
> "-sPYTHON_ROOT=c:\Bin\Python22"
>
> Despite of this, bjam is still trying to use the VC6
> include path (that doesn't exist in my machine):
>
>  -I"C:\Program Files\Microsoft Visual Studio\VC98\include"
>
> As expected, the icl isn't finding some basic include
> files (limits.h, utility, etc).
>
> Can you see anything wrong or missing in the command line
> I'm using? Is there any way to force bjam to add the correct
> VC7 include path?

Is MSVCDir set in your environment?  If so, it appears VC7_ROOT will be
ignored.  I think that's probably a mistake, but I don't want to try to
change it this close to branching for a release.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


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




From dave at boost-consulting.com  Tue Feb 25 16:36:29 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 25 Feb 2003 10:36:29 -0500
Subject: [C++-sig] Problem compiling with Intel/VC7
In-Reply-To: <000001c2dcd3$f8616da0$0d00000a@esss.com.br> ("Marcelo A.
 Camelo"'s message of "Tue, 25 Feb 2003 10:44:02 -0300")
References: <000001c2dcd3$f8616da0$0d00000a@esss.com.br>
Message-ID: <uel5wbcea.fsf@boost-consulting.com>

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

>> Is MSVCDir set in your environment?  
>
> Yep... pointing to the old VC6 dir...
>
>> If so, it appears VC7_ROOT will be ignored.  
>> I think that's probably a mistake, but I don't 
>> want to try to change it this close to 
>> branching for a release.
>
> Unsetting %MSVCDir or setting it to the actual
> VC7 dir also didin't worked. In the first case, 
> no include dir was passed to the compiler. 

Works for me.  The compiler should invoke iccvars.bat before it runs,
which should set up the INCLUDE environment variable.  OTOH, if you
installed your intel toolset to use the vc6 backend, that will point
to the wrong place.  We need to fix how this whole thing works, but
I'd rather do it in BBv2, which is much more coherent.

> In the second, the PlatformSDK include dir (were some of the
> standard VC7 header files are located) isn't passed.

Hm.

> For the records: the solution I've adopted was
> setting the INCLUDE environment variable to the
> above mentioned directories. The INTEL compiler
> also uses the contents of this variable when 
> searching for header files. The compilation 
> works just fine now.

You're welcome.  Sorry I don't have a better answer for today.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Tue Feb 25 16:45:33 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 25 Feb 2003 12:45:33 -0300
Subject: [C++-sig] Virtual methods
Message-ID: <3E5B8F9D.9030901@globalite.com.br>

Hi!

I'm using Intel C++, STLport 4.5.3 and the current CVS.

I can't get the simple example from the tutorial about virtual methods to work. 
I copied and pasted the example, but couldn't reproduce the correct behaviour in 
python:

// basic.cpp

#include <boost/python.hpp>

using namespace boost::python;

struct Base
{
     virtual int f() = 0;
};

int call_f(Base& b) { return b.f(); }

struct BaseWrap : Base
{
     BaseWrap(PyObject* self_)
         : self(self_) {}
     int f() { return call_method<int>(self, "f"); }
     PyObject* self;
};


// Module ======================================================================
BOOST_PYTHON_MODULE(basic)
{
     class_<Base, BaseWrap, boost::noncopyable>("Base", no_init)
         ;
     def("call_f", call_f);

}



 >>> from basic import *
 >>> class Derived(Base):
...     def f(self):
...             return 42
...
 >>> d = Derived()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
RuntimeError: This class cannot be instantiated from Python
 >>>
 >>> # hmmm... let's override the __init__ method and see
 >>> # what happens
 >>> class Derived(Base):
...     def __init__(self): pass
...     def f(self): return 42
...
 >>> d = Derived()
 >>> call_f(d)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
 >>>

I remember using this example before, and it did work... has something changed 
since then?


Thanks,
Nicodemus.





From dave at boost-consulting.com  Tue Feb 25 17:35:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 25 Feb 2003 11:35:48 -0500
Subject: [C++-sig] Virtual methods
In-Reply-To: <3E5B8F9D.9030901@globalite.com.br> (Nicodemus's message of
 "Tue, 25 Feb 2003 12:45:33 -0300")
References: <3E5B8F9D.9030901@globalite.com.br>
Message-ID: <uwujo9v2z.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Hi!
>
> I'm using Intel C++, STLport 4.5.3 and the current CVS.
>
> I can't get the simple example from the tutorial about virtual methods
> to work. I copied and pasted the example, but couldn't reproduce the
> correct behaviour in python:
>
> I remember using this example before, and it did work... has something
> changed since then?

See the very first line of:

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

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Tue Feb 25 23:07:04 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 25 Feb 2003 19:07:04 -0300
Subject: [C++-sig] Virtual methods
In-Reply-To: <uwujo9v2z.fsf@boost-consulting.com>
References: <3E5B8F9D.9030901@globalite.com.br> <uwujo9v2z.fsf@boost-consulting.com>
Message-ID: <3E5BE908.4030709@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>Hi!
>>
>>I'm using Intel C++, STLport 4.5.3 and the current CVS.
>>
>>I can't get the simple example from the tutorial about virtual methods
>>to work. I copied and pasted the example, but couldn't reproduce the
>>correct behaviour in python:
>>
>>I remember using this example before, and it did work... has something
>>changed since then?
>>    
>>
>
>See the very first line of:
>
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/tutorial/doc/deriving_a_python_class.html
>
>HTH,
>

Oh.8P

Thanks David, and sorry for the time-waster. 8)
Nicodemus.





From gillet at scripps.edu  Wed Feb 26 03:36:34 2003
From: gillet at scripps.edu (Alexandre Gillet)
Date: Tue, 25 Feb 2003 18:36:34 -0800
Subject: [C++-sig] problem wrapping a c++ function on windows
Message-ID: <3E5C2832.7090802@scripps.edu>

Hi,

I am trying to wrappe a library using swig on windows(windows 
2000,swig1.3.11). I am able to build a dll but when I load my module 
videolib,I get the following error:
the dynamic link library libARvideo.dll could not be found

But I did get link  with the library libARvideo.lib

Here is my interface file videolib.i and the command I used to build my 
python module:

%{

int       arVideoOpen( char *config );
%}
int        arVideoOpen( char *config );

##########################################

Here is the swig command I used:
H:\Swig\SWIG-1.3.11\swig.exe -python -dump_tree -shadow -c++ -no_default
  -DSWIG_RELEASE=1.3.11 -DSWIG_TYPE=python -IH:\Python\Python2.1\include 
-IH:\Python\Python2.1\PC -IH:\Python\Python2.1\Include -I..\..\include 
-D_WIN32 -IH:\Swig\SWIG-1.3.11\Lib -IH:\Swig\SWIG-1.3.11\Lib\python 
-module videolib -o videolib.swigout videolib.i > videolib.swigtree

H:\Python\Python2.1\libplus\bin\pybatch.bat "H:\Python\Python2.1\libplus
;H:\ARToolKit\ARToolKit-DS-2.65b;H:\ARToolKit\ARToolKit-DS-2.65b\python/videopython" 
H:\Python\Python2.1\python21.exe -c "import tool; tool.run()" filter  -i 
videolib.swigout -o videolib.precious.c

H:\ARToolKit\ARToolKit-DS-2.65b\python\videopython>H:\Python\Python2.1\python21.
exe -c "import tool; tool.run()" filter -i videolib.swigout -o 
videolib.precious

Command use to compile:
         CL.EXE -c -nologo -W3 -Gy -Ox -GD -MD  -DSWIG_RELEASE=1.3.11 
-DSWIG_TYPE=python -IH:\Python\Python2.1\include 
-IH:\Python\Python2.1\PC -IH:\Python\Pythn2.1\Include -I..\..\include 
-F -o videolib.obj videolib.precious.c

Link:
link -debug -nologo -warn:3 -map -dll -export:initvideolibc 
-out:videolbc.dll videolib.obj -LIBPATH:..\..\lib libARvideo.lib 
-LIBPATH:H:\Python\Python2.1\libs python21.lib


Any idea what I am doing wrong?
In the Library the function I need to access is define in the .h file by:

int __declspec(ddlexport) arVideoOpen( char *config );


Thanks
-- 
   o Alexandre Gillet               email: gillet at scripps.edu
  /  The Scripps Research Institute,
o   Dept. Molecular Biology,  MB-5,
  \  10550  North Torrey Pines Road,
   o La Jolla,  CA 92037-1000,  USA.
  /  tel: (858) 784-2053
o   fax: (858) 784-2860







From bso at inf.ufsc.br  Wed Feb 26 03:57:18 2003
From: bso at inf.ufsc.br (Bruno da Silva de Oliveira)
Date: Tue, 25 Feb 2003 23:57:18 -0300
Subject: [C++-sig] Virtual Methods + default arguments
Message-ID: <3E5C2D0E.9010908@inf.ufsc.br>

Hi!

Is it possible to indicate default arguments for virtual methods, using 
the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro?

I have this code:

    struct X
    {
        virtual void f(int x = 10, char c = 'a')
        {
           std::cout << x << ", " << c << std::endl;
        }
    };

    void call_f(X& x)
    {
        x.f();
    }


    BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(f_overloads, f, 0, 2)

    struct XWrap: X
    {
        XWrap(PyObject* self_): self(self_) {}
        XWrap(PyObject* self_, const X&): self(self_) {}
        PyObject* self;
   
        void f(int x = 10, char c = 'a')
        {
            call_method<void>(self, "f", x, c);
        }
   
        void default_f(int x = 10, char c = 'a')
        {
            X::f(x, c);
        }
    };

    BOOST_PYTHON_MODULE(test)
    {   
        def("call_f", &call_f);
        class_< X, XWrap >("X")       
            .def("f", &X::f, &XWrap::default_f, f_overloads())
        ;
    }

But this does not compile. Here's the first line of the output of the 
compiler:

    
D:\Programming\Libraries\boost-cvs\boost\boost/python/detail/caller.hpp(53): 
error: class "f_overloads" has no member "result_converter"

So I tried to change the class_ definition to this:
   
    class_< X, XWrap >("X")       
        .def("f", &X::f, &XWrap::default_f)
        .def("f", &X::f, f_overloads())
    ;

It compiles fine, but in python:

 >>> from test import *
 >>> x = X()
 >>> x.f(10, 'c')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: unidentifiable C++ exception
 >>>

I also tried to change the second .def to:

   .def("f", &XWrap::f, f_overloads())

and:

   .def("f", &XWrap::default_f, f_overloads())

But with the same results.

So, is it possible to have virtual methods with default arguments? If 
so, how? Any pointer would be greatly appreciated.

Thanks in advance,
Nicodemus.












From nicodemus at globalite.com.br  Wed Feb 26 04:00:58 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Wed, 26 Feb 2003 00:00:58 -0300
Subject: [C++-sig] problem wrapping a c++ function on windows
In-Reply-To: <3E5C2832.7090802@scripps.edu>
References: <3E5C2832.7090802@scripps.edu>
Message-ID: <3E5C2DEA.7070709@globalite.com.br>

Alexandre Gillet wrote:

> Hi,

Hi

>
> I am trying to wrappe a library using swig on windows(windows 
> 2000,swig1.3.11). I am able to build a dll but when I load my module 
> videolib,I get the following error:
> the dynamic link library libARvideo.dll could not be found
> [snip] 

I believe you will get far more answers if you post to the swig mail list:

    http://mailman.cs.uchicago.edu/mailman/listinfo/swig


Good luck,
Nicodemus.






From dave at boost-consulting.com  Wed Feb 26 05:47:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 25 Feb 2003 23:47:46 -0500
Subject: [C++-sig] Virtual Methods + default arguments
In-Reply-To: <3E5C2D0E.9010908@inf.ufsc.br> (Bruno da Silva de Oliveira's
 message of "Tue, 25 Feb 2003 23:57:18 -0300")
References: <3E5C2D0E.9010908@inf.ufsc.br>
Message-ID: <uof4z7iml.fsf@boost-consulting.com>

Bruno da Silva de Oliveira <bso at inf.ufsc.br> writes:

> Hi!
>
> Is it possible to indicate default arguments for virtual methods,
> using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro?
>

<snip>

> I also tried to change the second .def to:
>
>    .def("f", &XWrap::f, f_overloads())
>
> and:
>
>    .def("f", &XWrap::default_f, f_overloads())
>
> But with the same results.

This one is on the right track, but you need a separate version of
f_overloads for the second one.  The 2nd argument to def in this case
just carries type information; it could be a null function pointer
for all Boost.Python cares.  It's the 3rd arg which carries all the
info about what functions to call.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Wed Feb 26 05:58:48 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Wed, 26 Feb 2003 01:58:48 -0300
Subject: [C++-sig] Virtual Methods + default arguments
In-Reply-To: <uof4z7iml.fsf@boost-consulting.com>
References: <3E5C2D0E.9010908@inf.ufsc.br> <uof4z7iml.fsf@boost-consulting.com>
Message-ID: <3E5C4988.5010501@globalite.com.br>

David Abrahams wrote:

>Bruno da Silva de Oliveira <bso at inf.ufsc.br> writes:
>  
>
>>Hi!
>>
>>Is it possible to indicate default arguments for virtual methods,
>>using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro?
>>
>>    
>>
>
><snip>
>
>  
>
>>I also tried to change the second .def to:
>>
>>   .def("f", &XWrap::f, f_overloads())
>>
>>and:
>>
>>   .def("f", &XWrap::default_f, f_overloads())
>>
>>But with the same results.
>>    
>>
>
>This one is on the right track, but you need a separate version of
>f_overloads for the second one.  The 2nd argument to def in this case
>just carries type information; it could be a null function pointer
>for all Boost.Python cares.  It's the 3rd arg which carries all the
>info about what functions to call.
>

Nice. The solution is define the overloads as:

    BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(f_overloads, default_f, 0, 2)

generate the module as:

    class_< X, XWrap >("X")       
        .def("f", &X::f, &XWrap::default_f )
        .def("f", &XWrap::default_f, f_overloads())
    ;

Thanks a lot Dave! (Don't you sleep? 8P)

Farewell,
Nicodemus.





From harold at imb-jena.de  Wed Feb 26 18:54:29 2003
From: harold at imb-jena.de (harold fellermann)
Date: Wed, 26 Feb 2003 18:54:29 +0100
Subject: [C++-sig] problem with python::dict[]
Message-ID: <5A8F3486-49B3-11D7-B629-000393DA32FA@imb-jena.de>

Hello,

I got your address from 
http://mail.python.org/pipermail/c++-sig/2002-June/001311.html -- so I 
don't know whether you are the right person to ask.
I think I have found an error in the boost.python's dict-interface.

My following code-snippet runs into segmantation fault:

#include <stdlib.h>
#include <boost/python/dict.hpp>

using namespace boost::python;

int main()
{
   dict x[750];

   return 0;
}


The problem seems to concern the garbage collector from the 
Python/C-API, as
my debugger tells me, the program crashes in _PyObject_GC_New():


(gdb) run
Starting program: /home/tsb/harold/c_network/pytest
[New Thread 1024 (LWP 25905)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 25905)]
0x0809a909 in PyErr_Occurred ()
(gdb) bt
#0  0x0809a909 in PyErr_Occurred ()
#1  0x080addca in _PyObject_GC_New ()
#2  0x08064edc in PyDict_New ()
#3  0x4003b1f4 in boost::python::detail::dict_base::dict_base() ()
    from /usr/local/lib/libboost_python.so.1.29.0
#4  0x080c6c6c in main () at pytest.c:9
#5  0x401744a2 in __libc_start_main () from /lib/libc.so.6


I tried this with a couple of python-objects and all containers (dict, 
list, ...)
crashed in exactly the same way. Interestingly the program behaves 
normal when
I reduce the number of objects within my array to approx. 700.

My configuration looks as follows:
- python 2.2.1 (#1, Sep 10 2002, 17:49:17)
- gcc 3.2
- boost version 1.29.0

Do you have any idea what is going on here? Is this a known bug, maybe 
even a nowadays fixed one? Or is it only a question of configuration? 
Any help will be appreciated!


thanx,

- harold fellermann -


--
He who wonders discovers that this in itself is wonder.
-- M.C. Escher




From dave at boost-consulting.com  Wed Feb 26 20:53:24 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 26 Feb 2003 14:53:24 -0500
Subject: [C++-sig] problem with python::dict[]
In-Reply-To: <5A8F3486-49B3-11D7-B629-000393DA32FA@imb-jena.de> (harold
 fellermann's message of "Wed, 26 Feb 2003 18:54:29 +0100")
References: <5A8F3486-49B3-11D7-B629-000393DA32FA@imb-jena.de>
Message-ID: <u8yw26cp7.fsf@boost-consulting.com>

harold fellermann <harold at imb-jena.de> writes:

> Hello,
>
> I got your address from
> http://mail.python.org/pipermail/c++-sig/2002-June/001311.html -- so I
> don't know whether you are the right person to ask.

"We" are the right people to ask.  You sent it to the appropriate
place: c++-sig at python.org.

> I think I have found an error in the boost.python's dict-interface.
>
> My following code-snippet runs into segmantation fault:
>
> #include <stdlib.h>
> #include <boost/python/dict.hpp>
>
> using namespace boost::python;
>
> int main()
> {
>    dict x[750];
>
>    return 0;
> }


Do you really mean to construct an array of 750 dicts?  I think if
you're going to do that from a program (as opposed to an extension
module) you'll need to call some things like PyInitialize() first.
See libs/python/test/embedding.cpp for an example.

> The problem seems to concern the garbage collector from the
> Python/C-API, as
> my debugger tells me, the program crashes in _PyObject_GC_New():
>
>
> (gdb) run
> Starting program: /home/tsb/harold/c_network/pytest
> [New Thread 1024 (LWP 25905)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 25905)]
> 0x0809a909 in PyErr_Occurred ()
> (gdb) bt
> #0  0x0809a909 in PyErr_Occurred ()
> #1  0x080addca in _PyObject_GC_New ()
> #2  0x08064edc in PyDict_New ()
> #3  0x4003b1f4 in boost::python::detail::dict_base::dict_base() ()
>     from /usr/local/lib/libboost_python.so.1.29.0
> #4  0x080c6c6c in main () at pytest.c:9
> #5  0x401744a2 in __libc_start_main () from /lib/libc.so.6
>
>
> I tried this with a couple of python-objects and all containers (dict,
> list, ...)
> crashed in exactly the same way. Interestingly the program behaves
> normal when
> I reduce the number of objects within my array to approx. 700.

Very interesting, but inconclusive.

> My configuration looks as follows:
> - python 2.2.1 (#1, Sep 10 2002, 17:49:17)
> - gcc 3.2
> - boost version 1.29.0
>
> Do you have any idea what is going on here? Is this a known bug,
> maybe even a nowadays fixed one? Or is it only a question of
> configuration?  Any help will be appreciated!

It's hard to imagine any bug in Boost.PYthon that would depend on the
size of the array being small; maybe one in the compiler or in Python
could do that.

This works on my system:

#include <stdlib.h>
#include <boost/python/dict.hpp>

using namespace boost::python;

void test()
{
    // Initialize the interpreter
    Py_Initialize();
    dict d[750];
}

int main()
{
    if (handle_exception(test))
    {
        if (PyErr_Occurred())
            PyErr_Print();
        return 1;
    }
    return 0;
}

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nksauter at lbl.gov  Thu Feb 27 03:51:31 2003
From: nksauter at lbl.gov (Nicholas K. Sauter)
Date: Wed, 26 Feb 2003 18:51:31 -0800
Subject: [C++-sig] Boost.Python compiles & links on Darwin
Message-ID: <3E5D7D33.7BC667CE@lbl.gov>

This should be of interest to people waiting to use Boost.Python on the
Macintosh.  I have achieved partial success running Boost.Python modules
on Darwin.  The build system is based on the scheme proposed by Rene
Rivera last November, with the Boost.Python library dynamically linked
as a dylib, and the user's module as a bundle.  Python itself must be
installed as a Darwin Framework.  It was also necessary to download gcc
3.2.2 from FSF rather than use the pre-installed compiler from Apple.

Details are posted in the "darwin_notes" link presented on my
Multi-platform build page:

http://cci.lbl.gov/boost

As noted, this is only a partial port.  For one thing, the gcc 3.2.2
compiler doesn't seem to properly handle any C++ exceptions, so many of
the modules in the Boost.Python test suite will fail. It may be
necessary to wait for a proper gcc 3.3 release to fix this.  Also, some
work will be needed on the Boost.Python library itself to fix some
compile-time problems reported in the log files (see build page).

--
Nicholas K. Sauter, Ph.D.
Lawrence Berkeley National Lab
1 Cyclotron Road, Bldg 4R0230
Berkeley, CA 94720-8235

nksauter at lbl.gov
Voice: 510-486-5713
Fax: 510-486-5909

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nksauter.vcf
Type: text/x-vcard
Size: 354 bytes
Desc: Card for Nicholas K. Sauter
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030226/2c98ae12/attachment.vcf>

From dave at boost-consulting.com  Thu Feb 27 04:49:03 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 26 Feb 2003 22:49:03 -0500
Subject: [C++-sig] Enhanced shared_ptr support
Message-ID: <ubs0y9yds.fsf@boost-consulting.com>

A few days ago I checked in some changes to the way shared_ptrs get
converted to Python.  A while back I had added a special shared_ptr
deleter which caused all shared_ptr conversions from python to
maintain the lifetime of the owning Python object, not of the C++
object.  In other words, we'll have this:

      shared_ptr<T>         T
     +------+------+     +------+
     |      |      |     |      |
     |  *   |   *------->|      |
     |  ||  |      |     |      |
     +--||--+------+     +------+
        ||                  /\
        \/                  ||
     +-----------------+    ||
     |                 |    ||
     | Python Object *======++
     |                 |
     +-----------------+

The double lines represent ownership relationships.  Now, when such a
shared_ptr is converted back to python, the owned Python object is
returned, rather than a new Python object being built around the
shared_ptr, sharing ownership of the T object with the Python object
above.

-Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu Feb 27 07:20:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 27 Feb 2003 01:20:37 -0500
Subject: [C++-sig] Boost.Python compiles & links on Darwin
In-Reply-To: <3E5D7D33.7BC667CE@lbl.gov> ("Nicholas K. Sauter"'s message of
 "Wed, 26 Feb 2003 18:51:31 -0800")
References: <3E5D7D33.7BC667CE@lbl.gov>
Message-ID: <uvfz6p7m2.fsf@boost-consulting.com>

"Nicholas K. Sauter" <nksauter at lbl.gov> writes:

> This should be of interest to people waiting to use Boost.Python on the
> Macintosh.  I have achieved partial success running Boost.Python modules
> on Darwin.  

This is fantastic news, Nick!

> The build system is based on the scheme proposed by Rene Rivera last
> November, with the Boost.Python library dynamically linked as a
> dylib, and the user's module as a bundle.  Python itself must be
> installed as a Darwin Framework.  It was also necessary to download
> gcc 3.2.2 from FSF rather than use the pre-installed compiler from
> Apple.

Heh.  I wonder if Apple has fixed the EH bugs you mention below in
their local branch of GCC, and they just haven't been rolled back
into the FSF version yet?

> Details are posted in the "darwin_notes" link presented on my
> Multi-platform build page:
>
> http://cci.lbl.gov/boost
>
> As noted, this is only a partial port.  For one thing, the gcc 3.2.2
> compiler doesn't seem to properly handle any C++ exceptions, 

Is that just on the Apple platform, or everywhere?  Have you reported
these bugs to GNU through their GNATs system?

> so many of the modules in the Boost.Python test suite will fail. It
> may be necessary to wait for a proper gcc 3.3 release to fix this.
> Also, some work will be needed on the Boost.Python library itself to
> fix some compile-time problems reported in the log files (see build
> page).

I don't see any compile-errors there that aren't supposed to happen.
Link errors are another matter.  The introduction of Python's bool
type has changed the output of some of the runtime tests and the
docstrings need to be updated.

BTW, Nick, I never look at the build page; there's so much output
that it's almost impossible to find errors.  I don't know if it's
useful to you, but I think you might run bjam with

   bjam -d0 all

for that page so that the tests don't run.  The test page can hold the
test run output.  Just a suggestion.

Thanks for all your work on this!
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From Harri.Hakula at hut.fi  Thu Feb 27 15:38:32 2003
From: Harri.Hakula at hut.fi (Harri Hakula)
Date: Thu, 27 Feb 2003 16:38:32 +0200
Subject: [C++-sig] Boost.Python compiles & links on Darwin
In-Reply-To: <uvfz6p7m2.fsf@boost-consulting.com>
Message-ID: <251F9D10-4A61-11D7-95A4-000393C34364@hut.fi>

On Thursday, February 27, 2003, at 08:20 AM, David Abrahams wrote:

> "Nicholas K. Sauter" <nksauter at lbl.gov> writes:
>
>> The build system is based on the scheme proposed by Rene Rivera last
>> November, with the Boost.Python library dynamically linked as a
>> dylib, and the user's module as a bundle.  Python itself must be
>> installed as a Darwin Framework.  It was also necessary to download
>> gcc 3.2.2 from FSF rather than use the pre-installed compiler from
>> Apple.
>
> Heh.  I wonder if Apple has fixed the EH bugs you mention below in
> their local branch of GCC, and they just haven't been rolled back
> into the FSF version yet?
>
Here is a link to a note by Stan Shebs (shebs at apple.com)
http://gcc.gnu.org/ml/gcc/2001-10/msg00585.html
which explains the state of affairs on OSX.
(Assuming the info is still valid for the current gcc Apple is using, 
of course.)

Cheers,

	Harri Hakula







From ostiguy at fnal.gov  Thu Feb 27 19:47:36 2003
From: ostiguy at fnal.gov (Francois Ostiguy)
Date: Thu, 27 Feb 2003 12:47:36 -0600 (CST)
Subject: [C++-sig] extracting a c++ object from a PyObject
Message-ID: <Pine.GSO.4.40.0302271239520.20791-100000@boopsie.fnal.gov>

This is a follow-up question to a recent thread.
Dave Abrahams provided the following code to extract a c++ object from a
PyObject

void f(PyObject* p) {

  handle<> ph(borrowed(p));
  MyObj* op = extract<MyObj*>(object(ph));

}

this works beautifully, but appenrently fails in the case where MyObj
is a simple function. That is


typedef void (fcntptr*)();

void f(PyObject* p) {

  handle<> ph(borrowed(p));
  fcntptr op = extract<fcntptr>(object(ph));

}

results in the following compilation error message.

/usr/local/include/boost/type_traits/add_cv.hpp:34: `const volatile'
qualifiers cannot be applied to `void ()()'

As always, any help/insight is greatly appreciated.

-Francois

----------------------------------------------------------------------------
Dr. Jean-Francois OSTIGUY                              voice: (630) 840-2231
Beam Physics Dept MS220                                  FAX: (630) 840-6039
Fermi National Accelerator Laboratory                email: ostiguy at fnal.gov
Batavia IL 60510-0500                           WWW:www-ap.fnal.gov/~ostiguy





From dave at boost-consulting.com  Thu Feb 27 21:08:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 27 Feb 2003 15:08:59 -0500
Subject: [C++-sig] extracting a c++ object from a PyObject
In-Reply-To: <Pine.GSO.4.40.0302271239520.20791-100000@boopsie.fnal.gov> (Francois
 Ostiguy's message of "Thu, 27 Feb 2003 12:47:36 -0600 (CST)")
References: <Pine.GSO.4.40.0302271239520.20791-100000@boopsie.fnal.gov>
Message-ID: <uk7flmqp0.fsf@boost-consulting.com>

Francois Ostiguy <ostiguy at fnal.gov> writes:

> This is a follow-up question to a recent thread.
> Dave Abrahams provided the following code to extract a c++ object from a
> PyObject
>
> void f(PyObject* p) {
>
>   handle<> ph(borrowed(p));
>   MyObj* op = extract<MyObj*>(object(ph));
>
> }
>
> this works beautifully, but appenrently fails in the case where MyObj
> is a simple function. That is
>
>
> typedef void (fcntptr*)();
>
> void f(PyObject* p) {
>
>   handle<> ph(borrowed(p));
>   fcntptr op = extract<fcntptr>(object(ph));
>
> }
>
> results in the following compilation error message.
>
> /usr/local/include/boost/type_traits/add_cv.hpp:34: `const volatile'
> qualifiers cannot be applied to `void ()()'
>
> As always, any help/insight is greatly appreciated.

The compilation error occurs because Boost.Python isn't set up to
convert Python objects to function pointers.  It's not a crazy
idea to do so if, for example, you have a Python object which actually
contains a C++ function pointer in the first place, but that's not
implemented.  If you're trying to convert arbitrary Python functions
to C++ function pointers...

Can you figure out how to turn an arbitrary Python object into a C++
function pointer at runtime, using just the Python 'C' API?  If the
C++ function pointed to always does the same thing regardless of the
source Python object, you can... but that's not a very interesting
case.  If you want the C++ function to do something different based on
the Python function passed (e.g. call the Python object), where would
the code for that C++ function come from?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Fri Feb 28 23:57:20 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Fri, 28 Feb 2003 23:57:20 +0100
Subject: [C++-sig] BPL embedding tutorial updated.
Message-ID: <b3opfv$p6k$1@main.gmane.org>

I've made some changes to my Boost.Python tutorial on embedding. Joel 
and I will hopefully be able to integrate it into the main tutorial for 
the next Boost release. In the meantime it is available from the Boost 
sandbox:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/libs/python/doc/tutorial/doc/embedding.html

If you find any errors or have any suggestions, I'd love to hear from you.

Dirk Gerrits