From dave at boost-consulting.com  Wed Oct  1 00:04:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 30 Sep 2003 18:04:56 -0400
Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with
 static/non-static overloading
References: <uekxz31yk.fsf@boost-consulting.com>
	<20030930211240.98818.qmail@web41511.mail.yahoo.com>
Message-ID: <usmmeq6ev.fsf@boost-consulting.com>

Joel Gerard <llywelyn.geo at yahoo.com> writes:

> Ok.  I've got things mostly sorted out.  You can't overload static and non-static member
> functions, which is fine, but how do you use a static (not overloaded) function in Python? I need
> to keep the static function in the class scope. The reason is name collision, i.e.
>
> class A
> {
>    static void foo();
> }
>
> class B 
> {
>    static void foo();
> }

Do your static functions take the same sets of arguments?  If not,
name collision is OK because overloading will select the right one.

> I have:
> class Vector
> {
> public:
>     static  void        Orthonormalize          (Vector& kU, Vector& kV, Vector& kW);
> }
>
> Wrapped as:
>
>
> void (*Orthonormalize2)(Vector&, Vector&, Vector&)      = &Vector::Orthonormalize;
> .def("Orthonormalize",Orthonormalize2)
>             .staticmethod("Orthonormalize")
>
> In python, do you just use it as an unbound method?  Is the self argument non-existent in this
> case, or do I do something different?

See http://users.rcn.com/python/download/Descriptor.htm

> Currently I have:
> Vector.Orthonormalize (Vector1, Vector2, Vector3)
>
> Also, is there a good place to look for python examples. I didn't see a python example in the
> docs

Please post a doc bug in the Python bug database.
http://sourceforge.net/tracker/?group_id=5470


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




From s_sourceforge at nedprod.com  Wed Oct  1 02:26:59 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 01 Oct 2003 01:26:59 +0100
Subject: [C++-sig] Pyste could do with return_self()
Message-ID: <3F7A2D63.25835.3E1E1B16@localhost>

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

... which maps to return_self<>(). I use a lot of methods which 
return *this so you can chain the calls together.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP3ofVMEcvDLFGKbPEQJdpwCgtJHKYdRC/iM+Bfj9nqvgGiqAmgIAoMoI
H+jGM2CcMFqg0qNWE1lEiGov
=ICxQ
-----END PGP SIGNATURE-----



From pierre.barbier at cirad.fr  Wed Oct  1 14:58:03 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 01 Oct 2003 14:58:03 +0200
Subject: [C++-sig] Boost.Python and threads
Message-ID: <1065013082.663.61.camel@pbarbier>

Hello,

I've followed the thread about boost.python multithreading between Lijun
Qin and David Abrahams and I wondered where was the implementation of
this ? If there is no implementation, what is the best way to safely
unblock the python threads ? Or at least where can I find information
about this ?

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 ejoy at 163.com  Thu Oct  2 05:48:59 2003
From: ejoy at 163.com (Zhang Le)
Date: Thu, 2 Oct 2003 11:48:59 +0800
Subject: [C++-sig] On wrapping vector<pair<string, double> >
In-Reply-To: <E1A4Myu-0000la-U0@mail.python.org>
References: <E1A4Myu-0000la-U0@mail.python.org>
Message-ID: <mutt.200310021120.38@peoplemail.com.cn>

> From: Nicodemus <nicodemus at globalite.com.br>
> Subject: Re: [C++-sig] On wrapping vector<pair<string, double> >
> To: Development of Python/C++ integration <c++-sig at python.org>
> Message-ID: <3F7963B7.3030904 at globalite.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> It is hard to tell by your description of the problem alone, some code 
> would help. But try this:
> 
> py::list py_eval(py::list v)
> {
>     vector< pair<string, double> > input;
>     int i;
>     int len = py::extract<int>(v.attr("__len__")());
> ...
Thank you. I have tracked the bug:
I forget to use attr("__len__") to get the length of a list. Actually,
I'm trying to do:
     size_t len = py::extract<size_t>(v);

I have an additional question: How to detect a type of a py::object in
boost.python?

I want to change my function to accept either 'str' or 'list' type.
py_eval(py::object obj) {
   if (type(obj) is 'str') {
      ...
   } else if (type(obj) is 'list' or 'tuple') {
   ...
   }
}

How to do the above statements in c++ code?

Thanks.
-- 
                                     Sincerely yours,
                                            Zhang Le



From pierre.barbier at cirad.fr  Thu Oct  2 13:37:02 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Thu, 02 Oct 2003 13:37:02 +0200
Subject: [C++-sig] Sharing C++ data from different modules
Message-ID: <1065094621.960.72.camel@pbarbier>

I need to build a module for python that will be included in a broader
application with contributions from different teams using different
exporting tools (mainly SWIG or Boost.Python for C++ code, but sometimes
the native C fonctions are used). As we need to share C++ structures, is
there a way to define a function taking a PyObject* that returns a
pointer to the corresponding C++ object. For example, if I have a class
named "MyClass", I'd want to be able to write :

MyClass* ptr = PyObjectToMyClass( py_object );

Where py_object is a PyObject* known to correspond to a MyClass object
exported using Boost.Python.

I hope I'm clear enough,

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 rwgk at yahoo.com  Thu Oct  2 15:21:48 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 2 Oct 2003 06:21:48 -0700 (PDT)
Subject: [C++-sig] Sharing C++ data from different modules
In-Reply-To: <1065094621.960.72.camel@pbarbier>
Message-ID: <20031002132148.51720.qmail@web20209.mail.yahoo.com>

--- Pierre Barbier de Reuille <pierre.barbier at cirad.fr> wrote:
> I need to build a module for python that will be included in a broader
> application with contributions from different teams using different
> exporting tools (mainly SWIG or Boost.Python for C++ code, but sometimes
> the native C fonctions are used). As we need to share C++ structures, is
> there a way to define a function taking a PyObject* that returns a
> pointer to the corresponding C++ object. For example, if I have a class
> named "MyClass", I'd want to be able to write :
> 
> MyClass* ptr = PyObjectToMyClass( py_object );
> 
> Where py_object is a PyObject* known to correspond to a MyClass object
> exported using Boost.Python.

Is this what you are looking for?

http://www.boost.org/libs/python/doc/tutorial/doc/extracting_c___objects.html
http://www.boost.org/libs/python/doc/v2/extract.html

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From pierre.barbier at cirad.fr  Thu Oct  2 15:37:03 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Thu, 02 Oct 2003 15:37:03 +0200
Subject: [C++-sig] Sharing C++ data from different modules
In-Reply-To: <20031002132148.51720.qmail@web20209.mail.yahoo.com>
References: <20031002132148.51720.qmail@web20209.mail.yahoo.com>
Message-ID: <1065101823.663.74.camel@pbarbier>

Le jeu 02/10/2003 ? 15:21, Ralf W. Grosse-Kunstleve a ?crit :
> 
> Is this what you are looking for?
> 
> http://www.boost.org/libs/python/doc/tutorial/doc/extracting_c___objects.html
> http://www.boost.org/libs/python/doc/v2/extract.html
> 
> Ralf
> 

Arg, you are very right ... I must be very tired not to have think of
that ! Thanks a lot !

-- 
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 snyder at d0mino.fnal.gov  Thu Oct  2 18:40:23 2003
From: snyder at d0mino.fnal.gov (scott snyder)
Date: Thu, 02 Oct 2003 11:40:23 -0500
Subject: [C++-sig] problem with Boost.Python enum with duplicate values
Message-ID: <200310021640.h92GeO1f10000181@d0mino.fnal.gov>


hi -

I've found that the enum support in Boost.Python does not fully
handle the case of duplicate enum values.  For example, i was
processing (with pyste) this enum:

  enum { X=0, Y=1, NUM_COORDINATES=2, SIZE=NUM_COORDINATES };

Pyste generated code to set all four enum symbols like this:

    enum_< UniqueInt<4> >("unnamed")
        .value("Y", Hep2Vector::Y)
        .value("X", Hep2Vector::X)
        .value("SIZE", Hep2Vector::SIZE)
        .value("NUM_COORDINATES", Hep2Vector::NUM_COORDINATES)
        .export_values()
    ;

However, from python, the `SIZE' symbol was not present.

Looking at the code in enum.cpp, is see that it keeps the enum items
in a map indexed by the value --- so values added later overwrite
any added earlier.

It's common to use C++ enums to define small integral constants,
in addition to using them for things which are actual enumerations.
So the case of multiple enum symbols with the same value really should
be supported.

The following patch attempts to do this.
When value() is called, if the value is already in the map,
then we add the symbol to a (new) list instead.
export_values() then visits the list as well as the map when
exporting symbols.
The map is still used for the value->symbol mapping (so the first
one listed is the one you'll get).

thanks,
sss


Index: src/object/enum.cpp
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/src/object/enum.cpp,v
retrieving revision 1.5
diff -u -p -r1.5 enum.cpp
--- src/object/enum.cpp	20 Feb 2003 20:27:44 -0000	1.5
+++ src/object/enum.cpp	2 Oct 2003 16:23:30 -0000
@@ -148,6 +148,7 @@ namespace
       dict d;
       d["__slots__"] = tuple();
       d["values"] = dict();
+      d["othervalues"] = list();
 
       object module_name = module_prefix();
       if (module_name)
@@ -192,7 +193,12 @@ void enum_base::add_value(char const* na
     (*this).attr(name_) = x;
 
     dict d = extract<dict>(this->attr("values"))();
-    d[value] = x;
+    if (d.has_key (value)) {
+      list l = extract<list>(this->attr("othervalues"))();
+      l.append (x);
+    }
+    else
+      d[value] = x;
     
     // Set the name field in the new enum instanec
     enum_object* p = downcast<enum_object>(x.ptr());
@@ -204,11 +210,16 @@ void enum_base::export_values()
 {
     dict d = extract<dict>(this->attr("values"))();
     list values = d.values();
+    list othervalues = extract<list>(this->attr("othervalues"))();
     scope current;
     
     for (unsigned i = 0, max = len(values); i < max; ++i)
     {
         api::setattr(current, object(values[i].attr("name")), values[i]);
+    }
+    for (unsigned i = 0, max = len(othervalues); i < max; ++i)
+    {
+        api::setattr(current, object(othervalues[i].attr("name")), othervalues[i]);
     }
  }
 
Index: test/enum.cpp
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/test/enum.cpp,v
retrieving revision 1.6
diff -u -p -r1.6 enum.cpp
--- test/enum.cpp	21 May 2003 22:17:22 -0000	1.6
+++ test/enum.cpp	2 Oct 2003 16:23:30 -0000
@@ -13,7 +13,7 @@
 #endif 
 using namespace boost::python;
 
-enum color { red = 1, green = 2, blue = 4 };
+enum color { red = 1, green = 2, blue = 4, blue2 = 4 };
 
 #if BOOST_WORKAROUND(__MWERKS__, <= 0x2407)
 namespace boost  // Pro7 has a hard time detecting enums
@@ -35,6 +35,7 @@ BOOST_PYTHON_MODULE(enum_ext)
         .value("red", red)
         .value("green", green)
         .value("blue", blue)
+        .value("blue2", blue2)
         .export_values()
         ;
     
Index: test/enum.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/test/enum.py,v
retrieving revision 1.4
diff -u -p -r1.4 enum.py
--- test/enum.py	26 Aug 2003 13:11:51 -0000	1.4
+++ test/enum.py	2 Oct 2003 16:23:30 -0000
@@ -10,6 +10,15 @@ enum_ext.color.green
 >>> identity(color.blue)
 enum_ext.color.blue
 
+>>> identity(color.blue2)
+enum_ext.color.blue
+
+>>> int(color.blue)
+4
+
+>>> int(color.blue2)
+4
+
 >>> identity(color(1))
 enum_ext.color.red
 



From snyder at fnal.gov  Thu Oct  2 19:02:44 2003
From: snyder at fnal.gov (scott snyder)
Date: Thu, 02 Oct 2003 12:02:44 -0500
Subject: [C++-sig] typo in pyste breaking -= and *= operators
Message-ID: <200310021702.h92H2j1f10258327@d0mino.fnal.gov>


hi -

Here's a typo in pyste that prevents the -= and *= operators from
being recognized (there's a space missing between them).
sss

Index: pyste/src/Pyste/ClassExporter.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/pyste/src/Pyste/ClassExporter.py,v
retrieving revision 1.13
diff -u -p -r1.13 ClassExporter.py
--- pyste/src/Pyste/ClassExporter.py	4 Sep 2003 22:47:04 -0000	1.13
+++ pyste/src/Pyste/ClassExporter.py	2 Oct 2003 16:23:30 -0000
@@ -425,7 +425,7 @@ class ClassExporter(Exporter):
                 self.Add('template', holder(self.class_.FullName()))
 
     # operators natively supported by boost
-    BOOST_SUPPORTED_OPERATORS = '+ - * / % ^ & ! ~ | < > == != <= >= << >> && || += -='\
+    BOOST_SUPPORTED_OPERATORS = '+ - * / % ^ & ! ~ | < > == != <= >= << >> && || += -= '\
         '*= /= %= ^= &= |= <<= >>='.split()
     # create a map for faster lookup
     BOOST_SUPPORTED_OPERATORS = dict(zip(BOOST_SUPPORTED_OPERATORS, range(len(BOOST_SUPPORTED_OPERATORS))))



From s_sourceforge at nedprod.com  Thu Oct  2 21:03:10 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 02 Oct 2003 20:03:10 +0100
Subject: [C++-sig] problem with Boost.Python enum with duplicate values
In-Reply-To: <200310021640.h92GeO1f10000181@d0mino.fnal.gov>
Message-ID: <3F7C847E.16558.474259A0@localhost>

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

On 2 Oct 2003 at 11:40, scott snyder wrote:

> Looking at the code in enum.cpp, is see that it keeps the enum items
> in a map indexed by the value --- so values added later overwrite any
> added earlier.
> 
> It's common to use C++ enums to define small integral constants,
> in addition to using them for things which are actual enumerations. So
> the case of multiple enum symbols with the same value really should be
> supported.

I completely agree. Perhaps a reimplementation of enum.cpp Dave?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP3x2bsEcvDLFGKbPEQKvjgCbB6pMacz712hrRpwhiWGDVWxx37kAnAzL
j/rIvh0AA3qcHsneh8/RZw7U
=o1/t
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Thu Oct  2 22:29:55 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 02 Oct 2003 16:29:55 -0400
Subject: [C++-sig] Re: problem with Boost.Python enum with duplicate values
References: <200310021640.h92GeO1f10000181@d0mino.fnal.gov>
	<3F7C847E.16558.474259A0@localhost>
Message-ID: <uoewzl6ws.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 2 Oct 2003 at 11:40, scott snyder wrote:
>
>> Looking at the code in enum.cpp, is see that it keeps the enum items
>> in a map indexed by the value --- so values added later overwrite any
>> added earlier.
>> 
>> It's common to use C++ enums to define small integral constants,
>> in addition to using them for things which are actual enumerations. So
>> the case of multiple enum symbols with the same value really should be
>> supported.
>
> I completely agree. Perhaps a reimplementation of enum.cpp Dave?

Something's in order.  I'm not very fond of Scott's specific patch,
though (sorry).  I'll give it some thought.

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




From nicodemus at globalite.com.br  Thu Oct  2 23:14:10 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 02 Oct 2003 18:14:10 -0300
Subject: [C++-sig] typo in pyste breaking -= and *= operators
In-Reply-To: <200310021702.h92H2j1f10258327@d0mino.fnal.gov>
References: <200310021702.h92H2j1f10258327@d0mino.fnal.gov>
Message-ID: <3F7C9522.3020305@globalite.com.br>

Hi Scott,

scott snyder wrote:

>hi -
>
>Here's a typo in pyste that prevents the -= and *= operators from
>being recognized (there's a space missing between them).
>  
>

Thanks for the report! This fix will go in the next commit.

Regards,
Nicodemus.




From s_sourceforge at nedprod.com  Fri Oct  3 05:07:05 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 03 Oct 2003 04:07:05 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
Message-ID: <3F7CF5E9.12650.48FD659B@localhost>

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

Basically, it's dead easy. You need to break the includes section 
into two parts: common and specific.

The common needs to be seperated from the specific with the following 
code:

#ifdef _MSC_VER
#pragma hdrstop
#endif

This won't affect GCC, but it means on MSVC you can precompile the 
common section (eg; boost/python.hpp) and it no longer needs to be 
done repeatedly per file.

I know you can tell MSVC to stop after seeing a certain include, but 
pyste doesn't order them in a particularly predictable fashion I've 
found, so thus you can be missing bits out.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP3zn2sEcvDLFGKbPEQKu1QCg1SceAedN234mceNdOos1maj1Ed0AoN0l
ulkziYbEkcVbYKION2tVtoXi
=VcYS
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Fri Oct  3 20:14:45 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 03 Oct 2003 19:14:45 +0100
Subject: [C++-sig] Pyste bug: UniqueInt<> doesn't appear in all modules when
	using --multiple
Message-ID: <3F7DCAA5.10212.4C3C642A@localhost>

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

Can I suggest you simply always insert the following code instead:

            write('// Unique type for unnamed enums\n')
            write('#ifndef UNIQUEINTDEFINED')
            write('#define UNIQUEINTDEFINED')
            write('template<int num>\n')
            write('struct UniqueInt {\n')
            write('   int v;\n')
            write('   enum { value=num };\n')
            write('   UniqueInt(int v_):\n') 
            write('       v(v_)\n')
            write('   {}\n')
            write('   operator int() const\n')
            write('   { return v; }\n')
            write('};\n')
            write('#endif')

Problem solved.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP328lsEcvDLFGKbPEQIm6wCeNpfr3DhPUDxtoBjZz+AGTaLl6XwAoLk1
oW0GlgHo1g0EzElW4qkThlYI
=42Q6
-----END PGP SIGNATURE-----



From snyder at fnal.gov  Fri Oct  3 21:42:29 2003
From: snyder at fnal.gov (scott snyder)
Date: Fri, 03 Oct 2003 14:42:29 -0500
Subject: [C++-sig] pyste problem with AllFromHeader when -I is used
Message-ID: <200310031942.h93JgUI323817979@d0mino.fnal.gov>


hi -

I ran into an annoyance with the way AllFromHeader interacts with include
search paths.  Specifically, if the header in question is found through
an include path specified with -I then the header may not be processed.
Here's an example:


$ mkdir include
$ cat > include/x.h
void foo();
$ cat > test.pyste
AllFromHeader ("x.h")
$ python $PYSTE_DIR/pyste.py --module=test -I`pwd`/include test.pyste
Module test generated
0.06 seconds
$ cat test.cpp

// Includes ====================================================================
#include <boost/python.hpp>

// Using =======================================================================
using namespace boost::python;

// Module ======================================================================
BOOST_PYTHON_MODULE(test)
{
}

$ 


Here, the x.h header was not processed.

The difficulty comes here, in HeaderExporter.py:

            # check if this declaration is in the header
            location = os.path.normpath(decl.location[0])
            if location == header and not self.IsInternalName(decl.name):

For this example, it ends up comparing the two paths:

  /work/shoreham-clued0/snyder/pystuff/test2/include/x.h x.h

i.e., comparing an absolute one to a relative one.  So the comparison
fails, and the header doesn't get processed.

This is a problem in practice: the headers i'm reading are part of another
product.  The absolute path to the headers depends on which version
i'm using and where they're installed on the particular system;
thus, i don't want to put the full path into the pyste file.

Below is the change i made to pyste to work around this.
It works for me, though it's kind of clunky and may match in some
cases where it actually shouldn't.
sss


Index: HeaderExporter.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/pyste/src/Pyste/HeaderExporter.py,v
retrieving revision 1.4
diff -u -p -r1.4 HeaderExporter.py
--- HeaderExporter.py	9 Aug 2003 21:18:12 -0000	1.4
+++ HeaderExporter.py	30 Sep 2003 01:37:17 -0000
@@ -34,7 +34,12 @@ class HeaderExporter(Exporter):
         for decl in self.declarations:
             # check if this declaration is in the header
             location = os.path.normpath(decl.location[0])
-            if location == header and not self.IsInternalName(decl.name):
+            l = len (header)
+            if (location[-l:] == header and
+                (l == len (location) or
+                 location[-l-1] == '/' or
+                 location[-l-1] == '\\')
+                and not self.IsInternalName (decl.name)):
                 # ok, check the type of the declaration and export it accordingly
                 self.HandleDeclaration(decl, codeunit, exported_names)
             



From mike at nospam.com  Fri Oct  3 21:52:08 2003
From: mike at nospam.com (Mike Rovner)
Date: Fri, 3 Oct 2003 12:52:08 -0700
Subject: [C++-sig] Re: Pyste suggestion: MSVC precompiled headers support
References: <3F7CF5E9.12650.48FD659B@localhost>
Message-ID: <blkk17$nj3$1@sea.gmane.org>

Niall Douglas wrote:
> Basically, it's dead easy. You need to break the includes section
> into two parts: common and specific.

Be aware that currecnt release of BPL doesn't work with PCH correctly out of
the box
(tested on VC7.0, VC7.1).

Mike






From s_sourceforge at nedprod.com  Fri Oct  3 21:10:56 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 03 Oct 2003 20:10:56 +0100
Subject: [C++-sig] Methods returning & taking pointers to functions
Message-ID: <3F7DD7D0.9422.4C6FD328@localhost>

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

I /think/ these don't compile properly ie; lots of compiler warnings. 
Unfortunately a mechanism of specifying a sort function is 
commonplace in my library and ultimately I'll really need it.

I see a two pronged approach: (i) make a pointer to a function an 
opaque type and (ii) write a thunk which invokes an arbitrary python 
function. The latter, through some small alterations to the base 
library, could be entirely driven by parameters (all I need is a 
pointer to the thing calling the sort function).

Has anyone else tried this? Is it even possible? If BP can't wrap 
methods taking or receiving pointers to functions, then it's a non-
starter.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP33JwMEcvDLFGKbPEQLAUQCg5HZYHSfEoFMjUN9Uq9MNA0yFXUwAniw6
wcAF1+KWqamVc841o1Xt1k9P
=gNBi
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Fri Oct  3 22:58:23 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 03 Oct 2003 21:58:23 +0100
Subject: [C++-sig] Re: Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <blkk17$nj3$1@sea.gmane.org>
Message-ID: <3F7DF0FF.5649.4CD2334D@localhost>

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

On 3 Oct 2003 at 12:52, Mike Rovner wrote:

> Niall Douglas wrote:
> > Basically, it's dead easy. You need to break the includes section
> > into two parts: common and specific.
> 
> Be aware that currecnt release of BPL doesn't work with PCH correctly
> out of the box (tested on VC7.0, VC7.1).

I'd said that in here before but someone else told me I was wrong. 
This might explain a few things. Cheers for the tip.

I'm also having issues with things returning void * which I guess 
pyste by rights should really mark as an opaque pointer?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP33i78EcvDLFGKbPEQKtngCg726A3z7XDI7DAJAqZuO+z1LUDUMAoNJ5
PDGQHzHCWzeuWZM43HLY0MqX
=oJR/
-----END PGP SIGNATURE-----



From mike at nospam.com  Fri Oct  3 23:06:29 2003
From: mike at nospam.com (Mike Rovner)
Date: Fri, 3 Oct 2003 14:06:29 -0700
Subject: [C++-sig] Re: Methods returning & taking pointers to functions
References: <3F7DD7D0.9422.4C6FD328@localhost>
Message-ID: <blkocj$vm1$1@sea.gmane.org>

Niall Douglas wrote:
> I /think/ these don't compile properly ie; lots of compiler warnings.
> Unfortunately a mechanism of specifying a sort function is
> commonplace in my library and ultimately I'll really need it.
>
> I see a two pronged approach: (i) make a pointer to a function an
> opaque type and (ii) write a thunk which invokes an arbitrary python
> function. The latter, through some small alterations to the base
> library, could be entirely driven by parameters (all I need is a
> pointer to the thing calling the sort function).
>
> Has anyone else tried this? Is it even possible? If BP can't wrap
> methods taking or receiving pointers to functions, then it's a non-
> starter.

FWIW take a look at
http://www.python.org/cgi-bin/moinmoin/boost_2epython_2fHowTo#head-c731dcfc007c502c41166c7a524780cb43a16bab -
How to wrap a "raw" function.

HTH,
Mike






From dave at boost-consulting.com  Fri Oct  3 23:53:19 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Oct 2003 17:53:19 -0400
Subject: [C++-sig] Re: Methods returning & taking pointers to functions
References: <3F7DD7D0.9422.4C6FD328@localhost>
Message-ID: <usmmadm40.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> I /think/ these don't compile properly ie; lots of compiler warnings. 
> Unfortunately a mechanism of specifying a sort function is 
> commonplace in my library and ultimately I'll really need it.
>
> I see a two pronged approach: (i) make a pointer to a function an 
> opaque type and (ii) write a thunk which invokes an arbitrary python 
> function. The latter, through some small alterations to the base 
> library, could be entirely driven by parameters (all I need is a 
> pointer to the thing calling the sort function).
>
> Has anyone else tried this? Is it even possible? 

I think what you're asking for is an automatic conversion from a
Python callable object to a C++ function pointer.

Well, no, it isn't possible, at least not in a reliable way.  That's
because a C++ function pointer can't have any associated data, and
you'd need some way to bind the callable Python object to it.

If you can change your interface to use, say, 

        boost::function2<bool, T, T>

I think we can come up with a solution.

> If BP can't wrap methods taking or receiving pointers to functions,
> then it's a non- starter.

It may be that.  This isn't a Boost.Python issue.  Search back in the
archives for posts about FLTK if you want more details.

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




From jbrandmeyer at earthlink.net  Sat Oct  4 00:05:43 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 03 Oct 2003 18:05:43 -0400
Subject: [C++-sig] std::wstring availability
Message-ID: <1065218743.1007.16.camel@illuvatar>

The attached patch uses a predefined macro to exclude wstring support
when it is not available on the platform's standard library.

The code to set the macro is already supplied in
boost/config/stdlib/*.hpp

Thanks,
Jonathan Brandmeyer


Index: builtin_converters.cpp
===================================================================
RCS file:
/boost/boost/libs/python/src/converter/builtin_converters.cpp,v
retrieving revision 1.25
diff -w -d -u -r1.25 builtin_converters.cpp
--- builtin_converters.cpp      11 Sep 2003 19:19:55 -0000      1.25
+++ builtin_converters.cpp      3 Oct 2003 22:00:50 -0000
@@ -22,6 +22,10 @@
 #include <string>
 #include <complex>
  
+#ifndef BOOST_NO_STD_WSTRING
+# include <wstring>
+#endif
+
 namespace boost { namespace python { namespace converter {
  
 shared_ptr_deleter::shared_ptr_deleter(handle<> owner)
@@ -272,6 +276,7 @@
       }
   };
  
+#ifndef BOOST_NO_STD_WSTRING
   // encode_string_unaryfunc/py_encode_string -- manufacture a
unaryfunc
   // "slot" which encodes a Python string using the default encoding
   extern "C" PyObject* encode_string_unaryfunc(PyObject* x)
@@ -307,6 +312,7 @@
           return result;
       }
   };
+#endif // !BOOST_NO_STD_WSTRING
  
   struct complex_rvalue_from_python
   {
@@ -403,7 +409,9 @@
     registry::insert(convert_to_cstring,type_id<char>());
  
     // Register by-value converters to std::string, std::wstring
+# ifndef BOOST_NO_STD_WSTRING
     slot_rvalue_from_python<std::wstring,
wstring_rvalue_from_python>();
+# endif
     slot_rvalue_from_python<std::string, string_rvalue_from_python>();
 }
  





From jbrandmeyer at earthlink.net  Sat Oct  4 00:19:23 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 03 Oct 2003 18:19:23 -0400
Subject: [C++-sig] std::wstring availability
In-Reply-To: <1065218743.1007.16.camel@illuvatar>
References: <1065218743.1007.16.camel@illuvatar>
Message-ID: <1065219563.1007.19.camel@illuvatar>

On Fri, 2003-10-03 at 18:05, Jonathan Brandmeyer wrote:
> The attached patch uses a predefined macro to exclude wstring support
> when it is not available on the platform's standard library.
> 
> The code to set the macro is already supplied in
> boost/config/stdlib/*.hpp
> 
> Thanks,
> Jonathan Brandmeyer
> 

Here it is again as a patch, since email formatting butchered the
formatting.

Sorry,
Jonathan Brandmeyer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: builtin_converters.patch
Type: text/x-patch
Size: 1340 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031003/08151f66/attachment.bin>

From dave at boost-consulting.com  Sat Oct  4 00:28:19 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Oct 2003 18:28:19 -0400
Subject: [C++-sig] Re: Boost.Python and threads
References: <1065013082.663.61.camel@pbarbier>
Message-ID: <un0cidkho.fsf@boost-consulting.com>

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

> Hello,
>
> I've followed the thread about boost.python multithreading between
> Lijun Qin and David Abrahams and I wondered where was the
> implementation of this ? If there is no implementation, what is the
> best way to safely unblock the python threads ? Or at least where
> can I find information about this ?

Sorry it took so long to reply Pierre; I was really hoping someone
else (like Lijun) would answer.

Anyway, I don't have an implementation of multithreading support, at
least not yet.

THe best way to safely unblock threads that I know of is to write a
thin wrapper around your function which uses Py_BEGIN_ALLOW_THREADS
and Py_END_ALLOW_THREADS around a call to the real function.

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




From llywelyn.geo at yahoo.com  Sat Oct  4 00:51:22 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Fri, 3 Oct 2003 15:51:22 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with
	static/non-static overloading
In-Reply-To: <usmmeq6ev.fsf@boost-consulting.com>
Message-ID: <20031003225122.89769.qmail@web41504.mail.yahoo.com>

Re (from way below):
> Please post a doc bug in the Python bug database.
> http://sourceforge.net/tracker/?group_id=5470

Is this is the correct bug db?  I was referring to the Boost docs. Is there a Boost bug db where I
should log this?

Joel

--- David Abrahams <> wrote:
> Joel Gerard <llywelyn.geo at yahoo.com> writes:
> 
> > Ok.  I've got things mostly sorted out.  You can't overload static and non-static member
> > functions, which is fine, but how do you use a static (not overloaded) function in Python? I
> need
> > to keep the static function in the class scope. The reason is name collision, i.e.
> >
> > class A
> > {
> >    static void foo();
> > }
> >
> > class B 
> > {
> >    static void foo();
> > }
> 
> Do your static functions take the same sets of arguments?  If not,
> name collision is OK because overloading will select the right one.
> 
> > I have:
> > class Vector
> > {
> > public:
> >     static  void        Orthonormalize          (Vector& kU, Vector& kV, Vector& kW);
> > }
> >
> > Wrapped as:
> >
> >
> > void (*Orthonormalize2)(Vector&, Vector&, Vector&)      = &Vector::Orthonormalize;
> > .def("Orthonormalize",Orthonormalize2)
> >             .staticmethod("Orthonormalize")
> >
> > In python, do you just use it as an unbound method?  Is the self argument non-existent in this
> > case, or do I do something different?
> 
> See http://users.rcn.com/python/download/Descriptor.htm
> 
> > Currently I have:
> > Vector.Orthonormalize (Vector1, Vector2, Vector3)
> >
> > Also, is there a good place to look for python examples. I didn't see a python example in the
> > docs
> 
> Please post a doc bug in the Python bug database.
> http://sourceforge.net/tracker/?group_id=5470


=====
--------------------------------------
Email: joelgerard at canada.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From llywelyn.geo at yahoo.com  Sat Oct  4 01:03:42 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Fri, 3 Oct 2003 16:03:42 -0700 (PDT)
Subject: [C++-sig] Returning reference to member variable that's a basic type
In-Reply-To: <un0cidkho.fsf@boost-consulting.com>
Message-ID: <20031003230342.67433.qmail@web41510.mail.yahoo.com>

I hope this doesn't get me the dumb question of the day award but...

How do you return a pointer/reference to a member variable(a basic type) and modify it from
python?

Eg.

Class Foo
{
public:
    int *GetX() {return x;};
    int &GetY();
private:
    int *x;
}

I've tried

.def ("GetX()",&Foo::GetX, return_internal_reference<>())
.def ("GetY()",&Foo::GetY, return_internal_reference<>())

I have no problems returning objects, but basic types gives me this error:

d:\dev\libs\boost\boost\python\object\make_instance.hpp(25): error C2027: use of undefined type
'boost::STATIC_ASSERTION_FAILURE<x>'
        with
        [
            x=false
        ]

What am I doing wrong?

Thanks,
Joel

=====
--------------------------------------
Email: joelgerard at canada.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From s_sourceforge at nedprod.com  Sat Oct  4 01:19:19 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 04 Oct 2003 00:19:19 +0100
Subject: [C++-sig] Re: Methods returning & taking pointers to functions
In-Reply-To: <usmmadm40.fsf@boost-consulting.com>
Message-ID: <3F7E1207.18194.4D533B1A@localhost>

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

On 3 Oct 2003 at 17:53, David Abrahams wrote:

> > I see a two pronged approach: (i) make a pointer to a function an
> > opaque type and (ii) write a thunk which invokes an arbitrary python
> > function. The latter, through some small alterations to the base
> > library, could be entirely driven by parameters (all I need is a
> > pointer to the thing calling the sort function).
> >
> > Has anyone else tried this? Is it even possible? 
> 
> I think what you're asking for is an automatic conversion from a
> Python callable object to a C++ function pointer.
> 
> Well, no, it isn't possible, at least not in a reliable way.  That's
> because a C++ function pointer can't have any associated data, and
> you'd need some way to bind the callable Python object to it.

I was going to take a more traditional approach and have the sorting 
function caller pass "this" with the objects to be compared. Then a 
routine can look up the instance and call the correct piece of 
python.

I luckily can have the sources altered, though not significantly as 
it would break the ABI. Next major release probably.

> If you can change your interface to use, say, 
> 
>         boost::function2<bool, T, T>
> 
> I think we can come up with a solution.

Can't have any boost in the main C++ library, at least not yet. Not 
even the STL is permitted in FOX!

> > If BP can't wrap methods taking or receiving pointers to functions,
> > then it's a non- starter.
> 
> It may be that.  This isn't a Boost.Python issue.  Search back in the
> archives for posts about FLTK if you want more details.

It certainly seems to barf here, but I don't know if that's my CVS of 
BP yet.

It was merely whether it's possible to wrap function pointers or not. 
My solution above would require the function pointer accepting 
methods to be excluded and replaced with some python anyway.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP34D+cEcvDLFGKbPEQKFagCfWedH/TRDpM/WFEKVOd77Gay9H9QAn3Nc
URC2S8b7Gk2nzddZeXWd0f6V
=2I2j
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sat Oct  4 01:22:03 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 04 Oct 2003 00:22:03 +0100
Subject: [C++-sig] Re: Boost.Python and threads
In-Reply-To: <un0cidkho.fsf@boost-consulting.com>
Message-ID: <3F7E12AB.14376.4D55BD40@localhost>

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

On 3 Oct 2003 at 18:28, David Abrahams wrote:

> > I've followed the thread about boost.python multithreading between
> > Lijun Qin and David Abrahams and I wondered where was the
> > implementation of this ? If there is no implementation, what is the
> > best way to safely unblock the python threads ? Or at least where
> > can I find information about this ?
> 
> Sorry it took so long to reply Pierre; I was really hoping someone
> else (like Lijun) would answer.
> 
> Anyway, I don't have an implementation of multithreading support, at
> least not yet.
> 
> THe best way to safely unblock threads that I know of is to write a
> thin wrapper around your function which uses Py_BEGIN_ALLOW_THREADS
> and Py_END_ALLOW_THREADS around a call to the real function.

What did you think of my idea for a macro (say 
"BOOST_PYTHON_ALWAYS_UNLOCK_GIL") which compiles it unlocking and 
relocking around every traversal from BP into C++ code?

Inefficient, but changing a mutex is nothing when compared to 
executing a single python byteop.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP34EnMEcvDLFGKbPEQLQzwCfbBKC3LtfNiZIv9zMGqzS5kSIPUsAoPSX
OMTz2Lnlv4OKRqye5cLRDeoZ
=P2Rk
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Sat Oct  4 02:32:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Oct 2003 20:32:46 -0400
Subject: [C++-sig] Re: std::wstring availability
References: <1065218743.1007.16.camel@illuvatar>
	<1065219563.1007.19.camel@illuvatar>
Message-ID: <u7k3lc05t.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> On Fri, 2003-10-03 at 18:05, Jonathan Brandmeyer wrote:
>> The attached patch uses a predefined macro to exclude wstring support
>> when it is not available on the platform's standard library.
>> 
>> The code to set the macro is already supplied in
>> boost/config/stdlib/*.hpp
>> 
>> Thanks,
>> Jonathan Brandmeyer
>> 
>
> Here it is again as a patch, since email formatting butchered the
> formatting.
>
> Sorry,
> Jonathan Brandmeyer

Jonathan,

are you sure there's something wrong with the current CVS state?
(http://tinyurl.com/pnsm)

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




From dave at boost-consulting.com  Sat Oct  4 02:37:10 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Oct 2003 20:37:10 -0400
Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with
 static/non-static overloading
References: <usmmeq6ev.fsf@boost-consulting.com>
	<20031003225122.89769.qmail@web41504.mail.yahoo.com>
Message-ID: <usmm9ale1.fsf@boost-consulting.com>

Joel Gerard <llywelyn.geo at yahoo.com> writes:

> Re (from way below):
>> Please post a doc bug in the Python bug database.
>> http://sourceforge.net/tracker/?group_id=5470
>
> Is this is the correct bug db?  I was referring to the Boost
> docs. Is there a Boost bug db where I should log this?

I don't think it's Boost's job to document how to use regular Python
static methods.  Or did you mean something else when you wrote:

>> >
>> > Also, is there a good place to look for python examples. I didn't
>> >see a python example in the docs

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




From dave at boost-consulting.com  Sat Oct  4 02:35:12 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Oct 2003 20:35:12 -0400
Subject: [C++-sig] Re: Returning reference to member variable that's a basic
	type
References: <un0cidkho.fsf@boost-consulting.com>
	<20031003230342.67433.qmail@web41510.mail.yahoo.com>
Message-ID: <u1xttc01r.fsf@boost-consulting.com>

Joel Gerard <llywelyn.geo at yahoo.com> writes:

> I hope this doesn't get me the dumb question of the day award but...
>
> How do you return a pointer/reference to a member variable(a basic type) and modify it from
> python?

You don't.  Basic types get mapped to Python ints, longs, and
strings, all of which are immutable.  YOu can't modify them.

Decide what interface you'd like to see for this code in Python, code
up a pure-Python mock-up which does what you want, and we can discuss
how to achieve it with BPL.

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




From qinlj at solidshare.com  Sat Oct  4 03:57:18 2003
From: qinlj at solidshare.com (Lijun Qin)
Date: Sat, 4 Oct 2003 09:57:18 +0800
Subject: [C++-sig] Re: Boost.Python and threads
References: <1065013082.663.61.camel@pbarbier>
	<un0cidkho.fsf@boost-consulting.com>
Message-ID: <005701c38a1a$de440b90$0200a8c0@barrack>

Hi,

If you want the unlock-lock operation be done automatically, you can use
this new 'invoke.hpp' file. I known this is not a complete solution, but you
can use it as a start.
When I initially post this message, I'm using pythoncom from win32all
package, in this module, it'll lock the thread when enter into the COM
method, so I need to unlock it first in every COM method call, the right
place is in the invoke function.
But I have found that this unlock-lock-unlock-lock sequence becomes more and
more complicated when the COM method callbacks into the caller, and this can
happen in many places because a simple AddRef() or Release() call can cause
python code executed, and AddRef()/Release() is almost anywhere in COM code,
you can image the code becomes really ugly.
Actually, in the STA (Single Thread Apartment) mode, which is common, there
is only one thread here, so no python thread lock/unlock is needed, so I
decided to implement my own COM-python bridge, and currently it's already
working in the STA mode, my existing codes have migrated into the new bridge
successfully. And this makes the patch to the invoke function unnecessary.

In the MTA(multi thread apartment) mode, I think a good solution will be
using the Channel-Hook, basically this is a point where your code will be
called when COM runtimes do RPC marshal-unmarshal, I think this is a good
place to unlock-lock python core. I have not implemented this because
currently all of my existing python object live in the a single STA, no
thread-switching is needed yet.
If somebody is interested in my python-COM bridge and willing to add MTA
support, email me and I can give you the sources, and when this is done,
I'll publish it in some places (maybe sourceforge) to share with others.

Regards
Lijun Qin
http://www.solidshare.com

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Saturday, October 04, 2003 6:28 AM
Subject: [C++-sig] Re: Boost.Python and threads


> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
>
> > Hello,
> >
> > I've followed the thread about boost.python multithreading between
> > Lijun Qin and David Abrahams and I wondered where was the
> > implementation of this ? If there is no implementation, what is the
> > best way to safely unblock the python threads ? Or at least where
> > can I find information about this ?
>
> Sorry it took so long to reply Pierre; I was really hoping someone
> else (like Lijun) would answer.
>
> Anyway, I don't have an implementation of multithreading support, at
> least not yet.
>
> THe best way to safely unblock threads that I know of is to write a
> thin wrapper around your function which uses Py_BEGIN_ALLOW_THREADS
> and Py_END_ALLOW_THREADS around a call to the real function.
>
> HTH,
> -- 
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invoke.hpp.new
Type: application/octet-stream
Size: 4821 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031004/f632c631/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: thread_lock.hpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031004/f632c631/attachment.txt>

From jbrandmeyer at earthlink.net  Sat Oct  4 05:33:00 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 03 Oct 2003 23:33:00 -0400
Subject: [C++-sig] Re: std::wstring availability
In-Reply-To: <u7k3lc05t.fsf@boost-consulting.com>
References: <1065218743.1007.16.camel@illuvatar>
	<1065219563.1007.19.camel@illuvatar>
	<u7k3lc05t.fsf@boost-consulting.com>
Message-ID: <1065238380.915.63.camel@illuvatar>

On Fri, 2003-10-03 at 20:32, David Abrahams wrote:
> Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> 
> Jonathan,
> 
> are you sure there's something wrong with the current CVS state?
> (http://tinyurl.com/pnsm)

Something is wrong.  Although this link and viewcvs on Sourceforge show
that the #ifndefs are there, a checkout from
:pserver:anonymous at boost-consulting.com:/boost (which I am using) does
not.  My checkout shows file version 1.25, while viewcvs shows that the
most recent revision is 1.26.

-Jonathan Brandmeyer




From s_sourceforge at nedprod.com  Sat Oct  4 03:11:05 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 04 Oct 2003 02:11:05 +0100
Subject: [C++-sig] Boost.Python bug
Message-ID: <3F7E2C39.21276.4DB98C47@localhost>

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

The following doesn't compile on MSVC7.1 with today's CVS:

#include <boost/python.hpp>

using namespace boost::python;

class FXThread
{
public:
	bool setAutoDelete(bool doso) throw();
};

void Export_FXThread()
{
    class_< FXThread >("FXThread")
        .def("setAutoDelete", &FXThread::setAutoDelete)
    ;
}

It complains "boost\boost\python\detail\invoke.hpp(76) : error C2064: 
term does not evaluate to a function taking 2 arguments"

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP34eKcEcvDLFGKbPEQJYigCgip5hNOW77IJLAYVyl5vACm0BzLkAnArU
h3w4h8Cf4VMpjxJuy6GzMZBf
=jy5r
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sat Oct  4 04:51:45 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 04 Oct 2003 03:51:45 +0100
Subject: [C++-sig] Pyste suggestion for handling returns of void *
Message-ID: <3F7E43D1.20996.393C77@localhost>

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

Boost.Python won't process a method returning void * nor will it 
permit you to set a typedef void *voidptrtype; to an opaque type :( 
Unfortunately some methods in my code return void *'s where you don't 
actually need the return value at all (it's just useful)! This makes 
things difficult for automated wraps.

I suggest getting pyste to cast any methods returning a void * to 
return void instead. I figure most architectures return their value 
in a register so theroretically casting a function pointer to not 
return anything shouldn't cause stack frame corruption.

To do this, patch class Method in declarations.py as follows:

    def PointerDeclaration(self, force?lse):
        '''Returns a declaration of a pointer to this member 
function.
        @param force: If True, returns a complete pointer declaration 
regardless
        if this function is unique or not. 
        '''
        # Boost.Python won't accept void * returns
        result = self.result.FullName()
        if result=="void*":
            result="void"
            force=True
        if self.static:
            # static methods are like normal functions
            return Function.PointerDeclaration(self, force)
        if self.is_unique and not force:
            return '&%s' % self.FullName()
        else:
            params = ', '.join([x.FullName() for x in 
self.parameters]) 
            const = ''
            if self.const:
                const = 'const'
            return '(%s (%s::*)(%s) %s%s)&%s' %\
                (result, self.class_, params, const, 
self.Exceptions(), self.FullName())  

This probably leaves out virtual functions and may cause problems 
with getting the address of overloaded methods. Still some support 
for void * returns is better than none.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP341xMEcvDLFGKbPEQKRrwCg0x7lPp3q1KcKqy4jtzcgznLlrMQAn1Dj
onpaowqaSwOo3OEKIiLv3RWX
=Gv+8
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sat Oct  4 05:49:27 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 04 Oct 2003 04:49:27 +0100
Subject: [C++-sig] Pyste bug: operator! shouldn't be translated
Message-ID: <3F7E5157.30973.6E0F5A@localhost>

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

A "friend FXVec4f operator!(const FXVec4f& a)" gets converted by 
pyste into .def( !self ) which if I understand the BP docs correctly, 
is not supported.

Is there not any reason why this couldn't be added to Boost.Python 
which AFAICS supports every operator except logical NOT? I can't see 
any.

Other pyste bug: something like "operator float*()" converts into 
".def("to_float", &FX::FXVec4f::operator float*)" which is fine but 
how do you specify the return policy??? Furthermore if you didn't 
want them, how can you exclude() them?

Lastly, something like "operator FXVec3f&()" converts into 
".def("to_FX_FXVec3f", &FX::FXVec4f::operator FX::FXVec3f&)" which 
seems odd as how could python know what a FX_FXVec3f is? Perhaps 
"to_FXVec3f" (without the namespace) maybe.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP35DR8EcvDLFGKbPEQI8RwCfVSHEZPQYnrxjYufILXOgcipLg1gAn0Rt
hqlY9srUSF/DC30K2ehvYn6P
=yDta
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Sat Oct  4 13:53:35 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Oct 2003 07:53:35 -0400
Subject: [C++-sig] Re: std::wstring availability
References: <1065218743.1007.16.camel@illuvatar>
	<1065219563.1007.19.camel@illuvatar>
	<u7k3lc05t.fsf@boost-consulting.com>
	<1065238380.915.63.camel@illuvatar>
Message-ID: <uwubl8bi8.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> On Fri, 2003-10-03 at 20:32, David Abrahams wrote:
>> Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:
>
>> 
>> Jonathan,
>> 
>> are you sure there's something wrong with the current CVS state?
>> (http://tinyurl.com/pnsm)
>
> Something is wrong.  Although this link and viewcvs on Sourceforge show
> that the #ifndefs are there, a checkout from
> :pserver:anonymous at boost-consulting.com:/boost (which I am using) does
> not.  My checkout shows file version 1.25, while viewcvs shows that the
> most recent revision is 1.26.

Then I should just disable that CVS repository, because it doesn't
seem to be getting updated.  If you want the very latest, stuff, just
use anonymous CVS from SourceForge.  They fixed the speed a few weeks
ago.

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




From dave at boost-consulting.com  Sat Oct  4 13:57:47 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Oct 2003 07:57:47 -0400
Subject: [C++-sig] Re: Boost.Python bug
References: <3F7E2C39.21276.4DB98C47@localhost>
Message-ID: <ur81t8bb8.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> The following doesn't compile on MSVC7.1 with today's CVS:
>
> #include <boost/python.hpp>
>
> using namespace boost::python;
>
> class FXThread
> {
> public:
> 	bool setAutoDelete(bool doso) throw();
> };
>
> void Export_FXThread()
> {
>     class_< FXThread >("FXThread")
>         .def("setAutoDelete", &FXThread::setAutoDelete)
>     ;
> }
>
> It complains "boost\boost\python\detail\invoke.hpp(76) : error C2064: 
> term does not evaluate to a function taking 2 arguments"

That doesn't make it a Boost.Python bug.  It works with every other
compiler I've tried.

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




From dave at boost-consulting.com  Sat Oct  4 14:02:43 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Oct 2003 08:02:43 -0400
Subject: [C++-sig] Re: Pyste suggestion for handling returns of void *
References: <3F7E43D1.20996.393C77@localhost>
Message-ID: <uhe2p8b30.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Boost.Python won't process a method returning void * nor will it 
> permit you to set a typedef void *voidptrtype; to an opaque type :( 
> Unfortunately some methods in my code return void *'s where you don't 
> actually need the return value at all (it's just useful)! This makes 
> things difficult for automated wraps.
>
> I suggest getting pyste to cast any methods returning a void * to 
> return void instead. I figure most architectures return their value 
> in a register so theroretically casting a function pointer to not 
> return anything shouldn't cause stack frame corruption.

I hope Nicodemus will refuse to do that, since calling through such a
cast function pointer causes undefined behavior.

<snip>

> This probably leaves out virtual functions and may cause problems 
> with getting the address of overloaded methods. Still some support 
> for void * returns is better than none.

This isn't what I'd call "support for void* returns".  We should
return and accept void*s as opaque pointers.

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




From dave at boost-consulting.com  Sat Oct  4 14:10:31 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Oct 2003 08:10:31 -0400
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
References: <3F7E5157.30973.6E0F5A@localhost>
Message-ID: <ubrsx8aq0.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> A "friend FXVec4f operator!(const FXVec4f& a)" gets converted by 
> pyste into .def( !self ) which if I understand the BP docs correctly, 
> is not supported.
>
> Is there not any reason why this couldn't be added to Boost.Python 
> which AFAICS supports every operator except logical NOT? I can't see 
> any.

Which python special method would you like it to be translated into?
We could implement __nonzero__ as !!x, I guess.

> Other pyste bug: something like "operator float*()" converts into 
> ".def("to_float", &FX::FXVec4f::operator float*)" which is fine

really?  Why isn't it 

         .def(float_(self))

??

> but how do you specify the return policy??? 

A return policy for a Python float??  What did you have in mind?

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




From dave at boost-consulting.com  Sat Oct  4 17:43:53 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Oct 2003 11:43:53 -0400
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
References: <3F7E5157.30973.6E0F5A@localhost>
	<ubrsx8aq0.fsf@boost-consulting.com>
Message-ID: <ufzi9ovnq.fsf@boost-consulting.com>

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

>> Is there not any reason why this couldn't be added to Boost.Python 
>> which AFAICS supports every operator except logical NOT? I can't see 
>> any.
>
> Which python special method would you like it to be translated into?
> We could implement __nonzero__ as !!x, I guess.

This is done in the CVS now.

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




From nicodemus at globalite.com.br  Sat Oct  4 22:29:41 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 17:29:41 -0300
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
In-Reply-To: <ubrsx8aq0.fsf@boost-consulting.com>
References: <3F7E5157.30973.6E0F5A@localhost>
	<ubrsx8aq0.fsf@boost-consulting.com>
Message-ID: <3F7F2DB5.8010901@globalite.com.br>

David Abrahams wrote:

>"Niall Douglas" <s_sourceforge at nedprod.com> writes:
>  
>
>>Other pyste bug: something like "operator float*()" converts into 
>>".def("to_float", &FX::FXVec4f::operator float*)" which is fine
>>    
>>
>
>really?  Why isn't it 
>
>         .def(float_(self))
>
>??
>  
>

Because the operator returns float*... if it did return just float, 
float_(self) would be used.

>>but how do you specify the return policy??? 
>>    
>>
>
>A return policy for a Python float??  What did you have in mind?
>

It's strange to have an operator that return float*. 8)

Have you tried set_policy(FXVec.operator['float*'], ...)?





From nicodemus at globalite.com.br  Sat Oct  4 23:18:02 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 18:18:02 -0300
Subject: [C++-sig] Pyste could do with return_self()
In-Reply-To: <3F7A2D63.25835.3E1E1B16@localhost>
References: <3F7A2D63.25835.3E1E1B16@localhost>
Message-ID: <3F7F390A.5060701@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>... which maps to return_self<>(). I use a lot of methods which 
>return *this so you can chain the calls together.
>  
>

Sure, it was an oversight by my part. I just added this, and I noticed 
that <boost/python/return_arg.hpp> is not included in 
<boost/python.hpp>. Dave, is that intentional?

Regards,
Nicodemus.




From dave at boost-consulting.com  Sat Oct  4 23:37:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Oct 2003 17:37:52 -0400
Subject: [C++-sig] Pyste could do with return_self()
In-Reply-To: <3F7F390A.5060701@globalite.com.br> (nicodemus@globalite.com.br's
	message of "Sat, 04 Oct 2003 18:18:02 -0300")
References: <3F7A2D63.25835.3E1E1B16@localhost>
	<3F7F390A.5060701@globalite.com.br>
Message-ID: <u1xtsn0pb.fsf@boost-consulting.com>

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

> Niall Douglas wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>> ... which maps to return_self<>(). I use a lot of methods which
>> return *this so you can chain the calls together.
>>  
>>
>
> Sure, it was an oversight by my part. I just added this, and I noticed
> that <boost/python/return_arg.hpp> is not included in
> <boost/python.hpp>. Dave, is that intentional?

No, I keep forgetting to add things.  Feel free to check in a fix.

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




From nicodemus at globalite.com.br  Sat Oct  4 23:44:42 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 18:44:42 -0300
Subject: [C++-sig] Pyste could do with return_self()
In-Reply-To: <u1xtsn0pb.fsf@boost-consulting.com>
References: <3F7A2D63.25835.3E1E1B16@localhost>	<3F7F390A.5060701@globalite.com.br>
	<u1xtsn0pb.fsf@boost-consulting.com>
Message-ID: <3F7F3F4A.4060608@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>Niall Douglas wrote:
>>
>>    
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>... which maps to return_self<>(). I use a lot of methods which
>>>return *this so you can chain the calls together.
>>> 
>>>
>>>      
>>>
>>Sure, it was an oversight by my part. I just added this, and I noticed
>>that <boost/python/return_arg.hpp> is not included in
>><boost/python.hpp>. Dave, is that intentional?
>>    
>>
>
>No, I keep forgetting to add things.  Feel free to check in a fix.
>

Done.





From s_sourceforge at nedprod.com  Sun Oct  5 01:21:47 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 00:21:47 +0100
Subject: [C++-sig] Re: Boost.Python bug
In-Reply-To: <ur81t8bb8.fsf@boost-consulting.com>
Message-ID: <3F7F641B.13772.49F5C2F@localhost>

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

On 4 Oct 2003 at 7:57, David Abrahams wrote:

> > It complains "boost\boost\python\detail\invoke.hpp(76) : error
> > C2064: term does not evaluate to a function taking 2 arguments"
> 
> That doesn't make it a Boost.Python bug.  It works with every other
> compiler I've tried.

Hang on: does this mean it didn't work on your MSVC7.1 either? I did 
spend some hours zeroing that down to a small repeatable example for 
you as you always request.

Also, you know as well as I that the whole Boost library always works 
around compiler idiosyncracies where possible. While it isn't 
technically a BP bug, it does interfere with BP's implicit goal of 
being useful on all major compilers.

If it can't be fixed, at least a FAQ entry saying it doesn't work due 
to a bug in MSVC7.1 would be a good idea?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP39WC8EcvDLFGKbPEQLCygCff1T5lzvuhYyNe07S+DOvnybCktUAnjue
62KcPPbqK2klPeJplcvxFoMD
=NbFc
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sun Oct  5 01:15:02 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 00:15:02 +0100
Subject: [C++-sig] Re: std::wstring availability
In-Reply-To: <uwubl8bi8.fsf@boost-consulting.com>
Message-ID: <3F7F6286.30601.4992FFC@localhost>

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

On 4 Oct 2003 at 7:53, David Abrahams wrote:

> Then I should just disable that CVS repository, because it doesn't
> seem to be getting updated.  If you want the very latest, stuff, just
> use anonymous CVS from SourceForge.  They fixed the speed a few weeks
> ago.

Can you keep the .bz2 file made from CVS? It's much much quicker for 
me to download that than a CVS update by 33k modem.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP39UdsEcvDLFGKbPEQK9tQCfWtnyPLyiw5IYjWinG2AZYbUzHKIAoKYF
HDUfl/Qq21fX57ur3mElRZw4
=++wD
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sun Oct  5 01:24:45 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 00:24:45 +0100
Subject: [C++-sig] Re: Pyste suggestion for handling returns of void *
In-Reply-To: <uhe2p8b30.fsf@boost-consulting.com>
Message-ID: <3F7F64CD.23648.4A213EC@localhost>

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

On 4 Oct 2003 at 8:02, David Abrahams wrote:

> > This probably leaves out virtual functions and may cause problems
> > with getting the address of overloaded methods. Still some support
> > for void * returns is better than none.
> 
> This isn't what I'd call "support for void* returns".  We should
> return and accept void*s as opaque pointers.

No it's a nasty hack to temporarily fix a problem. I agree opaque 
pointers should support void * but AFAICS the code currently doesn't 
support them. I thought you can specialise a template for <void> or 
something?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP39WvcEcvDLFGKbPEQJ/xwCg5na6/7SvjqchLRj9HSuvMkmog1IAniG5
diAwauiRC7Q5mgRP2U1OlM30
=0Do3
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sun Oct  5 01:30:21 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 00:30:21 +0100
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
In-Reply-To: <3F7F2DB5.8010901@globalite.com.br>
References: <ubrsx8aq0.fsf@boost-consulting.com>
Message-ID: <3F7F661D.22606.4A736DD@localhost>

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

On 4 Oct 2003 at 17:29, Nicodemus wrote:

> It's strange to have an operator that return float*. 8)
> 
> Have you tried set_policy(FXVec.operator['float*'], ...)?

Did better again, I hacked pyste to not generate any custom converter 
casts :) But thanks for the suggestion, it'll be useful elsewhere.

BTW Bruno what's your policy on others distributing modified versions 
of pyste. I fear with your rate of improvements, a diff file wouldn't 
last too long and I have the LGPL to satisfy.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP39YDsEcvDLFGKbPEQJL9wCgrdxohjIZfZRD3eAGpj9VsiOqePkAn3GW
SBNyS0HV42DhIk30DTIL1ft5
=Egf2
-----END PGP SIGNATURE-----



From nicodemus at globalite.com.br  Sun Oct  5 04:05:03 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 23:05:03 -0300
Subject: [C++-sig] Re: Pyste suggestion for handling returns of void *
In-Reply-To: <3F7F64CD.23648.4A213EC@localhost>
References: <3F7F64CD.23648.4A213EC@localhost>
Message-ID: <3F7F7C4F.9080502@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 4 Oct 2003 at 8:02, David Abrahams wrote:
>
>  
>
>>>This probably leaves out virtual functions and may cause problems
>>>with getting the address of overloaded methods. Still some support
>>>for void * returns is better than none.
>>>      
>>>
>>This isn't what I'd call "support for void* returns".  We should
>>return and accept void*s as opaque pointers.
>>    
>>
>
>No it's a nasty hack to temporarily fix a problem.
>

Why you think that? In your proposed solution, you wanted to ignore the 
returning void*, which I think it's worse, at least as an generic 
solution... you can always ignore the opaque pointer that is returned 
after all.

> I agree opaque 
>pointers should support void * but AFAICS the code currently doesn't 
>support them. I thought you can specialise a template for <void> or 
>something?
>

Hmm, I didn't know that.

Another solution that meets your idea (ignoring the returning void*) is 
generating wrapper functions, but that's certainly more work.




From nicodemus at globalite.com.br  Sun Oct  5 04:07:51 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 23:07:51 -0300
Subject: [C++-sig] Re: Pyste suggestion for handling returns of void *
In-Reply-To: <uhe2p8b30.fsf@boost-consulting.com>
References: <3F7E43D1.20996.393C77@localhost>
	<uhe2p8b30.fsf@boost-consulting.com>
Message-ID: <3F7F7CF7.7070906@globalite.com.br>

David Abrahams wrote:

>"Niall Douglas" <s_sourceforge at nedprod.com> writes:
>
>  
>
>>Boost.Python won't process a method returning void * nor will it 
>>permit you to set a typedef void *voidptrtype; to an opaque type :( 
>>Unfortunately some methods in my code return void *'s where you don't 
>>actually need the return value at all (it's just useful)! This makes 
>>things difficult for automated wraps.
>>
>>I suggest getting pyste to cast any methods returning a void * to 
>>return void instead. I figure most architectures return their value 
>>in a register so theroretically casting a function pointer to not 
>>return anything shouldn't cause stack frame corruption.
>>    
>>
>
>I hope Nicodemus will refuse to do that, since calling through such a
>cast function pointer causes undefined behavior.
>
><snip>
>  
>

A safe approach would be creating thin wrappers around the functions, 
but I don't like this idea... I think that automatically making the 
functions return an opaque pointer would be better.

>  
>
>>This probably leaves out virtual functions and may cause problems 
>>with getting the address of overloaded methods. Still some support 
>>for void * returns is better than none.
>>    
>>
>
>This isn't what I'd call "support for void* returns".  We should
>return and accept void*s as opaque pointers.
>

Agreed, if that's workable (in another message, Niall said that 
opaque_pointers didn't support void*)





From nicodemus at globalite.com.br  Sun Oct  5 04:17:44 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 23:17:44 -0300
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
In-Reply-To: <3F7F661D.22606.4A736DD@localhost>
References: <ubrsx8aq0.fsf@boost-consulting.com>
	<3F7F661D.22606.4A736DD@localhost>
Message-ID: <3F7F7F48.1050207@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 4 Oct 2003 at 17:29, Nicodemus wrote:
>
>  
>
>>It's strange to have an operator that return float*. 8)
>>
>>Have you tried set_policy(FXVec.operator['float*'], ...)?
>>    
>>
>
>Did better again, I hacked pyste to not generate any custom converter 
>casts :) But thanks for the suggestion, it'll be useful elsewhere.
>

Hmm, but if that's what you want, you could have excluded the operator:

exclude(FXVec.operator['float*'], ...)
?

>BTW Bruno what's your policy on others distributing modified versions 
>of pyste. 
>

Hmm, good question. I never discussed licensing with Dave since Pyste 
started to make part of Boost. I guess then Pyste is under the same 
license as Boost's. Is that right Dave?
I personally don't mind that you distribute this custom fixes of yours 
at all, but of course there are things that I would like to integrate 
into Pyste, so please continue to share your ideas and patches here! 8)

>I fear with your rate of improvements, a diff file wouldn't 
>last too long and I have the LGPL to satisfy.
>

"Improvements", "bug fixes", it's all the same. ;)

Regards,
Nicodemus




From s_sourceforge at nedprod.com  Sun Oct  5 04:26:18 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 03:26:18 +0100
Subject: [C++-sig] Pointers to simple types,
	arrays and arrays of pointers to types
Message-ID: <3F7F8F5A.25283.5484CA8@localhost>

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

My apologies if this is really simple. I did search ASPN and didn't 
get anything relevent after 20 mins, so ...

I have everything compiling except for eight of over 100 source files 
(thanks again to everyone here!). Most of these won't compile because 
some method returns a pointer to a simple type eg;

typedef unsigned long FXColor;

class FXImage
{
public:
    FXColor* getData() const;
};

using namespace boost::python;

void Export_FXImage()
{
    class_< FXImage >("FXImage")
		.def("getData", &FXImage::getData, return_internal_reference< 1 
>())
    ;
};

This won't compile because FXColor is not a class. Ideally I'd like 
the python side to be able to access the array of FXColor's being 
returned - no limits are needed because other methods return the 
length.

In other places still I have a find() function returning a pointer to 
a single float for example. In this situation I'd want the float to 
dereference to a float if the pointer is not null, otherwise return 
none. But if I use a thin wrapper, it can only return float and not 
none! :(

Lastly, some other methods return a type ** ie; an array of pointers 
to object instances. How on earth can this get wrapped? Is that 
indexing suite the right answer for these?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP3+BS8EcvDLFGKbPEQL3GACgp/x+bIF9eJ6D2ge202gv/WvqXHcAoM3U
GXynK12l5N07P/c78kGr4O82
=Af9Z
-----END PGP SIGNATURE-----



From nicodemus at globalite.com.br  Sun Oct  5 04:50:19 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 04 Oct 2003 23:50:19 -0300
Subject: [C++-sig] Pointers to simple types, arrays and arrays of pointers
	to types
In-Reply-To: <3F7F8F5A.25283.5484CA8@localhost>
References: <3F7F8F5A.25283.5484CA8@localhost>
Message-ID: <3F7F86EB.5020709@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>My apologies if this is really simple. I did search ASPN and didn't 
>get anything relevent after 20 mins, so ...
>
>I have everything compiling except for eight of over 100 source files 
>(thanks again to everyone here!). Most of these won't compile because 
>some method returns a pointer to a simple type eg;
>
>typedef unsigned long FXColor;
>
>class FXImage
>{
>public:
>    FXColor* getData() const;
>};
>
>using namespace boost::python;
>
>void Export_FXImage()
>{
>    class_< FXImage >("FXImage")
>		.def("getData", &FXImage::getData, return_internal_reference< 1 
>  
>
>>())
>>    
>>
>    ;
>};
>
>This won't compile because FXColor is not a class. Ideally I'd like 
>the python side to be able to access the array of FXColor's being 
>returned - no limits are needed because other methods return the 
>length.
>

I don't think that's possible, since ints are immutable... it would at 
least be very troublesome. 8/
Do you plan to change the values in Python? If not, create a wrapper 
that returns a list of ints. If you want to change it in Python, you 
will have to create a function setData, that receives a list of ints and 
changes the original array. Notice that this function can be present 
just in the binding, you don't have to code it for the C++ class. This 
interface seems more Pythonic to me. 8)

>In other places still I have a find() function returning a pointer to 
>a single float for example. In this situation I'd want the float to 
>dereference to a float if the pointer is not null, otherwise return 
>none. But if I use a thin wrapper, it can only return float and not 
>none! :(
>

The wonders of Boost.Python (untested):

PyObject* find_wrapper(MyClass* cl)
{
     float *res = cl.find();
     if (res == NULL) {
          Py_INCREF(Py_None);
          return Py_None;
     }
     else {
          return PyFloat_FromDouble((float)v);
     }
}

(I couldn't create a None using Boost Python's api, I tried object(NULL) 
but it didn't work... how can one do that?)

>Lastly, some other methods return a type ** ie; an array of pointers 
>to object instances. How on earth can this get wrapped? Is that 
>indexing suite the right answer for these?
>

I think creating wrappers is the solution here.

Regards,
Nicodemus.




From s_sourceforge at nedprod.com  Sun Oct  5 05:11:56 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 04:11:56 +0100
Subject: [C++-sig] Pointers to simple types,
	arrays and arrays of pointers	to types
In-Reply-To: <3F7F86EB.5020709@globalite.com.br>
References: <3F7F8F5A.25283.5484CA8@localhost>
Message-ID: <3F7F9A0C.15271.5721531@localhost>

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

On 4 Oct 2003 at 23:50, Nicodemus wrote:

> >This won't compile because FXColor is not a class. Ideally I'd like
> >the python side to be able to access the array of FXColor's being
> >returned - no limits are needed because other methods return the
> >length.
> 
> I don't think that's possible, since ints are immutable... it would at
> least be very troublesome. 8/ Do you plan to change the values in
> Python? If not, create a wrapper that returns a list of ints. If you
> want to change it in Python, you will have to create a function
> setData, that receives a list of ints and changes the original array.
> Notice that this function can be present just in the binding, you
> don't have to code it for the C++ class. This interface seems more
> Pythonic to me. 8)

Basically FXImage is an image - whereby you can alter it by drawing 
on it, or modifiying its bitmap directly. If you were to make copies 
into a list, it would be sure slow.

I think the best solution might be for it to return a wrapper class 
which provides operator[]. This may in fact solve all my problems.

> >Lastly, some other methods return a type ** ie; an array of pointers
> >to object instances. How on earth can this get wrapped? Is that
> >indexing suite the right answer for these?
> 
> I think creating wrappers is the solution here.

Agreed, cheers for the help. I'll try hacking together some code to 
do this tomorrow, and if acceptable it might be an idea for pyste.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP3+L/cEcvDLFGKbPEQIqwACdEll60itBK9fPqOJgkp+M7VGdZjQAoLZe
TZ3ssdaFLiCRv3+Wi8WTCwL9
=eYRy
-----END PGP SIGNATURE-----



From datafeedNOSPAM at SoftHome.net  Sun Oct  5 11:04:44 2003
From: datafeedNOSPAM at SoftHome.net (M. Evans)
Date: Sun, 5 Oct 2003 02:04:44 -0700
Subject: [C++-sig] Mahogany Email Client
Message-ID: <1308490140.20031005020444@SoftHome.net>


The C++ Mahogany project http://mahogany.sourceforge.net/index.html
offers the promise of an embedded Python interpreter for user
customization purposes.

The embedded Python interpreter is/was supported by SWIG, and seems to
impose more maintenance headaches than the Mahogany team wishes to
endure.
http://sourceforge.net/mailarchive/message.php?msg_id=6180833
http://sourceforge.net/mailarchive/message.php?msg_id=6183696

>From what I remember, the problems are more than just SWIG interface
file maintenance, but revolve around the mirroring of Mahogany's C++
objects in Python - which is Boost Python turf!

Anyone looking for a likely Boost Python project can help out
Mahogany.

Mark




From dave at boost-consulting.com  Sun Oct  5 14:30:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Oct 2003 08:30:58 -0400
Subject: [C++-sig] Re: Boost.Python bug
References: <ur81t8bb8.fsf@boost-consulting.com>
	<3F7F641B.13772.49F5C2F@localhost>
Message-ID: <upthbkgsd.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 4 Oct 2003 at 7:57, David Abrahams wrote:
>
>> > It complains "boost\boost\python\detail\invoke.hpp(76) : error
>> > C2064: term does not evaluate to a function taking 2 arguments"
>> 
>> That doesn't make it a Boost.Python bug.  It works with every other
>> compiler I've tried.
>
> Hang on: does this mean it didn't work on your MSVC7.1 either? 

Yes.

> I did spend some hours zeroing that down to a small repeatable
> example for you as you always request.

Thanks.

> Also, you know as well as I that the whole Boost library always
> works around compiler idiosyncracies where possible. While it isn't
> technically a BP bug, it does interfere with BP's implicit goal of
> being useful on all major compilers.

So, do you know of a workaround?

> If it can't be fixed, at least a FAQ entry saying it doesn't work due 
> to a bug in MSVC7.1 would be a good idea?

There are lots of corner cases which don't work on various compilers
due to bugs in the compilers.  I don't feel the need to document each
one that we discover.  HOwever, if you want to contribute an
appropriate doc patch I'll gladly check it in.

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




From rwgk at yahoo.com  Sun Oct  5 15:28:56 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 5 Oct 2003 06:28:56 -0700 (PDT)
Subject: [C++-sig] Pointers to simple types,
	arrays and arrays of pointers to types
In-Reply-To: <3F7F86EB.5020709@globalite.com.br>
Message-ID: <20031005132856.42015.qmail@web20204.mail.yahoo.com>

--- Nicodemus <nicodemus at globalite.com.br> wrote:
> The wonders of Boost.Python (untested):
> 
> PyObject* find_wrapper(MyClass* cl)
> {
>      float *res = cl.find();
>      if (res == NULL) {
>           Py_INCREF(Py_None);
>           return Py_None;
>      }
>      else {
>           return PyFloat_FromDouble((float)v);
>      }
> }
> 
> (I couldn't create a None using Boost Python's api, I tried object(NULL) 
> but it didn't work... how can one do that?)

The problem is that it is too easy:

boost::python::object none;

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From dave at boost-consulting.com  Sun Oct  5 19:35:02 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Oct 2003 13:35:02 -0400
Subject: [C++-sig] Re: Mahogany Email Client
References: <1308490140.20031005020444@SoftHome.net>
Message-ID: <uk77jk2pl.fsf@boost-consulting.com>

"M. Evans" <datafeedNOSPAM at SoftHome.net> writes:

> The C++ Mahogany project http://mahogany.sourceforge.net/index.html
> offers the promise of an embedded Python interpreter for user
> customization purposes.
>
> The embedded Python interpreter is/was supported by SWIG, and seems to
> impose more maintenance headaches than the Mahogany team wishes to
> endure.
> http://sourceforge.net/mailarchive/message.php?msg_id=6180833
> http://sourceforge.net/mailarchive/message.php?msg_id=6183696
>
>>From what I remember, the problems are more than just SWIG interface
> file maintenance, but revolve around the mirroring of Mahogany's C++
> objects in Python - which is Boost Python turf!
>
> Anyone looking for a likely Boost Python project can help out
> Mahogany.

If they'd fix the stupid message pane split which makes it squat and
wide I'd even be somewhat inclined to give them custom support.

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




From dave at boost-consulting.com  Sun Oct  5 20:39:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Oct 2003 14:39:56 -0400
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
References: <ubrsx8aq0.fsf@boost-consulting.com>
	<3F7F661D.22606.4A736DD@localhost>
	<3F7F7F48.1050207@globalite.com.br>
Message-ID: <u1xtrjzpf.fsf@boost-consulting.com>

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

> Hmm, good question. I never discussed licensing with Dave since Pyste
> started to make part of Boost. I guess then Pyste is under the same
> license as Boost's. Is that right Dave?

Pyste is under whichever license you have put in the source files.
Of course, it is supposed to be compatible with the Boost license
requirements, which you can find at
http://www.boost.org/more/lib_guide.htm#License

If you are willing, I would appreciate it if you would relicense all
of Pyste using 

# Copyright Bruno da Silva de Oliveira 2003. Use, modification and 
# distribution is subject to the Boost Software License, Version 1.0.
# (See accompanying file LICENSE_1_0.txt or copy at 
# http:#www.boost.org/LICENSE_1_0.txt)

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




From dave at boost-consulting.com  Sun Oct  5 20:42:20 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Oct 2003 14:42:20 -0400
Subject: [C++-sig] Re: Pointers to simple types,
 arrays and arrays of pointers to types
References: <3F7F8F5A.25283.5484CA8@localhost>
	<3F7F86EB.5020709@globalite.com.br>
Message-ID: <uvfr3il0z.fsf@boost-consulting.com>

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

> (I couldn't create a None using Boost Python's api, I tried
> object(NULL) but it didn't work... how can one do that?)

object()

does it.

object find_wrapper(MyClass& cl) // should be a reference
{
     if (float *res = cl.find())
        return object(*res);
     else
        return object();
}

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




From nicodemus at globalite.com.br  Sun Oct  5 21:08:48 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sun, 05 Oct 2003 16:08:48 -0300
Subject: [C++-sig] Pointers to simple types, arrays and arrays of pointers
	to types
In-Reply-To: <20031005132856.42015.qmail@web20204.mail.yahoo.com>
References: <20031005132856.42015.qmail@web20204.mail.yahoo.com>
Message-ID: <3F806C40.5070608@globalite.com.br>

Ralf W. Grosse-Kunstleve wrote:

>--- Nicodemus <nicodemus at globalite.com.br> wrote:
>  
>
>>The wonders of Boost.Python (untested):
>>
>>PyObject* find_wrapper(MyClass* cl)
>>{
>>     float *res = cl.find();
>>     if (res == NULL) {
>>          Py_INCREF(Py_None);
>>          return Py_None;
>>     }
>>     else {
>>          return PyFloat_FromDouble((float)v);
>>     }
>>}
>>
>>(I couldn't create a None using Boost Python's api, I tried object(NULL) 
>>but it didn't work... how can one do that?)
>>    
>>
>
>The problem is that it is too easy:
>
>boost::python::object none;
>  
>

Hah! Of course! Thanks Ralf and Dave. 8)




From nicodemus at globalite.com.br  Sun Oct  5 21:09:18 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sun, 05 Oct 2003 16:09:18 -0300
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
In-Reply-To: <u1xtrjzpf.fsf@boost-consulting.com>
References: <ubrsx8aq0.fsf@boost-consulting.com>	<3F7F661D.22606.4A736DD@localhost>	<3F7F7F48.1050207@globalite.com.br>
	<u1xtrjzpf.fsf@boost-consulting.com>
Message-ID: <3F806C5E.9000209@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>Hmm, good question. I never discussed licensing with Dave since Pyste
>>started to make part of Boost. I guess then Pyste is under the same
>>license as Boost's. Is that right Dave?
>>    
>>
>
>Pyste is under whichever license you have put in the source files.
>Of course, it is supposed to be compatible with the Boost license
>requirements, which you can find at
>http://www.boost.org/more/lib_guide.htm#License
>
>If you are willing, I would appreciate it if you would relicense all
>of Pyste using 
>
># Copyright Bruno da Silva de Oliveira 2003. Use, modification and 
># distribution is subject to the Boost Software License, Version 1.0.
># (See accompanying file LICENSE_1_0.txt or copy at 
># http:#www.boost.org/LICENSE_1_0.txt)
>
>Thanks,
>

Sure, will do. Thanks for the clarification.





From s_sourceforge at nedprod.com  Sun Oct  5 21:14:24 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 20:14:24 +0100
Subject: [C++-sig] Re: Boost.Python bug
In-Reply-To: <upthbkgsd.fsf@boost-consulting.com>
Message-ID: <3F807BA0.18892.8E33C53@localhost>

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

On 5 Oct 2003 at 8:30, David Abrahams wrote:

> > Also, you know as well as I that the whole Boost library always
> > works around compiler idiosyncracies where possible. While it isn't
> > technically a BP bug, it does interfere with BP's implicit goal of
> > being useful on all major compilers.
> 
> So, do you know of a workaround?

Yes, the obvious one:

using namespace boost::python;

class FXThread
{
public:
    bool setAutoDelete(bool doso) throw();
};

void Export_FXThread()
{
    class_< FXThread >("FXThread")
		.def("setAutoDelete", (bool (FXThread::*)(bool)) 
&FXThread::setAutoDelete)
    ;
}

You just need to cast off the throw(). This probably makes undefined 
behaviour though as some PCS's mangle their symbols differently for 
null throw()'s though TBH I can't see how any PCS could penalise you 
as the direction of effect is opposite.

> > If it can't be fixed, at least a FAQ entry saying it doesn't work
> > due to a bug in MSVC7.1 would be a good idea?
> 
> There are lots of corner cases which don't work on various compilers
> due to bugs in the compilers.  I don't feel the need to document each
> one that we discover.  HOwever, if you want to contribute an
> appropriate doc patch I'll gladly check it in.

Well I was more thinking of saving you time in having to deal with 
support which I know sucks time from any maintainer.

Does anyone know a MS compiler person who'd like to take this bug?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4BtkMEcvDLFGKbPEQKdJACfSmjSCaEMOfQhtEsbJcepVzTEHNcAnjap
66Qb3Z3LOSsmdJeB/JJczOWF
=+R3T
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sun Oct  5 22:19:51 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 21:19:51 +0100
Subject: [C++-sig] Re: Boost.Python bug
Message-ID: <3F808AF7.25188.91F28E7@localhost>

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

On 5 Oct 2003 at 8:30, David Abrahams wrote:

> > Also, you know as well as I that the whole Boost library always
> > works around compiler idiosyncracies where possible. While it
> > isn't technically a BP bug, it does interfere with BP's implicit
> > goal of being useful on all major compilers.
> 
> So, do you know of a workaround?

Yes, the obvious one:

using namespace boost::python;

class FXThread
{
public:
    bool setAutoDelete(bool doso) throw();
};

void Export_FXThread()
{
    class_< FXThread >("FXThread")
  .def("setAutoDelete", (bool (FXThread::*)(bool)) 
&FXThread::setAutoDelete)
    ;
}

You just need to cast off the throw(). This probably makes undefined
behaviour though as some PCS's mangle their symbols differently for
null throw()'s though TBH I can't see how any PCS could penalise you
as the direction of effect is opposite.

> > If it can't be fixed, at least a FAQ entry saying it doesn't work
> > due to a bug in MSVC7.1 would be a good idea?
> 
> There are lots of corner cases which don't work on various compilers
> due to bugs in the compilers.  I don't feel the need to document
> each one that we discover.  HOwever, if you want to contribute an
> appropriate doc patch I'll gladly check it in.

Well I was more thinking of saving you time in having to deal with
support which I know sucks time from any maintainer.

Does anyone know a MS compiler person who'd like to take this bug?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4B858EcvDLFGKbPEQI0zgCfQPt8Ni/LZSHi/4JJl/oh0H7Bz/AAnj0t
kmZ2NYUXy4byzp7XX5MyGNii
=1BJH
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Sun Oct  5 22:29:04 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Oct 2003 16:29:04 -0400
Subject: [C++-sig] Re: Boost.Python bug
References: <upthbkgsd.fsf@boost-consulting.com>
	<3F807BA0.18892.8E33C53@localhost>
Message-ID: <uad8fh1in.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 5 Oct 2003 at 8:30, David Abrahams wrote:
>
>> > Also, you know as well as I that the whole Boost library always
>> > works around compiler idiosyncracies where possible. While it isn't
>> > technically a BP bug, it does interfere with BP's implicit goal of
>> > being useful on all major compilers.
>> 
>> So, do you know of a workaround?
>
> Yes, the obvious one:
>
> using namespace boost::python;
>
> class FXThread
> {
> public:
>     bool setAutoDelete(bool doso) throw();
> };
>
> void Export_FXThread()
> {
>     class_< FXThread >("FXThread")
> 		.def("setAutoDelete", (bool (FXThread::*)(bool)) 
> &FXThread::setAutoDelete)
>     ;
> }
>
> You just need to cast off the throw(). This probably makes undefined 
> behaviour though as some PCS's mangle their symbols differently for 
> null throw()'s though TBH I can't see how any PCS could penalise you 
> as the direction of effect is opposite.

I'm sorry; I meant "do you know of a workaround I can use in the
Boost.Python internals?"

>> > If it can't be fixed, at least a FAQ entry saying it doesn't work
>> > due to a bug in MSVC7.1 would be a good idea?
>> 
>> There are lots of corner cases which don't work on various compilers
>> due to bugs in the compilers.  I don't feel the need to document each
>> one that we discover.  HOwever, if you want to contribute an
>> appropriate doc patch I'll gladly check it in.
>
> Well I was more thinking of saving you time in having to deal with
> support which I know sucks time from any maintainer.

Thanks, but if you really want to save me time, you'll submit the doc
patch.

> Does anyone know a MS compiler person who'd like to take this bug?

I already passed it along.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From s_sourceforge at nedprod.com  Sun Oct  5 22:37:42 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 05 Oct 2003 21:37:42 +0100
Subject: [C++-sig] Re: Boost.Python bug
In-Reply-To: <uad8fh1in.fsf@boost-consulting.com>
Message-ID: <3F808F26.31871.92F8169@localhost>

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

On 5 Oct 2003 at 16:29, David Abrahams wrote:

> > You just need to cast off the throw(). This probably makes undefined
> > behaviour though as some PCS's mangle their symbols differently for
> > null throw()'s though TBH I can't see how any PCS could penalise you
> > as the direction of effect is opposite.
> 
> I'm sorry; I meant "do you know of a workaround I can use in the
> Boost.Python internals?"

Unfortunately I don't understand how they work, and so I didn't know 
whether the obvious solution would work or not. I've patched pyste to 
add the relevent cast but that's no use to you.

> >> There are lots of corner cases which don't work on various
> >> compilers due to bugs in the compilers.  I don't feel the need to
> >> document each one that we discover.  HOwever, if you want to
> >> contribute an appropriate doc patch I'll gladly check it in.
> >
> > Well I was more thinking of saving you time in having to deal with
> > support which I know sucks time from any maintainer.
> 
> Thanks, but if you really want to save me time, you'll submit the doc
> patch.

I hate to sound stupid, but is a doc patch like a GNU diff of the 
documentation HTML? If so, do I email it to you?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4CBFsEcvDLFGKbPEQIvUwCdGSwGeprBkGOJbt9X6UoU+XmrexcAnR+L
nrhXazkjmKzAi4epJHt1SVo0
=CLyS
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Sun Oct  5 23:08:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Oct 2003 17:08:58 -0400
Subject: [C++-sig] Re: Boost.Python bug
References: <uad8fh1in.fsf@boost-consulting.com>
	<3F808F26.31871.92F8169@localhost>
Message-ID: <ufzi7fl3p.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> I hate to sound stupid, but is a doc patch like a GNU diff of the 
> documentation HTML? 

That's right.

> If so, do I email it to you?

Sure, as an attachment.  Or post it here, as an attachment.

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




From pierre.barbier at cirad.fr  Mon Oct  6 09:08:16 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 06 Oct 2003 09:08:16 +0200
Subject: [C++-sig] Re: Boost.Python and threads
In-Reply-To: <un0cidkho.fsf@boost-consulting.com>
References: <1065013082.663.61.camel@pbarbier>
	<un0cidkho.fsf@boost-consulting.com>
Message-ID: <1065424096.574.1.camel@pbarbier>

Le sam 04/10/2003 ? 00:28, David Abrahams a ?crit :
> 
> Sorry it took so long to reply Pierre; I was really hoping someone
> else (like Lijun) would answer.
> 
> Anyway, I don't have an implementation of multithreading support, at
> least not yet.
> 
> THe best way to safely unblock threads that I know of is to write a
> thin wrapper around your function which uses Py_BEGIN_ALLOW_THREADS
> and Py_END_ALLOW_THREADS around a call to the real function.
> 
> HTH,

Well, thanks, I think I'll use this solution for the 'all fonctions are
non-blocking' is not good for me :)

-- 
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 RaoulGough at yahoo.co.uk  Mon Oct  6 14:20:22 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 06 Oct 2003 13:20:22 +0100
Subject: [C++-sig] New indexing suite nearing review readiness
Message-ID: <u3ce6zhfd.fsf@yahoo.co.uk>

I'm almost ready to release the new indexing suite for general testing
and review. Documentation is now available from:

http://boost-sandbox.sourceforge.net/python/indexing/containers.html

In order to make the code generally usable, it will need some Jamfile
changes since there are two non-template .cpp modules, and I'm not
sure how best to go about this. The easiest way (for me) would be to
add the new .cpp files directly to the Boost CVS repository, probably
in the libs/python/src/object directory and update
libs/python/build/Jamfile.  I would also need to add some stuff to
libs/python/test (two .cpp modules and about ten .py
modules). Otherwise, I would probably have to update boost-sandbox to
the point where users can build Boost.Python out of there, but I think
that is probably not worth the effort. Any objections to just cramming
it into the real CVS at this stage?

BTW, the two .cpp modules in question are slice.cpp, which handles
Python slice objects and python_iterator.cpp that provides a (very)
basic interface to Python iterable objects, using internally either
__iter__ or __getitem__.

Also, I'll need to decide on the namespace name to put the suite
into. It is currently in ::indexing, but should probably go in
::boost::python::indexing or maybe better ::boost::python::container
so that it can co-exist with the existing indexing suite. Any comments
on this matter?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Mon Oct  6 15:18:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Oct 2003 09:18:22 -0400
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk>
Message-ID: <ud6da33oh.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> I'm almost ready to release the new indexing suite for general testing
> and review. Documentation is now available from:
>
> http://boost-sandbox.sourceforge.net/python/indexing/containers.html
>
> In order to make the code generally usable, it will need some Jamfile
> changes since there are two non-template .cpp modules, and I'm not
> sure how best to go about this. The easiest way (for me) would be to
> add the new .cpp files directly to the Boost CVS repository, probably
> in the libs/python/src/object directory and update
> libs/python/build/Jamfile.  I would also need to add some stuff to
> libs/python/test (two .cpp modules and about ten .py
> modules). Otherwise, I would probably have to update boost-sandbox to
> the point where users can build Boost.Python out of there, but I think
> that is probably not worth the effort. Any objections to just cramming
> it into the real CVS at this stage?

I think I'd like to leave that up to Joel, since he's been watching
your work more closely than I have.  Joel?

> BTW, the two .cpp modules in question are slice.cpp, which handles
> Python slice objects and python_iterator.cpp that provides a (very)
> basic interface to Python iterable objects, using internally either
> __iter__ or __getitem__.

Shouldn't that be called "iterable.cpp"?  We already have an
"iterator.cpp".

> Also, I'll need to decide on the namespace name to put the suite
> into. It is currently in ::indexing, but should probably go in
> ::boost::python::indexing or maybe better ::boost::python::container
> so that it can co-exist with the existing indexing suite. Any comments
> on this matter?

Not yet.  I think Joel had some ideas about how the namespaces should
look, so I guess I'll call on him for an opinion too.

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




From joel at boost-consulting.com  Mon Oct  6 17:23:24 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Mon, 6 Oct 2003 23:23:24 +0800
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk> <ud6da33oh.fsf@boost-consulting.com>
Message-ID: <00d901c38c1d$ccfe1650$64646464@godzilla>

David Abrahams <dave at boost-consulting.com> wrote:
> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
> 
>> I'm almost ready to release the new indexing suite for general testing
>> and review. Documentation is now available from:
>> 
>> http://boost-sandbox.sourceforge.net/python/indexing/containers.html

That's great, Raoul!

>> In order to make the code generally usable, it will need some Jamfile
>> changes since there are two non-template .cpp modules, and I'm not
>> sure how best to go about this. The easiest way (for me) would be to
>> add the new .cpp files directly to the Boost CVS repository, probably
>> in the libs/python/src/object directory and update
>> libs/python/build/Jamfile.  I would also need to add some stuff to
>> libs/python/test (two .cpp modules and about ten .py
>> modules). Otherwise, I would probably have to update boost-sandbox to
>> the point where users can build Boost.Python out of there, but I think
>> that is probably not worth the effort. Any objections to just cramming
>> it into the real CVS at this stage?
> 
> I think I'd like to leave that up to Joel, since he's been watching
> your work more closely than I have.  Joel?

I have no objections with that. I think it's a good idea to put it in the CVS.
How about a branch? Then when things settle down to a stable state, we
merge it to the HEAD?

>> BTW, the two .cpp modules in question are slice.cpp, which handles
>> Python slice objects and python_iterator.cpp that provides a (very)
>> basic interface to Python iterable objects, using internally either
>> __iter__ or __getitem__.
> 
> Shouldn't that be called "iterable.cpp"?  We already have an
> "iterator.cpp".
> 
>> Also, I'll need to decide on the namespace name to put the suite
>> into. It is currently in ::indexing, but should probably go in
>>>> boost::python::indexing or maybe better ::boost::python::container
>> so that it can co-exist with the existing indexing suite. Any comments
>> on this matter?
> 
> Not yet.  I think Joel had some ideas about how the namespaces should
> look, so I guess I'll call on him for an opinion too.

Why should it coexist? Shouldn't it fully replace the old?

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From RaoulGough at yahoo.co.uk  Mon Oct  6 17:44:09 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 06 Oct 2003 16:44:09 +0100
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk> <ud6da33oh.fsf@boost-consulting.com>
	<00d901c38c1d$ccfe1650$64646464@godzilla>
Message-ID: <uvfr2xtfa.fsf@yahoo.co.uk>

"Joel de Guzman" <joel at boost-consulting.com> writes:

> David Abrahams <dave at boost-consulting.com> wrote:
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>> 
>>> I'm almost ready to release the new indexing suite for general testing
>>> and review. Documentation is now available from:
>>> 
>>> http://boost-sandbox.sourceforge.net/python/indexing/containers.html
>
> That's great, Raoul!
>
>>> Any objections to just cramming it into the real CVS at this
>>> stage?
>> 
>> I think I'd like to leave that up to Joel, since he's been watching
>> your work more closely than I have.  Joel?
>
> I have no objections with that. I think it's a good idea to put it
> in the CVS.  How about a branch? Then when things settle down to a
> stable state, we merge it to the HEAD?

Sounds like a great idea to me. I've never created a branch in CVS
before, so I think I'll try it out in the sandbox first. Any advice on
putting a *new* file on a branch, so it doesn't immediately appear on
HEAD?

>
>>> BTW, the two .cpp modules in question are slice.cpp, which handles
>>> Python slice objects and python_iterator.cpp that provides a (very)
>>> basic interface to Python iterable objects, using internally either
>>> __iter__ or __getitem__.
>> 
>> Shouldn't that be called "iterable.cpp"?  We already have an
>> "iterator.cpp".
>> 
>>> Also, I'll need to decide on the namespace name to put the suite
>>> into. It is currently in ::indexing, but should probably go in
>>>>> boost::python::indexing or maybe better ::boost::python::container
>>> so that it can co-exist with the existing indexing suite. Any comments
>>> on this matter?
>> 
>> Not yet.  I think Joel had some ideas about how the namespaces should
>> look, so I guess I'll call on him for an opinion too.
>
> Why should it coexist? Shouldn't it fully replace the old?

Well, the only trouble is that the interface is different. From the
activity in this group, there are already a number of people using the
existing code, so I was thinking about providing a transition
period. By the sounds of it, you would prefer a clean break? I suppose
people can always use the older versions from CVS if they really have
to.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Mon Oct  6 18:00:28 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 06 Oct 2003 17:00:28 +0100
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk> <ud6da33oh.fsf@boost-consulting.com>
Message-ID: <ur81qxso3.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> BTW, the two .cpp modules in question are slice.cpp, which handles
>> Python slice objects and python_iterator.cpp that provides a (very)
>> basic interface to Python iterable objects, using internally either
>> __iter__ or __getitem__.
>
> Shouldn't that be called "iterable.cpp"?  We already have an
> "iterator.cpp".

Not too sure about this. The existing iterator.cpp doesn't actually
provide much in the way of iterator support, so maybe I should just
shoe-horn the stuff into the existing module?

BTW, since this would probably go into the main python library (as
opposed to just the container indexing portion), maybe the interface
needs some closer examination. It currently looks like this:

  struct python_iterator  {
    virtual ~python_iterator ();
    virtual bool next () = 0;
    virtual boost::python::object current() const = 0;
  };

Maybe a single "boost::python::object next()" function would be
preferable. The current interface is designed to insulate the caller
from the StopIteration and IndexError exceptions, hence the split into
two separate functions. From a different angle again, maybe an
STL-style iterator interface would be better. I originally wrote this
without considering the wider use that it could be good for. Comments?

Anyway, there are currently two implementations of this ABC, one for
objects with __iter__ and one for those with __getitem__. There's a
factory function to generate a suitable one automatically:

std::auto_ptr<python_iterator> make_iterator (boost::python::object);

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Mon Oct  6 18:13:37 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 06 Oct 2003 17:13:37 +0100
Subject: [C++-sig] Re: Pointers to simple types,
 arrays and arrays of pointers	to types
References: <3F7F8F5A.25283.5484CA8@localhost>
	<3F7F9A0C.15271.5721531@localhost>
Message-ID: <uk77ixs26.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

[snip]
> Basically FXImage is an image - whereby you can alter it by drawing 
> on it, or modifiying its bitmap directly. If you were to make copies 
> into a list, it would be sure slow.
>
> I think the best solution might be for it to return a wrapper class 
> which provides operator[]. This may in fact solve all my problems.

The new indexing suite provides support for this kind of thing. It has
a template called iterator_pair which would allow you to expose
iterator_pair<FXImage *> as a container type - with full indexing,
slicing, searching, etc..., but without insert or erase for obvious
reasons. I should be checking this in on a new CVS branch later today,
if your interested. Documentation is already online at

http://boost-sandbox.sourceforge.net/python/indexing/containers.html

I've just realized that iterator_pair is not yet documented. Will get
this updated, too.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From llywelyn.geo at yahoo.com  Mon Oct  6 18:21:45 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Mon, 6 Oct 2003 09:21:45 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with
	static/non-static overloading
In-Reply-To: <usmm9ale1.fsf@boost-consulting.com>
Message-ID: <20031006162145.53734.qmail@web41503.mail.yahoo.com>

Yup. You're right. My mistake.

--- David Abrahams <dave at boost-consulting.com> wrote:
> Joel Gerard <llywelyn.geo at yahoo.com> writes:
> 
> > Re (from way below):
> >> Please post a doc bug in the Python bug database.
> >> http://sourceforge.net/tracker/?group_id=5470
> >
> > Is this is the correct bug db?  I was referring to the Boost
> > docs. Is there a Boost bug db where I should log this?
> 
> I don't think it's Boost's job to document how to use regular Python
> static methods.  Or did you mean something else when you wrote:
> 
> >> >
> >> > Also, is there a good place to look for python examples. I didn't
> >> >see a python example in the docs
> 
> ??
> -- 
> 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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From joel at boost-consulting.com  Mon Oct  6 18:37:43 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Tue, 7 Oct 2003 00:37:43 +0800
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk>
	<ud6da33oh.fsf@boost-consulting.com><00d901c38c1d$ccfe1650$64646464@godzilla>
	<uvfr2xtfa.fsf@yahoo.co.uk>
Message-ID: <014901c38c28$2ee02d90$64646464@godzilla>

Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> "Joel de Guzman" <joel at boost-consulting.com> writes:

>> I have no objections with that. I think it's a good idea to put it
>> in the CVS.  How about a branch? Then when things settle down to a
>> stable state, we merge it to the HEAD?
> 
> Sounds like a great idea to me. I've never created a branch in CVS
> before, so I think I'll try it out in the sandbox first. Any advice on
> putting a *new* file on a branch, so it doesn't immediately appear on
> HEAD?

Pardon me but I don't quite understand what you mean. AFAIK, if you
place a new file on a branch, it doesn't immediately appear on HEAD
unless you merge it. 

>>>> Also, I'll need to decide on the namespace name to put the suite
>>>> into. It is currently in ::indexing, but should probably go in
>>>>>> boost::python::indexing or maybe better ::boost::python::container
>>>> so that it can co-exist with the existing indexing suite. Any comments
>>>> on this matter?
>>> 
>>> Not yet.  I think Joel had some ideas about how the namespaces should
>>> look, so I guess I'll call on him for an opinion too.
>> 
>> Why should it coexist? Shouldn't it fully replace the old?
> 
> Well, the only trouble is that the interface is different. From the
> activity in this group, there are already a number of people using the
> existing code, so I was thinking about providing a transition
> period. By the sounds of it, you would prefer a clean break? I suppose
> people can always use the older versions from CVS if they really have
> to.

I don't think the new interface is too great a departure from the original, is it? 
Anyway, would it be possible to have a transition API that mimics the old 
interface?

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From rwgk at yahoo.com  Mon Oct  6 18:55:07 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 Oct 2003 09:55:07 -0700 (PDT)
Subject: [C++-sig] Re: New indexing suite nearing review readiness
In-Reply-To: <uvfr2xtfa.fsf@yahoo.co.uk>
Message-ID: <20031006165507.47803.qmail@web20208.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> > I have no objections with that. I think it's a good idea to put it
> > in the CVS.  How about a branch? Then when things settle down to a
> > stable state, we merge it to the HEAD?
> 
> Sounds like a great idea to me. I've never created a branch in CVS
> before, so I think I'll try it out in the sandbox first. Any advice on
> putting a *new* file on a branch, so it doesn't immediately appear on
> HEAD?

Based on my past experience, working with branches in the given situation
creates more problems than it solves. Since I might want to play with the new
indexing suite I am strongly in favor of simply checking in the new files on
the HEAD.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From llywelyn.geo at yahoo.com  Mon Oct  6 19:09:14 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Mon, 6 Oct 2003 10:09:14 -0700 (PDT)
Subject: [C++-sig] Re: Returning reference to member variable that's a
	basic type
In-Reply-To: <u1xttc01r.fsf@boost-consulting.com>
Message-ID: <20031006170914.33393.qmail@web41509.mail.yahoo.com>

Hmmm... I see what you mean.  Couldn't you map an int reference to something like:

class IntegerReference :
    def __setattr__(self, name, value) :
        #BPL code here 
       
    def __getattr__ (self, name) :
        #BPL code here

Then you could do something like:
i = Obj.FnThatReturnsAnIntRef()
i.value = 45

IntegerReference would keep a pointer to the original integer (I'm assuming you can do this: keep
the address of the original variable as a python int or something, and then deference it in C?). 
Then set and get would deference the pointer, and get/set the value respectively.

It's a pity that one can't overload the assignment operator in python (not that I've seen anyhow).
 The "i.value" mechanism is not the cleanest, and I'd prefer to do "i=5" but I'd rather have some
mechanism than nothing.  Perhaps there is a better way. I fairly new to python.

Thanks for the quick response. ;)

Joel


--- David Abrahams <dave at boost-consulting.com> wrote:
> Joel Gerard <llywelyn.geo at yahoo.com> writes:
> 
> > I hope this doesn't get me the dumb question of the day award but...
> >
> > How do you return a pointer/reference to a member variable(a basic type) and modify it from
> > python?
> 
> You don't.  Basic types get mapped to Python ints, longs, and
> strings, all of which are immutable.  YOu can't modify them.
> 
> Decide what interface you'd like to see for this code in Python, code
> up a pure-Python mock-up which does what you want, and we can discuss
> how to achieve it with BPL.
> 
> -- 
> 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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From djowel at softhome.net  Mon Oct  6 19:44:09 2003
From: djowel at softhome.net (Joel de Guzman)
Date: Tue, 7 Oct 2003 01:44:09 +0800
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <20031006165507.47803.qmail@web20208.mail.yahoo.com>
Message-ID: <017b01c38c31$89177d50$64646464@godzilla>

Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
> --- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
>>> I have no objections with that. I think it's a good idea to put it
>>> in the CVS.  How about a branch? Then when things settle down to a
>>> stable state, we merge it to the HEAD?
>> 
>> Sounds like a great idea to me. I've never created a branch in CVS
>> before, so I think I'll try it out in the sandbox first. Any advice on
>> putting a *new* file on a branch, so it doesn't immediately appear on
>> HEAD?
> 
> Based on my past experience, working with branches in the given situation
> creates more problems than it solves. Since I might want to play with the new
> indexing suite I am strongly in favor of simply checking in the new files on
> the HEAD.

I've never had any problems with branches at all. I see no reason why you can't 
play with the new indexing suite while sitting on a separate branch.  My main
Boost (and Spirit) directory has directories from different branches. When I
find a branch stable, I merge it to the head. What "more problems" are you
referring to in particular?

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From rwgk at yahoo.com  Mon Oct  6 20:16:21 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 Oct 2003 11:16:21 -0700 (PDT)
Subject: [C++-sig] Re: New indexing suite nearing review readiness
In-Reply-To: <017b01c38c31$89177d50$64646464@godzilla>
Message-ID: <20031006181621.30410.qmail@web20210.mail.yahoo.com>

--- Joel de Guzman <djowel at softhome.net> wrote:
> I've never had any problems with branches at all. I see no reason why you
> can't 
> play with the new indexing suite while sitting on a separate branch.  My main
> Boost (and Spirit) directory has directories from different branches. When I
> find a branch stable, I merge it to the head. What "more problems" are you
> referring to in particular?

Never mind, if you have strong feelings I'll try to adjust.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From RaoulGough at yahoo.co.uk  Mon Oct  6 20:22:04 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 06 Oct 2003 19:22:04 +0100
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk> <ud6da33oh.fsf@boost-consulting.com>
	<00d901c38c1d$ccfe1650$64646464@godzilla> <uvfr2xtfa.fsf@yahoo.co.uk>
	<014901c38c28$2ee02d90$64646464@godzilla>
Message-ID: <ufzi6xm43.fsf@yahoo.co.uk>

"Joel de Guzman" <joel at boost-consulting.com> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
>> "Joel de Guzman" <joel at boost-consulting.com> writes:
>
>>> I have no objections with that. I think it's a good idea to put it
>>> in the CVS.  How about a branch? Then when things settle down to a
>>> stable state, we merge it to the HEAD?
>> 
>> Sounds like a great idea to me. I've never created a branch in CVS
>> before, so I think I'll try it out in the sandbox first. Any advice on
>> putting a *new* file on a branch, so it doesn't immediately appear on
>> HEAD?
>
> Pardon me but I don't quite understand what you mean. AFAIK, if you
> place a new file on a branch, it doesn't immediately appear on HEAD
> unless you merge it. 

My fault - I don't know anything about creating branches. IIUC, I
create the branch using tag -b, and must then switch my working
directory to that branch using update -r. After that, any "add" that I
do seems to pick up the branch automatically (presumably using the
CVS/Tag file). I've just been trying this out in boost-sandbox.

[snip]
>> Well, the only trouble is that the interface is different. From the
>> activity in this group, there are already a number of people using the
>> existing code, so I was thinking about providing a transition
>> period. By the sounds of it, you would prefer a clean break? I suppose
>> people can always use the older versions from CVS if they really have
>> to.
>
> I don't think the new interface is too great a departure from the
> original, is it?  Anyway, would it be possible to have a transition
> API that mimics the old interface?

OK. Thinking about this, the only real problem is the proxy support -
since it now relies on an external "container adapter", the suite
can't provide proxying internally. It might be possible to use
something like the pointer mapping in the existing proxy code to
inject a container proxy in place of the plain container. It would be
less work for me *not* to do this, of course. How valuable would this
compatibility be?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From joel at boost-consulting.com  Mon Oct  6 20:28:37 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Tue, 7 Oct 2003 02:28:37 +0800
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <20031006181621.30410.qmail@web20210.mail.yahoo.com>
Message-ID: <01b801c38c37$ab7f4340$64646464@godzilla>

Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
> --- Joel de Guzman <djowel at softhome.net> wrote:
>> I've never had any problems with branches at all. I see no reason why you
>> can't
>> play with the new indexing suite while sitting on a separate branch.  My main
>> Boost (and Spirit) directory has directories from different branches. When I
>> find a branch stable, I merge it to the head. What "more problems" are you
>> referring to in particular?
> 
> Never mind, if you have strong feelings I'll try to adjust.
> Ralf

Well, no, I don't have a strong objection. Really ;) It's just that when there are
2 potentially conflicting versions, one that will supersede the other, I find
branching as the cleanest approach. I'm not a CVS expert, however, so
I could be missing something that you guys already know.

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From RaoulGough at yahoo.co.uk  Mon Oct  6 20:30:01 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 06 Oct 2003 19:30:01 +0100
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <017b01c38c31$89177d50$64646464@godzilla>
	<20031006181621.30410.qmail@web20210.mail.yahoo.com>
Message-ID: <ubrsuxlqu.fsf@yahoo.co.uk>

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

> --- Joel de Guzman <djowel at softhome.net> wrote:
>> I've never had any problems with branches at all. I see no reason
>> why you can't play with the new indexing suite while sitting on a
>> separate branch.  My main Boost (and Spirit) directory has
>> directories from different branches. When I find a branch stable, I
>> merge it to the head. What "more problems" are you referring to in
>> particular?
>
> Never mind, if you have strong feelings I'll try to adjust.

Well, I'm a bit confused about this branching business. If I create a
branch on the files in (say) boost/python/suite/indexing/ and I then
do a cvs update -r my_new_branch in a parent directory, won't that then
delete all the files that don't *have* a my_new_branch?

[in directory /d/CVS/boost-sandbox/boost-sandbox/boost]

$ cvs update -r indexing_20031006 .
cvs server: Updating .
cvs server: any.hpp is no longer in the repository
cvs server: array_traits.hpp is no longer in the repository
cvs server: assign.hpp is no longer in the repository
cvs server: bigint.hpp is no longer in the repository
cvs server: bigint_gmp.hpp is no longer in the repository
cvs server: bit_reference.hpp is no longer in the repository
cvs server: bit_vector.hpp is no longer in the repository
[etc...]

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From joel at boost-consulting.com  Mon Oct  6 20:35:31 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Tue, 7 Oct 2003 02:35:31 +0800
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <u3ce6zhfd.fsf@yahoo.co.uk>
	<ud6da33oh.fsf@boost-consulting.com><00d901c38c1d$ccfe1650$64646464@godzilla>
	<uvfr2xtfa.fsf@yahoo.co.uk><014901c38c28$2ee02d90$64646464@godzilla>
	<ufzi6xm43.fsf@yahoo.co.uk>
Message-ID: <01c201c38c38$a4885080$64646464@godzilla>

Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> "Joel de Guzman" <joel at boost-consulting.com> writes:

>>> Well, the only trouble is that the interface is different. From the
>>> activity in this group, there are already a number of people using the
>>> existing code, so I was thinking about providing a transition
>>> period. By the sounds of it, you would prefer a clean break? I suppose
>>> people can always use the older versions from CVS if they really have
>>> to.
>> 
>> I don't think the new interface is too great a departure from the
>> original, is it?  Anyway, would it be possible to have a transition
>> API that mimics the old interface?
> 
> OK. Thinking about this, the only real problem is the proxy support -
> since it now relies on an external "container adapter", the suite
> can't provide proxying internally. It might be possible to use
> something like the pointer mapping in the existing proxy code to
> inject a container proxy in place of the plain container. It would be
> less work for me *not* to do this, of course. How valuable would this
> compatibility be?

If it's more than a few minutes work, then I'd say forget it. The question is:
would people object to an interface change? I won't object at all.
Objections? Comments?

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From joel at boost-consulting.com  Mon Oct  6 20:46:32 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Tue, 7 Oct 2003 02:46:32 +0800
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <017b01c38c31$89177d50$64646464@godzilla><20031006181621.30410.qmail@web20210.mail.yahoo.com>
	<ubrsuxlqu.fsf@yahoo.co.uk>
Message-ID: <01ce01c38c3a$2d9b4c50$64646464@godzilla>

Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
>> --- Joel de Guzman <djowel at softhome.net> wrote:
>>> I've never had any problems with branches at all. I see no reason
>>> why you can't play with the new indexing suite while sitting on a
>>> separate branch.  My main Boost (and Spirit) directory has
>>> directories from different branches. When I find a branch stable, I
>>> merge it to the head. What "more problems" are you referring to in
>>> particular?
>> 
>> Never mind, if you have strong feelings I'll try to adjust.
> 
> Well, I'm a bit confused about this branching business. If I create a
> branch on the files in (say) boost/python/suite/indexing/ and I then
> do a cvs update -r my_new_branch in a parent directory, won't that then
> delete all the files that don't *have* a my_new_branch?

Yes. But you should only update the sub-directory, not the parent.
I'm not sure, but perhaps there's a flag to make CVS not delete non-
branch files?

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From nicodemus at globalite.com.br  Mon Oct  6 20:46:20 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 15:46:20 -0300
Subject: [C++-sig] Re: Pyste bug: operator! shouldn't be translated
In-Reply-To: <u1xtrjzpf.fsf@boost-consulting.com>
References: <ubrsx8aq0.fsf@boost-consulting.com>	<3F7F661D.22606.4A736DD@localhost>	<3F7F7F48.1050207@globalite.com.br>
	<u1xtrjzpf.fsf@boost-consulting.com>
Message-ID: <3F81B87C.8080704@globalite.com.br>

David Abrahams wrote:

>Pyste is under whichever license you have put in the source files.
>Of course, it is supposed to be compatible with the Boost license
>requirements, which you can find at
>http://www.boost.org/more/lib_guide.htm#License
>
>If you are willing, I would appreciate it if you would relicense all
>of Pyste using 
>
># Copyright Bruno da Silva de Oliveira 2003. Use, modification and 
># distribution is subject to the Boost Software License, Version 1.0.
># (See accompanying file LICENSE_1_0.txt or copy at 
># http:#www.boost.org/LICENSE_1_0.txt)
>
>Thanks,
>  
>

Done, thanks for the clarification.

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Mon Oct  6 20:47:07 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 15:47:07 -0300
Subject: [C++-sig] Bug: Pyste misoutputs 64 bit ints on MSVC
In-Reply-To: <CB5E3CDDBE181A4D83176C606F03719708CC33@oak2kmail.stcg.net>
References: <CB5E3CDDBE181A4D83176C606F03719708CC33@oak2kmail.stcg.net>
Message-ID: <3F81B8AB.8060904@globalite.com.br>

Conan Brink wrote:

>There appear to be boost::int64_t and boost::uint64_t in
><boost/cstdint.hpp>, as part of the integer library, for those systems
>where they are not already defined in <stdint.h> (cstdint.hpp will
>include stdint.h if it is available, or typedef the various integer
>types for itself if not)
>  
>

Nice. Pyste now always uses boost::int64_t and boost::uint64_t.

Thanks,
Nicodemus.




From nicodemus at globalite.com.br  Mon Oct  6 20:48:20 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 15:48:20 -0300
Subject: [C++-sig] Two Pyste suggestions
In-Reply-To: <3F790228.7010503@globalite.com.br>
References: <3F78714E.30515.37576749@localhost>
	<3F790228.7010503@globalite.com.br>
Message-ID: <3F81B8F4.3020102@globalite.com.br>

Nicodemus wrote:

> Sure thing, it's in my TODO list. It should be ready tomorrow, with 
> some updated documentation (at last!).


It's in CVS now (--file-list="mylist.txt").

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Mon Oct  6 20:57:31 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 15:57:31 -0300
Subject: [C++-sig] Pyste bug: UniqueInt<> doesn't appear in all modules
	when	using --multiple
In-Reply-To: <3F7DCAA5.10212.4C3C642A@localhost>
References: <3F7DCAA5.10212.4C3C642A@localhost>
Message-ID: <3F81BB1B.4070500@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Can I suggest you simply always insert the following code instead:
>
>            write('// Unique type for unnamed enums\n')
>            write('#ifndef UNIQUEINTDEFINED')
>            write('#define UNIQUEINTDEFINED')
>            write('template<int num>\n')
>            write('struct UniqueInt {\n')
>            write('   int v;\n')
>            write('   enum { value=num };\n')
>            write('   UniqueInt(int v_):\n') 
>            write('       v(v_)\n')
>            write('   {}\n')
>            write('   operator int() const\n')
>            write('   { return v; }\n')
>            write('};\n')
>            write('#endif')
>
>Problem solved.
>  
>

Fixed, thanks for the suggestion. 8)

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Mon Oct  6 20:58:45 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 15:58:45 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F7CF5E9.12650.48FD659B@localhost>
References: <3F7CF5E9.12650.48FD659B@localhost>
Message-ID: <3F81BB65.8030605@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Basically, it's dead easy. You need to break the includes section 
>into two parts: common and specific.
>
>The common needs to be seperated from the specific with the following 
>code:
>
>#ifdef _MSC_VER
>#pragma hdrstop
>#endif
>
>This won't affect GCC, but it means on MSVC you can precompile the 
>common section (eg; boost/python.hpp) and it no longer needs to be 
>done repeatedly per file.
>

It is in CVS now (it only writes the pragma and the surrounding #ifdef 
on windows systems).

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Mon Oct  6 20:59:12 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 15:59:12 -0300
Subject: [C++-sig] pyste problem with AllFromHeader when -I is used
In-Reply-To: <200310031942.h93JgUI323817979@d0mino.fnal.gov>
References: <200310031942.h93JgUI323817979@d0mino.fnal.gov>
Message-ID: <3F81BB80.6010200@globalite.com.br>

scott snyder wrote:

>hi -
>
>I ran into an annoyance with the way AllFromHeader interacts with include
>search paths.  Specifically, if the header in question is found through
>an include path specified with -I then the header may not be processed.
>Here's an example:
><snip example>
>

Hi scott, thanks for the report. It is fixed in CVS.

Regards,
Nicodemus.




From dave at boost-consulting.com  Mon Oct  6 20:57:47 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Oct 2003 14:57:47 -0400
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <017b01c38c31$89177d50$64646464@godzilla>
	<20031006181621.30410.qmail@web20210.mail.yahoo.com>
	<ubrsuxlqu.fsf@yahoo.co.uk>
Message-ID: <u65j2xkgk.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
>
>> --- Joel de Guzman <djowel at softhome.net> wrote:
>>> I've never had any problems with branches at all. I see no reason
>>> why you can't play with the new indexing suite while sitting on a
>>> separate branch.  My main Boost (and Spirit) directory has
>>> directories from different branches. When I find a branch stable, I
>>> merge it to the head. What "more problems" are you referring to in
>>> particular?
>>
>> Never mind, if you have strong feelings I'll try to adjust.
>
> Well, I'm a bit confused about this branching business. If I create a
> branch on the files in (say) boost/python/suite/indexing/ and I then
> do a cvs update -r my_new_branch in a parent directory, won't that then
> delete all the files that don't *have* a my_new_branch?

Raoul,

have you seen http://cvsbook.red-bean.com/?
It explains all.

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




From rwgk at yahoo.com  Mon Oct  6 21:13:36 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 Oct 2003 12:13:36 -0700 (PDT)
Subject: [C++-sig] Re: New indexing suite nearing review readiness
In-Reply-To: <01c201c38c38$a4885080$64646464@godzilla>
Message-ID: <20031006191336.46193.qmail@web20202.mail.yahoo.com>

--- Joel de Guzman <joel at boost-consulting.com> wrote:
> Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> > "Joel de Guzman" <joel at boost-consulting.com> writes:
> 
> If it's more than a few minutes work, then I'd say forget it. The question
> is:
> would people object to an interface change? I won't object at all.
> Objections? Comments?

One voice: I've been following the indexing suite developement with the idea
that I could use it as a base for rewriting my own array bindings. However,
I've not yet done anything in practice, so to me innovation is much more
interesting than backwards compatibility.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From rwgk at yahoo.com  Mon Oct  6 21:39:32 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 Oct 2003 12:39:32 -0700 (PDT)
Subject: [C++-sig] Re: New indexing suite nearing review readiness
In-Reply-To: <u65j2xkgk.fsf@boost-consulting.com>
Message-ID: <20031006193932.96958.qmail@web20206.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Well, I'm a bit confused about this branching business. If I create a
> > branch on the files in (say) boost/python/suite/indexing/ and I then
> > do a cvs update -r my_new_branch in a parent directory, won't that then
> > delete all the files that don't *have* a my_new_branch?
> 
> Raoul,
> 
> have you seen http://cvsbook.red-bean.com/?
> It explains all.

Right. This is the title of the relevant section :)

Going Out On A Limb (How To Work With Branches And Survive)

I guess as a punishment for being vicious I should try to be constructive. When
I was writing "more problems" I had the following in mind:

- At some point I tried to branch individual files. I cannot remember the
details of all implications, but it was horrible. Ever since then my survial
rule #1 is "don't branch files, only branch complete sub-directory trees."

- Survival rule #2 was already offered by Joel, I believe: run the cvs update
-r command (following the cvs tag -b) only in the branched subdirectory. (After
this you can run cvs update from the top level as long as you don't specify a
-r again.)

This should get you a long way, but in my experience there is another problem
when you finally merge the branch. It has to do with files that

- existed on the HEAD at the point of branching
- and were later removed on the branch

These still exist on the HEAD after merging. To make sure you don't have stray
files after the merge keep a copy of the branch and run a diff -r branch_dir
merge_dir.

Final point: if someone updates files on the HEAD you will not see these
changes on the branch unless you explicitly merge them. If you maintain a
branch for a long time this can become very cumbersome. This leads to my
survival rule #3: branch only at the latest point possible.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From rwgk at yahoo.com  Mon Oct  6 21:52:10 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 Oct 2003 12:52:10 -0700 (PDT)
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F81BB65.8030605@globalite.com.br>
Message-ID: <20031006195210.41024.qmail@web20209.mail.yahoo.com>

--- Nicodemus <nicodemus at globalite.com.br> wrote:
> >#ifdef _MSC_VER
> >#pragma hdrstop
> >#endif
> >
> It is in CVS now (it only writes the pragma and the surrounding #ifdef 
> on windows systems).

Not that I am using Pyste at the moment, but if I did I'd want to reuse the
Pyste output on platforms that don't have gcc-xml. I.e. under Windows I am
exclusively working with Visual C++ and I don't even have plain gcc available.
Therefore it would be nice if the Pyste output could be exactly the same on all
platforms. -- Too much wishful thinking?
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From guillon at myrealbox.com  Mon Oct  6 22:18:02 2003
From: guillon at myrealbox.com (Guillermo Narvaja)
Date: Mon, 6 Oct 2003 17:18:02 -0300
Subject: [C++-sig] Howto build a Boost.Python object that wraps a C++ class
Message-ID: <PDECLGCDHEHOGKAGOJDJAEIACCAA.guillon@myrealbox.com>

Hi, I'm new using Boost.Python. I ask for help with the following trouble:

I want to build a Python object that wraps a C++ class with an instance of
that class. Here is the code of what I tried...

I define a Python Module like this:

BOOST_PYTHON_MODULE(test)
{
	class_<Widget>( "Widget", init<int>() )
		.def( init<const Widget &>() )
		.def( "doSomething", &Widget::doSomething );
}

>From another module(.exe), I want to embed python code (in this example, a
function that receives 2 widgets and returns an int). I tried the following:

// Imports a module with a function that receives 2 widgets
object module( handle<>( PyImport_Import( boost::python::str(
"module_with_widgetfn" ).ptr() ) ) );
object test_module( handle<>( PyImport_Import( boost::python::str(
"test" ).ptr() ) ) );
// Get dictionaries from those modules
dict moduleDict( boost::python::detail::borrowed_reference(
PyModule_GetDict( module.ptr() ) ) );
dict testModuleDict( boost::python::detail::borrowed_reference(
PyModule_GetDict( test_module.ptr() ) ) );

object fnFoo = moduleDict.get( "foo" ); // Get the foo function object
object Widget_class = testModuleDict.get( "Widget" ); // To get the foo
class
object aPy( Widget_class( 1 ) ); // works
Widget b( 1 );
object bPy( Widget_class( b ) ); // ---->>DOESN'T WORKS, throws
error_already_set
int result = call< int >( fnFoo.ptr(), aPy, bPy );




From nicodemus at globalite.com.br  Mon Oct  6 23:32:18 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 06 Oct 2003 18:32:18 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <20031006195210.41024.qmail@web20209.mail.yahoo.com>
References: <20031006195210.41024.qmail@web20209.mail.yahoo.com>
Message-ID: <3F81DF62.8070308@globalite.com.br>

Ralf W. Grosse-Kunstleve wrote:

>--- Nicodemus <nicodemus at globalite.com.br> wrote:
>  
>
>>>#ifdef _MSC_VER
>>>#pragma hdrstop
>>>#endif
>>>
>>>      
>>>
>>It is in CVS now (it only writes the pragma and the surrounding #ifdef 
>>on windows systems).
>>    
>>
>
>Not that I am using Pyste at the moment, but if I did I'd want to reuse the
>Pyste output on platforms that don't have gcc-xml. I.e. under Windows I am
>exclusively working with Visual C++ and I don't even have plain gcc available.
>Therefore it would be nice if the Pyste output could be exactly the same on all
>platforms. -- Too much wishful thinking?
>

Actually, the precompiled header directive is guarded by an ifdef that 
tests for a define that only the msvc compiler uses:

#ifdef _MSC_VER
#pragma hdrstop
#endif

So it is harmless on other platforms. But I see that you want to generate the code on unix and compile it on windows, right? Well, we could implement a --msvc option, I just didn't thought about that. 8)

Opinions?






From rwgk at yahoo.com  Tue Oct  7 00:25:05 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 6 Oct 2003 15:25:05 -0700 (PDT)
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F81DF62.8070308@globalite.com.br>
Message-ID: <20031006222505.82591.qmail@web20202.mail.yahoo.com>

--- Nicodemus <nicodemus at globalite.com.br> wrote:
> So it is harmless on other platforms. But I see that you want to generate the
> code on unix and compile it on windows, right?

Ideally I'd run Pyste only on one platform (whatever is most convenient at a
given time) and use the exact same Pyste output everywhere else.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From mike at nospam.com  Tue Oct  7 00:29:48 2003
From: mike at nospam.com (Mike Rovner)
Date: Mon, 6 Oct 2003 15:29:48 -0700
Subject: [C++-sig] Re: Pyste suggestion: MSVC precompiled headers support
References: <20031006195210.41024.qmail@web20209.mail.yahoo.com>
	<3F81DF62.8070308@globalite.com.br>
Message-ID: <blsqcp$56b$1@sea.gmane.org>

Nicodemus wrote:
> Ralf W. Grosse-Kunstleve wrote:
>> Pyste output could be exactly the same on all platforms. -- Too much
>> wishful thinking?
> could implement a --msvc option, I just didn't thought about that. 8)
> Opinions?

Ralf suggested and I second opinion that generated code shall be exactly
same and
not depends on the platform it was generated. All neccessary platform
dependancies
shall be included in the code itself like the PCH example garded by #if
directives.

Another approach was suggested some time ago - deeply integrate pyste and
BPL so
that pyste (python) can actualy be used (almost) instead of C preprocessor.
For now AIUC it's too far fetched.

Mike






From dave at boost-consulting.com  Tue Oct  7 01:52:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Oct 2003 19:52:14 -0400
Subject: [C++-sig] Re: Howto build a Boost.Python object that wraps a C++
	class
References: <PDECLGCDHEHOGKAGOJDJAEIACCAA.guillon@myrealbox.com>
Message-ID: <uisn1vs9d.fsf@boost-consulting.com>

"Guillermo Narvaja" <guillon at myrealbox.com> writes:

> Hi, I'm new using Boost.Python. I ask for help with the following trouble:
>
> I want to build a Python object that wraps a C++ class with an instance of
> that class. Here is the code of what I tried...
>
> I define a Python Module like this:
>
> BOOST_PYTHON_MODULE(test)
> {
> 	class_<Widget>( "Widget", init<int>() )
> 		.def( init<const Widget &>() )
> 		.def( "doSomething", &Widget::doSomething );
> }
>
>>From another module(.exe), I want to embed python code (in this example, a
> function that receives 2 widgets and returns an int). I tried the following:
>
> // Imports a module with a function that receives 2 widgets
> object module( handle<>( PyImport_Import( boost::python::str(
> "module_with_widgetfn" ).ptr() ) ) );
> object test_module( handle<>( PyImport_Import( boost::python::str(
> "test" ).ptr() ) ) );
> // Get dictionaries from those modules
> dict moduleDict( boost::python::detail::borrowed_reference(
> PyModule_GetDict( module.ptr() ) ) );
> dict testModuleDict( boost::python::detail::borrowed_reference(
> PyModule_GetDict( test_module.ptr() ) ) );

> object fnFoo = moduleDict.get( "foo" ); // Get the foo function object
> object Widget_class = testModuleDict.get( "Widget" ); // To get the foo

Why bother with that?

  object fnFoo = module.attr("foo");
  object Widget_class = testModule.attr("Widget");

is cleaner and simpler.

> class
> object aPy( Widget_class( 1 ) ); // works
> Widget b( 1 );
> object bPy( Widget_class( b ) ); // ---->>DOESN'T WORKS, throws
> error_already_set

error_already_set corresponds to some Python exception.  Which Python
exception is being raised?  libs/python/test/embedding.cpp shows how
to report that exception.

> int result = call< int >( fnFoo.ptr(), aPy, bPy );

  int result = extract<int>(fnFoo(aPy,bPy));

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




From s_sourceforge at nedprod.com  Tue Oct  7 01:09:20 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 07 Oct 2003 00:09:20 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F81BB65.8030605@globalite.com.br>
References: <3F7CF5E9.12650.48FD659B@localhost>
Message-ID: <3F820430.22562.EE0AE37@localhost>

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

On 6 Oct 2003 at 15:58, Nicodemus wrote:

> >#ifdef _MSC_VER
> >#pragma hdrstop
> >#endif
> >
> >This won't affect GCC, but it means on MSVC you can precompile the
> >common section (eg; boost/python.hpp) and it no longer needs to be
> >done repeatedly per file.
> 
> It is in CVS now (it only writes the pragma and the surrounding #ifdef
> on windows systems).

How did you separate the two sets of header files?

There will be a few eg; boost/python.hpp which will be common to all 
source files. These can be precompiled.

There will however be other specified by Include() which are in some 
and not others. These would be "forgotten" by MSVC if they appear 
before the #pragma hdrstop.

I would suggest Include() for per-file includes and CommonInclude() 
for the cross-module includes. Then even better you can have your 
converter registering modules (I call mine _regconvs) generate your 
precompiled headers for you which saves another ten seconds :)

(BTW I've not forgotten the C array access class, right now I'm 
getting to grips with scons (python based make system) so I can 
finally compile two files at once and use all my processor space).

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4H2IMEcvDLFGKbPEQJDOgCfbnXBCVqhEOKqk+zoDsizEUN8yKYAoKVb
Y8AbpXbmGd+lr1YjKc4MIjcW
=fm4o
-----END PGP SIGNATURE-----



From niki at vintech.bg  Tue Oct  7 10:09:45 2003
From: niki at vintech.bg (Niki Spahiev)
Date: Tue, 07 Oct 2003 11:09:45 +0300
Subject: [C++-sig] Re: New indexing suite nearing review readiness
In-Reply-To: <20031006193932.96958.qmail@web20206.mail.yahoo.com>
References: <20031006193932.96958.qmail@web20206.mail.yahoo.com>
Message-ID: <3F8274C9.8020907@vintech.bg>

Ralf W. Grosse-Kunstleve wrote:

> Final point: if someone updates files on the HEAD you will not see these
> changes on the branch unless you explicitly merge them. If you maintain a
> branch for a long time this can become very cumbersome. This leads to my
> survival rule #3: branch only at the latest point possible.

rule #4: If you plan to merge more than once tag in *branch* before and 
after each merge.

HTH
Niki Spahiev




From xavier.warin at der.edfgdf.fr  Tue Oct  7 11:33:10 2003
From: xavier.warin at der.edfgdf.fr (Xavier WARIN(Compte LOCAL) - I23)
Date: Tue, 07 Oct 2003 11:33:10 +0200
Subject: [C++-sig] Run time error with Boost python with MVC 7 
Message-ID: <3F828856.5080403@der.edfgdf.fr>

Hi,


I have compiled the pickle1.cpp test (included in the distribution) in 
boost 1.30.2 with VC7 in .net2003 on windows 2000 server pack3. I use 
python 2.2.3 and i get a very weird error while using pickle1_ext module.
THe following example works fine :


C:\boost-1.30.2\libs\python\test\TEST_PICKLE1\Release>c:/python22/python
Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pickle1_ext
 >>> a=pickle1_ext.world("ettc")
 >>> a.greet()
'Hello from ettc!'
 >>>


The second one  gives me a  "c:/python22/python.exe  Runtime error..." 
while leaving python

C:\boost-1.30.2\libs\python\test\TEST_PICKLE1\Release>c:/python22/python
Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pickle1_ext
 >>> a=pickle1_ext.world("ettc")
 >>> a=pickle1_ext.world("ettc")

I'm not very familiar with windows and i don't know what to do.
Any idea ? Is it a bug ?
Thank you for your help


Xavier Warin





From dave at boost-consulting.com  Tue Oct  7 13:44:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 07 Oct 2003 07:44:46 -0400
Subject: [C++-sig] Re: New indexing suite nearing review readiness
References: <20031006193932.96958.qmail@web20206.mail.yahoo.com>
	<3F8274C9.8020907@vintech.bg>
Message-ID: <uvfr1qnkh.fsf@boost-consulting.com>

Niki Spahiev <niki at vintech.bg> writes:

> Ralf W. Grosse-Kunstleve wrote:
>
>> Final point: if someone updates files on the HEAD you will not see these
>> changes on the branch unless you explicitly merge them. If you maintain a
>> branch for a long time this can become very cumbersome. This leads to my
>> survival rule #3: branch only at the latest point possible.
>
> rule #4: If you plan to merge more than once tag in *branch* before
> and after each merge.

If you're doing multiple merges from head to branch, tagging in HEAD
is more useful than tagging in branch, it seems to me.  Tagging
before the merge doesn't seem to have much advantage either, at least
to me.

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




From niki at vintech.bg  Tue Oct  7 16:06:43 2003
From: niki at vintech.bg (Niki Spahiev)
Date: Tue, 07 Oct 2003 17:06:43 +0300
Subject: [C++-sig] Re: New indexing suite nearing review readiness
In-Reply-To: <uvfr1qnkh.fsf@boost-consulting.com>
References: <20031006193932.96958.qmail@web20206.mail.yahoo.com>	<3F8274C9.8020907@vintech.bg>
	<uvfr1qnkh.fsf@boost-consulting.com>
Message-ID: <3F82C873.90307@vintech.bg>

David Abrahams wrote:
> Niki Spahiev <niki at vintech.bg> writes:
> 
> 
>>Ralf W. Grosse-Kunstleve wrote:
>>
>>
>>>Final point: if someone updates files on the HEAD you will not see these
>>>changes on the branch unless you explicitly merge them. If you maintain a
>>>branch for a long time this can become very cumbersome. This leads to my
>>>survival rule #3: branch only at the latest point possible.
>>
>>rule #4: If you plan to merge more than once tag in *branch* before
>>and after each merge.
> 
> 
> If you're doing multiple merges from head to branch, tagging in HEAD
> is more useful than tagging in branch, it seems to me.  Tagging
> before the merge doesn't seem to have much advantage either, at least
> to me.
> 

Sorry if it's not clear. I meant merges from branch to head.

Niki Spahiev




From RaoulGough at yahoo.co.uk  Tue Oct  7 20:10:42 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 07 Oct 2003 19:10:42 +0100
Subject: [C++-sig] New indexing suite available on indexing_v2 branch
Message-ID: <uhe2k2a1p.fsf@yahoo.co.uk>

I've committed the new indexing suite code on a CVS branch called
"indexing_v2" in the boost sub-directories boost/python/suite/indexing
and libs/python (only). You will need an up-to-date checkout of CVS,
and can then get the trial code by executing (in the top-level CVS
directory)

cvs update -d -r indexing_v2 boost/python/suite/indexing libs/python

Of course, you can switch back with

cvs update -A -P boost/python/suite/indexing libs/python

Documentation is in libs/python/doc/v2/containers.html and there are
some tests in libs/python/test (have a look at testlinear.cpp and
testnonlinear.cpp, also test_vector_*.py etc.)

AFAIK, this code has only been testing on MinGW g++ 3.3.1 so please
report any results on other platforms ASAP.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From rwgk at yahoo.com  Tue Oct  7 23:25:49 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 7 Oct 2003 14:25:49 -0700 (PDT)
Subject: [C++-sig] New indexing suite available on indexing_v2 branch
In-Reply-To: <uhe2k2a1p.fsf@yahoo.co.uk>
Message-ID: <20031007212549.17452.qmail@web20203.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> AFAIK, this code has only been testing on MinGW g++ 3.3.1 so please
> report any results on other platforms ASAP.

The new files (slice.cpp and python_iterator.cpp) compile fine with EDG 245 and
EDG 300. That's a very good sign because these front ends are very strict.
However, compilation of testlinear.cpp and testnonlinear.cpp fails with a long
list of errors. To clear up some of them I made a couple of trivial changes to
IntWrapper.hpp (already in CVS). The remaining errors from compiling
testlinear.cpp with the Tru64 cxx compiler (EDG 245 front end) are here:

http://cci.lbl.gov/~rwgk/tmp/testlinear_errors_tru64_cxx

I'd be happy to give you access to our machines if you think this could be
useful for fixing the portability problems. We have all the platforms
advertised at http://cci.lbl.gov/cctbx_build/ plus Intel C++ 7.1 under Linux
(EDG 300).

BTW: Don't feel bad about the many errors. It is completely normal when you try
a new platform for the first time, and I've seen worse. Over the last couple of
years I've spent months worth of my time making sure Boost.Python works on so
many platforms. But I am confident it will not take that long this time.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From RaoulGough at yahoo.co.uk  Wed Oct  8 01:26:50 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 08 Oct 2003 00:26:50 +0100
Subject: [C++-sig] Re: New indexing suite available on indexing_v2 branch
References: <uhe2k2a1p.fsf@yahoo.co.uk>
	<20031007212549.17452.qmail@web20203.mail.yahoo.com>
Message-ID: <ud6d81vet.fsf@yahoo.co.uk>

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

> --- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
>> AFAIK, this code has only been testing on MinGW g++ 3.3.1 so please
>> report any results on other platforms ASAP.
>
> The new files (slice.cpp and python_iterator.cpp) compile fine with
> EDG 245 and EDG 300. That's a very good sign because these front
> ends are very strict.  However, compilation of testlinear.cpp and
> testnonlinear.cpp fails with a long list of errors. To clear up some
> of them I made a couple of trivial changes to IntWrapper.hpp
> (already in CVS).
> The remaining errors from compiling testlinear.cpp with the Tru64
> cxx compiler (EDG 245 front end) are here:
>
> http://cci.lbl.gov/~rwgk/tmp/testlinear_errors_tru64_cxx

Wow! Thanks very much for helping out so quickly. Very interesting
results, some of them look like real errors in the code that g++
didn't pick up, others could be because g++ already implements some
proposed language changes (e.g. nested classes are implicitly
friends). I won't get to look at this in depth until the morning (UK
time).

Looking at the changes to IntWrapper.hpp... I guess operator!= might
well be needed somewhere, depending on the standard library
implementation, but what does including <stdio.h> fix?

>
> I'd be happy to give you access to our machines if you think this
> could be useful for fixing the portability problems. We have all the
> platforms advertised at http://cci.lbl.gov/cctbx_build/ plus Intel
> C++ 7.1 under Linux (EDG 300).

That's a great offer - I'm sure it would save a lot of time. Could
you send me some details via email?

>
> BTW: Don't feel bad about the many errors. It is completely normal
> when you try a new platform for the first time, and I've seen
> worse. Over the last couple of years I've spent months worth of my
> time making sure Boost.Python works on so many platforms. But I am
> confident it will not take that long this time.

I more or less expected there to be compatibility issues, given the
amount of template code in there, and my lack of experience with this
on other platforms. The list of errors from tru64 is already a big
help, but if you can provide access to the machines, or even just try
out some future changes, I'm sure we can sort these out fairly
quickly. It's getting kind of late here though, so I'll take another
look in the morning.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From snyder at fnal.gov  Wed Oct  8 01:52:24 2003
From: snyder at fnal.gov (scott snyder)
Date: Tue, 07 Oct 2003 18:52:24 -0500
Subject: [C++-sig] problem with declaring a pyste wrapper for a method in a
	nested class
Message-ID: <200310072352.h97NqOI370340585@d0mino.fnal.gov>


hi -

I've run into a problem with declaring a pyste wrapper for a method
in a nested class.

Here's an example.


-- x.h --------------------------------------------------------------
struct A
{
  struct B
  {
    void foo();
  };
};
-- x.pyste ----------------------------------------------------------
A = Class ("A", "x.h")
foo_wrapper = Wrapper("foo_wrapper", "xxxfoo")
set_wrapper (A.B.foo, foo_wrapper)
---------------------------------------------------------------------

If i run pyste on this, here's the output:

// Boost Includes ==============================================================
#include <boost/python.hpp>
#include <boost/cstdint.hpp>

// Includes ====================================================================
#include <x.h>

// Using =======================================================================
using namespace boost::python;

// Module ======================================================================
BOOST_PYTHON_MODULE(x)
{
    scope* A_scope = new scope(
    class_< A >("A", init<  >())
        .def(init< const A& >())
    );

    class_< A::B >("B", init<  >())
        .def(init< const A::B& >())
        .def("foo", &foo_wrapper)
    ;

    delete A_scope;

}



Here, pyste has generated the reference to the wrapper, in the line

        .def("foo", &foo_wrapper)


But it has not inserted the requested wrapper text ('xxxfoo' in this example).

A fix follows.
thanks,
sss


Index: ClassExporter.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/pyste/src/Pyste/ClassExporter.py,v
retrieving revision 1.14
diff -u -p -r1.14 ClassExporter.py
--- ClassExporter.py	6 Oct 2003 19:10:50 -0000	1.14
+++ ClassExporter.py	7 Oct 2003 23:46:24 -0000
@@ -189,6 +189,8 @@ class ClassExporter(Exporter):
         if declarations:
             codeunit.Write('declaration', declarations + '\n')
         declarations_outside = '\n'.join(self.sections['declaration-outside'])
+        for nested_unit in nested_codeunits:
+            declarations_outside += nested_unit.Section('declaration-outside')
         if declarations_outside:
             codeunit.Write('declaration-outside', declarations_outside + '\n')




From rwgk at yahoo.com  Wed Oct  8 02:58:48 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 7 Oct 2003 17:58:48 -0700 (PDT)
Subject: [C++-sig] Re: New indexing suite available on indexing_v2 branch
In-Reply-To: <ud6d81vet.fsf@yahoo.co.uk>
Message-ID: <20031008005848.51817.qmail@web20209.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> Looking at the changes to IntWrapper.hpp... I guess operator!= might
> well be needed somewhere, depending on the standard library
> implementation, but what does including <stdio.h> fix?

It brings in the declaration of printf which the cxx compiler does not know
about otherwise (correctly so, I believe).

> That's a great offer - I'm sure it would save a lot of time. Could
> you send me some details via email?

Will do.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From nicodemus at globalite.com.br  Wed Oct  8 04:26:31 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 07 Oct 2003 23:26:31 -0300
Subject: [C++-sig] problem with declaring a pyste wrapper for a method
	in a	nested class
In-Reply-To: <200310072352.h97NqOI370340585@d0mino.fnal.gov>
References: <200310072352.h97NqOI370340585@d0mino.fnal.gov>
Message-ID: <3F8375D7.9050500@globalite.com.br>

Hi Scott,

scott snyder wrote:

>hi -
>
>I've run into a problem with declaring a pyste wrapper for a method
>in a nested class.
>
>Here's an example.
><snip example and patch>
>  
>

Thanks a lot for the simple reproductive case (which is always 
appreciated) and even more for the patch. 8)

I will commit this stuff tomorrow, is a little late now in here.

Thanks again,
Nicodemus.




From nicodemus at globalite.com.br  Wed Oct  8 04:29:12 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 07 Oct 2003 23:29:12 -0300
Subject: [C++-sig] Re: Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <blsqcp$56b$1@sea.gmane.org>
References: <20031006195210.41024.qmail@web20209.mail.yahoo.com>	<3F81DF62.8070308@globalite.com.br>
	<blsqcp$56b$1@sea.gmane.org>
Message-ID: <3F837678.1040905@globalite.com.br>

Mike Rovner wrote:

>Nicodemus wrote:
>  
>
>>Ralf W. Grosse-Kunstleve wrote:
>>    
>>
>>>Pyste output could be exactly the same on all platforms. -- Too much
>>>wishful thinking?
>>>      
>>>
>>could implement a --msvc option, I just didn't thought about that. 8)
>>Opinions?
>>    
>>
>
>Ralf suggested and I second opinion that generated code shall be exactly
>same and
>not depends on the platform it was generated. All neccessary platform
>dependancies
>shall be included in the code itself like the PCH example garded by #if
>directives.
>

Hmm, I agree. I just did this change because I thought it would make the 
code ugly for people (though harmless) that didn't use msvc. I will make 
this change then.

>Another approach was suggested some time ago - deeply integrate pyste and
>BPL so
>that pyste (python) can actualy be used (almost) instead of C preprocessor.
>For now AIUC it's too far fetched.
>

Yeah, the idea IIRC, according to Dave, is to expose a lower-level 
interface with the objective of reducing the compilation time.

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Wed Oct  8 04:41:36 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 07 Oct 2003 23:41:36 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F820430.22562.EE0AE37@localhost>
References: <3F7CF5E9.12650.48FD659B@localhost>
	<3F820430.22562.EE0AE37@localhost>
Message-ID: <3F837960.2010108@globalite.com.br>

Hi Niall,

Niall Douglas wrote:

>How did you separate the two sets of header files?
>
>There will be a few eg; boost/python.hpp which will be common to all 
>source files. These can be precompiled.
>
>There will however be other specified by Include() which are in some 
>and not others. These would be "forgotten" by MSVC if they appear 
>before the #pragma hdrstop.
>
>I would suggest Include() for per-file includes and CommonInclude() 
>for the cross-module includes. Then even better you can have your 
>converter registering modules (I call mine _regconvs) generate your 
>precompiled headers for you which saves another ten seconds :)
>
>(BTW I've not forgotten the C array access class, right now I'm 
>getting to grips with scons (python based make system) so I can 
>finally compile two files at once and use all my processor space).
>

Sorry, you will have to be a little more specific than that: I have no 
experience with precompiled headers. 8)
Also, could you tell the compiler switch and how to create/use 
precompiled headers? Using just your code didn't improve the speed at 
all, and didn't generate any PCH file. 8(

But I am not very inclined to add a new function just to support 
precompiled headers, since they're only avaiable on windows... 8/
And, from the little I know, you can always generate your own 
pre-compiled header and include that in your Pyste files, right?

Regards,
Nicodemus.




From RaoulGough at yahoo.co.uk  Wed Oct  8 16:24:08 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 08 Oct 2003 15:24:08 +0100
Subject: [C++-sig] Re: New indexing suite available on indexing_v2 branch
References: <ud6d81vet.fsf@yahoo.co.uk>
	<20031008005848.51817.qmail@web20209.mail.yahoo.com>
Message-ID: <u3ce324fr.fsf@yahoo.co.uk>

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

> --- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
>> Looking at the changes to IntWrapper.hpp... I guess operator!= might
>> well be needed somewhere, depending on the standard library
>> implementation, but what does including <stdio.h> fix?
>
> It brings in the declaration of printf which the cxx compiler does
> not know about otherwise (correctly so, I believe).

I see. Probably g++ was including this as a side-effect of including
<ostream>. BTW, I originaly had a separate IntWrapper.cpp, but
couldn't figure out how to get Jam to link this into a single dll
together with testlinear. Not sure now why I was using printf instead
of cout.

>
>> That's a great offer - I'm sure it would save a lot of time. Could
>> you send me some details via email?
>
> Will do.

Thanks to Ralf's generous provision of access to a Tru64 machine, I've
now fixed the code for the Compaq V6.5-031 compiler (I think Ralf said
this uses the EDG 245 front-end). The main problems were due to some
unqualified names in the templates, which I had to fix for proper
two-phase lookup. One other problem was that vector::size_type doesn't
seem to be unsigned int, so passing 0 was ambiguous in one case of
overloads on size_type and vector::iterator (presumably a pointer
type).

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From rwgk at yahoo.com  Wed Oct  8 18:07:59 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 8 Oct 2003 09:07:59 -0700 (PDT)
Subject: [C++-sig] Re: New indexing suite available on indexing_v2 branch
In-Reply-To: <u3ce324fr.fsf@yahoo.co.uk>
Message-ID: <20031008160759.5987.qmail@web20209.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
Thanks Raoul for the quick fixes. It works for me, too. I'll try out some other
platforms now.

> One other problem was that vector::size_type doesn't
> seem to be unsigned int, so passing 0 was ambiguous in one case of
> overloads on size_type and vector::iterator (presumably a pointer
> type).

Tru64 Unix is, ehmm, a true 64 bit platform. std::size_t is unsigned long.
Under 32-bit Linux std::size_t is unsigned int which is the same as unsigned
long. Therefore the compiler cannot detect incorrected uses of unsigned int
instead of std::size_t. Compiling under Tru64 brings these glitches to light.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From mike at nospam.com  Wed Oct  8 18:29:35 2003
From: mike at nospam.com (Mike Rovner)
Date: Wed, 8 Oct 2003 09:29:35 -0700
Subject: [C++-sig] Re: Pyste suggestion: MSVC precompiled headers support
References: <3F7CF5E9.12650.48FD659B@localhost><3F820430.22562.EE0AE37@localhost>
	<3F837960.2010108@globalite.com.br>
Message-ID: <bm1ejs$fd0$1@sea.gmane.org>

Nicodemus wrote:
> Also, could you tell the compiler switch and how to create/use
> precompiled headers? Using just your code didn't improve the speed at
> all, and didn't generate any PCH file. 8(

For MSVC:
/Yc"file" - create
/YX"file" - autogenerate
/Yu"file" - use

> But I am not very inclined to add a new function just to support
> precompiled headers, since they're only avaiable on windows... 8/

gcc now has pch support as well.
Didn't try them yet and not sure they are prodction quality though.

Mike






From s_sourceforge at nedprod.com  Wed Oct  8 19:58:38 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 08 Oct 2003 18:58:38 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F837960.2010108@globalite.com.br>
References: <3F820430.22562.EE0AE37@localhost>
Message-ID: <3F845E5E.25040.76951D@localhost>

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

On 7 Oct 2003 at 23:41, Nicodemus wrote:

> >I would suggest Include() for per-file includes and CommonInclude()
> >for the cross-module includes. Then even better you can have your
> >converter registering modules (I call mine _regconvs) generate your
> >precompiled headers for you which saves another ten seconds :)
> 
> Sorry, you will have to be a little more specific than that: I have no
> experience with precompiled headers. 8) Also, could you tell the
> compiler switch and how to create/use precompiled headers? Using just
> your code didn't improve the speed at all, and didn't generate any PCH
> file. 8(

Precompiled headers are really precompiled source ie; just before the 
back end of the compiler spits out assembler. In MSVC you must use 
special command line switches to both generate and use precompiled 
headers - without these nothing happens.

The traditional use is to tell MSVC to ignore everything prior to 
some specified header file or #pragma hdrstop ie; therefore if pyste 
puts an extra header file before that point, MSVC misses it 
completely and the file won't compile.

Because pyste doesn't order its header files in a usefully 
predictable way and order, it's very hard to set settings which 
correctly work without some hand reordering.

If you do get precompiled headers working (and once MSVC fixes the 
bugs which mean it doesn't work properly with Boost), you can expect 
up to a 50% speed increase.

To give you some idea, with a na?ve MSVC project implementation it 
was taking me about three hours to compile. With scons and 
precompiled headers, it's about 35 mins. That's about five or six 
times quicker!!!

> But I am not very inclined to add a new function just to support
> precompiled headers, since they're only avaiable on windows... 8/ And,
> from the little I know, you can always generate your own pre-compiled
> header and include that in your Pyste files, right?

I think GCC has them on the way. Not in v3.3, but very soon now. So 
the new command *will* become useful.

If you could always get pyste to start off with *exactly* the same 
#include's in the same order across all modules, then we don't need 
this feature. I had been assuming that the mechanism I proposed was 
easier and better extensible for the future.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4RQT8EcvDLFGKbPEQLnSACfVrmKuIQ9Q+qmBfp3F8Msu9oyiuUAnjNs
G5mDoXr8i6FsstlrKkbOJI81
=laOA
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Wed Oct  8 20:40:37 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 08 Oct 2003 19:40:37 +0100
Subject: [C++-sig] Example of use of indexing_suite NOT using the STL
Message-ID: <3F846835.30349.9D0301@localhost>

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

Hi,

Google nor list archives make any mention of using indexing_suite 
with a custom container class ie; not a STL one.

Is there such an example, and if so where is it?

Would the new indexing::container_suite be better suited for new code 
as I saw mention of indexing_suite getting retired?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4RaJcEcvDLFGKbPEQIxCQCcD3DMZJKl0s/k2RrEAyaiTtxTFfwAn2xQ
/PmE6Y3gZOEuwWcpaR8ZVeXx
=2MUc
-----END PGP SIGNATURE-----



From yakumoklesk at yahoo.es  Wed Oct  8 20:27:51 2003
From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es)
Date: Wed, 08 Oct 2003 20:27:51 +0200
Subject: [C++-sig] Getting the traceback string
In-Reply-To: <3F845E5E.25040.76951D@localhost>
References: <3F837960.2010108@globalite.com.br>
Message-ID: <3F847347.15627.1161DDD8@localhost>

I am writing an application in C++ using MFCs. I huse the Boost.python 
handle_exception function to handle the function that runs the code that 
works with python, but sometimes I get errors and I want to show them 
in a messagebox because MFC applications do not have console.

I have tride to use PyErr_Fetch, but I don't know how to work with the 
PyObject of type Traceback, and I don't find documentation.

I have tried to import sys, and traceback modules, then create a 
variable traceback that gets the results of 
extract_tb(sys.last_traceback), but it seems not to work, because when 
I get the PyObject of traceback, it is NULL. I suppose there has been an 
internal error or something, but I don't know what could happen 
because I had the same code in a C++ console application and it 
worked.

If any of you have any ideas, I would appreciate them. I'll keep trying.

Thanks in advance.

David.




From nicodemus at globalite.com.br  Wed Oct  8 23:27:25 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Wed, 08 Oct 2003 18:27:25 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F845E5E.25040.76951D@localhost>
References: <3F820430.22562.EE0AE37@localhost>
	<3F845E5E.25040.76951D@localhost>
Message-ID: <3F84813D.2080609@globalite.com.br>

Hi Niall,

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 7 Oct 2003 at 23:41, Nicodemus wrote:
>
>  
>
>>>I would suggest Include() for per-file includes and CommonInclude()
>>>for the cross-module includes. Then even better you can have your
>>>converter registering modules (I call mine _regconvs) generate your
>>>precompiled headers for you which saves another ten seconds :)
>>>      
>>>
>>Sorry, you will have to be a little more specific than that: I have no
>>experience with precompiled headers. 8) Also, could you tell the
>>compiler switch and how to create/use precompiled headers? Using just
>>your code didn't improve the speed at all, and didn't generate any PCH
>>file. 8(
>>    
>>
>
>Precompiled headers are really precompiled source ie; just before the 
>back end of the compiler spits out assembler. In MSVC you must use 
>special command line switches to both generate and use precompiled 
>headers - without these nothing happens.
>
>The traditional use is to tell MSVC to ignore everything prior to 
>some specified header file or #pragma hdrstop ie; therefore if pyste 
>puts an extra header file before that point, MSVC misses it 
>completely and the file won't compile.
>

I don't understand that, because:

#include <boost/python.hpp>
#include <boost/cstdint.hpp>
#ifdef _MSC_VER
#pragma hdrstop
#endif
#include <A.h>

works for me. I thought that everything before #hdrstop would be 
*included* in the pre-compiled header, not excluded. But I don't see 
that happening, the code compiles fine.

>Because pyste doesn't order its header files in a usefully 
>predictable way and order, it's very hard to set settings which 
>correctly work without some hand reordering.
>
>If you do get precompiled headers working (and once MSVC fixes the 
>bugs which mean it doesn't work properly with Boost), you can expect 
>up to a 50% speed increase.
>
>To give you some idea, with a na?ve MSVC project implementation it 
>was taking me about three hours to compile. With scons and 
>precompiled headers, it's about 35 mins. That's about five or six 
>times quicker!!!
>

Thanks for the explanation. If it has so much benefits, I am very wiling 
to add support for it.

>If you could always get pyste to start off with *exactly* the same 
>#include's in the same order across all modules, then we don't need 
>this feature. I had been assuming that the mechanism I proposed was 
>easier and better extensible for the future.
>

Well, this headers are included always first:

<boost/python.hpp>
<boost/cstdint.hpp>

And I guess you could easily create a header, named "mylib.h", that 
includes everything else. So your pyste files would always just use this 
header to look for the classes/functions. Notice too that with the new 
--cache-dir option, GCCXML would be called only once for "mylib.h".
With this, I guess using pre-compiled headers would be possible, right?

Regards,
Nicodemus.




From llywelyn.geo at yahoo.com  Thu Oct  9 01:13:16 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Wed, 8 Oct 2003 16:13:16 -0700 (PDT)
Subject: [C++-sig] Sharing Singleton instances across boost.python extension
	modules
Message-ID: <20031008231316.40956.qmail@web41502.mail.yahoo.com>

Hi all,

How do I share singleton instances across extension modules in Windows?  For
instance, if I have an instance of a memory manager in one DLL, how do I use
the same memory manager in the other?

I realise this is a big question, but any links, references etc would be
appreciated.  Is it even possible?

Joel

=====


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From yakumoklesk at yahoo.es  Wed Oct  8 19:52:48 2003
From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es)
Date: Wed, 08 Oct 2003 19:52:48 +0200
Subject: [C++-sig] Getting the traceback string
In-Reply-To: <uisn1vs9d.fsf@boost-consulting.com>
Message-ID: <3F846B10.6559.1141C6C0@localhost>

I am writing an application in C++ using MFCs. I huse the Boost.python 
handle_exception function to handle the function that runs the code that 
works with python, but sometimes I get errors and I want to show them 
in a messagebox because MFC applications do not have console.

I have tride to use PyErr_Fetch, but I don't know how to work with the 
PyObject of type Traceback, and I don't find documentation.

I have tried to import sys, and traceback modules, then create a 
variable traceback that gets the results of 
extract_tb(sys.last_traceback), but it seems not to work, because when 
I get the PyObject of traceback, it is NULL. I suppose there has been an 
internal error or something, but I don't know what could happen 
because I had the same code in a C++ console application and it 
worked.

If any of you have any ideas, I would appreciate them. I'll keep trying.

Thanks in advance.

David.



From s_sourceforge at nedprod.com  Thu Oct  9 02:57:34 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 09 Oct 2003 01:57:34 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F84813D.2080609@globalite.com.br>
References: <3F845E5E.25040.76951D@localhost>
Message-ID: <3F84C08E.2631.1F61F26@localhost>

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

On 8 Oct 2003 at 18:27, Nicodemus wrote:

> #include <boost/python.hpp>
> #include <boost/cstdint.hpp>
> #ifdef _MSC_VER
> #pragma hdrstop
> #endif
> #include <A.h>
> 
> works for me. I thought that everything before #hdrstop would be
> *included* in the pre-compiled header, not excluded. But I don't see
> that happening, the code compiles fine.

Try generating a .pch file from some completely unrelated piece of 
code. Then try compiling the above using that pch file instead. You 
should get lots of errors.

Note that when you create a .pch file it still compiles whatever file 
you're doing - it just spits out the .pch file at the same time.

> >If you could always get pyste to start off with *exactly* the same 
> >#include's in the same order across all modules, then we don't need 
> >this feature. I had been assuming that the mechanism I proposed was
> >easier and better extensible for the future.
> >
> 
> Well, this headers are included always first:
> 
> <boost/python.hpp>
> <boost/cstdint.hpp>

Err, they're not here. The first include is always the one the 
Class() or AllFromHeader() has pulled in, which is invariably not 
global across all modules.

BTW is AllFromHeader() fixed yet?

> And I guess you could easily create a header, named "mylib.h", that
> includes everything else. So your pyste files would always just use
> this header to look for the classes/functions. Notice too that with
> the new --cache-dir option, GCCXML would be called only once for
> "mylib.h". With this, I guess using pre-compiled headers would be
> possible, right?

That causes extra recompiles. If I alter some header higher up, it 
means I must recompile ALL my modules instead of the one it actually 
affects. I'd prefer to avoid that please.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4SyfsEcvDLFGKbPEQLhlgCeKf/GaDV/7gkbK+6vARfhTQ2/DfIAn3U5
SAIc8eoHHW3sC8SZQ+F4S4Yq
=H089
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Thu Oct  9 03:14:24 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 09 Oct 2003 02:14:24 +0100
Subject: (Fwd) Re: [C++-sig] Sharing Singleton instances across boost.p
Message-ID: <3F84C480.20372.20588B5@localhost>

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

Sorry yahoo bounced this when sent off list.

Niall
- ------- Forwarded message follows -------
From:           	Niall Douglas <s_sourceforge at nedprod.com>
To:             	llywelyn.geo at yahoo.com
Subject:        	Re: [C++-sig] Sharing Singleton instances across boost.python extension	modules
Date sent:      	Thu, 09 Oct 2003 01:51:23 +0100

On 8 Oct 2003 at 16:13, Joel Gerard wrote:

> How do I share singleton instances across extension modules in
> Windows?  For instance, if I have an instance of a memory manager in
> one DLL, how do I use the same memory manager in the other?
> 
> I realise this is a big question, but any links, references etc
> would be appreciated.  Is it even possible?

Off topic, so off list.

CreateFileMapping() and repointing the MSVC free store to use a Win32
heap (HeapAlloc()) allocated within the shared memory region.

You'll have a nightmare with data locking correctly. I recommend you
find another solution eg; use a mailslot (CreateMailslot()) to send
and receive IPC messages between the instances of code.

Usually when you come to a problem like this, it's one of design. 
Very rarely will you actually want to do what you're proposing in the 
long run. We didn't get away from global memory segments on DOS 
without a very, very good reason.  

Cheers,
Niall

- ------- End of forwarded message -------




-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4S2cMEcvDLFGKbPEQKh9wCgvg2h3icoJXZYW2fShQpR9ZK5U64AoOfs
zk8Xcn5Xjf7q6BRMxYFvrj+W
=Q/Ut
-----END PGP SIGNATURE-----



From xavier.warin at der.edfgdf.fr  Thu Oct  9 13:38:04 2003
From: xavier.warin at der.edfgdf.fr (Xavier WARIN(Compte LOCAL) - I23)
Date: Thu, 09 Oct 2003 13:38:04 +0200
Subject: [C++-sig] Boost Python and Intel C++ 7.1 windows
Message-ID: <3F85489C.9060203@der.edfgdf.fr>

Hi,

While compiling with Intel C++ 7.1 Boost Python , i get this kind of 
error on class.cpp and a lot of other Boost Python files  :

C:\boost-1.30.2\boost/type_traits/is_integral.hpp(39): error: class 
"boost::is_integral<unsigned short>" has already been defined
   BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true)

I think that there must be a  define that i missed somewhere ! I don't 
find it
Any idea ?

Thank you

Xavier Warin




From RaoulGough at yahoo.co.uk  Thu Oct  9 15:32:15 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 09 Oct 2003 14:32:15 +0100
Subject: [C++-sig] Linux Intel compiler exception problems in Python
Message-ID: <u3ce2mt9c.fsf@yahoo.co.uk>

Some of the Boost.Python tests fail drastically with the Linux Intel
Compiler v7.1. It looks like throwing any C++ exception from code
executed within the Python interpreter will cause an abort. Can anyone
suggest a solution, or maybe another mailing list to get help?  Unless
this can be resolved, I don't see much Boost.Python code working
properly with this compiler.

This may be related to an issue mentioned on the babel-users list at
http://www.cca-forum.org/pipermail/babel-users/2003q2/000265.html

Tom Epperly <babel-users at llnl.gov> wrote (Thu, 24 Apr 2003 09:09:52
-0700):
> It turns out that there seems to be a conflict between libgcc_s.so
> and icc's exception mechanism. I modified the Babel build to make
> sure that libgcc_s.so isn't linked in to shared libaries and
> executables. However, the Python backend uses Python's build system,
> and Python's build system uses the compiler and flags that Python
> was built with -- in most cases GCC. This causes a problem when you
> have a Python extension module wrapping icc compiled C++ that throws
> an exception.

This could mean that if Python was compiled with gcc, then icc
compiled extension modules cannot use C++ exceptions (although the
copy of Python I'm using doesn't depend on anything called
libgcc_s.so). Anyway, here's a simple example that demonstrates the
problem:

-----8<---- pythrow.cpp -----8<-----

#include <Python.h>

PyObject *throw_catch (PyObject *, PyObject *) {
  try { throw 0; } catch (int) { }
  PyErr_SetString (PyExc_RuntimeError, "Thrown and caught");
  return 0;
}

static PyMethodDef methods[] = {
  {"throw_catch",  throw_catch, METH_VARARGS, "Throw and catch an excpetion."},
  {NULL, NULL, 0, NULL}
};

extern "C" {
  void initpythrow(void) {
    Py_InitModule("pythrow", methods);
  }
}

------8<-----------------8<---------

$ icc -I/usr/include/python2.2 -shared -g -o pythrow.so pythrow.cpp
$ python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pythrow import throw_catch
>>> throw_catch()
Abort
$

Traceback from running in gdb looks like this:

Program received signal SIGABRT, Aborted.
[Switching to Thread 8192 (LWP 3274)]
0x42028cc1 in kill () from /lib/i686/libc.so.6
(gdb) where
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x4002e07d in raise () from /lib/i686/libpthread.so.0
#2  0x4202a019 in abort () from /lib/i686/libc.so.6
#3  0x4007c9dc in GetCurrentFrame32 () from ./pythrow.so
#4  0x4007c240 in _Unwind_RaiseException () from ./pythrow.so
#5  0x4008948b in __cxa_throw ()
   from /opt/intel/compiler70/ia32/lib/libcxa.so.3
#6  0x4007c05b in throw_catch () at pythrow.cpp:4
#7  0x080ceb13 in PyCFunction_Call ()
#8  0x080796bc in eval_frame ()
#9  0x0807a10e in PyEval_EvalCodeEx ()
#10 0x08077025 in PyEval_EvalCode ()
#11 0x08096a49 in run_node ()
#12 0x080959c3 in PyRun_SimpleFileExFlags ()
#13 0x0809530a in PyRun_AnyFileExFlags ()
#14 0x0805381c in Py_Main ()
#15 0x08053269 in main ()
#16 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Thu Oct  9 20:03:19 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 09 Oct 2003 19:03:19 +0100
Subject: [C++-sig] msvc_typeid problem on Intel/Linux compiler
Message-ID: <uwubel254.fsf@yahoo.co.uk>

In working on the new indexing suite, I encountered an error in an
instantiation of the type_id template. I think the relvant code is in
boost/python/type_id.hpp:

template <class T>
inline type_info type_id(BOOST_EXPLICIT_TEMPLATE_TYPE(T))
{
    return type_info(
#  if (!defined(BOOST_MSVC) || BOOST_MSVC > 1300)
&& (!defined(BOOST_INTEL_CXX_VERSION) || BOOST_INTEL_CXX_VERSION > 700)
        typeid(T)
#  else // strip the decoration which msvc and Intel mistakenly leave in
        python::detail::msvc_typeid((boost::type<T>*)0)
#  endif 
        );
}

BOOST_INTEL_CXX_VERSION is getting set to 700 for this compiler
(checked via a printf), which means that it currently selects the
workaround msvc_typeid, which leads to the error:

boost/python/detail/msvc_typeinfo.hpp(45): error: no instance of
function template "boost::python::detail::typeid_ref_1" matches the
argument list [...]

full text at http://home.clara.net/raoulgough/boost/typeid_problem.txt
- I believe it happens in an attempt to def() a static member function
with the signature:

[ in template<...> struct set_algorithms ]
  static void assign (std::set<int> &, int, void *dummy);

although it's hard to be completely sure from the type names in the
error message.  Anyway, I made a local change to test for intel
version >= 700 and the problem went away (i.e. selecting the
non-workaround, normal version for 700).

>From the CVS log, the current test was introduced for an Intel 7.0
Beta - maybe this changed prior to release? Strangely, icc -V reports
"Version 7.1 Build 20030307Z" despite the value of
BOOST_INTEL_CXX_VERSION. On the other hand, maybe this is a Linux
vs. Windows issue with the Intel compiler, and the test needs to check
the platform as well? Unfortunately, I can't confirm whether using >=
is OK on Windows, so I don't know if the fix is good or not.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From rwgk at yahoo.com  Thu Oct  9 20:10:02 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 9 Oct 2003 11:10:02 -0700 (PDT)
Subject: [C++-sig] Linux Intel compiler exception problems in Python
In-Reply-To: <u3ce2mt9c.fsf@yahoo.co.uk>
Message-ID: <20031009181002.1339.qmail@web20201.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> This could mean that if Python was compiled with gcc, then icc
> compiled extension modules cannot use C++ exceptions (although the
> copy of Python I'm using doesn't depend on anything called
> libgcc_s.so).

Thanks for the clue! I've compiled Python 2.3 with the icc compiler. When
compiling Boost.Python modules against that Python installation the exception
handling problems seem to be gone (I did not run all tests yet). Very, very
good!

Raoul, to try it out on our machine enter

setup py23icc70

before running the libtbx/configure.py command.

Ralf

P.S.: This is what I did to compile Python with the icc compiler:

./configure CC=icc --prefix=/your/choice
After configure finishes edit the Makefile and comment out
#BASECFLAGS=     -OPT:Olimit=0
Then:
make
make install


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From dave at boost-consulting.com  Thu Oct  9 23:26:08 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 09 Oct 2003 17:26:08 -0400
Subject: [C++-sig] Re: msvc_typeid problem on Intel/Linux compiler
References: <uwubel254.fsf@yahoo.co.uk>
Message-ID: <u65iyhzm7.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> In working on the new indexing suite, I encountered an error in an
> instantiation of the type_id template. I think the relvant code is in
> boost/python/type_id.hpp:
>
> template <class T>
> inline type_info type_id(BOOST_EXPLICIT_TEMPLATE_TYPE(T))
> {
>     return type_info(
> #  if (!defined(BOOST_MSVC) || BOOST_MSVC > 1300)
> && (!defined(BOOST_INTEL_CXX_VERSION) || BOOST_INTEL_CXX_VERSION > 700)
>         typeid(T)
> #  else // strip the decoration which msvc and Intel mistakenly leave in
>         python::detail::msvc_typeid((boost::type<T>*)0)
> #  endif 
>         );
> }
>
> BOOST_INTEL_CXX_VERSION is getting set to 700 for this compiler
> (checked via a printf), which means that it currently selects the
> workaround msvc_typeid, which leads to the error:
>
> boost/python/detail/msvc_typeinfo.hpp(45): error: no instance of
> function template "boost::python::detail::typeid_ref_1" matches the
> argument list [...]
>
> full text at http://home.clara.net/raoulgough/boost/typeid_problem.txt
> - I believe it happens in an attempt to def() a static member function
> with the signature:
>
> [ in template<...> struct set_algorithms ]
>   static void assign (std::set<int> &, int, void *dummy);
>
> although it's hard to be completely sure from the type names in the
> error message.  Anyway, I made a local change to test for intel
> version >= 700 and the problem went away (i.e. selecting the
> non-workaround, normal version for 700).
>
>>From the CVS log, the current test was introduced for an Intel 7.0
> Beta - maybe this changed prior to release? Strangely, icc -V reports
> "Version 7.1 Build 20030307Z" despite the value of
> BOOST_INTEL_CXX_VERSION. On the other hand, maybe this is a Linux
> vs. Windows issue with the Intel compiler, and the test needs to check
> the platform as well? Unfortunately, I can't confirm whether using >=
> is OK on Windows, so I don't know if the fix is good or not.

I believe the workaround is only needed on Windows, because Intel
tries to emulate the bugs of MSVC.  Maybe 

#  if !defined(_MSC_VER)                                      \
     || !BOOST_WORKAROUND(BOOST_MSVC, <= 1300)                \
        && !BOOST_WORKAROUND(BOOST_INTEL_CXX_VERSION, <= 700)

??

If that works for you, Raoul, you can check it in (don't forget to
make sure boost/detail/workaround.hpp is included).

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




From nicodemus at globalite.com.br  Fri Oct 10 01:27:50 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 09 Oct 2003 20:27:50 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F84C08E.2631.1F61F26@localhost>
References: <3F845E5E.25040.76951D@localhost> <3F84C08E.2631.1F61F26@localhost>
Message-ID: <3F85EEF6.2070405@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 8 Oct 2003 at 18:27, Nicodemus wrote:
>
>
>>#include <boost/python.hpp>
>>#include <boost/cstdint.hpp>
>>#ifdef _MSC_VER
>>#pragma hdrstop
>>#endif
>>#include <A.h>
>>
>>works for me. I thought that everything before #hdrstop would be
>>*included* in the pre-compiled header, not excluded. But I don't see
>>that happening, the code compiles fine.
>>
>
>Try generating a .pch file from some completely unrelated piece of 
>code. Then try compiling the above using that pch file instead. You 
>should get lots of errors.
>

Hmm, thanks for clarifying.

>>>If you could always get pyste to start off with *exactly* the same 
>>>#include's in the same order across all modules, then we don't need 
>>>this feature. I had been assuming that the mechanism I proposed was
>>>easier and better extensible for the future.
>>>
>>>
>>Well, this headers are included always first:
>>
>><boost/python.hpp>
>><boost/cstdint.hpp>
>>
>
>Err, they're not here. The first include is always the one the 
>Class() or AllFromHeader() has pulled in, which is invariably not 
>global across all modules.
>

Just generated:

// Boost Includes 
==============================================================
#include <boost/python.hpp>
#include <boost/cstdint.hpp>

// Includes 
====================================================================
#include <A.h>

Both in single and multiple mode. Can you post your generated code where 
the user's headers are included first?

>BTW is AllFromHeader() fixed yet?
>

No. 8(

>>And I guess you could easily create a header, named "mylib.h", that
>>includes everything else. So your pyste files would always just use
>>this header to look for the classes/functions. Notice too that with
>>the new --cache-dir option, GCCXML would be called only once for
>>"mylib.h". With this, I guess using pre-compiled headers would be
>>possible, right?
>>
>
>That causes extra recompiles. If I alter some header higher up, it 
>means I must recompile ALL my modules instead of the one it actually 
>affects. I'd prefer to avoid that please.
>

Ops, you're right. You suggested CommonInclude, but I think PCHInclude 
would be better, what you think? Also, I seem to have missed the point 
of your posted #ifdef...

So, PCHInclude would always include that header first in *all* modules, 
right? Anything else is needed?

Regards,
Nicodemus.




From mike at nospam.com  Fri Oct 10 02:53:50 2003
From: mike at nospam.com (Mike Rovner)
Date: Thu, 9 Oct 2003 17:53:50 -0700
Subject: [C++-sig] strange class_.def behaivior
Message-ID: <bm4vun$j2s$1@sea.gmane.org>

Hi,

I have an exception during loading a bpl extension module.
When bpl try to execute class_.def statement, class namespace object pointer
= 0.
In file src/object/function.cpp line 388 (add_to_namespace()) ns
uninitialized,
because class_ this->m_ptr = 0.

It looks like my mistake but where?

Regards,
Mike


Example code:

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

struct Test
{
  Test(int s=0) : size(s) {}
  int Size() const {return size;}

  int size;
};

static bool test_eq(const Test& t1, const Test& t2) { return t1.Size() ==
t2.Size(); }

template<class T>
struct Wrap
{
  static class_<T>& PyClass(const char* name)
  {
    return
    class_<T>(name)
      .def(init<int>())
      .def("__len__", &T::Size)
      ;
  }
};

BOOST_PYTHON_MODULE(ext1)
{
  Wrap<Test>::PyClass("Test").def("__eq__", &test_eq);
}






From dave at boost-consulting.com  Fri Oct 10 03:47:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 09 Oct 2003 21:47:00 -0400
Subject: [C++-sig] Re: strange class_.def behaivior
References: <bm4vun$j2s$1@sea.gmane.org>
Message-ID: <ud6d5g8yz.fsf@boost-consulting.com>

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

> Hi,
>
> I have an exception during loading a bpl extension module.
> When bpl try to execute class_.def statement, class namespace object pointer
> = 0.
> In file src/object/function.cpp line 388 (add_to_namespace()) ns
> uninitialized,
> because class_ this->m_ptr = 0.
>
> It looks like my mistake but where?

You're returning a dangling reference to a local temporary from
PyClass.  That's a no-no.

> Regards,
> Mike
>
>
> Example code:
>
> #include <boost/python.hpp>
> using namespace boost::python;
>
> struct Test
> {
>   Test(int s=0) : size(s) {}
>   int Size() const {return size;}
>
>   int size;
> };
>
> static bool test_eq(const Test& t1, const Test& t2) { return t1.Size() ==
> t2.Size(); }
>
> template<class T>
> struct Wrap
> {
>   static class_<T>& PyClass(const char* name)
>   {
>     return
>     class_<T>(name)
>       .def(init<int>())
>       .def("__len__", &T::Size)
>       ;
>   }
> };
>
> BOOST_PYTHON_MODULE(ext1)
> {
>   Wrap<Test>::PyClass("Test").def("__eq__", &test_eq);
> }

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




From mike at nospam.com  Fri Oct 10 03:47:29 2003
From: mike at nospam.com (Mike Rovner)
Date: Thu, 9 Oct 2003 18:47:29 -0700
Subject: [C++-sig] Re: strange class_.def behaivior
References: <bm4vun$j2s$1@sea.gmane.org>
Message-ID: <bm533a$mta$1@sea.gmane.org>

Never mind. It was python object garbage collected.
In this case class_ object itself, not reference must be returned.

Mike

Mike Rovner wrote:
>   static class_<T>& PyClass(const char* name)
                                   ^^^ drop &
>   {
>     return
>     class_<T>(name)
>       .def(init<int>())
>       .def("__len__", &T::Size)
>       ;
>   }






From mike at nospam.com  Fri Oct 10 04:32:19 2003
From: mike at nospam.com (Mike Rovner)
Date: Thu, 9 Oct 2003 19:32:19 -0700
Subject: [C++-sig] Re: strange class_.def behaivior
References: <bm4vun$j2s$1@sea.gmane.org> <ud6d5g8yz.fsf@boost-consulting.com>
Message-ID: <bm55nb$qdk$1@sea.gmane.org>

David Abrahams wrote:
> "Mike Rovner" <mike at nospam.com> writes:
>> It looks like my mistake but where?
>
> You're returning a dangling reference to a local temporary from
> PyClass.  That's a no-no.

Thank you, Dave.

Now (after step-by-step debugging) I understand the bpl code a little bit
better ;)

Mike






From RaoulGough at yahoo.co.uk  Fri Oct 10 11:40:08 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 10 Oct 2003 10:40:08 +0100
Subject: [C++-sig] Re: Example of use of indexing_suite NOT using the STL
References: <3F846835.30349.9D0301@localhost>
Message-ID: <ur81ll9c7.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Hi,
>
> Google nor list archives make any mention of using indexing_suite 
> with a custom container class ie; not a STL one.
>
> Is there such an example, and if so where is it?
>
> Would the new indexing::container_suite be better suited for new code 
> as I saw mention of indexing_suite getting retired?

Well, the old indexing suite was certainly extensible, since you can
override any/all of the static functions (with the curiously recurring
template pattern). I don't know of any actual examples, though, except
for the vector and map extensions themselves.

In any case, it might well be better to look at the new suite, since
that is starting to look like it will eventually replace the old
one. Creating a new binding for the suite could be reasonably easy,
depending on how weird the container is. If it is similar to an
existing container, you should be able to get away with creating a new
container_traits class and substituting that in an existing algorithms
instance (e.g. set_algorithms<my_container_traits>). The documentation
should describe how to do this, so any comments on using it would be
appreciated.

Details of getting the new suite from CVS are in my message "New
indexing suite available on indexing_v2 branch" from 2003/10/07.

BTW, I plan to add support for overriding parts of the existing
algorithms with an extra template parameter - for instance, if your
container uses different names for "begin" and "end", it would be
possible to override the two relevant static functions in an existing
algorithms class via the curiously recurring template pattern.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From pierre.barbier at cirad.fr  Fri Oct 10 12:04:46 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Fri, 10 Oct 2003 12:04:46 +0200
Subject: [C++-sig] Problem with init<>
Message-ID: <1065780285.18677.5.camel@pbarbier>

I want to export some classes that takes as constructor argument, a
reference on an object (a non-const reference).

The problem is that Boost.Python expect only constant reference. Is
there a way to go around this limitation ?

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  Fri Oct 10 13:48:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 07:48:56 -0400
Subject: [C++-sig] Re: Problem with init<>
References: <1065780285.18677.5.camel@pbarbier>
Message-ID: <ur81lcnyv.fsf@boost-consulting.com>

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

> I want to export some classes that takes as constructor argument, a
> reference on an object (a non-const reference).
>
> The problem is that Boost.Python expect only constant reference. 

Why do you say that?

> Is there a way to go around this limitation ?

There's no limitation that prevents the passing of non-const
references:

        .def(init<foo&>())

works just fine.

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




From pierre.barbier at cirad.fr  Fri Oct 10 14:20:52 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Fri, 10 Oct 2003 14:20:52 +0200
Subject: [C++-sig] Re: Problem with init<>
In-Reply-To: <ur81lcnyv.fsf@boost-consulting.com>
References: <1065780285.18677.5.camel@pbarbier>
	<ur81lcnyv.fsf@boost-consulting.com>
Message-ID: <1065788451.18677.8.camel@pbarbier>

Le ven 10/10/2003 ? 13:48, David Abrahams a ?crit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
> 
> > I want to export some classes that takes as constructor argument, a
> > reference on an object (a non-const reference).
> >
> > The problem is that Boost.Python expect only constant reference. 
> 
> Why do you say that?
> 
> > Is there a way to go around this limitation ?
> 
> There's no limitation that prevents the passing of non-const
> references:
> 
>         .def(init<foo&>())
> 
> works just fine.

Indeed ... I'm sorry, I forgot that I had the same error twice and I
wrote the solution you propose anly for the first one ! Then I saw the
error again and I wrote this mail ...

Thank you 

-- 
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 halbert at bbn.com  Fri Oct 10 16:20:45 2003
From: halbert at bbn.com (Dan Halbert)
Date: Fri, 10 Oct 2003 10:20:45 -0400
Subject: [C++-sig] Exception support in CVS version of Boost.Python?
Message-ID: <200310101420.h9AEKj925162@rolex.bbn.com>

I am a newcomer to Boost.Python and Pyste. I am very impressed. I
didn't write a bit of code, and got most of our interface working.

One thing I could still use is automatic translation of C++ exceptions
to Python exceptions. In the C++-SIG mail archives, I see discussion
of Gottfried G's exception translation automation. I think I see code
for it in the CVS snapshot of BPL in Boost. But I'm not quite sure how
this mechanism to be used, as it seemed to be evolving for a while. It
doesn't seem to be mentioned in the updated documentation.

Could someone supply a simple example of the Pyste exception
translation construct and a handler function?

And I'll need the latest CVS version of GCC_XML, right?

Also, is the Boost.Python CVS snapshot pretty stable (in terms of
being usable) and mostly waiting for Boost 1.31 to become official? My
current testing has all been with the Boost.Python code in the 1.30.2
release version.

Gratefully,
Dan Halbert



From RaoulGough at yahoo.co.uk  Fri Oct 10 17:13:38 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 10 Oct 2003 16:13:38 +0100
Subject: [C++-sig] Re: msvc_typeid problem on Intel/Linux compiler
References: <uwubel254.fsf@yahoo.co.uk> <u65iyhzm7.fsf@boost-consulting.com>
Message-ID: <un0c9ktwd.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> From the CVS log, the current test was introduced for an Intel 7.0
>> Beta - maybe this changed prior to release? Strangely, icc -V reports
>> "Version 7.1 Build 20030307Z" despite the value of
>> BOOST_INTEL_CXX_VERSION. On the other hand, maybe this is a Linux
>> vs. Windows issue with the Intel compiler, and the test needs to check
>> the platform as well? Unfortunately, I can't confirm whether using >=
>> is OK on Windows, so I don't know if the fix is good or not.
>
> I believe the workaround is only needed on Windows, because Intel
> tries to emulate the bugs of MSVC.  Maybe 
>
> #  if !defined(_MSC_VER)                                      \
>      || !BOOST_WORKAROUND(BOOST_MSVC, <= 1300)                \
>         && !BOOST_WORKAROUND(BOOST_INTEL_CXX_VERSION, <= 700)
>
> ??
>
> If that works for you, Raoul, you can check it in (don't forget to
> make sure boost/detail/workaround.hpp is included).

Dave, this checked out OK on Intel, so I've updated the CVS. The
container suite should now build without problems on Intel C++ 7.1 for
Linux, but the exception-related issues with gcc-built Python
interpreters remain. Note that I have found a workaround for this -
forcing the loading of a couple of Intel shared object libraries
before Python starts execution seems to solve the problem:

export LD_PRELOAD="/opt/intel/compiler70/ia32/lib/libunwind.so.3
/opt/intel/compiler70/ia32/lib/libcxa.so.3"

More details to follow in the thread "Linux Intel compiler exception
problems in Python"

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Fri Oct 10 18:01:07 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 10 Oct 2003 17:01:07 +0100
Subject: [C++-sig] Re: Linux Intel compiler exception problems in Python
References: <u3ce2mt9c.fsf@yahoo.co.uk>
	<20031009181002.1339.qmail@web20201.mail.yahoo.com>
Message-ID: <uismxkrp8.fsf@yahoo.co.uk>

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

> --- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
>> This could mean that if Python was compiled with gcc, then icc
>> compiled extension modules cannot use C++ exceptions (although the
>> copy of Python I'm using doesn't depend on anything called
>> libgcc_s.so).
>
> Thanks for the clue! I've compiled Python 2.3 with the icc
> compiler. When compiling Boost.Python modules against that Python
> installation the exception handling problems seem to be gone (I did
> not run all tests yet). Very, very good!

I managed to reduce the problem further, and isolated it to a specific
problem with the Intel libcxa.so.3 shared library. It seems that if
this doesn't get loaded before program execution begins, it doesn't
set up the exception handling correctly.  Fortunately, there is a way
to force it to load, even if the Python executable doesn't have a
dependency on it (which is what rebuilding Python with icc fixes, of
course).

Reading the linux ld.so man page, the linker/loader inspects the
environment variable LD_PRELOAD to allow the injection of libraries
before program startup. It accepts a space separated list of
libraries, and in this case we need:

/opt/intel/compiler70/ia32/lib/libunwind.so.3
/opt/intel/compiler70/ia32/lib/libcxa.so.3

e.g. (from bash, with the stock gcc-built python)

$ python $BOOST_DIST/libs/python/test/exception_translator.py
running...
Aborted
$ LD_PRELOAD="/opt/intel/compiler70/ia32/lib/libunwind.so.3 /opt/intel/compiler70/ia32/lib/libcxa.so.3" python $BOOST_DIST/libs/python/test/exception_translator.py
running...
Done.
$ alias python_icc='LD_PRELOAD="/opt/intel/compiler70/ia32/lib/libunwind.so.3 /opt/intel/compiler70/ia32/lib/libcxa.so.3" python'
$ python_icc $BOOST_DIST/libs/python/test/exception_translator.py
running...
Done.
$

Which turns out to be an amazingly easy workaround, once known.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Fri Oct 10 18:32:39 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 10 Oct 2003 17:32:39 +0100
Subject: [C++-sig] Re: Linux Intel compiler exception problems in Python
References: <u3ce2mt9c.fsf@yahoo.co.uk>
	<20031009181002.1339.qmail@web20201.mail.yahoo.com>
	<uismxkrp8.fsf@yahoo.co.uk>
Message-ID: <u1xtlkq8o.fsf@yahoo.co.uk>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]

> $ alias python_icc='LD_PRELOAD="/opt/intel/compiler70/ia32/lib/libunwind.so.3 /opt/intel/compiler70/ia32/lib/libcxa.so.3" python'
> $ python_icc $BOOST_DIST/libs/python/test/exception_translator.py
> running...
> Done.
> $
>
> Which turns out to be an amazingly easy workaround, once known.

After further testing, it looks like libunwind.so.3 is all that you
need to preload - libcxa then seems to work OK when it gets
dynamically loaded along with the extension module.

$ alias python_icc='LD_PRELOAD=/opt/intel/compiler70/ia32/lib/libunwind.so.3 python'
$ python_icc $BOOST_DIST/libs/python/test/exception_translator.py
running...
Done.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From rwgk at yahoo.com  Fri Oct 10 19:11:31 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 10 Oct 2003 10:11:31 -0700 (PDT)
Subject: [C++-sig] Re: Linux Intel compiler exception problems in Python
In-Reply-To: <u1xtlkq8o.fsf@yahoo.co.uk>
Message-ID: <20031010171131.29770.qmail@web20209.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> After further testing, it looks like libunwind.so.3 is all that you
> need to preload - libcxa then seems to work OK when it gets
> dynamically loaded along with the extension module.
> 
> $ alias python_icc='LD_PRELOAD=/opt/intel/compiler70/ia32/lib/libunwind.so.3
> python'
> $ python_icc $BOOST_DIST/libs/python/test/exception_translator.py
> running...
> Done.

Wow!

A problem with aliases is that they are not inherited by child processes. Do
you think it could have negative side effects to globally

setenv LD_PRELOAD /opt/intel/compiler70/ia32/lib/libunwind.so.3

?

I doesn't seem to do any obvious harm. Did you come across any warnings while
reading the man pages?

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From RaoulGough at yahoo.co.uk  Fri Oct 10 19:50:38 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 10 Oct 2003 18:50:38 +0100
Subject: [C++-sig] Re: Linux Intel compiler exception problems in Python
References: <u1xtlkq8o.fsf@yahoo.co.uk>
	<20031010171131.29770.qmail@web20209.mail.yahoo.com>
Message-ID: <uwubdj829.fsf@yahoo.co.uk>

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

> --- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
>> After further testing, it looks like libunwind.so.3 is all that you
>> need to preload - libcxa then seems to work OK when it gets
>> dynamically loaded along with the extension module.
>> 
>> $ alias python_icc='LD_PRELOAD=/opt/intel/compiler70/ia32/lib/libunwind.so.3
>> python'
>> $ python_icc $BOOST_DIST/libs/python/test/exception_translator.py
>> running...
>> Done.
>
> Wow!
>
> A problem with aliases is that they are not inherited by child
> processes. Do you think it could have negative side effects to
> globally

I see. Another option would be to put a shell script called python_icc
(or something similar) on the search path. It could set LD_PRELOAD and
then do python "$@". Or even more generically, a script called
preload_icc (or maybe "preload_unwind" would be better) which can run
any executable:

#!/bin/bash
LD_PRELOAD=/opt/.../libunwind.so.3 "$@"

You could then do "preload_icc python ..."

>
> setenv LD_PRELOAD /opt/intel/compiler70/ia32/lib/libunwind.so.3
>
> ?
>
> I doesn't seem to do any obvious harm. Did you come across any
> warnings while reading the man pages?

I didn't see any specific warnings in the ld.so man page, but the
whole thing just seems a tiny bit hairy to me!

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From s_sourceforge at nedprod.com  Fri Oct 10 20:41:50 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Oct 2003 19:41:50 +0100
Subject: [C++-sig] Exception support in CVS version of Boost.Python?
In-Reply-To: <200310101420.h9AEKj925162@rolex.bbn.com>
Message-ID: <3F870B7E.19835.AEAD868@localhost>

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

On 10 Oct 2003 at 10:20, Dan Halbert wrote:

> One thing I could still use is automatic translation of C++ exceptions
> to Python exceptions. In the C++-SIG mail archives, I see discussion
> of Gottfried G's exception translation automation. I think I see code
> for it in the CVS snapshot of BPL in Boost. But I'm not quite sure how
> this mechanism to be used, as it seemed to be evolving for a while. It
> doesn't seem to be mentioned in the updated documentation.

I'm pretty sure that part hasn't changed at all.

> Could someone supply a simple example of the Pyste exception
> translation construct and a handler function?

Attached below. See the FXException bit.

> And I'll need the latest CVS version of GCC_XML, right?

I've used the release version fine. Nicodemus knows more.

> Also, is the Boost.Python CVS snapshot pretty stable (in terms of
> being usable) and mostly waiting for Boost 1.31 to become official? My
> current testing has all been with the Boost.Python code in the 1.30.2
> release version.

Sometimes CVS works, other times not as is its nature. But mostly it 
does and the improved functionality is most useful.

Cheers,
Niall

- --- cut ---
/*********************************************************************
***********
*                                                                     
          *
*                             Boost.python converters                 
          *
*                                                                     
          *
**********************************************************************
***********
*        Copyright (C) 2003 by Niall Douglas.   All Rights Reserved.  
          *
*       NOTE THAT I DO NOT PERMIT ANY OF MY CODE TO BE PROMOTED TO 
THE GPL      *
**********************************************************************
***********
* This code is free software; you can redistribute it and/or          
          *
* modify it under the terms of the GNU Library General Public         
          *
* License as published by the Free Software Foundation; either        
          *
* version 2.1 of the License, or (at your option) any later version   
          *
* EXCEPT that clause 3 of the LGPL does not apply ie; you may not     
          *
* "upgrade" this code to the GPL without my prior written permission. 
          *
* Please consult the file "License_Addendum2.txt" accompanying this 
file.       *
*                                                                     
          *
* This library is distributed in the hope that it will be useful,     
          *
* but WITHOUT ANY WARRANTY; without even the implied warranty of      
          *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.                
          *
**********************************************************************
**********/

#include <complex>
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/to_python_converter.hpp>
#include <boost/python/exception_translator.hpp>
#include "../include/fxdefs.h"
#include "../include/FXString.h"
#include "../include/FXException.h"
#include "../include/FXPtrHold.h"
#include "../include/FXProcess.h"

using namespace boost::python;

//********************************************************************
***********
// FXString converter

struct FXString_to_python_str
{
	static PyObject *convert(const FX::FXString &str)
	{
		return PyString_FromStringAndSize(str.text(), str.length());
		//return incref(boost::python::object(str).ptr());
	}
};

struct FXString_from_python_str
{
	FXString_from_python_str()
	{
		converter::registry::push_back(&convertible, &construct, 
type_id<FX::FXString>());
	}
	static void *convertible(PyObject *obj)
	{
		return PyString_Check(obj) ? obj : 0;
	}
	static void construct(PyObject *obj, 
converter::rvalue_from_python_stage1_data *data)
	{
		const char *value=PyString_AsString(obj);
		if(!value) throw_error_already_set();
		void *storage=((converter::rvalue_from_python_storage<FX::FXString> 
*) data)->storage.bytes;
		new(storage) FX::FXString(value, PyString_Size(obj));
		data->convertible = storage;
	}
};

void RegisterConvFXString()
{
	to_python_converter<FX::FXString, FXString_to_python_str>();
	FXString_from_python_str();
}

//********************************************************************
***********
// FXException converter

static void FXExceptionTranslator(const FX::FXException &e)
{
	PyObject *type=0;
	switch(e.code())
	{
	case FXEXCEPTION_NOMEMORY:
		type=PyExc_MemoryError;
		break;
	case FXEXCEPTION_NORESOURCE:
		type=PyExc_EnvironmentError;
		break;
	case FXEXCEPTION_IOERROR:
	case FXEXCEPTION_NOTFOUND:
		type=PyExc_IOError;
		break;
	case FXEXCEPTION_OSSPECIFIC:
		type=PyExc_OSError;
		break;
	default:
		type=PyExc_RuntimeError;
		break;
	}
	PyErr_SetString(type, e.report().text());
}

void RegisterConvFXException()
{
	
register_exception_translator<FX::FXException>(&FXExceptionTranslator)
;
}

//********************************************************************
***********
// Overall initialiser

using namespace FX;

void InitialiseTnFOXPython()
{
	RegisterConvFXException();
	RegisterConvFXString();
	static FXPtrHold<FXProcess> myprocess;
	FXProcess *alreadyinited=FXProcess::instance();
	if(!alreadyinited)
	{
		FXERRHM(myprocess=new FXProcess);
	}
}






-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4b9bsEcvDLFGKbPEQIKpwCeKSCV/AttkBIZjhRBvVky3hHJR/EAoKu1
MHwBz7FF9JkdMcUCFTwRLzJt
=vfop
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Fri Oct 10 20:50:31 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Oct 2003 19:50:31 +0100
Subject: [C++-sig] Re: Example of use of indexing_suite NOT using the STL
In-Reply-To: <ur81ll9c7.fsf@yahoo.co.uk>
Message-ID: <3F870D87.9385.AF2CBDE@localhost>

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

On 10 Oct 2003 at 10:40, Raoul Gough wrote:

> Well, the old indexing suite was certainly extensible, since you can
> override any/all of the static functions (with the curiously recurring
> template pattern). I don't know of any actual examples, though, except
> for the vector and map extensions themselves.

Might this not be a good idea? I want to wrap C arrays so python can 
access them. Yes, I know it's dangerous and misuse will crash python. 
But in at least three areas within this library it makes things much 
easier and until I get some feedback from users who use this code (I 
don't), I don't really know what they need.

> In any case, it might well be better to look at the new suite, since
> that is starting to look like it will eventually replace the old one.
> Creating a new binding for the suite could be reasonably easy,
> depending on how weird the container is. If it is similar to an
> existing container, you should be able to get away with creating a new
> container_traits class and substituting that in an existing algorithms
> instance (e.g. set_algorithms<my_container_traits>). The documentation
> should describe how to do this, so any comments on using it would be
> appreciated.

I read your docs but like most of the boost.python stuff I don't get 
most of it. This is probably mostly my fault, however I understand 
loki's documentation fine so I think it's a strong case of writing 
style ie; yours is not how I think or how I write my documentation.

As with Boost.Python, it's likely I'll just have to plough through 
the source code which TBH I find about as easy as the docs :( At 
least I suppose both together must make for something better than 
either alone.

> Details of getting the new suite from CVS are in my message "New
> indexing suite available on indexing_v2 branch" from 2003/10/07.
> 
> BTW, I plan to add support for overriding parts of the existing
> algorithms with an extra template parameter - for instance, if your
> container uses different names for "begin" and "end", it would be
> possible to override the two relevant static functions in an existing
> algorithms class via the curiously recurring template pattern.

Can I use your suite and not have begin() or end() methods? Indeed, a 
C array doesn't even have length!

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4b/d8EcvDLFGKbPEQLglACdGttViuZgRjsEGfu/9vc1q0fofysAn2wR
dfrQmuqeA2CxeEfq6sS7XYcR
=817F
-----END PGP SIGNATURE-----



From RaoulGough at yahoo.co.uk  Fri Oct 10 21:10:58 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 10 Oct 2003 20:10:58 +0100
Subject: [C++-sig] Re: Example of use of indexing_suite NOT using the STL
References: <ur81ll9c7.fsf@yahoo.co.uk> <3F870D87.9385.AF2CBDE@localhost>
Message-ID: <usmm0kiwt.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

[snip]
> I read your docs but like most of the boost.python stuff I don't get 
> most of it. This is probably mostly my fault, however I understand 
> loki's documentation fine so I think it's a strong case of writing 
> style ie; yours is not how I think or how I write my documentation.

I haven't seen the loki documentation, but maybe I should have a look
at it. I have to agree with you about the documentation being hard to
follow - mostly, it makes sense only once you've already figured it
out some other way. The trouble is probably that it is written mostly
as a reference instead of being a tutorial or user guide. Both types
are important to have, IMHO.

> As with Boost.Python, it's likely I'll just have to plough through 
> the source code which TBH I find about as easy as the docs :( At 
> least I suppose both together must make for something better than 
> either alone.
>
>> Details of getting the new suite from CVS are in my message "New
>> indexing suite available on indexing_v2 branch" from 2003/10/07.
>> 
>> BTW, I plan to add support for overriding parts of the existing
>> algorithms with an extra template parameter - for instance, if your
>> container uses different names for "begin" and "end", it would be
>> possible to override the two relevant static functions in an existing
>> algorithms class via the curiously recurring template pattern.
>
> Can I use your suite and not have begin() or end() methods? Indeed, a 
> C array doesn't even have length!

Well, that's actually not too hard. I haven't yet documented the
iterator_pair template, but you can probably figure it out from the
the getArray function in libs/python/test/testlinear.cpp

BTW, the suite definitely wants to know how long the array is. If you
really want to disable the bounds checking, you could probably just
pretend that the array is "really long" by adding a big number to the
start address.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From s_sourceforge at nedprod.com  Fri Oct 10 21:14:25 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Oct 2003 20:14:25 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F85EEF6.2070405@globalite.com.br>
References: <3F84C08E.2631.1F61F26@localhost>
Message-ID: <3F871321.4787.B08AD10@localhost>

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

On 9 Oct 2003 at 20:27, Nicodemus wrote:

> >>Well, this headers are included always first:
> >>
> >><boost/python.hpp>
> >><boost/cstdint.hpp>
> >
> >Err, they're not here. The first include is always the one the 
> >Class() or AllFromHeader() has pulled in, which is invariably not
> >global across all modules.
> 
> Both in single and multiple mode. Can you post your generated code
> where the user's headers are included first?

The pyste file:
from Policies import FX4Splitter
Include('../include/fx.h')
cclass=Class('FX::FX4Splitter', '../include/FX4Splitter.h')
FX4Splitter.apply(globals(), cclass)

The output:

// Includes 
===================================================================#include <../include/FX4Splitter.h>
#include <boost/python.hpp>
#include <../include/fx.h>

// Using 
=====================================================================using namespace boost::python;

// Declarations 
===============================================================namespace TnFOX {
...

As you can see, the ../include/FX4Splitter.h is before the common 
includes boost/python.hpp and ../include/fx.h.

> >BTW is AllFromHeader() fixed yet?
> >
> 
> No. 8(

Shame. Until it is, my bindings will be only 75% complete.

> Ops, you're right. You suggested CommonInclude, but I think PCHInclude
> would be better, what you think?

Actually yes and I'd make it only permit one file only. Why? Because 
it seems future G++ support will only permit one precompiled header 
file per compilation. See 
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-
Headers.html#Precompiled%20Headers

Therefore in my example above, we'd need to have one header file 
including everything common to all modules. This will require some 
tweaking on my end (I'll do it tonight).

> Also, I seem to have missed the point
> of your posted #ifdef...

Because #pragma hdrstop won't compile on GCC.

> So, PCHInclude would always include that header first in *all*
> modules, right? Anything else is needed?

Well, you needn't go that far as I and probably most people invoke 
pyste once per .pyste file (not many .pyste files at once). Making 
pyste behave differently with many files and a single file seems 
foolish as my make system only re-pyste's the pyste files which would 
have changed from the headers they include changing. I don't want to 
re-pyste everything with each header file change!

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4cFEcEcvDLFGKbPEQI0qgCaA+4HW+zR4GDMSuOShn7MigJjkAkAnjI6
AxKkA8mz+zUBpwZen9UjtZdq
=jmjv
-----END PGP SIGNATURE-----



From rwgk at yahoo.com  Fri Oct 10 21:19:09 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 10 Oct 2003 12:19:09 -0700 (PDT)
Subject: [C++-sig] Re: Linux Intel compiler exception problems in Python
In-Reply-To: <uwubdj829.fsf@yahoo.co.uk>
Message-ID: <20031010191909.56201.qmail@web20209.mail.yahoo.com>

--- Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> #!/bin/bash
> LD_PRELOAD=/opt/.../libunwind.so.3 "$@"

Thanks for the "$@"! I will not admit how much time I spent this morning trying
to figure this out. I tried $* ${*} "$*" "${*}" $@ ${@} in no particular order.
None of this preserves quoted arguments with spaces correctly. Then I got
frustrated and gave up. But your version does just what I want! -- It is
amazing how little things can sometimes save the day. :)

> > I doesn't seem to do any obvious harm. Did you come across any
> > warnings while reading the man pages?
> 
> I didn't see any specific warnings in the ld.so man page, but the
> whole thing just seems a tiny bit hairy to me!

In the meantime I ran a full build and all my tests. The global LD_PRELOAD does
still not appear to do any harm, but your "$@" trick is what I will use.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From s_sourceforge at nedprod.com  Fri Oct 10 22:08:31 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Oct 2003 21:08:31 +0100
Subject: [C++-sig] Re: Example of use of indexing_suite NOT using the STL
In-Reply-To: <usmm0kiwt.fsf@yahoo.co.uk>
Message-ID: <3F871FCF.18482.B3A35DA@localhost>

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

On 10 Oct 2003 at 20:10, Raoul Gough wrote:

> > I read your docs but like most of the boost.python stuff I don't get
> > most of it. This is probably mostly my fault, however I understand
> > loki's documentation fine so I think it's a strong case of writing
> > style ie; yours is not how I think or how I write my documentation.
> 
> I haven't seen the loki documentation, but maybe I should have a look
> at it. I have to agree with you about the documentation being hard to
> follow - mostly, it makes sense only once you've already figured it
> out some other way. The trouble is probably that it is written mostly
> as a reference instead of being a tutorial or user guide. Both types
> are important to have, IMHO.

You don't need to go as far as a tutorial as they take ages to write 
and usually you have too much detail in some places and too little in 
others (hard to think like a newbie). They're also very boring to 
write when you have dozens of better uses for your time.

I personally always write reference only documentation. The big 
difference between mine and what seems to be considered normal for 
Boost is that I logically tie together how all the bits relate to 
each other in order to provide the overall solution. It's like the 
difference between Bertrand Russell's "History of Western Philosophy" 
and most other compendium of philosophy books - he said how he 
thought all the myriad of philosophies had fed into each other and in 
& out of the prevailing cultural context of the time. Thus Russell's 
book is eminently more readable and understandable than other books 
of its ilk, though of course one gets strongly flavoured by Russell's 
subjective view of things.

If you can master this ability, it only adds 20% more to the length 
of the documentation but it means more able programmers can teach 
themselves the whole system very quickly indeed without bothering 
other people. In Boost.Python's docs, the only knowledge I could 
glean about how the whole thing works was from Dave's status update 
posts and even then, those preassumed an excellent working 
understanding of how Boost.Python v1 worked.

It's very old (year 2000) but this page 
(http://www.nedprod.com/NedHAL/Docs/Core/ARM/Excepts.html) from my 
degree project gives a good idea. Reference docs about something few 
know about normally but there's enough added sugar to quickly twig 
both what's going on, but also how it works. Note I don't explain 
acronyms or do any hand holding whatsoever, but I clearly am much 
more "chatty" than you get in most technical documentation - thus 
readers get lots of hints subconsciously. And from the user feedback 
I have received, this technique is very well received (and thus I 
spend more time coding and not answering email which already sucks an 
hour of productivity from me per day).

> > Can I use your suite and not have begin() or end() methods? Indeed,
> > a C array doesn't even have length!
> 
> Well, that's actually not too hard. I haven't yet documented the
> iterator_pair template, but you can probably figure it out from the
> the getArray function in libs/python/test/testlinear.cpp

I'm still fetching Boost from CVS. It'll take another 30 mins yet, 
then I can fetch your new indexing suite. After that, I'll play and 
let you know my experiences.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4cRwMEcvDLFGKbPEQLlfQCg+k4p0iPiyu29q0YQ1Nysk6wONAUAn0VE
qhu5wedEplL1Ssoy5zWo/+69
=UMvR
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Fri Oct 10 22:32:15 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Oct 2003 21:32:15 +0100
Subject: [C++-sig] Getting the new indexing_suite
Message-ID: <3F87255F.3638.B4FF1B1@localhost>

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

This is almost certainly something simple I've missed, but I have a 
long-standing hatred of CVS and everything about it precisely because 
it eats my files and refuses to work properly in my experience (I use 
subversion here). Yes, I know it's an old and well tested tool so it 
does work, but it's something about me and it not gelling in six 
years of usage.

I try running cvs update -d -r indexing_v2 
boost/python/suite/indexing libs/python and I get the error message 
"cvs [server aborted]: no such tag indexing_v2". I've tried browsing 
CVS on sourceforge and can't find indexing_v2 either. How about a 
good old zip file with the relevent files? :)

Lastly, the CVS I was working with was boost-consulting as I have 
never even once got CVS to work with sourceforge :(

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4cXUMEcvDLFGKbPEQKdUgCgnPS4/QeXLCgm9L0ylog9hw5G9r0An3bJ
Vp3l3wm9KSD/9ey+hAohv12l
=3PZI
-----END PGP SIGNATURE-----



From rwgk at yahoo.com  Fri Oct 10 23:05:04 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 10 Oct 2003 14:05:04 -0700 (PDT)
Subject: [C++-sig] Getting the new indexing_suite
In-Reply-To: <3F87255F.3638.B4FF1B1@localhost>
Message-ID: <20031010210504.88173.qmail@web20203.mail.yahoo.com>

--- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> I try running cvs update -d -r indexing_v2 
> boost/python/suite/indexing libs/python and I get the error message 
> "cvs [server aborted]: no such tag indexing_v2". I've tried browsing 
> CVS on sourceforge and can't find indexing_v2 either. How about a 
> good old zip file with the relevent files? :)

To cut this short:

http://cci.lbl.gov/~rwgk/tmp/boost_2003_10_10_1228.tar.gz

The time stamp is w.r.t. PDT.

> Lastly, the CVS I was working with was boost-consulting as I have 
> never even once got CVS to work with sourceforge :(

Anonymous access is getting worse every day. It is now almost completely
useless. :(:(:(

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From llywelyn.geo at yahoo.com  Sat Oct 11 00:01:49 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Fri, 10 Oct 2003 15:01:49 -0700 (PDT)
Subject: [C++-sig] Sharing Global Singleton instances across boost.python
	extensions (windows & unix)
In-Reply-To: <3F84C480.20372.20588B5@localhost>
Message-ID: <20031010220149.63454.qmail@web41507.mail.yahoo.com>

Thanks for the advice but I don't think I explained my problem very well (and after reading this
post you'll think that to be a gross understatement). I'm not sure its all that off topic but I
suppose it may be a general problem.  The filemapping idea doesn't seem to fit my problem.  Here's
what I'm trying to do:

- I have a library of Math functions that I'm trying to expose to Python: Matrix, Vector etc.

- I also have a library of Geometry types and functions  that I'm trying to expose: Sphere etc.

- Each of these libraries uses functionality in other libraries that I statically link to. In
particular, I have a Mem Manager that's a singleton. So Math and Geometry each statically link to
the MemManager lib in the Boost.Python extension module.

- Once exported using Boost I write python scripts that use them. Additionally, I want to embed
these scripts into a c++ application, which also uses the same libraries in C++ including my
memory manager. 

As I understand it, Boost sets things up to create a Windows DLL that Python explicitly links to
when you use "import" (ie. using LoadLibrary), and then does its magic with the init function etc.
 So what happens for me now is that my app starts the memory manager, fires up python and runs a
script that uses my boost.python extensions, which are supposed to use my Memory Manager.  The
MemoryManager (as well as some other singletons) are supposed to be global in scope so that the
extensions use them.  What's the best way to proceed with Boost so that these globals really are
globals?  I can hack it out in DLL world to make it work, but I also need to port this code to
some kind of POSIXish platform, and I'm not sure if my design will work with SOs.  

First question: What is the best cross platform solution here?

Second question: when you compile the application into which scripts will be embedded and link
against python22.lib is the python library statically linked to my app (ie nothing like
LoadLibrary("python.dll") is going on?)  That is, am I statically linked to the pythoncore, and
not to some thin layer that loads python dynamically?

Third question: can I recompile python and use Boost to statically link my extension modules to
the Python core, and then statically link python to my app and will this solve my problem?

If this is off topic, can you recommend a forum to post this to?

Thanks,
Joel

  

> From:           Niall Douglas <>
 Subject:        Re: [C++-sig] Sharing Singleton instances across boost.python extension modules
> Date sent:      Thu, 09 Oct 2003 01:51:23 +0100
> 
> On 8 Oct 2003 at 16:13, Joel Gerard wrote:
> 
> > How do I share singleton instances across extension modules in
> > Windows?  For instance, if I have an instance of a memory manager in
> > one DLL, how do I use the same memory manager in the other?
> > 
> > I realise this is a big question, but any links, references etc
> > would be appreciated.  Is it even possible?
> 
> Off topic, so off list.
> 
> CreateFileMapping() and repointing the MSVC free store to use a Win32
> heap (HeapAlloc()) allocated within the shared memory region.
> 
> You'll have a nightmare with data locking correctly. I recommend you
> find another solution eg; use a mailslot (CreateMailslot()) to send
> and receive IPC messages between the instances of code.
> 
> Usually when you come to a problem like this, it's one of design. 
> Very rarely will you actually want to do what you're proposing in the 
> long run. We didn't get away from global memory segments on DOS 
> without a very, very good reason.  
> 
> Cheers,
> Niall
> 
> - ------- End of forwarded message -------
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2
> 
> iQA/AwUBP4S2cMEcvDLFGKbPEQKh9wCgvg2h3icoJXZYW2fShQpR9ZK5U64AoOfs
> zk8Xcn5Xjf7q6BRMxYFvrj+W
> =Q/Ut
> -----END PGP SIGNATURE-----


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From nicodemus at globalite.com.br  Sat Oct 11 00:06:32 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 10 Oct 2003 19:06:32 -0300
Subject: [C++-sig] Exception support in CVS version of Boost.Python?
In-Reply-To: <200310101420.h9AEKj925162@rolex.bbn.com>
References: <200310101420.h9AEKj925162@rolex.bbn.com>
Message-ID: <3F872D68.5080609@globalite.com.br>

Dan Halbert wrote:

>I am a newcomer to Boost.Python and Pyste. I am very impressed. I
>didn't write a bit of code, and got most of our interface working.
>  
>

Glad to know that some of Pyste is useful. 8)

>One thing I could still use is automatic translation of C++ exceptions
>to Python exceptions. In the C++-SIG mail archives, I see discussion
>of Gottfried G's exception translation automation. I think I see code
>for it in the CVS snapshot of BPL in Boost. But I'm not quite sure how
>this mechanism to be used, as it seemed to be evolving for a while. It
>doesn't seem to be mentioned in the updated documentation.
>  
>

There were some disagreements between Dave and Gottfried about the 
implementation, so its inclusion in the CVS was post-poned until 
Gottfried could do some more work on it, IIRC.

>Could someone supply a simple example of the Pyste exception
>translation construct and a handler function?
>

There is no explicit support for that, mostly because it wasn't really 
asked for. Note that you can include code in the generated files from 
the Pyste files, so that can be used as an workaround.

>And I'll need the latest CVS version of GCC_XML, right?
>

Not for exception translation. You will need the CVS version if your 
virtual classes' member functions declare exception specifiers (is the 
therminology correct?):


    virtual void foo() throw std::runtime_error
    {
        ...
    }

Otherwise, the wrapper classes will end up being generated thus:

    class A_Wrapper(A)
    {
        virtual void foo()
        {
             call_method<void>(self, "foo");
        }
    };

And the code will not compile.

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Sat Oct 11 00:16:07 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 10 Oct 2003 19:16:07 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F871321.4787.B08AD10@localhost>
References: <3F84C08E.2631.1F61F26@localhost> <3F871321.4787.B08AD10@localhost>
Message-ID: <3F872FA7.8030007@globalite.com.br>

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 9 Oct 2003 at 20:27, Nicodemus wrote:
>
>
>>>>Well, this headers are included always first:
>>>>
>>>><boost/python.hpp>
>>>><boost/cstdint.hpp>
>>>>
>>>Err, they're not here. The first include is always the one the 
>>>Class() or AllFromHeader() has pulled in, which is invariably not
>>>global across all modules.
>>>
>>Both in single and multiple mode. Can you post your generated code
>>where the user's headers are included first?
>>
>
><snip example that proves that the includes don't appear in any particular order>
>

Oops, again. ;)
You're completely right. I was using the new version, where this problem 
*accidentaly* goes away. Now <boost/python.hpp> and <boost/cstdint.hpp> 
are included first, and then the user includes follow, sorted by name. 
What you thing?

>Actually yes and I'd make it only permit one file only. Why? Because 
>it seems future G++ support will only permit one precompiled header 
>file per compilation. See 
>http://gcc.gnu.org/onlinedocs/gcc/Precompiled-
>Headers.html#Precompiled%20Headers
>
>Therefore in my example above, we'd need to have one header file 
>including everything common to all modules. This will require some 
>tweaking on my end (I'll do it tonight).
>

Don't know though how we could make such prohibition, because nothing 
stops the user from writing a PCHInclude in a pyste file and then 
PCHInclude again in another, and then running pyste in multiple mode 
passing only one of them. I think it's ok to let the user take care 
about that.

>>Also, I seem to have missed the point
>>of your posted #ifdef...
>>
>
>Because #pragma hdrstop won't compile on GCC.
>

Sorry, I meant the entire snippet:

#ifdef _MSC_VER
#pragma hdrstop
#endif    

Not only the #ifdef part... 8)

>>So, PCHInclude would always include that header first in *all*
>>modules, right? Anything else is needed?
>>
>
>Well, you needn't go that far as I and probably most people invoke 
>pyste once per .pyste file (not many .pyste files at once). Making 
>pyste behave differently with many files and a single file seems 
>foolish as my make system only re-pyste's the pyste files which would 
>have changed from the headers they include changing. I don't want to 
>re-pyste everything with each header file change!
>

Sorry, my phrase was (very) badly worded. I didn't meant that once Pyste 
sees a PCHInclude, it should re-generate all the other pyste files, just 
that, inside a Pyste file, the contents of PCHInclude should be included 
*first* before anything else (well, perhaps after the boost's includes?).

So, summarizing, given this Pyste file:

A = Class('A', 'A.h')
PCHInclude('stdfx.h')

The generated file:

// Boost Includes 
==============================================================
#include <boost/python.hpp>
#include <boost/cstdint.hpp>

// PCH 
=========================================================================
#include <stdfx.h>

// Includes 
====================================================================
#include <A.h>


Is enough for PCH support?

Regards,
Nicodemus.




From s_sourceforge at nedprod.com  Sat Oct 11 00:46:18 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Oct 2003 23:46:18 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F872FA7.8030007@globalite.com.br>
References: <3F871321.4787.B08AD10@localhost>
Message-ID: <3F8744CA.21752.BCAAACF@localhost>

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

On 10 Oct 2003 at 19:16, Nicodemus wrote:

> Don't know though how we could make such prohibition, because nothing
> stops the user from writing a PCHInclude in a pyste file and then
> PCHInclude again in another, and then running pyste in multiple mode
> passing only one of them. I think it's ok to let the user take care
> about that.

I was more thinking of a warning if there is more than one PCHInclude 
eg; WARNING: Not compatible with GCC v3.4.

> #ifdef _MSC_VER
> #pragma hdrstop
> #endif    
> 
> Not only the #ifdef part... 8)

#pragma hdrstop tells MSVC to either stop making a precompiled header 
(when creating one) or to start compilation as normal (when using 
one).

I'll expand below.

> A = Class('A', 'A.h')
> PCHInclude('stdfx.h')
> 
> The generated file:
> 
> // Boost Includes 
> =============================================================> #include <boost/python.hpp>
> #include <boost/cstdint.hpp>
> 
> // PCH 
> =====================================================================> === #include <stdfx.h>
> 
> // Includes 
> ===================================================================> #include <A.h>
> 
> 
> Is enough for PCH support?

It isn't for v3.4 of GCC I don't think. It should instead be:

> A = Class('A', 'A.h')
> PCHInclude('common.h')

I don't use stdafx.h here because it smells of MFC which I personally 
dislike. Aesthetically, it isn't nice IMHO (like my view of hungarian 
notation).

> The generated file:
> 
> // PCH 
> =================================================================> #include "common.h"
> #ifdef _MSC_VER
> #pragma hdrstop
> #endif
> 
> // Includes 
> =================================================================> #include <A.h>
> ...

The PCH file must be the FIRST include and the ONLY precompiled 
header for v3.4 of GCC at least (I'm guessing they'll improve this 
with time). For MSVC you can have as many headers as you like before 
the #pragma hdrstop. It should be the user's responsibility to ensure 
common.h includes <boost/python.hpp> and anything else.

The above gives the maximum flexibility to users AFAICS. Comments 
from the group?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4c2u8EcvDLFGKbPEQL/iACfRj4zUqaDFkF/+SYSvd8xvRU81iAAn2X5
HFPernG+02WgkSECzxRFVUJw
=7Zdk
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sat Oct 11 01:09:30 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 00:09:30 +0100
Subject: [C++-sig] Sharing Global Singleton instances across
	boost.python	extensions (windows & unix)
In-Reply-To: <20031010220149.63454.qmail@web41507.mail.yahoo.com>
References: <3F84C480.20372.20588B5@localhost>
Message-ID: <3F874A3A.26347.BDFE58F@localhost>

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

On 10 Oct 2003 at 15:01, Joel Gerard wrote:

> Thanks for the advice but I don't think I explained my problem very
> well (and after reading this post you'll think that to be a gross
> understatement). I'm not sure its all that off topic but I suppose it
> may be a general problem.  The filemapping idea doesn't seem to fit my
> problem.  Here's what I'm trying to do:

It's on topic in the sense that it's about C++ and Python which is 
what this mailing list is actually for. It's rare we get something 
more general than boost.python!

> As I understand it, Boost sets things up to create a Windows DLL that
> Python explicitly links to when you use "import" (ie. using
> LoadLibrary), and then does its magic with the init function etc.
>  So what happens for me now is that my app starts the memory manager,
>  fires up python and runs a
> script that uses my boost.python extensions, which are supposed to use
> my Memory Manager.  The MemoryManager (as well as some other
> singletons) are supposed to be global in scope so that the extensions
> use them.  What's the best way to proceed with Boost so that these
> globals really are globals?  I can hack it out in DLL world to make it
> work, but I also need to port this code to some kind of POSIXish
> platform, and I'm not sure if my design will work with SOs.

You need not worry about POSIX shared objects because these behave 
more like a static library than DLL's do. But it is important not to 
have anything depend on special DLL functionality eg; DllMain.

> First question: What is the best cross platform solution here?

Do you have a GUI, and if so what are you using to operate it?

> Second question: when you compile the application into which scripts
> will be embedded and link against python22.lib is the python library
> statically linked to my app (ie nothing like LoadLibrary("python.dll")
> is going on?)  That is, am I statically linked to the pythoncore, and
> not to some thin layer that loads python dynamically?

On Windows python is almost always a DLL. On Linux the default is a 
static library to my knowledge.

> Third question: can I recompile python and use Boost to statically
> link my extension modules to the Python core, and then statically link
> python to my app and will this solve my problem?

If I understand what you've said so far correctly, there is no reason 
why either a fully static build or an entirely DLL build should not 
work. The only caveat is that python must import a DLL or shared 
object so you'll need at least one of those (it could simply 
bootstrap back into the parent process) though I'm sure with the 
appropriate C API calls of python you could skip this too.

I would suggest you place your memory manager into its own library so 
it can be loaded by your app and BP extension library. Then put the 
maths and geometry libraries into their own DLL's too and then 
generate a BP library which links in those libraries in order to 
provide them to python.

This is a design choice. I chose it because DLL's compartmentalise 
your code and generally speaking are better for good design and an 
easier transition to unix when the time comes. However as I said, you 
could link everything statically into a large monolithic binary. 
Since all code shares the same process and thus the same address 
space, it can all see each other - though of course it may not be 
able to /find/ each other.

I note that you think because code lives in a DLL it is somehow 
separate from other code. This is the right mentality to have for 
good design but it's incorrect in reality - once a DLL is mapped into 
a process space, it's almost the same as being statically linked into 
the binary. Indeed on Linux the kernel invokes the linker to "finish 
off" the linking process.

BTW if you plan to move to POSIX eventually, I *strongly* suggest you 
do it sooner rather than later. If you develop for both platforms 
simultaneously, you'll encounter all sorts of traps which you can 
work around as they occur. If you do windows first, you'll find the 
porting effort later much much harder.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4c8KsEcvDLFGKbPEQJP2QCeKuJ6WExkM5bjrY4uWqDiU8UGuHwAn0k1
UyoMvAYe2n9TG1dDy+Dzm1PK
=Z5ed
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Sat Oct 11 01:10:05 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:10:05 -0400
Subject: [C++-sig] Re: Example of use of indexing_suite NOT using the STL
References: <ur81ll9c7.fsf@yahoo.co.uk> <3F870D87.9385.AF2CBDE@localhost>
	<usmm0kiwt.fsf@yahoo.co.uk>
Message-ID: <ur81k7kqa.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> "Niall Douglas" <s_sourceforge at nedprod.com> writes:
>
> [snip]
>> I read your docs but like most of the boost.python stuff I don't get 
>> most of it. This is probably mostly my fault, however I understand 
>> loki's documentation fine so I think it's a strong case of writing 
>> style ie; yours is not how I think or how I write my documentation.
>
> I haven't seen the loki documentation, but maybe I should have a look
> at it. I have to agree with you about the documentation being hard to
> follow - mostly, it makes sense only once you've already figured it
> out some other way. The trouble is probably that it is written mostly
> as a reference instead of being a tutorial or user guide. Both types
> are important to have, IMHO.

Well, we have Joel's tutorial.  As for implementation documentation,
I'm trying to get Synopsis to do something useful with the source
tree, with the help of its maintainer.

>> As with Boost.Python, it's likely I'll just have to plough through 
>> the source code which TBH I find about as easy as the docs :( At 
>> least I suppose both together must make for something better than 
>> either alone.
>>
>>> Details of getting the new suite from CVS are in my message "New
>>> indexing suite available on indexing_v2 branch" from 2003/10/07.
>>> 
>>> BTW, I plan to add support for overriding parts of the existing
>>> algorithms with an extra template parameter - for instance, if your
>>> container uses different names for "begin" and "end", it would be
>>> possible to override the two relevant static functions in an existing
>>> algorithms class via the curiously recurring template pattern.
>>
>> Can I use your suite and not have begin() or end() methods? Indeed, a 
>> C array doesn't even have length!
>
> Well, that's actually not too hard. I haven't yet documented the
> iterator_pair template, but you can probably figure it out from the
> the getArray function in libs/python/test/testlinear.cpp
>
> BTW, the suite definitely wants to know how long the array is. If you
> really want to disable the bounds checking, you could probably just
> pretend that the array is "really long" by adding a big number to the
> start address.

Doubtless that'll get you undefined behavior, but you'll probably get
away with it anyway.

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




From s_sourceforge at nedprod.com  Sat Oct 11 01:11:26 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 00:11:26 +0100
Subject: [C++-sig] Getting the new indexing_suite
In-Reply-To: <20031010210504.88173.qmail@web20203.mail.yahoo.com>
References: <3F87255F.3638.B4FF1B1@localhost>
Message-ID: <3F874AAE.3283.BE1ADBD@localhost>

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

On 10 Oct 2003 at 14:05, Ralf W. Grosse-Kunstleve wrote:

> --- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> > I try running cvs update -d -r indexing_v2 
> > boost/python/suite/indexing libs/python and I get the error message
> > "cvs [server aborted]: no such tag indexing_v2". I've tried browsing
> > CVS on sourceforge and can't find indexing_v2 either. How about a
> > good old zip file with the relevent files? :)
> 
> To cut this short:
> 
> http://cci.lbl.gov/~rwgk/tmp/boost_2003_10_10_1228.tar.gz

You are a wonderful man! I take it the extra 3Mb is all the 
sandbox/experimental stuff.

> > Lastly, the CVS I was working with was boost-consulting as I have
> > never even once got CVS to work with sourceforge :(
> 
> Anonymous access is getting worse every day. It is now almost
> completely useless. :(:(:(

So it isn't actually me then? Wow. I'm actually feeling less like a 
luddite, cheers!

Thanks,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4c8n8EcvDLFGKbPEQKG3ACghZ4RNYtCfDI4sdZRb11/6r30NI4AoPvN
ChimKhxKQMkiE39pj51oPu8h
=U3Ot
-----END PGP SIGNATURE-----



From jbrandmeyer at earthlink.net  Sat Oct 11 01:13:34 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 10 Oct 2003 19:13:34 -0400
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F8744CA.21752.BCAAACF@localhost>
References: <3F871321.4787.B08AD10@localhost>
	<3F8744CA.21752.BCAAACF@localhost>
Message-ID: <1065827613.2010.11.camel@illuvatar>

On Fri, 2003-10-10 at 18:46, Niall Douglas wrote:
> The PCH file must be the FIRST include and the ONLY precompiled 
> header for v3.4 of GCC at least (I'm guessing they'll improve this 
> with time). For MSVC you can have as many headers as you like before 
> the #pragma hdrstop. It should be the user's responsibility to ensure 
> common.h includes <boost/python.hpp> and anything else.
> 
> The above gives the maximum flexibility to users AFAICS. Comments 
> from the group?
> 
> Cheers,
> Niall

I tried out a CVS version of GCC a few days ago to try out the PCH
support in the next compiler.  It ICEed with a segmentation fault when
trying to compile a header file that only included boost/python.hpp. 
Given that failure, my only comment is that it will be hard to
operationally test Pyste's support for PCH with GCC.

-Jonathan Brandmeyer




From dave at boost-consulting.com  Sat Oct 11 01:15:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:15:21 -0400
Subject: [C++-sig] Re: Getting the new indexing_suite
References: <3F87255F.3638.B4FF1B1@localhost>
	<20031010210504.88173.qmail@web20203.mail.yahoo.com>
Message-ID: <ullrs7khi.fsf@boost-consulting.com>

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

> --- Niall Douglas <s_sourceforge at nedprod.com> wrote:
>> I try running cvs update -d -r indexing_v2 
>> boost/python/suite/indexing libs/python and I get the error message 
>> "cvs [server aborted]: no such tag indexing_v2". I've tried browsing 
>> CVS on sourceforge and can't find indexing_v2 either. How about a 
>> good old zip file with the relevent files? :)
>
> To cut this short:
>
> http://cci.lbl.gov/~rwgk/tmp/boost_2003_10_10_1228.tar.gz
>
> The time stamp is w.r.t. PDT.
>
>> Lastly, the CVS I was working with was boost-consulting as I have 
>> never even once got CVS to work with sourceforge :(
>
> Anonymous access is getting worse every day. It is now almost completely
> useless. :(:(:(

I suggest you use the Boost Consulting CVS *snapshot* (updated hourly)
instead of the anonymous repository (updated daily, but only after SF
has made us a new CVS backup tarball).

The snapshot is at:

  http://www.boost-consulting.com/boost.tar.bz2

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




From dave at boost-consulting.com  Sat Oct 11 01:19:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:19:52 -0400
Subject: [C++-sig] Re: Exception support in CVS version of Boost.Python?
References: <200310101420.h9AEKj925162@rolex.bbn.com>
	<3F872D68.5080609@globalite.com.br>
Message-ID: <uad887k9z.fsf@boost-consulting.com>

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

> Not for exception translation. You will need the CVS version if your
> virtual classes' member functions declare exception specifiers (is the
> therminology correct?):

"exception specifications"

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




From dave at boost-consulting.com  Sat Oct 11 01:28:25 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:28:25 -0400
Subject: [C++-sig] Re: Sharing Global Singleton instances across boost.python
 extensions (windows & unix)
References: <3F84C480.20372.20588B5@localhost>
	<20031010220149.63454.qmail@web41507.mail.yahoo.com>
Message-ID: <u3ce07jvq.fsf@boost-consulting.com>

Joel Gerard <llywelyn.geo at yahoo.com> writes:

> Thanks for the advice but I don't think I explained my problem very
> well (and after reading this post you'll think that to be a gross
> understatement). I'm not sure its all that off topic but I suppose it
> may be a general problem.  The filemapping idea doesn't seem to fit my
> problem.  Here's what I'm trying to do:
>
> - I have a library of Math functions that I'm trying to expose to
> Python: Matrix, Vector etc.
>
> - I also have a library of Geometry types and functions that I'm
> trying to expose: Sphere etc.
>
> - Each of these libraries uses functionality in other libraries that I
> statically link to. In particular, I have a Mem Manager that's a
> singleton. So Math and Geometry each statically link to the MemManager
> lib in the Boost.Python extension module.
>
> - Once exported using Boost I write python scripts that use
> them. Additionally, I want to embed these scripts into a c++
> application, which also uses the same libraries in C++ including my
> memory manager.
>
> As I understand it, Boost sets things up to create a Windows DLL that
> Python explicitly links to when you use "import" (ie. using
> LoadLibrary), and then does its magic with the init function etc.  

You can either do that (recommended), or you can statically link your
extension module directly into Python, or embed Python into your
application via dynamic linking and statically link your extension
module into it.

> So what happens for me now is that my app starts the memory manager,
> fires up python and runs a script that uses my boost.python
> extensions, which are supposed to use my Memory Manager.  The
> MemoryManager (as well as some other singletons) are supposed to be
> global in scope so that the extensions use them.  What's the best
> way to proceed with Boost so that these globals really are globals?
> I can hack it out in DLL world to make it work, but I also need to
> port this code to some kind of POSIXish platform, and I'm not sure
> if my design will work with SOs.
>
> First question: What is the best cross platform solution here?

Stop statically linking to your math and geometry libraries.  Build
shared math and geometry libraries and use dynamic linking instead.

Or, don't build DLL extension modules.  Instead compile with
-DBOOST_PYTHON_STATIC_MODULE
(http://www.boost.org/libs/python/doc/v2/configuration.html) and
statically link the extension modules into your application, along
with your static libraries.

> Second question: when you compile the application into which scripts
> will be embedded and link against python22.lib is the python library
> statically linked to my app (ie nothing like LoadLibrary("python.dll")
> is going on?)  

No, on windows you statically link to the import library, so you're
linking dynamically to python22.dll.

> That is, am I statically linked to the pythoncore, and
> not to some thin layer that loads python dynamically?
>
> Third question: can I recompile python and use Boost to statically
> link my extension modules to the Python core, and then statically link
> python to my app and will this solve my problem?

Yes, but that's the hard way.

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




From dave at boost-consulting.com  Sat Oct 11 01:19:16 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:19:16 -0400
Subject: [C++-sig] Re: Boost Python and Intel C++ 7.1 windows
References: <3F85489C.9060203@der.edfgdf.fr>
Message-ID: <ufzi07kaz.fsf@boost-consulting.com>

"Xavier WARIN(Compte LOCAL) - I23" <xavier.warin at der.edfgdf.fr> writes:

> Hi,
>
> While compiling with Intel C++ 7.1 Boost Python , i get this kind of
> error on class.cpp and a lot of other Boost Python files  :
>
> C:\boost-1.30.2\boost/type_traits/is_integral.hpp(39): error: class
> "boost::is_integral<unsigned short>" has already been defined
>    BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true)
>
> I think that there must be a  define that i missed somewhere ! I don't
> find it
> Any idea ?

Are you using Boost.Build?  Are you using the CVS version of
Boost.Python?

Works fine for Intel7.1/windows when I do it.

bjam -sTOOLS=intel7 class.obj
...found 909 targets...
...updating 4 targets...
vc-C++ c:\build\bin\boost\libs\python\build\libboost_python.lib\intel7\debug-python\class.obj
class.cpp
vc-C++ c:\build\bin\boost\libs\python\build\boost_python.dll\intel7\debug-python\class.obj
class.cpp
MkDir1 c:\build\bin\boost\libs\python\build\boost_python.dll\intel7\debug-python\debug-
    symbols-off
vc-C++ c:\build\bin\boost\libs\python\build\boost_python.dll\intel7\debug-python\debug-symbo
    ls-off\class.obj
class.cpp
...updated 4 targets...

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




From nicodemus at globalite.com.br  Sat Oct 11 02:00:35 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 10 Oct 2003 21:00:35 -0300
Subject: [C++-sig] Re: Exception support in CVS version of Boost.Python?
In-Reply-To: <uad887k9z.fsf@boost-consulting.com>
References: <200310101420.h9AEKj925162@rolex.bbn.com>	<3F872D68.5080609@globalite.com.br>
	<uad887k9z.fsf@boost-consulting.com>
Message-ID: <3F874823.1040209@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>Not for exception translation. You will need the CVS version if your
>>virtual classes' member functions declare exception specifiers (is the
>>therminology correct?):
>>    
>>
>
>"exception specifications"
>

Thanks 8)





From s_sourceforge at nedprod.com  Sat Oct 11 02:01:32 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 01:01:32 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <1065827613.2010.11.camel@illuvatar>
References: <3F8744CA.21752.BCAAACF@localhost>
Message-ID: <3F87566C.4102.C0F8B50@localhost>

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

On 10 Oct 2003 at 19:13, Jonathan Brandmeyer wrote:

> > The above gives the maximum flexibility to users AFAICS. Comments
> > from the group?
> 
> I tried out a CVS version of GCC a few days ago to try out the PCH
> support in the next compiler.  It ICEed with a segmentation fault when
> trying to compile a header file that only included boost/python.hpp.
> Given that failure, my only comment is that it will be hard to
> operationally test Pyste's support for PCH with GCC.

I would be /very/ surprised if v3.4's PCH support worked straight off 
with Boost. If MSVC can't do it despite MS having supported that 
since v5 at least (maybe even v4?), then the GCC developers are going 
to need a few bug fix releases at least /after/ the initial v3.4 
release.

- From what few docs there are available, I think what I said about how 
to support it when it does work eventually. BTW I'm still downloading 
GCC v3.4, I only had v3.2 on my RH9 installation and I think someone 
in here said that it had issues with BPL so I'm hoping that's 
sufficiently stable to be of use. Also, any performance increase 
would be nice (RH9 in VMWare is slow, but oh boy is it slow when 
compiling BPL).

BTW, anyone tried using Mingw GCC to make object files on Windows 
(against the Linux file system exposed by samba), then linking them 
on Linux? I have a dual processor machine, but VMWare can only use 
one of them :( and I figure the object file output should be 
identical.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4dIXcEcvDLFGKbPEQIY0wCeMeceNxXy5hQUuywiMtU6uxZ48oIAn3Uh
AWgFEwLbI0iUEnyO8jLkz6gg
=pzVk
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Sat Oct 11 01:56:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:56:14 -0400
Subject: [C++-sig] Re: Sharing Global Singleton instances across boost.python
	extensions (windows & unix)
References: <3F84C480.20372.20588B5@localhost>
	<3F874A3A.26347.BDFE58F@localhost>
Message-ID: <u3ce0640x.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

F> On 10 Oct 2003 at 15:01, Joel Gerard wrote:
>
>> Thanks for the advice but I don't think I explained my problem very
>> well (and after reading this post you'll think that to be a gross
>> understatement). I'm not sure its all that off topic but I suppose it
>> may be a general problem.  The filemapping idea doesn't seem to fit my
>> problem.  Here's what I'm trying to do:
>
> It's on topic in the sense that it's about C++ and Python which is 
> what this mailing list is actually for. It's rare we get something 
> more general than boost.python!
>
>> As I understand it, Boost sets things up to create a Windows DLL that
>> Python explicitly links to when you use "import" (ie. using
>> LoadLibrary), and then does its magic with the init function etc.
>>  So what happens for me now is that my app starts the memory manager,
>>  fires up python and runs a
>> script that uses my boost.python extensions, which are supposed to use
>> my Memory Manager.  The MemoryManager (as well as some other
>> singletons) are supposed to be global in scope so that the extensions
>> use them.  What's the best way to proceed with Boost so that these
>> globals really are globals?  I can hack it out in DLL world to make it
>> work, but I also need to port this code to some kind of POSIXish
>> platform, and I'm not sure if my design will work with SOs.
>
> You need not worry about POSIX shared objects because these behave 
> more like a static library than DLL's do. But it is important not to 
> have anything depend on special DLL functionality eg; DllMain.

Saying you need not worry is a bit too sanguine.  POSIX shared objects
have plenty of potential quirks, especially when it comes to dlopen'ed
ones like most Python extension modules.

>> First question: What is the best cross platform solution here?
>
> Do you have a GUI, and if so what are you using to operate it?

I don't see how *that*'s relevant.

>> Second question: when you compile the application into which scripts
>> will be embedded and link against python22.lib is the python library
>> statically linked to my app (ie nothing like LoadLibrary("python.dll")
>> is going on?)  That is, am I statically linked to the pythoncore, and
>> not to some thin layer that loads python dynamically?
>
> On Windows python is almost always a DLL. 

On Windows most of python is *always* a DLL which is linked to a tiny
shell, the application.

> On Linux the default is a static library to my knowledge.

On Linux the default for extending is that it's an executable and the
symbols get seen by extension modules.  For embedding, yes the
default is a static library.

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




From dave at boost-consulting.com  Sat Oct 11 01:57:41 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 19:57:41 -0400
Subject: [C++-sig] Re: Pyste suggestion: MSVC precompiled headers support
References: <3F871321.4787.B08AD10@localhost>
	<3F8744CA.21752.BCAAACF@localhost>
	<1065827613.2010.11.camel@illuvatar>
Message-ID: <uwubc4pe2.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> On Fri, 2003-10-10 at 18:46, Niall Douglas wrote:
>> The PCH file must be the FIRST include and the ONLY precompiled 
>> header for v3.4 of GCC at least (I'm guessing they'll improve this 
>> with time). For MSVC you can have as many headers as you like before 
>> the #pragma hdrstop. It should be the user's responsibility to ensure 
>> common.h includes <boost/python.hpp> and anything else.
>> 
>> The above gives the maximum flexibility to users AFAICS. Comments 
>> from the group?
>> 
>> Cheers,
>> Niall
>
> I tried out a CVS version of GCC a few days ago to try out the PCH
> support in the next compiler.  It ICEed with a segmentation fault when
> trying to compile a header file that only included boost/python.hpp. 
> Given that failure, my only comment is that it will be hard to
> operationally test Pyste's support for PCH with GCC.

Did you report the bug to the GCC maintainers?

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




From s_sourceforge at nedprod.com  Sat Oct 11 02:53:27 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 01:53:27 +0100
Subject: [C++-sig] Re: Sharing Global Singleton instances across
	boost.python	extensions (windows & unix)
In-Reply-To: <u3ce0640x.fsf@boost-consulting.com>
Message-ID: <3F876297.263.C3F1174@localhost>

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

On 10 Oct 2003 at 19:56, David Abrahams wrote:

> > You need not worry about POSIX shared objects because these behave
> > more like a static library than DLL's do. But it is important not to
> > have anything depend on special DLL functionality eg; DllMain.
> 
> Saying you need not worry is a bit too sanguine.  POSIX shared objects
> have plenty of potential quirks, especially when it comes to dlopen'ed
> ones like most Python extension modules.

As do DLL's in Windows. If you've ever had the mispleasure of a DLL 
faulting during initialisation, you'll know what I mean. Also, you 
can't compare function pointers for equivalence if they're in a Win32 
DLL etc. etc.

Thing is, if you're porting to and only to very recent versions of 
Linux there are very few non-obvious quirks nowadays.

> >> First question: What is the best cross platform solution here?
> >
> > Do you have a GUI, and if so what are you using to operate it?
> 
> I don't see how *that*'s relevant.

Because if he were using MFC or the Win32 API, then first off we need 
to move to a cross-platform GUI toolkit - many of which provide 
abstractions for dealing with DLL's and plenty more besides.

> > On Windows python is almost always a DLL. 
> 
> On Windows most of python is *always* a DLL which is linked to a tiny
> shell, the application.

I'm pretty sure it can be compiled as a static library on Win32, but 
you're the expert.

> > On Linux the default is a static library to my knowledge.
> 
> On Linux the default for extending is that it's an executable and the
> symbols get seen by extension modules.  For embedding, yes the default
> is a static library.

Don't suppose you know why this is Dave? I only found this out last 
night and was quite puzzled by it not using a .so.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4dUh8EcvDLFGKbPEQLytwCfUauz4jApa3yd1VuNay62XFSAeH8AnRHr
G7Nh4byCIz5nrRp8JVXcz5Z4
=rlpq
-----END PGP SIGNATURE-----



From jbrandmeyer at earthlink.net  Sat Oct 11 04:01:17 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 10 Oct 2003 22:01:17 -0400
Subject: [C++-sig] g++ bug (Was: Pyste suggestion: MSVC precompiled headers
	support)
In-Reply-To: <uwubc4pe2.fsf@boost-consulting.com>
References: <3F871321.4787.B08AD10@localhost>
	<3F8744CA.21752.BCAAACF@localhost> <1065827613.2010.11.camel@illuvatar>
	<uwubc4pe2.fsf@boost-consulting.com>
Message-ID: <1065837677.18610.60.camel@illuvatar>

On Fri, 2003-10-10 at 19:57, David Abrahams wrote:
> Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:
> > I tried out a CVS version of GCC a few days ago to try out the PCH
> > support in the next compiler.  It ICEed with a segmentation fault when
> > trying to compile a header file that only included boost/python.hpp. 
> > Given that failure, my only comment is that it will be hard to
> > operationally test Pyste's support for PCH with GCC.
> 
> Did you report the bug to the GCC maintainers?

I have been attempting to reduce the size of the test case.  It is
currently down to about 1MB, produced by compiling only
boost/python/converter/registry.hpp.  I'm not sufficiently familiar with
Boost.Python's internals to shrink it down any farther.

The error was:
In file included from
/usr/include/boost/python/converter/registry.hpp:12:
/usr/include/boost/python/converter/rvalue_from_python_data.hpp: At
global scope:
/usr/include/boost/python/converter/rvalue_from_python_data.hpp:100:
internal compiler error: Segmentation fault

I went ahead and submitted a bug report, but if you know a way to trim
down that case, the GCC maintainers would probably appreciate it.

Thanks,
-Jonathan Brandmeyer




From jbrandmeyer at earthlink.net  Sat Oct 11 04:12:41 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 10 Oct 2003 22:12:41 -0400
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F87566C.4102.C0F8B50@localhost>
References: <3F8744CA.21752.BCAAACF@localhost>
	<3F87566C.4102.C0F8B50@localhost>
Message-ID: <1065838361.18615.68.camel@illuvatar>

On Fri, 2003-10-10 at 20:01, Niall Douglas wrote:
> -
> BTW, anyone tried using Mingw GCC to make object files on Windows 
> (against the Linux file system exposed by samba), then linking them 
> on Linux? I have a dual processor machine, but VMWare can only use 
> one of them :( and I figure the object file output should be 
> identical.
> 

It sounds like you want to use MinGW to produce object files for
programs to be run on your Linux machine.  In that case, you will need
to build a i686-pc-mingw32 hosted i686-pc-linux-gnu targeted cross
compiler.  The object files are not the same.

Good luck,
Jonathan Brandmeyer




From dave at boost-consulting.com  Sat Oct 11 04:31:19 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Oct 2003 22:31:19 -0400
Subject: [C++-sig] Re: Sharing Global Singleton instances across boost.python
	extensions (windows & unix)
References: <u3ce0640x.fsf@boost-consulting.com>
	<3F876297.263.C3F1174@localhost>
Message-ID: <uk77c4ia0.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 10 Oct 2003 at 19:56, David Abrahams wrote:
>
>> > You need not worry about POSIX shared objects because these behave
>> > more like a static library than DLL's do. But it is important not to
>> > have anything depend on special DLL functionality eg; DllMain.
>> 
>> Saying you need not worry is a bit too sanguine.  POSIX shared objects
>> have plenty of potential quirks, especially when it comes to dlopen'ed
>> ones like most Python extension modules.
>
> As do DLL's in Windows. If you've ever had the mispleasure of a DLL 
> faulting during initialisation, you'll know what I mean. Also, you 
> can't compare function pointers for equivalence if they're in a Win32 
> DLL etc. etc.

I wasn't claiming otherwise.

> Thing is, if you're porting to and only to very recent versions of 
> Linux there are very few non-obvious quirks nowadays.

Obviously you haven't been dealing with the same problems I've been
having in Boost.Python.  There are definitely some very subtle things
going on with weak symbols and templates; see
http://www.boost.org/libs/python/doc/v2/May2002.html#shared

>> On Linux the default for extending is that it's an executable and the
>> symbols get seen by extension modules.  For embedding, yes the default
>> is a static library.
>
> Don't suppose you know why this is Dave? I only found this out last 
> night and was quite puzzled by it not using a .so.

I think the extending configuration just makes distribution and
building simpler, but I'm really just guessing at the reasons.

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




From jbrandmeyer at earthlink.net  Sat Oct 11 04:44:04 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 10 Oct 2003 22:44:04 -0400
Subject: [C++-sig] g++ bug (Was: Pyste suggestion: MSVC precompiled
	headers support)
In-Reply-To: <1065837677.18610.60.camel@illuvatar>
References: <3F871321.4787.B08AD10@localhost>
	<3F8744CA.21752.BCAAACF@localhost> <1065827613.2010.11.camel@illuvatar>
	<uwubc4pe2.fsf@boost-consulting.com>
	<1065837677.18610.60.camel@illuvatar>
Message-ID: <1065840244.18615.71.camel@illuvatar>

On Fri, 2003-10-10 at 22:01, Jonathan Brandmeyer wrote:
> On Fri, 2003-10-10 at 19:57, David Abrahams wrote:
> > Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:
> I went ahead and submitted a bug report, but if you know a way to trim
> down that case, the GCC maintainers would probably appreciate it.
> 

Never mind, they already have (27 lines).

-Jonathan Brandmeyer




From s_sourceforge at nedprod.com  Sat Oct 11 04:09:49 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 03:09:49 +0100
Subject: [C++-sig] MSVC7.1 warnings with indexing_suite
Message-ID: <3F87747D.14454.C84FED2@localhost>

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

Easy to fix these:

d:\Tornado\TClient\boost\boost\python\suite\indexing\container_proxy.h
pp(68) : warning C4099: 'boost::python::indexing::proxy_iterator' : 
type name first seen using 'struct' now seen using 'class'
        
d:\Tornado\TClient\boost\boost\python\suite\indexing\proxy_iterator.hp
p(108) : see declaration of 'boost::python::indexing::proxy_iterator'
        
d:\Tornado\TClient\boost\boost\python\suite\indexing\container_proxy.h
pp(167) : see reference to class template instantiation 
'boost::python::indexing::container_proxy<Container,Holder>' being 
compiled
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(63) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::set<_Kty,_Pr,_All
oc>>' : type name first seen using 'struct' now seen using 'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(77) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::multiset<_Kty,_Pr
,_Alloc>>' : type name first seen using 'struct' now seen using 
'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(91) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::map<_Kty,_Ty,_Pr,
_Alloc>>' : type name first seen using 'struct' now seen using 
'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(105) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::multimap<_Kty,_Ty
,_Pr,_Alloc>>' : type name first seen using 'struct' now seen using 
'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(119) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::vector<_Ty,_Ax>>'
 : type name first seen using 'struct' now seen using 'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(133) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::deque<_Ty,_Ax>>' 
: type name first seen using 'struct' now seen using 'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(147) : warning C4099: 
'boost::python::indexing::detail::selector_impl<std::list<_Ty,_Ax>>' 
: type name first seen using 'struct' now seen using 'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(161) : warning C4099: 
'boost::python::indexing::detail::selector_impl<boost::python::indexin
g::iterator_pair<Iterator>>' : type name first seen using 'struct' 
now seen using 'class'
d:\Tornado\TClient\boost\boost\python\suite\indexing\algo_selector.hpp
(175) : warning C4099: 
'boost::python::indexing::detail::selector_impl<boost::python::indexin
g::container_proxy<Container>>' : type name first seen using 'struct' 
now seen using 'class'

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4dmbsEcvDLFGKbPEQJ8UQCgtmsx4r4A08e4DphTiMMf+Vwg1TUAn2k9
K1xV31zAxRTMKg7dNbu/2FbC
=tfnZ
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sat Oct 11 05:50:22 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 04:50:22 +0100
Subject: [C++-sig] IntWrapper.hpp in indexing_suite
Message-ID: <3F878C0E.20068.CE10D1A@localhost>

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

Firstly, let me confirm I have this right:

IntWrapper is converted into an int by bpl using the operator 
boost::shared_ptr<IntWrapper>() const yes? Or is it the 
implicitly_convertible? If it is the latter, why do we need the 
shared_ptr<> operator?

Anyway I came up with the below by basically following the 
testlinear.cpp example but unfortunately it complains "TypeError: No 
to_python (by-value) converter found for C++ type: class 
boost::python::indexing::iterator_pair<class CArrayMember<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > > *>". The code I used was:

>>> from TestCArrays import *
>>> a=MyList()
>>> b=a.getData()

I don't get why it's failing to find the conversion with mine whereas 
it works with the test :(

Any help much appreciated.

Cheers,
Niall

- --- cut ---
#include <boost/python.hpp>
#include <boost/python/suite/indexing/container_suite.hpp>
#include <boost/python/suite/indexing/iterator_pair.hpp>
#include <boost/python/suite/indexing/container_proxy.hpp>
#include <string>

class MyList
{
	std::string *array;
public:
	MyList();
	std::string *getData() { return array; }
};

MyList::MyList()
{
	static std::string data[]={ std::string("Niall"),
								std::string("is"),
								std::string("a"),
								std::string("teapot")
								};
	array?ta;
}

template<class T> class CArrayMember : public T
{
public:
	CArrayMember() : T() { }
	CArrayMember(const CArrayMember &o) : T(o) { }
	explicit CArrayMember(const T &o) : T(o) { }
	operator boost::shared_ptr<CArrayMember>() const
	{
		return boost::shared_ptr<CArrayMember>(new CArrayMember(*this));
	}
};

typedef 
boost::python::indexing::iterator_pair<CArrayMember<std::string> *> 
MyListCArray;

MyListCArray MyList_getArray(MyList &l)
{
	CArrayMember<std::string> 
*data=static_cast<CArrayMember<std::string> *>(l.getData());
	return 
boost::python::indexing::iterator_pair<CArrayMember<std::string> *>
		(data, data+100000); // Issue if l is near the 4Gb mark
}

BOOST_PYTHON_MODULE(TestCArrays)
{
	boost::python::implicitly_convertible<std::string, 
CArrayMember<std::string> >();

	boost::python::class_< MyListCArray, 
boost::noncopyable>("MyListCArray", 
		boost::python::init<CArrayMember<std::string> *, 
CArrayMember<std::string> *>())
		.def(boost::python::indexing::container_suite< MyListCArray >());

    boost::python::class_< MyList, boost::noncopyable >("MyList")
		.def("getData", &MyList_getArray)
		;
}





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4d9/8EcvDLFGKbPEQLYxwCfSIKfJ6mtqNtS76pbNYxTF4OvZZUAoL+3
4O1w8HK0sgRIaFPbxZ5WXbfV
=d8TG
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Sat Oct 11 06:01:01 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 05:01:01 +0100
Subject: [C++-sig] Re: Sharing Global Singleton instances across
	boost.python	extensions (windows & unix)
In-Reply-To: <uk77c4ia0.fsf@boost-consulting.com>
Message-ID: <3F878E8D.293.CEACC38@localhost>

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

On 10 Oct 2003 at 22:31, David Abrahams wrote:

> > Thing is, if you're porting to and only to very recent versions of
> > Linux there are very few non-obvious quirks nowadays.
> 
> Obviously you haven't been dealing with the same problems I've been
> having in Boost.Python.  There are definitely some very subtle things
> going on with weak symbols and templates; see
> http://www.boost.org/libs/python/doc/v2/May2002.html#shared

I'd forgotten some of those which I too have had run-ins with. Why oh 
why can't they make all symbols hidden by default and only public 
with a modifier syntaxically identical to __declspec(dllexport) so we 
can reuse our Win32 idioms?

It would require a small amount of complexity within G++ to do this, 
but the current method they have of you selecting each method 
individually is useless for Win32 compatibility :(

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4eAfcEcvDLFGKbPEQKROQCg+IfzxPwEThggM3mLmJgZAv3nYRsAn25r
qlciEZFNYPILkJRbzo+kbBYP
=gFef
-----END PGP SIGNATURE-----



From RaoulGough at yahoo.co.uk  Sat Oct 11 13:14:14 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sat, 11 Oct 2003 12:14:14 +0100
Subject: [C++-sig] Re: IntWrapper.hpp in indexing_suite
References: <3F878C0E.20068.CE10D1A@localhost>
Message-ID: <uoewojabd.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Firstly, let me confirm I have this right:
>
> IntWrapper is converted into an int by bpl using the operator 
> boost::shared_ptr<IntWrapper>() const yes? Or is it the 
> implicitly_convertible? If it is the latter, why do we need the 
> shared_ptr<> operator?

I've used IntWrapper in a number of different test cases, and ISTR one
of them needed a conversion to shared pointer. I suspect that test
didn't make it into the CVS, so the shared pointer conversion is
currently redundant.

>
> Anyway I came up with the below by basically following the 
> testlinear.cpp example but unfortunately it complains "TypeError: No 
> to_python (by-value) converter found for C++ type: class 
> boost::python::indexing::iterator_pair<class CArrayMember<class 
> std::basic_string<char,struct std::char_traits<char>,class 
> std::allocator<char> > > *>". The code I used was:
>
>>>> from TestCArrays import *
>>>> a=MyList()
>>>> b=a.getData()
>
> I don't get why it's failing to find the conversion with mine whereas 
> it works with the test :(

I don't think the shared pointer conversion has anything to do with
this. The really important bit is this:

  boost::python::class_<IntWrapper> ("IntWrapper", boost::python::init<int>())
    .def ("increment", &IntWrapper::increment)
    .def ("__repr__", repr)
    .def ("__cmp__", compare)
    ;

which turns IntWrapper into a Python class, with enough support to
convert it to a string and compare two IntWrapper objects. There is
also an implicit conversion from int, which means that code like this
will work:

>>> v.append (IntWrapper(43))  # OK
>>> v.append (44)              # Also OK - implicit conversion

>
> Any help much appreciated.
>
> Cheers,
> Niall
>
> --- cut ---
> #include <boost/python.hpp>
> #include <boost/python/suite/indexing/container_suite.hpp>
> #include <boost/python/suite/indexing/iterator_pair.hpp>
> #include <boost/python/suite/indexing/container_proxy.hpp>
> #include <string>
>
> class MyList
> {
> 	std::string *array;
> public:
> 	MyList();
> 	std::string *getData() { return array; }
> };
>
> MyList::MyList()
> {
> 	static std::string data[]={ std::string("Niall"),
> 								std::string("is"),
> 								std::string("a"),
> 								std::string("teapot")
> 								};
> 	array?ta;
> }
>
> template<class T> class CArrayMember : public T
> {
> public:
> 	CArrayMember() : T() { }
> 	CArrayMember(const CArrayMember &o) : T(o) { }
> 	explicit CArrayMember(const T &o) : T(o) { }
> 	operator boost::shared_ptr<CArrayMember>() const
> 	{
> 		return boost::shared_ptr<CArrayMember>(new CArrayMember(*this));
> 	}
> };
>
> typedef 
> boost::python::indexing::iterator_pair<CArrayMember<std::string> *> 
> MyListCArray;
>
> MyListCArray MyList_getArray(MyList &l)
> {
> 	CArrayMember<std::string> 
> *data=static_cast<CArrayMember<std::string> *>(l.getData());

Wow. This is almost certainly undefined behaviour.

> 	return 
> boost::python::indexing::iterator_pair<CArrayMember<std::string> *>
> 		(data, data+100000); // Issue if l is near the 4Gb mark
> }

The bounds checking code will still be compiled, of course, so lying
about the bound doesn't actually gain you anything (unless you have no
way of figuring out the real bound). You should be able to provide the
correct bound without too much trouble in this example.

>
> BOOST_PYTHON_MODULE(TestCArrays)
> {
> 	boost::python::implicitly_convertible<std::string, 
> CArrayMember<std::string> >();
>
> 	boost::python::class_< MyListCArray, 
> boost::noncopyable>("MyListCArray", 
> 		boost::python::init<CArrayMember<std::string> *, 
> CArrayMember<std::string> *>())
> 		.def(boost::python::indexing::container_suite< MyListCArray >());
>
>     boost::python::class_< MyList, boost::noncopyable >("MyList")
> 		.def("getData", &MyList_getArray)
> 		;
> }

OK, so CArrayMember<std::string> is-a std::string. You still haven't
exposed it to Python though. You will need something like this:

class_<CArrayMember<std::string>, bases<std::string> >
   ("CArrayMember_string");

I don't know exactly what else you'll have to do here - maybe define
implicit conversions to/from std::string, maybe make it no_init. The
container suite doesn't attempt to expose the container's value type
to Python - it assumes that you will do that yourself. I would suggest
first trying to get CArrayMember<...> working in Python before trying
to expose a container of CArrayMembers.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Sat Oct 11 13:34:07 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sat, 11 Oct 2003 12:34:07 +0100
Subject: [C++-sig] Re: MSVC7.1 warnings with indexing_suite
References: <3F87747D.14454.C84FED2@localhost>
Message-ID: <uismwj9e8.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Easy to fix these:
>
> d:\Tornado\TClient\boost\boost\python\suite\indexing\container_proxy.h
> pp(68) : warning C4099: 'boost::python::indexing::proxy_iterator' : 
> type name first seen using 'struct' now seen using 'class'
[snip]

Thanks for pointing this out. I must admit, I don't see what the point
of this warning is, but I've fixed it in the CVS anyway. MSVC now
compiles testlinear.cpp (almost) silently at /W3. Only warning is
this:

d:\CVS\boost\boost\libs\python\test\IntWrapper.hpp(139) : warning
 C4800: 'int' : forcing value to bool 'true' or 'false' (performance
 warning)

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Sat Oct 11 14:22:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 11 Oct 2003 08:22:00 -0400
Subject: [C++-sig] Re: MSVC7.1 warnings with indexing_suite
References: <3F87747D.14454.C84FED2@localhost> <uismwj9e8.fsf@yahoo.co.uk>
Message-ID: <ubrso2cd3.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> "Niall Douglas" <s_sourceforge at nedprod.com> writes:
>
>> Easy to fix these:
>>
>> d:\Tornado\TClient\boost\boost\python\suite\indexing\container_proxy.h
>> pp(68) : warning C4099: 'boost::python::indexing::proxy_iterator' : 
>> type name first seen using 'struct' now seen using 'class'
> [snip]
>
> Thanks for pointing this out. I must admit, I don't see what the point
> of this warning is, but I've fixed it in the CVS anyway. MSVC now
> compiles testlinear.cpp (almost) silently at /W3. Only warning is
> this:

The warning is important because vc6 has a bug which actually causes
struct and class to be treated differently in the linker :(

> d:\CVS\boost\boost\libs\python\test\IntWrapper.hpp(139) : warning
>  C4800: 'int' : forcing value to bool 'true' or 'false' (performance
>  warning)

Yeah, that's ridiculous.  I think an explicit cast fixes it.

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




From rwgk at yahoo.com  Sat Oct 11 17:37:55 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 11 Oct 2003 08:37:55 -0700 (PDT)
Subject: [C++-sig] g++ bug (Was: Pyste suggestion: MSVC precompiled
	headers support)
In-Reply-To: <1065840244.18615.71.camel@illuvatar>
Message-ID: <20031011153755.13646.qmail@web20201.mail.yahoo.com>

--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> On Fri, 2003-10-10 at 22:01, Jonathan Brandmeyer wrote:
> > On Fri, 2003-10-10 at 19:57, David Abrahams wrote:
> > > Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:
> > I went ahead and submitted a bug report, but if you know a way to trim
> > down that case, the GCC maintainers would probably appreciate it.
> > 
> 
> Never mind, they already have (27 lines).

Do you still have the bugzilla reference number of the URL to the bugzilla web
page?
Thanks,
        Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From jbrandmeyer at earthlink.net  Sat Oct 11 17:54:46 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Sat, 11 Oct 2003 11:54:46 -0400
Subject: [C++-sig] g++ bug (Was: Pyste suggestion: MSVC precompiled
	headers support)
In-Reply-To: <20031011153755.13646.qmail@web20201.mail.yahoo.com>
References: <20031011153755.13646.qmail@web20201.mail.yahoo.com>
Message-ID: <1065887686.926.2.camel@illuvatar>

On Sat, 2003-10-11 at 11:37, Ralf W. Grosse-Kunstleve wrote:

> Do you still have the bugzilla reference number of the URL to the bugzilla web
> page?
> Thanks,
>         Ralf

Bug #12573 @ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12573

-Jonathan Brandmeyer




From s_sourceforge at nedprod.com  Sat Oct 11 20:45:48 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Oct 2003 19:45:48 +0100
Subject: [C++-sig] Re: IntWrapper.hpp in indexing_suite
In-Reply-To: <uoewojabd.fsf@yahoo.co.uk>
Message-ID: <3F885DEC.4065.1014D51E@localhost>

On 11 Oct 2003 at 12:14, Raoul Gough wrote:

> I've used IntWrapper in a number of different test cases, and ISTR one
> of them needed a conversion to shared pointer. I suspect that test
> didn't make it into the CVS, so the shared pointer conversion is
> currently redundant.

Right, sorry, as I mentioned before I don't quite get how all this 
works ...

> I don't think the shared pointer conversion has anything to do with
> this. The really important bit is this:
> 
>   boost::python::class_<IntWrapper> ("IntWrapper",
>   boost::python::init<int>())
>     .def ("increment", &IntWrapper::increment)
>     .def ("__repr__", repr)
>     .def ("__cmp__", compare)
>     ;
> 
> which turns IntWrapper into a Python class, with enough support to
> convert it to a string and compare two IntWrapper objects. There is
> also an implicit conversion from int, which means that code like this
> will work:

Hang on, back up a way bit. Firstly, you appear to be implying that 
the sequence in python is actually of IntWrapper's, not real int's. 
Actually, now that looks obvious, but I hadn't realised that before.

Therefore the down conversion from an IntWrapper to an int is 
happening when python pulls a value /from/ the sequence eg; 
repr(sequence).

Ok, I now get why there's the __cmp__ and __repr__. But why the 
increment()? Surely that should be __inc__ or something? (I can't 
find __inc__ anywhere in the python docs. But it can't be a reference 
count as there's no way of reading it, decrementing it and besides, 
it's incrementing the value, not a refCount).

Actually, how the hell is bpl converting an IntWrapper to an int? I 
understand how int becomes IntWrapper (the explicit copy 
constructor), but not vice versa!

> > 	CArrayMember<std::string> 
> > *data=static_cast<CArrayMember<std::string> *>(l.getData());
> 
> Wow. This is almost certainly undefined behaviour.

Might be according to the standard, but if CArrayMember<> contains no 
data members, there's no chance of copy slicing and thus no problem.

> > 	return 
> > boost::python::indexing::iterator_pair<CArrayMember<std::string> *>
> > 		(data, data+100000); // Issue if l is near the 4Gb mark
> > }
> 
> The bounds checking code will still be compiled, of course, so lying
> about the bound doesn't actually gain you anything (unless you have no
> way of figuring out the real bound). You should be able to provide the
> correct bound without too much trouble in this example.

Yeah twas temporary code I'll fix later. I was going to have a 
template parameter take an address to a function which when called, 
returns the length of the array (seeing as that function varies 
between classes). And a template specialisation taking arrays with 
length attached.

> OK, so CArrayMember<std::string> is-a std::string. You still haven't
> exposed it to Python though. You will need something like this:
> 
> class_<CArrayMember<std::string>, bases<std::string> >
>    ("CArrayMember_string");
> 
> I don't know exactly what else you'll have to do here - maybe define
> implicit conversions to/from std::string, maybe make it no_init. The
> container suite doesn't attempt to expose the container's value type
> to Python - it assumes that you will do that yourself. I would suggest
> first trying to get CArrayMember<...> working in Python before trying
> to expose a container of CArrayMembers.

I had been assuming that std::string already has a registered 
converter converting it to a python string.

But what's *very* important to understand here is that soon I'll make 
the std::string a template parameter as I want it to be generically 
applicable ie; you can wrap any C++ object with the necessary gumph 
to make it a member of a sequence.

Ideally however I'd like to somehow divorce the conversion of the 
types in the array from the accessing of the array. The conversions 
are already registered and mapped to python types - my CArray code 
should merely index the array and return a type (often pointer to 
type) to the array member which then BPL converts as it would 
normally do (when returned from a method) to its corresponding python 
type.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031011/5f7d3105/attachment.pgp>

From yakumoklesk at yahoo.es  Sat Oct 11 23:42:53 2003
From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es)
Date: Sat, 11 Oct 2003 23:42:53 +0200
Subject: [C++-sig] Deriving python class from a C++ "virtual" class
In-Reply-To: <3F885DEC.4065.1014D51E@localhost>
References: <uoewojabd.fsf@yahoo.co.uk>
Message-ID: <3F88957D.18405.218822D6@localhost>

Imagine we have this C++ class:

class CClassActor
{
private:
	int		m_iValue;
public:
	CClassActor() { m_iValue = 0; }
	virtual ~CClassActor() {}
	void SetValue( int iValue ) { m_iValue = iValue; }
	int	 GetValue() { return m_iValue; }
	virtual int GetConcreteInt();
};

and we have a derived class from the first:

class CClassActorDerived: CClassActor
{
private:
	int	m_iOther;
	CClassActorDerived() { CClassActor(); m_iOther = 0; }
	virtual ~CClassActorDerived() {}
	int	GetConcreteInt() { return 10; }
}

As you can see, CClassActor is virtual, but has a constructor, because it
initializes some of the attributes of the virtual class that the derived
class will eventually use.

But what I want is having a class the same way as CClassActorDerived but in
Python. As CClassActor is virtual, because it have virtual functions, it is
supposed that we need a Wrapper class. What I did whas this:

class CClassActorWrap: public CClassActor
{
public:
	CClassActorWrap(PyObject* self_)
		: self(self_) {}

	int GetConcreteInt() { return py::call_method<int>( self, "GetConcreteInt"); }
public:
	PyObject* self;
	
};

And the module that holds de class wrap:

BOOST_PYTHON_MODULE(ClassActorWrapper)
{
	py::class_<CClassActor, CClassActorWrap, boost::noncopyable>( 
"CppClassActor" )
		.def ( "SetValue", &CClassActor::SetValue )
		.def ( "GetValue", &CClassActor::GetValue )
	;
}

Lately in the program I make:

	PyImport_AppendInittab("ClassActorWrapper", initClassActorWrapper);
    Py_Initialize();

    PyObject* mainmod = PyImport_AddModule("__main__");
    ns = PyModule_GetDict(mainmod);
    Py_INCREF(ns);

	PyObject* x = PyRun_String(
        "from ClassActorWrapper import *\n"
		"class ClassActorDerived(CppClassActor):\n"
		"    def __init__(self):\n"
		"        pass\n"
		"    def GetConcreteInt(self):\n"
		"        print \"Class Python ClassActorDerived deriveda from C++ class 
CClassActor\"\n"
		"        return 1\n"
		"class ClassActorDerivedB(CppClassActor):\n"
		"    def __init__(self):\n"
		"        pass\n"
		"    def GetConcreteInt(self):\n"
		"        print \"Class Python ClassActorDerivedB derive from C++ class 
CClassActor\"\n"
		"        return 2\n"
		,Py_file_input, ns, ns);
	
	Py_XDECREF(x);
	PyRun_SimpleString( "ca2 = ClassActorDerived()" );  
	PyRun_SimpleString( "print ca2.GetConcreteInt()" );
	//
	//	--> It ouputs
	//	"Class Python ClassActorDerived deriveda from C++ class CClassActor
	//	1"
	//  So it is OK

	PyRun_SimpleString( "ca2b = ClassActorDerivedB()" );
	PyRun_SimpleString( "print ca2b.GetConcreteInt()" );
	//
	//	--> It ouputs
	//	"Class Python ClassActorDerived deriveda from C++ class CClassActor
	//	2"
	//  So it is OK
			
	PyRun_SimpleString( "print ca2.GetValue()" );
	It raises an exception:
	
	// TypeError: no to_python (by value) converter found for C++ type: char
	
I do not understand how can I access to de GetValue and SetValue
concrete functions of the virtual class CClassActor without rising
that exception.

And I would like also to call to __init__ of CClassActor inside the __init__
method of the Python Derived classes so that m_iValue gets initialized, but
when I define

py::class_<CClassActor, CClassActorWrap>( "CppClassActor", py::init<>() ) 

instead of

py::class_<CClassActor, CClassActorWrap, boost::noncopyable>( "CppClassActor", 
py::no_init )

I get this compile error:

e:\...\value_holder.hpp(137) : error C2661: 'CClassActorWrap::CClassActorWrap' : no 
overloaded function takes 2 parameters
       	e:\...\\make_instance.hpp(69) : see reference to function template instantiation 
        '__thiscall boost::python::objects::value_holder_back_reference<class 
CClassActor,class CClassActorWrap>::


So, is it possible to do what I want to do? And how can I do it?

-Wrap a virtual C++ class with Constructor to Python
-Wrap a virtual C++ class with Concrete methods
-Make a Python class that derives from that virtual class and can call __init__
 of the parent class inside its __init__ method
 
 
Thanks in advance.

David.

PD.- using MSVC 6 with Python 2.3 and Boost.python 1.30
	
	






From s_sourceforge at nedprod.com  Sun Oct 12 03:22:17 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 12 Oct 2003 02:22:17 +0100
Subject: [C++-sig] Re: IntWrapper.hpp in indexing_suite
In-Reply-To: <3F885DEC.4065.1014D51E@localhost>
References: <uoewojabd.fsf@yahoo.co.uk>
Message-ID: <3F88BAD9.5838.117FD47C@localhost>

On 11 Oct 2003 at 19:45, Niall Douglas wrote:

Fixed it!

The below works lovely, and my thanks for the advice. The problem was 
the boost::noncopyable in the MyListCArray declaration.

Ok, next question: How do you determine the return type of a function 
pointer? It must be possible as bpl determines return type in def() - 
get_signature() from signature.hpp looked hopeful, but it appears to 
be a run-time not compile-time function.

To clarify:

std::string *foo();

typedef result_of<&foo>::value return_type;

.... and return_type is std::string *.

Cheers,
Niall

--- cut ---
#include <boost/python.hpp>
#include <boost/python/suite/indexing/container_suite.hpp>
#include <boost/python/suite/indexing/iterator_pair.hpp>
#include <boost/python/suite/indexing/container_proxy.hpp>
#include <string>

class MyList
{
	std::string *array;
public:
	MyList();
	std::string *getData() { return array; }
	int getDataLen() const { return 4; }
};

MyList::MyList()
{
	static std::string data[]={ std::string("Niall"),
								std::string("is"),
								std::string("a"),
								std::string("teapot")
								};
	array=data;
}

// ****** Where the CArray.h stuff begins ********

template<class T> class CArray
{
	// Sets subType::value to the type of the array's contents
	template<class sT> struct subType
	{
		typedef sT value;
	};
	template<class sT> struct subType<sT *>
	{
		typedef sT value;
	};
	//! The type the array contains
	typedef typename subType<T>::value memberType;
public:
	//! Type used to access array (and sets its upper and lower members)
	typedef boost::python::indexing::iterator_pair<memberType *> 
mTypeIt;
	//! Returns an appropriately wrapped array
	typename CArray<T>::mTypeIt getArray(MyList &l)
	{
		CArray<T>::memberType *data=l.getData();
		return CArray<T>::mTypeIt(data, data+1000); // Issue if l is near 
the 4Gb mark
	}
};



BOOST_PYTHON_MODULE(TestCArrays)
{
	boost::python::class_< CArray<std::string *>::mTypeIt 
>("CArray_string", 
		boost::python::init<std::string *, std::string *>())
		.def(boost::python::indexing::container_suite< CArray<std::string 
*>::mTypeIt >());

    boost::python::class_< MyList, boost::noncopyable >("MyList")
		.def("getData", &getArray<std::string *>)
		;

}




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031012/0a91e0df/attachment.pgp>

From RaoulGough at yahoo.co.uk  Sun Oct 12 19:05:30 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sun, 12 Oct 2003 18:05:30 +0100
Subject: [C++-sig] Re: IntWrapper.hpp in indexing_suite
References: <uoewojabd.fsf@yahoo.co.uk> <3F88BAD9.5838.117FD47C@localhost>
Message-ID: <uekxijsit.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 11 Oct 2003 at 19:45, Niall Douglas wrote:
>
> Fixed it!
>
> The below works lovely, and my thanks for the advice. The problem was 
> the boost::noncopyable in the MyListCArray declaration.

I wouldn't have guessed that it had to do with the noncopyable, so I
don't think I actually helped out at all. Still, a good result in the
end :-)

>
> Ok, next question: How do you determine the return type of a function 
> pointer? It must be possible as bpl determines return type in def() - 
> get_signature() from signature.hpp looked hopeful, but it appears to 
> be a run-time not compile-time function.
>
> To clarify:
>
> std::string *foo();
>
> typedef result_of<&foo>::value return_type;
>
> .... and return_type is std::string *.

Not sure if this is how Boost.Python does it, but the Boost
type_traits library would be sufficient for what you described
above. See the "Function Traits" section of libs/type_traits/index.htm
for details.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Sun Oct 12 19:22:04 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sun, 12 Oct 2003 18:22:04 +0100
Subject: [C++-sig] Re: IntWrapper.hpp in indexing_suite
References: <uoewojabd.fsf@yahoo.co.uk> <3F885DEC.4065.1014D51E@localhost>
Message-ID: <uad86jrr7.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 11 Oct 2003 at 12:14, Raoul Gough wrote:
>
>> I've used IntWrapper in a number of different test cases, and ISTR one
>> of them needed a conversion to shared pointer. I suspect that test
>> didn't make it into the CVS, so the shared pointer conversion is
>> currently redundant.
>
> Right, sorry, as I mentioned before I don't quite get how all this 
> works ...
>
>> I don't think the shared pointer conversion has anything to do with
>> this. The really important bit is this:
>> 
>>   boost::python::class_<IntWrapper> ("IntWrapper",
>>   boost::python::init<int>())
>>     .def ("increment", &IntWrapper::increment)
>>     .def ("__repr__", repr)
>>     .def ("__cmp__", compare)
>>     ;
>> 
>> which turns IntWrapper into a Python class, with enough support to
>> convert it to a string and compare two IntWrapper objects. There is
>> also an implicit conversion from int, which means that code like this
>> will work:
>
> Hang on, back up a way bit. Firstly, you appear to be implying that 
> the sequence in python is actually of IntWrapper's, not real int's. 
> Actually, now that looks obvious, but I hadn't realised that before.
>
> Therefore the down conversion from an IntWrapper to an int is 
> happening when python pulls a value /from/ the sequence eg; 
> repr(sequence).

I don't think that Python ever converts the IntWrapper to an int - the
__repr__ method returns a string. Although the int member variable is
publically visible, AFAIR there isn't any external code that accesses
it.

>
> Ok, I now get why there's the __cmp__ and __repr__. But why the 
> increment()? Surely that should be __inc__ or something? (I can't 
> find __inc__ anywhere in the python docs. But it can't be a reference 
> count as there's no way of reading it, decrementing it and besides, 
> it's incrementing the value, not a refCount).

As you surmise, the increment doesn't have anything to do with the
reference counting. It's just a minimal mutation function to
facilitate checking whether two Python objects refer to the same
IntWrapper object or not - the tests typically call obj1.increment()
and check whether the values of obj1 and obj2 are still identical
after the change. That's really the main reason to have IntWrapper (or
int_wrapper as it will soon be called) apart from the optional
tracing, which isn't currently used.

>
> Actually, how the hell is bpl converting an IntWrapper to an int? I 
> understand how int becomes IntWrapper (the explicit copy 
> constructor), but not vice versa!
>
>> > 	CArrayMember<std::string> 
>> > *data=static_cast<CArrayMember<std::string> *>(l.getData());
>> 
>> Wow. This is almost certainly undefined behaviour.
>
> Might be according to the standard, but if CArrayMember<> contains no 
> data members, there's no chance of copy slicing and thus no problem.

I guess it would be pretty surprising for the types to have different
layouts or sizes if you don't add any more data members. I think the
risk exists in theory at least, so other compilers or compiler options
might break the code. There is also the (maybe not so theoretical)
risk that somebody accidentally adds a member variable to the class
template.

>
>> > 	return 
>> > boost::python::indexing::iterator_pair<CArrayMember<std::string> *>
>> > 		(data, data+100000); // Issue if l is near the 4Gb mark
>> > }
>> 
>> The bounds checking code will still be compiled, of course, so lying
>> about the bound doesn't actually gain you anything (unless you have no
>> way of figuring out the real bound). You should be able to provide the
>> correct bound without too much trouble in this example.
>
> Yeah twas temporary code I'll fix later. I was going to have a 
> template parameter take an address to a function which when called, 
> returns the length of the array (seeing as that function varies 
> between classes). And a template specialisation taking arrays with 
> length attached.

Ah ha. Now it makes sense.

>
>> OK, so CArrayMember<std::string> is-a std::string. You still haven't
>> exposed it to Python though. You will need something like this:
>> 
>> class_<CArrayMember<std::string>, bases<std::string> >
>>    ("CArrayMember_string");
>> 
>> I don't know exactly what else you'll have to do here - maybe define
>> implicit conversions to/from std::string, maybe make it no_init. The
>> container suite doesn't attempt to expose the container's value type
>> to Python - it assumes that you will do that yourself. I would suggest
>> first trying to get CArrayMember<...> working in Python before trying
>> to expose a container of CArrayMembers.
>
> I had been assuming that std::string already has a registered 
> converter converting it to a python string.

Yes, it does. I hadn't really thought this through before, but the
implicit conversion from derived to base must mean that Boost.Python
can already return the string portion of the object to Python. This
may result in object slicing if you're returning the object by value,
though (I guess not a problem in this case).

>
> But what's *very* important to understand here is that soon I'll
> make the std::string a template parameter as I want it to be
> generically applicable ie; you can wrap any C++ object with the
> necessary gumph to make it a member of a sequence.
>
> Ideally however I'd like to somehow divorce the conversion of the
> types in the array from the accessing of the array. The conversions
> are already registered and mapped to python types - my CArray code
> should merely index the array and return a type (often pointer to
> type) to the array member which then BPL converts as it would
> normally do (when returned from a method) to its corresponding
> python type.

Sounds alright to me.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From s_sourceforge at nedprod.com  Mon Oct 13 04:33:34 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 13 Oct 2003 03:33:34 +0100
Subject: C arrays solution (was: Re: [C++-sig] Re: IntWrapper.hpp in
	indexing_suite)
In-Reply-To: <uekxijsit.fsf@yahoo.co.uk>
Message-ID: <3F8A1D0E.13673.16E77326@localhost>

On 12 Oct 2003 at 18:05, Raoul Gough wrote:

> > The below works lovely, and my thanks for the advice. The problem
> > was the boost::noncopyable in the MyListCArray declaration.
> 
> I wouldn't have guessed that it had to do with the noncopyable, so I
> don't think I actually helped out at all. Still, a good result in the
> end :-)

Well I had reached that point of despair when you just stare at the 
code and hope something comes to you. That did, and hey presto!

> > Ok, next question: How do you determine the return type of a
> > function pointer? It must be possible as bpl determines return type
> > in def() - get_signature() from signature.hpp looked hopeful, but it
> > appears to be a run-time not compile-time function.
> 
> Not sure if this is how Boost.Python does it, but the Boost
> type_traits library would be sufficient for what you described
> above. See the "Function Traits" section of libs/type_traits/index.htm
> for details.

Actually this came to me as a sort of epiphany today as I was hauling 
rigging off a boat - some number of hours later and I have the below, 
the very first working proof of concept.

I should also add that the below is my VERY FIRST C++ metaprogram. I 
failed a job interview for not knowing it, bought Andrei's Modern C++ 
Design immediately afterwards and have been playing with it on & off 
since for the last four months. But not until today did I actually 
ever write something on my own bat not copied from elsewhere. I feel 
like my very first 1000 line program in BBC Basic nearly two decades 
ago now!

Note the below is nasty (especially my choice of non-distinctive 
naming) and only supports one instance currently. I'm going to need a 
functor more generic than the boost one in order to store a hash 
table of functions from which I can correctly invoke translation (you 
can see the hack I used below to access the function pointers). Thus 
chances are that my end effort will be compatible with my library, 
but not yours.

Thoughts on the below? Is it worth you integrating similar 
functionality and thus all other bpl users can use it? Or is this too 
esoteric and/or demanding to warrant inclusion?

Cheers,
Niall

--- cut ---
#include <boost/python.hpp>
#include <boost/python/suite/indexing/container_suite.hpp>
#include <boost/python/suite/indexing/iterator_pair.hpp>
#include <boost/python/suite/indexing/container_proxy.hpp>
#include <string>

class MyList
{
	std::string *array;
public:
	MyList();
	std::string *getData() { return array; }
	int getDataLen() const { return 4; }
};

MyList::MyList()
{
	static std::string data[]={ std::string("Niall"),
								std::string("is"),
								std::string("a"),
								std::string("teapot")
								};
	array=data;
}

// ****** Where the CArray.h stuff begins ********

static void *carray;
template<typename getArrayFn, typename getLenFn> class CArray
{
	// Gets the return type of getArrayFn
	template<typename fn> struct fnInfo;
	template<typename R, typename O> struct fnInfo<R (O::*)()>
	{
		typedef R resultType;
		typedef O objectType;
	};
	typedef typename fnInfo<getArrayFn> arrayFnInfo;
	typedef typename arrayFnInfo::resultType arrayType;
	// Sets subType::value to the type of the array's contents (ie; 
arrayType less an indirection level)
	template<class sT> struct subType;
	template<class sT> struct subType<sT *>
	{
		typedef sT value;
	};
	getArrayFn getArrayFunc;	// Gets the array data
	getLenFn getLenFunc;		// Gets the length of the array data
public:
	//! The type of the container
	typedef typename arrayFnInfo::objectType container;
	//! The type the array contains
	typedef typename subType<arrayType>::value memberType;
	//! Type used to access array (and sets its upper and lower members)
	typedef boost::python::indexing::iterator_pair<memberType *> 
mTypeIt;

	//! Constructor
	CArray(getArrayFn _getArrayFunc, getLenFn _getLenFunc)
		: getArrayFunc(_getArrayFunc), getLenFunc(_getLenFunc)
	{
		boost::python::class_<mTypeIt>("CArray_unique", 
			boost::python::init<memberType *, memberType *>())
			.def(boost::python::indexing::container_suite<mTypeIt>());
	}
	//! Returns an appropriately wrapped array
	static typename mTypeIt getArray(container &l)
	{
		CArray<getArrayFn, getLenFn> *that=(CArray<getArrayFn, getLenFn> *) 
carray;		// Temporary
		memberType *data=(l.*that->getArrayFunc)();
		return mTypeIt(data, data+(l.*that->getLenFunc)());
	}
	//! A type representing the getArray function above
	typedef typename mTypeIt (*getArrayFunctionType)(container &);
};


template<typename getArrayFn, typename getLenFn> typename 
CArray<getArrayFn, getLenFn>::getArrayFunctionType 
MakeCArray(getArrayFn a, getLenFn b)
{
	carray=(void *) new CArray<getArrayFn, getLenFn>(a, b);
	return &CArray<getArrayFn, getLenFn>::getArray;
}

BOOST_PYTHON_MODULE(TestCArrays)
{
    boost::python::class_< MyList, boost::noncopyable >("MyList")
		.def("getData", MakeCArray(&MyList::getData, &MyList::getDataLen))
	;
}





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031013/283d8ae0/attachment.pgp>

From RaoulGough at yahoo.co.uk  Mon Oct 13 11:01:19 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 13 Oct 2003 10:01:19 +0100
Subject: [C++-sig] Re: C arrays solution
References: <uekxijsit.fsf@yahoo.co.uk> <3F8A1D0E.13673.16E77326@localhost>
Message-ID: <uwub9ik9s.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 12 Oct 2003 at 18:05, Raoul Gough wrote:
[snip]
>> Not sure if this is how Boost.Python does it, but the Boost
>> type_traits library would be sufficient for what you described
>> above. See the "Function Traits" section of libs/type_traits/index.htm
>> for details.
>
> Actually this came to me as a sort of epiphany today as I was hauling 
> rigging off a boat - some number of hours later and I have the below, 
> the very first working proof of concept.
>
> I should also add that the below is my VERY FIRST C++ metaprogram. I 
> failed a job interview for not knowing it, bought Andrei's Modern C++ 
> Design immediately afterwards and have been playing with it on & off 
> since for the last four months. But not until today did I actually 
> ever write something on my own bat not copied from elsewhere. I feel 
> like my very first 1000 line program in BBC Basic nearly two decades 
> ago now!
>
> Note the below is nasty (especially my choice of non-distinctive 
> naming) and only supports one instance currently. I'm going to need a 
> functor more generic than the boost one in order to store a hash 
> table of functions from which I can correctly invoke translation (you 
> can see the hack I used below to access the function pointers). Thus 
> chances are that my end effort will be compatible with my library, 
> but not yours.
>
> Thoughts on the below? Is it worth you integrating similar 
> functionality and thus all other bpl users can use it? Or is this too 
> esoteric and/or demanding to warrant inclusion?
[snip]

I can't really comment on this, because I don't understand what the
code is supposed to do. Can you explain the motivation for it?

I have the feeling that you may be reinventing one or two wheels as
well - e.g. have you considered using std::vector or boost::array, and
what about type_traits? Also, I wonder about the use of member
function pointers - is there an easier way to get what you want?

> static void *carray;
> ...
> carray=(void *) new CArray<getArrayFn, getLenFn>(a, b);

This look pretty suspect to me - what's going on here?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From collar at gamic.com  Mon Oct 13 15:53:25 2003
From: collar at gamic.com (Benjamin Collar)
Date: Mon, 13 Oct 2003 15:53:25 +0200
Subject: [C++-sig] problems compiling and embedding, boost-python
Message-ID: <200310131553.25984.collar@gamic.com>

Greetings

I'm trying for the first time to embed the python interpreter in my 
application. I'm using boost from today's CVS and gcc 3.3.1. I'm just trying 
to follow the example from the boost-python documentation. I've got two 
problems, one of which I solved and one I haven't. Any help would be 
appreciated.

When I try this:

handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));
handle<>( PyRun_String("hello = file('hello.txt', 'w')\n"
                           "hello.write('Hello world!')\n"
                           "hello.close()", Py_file_input,
                           main_namespace.get(), main_namespace.get()) );

I get:
main.cc: In function `int main(int, char**)':
main.cc:37: error: no matching function for call to `
   boost::python::handle<PyObject>::handle(const char[73], int, PyObject*, 
   PyObject*)'
/home/bc/HEAD/muranxx3/include/boost/python/handle.hpp:129: error: candidates 
   are: 
   
boost::python::handle<T>::handle(boost::python::detail::borrowed_reference_t*)
   [with T = PyObject]
/home/bc/HEAD/muranxx3/include/boost/python/handle.hpp:110: error:              
      boost::python::handle<T>::handle(const boost::python::handle<T>&) [with 
T 
   = PyObject]
/home/bc/HEAD/muranxx3/include/boost/python/handle.hpp:187: error:              
      boost::python::handle<T>::handle() [with T = PyObject]


No Problem, all I have to do is replace the last function with:

handle<> x(PyRun_String(...)

If I declare a variable it compiles fine.

However, moving right along in the documentation, if I try to compile this:

    handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
    dict main_namespace(handle<>(borrowed( PyModule_GetDict(main_module.get()) 
)));
    handle<>( PyRun_String("result = 5 ** 2", Py_file_input,
                           main_namespace.ptr(), main_namespace.ptr()) );
    int five_squared = extract<int>( main_namespace["result"] );

I get this, which I do not know how to resolve:

main.cc: In function `int main(int, char**)':
main.cc:33: error: variable declaration is not allowed here
main.cc:35: error: request for member `ptr' in `main_namespace()', which is of 
   non-aggregate type `boost::python::dict ()()'
main.cc:35: error: request for member `ptr' in `main_namespace()', which is of 
   non-aggregate type `boost::python::dict ()()'
main.cc:36: error: invalid types `boost::python::dict ()()[const char[7]]' for 
   array subscript
main.cc:36: warning: unused variable `int five_squared'

What's up with this last one?

Thanks
Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From pierre.barbier at cirad.fr  Mon Oct 13 16:16:57 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 13 Oct 2003 16:16:57 +0200
Subject: [C++-sig] problems compiling and embedding, boost-python
In-Reply-To: <200310131553.25984.collar@gamic.com>
References: <200310131553.25984.collar@gamic.com>
Message-ID: <1066054617.581.10.camel@pbarbier>

Which version of Python to you want to embed ?

Because I had experienced problem with python 2.3 but I have a working
embedded interpreter with Python 2.2.


Le lun 13/10/2003 ? 15:53, Benjamin Collar a ?crit :
> Greetings
> 
> I'm trying for the first time to embed the python interpreter in my 
> application. I'm using boost from today's CVS and gcc 3.3.1. I'm just trying 
> to follow the example from the boost-python documentation. I've got two 
> problems, one of which I solved and one I haven't. Any help would be 
> appreciated.
> 
> When I try this:
> 
> handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
> handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));
> handle<>( PyRun_String("hello = file('hello.txt', 'w')\n"
>                            "hello.write('Hello world!')\n"
>                            "hello.close()", Py_file_input,
>                            main_namespace.get(), main_namespace.get()) );
> 
> I get:
> main.cc: In function `int main(int, char**)':
> main.cc:37: error: no matching function for call to `
>    boost::python::handle<PyObject>::handle(const char[73], int, PyObject*, 
>    PyObject*)'
> /home/bc/HEAD/muranxx3/include/boost/python/handle.hpp:129: error: candidates 
>    are: 
>    
> boost::python::handle<T>::handle(boost::python::detail::borrowed_reference_t*)
>    [with T = PyObject]
> /home/bc/HEAD/muranxx3/include/boost/python/handle.hpp:110: error:              
>       boost::python::handle<T>::handle(const boost::python::handle<T>&) [with 
> T 
>    = PyObject]
> /home/bc/HEAD/muranxx3/include/boost/python/handle.hpp:187: error:              
>       boost::python::handle<T>::handle() [with T = PyObject]
> 
> 
> No Problem, all I have to do is replace the last function with:
> 
> handle<> x(PyRun_String(...)
> 
> If I declare a variable it compiles fine.
> 
> However, moving right along in the documentation, if I try to compile this:
> 
>     handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>     dict main_namespace(handle<>(borrowed( PyModule_GetDict(main_module.get()) 
> )));
>     handle<>( PyRun_String("result = 5 ** 2", Py_file_input,
>                            main_namespace.ptr(), main_namespace.ptr()) );
>     int five_squared = extract<int>( main_namespace["result"] );
> 
> I get this, which I do not know how to resolve:
> 
> main.cc: In function `int main(int, char**)':
> main.cc:33: error: variable declaration is not allowed here
> main.cc:35: error: request for member `ptr' in `main_namespace()', which is of 
>    non-aggregate type `boost::python::dict ()()'
> main.cc:35: error: request for member `ptr' in `main_namespace()', which is of 
>    non-aggregate type `boost::python::dict ()()'
> main.cc:36: error: invalid types `boost::python::dict ()()[const char[7]]' for 
>    array subscript
> main.cc:36: warning: unused variable `int five_squared'
> 
> What's up with this last one?
> 
> Thanks
> Ben
-- 
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 collar at gamic.com  Mon Oct 13 16:20:19 2003
From: collar at gamic.com (Benjamin Collar)
Date: Mon, 13 Oct 2003 16:20:19 +0200
Subject: [C++-sig] problem importing my own module
Message-ID: <200310131620.19939.collar@gamic.com>

Greetings

Here's the other problem I've been fighting with today and haven't found an 
answer for yet.  Perhaps I've totally misunderstood what has to be done in my 
code. I'd appreciate it if someone could help me accomplish the following.

1. Write a module that exposes a little bit of my library code
2. Using the embedded interpreter, evaluate a python script which imports the 
code written in 1.

So far:
1. I've gotten a script to import the module I made and print some 
results--just calling the script from the command line.
2. However, whenever I attempt "import MyModule" with code like what's below, 
I get an core dump:

    handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
    handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));
    handle<> x( PyRun_String(
      "import PyMuranLog"
      , Py_file_input, main_namespace.get(), main_namespace.get()) );

Thanks for any help or explanation. I guess I'd really like know what kind of 
linking or C code is necessary to allow importing my module in the script. 

The module (built with bjam under the boost/libs/python directory) is 
available within the PYTHONPATH. I also copied the .so to 
/usr/lib/python2.2/site-packages but it still core dumps. 

I don't mind having a PyImport_AddModule call in my code, but I haven't gotten 
any of those sort of calls working yet either.

Sincerely
Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From collar at gamic.com  Mon Oct 13 16:26:33 2003
From: collar at gamic.com (Benjamin Collar)
Date: Mon, 13 Oct 2003 16:26:33 +0200
Subject: [C++-sig] problems compiling and embedding, boost-python
In-Reply-To: <1066054617.581.10.camel@pbarbier>
References: <200310131553.25984.collar@gamic.com>
	<1066054617.581.10.camel@pbarbier>
Message-ID: <200310131626.33214.collar@gamic.com>

Greetings Pierre,

On Monday 13 October 2003 16:16, Pierre Barbier de Reuille wrote:
> Which version of Python to you want to embed ?

I'm trying to embed 2.2 right now since the main/stable boost-python appears 
to support only this.

Thanks
Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From collar at gamic.com  Mon Oct 13 16:27:33 2003
From: collar at gamic.com (Benjamin Collar)
Date: Mon, 13 Oct 2003 16:27:33 +0200
Subject: [C++-sig] problem importing my own module
In-Reply-To: <200310131620.19939.collar@gamic.com>
References: <200310131620.19939.collar@gamic.com>
Message-ID: <200310131627.33751.collar@gamic.com>

Greetings again

I forgot one example. This causes it to core as well:

    handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
    handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));
    handle<> l_module(PyImport_ImportModule("PyMuranLog"));
    handle<> x( PyRun_String(
    "hello = file('hello.txt', 'w')\n"
                           "hello.write('Hello world!')\n"
                           "hello.close()", Py_file_input,
                           main_namespace.get(), main_namespace.get()) );

Again, thanks for your help

Ben

On Monday 13 October 2003 16:20, Benjamin Collar wrote:
> Greetings
>
> Here's the other problem I've been fighting with today and haven't found an
> answer for yet.  Perhaps I've totally misunderstood what has to be done in
> my code. I'd appreciate it if someone could help me accomplish the
> following.
>
> 1. Write a module that exposes a little bit of my library code
> 2. Using the embedded interpreter, evaluate a python script which imports
> the code written in 1.
>
> So far:
> 1. I've gotten a script to import the module I made and print some
> results--just calling the script from the command line.
> 2. However, whenever I attempt "import MyModule" with code like what's
> below, I get an core dump:
>
>     handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>     handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get())
> )); handle<> x( PyRun_String(
>       "import PyMuranLog"
>       , Py_file_input, main_namespace.get(), main_namespace.get()) );
>
> Thanks for any help or explanation. I guess I'd really like know what kind
> of linking or C code is necessary to allow importing my module in the
> script.
>
> The module (built with bjam under the boost/libs/python directory) is
> available within the PYTHONPATH. I also copied the .so to
> /usr/lib/python2.2/site-packages but it still core dumps.
>
> I don't mind having a PyImport_AddModule call in my code, but I haven't
> gotten any of those sort of calls working yet either.
>
> Sincerely
> Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From collar at gamic.com  Mon Oct 13 16:41:43 2003
From: collar at gamic.com (Benjamin Collar)
Date: Mon, 13 Oct 2003 16:41:43 +0200
Subject: [C++-sig] problem importing my own module
In-Reply-To: <200310131553.25984.collar@gamic.com>
References: <200310131553.25984.collar@gamic.com>
Message-ID: <200310131641.43297.collar@gamic.com>

Greetings,

I think the problem is solved. All the examples I just posted about core dumps 
have gone away, since I read more of the documentation and added:

-Xlinker -export-dynamic

to my link line.

Sorry for the bother.

Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From s_sourceforge at nedprod.com  Mon Oct 13 23:22:38 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 13 Oct 2003 22:22:38 +0100
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <uwub9ik9s.fsf@yahoo.co.uk>
Message-ID: <3F8B25AE.27326.1AF1259D@localhost>

On 13 Oct 2003 at 10:01, Raoul Gough wrote:

> > Thoughts on the below? Is it worth you integrating similar 
> > functionality and thus all other bpl users can use it? Or is this
> > too esoteric and/or demanding to warrant inclusion?
> [snip]
> 
> I can't really comment on this, because I don't understand what the
> code is supposed to do. Can you explain the motivation for it?

The motivation is with a single call to wrap C arrays. Let me give 
you an example:

I have a class FXObjectList which is a bespoke container for 
FXObject's. Among the many fun things it does which normal containers 
would not it also returns the container's contents as a C array and 
provides another method returning the length. Let's call them 
FXObject *getData() and int getDataLen().

Now when wrapping FXObjectList I already have FXObject wrapped - it 
does it's own thing and there's no problem. Just FXObjectList. Before 
I could not wrap FXObjectList without lots of custom code whereas 
with code like I previously posted, it becomes as simple as:

boost::python::class_<FXObjectList, 
boost::noncopyable>("FXObjectList")
        .def("getData", MakeCArray(&FXObjectList::getData, 
&FXObjectList::getDataLen))

And bam!, in one fell swoop the problem is solved.

Another problem I have is that the library I am wrapping provides 
static const indexed lists of constant strings (providing stuff like 
DND target names and MIME types). It's very hard to provide these to 
python code but again with the above, bam! and the problem is solved.

Lastly I have some code which unfortunately returns a pointer to a 
single value just so it can indicate "value is invalid" by returning 
a null pointer. In this situation a MakeCArray(&function, 1) means 
once again bam!, and the problem is solved.

> I have the feeling that you may be reinventing one or two wheels as
> well - e.g. have you considered using std::vector or boost::array, and
> what about type_traits?

I'm wrapping a large preexisting library which is not my own. It uses 
many idioms which make translation into python hard which has up 
until now made python wrappings for the library very tough to 
maintain.

> Also, I wonder about the use of member
> function pointers - is there an easier way to get what you want?

Not at all. Those member functions are the official interface for 
accessing the array's contents. They must be called at run-time to 
yield correct access.

> > static void *carray;
> > ...
> > carray=(void *) new CArray<getArrayFn, getLenFn>(a, b);
> 
> This look pretty suspect to me - what's going on here?

More temporary code bootstrapping in static data. The actual 
implementation will use a generic functor class I'm writing to store 
the function pointers in a global list which is hash-indexed.

As I previously mentioned, it was a proof of concept.

Now I've explained, your thoughts on whether it would be of use to 
others?

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031013/6c012ede/attachment.pgp>

From dave at boost-consulting.com  Tue Oct 14 01:12:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Oct 2003 19:12:22 -0400
Subject: [C++-sig] Re: C arrays solution
References: <uwub9ik9s.fsf@yahoo.co.uk> <3F8B25AE.27326.1AF1259D@localhost>
Message-ID: <upth0zq95.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> boost::python::class_<FXObjectList, 
> boost::noncopyable>("FXObjectList")
>         .def("getData", MakeCArray(&FXObjectList::getData, 
> &FXObjectList::getDataLen))
>
> And bam!, in one fell swoop the problem is solved.

I'm not sure I know exactly what problem you're solving (what do you
expect to be able to do with the result of this getData call?)  but
your use of a global pointer to hold the result is terribly
unsafe... not to mention the fact that your code leaks CArray objects
like a sieve.

If you're satisfied with that, I guess I'm satisfied.  Otherwise,
perhaps you'd like to post a little more detail about how you want to
be able to *use* this code from Python?  I think people here,
especially Raoul, should be able to make some suggestions which would
solve the problem in a more principled way.

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




From RaoulGough at yahoo.co.uk  Tue Oct 14 02:00:53 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 14 Oct 2003 01:00:53 +0100
Subject: [C++-sig] Re: C arrays solution
References: <uwub9ik9s.fsf@yahoo.co.uk> <3F8B25AE.27326.1AF1259D@localhost>
Message-ID: <uoewkr8lm.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 13 Oct 2003 at 10:01, Raoul Gough wrote:
>
>> > Thoughts on the below? Is it worth you integrating similar 
>> > functionality and thus all other bpl users can use it? Or is this
>> > too esoteric and/or demanding to warrant inclusion?
>> [snip]
>> 
>> I can't really comment on this, because I don't understand what the
>> code is supposed to do. Can you explain the motivation for it?
>
> The motivation is with a single call to wrap C arrays. Let me give 
> you an example:
>
> I have a class FXObjectList which is a bespoke container for 
> FXObject's. Among the many fun things it does which normal containers 
> would not it also returns the container's contents as a C array and 
> provides another method returning the length. Let's call them 
> FXObject *getData() and int getDataLen().
>
> Now when wrapping FXObjectList I already have FXObject wrapped - it 
> does it's own thing and there's no problem. Just FXObjectList. Before 
> I could not wrap FXObjectList without lots of custom code whereas 
> with code like I previously posted, it becomes as simple as:
>
> boost::python::class_<FXObjectList, 
> boost::noncopyable>("FXObjectList")
>         .def("getData", MakeCArray(&FXObjectList::getData, 
> &FXObjectList::getDataLen))
>
> And bam!, in one fell swoop the problem is solved.
>
> Another problem I have is that the library I am wrapping provides 
> static const indexed lists of constant strings (providing stuff like 
> DND target names and MIME types). It's very hard to provide these to 
> python code but again with the above, bam! and the problem is solved.
>
> Lastly I have some code which unfortunately returns a pointer to a 
> single value just so it can indicate "value is invalid" by returning 
> a null pointer. In this situation a MakeCArray(&function, 1) means 
> once again bam!, and the problem is solved.
>
>> I have the feeling that you may be reinventing one or two wheels as
>> well - e.g. have you considered using std::vector or boost::array, and
>> what about type_traits?
>
> I'm wrapping a large preexisting library which is not my own. It uses 
> many idioms which make translation into python hard which has up 
> until now made python wrappings for the library very tough to 
> maintain.

Now I'm beginning to understand :-) You can't re-use (for instance)
boost::array because this library already does things its own way.

>
>> Also, I wonder about the use of member
>> function pointers - is there an easier way to get what you want?
>
> Not at all. Those member functions are the official interface for 
> accessing the array's contents. They must be called at run-time to 
> yield correct access.

It was more a question of how you inform your wrapper layer what
functions should be called. e.g. you could use a traits class, which
would take care of this on a per-type basis (assuming that the
functions to call don't vary from one object to another). Or you could
just use function overloading, something like the indexing::begin()
and indexing::end() functions for arrays.

>
>> > static void *carray;
>> > ...
>> > carray=(void *) new CArray<getArrayFn, getLenFn>(a, b);
>> 
>> This look pretty suspect to me - what's going on here?
>
> More temporary code bootstrapping in static data. The actual 
> implementation will use a generic functor class I'm writing to store 
> the function pointers in a global list which is hash-indexed.
>
> As I previously mentioned, it was a proof of concept.
>
> Now I've explained, your thoughts on whether it would be of use to 
> others?

Well, it's starting to make more sense to me. In fact, I think there
is already something similar to this which returns a Python iterator
instead of an indexing::iterator_pair. IIRC it's called
boost::python::range or similar. The iterator_pair (with the container
suite) has far more functionality than a Python iterator, of course.

To summarise: this boils down to a method for generating an
iterator_pair from an arbitrary object which has some way of
generating two iterators. Does that sound about right?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From snyder at fnal.gov  Tue Oct 14 04:44:02 2003
From: snyder at fnal.gov (scott snyder)
Date: Mon, 13 Oct 2003 21:44:02 -0500
Subject: [C++-sig] pyste suggestion: easier overriding of exporters
Message-ID: <200310140244.h9E2i2N81017569@d0mino.fnal.gov>


hi -

In the course of playing with pyste, i've made numerous minor
fixes and extensions.  In such cases, i'd like to be able to keep
my new code in the .pyste file (or something imported from there)
rather than having to change the pyste code itself.

One way of extending pyste is to use one's own Exporter classes.
In most cases, these can derive from the existing ones, modifying
any needed behaviors.

There is, however, no clean way to specify in a .pyste file that you
want to use a custom exporter class.  In the past, i've done this
by duplicating the classes that derive from DeclarationInfo and
changing the Exporter class, i.e., doing something like this:

class Class (DeclarationInfo):
    def __init__(self, name, include, tail=None, otherInfo=None):
        DeclarationInfo.__init__(self, otherInfo)
        self._Attribute('name', name)
        self._Attribute('include', include)
        self._Attribute('exclude', False)
        # create a ClassExporter
        exporter = My_Class_Exporter(InfoWrapper(self), tail)
        exporters.exporters.append(exporter)
        exporter.interface_file = exporters.current_interface

and then importing this into the pyste file.

This is not entirely satisfactory, due to the pyste code that must
be duplicated here.  One also runs into a problem with ClassExporter,
as its ExportNestedClasses method also has a reference to
`ClassExporter' literally coded.

I would suggest allowing for such extensions by adding an (optional)
argument to the constructors of the info classes giving the class
to use for the exporter.  Thus, if someone wants to use a non-standard
exporter for a particular declaration, it can just be specified
in the Class() or whatever call.  Then if i want all classes to use
my custom exporter, i can do something like this:

def Class (name, include, tail=None, otherInfo=None):
    return ClassInfo (name, include, tail, otherInfo,
                      exporter_class = My_Class_Exporter)

avoiding having to duplicate the code from ClassInfo.

The patches below implement this.
I added an optional parameter `exporter_class' to the info class
constructors, giving the class to use for the exporter.  I also
modified ClassExporter.ExportNestedClasses to create the nested
class exporters using the same class as the current exporter,
rather than hardwiring in ClassExporter.

sss



Index: ClassExporter.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/pyste/src/Pyste/ClassExporter.py,v
retrieving revision 1.14
diff -u -p -r1.14 ClassExporter.py
--- ClassExporter.py	6 Oct 2003 19:10:50 -0000	1.14
+++ ClassExporter.py	13 Oct 2003 18:29:32 -0000
@@ -598,7 +600,7 @@ class ClassExporter(Exporter):
             nested_info = self.info[nested_class.name]
             nested_info.include = self.info.include
             nested_info.name = nested_class.FullName()
-            exporter = ClassExporter(nested_info)
+            exporter = self.__class__(nested_info)
             exporter.SetDeclarations(self.declarations)
             codeunit = SingleCodeUnit(None, None)
             exporter.Export(codeunit, exported_names)
Index: infos.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/pyste/src/Pyste/infos.py,v
retrieving revision 1.9
diff -u -p -r1.9 infos.py
--- infos.py	6 Oct 2003 19:10:50 -0000	1.9
+++ infos.py	13 Oct 2003 18:29:32 -0000
@@ -56,13 +56,14 @@ class DeclarationInfo:
 #==============================================================================
 class FunctionInfo(DeclarationInfo):
 
-    def __init__(self, name, include, tail=None, otherOption=None):        
+    def __init__(self, name, include, tail=None, otherOption=None,
+                 exporter_class = FunctionExporter):        
         DeclarationInfo.__init__(self, otherOption)
         self._Attribute('name', name)
         self._Attribute('include', include)
         self._Attribute('exclude', False)
         # create a FunctionExporter
-        exporter = FunctionExporter(InfoWrapper(self), tail)
+        exporter = exporter_class(InfoWrapper(self), tail)
         if exporter not in exporters.exporters:
             exporters.exporters.append(exporter)
         exporter.interface_file = exporters.current_interface
@@ -73,13 +74,14 @@ class FunctionInfo(DeclarationInfo):
 #==============================================================================
 class ClassInfo(DeclarationInfo):
 
-    def __init__(self, name, include, tail=None, otherInfo=None):
+    def __init__(self, name, include, tail=None, otherInfo=None,
+                 exporter_class = ClassExporter):
         DeclarationInfo.__init__(self, otherInfo)
         self._Attribute('name', name)
         self._Attribute('include', include)
         self._Attribute('exclude', False)
         # create a ClassExporter
-        exporter = ClassExporter(InfoWrapper(self), tail)
+        exporter = exporter_class(InfoWrapper(self), tail)
         if exporter not in exporters.exporters: 
             exporters.exporters.append(exporter) 
         exporter.interface_file = exporters.current_interface 
@@ -96,10 +98,12 @@ def GenerateName(name, type_list):
     
 class ClassTemplateInfo(DeclarationInfo):
 
-    def __init__(self, name, include):
+    def __init__(self, name, include,
+                 exporter_class = ClassExporter):
         DeclarationInfo.__init__(self)
         self._Attribute('name', name)
         self._Attribute('include', include)
+        self._exporter_class = exporter_class
 
 
     def Instantiate(self, type_list, rename=None):
@@ -111,7 +115,8 @@ class ClassTemplateInfo(DeclarationInfo)
         tail += 'void __instantiate_%s()\n' % rename
         tail += '{ sizeof(%s); }\n\n' % rename
         # create a ClassInfo
-        class_ = ClassInfo(rename, self._Attribute('include'), tail, self)
+        class_ = ClassInfo(rename, self._Attribute('include'), tail, self,
+                           exporter_class = self._exporter_class)
         return class_
 
 
@@ -125,13 +130,13 @@ class ClassTemplateInfo(DeclarationInfo)
 #==============================================================================
 class EnumInfo(DeclarationInfo):
     
-    def __init__(self, name, include):
+    def __init__(self, name, include, exporter_class = EnumExporter):
         DeclarationInfo.__init__(self)
         self._Attribute('name', name)
         self._Attribute('include', include)
         self._Attribute('exclude', False)
         self._Attribute('export_values', False)
-        exporter = EnumExporter(InfoWrapper(self))
+        exporter = exporter_class(InfoWrapper(self))
         if exporter not in exporters.exporters: 
             exporters.exporters.append(exporter)
         exporter.interface_file = exporters.current_interface 
@@ -142,10 +147,10 @@ class EnumInfo(DeclarationInfo):
 #==============================================================================
 class HeaderInfo(DeclarationInfo):
 
-    def __init__(self, include):
+    def __init__(self, include, exporter_class = HeaderExporter):
         DeclarationInfo.__init__(self)
         self._Attribute('include', include)
-        exporter = HeaderExporter(InfoWrapper(self))
+        exporter = exporter_class(InfoWrapper(self))
         if exporter not in exporters.exporters: 
             exporters.exporters.append(exporter)
         exporter.interface_file = exporters.current_interface 
@@ -156,11 +161,11 @@ class HeaderInfo(DeclarationInfo):
 #==============================================================================
 class VarInfo(DeclarationInfo):
     
-    def __init__(self, name, include):
+    def __init__(self, name, include, exporter_class = VarExporter):
         DeclarationInfo.__init__(self)
         self._Attribute('name', name)
         self._Attribute('include', include)
-        exporter = VarExporter(InfoWrapper(self))
+        exporter = exporter_class(InfoWrapper(self))
         if exporter not in exporters.exporters: 
             exporters.exporters.append(exporter)
         exporter.interface_file = exporters.current_interface 
@@ -171,11 +176,11 @@ class VarInfo(DeclarationInfo):
 #==============================================================================
 class CodeInfo(DeclarationInfo):
 
-    def __init__(self, code, section):
+    def __init__(self, code, section, exporter_class = CodeExporter):
         DeclarationInfo.__init__(self)
         self._Attribute('code', code)
         self._Attribute('section', section)
-        exporter = CodeExporter(InfoWrapper(self))
+        exporter = exporter_class(InfoWrapper(self))
         if exporter not in exporters.exporters:
             exporters.exporters.append(exporter)
         exporter.interface_file = exporters.current_interface



From s_sourceforge at nedprod.com  Tue Oct 14 03:01:22 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 14 Oct 2003 02:01:22 +0100
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <upth0zq95.fsf@boost-consulting.com>
Message-ID: <3F8B58F2.7044.1BB9676C@localhost>

On 13 Oct 2003 at 19:12, David Abrahams wrote:

> > boost::python::class_<FXObjectList, 
> > boost::noncopyable>("FXObjectList")
> >         .def("getData", MakeCArray(&FXObjectList::getData, 
> > &FXObjectList::getDataLen))
> >
> > And bam!, in one fell swoop the problem is solved.
> 
> I'm not sure I know exactly what problem you're solving (what do you
> expect to be able to do with the result of this getData call?)  but
> your use of a global pointer to hold the result is terribly unsafe...
> not to mention the fact that your code leaks CArray objects like a
> sieve.

Again, all artifacts of proof of concept code. The hard part for me 
was the compile-time programming.

I should add that in all the code I've written in the last three 
years, I've had a total of I think eight memory leaks ever (according 
to valgrind and MSVC's debug CRT memory leak facilities). And that's 
over 50,000 lines now, probably more.

> If you're satisfied with that, I guess I'm satisfied.  Otherwise,
> perhaps you'd like to post a little more detail about how you want to
> be able to *use* this code from Python?  I think people here,
> especially Raoul, should be able to make some suggestions which would
> solve the problem in a more principled way.

>>> from TestCArrays import *
>>> a=MyList()
>>> b=a.getData()
>>> print len(b)
4
>>> print b[0:4]
['Niall', 'is', 'a', 'teapot']
>>> b[1]="is not"
>>> print b[0:4]
['Niall', 'is not', 'a', 'teapot']

The key here is that MyList knows nothing of python and offers no 
more than a C array of pointers, something which up until now was 
hard to wrap without lots of munge code.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031014/b6d9b42c/attachment.pgp>

From s_sourceforge at nedprod.com  Tue Oct 14 03:22:39 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 14 Oct 2003 02:22:39 +0100
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <uoewkr8lm.fsf@yahoo.co.uk>
Message-ID: <3F8B5DEF.13867.1BCCE1C0@localhost>

On 14 Oct 2003 at 1:00, Raoul Gough wrote:

> > I'm wrapping a large preexisting library which is not my own. It
> > uses many idioms which make translation into python hard which has
> > up until now made python wrappings for the library very tough to
> > maintain.
> 
> Now I'm beginning to understand :-) You can't re-use (for instance)
> boost::array because this library already does things its own way.

Precisely. It doesn't even use the STL and its authors have clearly 
stated that the STL is *not* *permitted* to enter the library. 
Furthermore while they'll agree to /minor/ changes, they won't go for 
anything more than trivial.

Also while they have python bindings which they use a lot (they like 
python), they are only for the stable release and not the development 
release and thus are very out of date. The existing bindings are 
generated using SWIG and are a real pain to keep up to date - indeed 
they are sufficiently convoluted that I believe one of the SWIG 
authors is the only one able to substantially modify them.

> >> Also, I wonder about the use of member
> >> function pointers - is there an easier way to get what you want?
> >
> > Not at all. Those member functions are the official interface for
> > accessing the array's contents. They must be called at run-time to
> > yield correct access.
> 
> It was more a question of how you inform your wrapper layer what
> functions should be called. e.g. you could use a traits class, which
> would take care of this on a per-type basis (assuming that the
> functions to call don't vary from one object to another).

Already thought of that and they do vary in name from container to 
container.

> Or you could
> just use function overloading, something like the indexing::begin()
> and indexing::end() functions for arrays.

That's interesting, but wouldn't it require a separate declaration of 
the required functions somewhere beforehand? The solution I chose 
means very minimal manual editing of pyste's output - in fact, I'm 
going to make it a diff file applied by scons after calling pyste.

> > Now I've explained, your thoughts on whether it would be of use to
> > others?
> 
> Well, it's starting to make more sense to me. In fact, I think there
> is already something similar to this which returns a Python iterator
> instead of an indexing::iterator_pair. IIRC it's called
> boost::python::range or similar. The iterator_pair (with the container
> suite) has far more functionality than a Python iterator, of course.

Does boost::python::range provide random access? I don't think it 
does.

Basically, I want to make C arrays available as lists to python. Your 
suite (and thank you for it) with my little extension appears to do 
this very nicely indeed.

For example, there's now no reason why a bitmap's contents cannot be 
directly manipulated by python eg; bitmapdata[4]=0xff puts a white 
pixel at (4,0) on the screen.

> To summarise: this boils down to a method for generating an
> iterator_pair from an arbitrary object which has some way of
> generating two iterators. Does that sound about right?

Nearly.

This boils down to a method for generating an iterator_pair from an 
arbitrary object providing no more than a pointer and a length. The 
pointer and length can be retrieved from any arbitrary function 
except ones which return the value through their parameters (a lambda 
wrap could fix these though).

Once I'm done with the overloads, you won't even need a container 
object. I have several static global arrays I need to provide to 
python.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031014/16da90d6/attachment.pgp>

From collar at gamic.com  Tue Oct 14 11:21:39 2003
From: collar at gamic.com (Benjamin Collar)
Date: Tue, 14 Oct 2003 11:21:39 +0200
Subject: [C++-sig] getting result from the interpreter -- boost-python
Message-ID: <200310141121.39776.collar@gamic.com>

Greetings

Yesterday I posted a question that hasn't been commented on until now...No 
problem. It was kind of a messy question anyway.

I've sort of found an answer. However, the example in the documentation does 
not work properly in my environment. Here's the example:

    handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
    dict main_namespace(handle<>(borrowed( PyModule_GetDict(main_module.get()) 
)));
    handle<>( PyRun_String("result = 5 ** 2", Py_file_input,
                           main_namespace.ptr(), main_namespace.ptr()) );
    int five_squared = extract<int>( main_namespace["result"] );

This will not compile:
  main.cc: In function `int main(int, char**)':
  main.cc:33: error: variable declaration is not allowed here
  main.cc:35: error: request for member `ptr' in `main_namespace()', which is 
of non-aggregate type `boost::python::dict ()()'
  main.cc:35: error: request for member `ptr' in `main_namespace()', which is 
of non-aggregate type `boost::python::dict ()()'
  main.cc:36: error: invalid types `boost::python::dict ()()[const char[7]]' 
for array subscript

I can get it to compile if I dereference the handle<> when declaring 
main_namespace--but then it throws and exception.  What I have below will 
compile and gives me the right result but seems messy and perhaps leaks?  If 
someone could tell me the 'right' way to do this, I'd appreciate it:

    handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
    handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));
    handle<> rs( PyRun_File(fp, const_cast<char *>("test.py")),
      Py_file_input, main_namespace.get(), main_namespace.get()));
    fclose(fp);
    object x(main_namespace);
    dict m_n = extract<dict>(x);
    int pi = extract<int>(m_n["i"]);

Thanks again
Ben


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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From collar at gamic.com  Tue Oct 14 11:41:11 2003
From: collar at gamic.com (Benjamin Collar)
Date: Tue, 14 Oct 2003 11:41:11 +0200
Subject: [C++-sig] preventing an infinite loop
In-Reply-To: <3F8B5DEF.13867.1BCCE1C0@localhost>
References: <3F8B5DEF.13867.1BCCE1C0@localhost>
Message-ID: <200310141141.11445.collar@gamic.com>

Greetings

I'm embedding python in order to allow our customers to decide, using a python 
script, whether certain messages in the system are distributed to other 
instances of the system. The script must assign 1 or 0 to a variable called 
SendIt (I'm going for the simplest solution at the moment...) and I read that 
variable's value after the script finishes.

I'd like to know what people do to ensure that the script doesn't enter an 
infinite loop. If that's not possible, how can one detect that the script is 
in an infinite loop and stop it. The solution that's been considered so far 
is to run the interpreter in its own thread and put a limit on its run time. 
But I figure there's got to be a better way.

Thanks for any suggestions.

Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From RaoulGough at yahoo.co.uk  Tue Oct 14 12:43:54 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 14 Oct 2003 11:43:54 +0100
Subject: [C++-sig] Re: C arrays solution
References: <uoewkr8lm.fsf@yahoo.co.uk> <3F8B5DEF.13867.1BCCE1C0@localhost>
Message-ID: <uk778qetx.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 14 Oct 2003 at 1:00, Raoul Gough wrote:
[snip]
>> >> Also, I wonder about the use of member
>> >> function pointers - is there an easier way to get what you want?
>> >
>> > Not at all. Those member functions are the official interface for
>> > accessing the array's contents. They must be called at run-time to
>> > yield correct access.
>> 
>> It was more a question of how you inform your wrapper layer what
>> functions should be called. e.g. you could use a traits class, which
>> would take care of this on a per-type basis (assuming that the
>> functions to call don't vary from one object to another).
>
> Already thought of that and they do vary in name from container to 
> container.

Do you mean they just vary from container type to container type? Or
from one instance of a container type to another? For instance, the
standard library can use char_traits::eq to compare chars, because the
comparison function doesn't vary from one char object to another (just
from one *type* of char to another).

>
>> Or you could
>> just use function overloading, something like the indexing::begin()
>> and indexing::end() functions for arrays.
>
> That's interesting, but wouldn't it require a separate declaration of 
> the required functions somewhere beforehand? The solution I chose 
> means very minimal manual editing of pyste's output - in fact, I'm 
> going to make it a diff file applied by scons after calling pyste.

Yes it would. However, I would assume that the number of different
types of containers within the library is more or less fixed, so you
could just put this sort of thing in a separate header:

template<typename Element>
boost::python::indexing::iterator_pair<Element *>
make_iter_pair (container_type_1<Element> &c1)
{
  return boost::python::indexing::iterator_pair<Element *>
    (c1.getArray(), c1.getArray() + c1.getLength());
}

template<typename Element>
boost::python::indexing::iterator_pair<Element *>
make_iter_pair (container_type_2<Element> &c)
{
  return boost::python::indexing::iterator_pair<Element *>
    (c2.get_array(), c2.get_array() + c2.get_length());
}

Basically, you've somewhere got to say "use getArray here" and "use
get_array" there. If that is invariant on the container type, why mess
around with storing pointers to member functions in every object?
Things would be a bit different if you have a single type that
contains two or more different sequences and you want to select from
any of them at run-time.

>
>> > Now I've explained, your thoughts on whether it would be of use to
>> > others?
>> 
>> Well, it's starting to make more sense to me. In fact, I think there
>> is already something similar to this which returns a Python iterator
>> instead of an indexing::iterator_pair. IIRC it's called
>> boost::python::range or similar. The iterator_pair (with the container
>> suite) has far more functionality than a Python iterator, of course.
>
> Does boost::python::range provide random access? I don't think it 
> does.

Like I said, the iterator pair/container suite combination provides a
lot more functionality, but that doesn't really affect the choice of
interface, since the only requirement is somehow to provide an
iterator range through it. The range() function accepts pointers to
member functions, pointers to normal functions or even pointers to
member variables. Just to prove all my ideas ill-founded, it doesn't
support traits or function overloading :-)

> Basically, I want to make C arrays available as lists to python. Your 
> suite (and thank you for it) with my little extension appears to do 
> this very nicely indeed.
>
> For example, there's now no reason why a bitmap's contents cannot be 
> directly manipulated by python eg; bitmapdata[4]=0xff puts a white 
> pixel at (4,0) on the screen.

Of course, this particular example wouldn't be very fast. That
expression results in a whole bunch of Boost.Python code being
executed to figure out which C++ functions to call and how to extract
the C++ objects from the Python ones. Where you really get performance
is if you can do one call from Python to C++ that then performs a
whole lot of processing.

>
>> To summarise: this boils down to a method for generating an
>> iterator_pair from an arbitrary object which has some way of
>> generating two iterators. Does that sound about right?
>
> Nearly.
>
> This boils down to a method for generating an iterator_pair from an 
> arbitrary object providing no more than a pointer and a length. The 
> pointer and length can be retrieved from any arbitrary function 
> except ones which return the value through their parameters (a lambda 
> wrap could fix these though).

On the other hand, the begin() and end() style is more general.  It's
also easy enough to write a wrapper for it if you only have begin()
and length(), but not so in the other direction. For example, if your
container doesn't have random access, using begin() and length()
doesn't make sense at all.

>
> Once I'm done with the overloads, you won't even need a container 
> object. I have several static global arrays I need to provide to 
> python.

Maybe something like this would be useful to have in the library?

  template<typename T, std::size_t N>
  iterator_pair<T *> make_iterator_pair (T (&array)[N])
  {
    return iterator_pair<T *>(array, array + N);
  }

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Tue Oct 14 13:42:47 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Oct 2003 07:42:47 -0400
Subject: [C++-sig] Re: C arrays solution
References: <upth0zq95.fsf@boost-consulting.com>
	<3F8B58F2.7044.1BB9676C@localhost>
Message-ID: <uvfqsxcy0.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

>> If you're satisfied with that, I guess I'm satisfied.  Otherwise,
>> perhaps you'd like to post a little more detail about how you want to
>> be able to *use* this code from Python?  I think people here,
>> especially Raoul, should be able to make some suggestions which would
>> solve the problem in a more principled way.
>
>>>> from TestCArrays import *
>>>> a=MyList()
>>>> b=a.getData()
>>>> print len(b)
> 4
>>>> print b[0:4]
> ['Niall', 'is', 'a', 'teapot']
>>>> b[1]="is not"
>>>> print b[0:4]
> ['Niall', 'is not', 'a', 'teapot']
>
> The key here is that MyList knows nothing of python and offers no 
> more than a C array of pointers, something which up until now was 
> hard to wrap without lots of munge code.

I'm not sure what "munge code" means.  The behavior you show above is
almost trivial to achieve using Boost.Python, without anything I
consider to be "munge code".

Question 1:  when you modify b above, do you expect it to affect a?

Question 2:  do you expect b to be an actual Python list,
             i.e. type(b) == list ??


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




From dave at boost-consulting.com  Tue Oct 14 14:25:53 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Oct 2003 08:25:53 -0400
Subject: [C++-sig] Re: getting result from the interpreter -- boost-python
References: <200310141121.39776.collar@gamic.com>
Message-ID: <upth0xay6.fsf@boost-consulting.com>

[Dirk & Joel, please see below]

Benjamin Collar <collar at gamic.com> writes:

> Greetings
>
> Yesterday I posted a question that hasn't been commented on until now...No 
> problem. It was kind of a messy question anyway.
>
> I've sort of found an answer. However, the example in the documentation does 
> not work properly in my environment. 
                       ^^^^^^^^^^^^^^
...which is... ??

> Here's the example:
>
>     handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>     dict main_namespace(handle<>(borrowed( PyModule_GetDict(main_module.get()) 
> )));
>     handle<>( PyRun_String("result = 5 ** 2", Py_file_input,
>                            main_namespace.ptr(), main_namespace.ptr()) );
>     int five_squared = extract<int>( main_namespace["result"] );
>
> This will not compile:
>   main.cc: In function `int main(int, char**)':
>   main.cc:33: error: variable declaration is not allowed here
>   main.cc:35: error: request for member `ptr' in `main_namespace()', which is 
> of non-aggregate type `boost::python::dict ()()'
>   main.cc:35: error: request for member `ptr' in `main_namespace()', which is 
> of non-aggregate type `boost::python::dict ()()'
>   main.cc:36: error: invalid types `boost::python::dict ()()[const char[7]]' 
> for array subscript

Posting error messages which cite errors on line 33 for a 5-line
example is bound to be confusing for anyone, so it's a bit difficutlt
to help you.  There's a lot of information missing.

> I can get it to compile if I dereference the handle<> when declaring 
> main_namespace--but then it throws and exception.

The problem is that the line declaring "main_namespace" is declaring
a function which returns a dict.  But where did you get that line?
It's not in any of the docs I can find.

I'd write:
    
    // Retrieve the main module
    python::object main_module = python::extract<python::object>(
        PyImport_AddModule("__main__")
    );
    
    // Retrieve the main module's namespace
    python::object main_namespace = main_module.attr("__dict__");
    
or, if your code has to run on broken compilers like vc6:

    // Retrieve the main module
    python::object main_module = python::extract<python::object>(
        PyImport_AddModule("__main__")
    )();
    
    // Retrieve the main module's namespace
    python::object main_namespace(main_module.attr("__dict__"));

In fact, I would like it very much if we could change the examples in
the tutorial to use this style.  It's far simpler and clearer, IMO.
    
>  What I have below will 
> compile and gives me the right result but seems messy and perhaps leaks?  If 
> someone could tell me the 'right' way to do this, I'd appreciate it:


There are no leaks here AFAICT.

>     handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>     handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));
>     handle<> rs( PyRun_File(fp, const_cast<char *>("test.py")),
>       Py_file_input, main_namespace.get(), main_namespace.get()));
>     fclose(fp);
>     object x(main_namespace);
>     dict m_n = extract<dict>(x);
>     int pi = extract<int>(m_n["i"]);

Building a dict is really unneccessary here.  You can just as easily
index an object:

     int pi = extract<int>(x["i"]);

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




From collar at gamic.com  Tue Oct 14 14:50:16 2003
From: collar at gamic.com (Benjamin Collar)
Date: Tue, 14 Oct 2003 14:50:16 +0200
Subject: [C++-sig] Re: getting result from the interpreter -- boost-python
In-Reply-To: <upth0xay6.fsf@boost-consulting.com>
References: <200310141121.39776.collar@gamic.com>
	<upth0xay6.fsf@boost-consulting.com>
Message-ID: <200310141450.16097.collar@gamic.com>

Hello David,

On Tuesday 14 October 2003 14:25, David Abrahams wrote:
> > does not work properly in my environment.
>                        ^^^^^^^^^^^^^^
> ...which is... ??
GCC 3.3.1, Python 2.3.2, Gentoo Linux.

I've reposted the example here, with line numbers in front. The line numbers 
start at 32 because I cut and pasted the code from the tutorial directly into 
my application, right in the middle (after some app initialization and 
whatnot). The place where I got the example? 
http://www.boost.org/libs/python/doc/tutorial/doc/using_the_interpreter.html

> > Here's the example:

32  handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
33  dict main_namespace(handle<>(borrowed(
        PyModule_GetDict(main_module.get()) )));
34  handle<>( PyRun_String("result = 5 ** 2", Py_file_input,
35    main_namespace.ptr(), main_namespace.ptr()) );
36  int five_squared = extract<int>( main_namespace["result"] );

> > This will not compile:
> >   main.cc: In function `int main(int, char**)':
> >   main.cc:33: error: variable declaration is not allowed here
> >   main.cc:35: error: request for member `ptr' in `main_namespace()',
> > which is of non-aggregate type `boost::python::dict ()()'
> >   main.cc:35: error: request for member `ptr' in `main_namespace()',
> > which is of non-aggregate type `boost::python::dict ()()'
> >   main.cc:36: error: invalid types `boost::python::dict ()()[const
> > char[7]]' for array subscript

>
> I'd write:
> [example cut]
> In fact, I would like it very much if we could change the examples in
> the tutorial to use this style.  It's far simpler and clearer, IMO.
Me too! That's easier to understand.

I appreciate your help. The code looks a little simpler on my end now.

Thanks
Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From RaoulGough at yahoo.co.uk  Tue Oct 14 17:20:42 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 14 Oct 2003 16:20:42 +0100
Subject: [C++-sig] Extensible slice support in new indexing suite
Message-ID: <ufzhvrgl1.fsf@yahoo.co.uk>

After some offline disucssion with Joel de Guzman, I've made slice
support configurable in the new indexing suite (it was already
configurable in the original suite). This is designed to support
client-code extensions for slices with non-integer index types.

Here's an overview of how it works: there is an indexing::slice class,
which is registered for automatic conversion from PySlice_Type
objects. The code that actually extracts the indexes from the Python
object is separated into a new indexing::integer_slice class, which
take the plain slice for construction. Client code can now select an
alternative implementation intead of integer_slice as follows.

The slice_handler template relies on a typedef "slice_helper" and
factory function "make_slice_helper" provided by its Algorithms
argument. The only existing implementation is int_slice_helper, which
inter-operates with the integer_slice class, or anything else which
can provide similar start, stop, step and in_range functions. For the
sort of cases Joel and I were discussing, I would expect
int_slice_helper to be sufficiently generic so you would only have to
provide a new class to extract the bounds from the Python slice object
(i.e. a new version of integer_slice) and override the typedef and the
factory function.  Other cases, like slices in a std::map, would
probably require a complete new slice_helper, e.g. an
iterator_slice_helper.

BTW, I've also added support for overriding basic support functions in
the algorithms templates like begin() and end() using the curiously
recurring template idiom. However, that's unrelated to the slice
extensions - hopefully it won't confuse the issue too much.

I'll get started on proper documentation for all this sometime
soonish, but if anyone has comments on the code already, please let me
know.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From s_sourceforge at nedprod.com  Tue Oct 14 23:39:52 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 14 Oct 2003 22:39:52 +0100
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <uvfqsxcy0.fsf@boost-consulting.com>
Message-ID: <3F8C7B38.28072.20274746@localhost>

On 14 Oct 2003 at 7:42, David Abrahams wrote:

> > The key here is that MyList knows nothing of python and offers no
> > more than a C array of pointers, something which up until now was
> > hard to wrap without lots of munge code.
> 
> I'm not sure what "munge code" means.  The behavior you show above is
> almost trivial to achieve using Boost.Python, without anything I
> consider to be "munge code".

I'm getting that picture from Raoul. However if it's so easy, why is 
Raoul developing indexing_suite?

> Question 1:  when you modify b above, do you expect it to affect a?

Yes.

> Question 2:  do you expect b to be an actual Python list,
>              i.e. type(b) == list ??

Not really as it can't be extended in length. So while it looks like 
a list and acts like a list, it's not a list.

(Don't worry, the users will know this. And remember this affects 
about seven different areas of the library which I've never used so 
basically I'm providing a default action for users so they can tell 
me afterwards if they don't like it).

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031014/2715b625/attachment.pgp>

From s_sourceforge at nedprod.com  Tue Oct 14 23:46:48 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 14 Oct 2003 22:46:48 +0100
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <uk778qetx.fsf@yahoo.co.uk>
Message-ID: <3F8C7CD8.11676.202DA0B3@localhost>

On 14 Oct 2003 at 11:43, Raoul Gough wrote:

> > Already thought of that and they do vary in name from container to
> > container.
> 
> Do you mean they just vary from container type to container type? Or
> from one instance of a container type to another? For instance, the
> standard library can use char_traits::eq to compare chars, because the
> comparison function doesn't vary from one char object to another (just
> from one *type* of char to another).

No, they're fixed per container.

> > That's interesting, but wouldn't it require a separate declaration
> > of the required functions somewhere beforehand? The solution I chose
> > means very minimal manual editing of pyste's output - in fact, I'm
> > going to make it a diff file applied by scons after calling pyste.
> 
> Yes it would. However, I would assume that the number of different
> types of containers within the library is more or less fixed, so you
> could just put this sort of thing in a separate header:
> [snip]
> 
> Basically, you've somewhere got to say "use getArray here" and "use
> get_array" there. If that is invariant on the container type, why mess
> around with storing pointers to member functions in every object?
> Things would be a bit different if you have a single type that
> contains two or more different sequences and you want to select from
> any of them at run-time.

Your approach looks better. If that really does work as easily as 
sticking those little bits of code in, I'll go for that instead.

> > For example, there's now no reason why a bitmap's contents cannot be
> > directly manipulated by python eg; bitmapdata[4]=0xff puts a white
> > pixel at (4,0) on the screen.
> 
> Of course, this particular example wouldn't be very fast. That
> expression results in a whole bunch of Boost.Python code being
> executed to figure out which C++ functions to call and how to extract
> the C++ objects from the Python ones. Where you really get performance
> is if you can do one call from Python to C++ that then performs a
> whole lot of processing.

That's cool with me. I just want to provide as full a toolset as 
possible and let the users decide what's best for them.

> > Once I'm done with the overloads, you won't even need a container
> > object. I have several static global arrays I need to provide to
> > python.
> 
> Maybe something like this would be useful to have in the library?
> 
>   template<typename T, std::size_t N>
>   iterator_pair<T *> make_iterator_pair (T (&array)[N])
>   {
>     return iterator_pair<T *>(array, array + N);
>   }

Well I'll find this out tonight, but if that little bit of code like 
the above is all I need, I'll go for that.

Why aren't useful things like that in the docs? What I'm doing is 
surely a common problem to a lot of people wrapping C++ (ie; wrapping 
C arrays) - though I'll admit I've never seen anyone ask about it 
before in the archives.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031014/27d84143/attachment.pgp>

From collar at gamic.com  Wed Oct 15 16:19:30 2003
From: collar at gamic.com (Benjamin Collar)
Date: Wed, 15 Oct 2003 16:19:30 +0200
Subject: [C++-sig] is there a recent CVS tag I can use?
Message-ID: <200310151619.30274.collar@gamic.com>

Greetings again,

The latest release doesn't completely work for me--I run into the 
method_call_expr not supported by dump_expr problem. This problem is 
rectified in the CVS. But I'd really rather use a release, or at least a 
known tag, than just CVS HEAD. Is there a tag I can check out?

Thanks
Ben

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

(o__      Benjamin Collar
//\       GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From dave at boost-consulting.com  Wed Oct 15 17:38:03 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 11:38:03 -0400
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <3F8C7B38.28072.20274746@localhost>
References: <uvfqsxcy0.fsf@boost-consulting.com>
	<3F8C7B38.28072.20274746@localhost>
Message-ID: <bmjpkt$ncf$1@sea.gmane.org>

Niall Douglas wrote:

> On 14 Oct 2003 at 7:42, David Abrahams wrote:
> 
> 
>>>The key here is that MyList knows nothing of python and offers no
>>>more than a C array of pointers, something which up until now was
>>>hard to wrap without lots of munge code.
>>
>>I'm not sure what "munge code" means.  The behavior you show above is
>>almost trivial to achieve using Boost.Python, without anything I
>>consider to be "munge code".
> 
> 
> I'm getting that picture from Raoul. However if it's so easy, why is 
> Raoul developing indexing_suite?

To handle reference and lifetime issues which are mostly not relevant to 
you because your container holds strings, which are immutable in Python.

>>Question 1:  when you modify b above, do you expect it to affect a?
> 
> 
> Yes.
> 
> 
>>Question 2:  do you expect b to be an actual Python list,
>>             i.e. type(b) == list ??
> 
> 
> Not really as it can't be extended in length. So while it looks like 
> a list and acts like a list, it's not a list.

In that case, I suggest you just make a getData function which returns 
self.  That'll make your life *way* simpler.





From s_sourceforge at nedprod.com  Wed Oct 15 18:30:55 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Oct 2003 17:30:55 +0100
Subject: [C++-sig] Indexing_suite when container is newed
Message-ID: <3F8D844F.26416.2432C8EF@localhost>

Right, last error in the last file - everything else compiles! I have 
a method called lasso() in FXGLViewer which returns an array of 
FXGLObject pointers falling within the specified coordinates.

Unfortunately the list returned is malloced and if not freed after 
python is done with it would leak memory. My initial attempt was as 
below:

static indexing::iterator_pair<FXGLObject **> 
FXGLViewer_lasso(FXGLViewer &c, FXint x1,FXint y1,FXint x2,FXint y2)
{
	typedef indexing::iterator_pair<FXGLObject **> IterPair;
	class_<IterPair>( "FXGLViewer_lassoIndirect", init<FXGLObject **, 
FXGLObject **>())
		.def(indexing::container_suite<IterPair>
			::with_policies(return_value_policy<manage_new_object>()));
	FXGLObject **data=c.lasso(x1,y1,x2,y2);
	return IterPair(data, data+(1<<16));
}

However it would appear that setting a policy at the container_suite 
level sets it for the iterator_pair which isn't what I want. Anyway 
besides the list is malloced and not newed, though in fact I've 
replaced new and delete with my own versions which do call malloc.

What one would want is the ability to call a destructor when the 
iterator_pair is destroyed. Unfortunately I can't hack in a 
destructor because it gets lost in the downcast and I can't use 
auto_ptr because both of the iterators must be the same type (and the 
end of array is not a valid memory location). So I'm guessing it 
needs added support.

I'd imagine copy construction needs to be destructive so myBegin and 
myEnd would need to become mutable and one would need a user-
overridable destructor.

Or perhaps one could create a new custom type of return policy and 
set that instead?

Thoughts?

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/e3033c03/attachment.pgp>

From s_sourceforge at nedprod.com  Wed Oct 15 03:38:36 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Oct 2003 02:38:36 +0100
Subject: [C++-sig] C arrays mk 2
Message-ID: <3F8CB32C.2681.2101D79B@localhost>

This is for reference only to anyone else that might have this 
problem and searches the list archive in times to come. People who 
don't like macros beware!

My most gracious thanks to Raoul Gough for helping me in this. You're 
now in the acknowledgements for the library.

Cheers,
Niall

--- cut ---
#include <boost/python.hpp>
#include <boost/python/suite/indexing/container_suite.hpp>
#include <boost/python/suite/indexing/iterator_pair.hpp>
#include <boost/python/suite/indexing/container_proxy.hpp>
#include <string>

class MyList
{
	std::string *array;
public:
	MyList();
	std::string *getData() { return array; }
	int getDataLen() const { return 4; }
};

MyList::MyList()
{
	static std::string data[]={ std::string("Niall"),
								std::string("is"),
								std::string("a"),
								std::string("teapot")
								};
	array=data;
}

// ****** Where the CArray.h stuff begins ********

#define DEFINE_MAKECARRAYITER(contType, memberType, getArrayFunction, 
getArrayLengthFunction) \
	boost::python::indexing::iterator_pair<memberType *> Make 
##contType## Iter(contType &c) \
{ \
	typedef boost::python::indexing::iterator_pair<memberType *> 
IterPair; \
	boost::python::class_<IterPair>( #contType "Indirect", \
		boost::python::init<memberType *, memberType *>()) \
		.def(boost::python::indexing::container_suite<IterPair>()); \
	memberType *data=c.##getArrayFunction##; \
	return IterPair(data, data+c.##getArrayLengthFunction##); \
}

DEFINE_MAKECARRAYITER(MyList, std::string, getData(), getDataLen() )

BOOST_PYTHON_MODULE(TestCArrays)
{
    boost::python::class_< MyList, boost::noncopyable >("MyList")
		.def("getData", &MakeMyListIter)
	;
}





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/3efd0efc/attachment.pgp>

From dave at boost-consulting.com  Wed Oct 15 19:22:28 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 13:22:28 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <3F8CB32C.2681.2101D79B@localhost>
References: <3F8CB32C.2681.2101D79B@localhost>
Message-ID: <bmjvoo$7bi$1@sea.gmane.org>

Niall Douglas wrote:

> This is for reference only to anyone else that might have this 
> problem and searches the list archive in times to come. People who 
> don't like macros beware!
> 
> My most gracious thanks to Raoul Gough for helping me in this. You're 
> now in the acknowledgements for the library.
> 
> Cheers,
> Niall

This appears to me to be more complicated and less reliable than 
neccessary.  Why not just give your Python MyList class __len__ and 
__getitem__ functions?





From RaoulGough at yahoo.co.uk  Wed Oct 15 20:57:25 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 15 Oct 2003 19:57:25 +0100
Subject: [C++-sig] Re: Indexing_suite when container is newed
References: <3F8D844F.26416.2432C8EF@localhost>
Message-ID: <u8ynmib1m.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Right, last error in the last file - everything else compiles! I have 
> a method called lasso() in FXGLViewer which returns an array of 
> FXGLObject pointers falling within the specified coordinates.
>
> Unfortunately the list returned is malloced and if not freed after 
> python is done with it would leak memory. My initial attempt was as 
> below:
>
> static indexing::iterator_pair<FXGLObject **> 
> FXGLViewer_lasso(FXGLViewer &c, FXint x1,FXint y1,FXint x2,FXint y2)
> {
> 	typedef indexing::iterator_pair<FXGLObject **> IterPair;
> 	class_<IterPair>( "FXGLViewer_lassoIndirect", init<FXGLObject **, 
> FXGLObject **>())
> 		.def(indexing::container_suite<IterPair>
> 			::with_policies(return_value_policy<manage_new_object>()));
> 	FXGLObject **data=c.lasso(x1,y1,x2,y2);
> 	return IterPair(data, data+(1<<16));
> }

I suppose you have some kind of class_<> for FXGLObject, but how does
Python deal with the FXGLObject * that the suite returns? I mean,
iterator_pair does only one level of indirection, so what happens to
the plain pointer before it gets handed back to Python?

>
> However it would appear that setting a policy at the container_suite 
> level sets it for the iterator_pair which isn't what I want. Anyway 
> besides the list is malloced and not newed, though in fact I've 
> replaced new and delete with my own versions which do call malloc.

Not sure what you mean here - iterator_pair doesn't have any
policies. The container suite applies the policies to the results of
(for instance) iterator_pair<...>::operator[] which returns an
FXGLObject * in this case, AFAICS.

>
> What one would want is the ability to call a destructor when the 
> iterator_pair is destroyed. Unfortunately I can't hack in a 
> destructor because it gets lost in the downcast and I can't use 
> auto_ptr because both of the iterators must be the same type (and the 
> end of array is not a valid memory location). So I'm guessing it 
> needs added support.

Sounds about right to me. But you would currently have the same
problem in C++, anyway, so I would first suggest coming up with a
class to manage the array in C++. You could then expose *that* class
to Python, and give it a function that returns an iterator_pair via
the return_internal_reference return policy. You would then have
something like:

>>> array_manager = getArray(...)
>>> array = array_manager.iter_pair()  # return_internal_reference

You could reduce this to:

>>> array = getArray(...).iter_pair()

The return_internal_reference policy links the lifetime of the two
Python objects together, so in the latter case, when array disappears
(e.g. if you "del" it) it also causes the object returned from
getArray() to go.

>
> I'd imagine copy construction needs to be destructive so myBegin and 
> myEnd would need to become mutable and one would need a user-
> overridable destructor.
>
> Or perhaps one could create a new custom type of return policy and 
> set that instead?
>
> Thoughts?

Well, if I was in danger of forgetting how much easier programming
with std::vector and boost::shared_ptr is compared to malloc and
arrays in C, you've just reminding me :-)

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Wed Oct 15 21:08:24 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 15 Oct 2003 20:08:24 +0100
Subject: [C++-sig] Re: C arrays mk 2
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
Message-ID: <u1xteiajb.fsf@yahoo.co.uk>

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

> Niall Douglas wrote:
>
>> This is for reference only to anyone else that might have this
>> problem and searches the list archive in times to come. People who
>> don't like macros beware!
>> My most gracious thanks to Raoul Gough for helping me in
>> this. You're now in the acknowledgements for the library.
>> Cheers,
>> Niall
>
> This appears to me to be more complicated and less reliable than
> neccessary.  Why not just give your Python MyList class __len__ and
> __getitem__ functions?

I suppose it depends how rich an interface he wants on the Python
side. The two methods you named are sufficient for a lot of cases
(almost everything, in fact), but if he wants slice support or
__setitem__, it might still pay off to use the container suite. I
don't know - all of that C-style array stuff looks like doing things
the hard way to me.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Wed Oct 15 21:23:39 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 15:23:39 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <u1xteiajb.fsf@yahoo.co.uk>
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
	<u1xteiajb.fsf@yahoo.co.uk>
Message-ID: <bmk6ru$lsj$1@sea.gmane.org>

Raoul Gough wrote:

> David Abrahams <dave at boost-consulting.com> writes:
> 
> 
>>Niall Douglas wrote:
>>
>>
>>>This is for reference only to anyone else that might have this
>>>problem and searches the list archive in times to come. People who
>>>don't like macros beware!
>>>My most gracious thanks to Raoul Gough for helping me in
>>>this. You're now in the acknowledgements for the library.
>>>Cheers,
>>>Niall
>>
>>This appears to me to be more complicated and less reliable than
>>neccessary.  Why not just give your Python MyList class __len__ and
>>__getitem__ functions?
> 
> 
> I suppose it depends how rich an interface he wants on the Python
> side. The two methods you named are sufficient for a lot of cases
> (almost everything, in fact), but if he wants slice support or
> __setitem__, it might still pay off to use the container suite. 

Sure.  But his example just creates an iterator (the extremely hard 
way), and __len__ + __getitem__ already gets you an iterator and more.

 > I
> don't know - all of that C-style array stuff looks like doing things
> the hard way to me.

At least he's having fun ;-)





From s_sourceforge at nedprod.com  Wed Oct 15 19:38:49 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Oct 2003 18:38:49 +0100
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <bmjpkt$ncf$1@sea.gmane.org>
References: <3F8C7B38.28072.20274746@localhost>
Message-ID: <3F8D9439.4770.2470F486@localhost>

On 15 Oct 2003 at 11:38, David Abrahams wrote:

> >>>The key here is that MyList knows nothing of python and offers no
> >>>more than a C array of pointers, something which up until now was
> >>>hard to wrap without lots of munge code.
> >>
> >>I'm not sure what "munge code" means.  The behavior you show above
> >>is almost trivial to achieve using Boost.Python, without anything I
> >>consider to be "munge code".
> > 
> > I'm getting that picture from Raoul. However if it's so easy, why is
> > Raoul developing indexing_suite?
> 
> To handle reference and lifetime issues which are mostly not relevant
> to you because your container holds strings, which are immutable in
> Python.

?!?!?!?

Whatever gave you the idea my container holds strings? That was my 
*test* container and I chose strings because BPL already provides 
conversion to python types.

The real actual world use is for arbitrary bespoke containers 
returning arbitrary objects sometimes by value and sometimes by 
reference.

I did state that the code I posted was proof of concept many times!

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/0257f800/attachment.pgp>

From dave at boost-consulting.com  Wed Oct 15 23:10:19 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 17:10:19 -0400
Subject: [C++-sig] Re: C arrays solution
In-Reply-To: <3F8D9439.4770.2470F486@localhost>
References: <3F8C7B38.28072.20274746@localhost>
	<3F8D9439.4770.2470F486@localhost>
Message-ID: <bmkd3u$3e2$2@sea.gmane.org>

Niall Douglas wrote:

> On 15 Oct 2003 at 11:38, David Abrahams wrote:
> 
> 
>>>>>The key here is that MyList knows nothing of python and offers no
>>>>>more than a C array of pointers, something which up until now was
>>>>>hard to wrap without lots of munge code.
>>>>
>>>>I'm not sure what "munge code" means.  The behavior you show above
>>>>is almost trivial to achieve using Boost.Python, without anything I
>>>>consider to be "munge code".
>>>
>>>I'm getting that picture from Raoul. However if it's so easy, why is
>>>Raoul developing indexing_suite?
>>
>>To handle reference and lifetime issues which are mostly not relevant
>>to you because your container holds strings, which are immutable in
>>Python.
> 
> 
> ?!?!?!?
> 
> Whatever gave you the idea my container holds strings? 

Your examples did.  You can't really claim to be shocked, can you?

 > That was my
> *test* container and I chose strings because BPL already provides 
> conversion to python types.
> 
> The real actual world use is for arbitrary bespoke containers 

Hmm...

bespoke

Bespoke (pronounced bee-SPOHK) is a term used in the United Kingdom and 
elsewhere for an individually- or custom-made product or service. 
Traditionally applied to custom-tailored clothing, the term has been 
extended to information technology, especially for software consulting 
services. Typically, software consulting companies offer packaged 
(already invented and generally applicable) software and bespoke 
software for client needs that can't be satisfied by packaged software. 
In the U.S., bespoke software is often called custom or custom-designed 
software

OK.

> returning arbitrary objects sometimes by value and sometimes by 
> reference.

OK, then I'd use the suites if I were you.

> I did state that the code I posted was proof of concept many times!

I don't know why you're telling me that, but anyway... I was just trying 
to help you get to an easy and reliable solution.  If you're interested 
in pursuing your own homegrown solution, it's fine by me.  I'll be happy 
to go back to my other pursuits and stop pointing out that I think 
there's a better way.

Regards,
Dave





From RaoulGough at yahoo.co.uk  Wed Oct 15 23:24:30 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 15 Oct 2003 22:24:30 +0100
Subject: [C++-sig] Re: C arrays mk 2
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
	<u1xteiajb.fsf@yahoo.co.uk> <bmk6ru$lsj$1@sea.gmane.org>
Message-ID: <uwub6gpo1.fsf@yahoo.co.uk>

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

> Raoul Gough wrote:
[snip]
>> I suppose it depends how rich an interface he wants on the Python
>> side. The two methods you named are sufficient for a lot of cases
>> (almost everything, in fact), but if he wants slice support or
>> __setitem__, it might still pay off to use the container suite.
>
> Sure.  But his example just creates an iterator (the extremely hard
> way), and __len__ + __getitem__ already gets you an iterator and more.

That's right - it's neat how many Python expressions can work with
just those two methods (in fact, I think __len__ is not even necessary
for much of it, since IndexError works as well as StopIteration).
However, I think his code actually does enlist some extra
container_suite support via the iterator_pair container emulation,
which goes one or two steps further. The macros obscure it somewhat,
but I think it basically does this:

typedef indexing::iterator_pair<memberType *> IterPair;

class_<IterPair>("Name", init<...>)
  .def (indexing::container_suite<IterPair>());

Which usually gives you __getitem__ and __setitem__ with slice
support, as well as __len__, index, count, sort and reverse. Now
whether you actually need all that stuff is another question!

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From cedric at shockfamily.net  Wed Oct 15 23:33:44 2003
From: cedric at shockfamily.net (Cedric Shock)
Date: Wed, 15 Oct 2003 14:33:44 -0700
Subject: [C++-sig] boost::python::object and stl::map warning
Message-ID: <3F8DBD38.3000909@shockfamily.net>

To whomever can provide some assistance:

The following simple code (included below) attempts to implement a 
std::map of boost::python::object.

I have defined a map of the objects as:
std::map<boost::python::object, boost::python::object> data;

Given boost::python::objects oi and ov, the following works:
data[oi] = ov;

However, the follwing statements all produce a warning (explained below):
ov = data[oi];
data.count(oi);
data[oi].ptr();

So assignment to the map is warning free, however, attempting to read 
from the map raises this warning.

It compiles with g++ 3.2.2, and will work as expected in python. 
However, for each of those offending statements it produces a warning like:

(data.count(oi)):
warning: cannot pass objects of non-POD type `struct 
std::_Rb_tree_iterator<std::pair<const boost::python::api::object, 
boost::python::api::object>, const std::pair<const 
boost::python::api::object, boost::python::api::object>&, const 
std::pair<const boost::python::api::object, 
boost::python::api::object>*>' through `...'; call will abort at runtime

(data[oi].ptr()):
warning: cannot pass objects of non-POD type `struct 
std::_Rb_tree_iterator<std::pair<const boost::python::api::object, 
boost::python::api::object>, std::pair<const boost::python::api::object, 
boost::python::api::object>&, std::pair<const 
boost::python::api::object, boost::python::api::object>*>' through 
`...'; call will abort at runtime


This warning usually indicates that something bad has been done with a 
variable argument function like passing a non-POD type to printf. But it 
should not be an issue here. std::map is routinely used to deal with 
non-POD objects, why can't it handle the boost::python::object?

Thank you in advance for your help,

Cedric A. Shock



#############################################################
#include <map>
#include <boost/python.hpp>

// Interface for map
class PyObjectMap {
	public:
	int contains(PyObject* index);
	PyObject* getitem(PyObject* index);
	void setitem(PyObject* index, PyObject* value);

	private:
	std::map<boost::python::object, boost::python::object> data;
};


// Implelementation of map:
int PyObjectMap::contains(PyObject* index) {
	// Convert PyObject* to an object:
	boost::python::object o(boost::python::borrowed(index));
	// Return whether it is in the map:
	return data.count(o);
}

PyObject* PyObjectMap::getitem(PyObject* index) {
	// Convert PyObject* to an object:
	boost::python::object o(boost::python::borrowed(index));

	if (data.count(o)) {
		// Get the pointer:
		PyObject* ptr;
		ptr = data[o].ptr();
		// We are returning it.
		// That means there's one more reference out there:
		boost::python::incref(ptr);
		//return ptr;
		return ptr;
	} else {
		// Raise an exception: IndexError
		// Not implemented yet
		return 0;
	}

}

void PyObjectMap::setitem(PyObject* index, PyObject* value) {
	// Convert PyObject* to objects:
	boost::python::object oi(boost::python::borrowed(index));
	boost::python::object ov(boost::python::borrowed(value));
	// Store the value
	data[oi] = ov;
}

using namespace boost::python;

BOOST_PYTHON_MODULE(map)
{
	class_<PyObjectMap>("map")
		.def("getitem", &PyObjectMap::getitem)
		.def("__getitem__", &PyObjectMap::getitem)
		.def("setitem", &PyObjectMap::setitem)
		.def("__setitem__", &PyObjectMap::setitem)
		.def("contains", &PyObjectMap::contains)
		.def("__contains__", &PyObjectMap::contains)
	;
}
####################################################




From dave at boost-consulting.com  Thu Oct 16 00:01:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 18:01:26 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <uwub6gpo1.fsf@yahoo.co.uk>
References: <3F8CB32C.2681.2101D79B@localhost>
	<bmjvoo$7bi$1@sea.gmane.org>	<u1xteiajb.fsf@yahoo.co.uk>
	<bmk6ru$lsj$1@sea.gmane.org> <uwub6gpo1.fsf@yahoo.co.uk>
Message-ID: <bmkg3r$tpt$1@sea.gmane.org>

Raoul Gough wrote:
> David Abrahams <dave at boost-consulting.com> writes:
> 
> 
>>Raoul Gough wrote:
> 
> [snip]
> 
>>>I suppose it depends how rich an interface he wants on the Python
>>>side. The two methods you named are sufficient for a lot of cases
>>>(almost everything, in fact), but if he wants slice support or
>>>__setitem__, it might still pay off to use the container suite.
>>
>>Sure.  But his example just creates an iterator (the extremely hard
>>way), and __len__ + __getitem__ already gets you an iterator and more.
> 
> 
> That's right - it's neat how many Python expressions can work with
> just those two methods (in fact, I think __len__ is not even necessary
> for much of it, since IndexError works as well as StopIteration).
> However, I think his code actually does enlist some extra
> container_suite support via the iterator_pair container emulation,
> which goes one or two steps further. The macros obscure it somewhat,
> but I think it basically does this:
> 
> typedef indexing::iterator_pair<memberType *> IterPair;
> 
> class_<IterPair>("Name", init<...>)
>   .def (indexing::container_suite<IterPair>());

Ah, I didn't realize he was using the indexing suite.  Sorry!
I think I have some arguments with the naming of iterator_pair, which is 
part of what threw me off.
It really represents an "immutable sequence".  "iterator pair" is more 
like an implementation detail.

As a side note, please use boost::detail::iterator_traits instead of 
std::iterator_traits, for portability reasons.

As another side note, endline layout

   template<typename Iterator>
   iterator_pair<Iterator>::iterator_pair (iterator_param begin
                                           , iterator_param end)

is banned in Boost.Python.  Should be, e.g.:

   template<typename Iterator>
   iterator_pair<Iterator>::iterator_pair (
       iterator_param begin, iterator_param end)

;->

I'll stop picking nits with your excellent work now.

> Which usually gives you __getitem__ and __setitem__ with slice
> support, as well as __len__, index, count, sort and reverse. Now
> whether you actually need all that stuff is another question!

Indeed.






From RaoulGough at yahoo.co.uk  Thu Oct 16 00:29:40 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 15 Oct 2003 23:29:40 +0100
Subject: [C++-sig] Re: C arrays mk 2
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
	<u1xteiajb.fsf@yahoo.co.uk> <bmk6ru$lsj$1@sea.gmane.org>
	<uwub6gpo1.fsf@yahoo.co.uk> <bmkg3r$tpt$1@sea.gmane.org>
Message-ID: <uoewigmnf.fsf@yahoo.co.uk>

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

> Raoul Gough wrote:
>> David Abrahams <dave at boost-consulting.com> writes:
>>
>>>Raoul Gough wrote:
>> [snip]
>>
>>>>I suppose it depends how rich an interface he wants on the Python
>>>>side. The two methods you named are sufficient for a lot of cases
>>>>(almost everything, in fact), but if he wants slice support or
>>>>__setitem__, it might still pay off to use the container suite.
>>>
>>>Sure.  But his example just creates an iterator (the extremely hard
>>>way), and __len__ + __getitem__ already gets you an iterator and more.
>> That's right - it's neat how many Python expressions can work with
>> just those two methods (in fact, I think __len__ is not even necessary
>> for much of it, since IndexError works as well as StopIteration).
>> However, I think his code actually does enlist some extra
>> container_suite support via the iterator_pair container emulation,
>> which goes one or two steps further. The macros obscure it somewhat,
>> but I think it basically does this:
>> typedef indexing::iterator_pair<memberType *> IterPair;
>> class_<IterPair>("Name", init<...>)
>>   .def (indexing::container_suite<IterPair>());
>
> Ah, I didn't realize he was using the indexing suite.  Sorry!
> I think I have some arguments with the naming of iterator_pair, which
> is part of what threw me off.
> It really represents an "immutable sequence".  "iterator pair" is more
> like an implementation detail.

Welll, I don't know - it's not just *any* immutable sequence, because
it only works with iterators. I've actually wondered about the name
myself, but not for the reason you mentioned: it doesn't work with
every pair of iterator instances, because they have to specify a valid
range, like the requirements for std::distance ("last must be
reachable from first"). i.e. it's not the same as std::pair<iterator,
iterator>, because there are further requirements on the values used.

Also, I'm also not sure that it could really be called immutable,
since you can replace elements (just not insert or delete them).
Anyway, can you suggest an alternative name?

>
> As a side note, please use boost::detail::iterator_traits instead of
> std::iterator_traits, for portability reasons.

OK - will fix these.

>
> As another side note, endline layout
>
>    template<typename Iterator>
>    iterator_pair<Iterator>::iterator_pair (iterator_param begin
>                                            , iterator_param end)
>
> is banned in Boost.Python.  Should be, e.g.:
>
>    template<typename Iterator>
>    iterator_pair<Iterator>::iterator_pair (
>        iterator_param begin, iterator_param end)
>
> ;->

?What do you do when the parameter list itself gets too long for a
single line? I usually use the vertical layout as soon as I have to
split the line the first time.

>
> I'll stop picking nits with your excellent work now.

Well, a uniform coding style is always a good thing. I'm just
wondering how much effort this will involve, especially considering
that Emacs auto-indent won't co-operate with what you use (or have you
customized this somehow?). BTW, why do you dislike the vertical style?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Thu Oct 16 01:11:50 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 19:11:50 -0400
Subject: [C++-sig] Re: boost::python::object and stl::map warning
In-Reply-To: <3F8DBD38.3000909@shockfamily.net>
References: <3F8DBD38.3000909@shockfamily.net>
Message-ID: <bmkk7q$509$1@sea.gmane.org>

Cedric Shock wrote:

> To whomever can provide some assistance:

> It compiles with g++ 3.2.2, and will work as expected in python. 
> However, for each of those offending statements it produces a warning like:
> 
> (data.count(oi)):
> warning: cannot pass objects of non-POD type `struct 
> std::_Rb_tree_iterator<std::pair<const boost::python::api::object, 
> boost::python::api::object>, const std::pair<const 
> boost::python::api::object, boost::python::api::object>&, const 
> std::pair<const boost::python::api::object, 
> boost::python::api::object>*>' through `...'; call will abort at runtime
> 
> (data[oi].ptr()):
> warning: cannot pass objects of non-POD type `struct 
> std::_Rb_tree_iterator<std::pair<const boost::python::api::object, 
> boost::python::api::object>, std::pair<const boost::python::api::object, 
> boost::python::api::object>&, std::pair<const 
> boost::python::api::object, boost::python::api::object>*>' through 
> `...'; call will abort at runtime
> 
> 
> This warning usually indicates that something bad has been done with a 
> variable argument function like passing a non-POD type to printf. But it 
> should not be an issue here. std::map is routinely used to deal with 
> non-POD objects, why can't it handle the boost::python::object?

Short answer:  it can.

Long answer: The warning is benign, since the function "invocation" is 
inside sizeof(...) and never actually happens.  The compiler should be 
smarter about this.

Even longer answer:  Turn off the warning; it'll cause problems with 
other parts of Boost.

Still longer answer:  Ok, ok.  Try the enclosed patch ;->

HTH,
Dave
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: object_operators.patch
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/f755ac67/attachment.txt>

From s_sourceforge at nedprod.com  Thu Oct 16 00:40:03 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Oct 2003 23:40:03 +0100
Subject: [C++-sig] Re: Indexing_suite when container is newed
In-Reply-To: <u8ynmib1m.fsf@yahoo.co.uk>
Message-ID: <3F8DDAD3.13729.2584BD3B@localhost>

On 15 Oct 2003 at 19:57, Raoul Gough wrote:

> I suppose you have some kind of class_<> for FXGLObject, but how does
> Python deal with the FXGLObject * that the suite returns? I mean,
> iterator_pair does only one level of indirection, so what happens to
> the plain pointer before it gets handed back to Python?

I had assumed BPL was converting it for me into its python wrapper as 
it normally does?

> > However it would appear that setting a policy at the container_suite
> > level sets it for the iterator_pair which isn't what I want. Anyway
> > besides the list is malloced and not newed, though in fact I've
> > replaced new and delete with my own versions which do call malloc.
> 
> Not sure what you mean here - iterator_pair doesn't have any
> policies. The container suite applies the policies to the results of
> (for instance) iterator_pair<...>::operator[] which returns an
> FXGLObject * in this case, AFAICS.

Precisely what I had concluded though I didn't say so. Your docs make 
mention of three types of policy setting but don't make it clear how 
to set each individually or even if you can.

> Sounds about right to me. But you would currently have the same
> problem in C++, anyway, so I would first suggest coming up with a
> class to manage the array in C++. You could then expose *that* class
> to Python, and give it a function that returns an iterator_pair via
> the return_internal_reference return policy. You would then have
> something like:
> [snip]
> The return_internal_reference policy links the lifetime of the two
> Python objects together, so in the latter case, when array disappears
> (e.g. if you "del" it) it also causes the object returned from
> getArray() to go.

Outstanding idea. I've just got back from a restaurant so I haven't 
been working on it this evening. But this is definitely the quickest 
fix for the last single remaining problem. And then, after two months 
of this, I'm finally done and can move on!

> > Thoughts?
> 
> Well, if I was in danger of forgetting how much easier programming
> with std::vector and boost::shared_ptr is compared to malloc and
> arrays in C, you've just reminding me :-)

Strangely enough, I never had problems with malloc like others did. 
My last C project was 30,000 lines long and only had six memory leaks 
but I'm guessing this mostly results from me being originally an 
assembler programmer. All this fancy C++ stuff is quite new for me - 
literally I only really properly began about a year and a half ago 
but thanks to Marshall Cline helping me I think I got fairly 
competent pretty quickly. I still have sooo much to learn though.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/f96f4f91/attachment.pgp>

From s_sourceforge at nedprod.com  Thu Oct 16 00:28:04 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Oct 2003 23:28:04 +0100
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <bmjvoo$7bi$1@sea.gmane.org>
References: <3F8CB32C.2681.2101D79B@localhost>
Message-ID: <3F8DD804.29877.2579C32C@localhost>

On 15 Oct 2003 at 13:22, David Abrahams wrote:

> This appears to me to be more complicated and less reliable than
> neccessary.  Why not just give your Python MyList class __len__ and
> __getitem__ functions?

Aesthetically that isn't very pythonesque. Call me a romantic, but I 
believe in beautiful software!

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/c469ed64/attachment.pgp>

From dave at boost-consulting.com  Thu Oct 16 01:18:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 19:18:52 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <uoewigmnf.fsf@yahoo.co.uk>
References: <3F8CB32C.2681.2101D79B@localhost>
	<bmjvoo$7bi$1@sea.gmane.org>	<u1xteiajb.fsf@yahoo.co.uk>
	<bmk6ru$lsj$1@sea.gmane.org>	<uwub6gpo1.fsf@yahoo.co.uk>
	<bmkg3r$tpt$1@sea.gmane.org> <uoewigmnf.fsf@yahoo.co.uk>
Message-ID: <bmkkl0$5i3$1@sea.gmane.org>

Raoul Gough wrote:

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

>>I think I have some arguments with the naming of iterator_pair, which
>>is part of what threw me off.
>>It really represents an "immutable sequence".  "iterator pair" is more
>>like an implementation detail.
> 
> 
> Welll, I don't know - it's not just *any* immutable sequence, because
> it only works with iterators. 

Go look up the Sequence requirements in the standard.  A Sequence is 
defined by two iterators... uh, whoops: I should have said "Container". 
  "Sequence" adds mutability.

"works with iterators" is irrelevant to what it *is* in essence, since 
it says nothing about how it's used once it's initialized.

> I've actually wondered about the name
> myself, but not for the reason you mentioned: it doesn't work with
> every pair of iterator instances, because they have to specify a valid
> range, like the requirements for std::distance ("last must be
> reachable from first"). i.e. it's not the same as std::pair<iterator,
> iterator>, because there are further requirements on the values used.

Right, and because it's not, fundamentally, a pair of iterators.  It's a 
facade for the Container concept.

> Also, I'm also not sure that it could really be called immutable,
> since you can replace elements (just not insert or delete them).
> Anyway, can you suggest an alternative name?

container ;->

>>As a side note, please use boost::detail::iterator_traits instead of
>>std::iterator_traits, for portability reasons.
> 
> 
> OK - will fix these.
> 
> 
>>As another side note, endline layout
>>
>>   template<typename Iterator>
>>   iterator_pair<Iterator>::iterator_pair (iterator_param begin
>>                                           , iterator_param end)
>>
>>is banned in Boost.Python.  Should be, e.g.:
>>
>>   template<typename Iterator>
>>   iterator_pair<Iterator>::iterator_pair (
>>       iterator_param begin, iterator_param end)
>>
>>;->
> 
> 
> ?What do you do when the parameter list itself gets too long for a
> single line? I usually use the vertical layout as soon as I have to
> split the line the first time.

   template<typename Iterator>
   iterator_pair<Iterator>::iterator_pair (
       iterator_param begin
     , iterator_param end)

Just avoid endline layout; all other line breaks are fine.

>>I'll stop picking nits with your excellent work now.
> 
> 
> Well, a uniform coding style is always a good thing. I'm just
> wondering how much effort this will involve, especially considering
> that Emacs auto-indent won't co-operate with what you use (or have you
> customized this somehow?). 

Yes.  I have enclosed my .emacs; you'll need the latest cc-mode (like 
from CVS).

> BTW, why do you dislike the vertical style?

I have no problem with vertical style, but you can google for endline 
layout to read about the associated evils.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: .emacs
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/2fdfcc36/attachment.txt>

From s_sourceforge at nedprod.com  Thu Oct 16 00:50:21 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Oct 2003 23:50:21 +0100
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <bmk6ru$lsj$1@sea.gmane.org>
References: <u1xteiajb.fsf@yahoo.co.uk>
Message-ID: <3F8DDD3D.12847.258E2CF1@localhost>

On 15 Oct 2003 at 15:23, David Abrahams wrote:

>  > I
> > don't know - all of that C-style array stuff looks like doing things
> > the hard way to me.
> 
> At least he's having fun ;-)

And learning stuff too. I think my next stage will be typelist 
support, then functors, then finally the IPC messaging classes. I 
won't be using boost because (a) it's overkill and (b) I could do 
with learning this stuff myself and like typing in BASIC programs 
from magazine listings during the 80's, DIY is the right way.

Anyway, apart from a few small bits to tidy up in pyste which I'll 
take up with Bruno, you won't be seeing too much more of me in here 
from today onwards (I hope anyway). I'll still be around, just off 
pestering other groups and hopefully answering queries in my own 
group.

I can't thank both of you enough for your assistence. I know you guys 
get dozens of newbies wandering in here every month and it can get 
annoying, but you've really come through for me here, and I 
appreciate it.

Just FYI, the project you've advanced is at 
http://www.nedprod.com/TnFOX/. I am confident that when it's finished 
it will be *the* non-commercial GUI abstraction toolkit, perhaps even 
giving WxWindows a run for its money :)

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031015/617544ff/attachment.pgp>

From dave at boost-consulting.com  Thu Oct 16 03:05:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Oct 2003 21:05:48 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <3F8DDD3D.12847.258E2CF1@localhost>
References: <u1xteiajb.fsf@yahoo.co.uk> <3F8DDD3D.12847.258E2CF1@localhost>
Message-ID: <bmkqti$dt7$1@sea.gmane.org>

Niall Douglas wrote:

> On 15 Oct 2003 at 15:23, David Abrahams wrote:
> 
> 
>> > I
>>
>>>don't know - all of that C-style array stuff looks like doing things
>>>the hard way to me.
>>
>>At least he's having fun ;-)
> 
> 
> And learning stuff too. I think my next stage will be typelist 
> support, then functors, then finally the IPC messaging classes. I 
> won't be using boost because (a) it's overkill and (b) I could do 
> with learning this stuff myself and like typing in BASIC programs 
> from magazine listings during the 80's, DIY is the right way.

Reuse is "the right way".  That's why we do this Boost stuff! ;->
It's very disappointing for us library writers to hear anyone's going to 
go and repeat our work.  Most especially writing typelists yourself 
instead of using MPL you will be having way less fun and doing way more 
hair-pulling; your code will be uglier, harder to maintain and debug, 
and may take longer to compile.  Compile-time C++'s "assembly language" 
(raw templates) is much less well-thought-out than a high-level language 
like MPL.

What do you mean by "it's overkill", anyway?

> Anyway, apart from a few small bits to tidy up in pyste which I'll 
> take up with Bruno, you won't be seeing too much more of me in here 
> from today onwards (I hope anyway). I'll still be around, just off 
> pestering other groups and hopefully answering queries in my own 
> group.
> 
> I can't thank both of you enough for your assistence. I know you guys 
> get dozens of newbies wandering in here every month and it can get 
> annoying, but you've really come through for me here, and I 
> appreciate it.

I'm glad we were able to help, and especially glad that Raoul stepped up 
to answer your questions since I've been so busy.

> Just FYI, the project you've advanced is at 
> http://www.nedprod.com/TnFOX/. I am confident that when it's finished 
> it will be *the* non-commercial GUI abstraction toolkit, perhaps even 
> giving WxWindows a run for its money :)

Wow, that's an awesome task.

I hate having to give this message to various open-source projects over 
and over and over again, but I can't help myself: you have a huge 
undertaking before you.  Reusing the Boost components instead of 
reinventing them yourself will save you gobs of time, bugs, and hassles. 
  You won't have to develop, debug, and maintain the components 
yourself, and, and will be able to get on with the real job of building 
software.

Just think what it'll be like when you hear someone's building the next 
great email/newsreader or web browser or whatever, and they tell you 
they're not using TnFOX because it's overkill or they want to learn how 
to do it themselves, or whatever.  You will have been through the 
trenches with the problems they'll have to solve...  The difference in 
your perspective from theirs is the same as the difference between yours 
and mine right now.

Anyway, best of luck with TnFOX!

-Dave





From RaoulGough at yahoo.co.uk  Thu Oct 16 17:45:25 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 16 Oct 2003 16:45:25 +0100
Subject: [C++-sig] Re: Indexing_suite when container is newed
References: <u8ynmib1m.fsf@yahoo.co.uk> <3F8DDAD3.13729.2584BD3B@localhost>
Message-ID: <uk775gp9m.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 15 Oct 2003 at 19:57, Raoul Gough wrote:
[snip]
>> Well, if I was in danger of forgetting how much easier programming
>> with std::vector and boost::shared_ptr is compared to malloc and
>> arrays in C, you've just reminding me :-)
>
> Strangely enough, I never had problems with malloc like others did. 
> My last C project was 30,000 lines long and only had six memory leaks 
> but I'm guessing this mostly results from me being originally an 
> assembler programmer.

It's not such a problem when you manage to find the leaks early
enough, but systematically avoiding them would be even better. I
worked on a mature project once that had been in widespread production
use for about five years at the time. One of the support requests I
dealt with was for a memory leak, which nobody had ever noticed
before. The particular customer sent in the request for a fix because
their devices kept running out of memory and requiring rebooting every
week or so. Turns out the scripts they were running as part of backup
readiness testing were triggering the leak. A few years later and they
probably would have scrapped the devices because of that one leak,
since support was expiring. My point? Just that memory leaks reduce
the quality of a software system, and don't always appear at a
convenient time :-)

> All this fancy C++ stuff is quite new for me - literally I only
> really properly began about a year and a half ago but thanks to
> Marshall Cline helping me I think I got fairly competent pretty
> quickly. I still have sooo much to learn though.

Sounds like nice work if you can get it.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Thu Oct 16 18:11:52 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 16 Oct 2003 17:11:52 +0100
Subject: [C++-sig] Re: C arrays mk 2
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
	<u1xteiajb.fsf@yahoo.co.uk> <bmk6ru$lsj$1@sea.gmane.org>
	<uwub6gpo1.fsf@yahoo.co.uk> <bmkg3r$tpt$1@sea.gmane.org>
	<uoewigmnf.fsf@yahoo.co.uk> <bmkkl0$5i3$1@sea.gmane.org>
Message-ID: <ufzhtgo1j.fsf@yahoo.co.uk>

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

> Raoul Gough wrote:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>
>>>I think I have some arguments with the naming of iterator_pair, which
>>>is part of what threw me off.
>>>It really represents an "immutable sequence".  "iterator pair" is more
>>>like an implementation detail.
>> Welll, I don't know - it's not just *any* immutable sequence, because
>> it only works with iterators.
>
> Go look up the Sequence requirements in the standard.  A Sequence is
> defined by two iterators... uh, whoops: I should have said
> "Container". "Sequence" adds mutability.
>
> "works with iterators" is irrelevant to what it *is* in essence, since
> it says nothing about how it's used once it's initialized.

I think you're stretching a point here. The iterator_pair template
does little more than store two iterators and define some types. In
fact, the three member functions other than begin() and end() are only
provided for convenience, since they simply use std::advance or
std::distance. So from that point of view, it really is just a pair of
iterators. Importantly, it doesn't manage storage, in contrast to the
all of the standard containers that also accept a pair of iterators
for construction.

>
>> I've actually wondered about the name
>> myself, but not for the reason you mentioned: it doesn't work with
>> every pair of iterator instances, because they have to specify a valid
>> range, like the requirements for std::distance ("last must be
>> reachable from first"). i.e. it's not the same as std::pair<iterator,
>> iterator>, because there are further requirements on the values used.
>
> Right, and because it's not, fundamentally, a pair of iterators.  It's
> a facade for the Container concept.

OK, yes, it provides *part* of the container interface, since it has
the typedefs and begin() and end() and some syntactic niceities like
operator[]. However, there is an important distinction in terms of
storage management as I already mentioned. From the way you described
it, calling something std::list would be wrong, because that's an
implementation detail.

Anyway, paragraph one of the container requirements says:

  "Containers are objects that store other objects. They control
  allocation and deallocation of these objects through constructors,
  destructors, insert and erase operations."

There is also no way that ~iterator_pair is going to "apply the
destructor to every element", as is required of containers.

>
>> Also, I'm also not sure that it could really be called immutable,
>> since you can replace elements (just not insert or delete them).
>> Anyway, can you suggest an alternative name?
>
> container ;->
>
>>>As a side note, please use boost::detail::iterator_traits instead of
>>>std::iterator_traits, for portability reasons.
>> OK - will fix these.
>>
>>>As another side note, endline layout
>>>
>>>   template<typename Iterator>
>>>   iterator_pair<Iterator>::iterator_pair (iterator_param begin
>>>                                           , iterator_param end)
>>>
>>>is banned in Boost.Python.  Should be, e.g.:
>>>
>>>   template<typename Iterator>
>>>   iterator_pair<Iterator>::iterator_pair (
>>>       iterator_param begin, iterator_param end)
>>>
>>>;->
>> ?What do you do when the parameter list itself gets too long for a
>> single line? I usually use the vertical layout as soon as I have to
>> split the line the first time.
>
>    template<typename Iterator>
>    iterator_pair<Iterator>::iterator_pair (
>        iterator_param begin
>      , iterator_param end)
>
> Just avoid endline layout; all other line breaks are fine.
>
>>>I'll stop picking nits with your excellent work now.
>> Well, a uniform coding style is always a good thing. I'm just
>> wondering how much effort this will involve, especially considering
>> that Emacs auto-indent won't co-operate with what you use (or have you
>> customized this somehow?).
>
> Yes.  I have enclosed my .emacs; you'll need the latest cc-mode (like
> from CVS).

Far out. Does this also handle indentation to "<" as a template
argument list delimiter?

>
>> BTW, why do you dislike the vertical style?
>
> I have no problem with vertical style, but you can google for endline
> layout to read about the associated evils.

Well, I did have a look with Google but didn't find anything
particularly conclusive. I understood that "endline layout" means
aligning a column of equally-indented code near the right-hand margin,
which creates problems when the textual components change length
(e.g. renaming an identifier). Is that about right? I initially
thought you wanted to avoid columnar layouts entirely.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From sf.lists at web.de  Thu Oct 16 19:36:52 2003
From: sf.lists at web.de (Stefan Fleiter)
Date: Thu, 16 Oct 2003 19:36:52 +0200
Subject: [C++-sig] can't compile code with cvs version
Message-ID: <3F8ED734.7080105@web.de>

Hi,

the following (stripped down) code compiles perfectly with
boost_python 1.30, but not with the current cvs-version:

#include <boost/python.hpp>
#include <iostream>
#include <map>

namespace py = boost::python;

void test_func(py::list &)
{
     std::cout << "called test_func." << std::endl;
     return;
}

std::map<int, void(*)(py::list &) >cpp2Python;

BOOST_PYTHON_MODULE(foo_ext)
{
     py::list test_list;
     cpp2Python[0] = test_func;
     void (*fp)(py::list&) = cpp2Python[0];
     (*fp)(test_list);
}


The error messages of
g++ -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib 
--enable-languages=c,c++,f77,objc,java,ada --enable-libgcj 
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
--with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2 (SuSE Linux)

are

/usr/include/g++/bits/stl_map.h: In instantiation of 
`boost::python::api::is_object_operators<std::_Rb_tree_iterator<std::pair<const 
int, void (*)(boost::python::list&)>, std::pair<const int, void 
(*)(boost::python::list&)>&, std::pair<const int, void 
(*)(boost::python::list&)>*>, std::_Rb_tree_iterator<std::pair<const 
int, void (*)(boost::python::list&)>, std::pair<const int, void 
(*)(boost::python::list&)>&, std::pair<const int, void 
(*)(boost::python::list&)>*> >':
/usr/include/g++/bits/stl_map.h:224:   instantiated from 
`boost::iterators::enable_if<boost::python::api::is_object_operators<std::_Rb_tree_iterator<std::pair<const 
int, void (*)(boost::python::list&)>, std::pair<const int, void 
(*)(boost::python::list&)>&, std::pair<const int, void 
(*)(boost::python::list&)>*>, std::_Rb_tree_iterator<std::pair<const 
int, void (*)(boost::python::list&)>, std::pair<const int, void 
(*)(boost::python::list&)>&, std::pair<const int, void 
(*)(boost::python::list&)>*> >, bool>'
/usr/include/g++/bits/stl_map.h:224:   instantiated from 
`boost::python::api::enable_binary<std::_Rb_tree_iterator<std::pair<const 
int, void (*)(boost::python::list&)>, std::pair<const int, void 
(*)(boost::python::list&)>&, std::pair<const int, void 
(*)(boost::python::list&)>*>, std::_Rb_tree_iterator<std::pair<const 
int, void (*)(boost::python::list&)>, std::pair<const int, void 
(*)(boost::python::list&)>&, std::pair<const int, void 
(*)(boost::python::list&)>*>, bool>'
/usr/include/g++/bits/stl_map.h:224:   instantiated from `_Tp& 
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with 
_Key = int, _Tp = void (*)(boost::python::list&), _Compare = 
std::less<int>, _Alloc = std::allocator<std::pair<const int, void 
(*)(boost::python::list&)> >]'
foo_ext.cpp:18:   instantiated from here
/usr/include/g++/bits/stl_map.h:224: cannot pass objects of non-POD type `
    struct std::_Rb_tree_iterator<std::pair<const int, void
    (*)(boost::python::list&)>, std::pair<const int, void
    (*)(boost::python::list&)>&, std::pair<const int, void
    (*)(boost::python::list&)>*>' through `...'

These are printed twice.

Thanks for any help in advance!

Greets,
Stefan




From llywelyn.geo at yahoo.com  Thu Oct 16 19:37:48 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Thu, 16 Oct 2003 10:37:48 -0700 (PDT)
Subject: [C++-sig] Re: Sharing Global Singleton instances across
	boost.python extensions (windows & unix)
In-Reply-To: <3F878E8D.293.CEACC38@localhost>
Message-ID: <20031016173748.73884.qmail@web41505.mail.yahoo.com>

Hmmmm... thanks for the info and suggestions. I'll try some of the things you've suggested. 

Thanks again. 

Joel
--- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10 Oct 2003 at 22:31, David Abrahams wrote:
> 
> > > Thing is, if you're porting to and only to very recent versions of
> > > Linux there are very few non-obvious quirks nowadays.
> > 
> > Obviously you haven't been dealing with the same problems I've been
> > having in Boost.Python.  There are definitely some very subtle things
> > going on with weak symbols and templates; see
> > http://www.boost.org/libs/python/doc/v2/May2002.html#shared
> 
> I'd forgotten some of those which I too have had run-ins with. Why oh 
> why can't they make all symbols hidden by default and only public 
> with a modifier syntaxically identical to __declspec(dllexport) so we 
> can reuse our Win32 idioms?
> 
> It would require a small amount of complexity within G++ to do this, 
> but the current method they have of you selecting each method 
> individually is useless for Win32 compatibility :(
> 
> Cheers,
> Niall
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2
> 
> iQA/AwUBP4eAfcEcvDLFGKbPEQKROQCg+IfzxPwEThggM3mLmJgZAv3nYRsAn25r
> qlciEZFNYPILkJRbzo+kbBYP
> =gFef
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


=====


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From RaoulGough at yahoo.co.uk  Thu Oct 16 20:17:43 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 16 Oct 2003 19:17:43 +0100
Subject: [C++-sig] Re: can't compile code with cvs version
References: <3F8ED734.7080105@web.de>
Message-ID: <u8ynlgi7s.fsf@yahoo.co.uk>

Stefan Fleiter <sf.lists at web.de> writes:

[snip]
> /usr/include/g++/bits/stl_map.h:224: cannot pass objects of non-POD type `
>     struct std::_Rb_tree_iterator<std::pair<const int, void
>     (*)(boost::python::list&)>, std::pair<const int, void
>     (*)(boost::python::list&)>&, std::pair<const int, void
>     (*)(boost::python::list&)>*>' through `...'
>
> These are printed twice.
>
> Thanks for any help in advance!

Suggest you see the immediately preceeding thread
"boost::python::object and stl::map warning" because it looks like the
identical problem with the compiler.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From s_sourceforge at nedprod.com  Thu Oct 16 21:34:07 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 16 Oct 2003 20:34:07 +0100
Subject: [C++-sig] Re: Indexing_suite when container is newed
In-Reply-To: <uk775gp9m.fsf@yahoo.co.uk>
Message-ID: <3F8F00BF.4650.2A00DD75@localhost>

On 16 Oct 2003 at 16:45, Raoul Gough wrote:

> My point? Just that memory leaks reduce
> the quality of a software system, and don't always appear at a
> convenient time :-)

I completely agree. Just because I can write code which doesn't leak 
memory doesn't mean someone else altering my code won't introduce 
half a dozen memory leaks each go. And one must be very cautious of 
that. I once designed a structured exception handling system for a C 
project which ran like C++ but you had to be very very dilligent in 
wrapping each C function with the necessary runtime code. As I later 
found out, other programmers in the team just didn't care when 
writing new code - and thus errors vanished as they do when C++ goes 
through C code.

> > All this fancy C++ stuff is quite new for me - literally I only
> > really properly began about a year and a half ago but thanks to
> > Marshall Cline helping me I think I got fairly competent pretty
> > quickly. I still have sooo much to learn though.
> 
> Sounds like nice work if you can get it.

Hardly. I've been unemployed for eighteen months now. Been trying to 
start a company, but there's zero interest in software companies 
right now. If nothing happens by next summer, I'm going to read for a 
second degree - maybe philosophy.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031016/e776c204/attachment.pgp>

From s_sourceforge at nedprod.com  Thu Oct 16 21:26:35 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 16 Oct 2003 20:26:35 +0100
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <bmkqti$dt7$1@sea.gmane.org>
References: <3F8DDD3D.12847.258E2CF1@localhost>
Message-ID: <3F8EFEFB.26159.29F9F804@localhost>

On 15 Oct 2003 at 21:05, David Abrahams wrote:

> > And learning stuff too. I think my next stage will be typelist
> > support, then functors, then finally the IPC messaging classes. I
> > won't be using boost because (a) it's overkill and (b) I could do
> > with learning this stuff myself and like typing in BASIC programs
> > from magazine listings during the 80's, DIY is the right way.
> 
> Reuse is "the right way".  That's why we do this Boost stuff! ;-> It's
> very disappointing for us library writers to hear anyone's going to go
> and repeat our work.  Most especially writing typelists yourself
> instead of using MPL you will be having way less fun and doing way
> more hair-pulling; your code will be uglier, harder to maintain and
> debug, and may take longer to compile.  Compile-time C++'s "assembly
> language" (raw templates) is much less well-thought-out than a
> high-level language like MPL.

I completely agree and my documentation makes no short reference of 
Boost. BTW I wrote typelists last night and they appear to be running 
fine today with the type traits class I wrote. I do have "Modern C++ 
Design" to help me but I've significantly deviated from its design. 
And oh - I really wish you could template typedefs (I know it's 
coming, just wish it were here already).

> What do you mean by "it's overkill", anyway?

My typelists are very simple. You can make them, append, search and 
remove. Nothing more. MPL is far more fully featured and if I 
understand the docs correctly, can use my typelists.

My entire generic programming library amounts to a few hundred lines. 
It's all I need - if I were designing a GUI toolkit from scratch I 
almost certainly would base it on boost but since I'm forking FOX, my 
extensions are very much limited in scope - thus boost's extensive 
facilities are overkill for what is ultimately very trivial usage. My 
extensions are 99.8% normal C++ with 0.2% using metaprogramming 
facilities, and that's very unlikely to change.

You'll probably point to the python bindings using BPL and therefore 
have boost. However, some users will not want the python bindings so 
I'm not wanting to lumber them with having to download boost just to 
make a tiny fraction of code work. My main personal need of typelists 
actually is to ease replicating a set of almost identical classes 
which you can do by copy & paste if your compiler doesn't support 
typelists - though I'm seriously thinking of a self-optimising 
generic copy which knows when it can use memcpy or even, possibly, 
some sort of self-optimising linear search.

> > Just FYI, the project you've advanced is at 
> > http://www.nedprod.com/TnFOX/. I am confident that when it's
> > finished it will be *the* non-commercial GUI abstraction toolkit,
> > perhaps even giving WxWindows a run for its money :)
> 
> Wow, that's an awesome task.

FOX already does GUI stuff much better than WxWindows (in my opinion) 
- it works identically on all platforms and is very, very quick (no 
flicker). TnFOX extends FOX with Qt-similar classes so it offers 
everything Qt has except for the rich text widget and the XML stuff 
(however, python provides the latter). However TnFOX is completely 
exception safe & thread-aware which Qt most certainly is not (and 
neither is WxWindows AFAIK).

> I hate having to give this message to various open-source projects
> over and over and over again, but I can't help myself: you have a huge
> undertaking before you.  Reusing the Boost components instead of
> reinventing them yourself will save you gobs of time, bugs, and
> hassles. 
>   You won't have to develop, debug, and maintain the components 
> yourself, and, and will be able to get on with the real job of
> building software.

I absolutely agree, and my docs say just that. TnFOX's generic tools 
BTW need partial template specialisation and if you don't have that, 
you have to insert a stubs redirecting to boost (currently unwritten, 
but it's been designed to work that way).

> Just think what it'll be like when you hear someone's building the
> next great email/newsreader or web browser or whatever, and they tell
> you they're not using TnFOX because it's overkill or they want to
> learn how to do it themselves, or whatever.  You will have been
> through the trenches with the problems they'll have to solve...  The
> difference in your perspective from theirs is the same as the
> difference between yours and mine right now.

It's not for me to know what my users will want to do with my 
library. I've always felt that good library design should offer as 
many options to the end user as possible.

If the user has a conformant compiler, what I've supplied is fine for 
simple tasks. If they want more comprehensive facilities or have a 
non-conformant compiler, there are hooks for Boost.

I'm guessing that's probably not quite what you'd prefer to hear. But 
please do understand that while I may not be an expert in C++, I do 
consider myself an expert in library design and I know what I like to 
see in a third-party library. It is this vision of what I would like 
that ultimately drives design choices (and I'm going far, far further 
with this - Tn which TnFOX is for redesigns the GUI, file system, UI, 
code structure etc. etc. etc ...)

Cheers,
Niall





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031016/472b6f64/attachment.pgp>

From dave at boost-consulting.com  Thu Oct 16 22:51:10 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Oct 2003 16:51:10 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <ufzhtgo1j.fsf@yahoo.co.uk>
References: <3F8CB32C.2681.2101D79B@localhost>
	<bmjvoo$7bi$1@sea.gmane.org>	<u1xteiajb.fsf@yahoo.co.uk>
	<bmk6ru$lsj$1@sea.gmane.org>	<uwub6gpo1.fsf@yahoo.co.uk>
	<bmkg3r$tpt$1@sea.gmane.org>	<uoewigmnf.fsf@yahoo.co.uk>
	<bmkkl0$5i3$1@sea.gmane.org> <ufzhtgo1j.fsf@yahoo.co.uk>
Message-ID: <bmn0c5$bvd$1@sea.gmane.org>

Raoul Gough wrote:

>>Go look up the Sequence requirements in the standard.  A Sequence is
>>defined by two iterators... uh, whoops: I should have said
>>"Container". "Sequence" adds mutability.
>>
>>"works with iterators" is irrelevant to what it *is* in essence, since
>>it says nothing about how it's used once it's initialized.
> 
> I think you're stretching a point here. 

OK, you're right.  Perhaps iterator_range_container_facade.

> The iterator_pair template
> does little more than store two iterators and define some types. In
> fact, the three member functions other than begin() and end() are only
> provided for convenience, since they simply use std::advance or
> std::distance. 

I try not to decide naming based on implementation details.  Is it 
really "just for convenience", or is it so that it satisfies the 
interface requirements of the container suite?

> So from that point of view, it really is just a pair of
> iterators. Importantly, it doesn't manage storage, in contrast to the
> all of the standard containers that also accept a pair of iterators
> for construction.

Can you find storage management as part of the Container concept in the 
standard?  OK, I see below that you can.

>>>I've actually wondered about the name
>>>myself, but not for the reason you mentioned: it doesn't work with
>>>every pair of iterator instances, because they have to specify a valid
>>>range, like the requirements for std::distance ("last must be
>>>reachable from first"). i.e. it's not the same as std::pair<iterator,
>>>iterator>, because there are further requirements on the values used.
>>
>>Right, and because it's not, fundamentally, a pair of iterators.  It's
>>a facade for the Container concept.
> 
> 
> OK, yes, it provides *part* of the container interface, since it has
> the typedefs and begin() and end() and some syntactic niceities like
> operator[]. However, there is an important distinction in terms of
> storage management as I already mentioned. From the way you described
> it, calling something std::list would be wrong, because that's an
> implementation detail.

No, it's not.  Its list-ness affects externally visible properties like 
complexity of insert, iterator invalidation, etc.  If you can build 
something with the same properties using a different data structure, by 
all means go ahead and call it "list".

> Anyway, paragraph one of the container requirements says:
> 
>   "Containers are objects that store other objects. They control
>   allocation and deallocation of these objects through constructors,
>   destructors, insert and erase operations."
> 
> There is also no way that ~iterator_pair is going to "apply the
> destructor to every element", as is required of containers.

OK, point taken.

>>>Also, I'm also not sure that it could really be called immutable,
>>>since you can replace elements (just not insert or delete them).
>>>Anyway, can you suggest an alternative name?
>>
>>container ;->

Well, I'm stumped for a name at the moment.  I think we need a new 
concept in the hierarchy, less-refined than Container.

>>>>As a side note, please use boost::detail::iterator_traits instead of
>>>>std::iterator_traits, for portability reasons.
>>>
>>>OK - will fix these.
>>>
>>>
>>>>As another side note, endline layout
>>>>
>>>>  template<typename Iterator>
>>>>  iterator_pair<Iterator>::iterator_pair (iterator_param begin
>>>>                                          , iterator_param end)
>>>>
>>>>is banned in Boost.Python.  Should be, e.g.:
>>>>
>>>>  template<typename Iterator>
>>>>  iterator_pair<Iterator>::iterator_pair (
>>>>      iterator_param begin, iterator_param end)
>>>>
>>>>;->
>>>
>>>?What do you do when the parameter list itself gets too long for a
>>>single line? I usually use the vertical layout as soon as I have to
>>>split the line the first time.
>>
>>   template<typename Iterator>
>>   iterator_pair<Iterator>::iterator_pair (
>>       iterator_param begin
>>     , iterator_param end)
>>
>>Just avoid endline layout; all other line breaks are fine.
>>
>>
>>>>I'll stop picking nits with your excellent work now.
>>>
>>>Well, a uniform coding style is always a good thing. I'm just
>>>wondering how much effort this will involve, especially considering
>>>that Emacs auto-indent won't co-operate with what you use (or have you
>>>customized this somehow?).
>>
>>Yes.  I have enclosed my .emacs; you'll need the latest cc-mode (like
>>from CVS).
> 
> 
> Far out. Does this also handle indentation to "<" as a template
> argument list delimiter?

Mostly.  I have found a few cases which need tweaking.  Every once in a 
while when I allow myself I improve it a little bit.
>>>BTW, why do you dislike the vertical style?
>>
>>I have no problem with vertical style, but you can google for endline
>>layout to read about the associated evils.
> 
> 
> Well, I did have a look with Google but didn't find anything
> particularly conclusive. I understood that "endline layout" means
	> aligning a column of equally-indented code near the right-hand margin,
> which creates problems when the textual components change length
> (e.g. renaming an identifier). Is that about right? 

Yes.

Endline layout is what happens when you have an unmatched open delimiter 
in the middle of the line:

     foo(bar

What happens is that you're then compelled to line things up under bar. 
  Not only does that make poor use of space, it means a whole lotta 
busywork indentation adjustment when someone changes the name of foo to 
"fu" or "foobarre".

This isn't one of those things that kills a project, but you need to 
choose some style and I prefer to choose one that has a nice rationale 
so I can stop thinking about whether I chose right ;->

 > I initially
> thought you wanted to avoid columnar layouts entirely.

No, you can see lots of examples of that in my code I'm sure.

-Dave





From sf.lists at web.de  Fri Oct 17 09:26:19 2003
From: sf.lists at web.de (Stefan Fleiter)
Date: Fri, 17 Oct 2003 09:26:19 +0200
Subject: [C++-sig] Re: can't compile code with cvs version
In-Reply-To: <u8ynlgi7s.fsf@yahoo.co.uk>
References: <3F8ED734.7080105@web.de> <u8ynlgi7s.fsf@yahoo.co.uk>
Message-ID: <3F8F999B.7080700@web.de>

> Suggest you see the immediately preceeding thread
> "boost::python::object and stl::map warning" because it looks like the
> identical problem with the compiler.

Oh, thanks!
I'll answer there.

Greets,
Stefan





From sf.lists at web.de  Fri Oct 17 09:30:21 2003
From: sf.lists at web.de (Stefan Fleiter)
Date: Fri, 17 Oct 2003 09:30:21 +0200
Subject: [C++-sig] Re: boost::python::object and stl::map warning
In-Reply-To: <bmkk7q$509$1@sea.gmane.org>
References: <3F8DBD38.3000909@shockfamily.net> <bmkk7q$509$1@sea.gmane.org>
Message-ID: <3F8F9A8D.3060605@web.de>



David Abrahams wrote:

>> warning: cannot pass objects of non-POD type `struct 
>> std::_Rb_tree_iterator<std::pair<const boost::python::api::object, 
>> boost::python::api::object>, const std::pair<const 
>> boost::python::api::object, boost::python::api::object>&, const 
>> std::pair<const boost::python::api::object, 
>> boost::python::api::object>*>' through `...'; call will abort at runtime

> Still longer answer:  Ok, ok.  Try the enclosed patch ;->

I get an *error* with the same message.
g++ -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib 
--enable-languages=c,c++,f77,objc,java,ada --enable-libgcj 
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
--with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2 (SuSE Linux)


Could you check this patch in the cvs, please?

Thanks a lot,
Stefan




From warkid at hotbox.ru  Fri Oct 17 10:51:13 2003
From: warkid at hotbox.ru (Kerim Borchaev)
Date: Fri, 17 Oct 2003 12:51:13 +0400
Subject: [C++-sig] Duplicate "ignore"(again...) and more. (Latest CVS,
	VC .NET 2003)
Message-ID: <43176117328.20031017125113@hotbox.ru>

Hello c++-sig,

As I get it VC7.1 also has this bug with anonymous namespace:

... : error LNK2005:
"struct swallow_assign::boost::detail::swallow_assign
boost::tuples::`anonymous namespace'::ignore"
... already defined in ...

I've read the archives and found that this bug has already been fixed
for Visual C version <=7 in tuple_basic_no_partial_spec.hpp:

    namespace {
#if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) || (defined(__DECCXX_VER) && __DECCXX_VER <= 60590031)
      static
#endif 
      detail::swallow_assign ignore;
    }

But VC7.1 is compiled with tuple_basic.hpp that has no such
a workaround.

And another one:
... : error LNK2005:
"class boost::arg<6> `anonymous namespace'::_6"
... already defined in ...

fixes if BOOST_MSVC <= 1300  replaced with BOOST_MSVC <= 1310 in
boost/bind/placeholders.hpp line 39

It would be nice if the patch was supplied by someone with knowledge
of how to do it:-)

Best regards,
 Kerim                          mailto:warkid at hotbox.ru




From nikolai.kirsebom at siemens.no  Fri Oct 17 11:13:29 2003
From: nikolai.kirsebom at siemens.no (Kirsebom Nikolai)
Date: Fri, 17 Oct 2003 11:13:29 +0200
Subject: [C++-sig] Reloading python code in BOOST environment
Message-ID: <5B5544F322E5D211850F00A0C91DEF3B05607A1A@osll007a.siemens.no>

I have a problem in trying to 'reload' python code in an BOOST invironment.
Given the two files below.  When I open Python (in command prompt) and do
the following:

>>> import Wrap
>>> Wrap.Main()
5 abc

        # CHANGE CONTENT OF FILE Subber.py to have i = 6
>>> Wrap.Main()
6 abc
>>>

If I try to do the same in my application (change the Subber.py content)
without restarting the whole application,
the changes are not seen.  Does this have something to do with BOOST
environment, or is it probably in the Subber.py
file (which in my application is a wxPython dialog presenting some
information from the application (exposed objects
using BOOST)).
It would be so nice to not have to restart the application when only
changing the Python-code.

Thanks for any help.
Nikolai


----- File Wrap.py ------------------------------------
def Main():
    import sys,copy
    bi=copy.copy(sys.modules.keys())
    try:
        import Subber
        Subber.Main()
    except:
        raise ImportError, "Failed to import"
    ai=copy.copy(sys.modules.keys())
    for k in ai:
        if not k in bi:
          del sys.modules[k]

----- File Subber.py ---------------------------------
i = 5
a = 'abc'

def Main():
    print i, a





From nlelong at mgdesign.org  Fri Oct 17 11:47:03 2003
From: nlelong at mgdesign.org (Nicolas LELONG)
Date: Fri, 17 Oct 2003 11:47:03 +0200
Subject: [C++-sig] problem with scope().attr(xxx)
Message-ID: <007e01c39493$9e8f7150$cd00a8c0@nico>

Hello,

I did not update the BPL code I use since August (nor did I really follow
the evolutions), and monday I decided to grab the lastest CVS (as of
monday). I'm now having problems with some 'global' variables declarations
that worked previously.

The minimal code I use is the following :

class Test
{
};
Test test;

BOOST_PYTHON_MODULE( aaa )
{
  class_<Test, boost::noncopyable>("Test", no_init);
  scope().attr("test") = boost::ref(test);
}

which worked OK previously - now the scope().attr line raises an error "No
to_python (by-value) converter found for C++ type" ! I've noticed that if if
I remove the boost::noncopyable from the 'class_' instanciation, it all
works ok.

I was wondering if this was a normal 'new' behaviour or not ? if it is
normal, how can I expose my global noncopyable instances to python ?

Thanks,
Nicolas.




From RaoulGough at yahoo.co.uk  Fri Oct 17 13:52:40 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 17 Oct 2003 12:52:40 +0100
Subject: [C++-sig] Re: C arrays mk 2
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
	<u1xteiajb.fsf@yahoo.co.uk> <bmk6ru$lsj$1@sea.gmane.org>
	<uwub6gpo1.fsf@yahoo.co.uk> <bmkg3r$tpt$1@sea.gmane.org>
	<uoewigmnf.fsf@yahoo.co.uk> <bmkkl0$5i3$1@sea.gmane.org>
	<ufzhtgo1j.fsf@yahoo.co.uk> <bmn0c5$bvd$1@sea.gmane.org>
Message-ID: <u4qy8gjxz.fsf@yahoo.co.uk>

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

> Raoul Gough wrote:
[snip]
>>>Right, and because it's not, fundamentally, a pair of iterators.  It's
>>>a facade for the Container concept.
>> OK, yes, it provides *part* of the container interface, since it has
>> the typedefs and begin() and end() and some syntactic niceities like
>> operator[]. However, there is an important distinction in terms of
>> storage management as I already mentioned. From the way you described
>> it, calling something std::list would be wrong, because that's an
>> implementation detail.
>
> No, it's not.  Its list-ness affects externally visible properties
> like complexity of insert, iterator invalidation, etc.  If you can
> build something with the same properties using a different data
> structure, by all means go ahead and call it "list".

OK, but apply the same reasoning to "iterator_pair" and there is no
problem with that name either. The iterator-pairness of my container
affects important semantic properties, mainly the fact that it
references external objects. e.g.

int a[10] = { 0 };
&iterator_pair<int *>(a, a + 10)[0] == a

This is an important property in terms of usefulness, but also in
terms of object lifetime management, unless you want to risk having
dangling references. For instance you need to consider what would
happen if you have an iterator_pair that references the contents of a
standard container - any operations on the container that invalidate
iterators within the range will affect the iterator_pair.

>
>> Anyway, paragraph one of the container requirements says:
>>   "Containers are objects that store other objects. They control
>>   allocation and deallocation of these objects through constructors,
>>   destructors, insert and erase operations."
>> There is also no way that ~iterator_pair is going to "apply the
>> destructor to every element", as is required of containers.
>
> OK, point taken.
>
>>>>Also, I'm also not sure that it could really be called immutable,
>>>>since you can replace elements (just not insert or delete them).
>>>>Anyway, can you suggest an alternative name?
>>>
>>>container ;->
>
> Well, I'm stumped for a name at the moment.  I think we need a new
> concept in the hierarchy, less-refined than Container.

How about "iterator_pair" :-)

Actually, I now think "iterator_range" might have been better, because
it hints that the two iterators must define a range. However, I can't
conceive of any sensible implementation with similar semantics that
*doesn't* store a pair of iterators, so I don't see anything to be
gained by trying to hide this behind a new abstraction.

[snip]
> Endline layout is what happens when you have an unmatched open
> delimiter in the middle of the line:
>
>      foo(bar
>
> What happens is that you're then compelled to line things up under
> bar. Not only does that make poor use of space, it means a whole lotta
> busywork indentation adjustment when someone changes the name of foo
> to "fu" or "foobarre".
>
> This isn't one of those things that kills a project, but you need to
> choose some style and I prefer to choose one that has a nice rationale
> so I can stop thinking about whether I chose right ;->
>
>  > I initially
>> thought you wanted to avoid columnar layouts entirely.
>
> No, you can see lots of examples of that in my code I'm sure.

OK, that makes a lot of sense to me know. I've added this to my (know
slowing shrinking) list.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Fri Oct 17 15:09:35 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Oct 2003 09:09:35 -0400
Subject: [C++-sig] Re: boost::python::object and stl::map warning
In-Reply-To: <3F8F9A8D.3060605@web.de>
References: <3F8DBD38.3000909@shockfamily.net> <bmkk7q$509$1@sea.gmane.org>
	<3F8F9A8D.3060605@web.de>
Message-ID: <bmopmk$tkc$2@sea.gmane.org>

Stefan Fleiter wrote:

> 
> 
> David Abrahams wrote:
> 
>>> warning: cannot pass objects of non-POD type `struct 
>>> std::_Rb_tree_iterator<std::pair<const boost::python::api::object, 
>>> boost::python::api::object>, const std::pair<const 
>>> boost::python::api::object, boost::python::api::object>&, const 
>>> std::pair<const boost::python::api::object, 
>>> boost::python::api::object>*>' through `...'; call will abort at runtime
> 
> 
>> Still longer answer:  Ok, ok.  Try the enclosed patch ;->
> 
> 
> I get an *error* with the same message.
> g++ -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
> Configured with: ../configure --enable-threads=posix --prefix=/usr 
> --with-local-prefix=/usr/local --infodir=/usr/share/info 
> --mandir=/usr/share/man --libdir=/usr/lib 
> --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj 
> --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
> --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
> Thread model: posix
> gcc version 3.2 (SuSE Linux)
> 
> 
> Could you check this patch in the cvs, please?

Already done a long time ago.





From dave at boost-consulting.com  Fri Oct 17 15:12:35 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Oct 2003 09:12:35 -0400
Subject: [C++-sig] Re: Reloading python code in BOOST environment
In-Reply-To: <5B5544F322E5D211850F00A0C91DEF3B05607A1A@osll007a.siemens.no>
References: <5B5544F322E5D211850F00A0C91DEF3B05607A1A@osll007a.siemens.no>
Message-ID: <bmops8$tkc$3@sea.gmane.org>

Python extension modules are never unloaded; this isn't a boost-specific 
thing.

HTH,
Dave

Kirsebom Nikolai wrote:

> I have a problem in trying to 'reload' python code in an BOOST invironment.
> Given the two files below.  When I open Python (in command prompt) and do
> the following:
> 
> 
>>>>import Wrap
>>>>Wrap.Main()
> 
> 5 abc
> 
>         # CHANGE CONTENT OF FILE Subber.py to have i = 6
> 
>>>>Wrap.Main()
> 
> 6 abc
> 
> 
> If I try to do the same in my application (change the Subber.py content)
> without restarting the whole application,
> the changes are not seen.  Does this have something to do with BOOST
> environment, or is it probably in the Subber.py
> file (which in my application is a wxPython dialog presenting some
> information from the application (exposed objects
> using BOOST)).
> It would be so nice to not have to restart the application when only
> changing the Python-code.
> 
> Thanks for any help.
> Nikolai
> 
> 
> ----- File Wrap.py ------------------------------------
> def Main():
>     import sys,copy
>     bi=copy.copy(sys.modules.keys())
>     try:
>         import Subber
>         Subber.Main()
>     except:
>         raise ImportError, "Failed to import"
>     ai=copy.copy(sys.modules.keys())
>     for k in ai:
>         if not k in bi:
>           del sys.modules[k]
> 
> ----- File Subber.py ---------------------------------
> i = 5
> a = 'abc'
> 
> def Main():
>     print i, a





From dave at boost-consulting.com  Fri Oct 17 15:25:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Oct 2003 09:25:21 -0400
Subject: [C++-sig] Re: C arrays mk 2
In-Reply-To: <u4qy8gjxz.fsf@yahoo.co.uk>
References: <3F8CB32C.2681.2101D79B@localhost>
	<bmjvoo$7bi$1@sea.gmane.org>	<u1xteiajb.fsf@yahoo.co.uk>
	<bmk6ru$lsj$1@sea.gmane.org>	<uwub6gpo1.fsf@yahoo.co.uk>
	<bmkg3r$tpt$1@sea.gmane.org>	<uoewigmnf.fsf@yahoo.co.uk>
	<bmkkl0$5i3$1@sea.gmane.org>	<ufzhtgo1j.fsf@yahoo.co.uk>
	<bmn0c5$bvd$1@sea.gmane.org> <u4qy8gjxz.fsf@yahoo.co.uk>
Message-ID: <bmoqk7$b7$1@sea.gmane.org>

Raoul Gough wrote:

> David Abrahams <dave at boost-consulting.com> writes:
> 
> 
>>Raoul Gough wrote:
> 
> [snip]
> 
>>>>Right, and because it's not, fundamentally, a pair of iterators.  It's
>>>>a facade for the Container concept.
>>>
>>>OK, yes, it provides *part* of the container interface, since it has
>>>the typedefs and begin() and end() and some syntactic niceities like
>>>operator[]. However, there is an important distinction in terms of
>>>storage management as I already mentioned. From the way you described
>>>it, calling something std::list would be wrong, because that's an
>>>implementation detail.
>>
>>No, it's not.  Its list-ness affects externally visible properties
>>like complexity of insert, iterator invalidation, etc.  If you can
>>build something with the same properties using a different data
>>structure, by all means go ahead and call it "list".
> 
> 
> OK, but apply the same reasoning to "iterator_pair" and there is no
> problem with that name either. The iterator-pairness of my container
> affects important semantic properties, mainly the fact that it
> references external objects. e.g.
> 
> int a[10] = { 0 };
> &iterator_pair<int *>(a, a + 10)[0] == a

Nothing about its interface exposes its pairness or the underlying 
iterators.  Can you ask it to increment its its first or last iterator? 
  At least with list the name tells you there's a sequence.

> This is an important property in terms of usefulness, but also in
> terms of object lifetime management, unless you want to risk having
> dangling references. For instance you need to consider what would
> happen if you have an iterator_pair that references the contents of a
> standard container - any operations on the container that invalidate
> iterators within the range will affect the iterator_pair.

There are too many other ways to realize that property.  Maybe "list" is 
badly named also; it's the only such example in the standard containers. 
  The tradition in container collections is to go with more-generic 
names like "bag".

But, enough of this; I don't believe in the name "iterator_pair" -- that 
should be reserved for something like pair<iterator,iterator> -- but if 
I can't convince you, so be it.

>>>Anyway, paragraph one of the container requirements says:
>>>  "Containers are objects that store other objects. They control
>>>  allocation and deallocation of these objects through constructors,
>>>  destructors, insert and erase operations."
>>>There is also no way that ~iterator_pair is going to "apply the
>>>destructor to every element", as is required of containers.
>>
>>OK, point taken.
>>
>>
>>>>>Also, I'm also not sure that it could really be called immutable,
>>>>>since you can replace elements (just not insert or delete them).
>>>>>Anyway, can you suggest an alternative name?
>>>>
>>>>container ;->
>>
>>Well, I'm stumped for a name at the moment.  I think we need a new
>>concept in the hierarchy, less-refined than Container.
> 
> 
> How about "iterator_pair" :-)

Yuck.

> Actually, I now think "iterator_range" might have been better

Yes.

> , because
> it hints that the two iterators must define a range. However, I can't
> conceive of any sensible implementation with similar semantics that
> *doesn't* store a pair of iterators, so I don't see anything to be
> gained by trying to hide this behind a new abstraction.

Ah, I just realized what the right name is:

      range_view

or, if you insist

      iterator_range_view

see http://www.zib.de/weiser/vtl/ for precedent.






From dave at boost-consulting.com  Fri Oct 17 16:07:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Oct 2003 10:07:48 -0400
Subject: [C++-sig] Re: problem with scope().attr(xxx)
In-Reply-To: <007e01c39493$9e8f7150$cd00a8c0@nico>
References: <007e01c39493$9e8f7150$cd00a8c0@nico>
Message-ID: <bmot3q$67h$1@sea.gmane.org>

Nicolas LELONG wrote:

> Hello,
> 
> I did not update the BPL code I use since August (nor did I really follow
> the evolutions), and monday I decided to grab the lastest CVS (as of
> monday). I'm now having problems with some 'global' variables declarations
> that worked previously.
> 
> The minimal code I use is the following :
> 
> class Test
> {
> };
> Test test;
> 
> BOOST_PYTHON_MODULE( aaa )
> {
>   class_<Test, boost::noncopyable>("Test", no_init);
>   scope().attr("test") = boost::ref(test);
> }
> 
> which worked OK previously - now the scope().attr line raises an error "No
> to_python (by-value) converter found for C++ type" ! I've noticed that if if
> I remove the boost::noncopyable from the 'class_' instanciation, it all
> works ok.
> 
> I was wondering if this was a normal 'new' behaviour or not ? if it is
> normal, how can I expose my global noncopyable instances to python ?

No, it's a bug.  THanks for the report!
The enclosed patch should help.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: object_core.patch
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031017/35c10216/attachment.txt>

From sf.lists at web.de  Fri Oct 17 16:15:43 2003
From: sf.lists at web.de (Stefan Fleiter)
Date: Fri, 17 Oct 2003 16:15:43 +0200
Subject: [C++-sig] Re: boost::python::object and stl::map warning
In-Reply-To: <bmopmk$tkc$2@sea.gmane.org>
References: <3F8DBD38.3000909@shockfamily.net>
	<bmkk7q$509$1@sea.gmane.org>	<3F8F9A8D.3060605@web.de>
	<bmopmk$tkc$2@sea.gmane.org>
Message-ID: <3F8FF98F.6010009@web.de>

> Already done a long time ago.

Sorry, but using :pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
I still get the old version (revision 1.9).

Greets,
Stefan




From nico_ml at mgdesign.org  Fri Oct 17 17:03:28 2003
From: nico_ml at mgdesign.org (Nicolas LELONG)
Date: Fri, 17 Oct 2003 17:03:28 +0200
Subject: [C++-sig] Re: problem with scope().attr(xxx)
References: <007e01c39493$9e8f7150$cd00a8c0@nico> <bmot3q$67h$1@sea.gmane.org>
Message-ID: <015801c394bf$ddc0a480$cd00a8c0@nico>

> No, it's a bug.  THanks for the report!

You're welcome :)

> The enclosed patch should help.

It indeed fixes the problem. Have you already included this patch in the
boost cvs ?
Thanks once more for the quick help :)

Nicolas.




From dave at boost-consulting.com  Fri Oct 17 17:30:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Oct 2003 11:30:26 -0400
Subject: [C++-sig] Re: problem with scope().attr(xxx)
In-Reply-To: <015801c394bf$ddc0a480$cd00a8c0@nico>
References: <007e01c39493$9e8f7150$cd00a8c0@nico> <bmot3q$67h$1@sea.gmane.org>
	<015801c394bf$ddc0a480$cd00a8c0@nico>
Message-ID: <bmp1up$86b$1@sea.gmane.org>

Nicolas LELONG wrote:
>>No, it's a bug.  THanks for the report!
> 
> 
> You're welcome :)
> 
> 
>>The enclosed patch should help.
> 
> 
> It indeed fixes the problem. Have you already included this patch in the
> boost cvs ?

Of course; no need to ask

> Thanks once more for the quick help :)

No problem.





From dave at boost-consulting.com  Fri Oct 17 17:30:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Oct 2003 11:30:58 -0400
Subject: [C++-sig] Re: boost::python::object and stl::map warning
In-Reply-To: <3F8FF98F.6010009@web.de>
References: <3F8DBD38.3000909@shockfamily.net>	<bmkk7q$509$1@sea.gmane.org>	<3F8F9A8D.3060605@web.de>	<bmopmk$tkc$2@sea.gmane.org>
	<3F8FF98F.6010009@web.de>
Message-ID: <bmp1vo$86b$2@sea.gmane.org>

Stefan Fleiter wrote:

>> Already done a long time ago.
> 
> 
> Sorry, but using 
> :pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
> I still get the old version (revision 1.9).

The SF anonymous CVS is still lagging behind.





From s_sourceforge at nedprod.com  Fri Oct 17 18:45:45 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 17 Oct 2003 17:45:45 +0100
Subject: [C++-sig] Pyste problem: ordering of inits
Message-ID: <3F902AC9.18696.2E8D16A8@localhost>

Unfortunately if pyste produces class_ registrations with a bases<> 
member, BPL requires the base to be registered before its subclasses. 
As pyste orders its writing of _main.cpp based on alphabetical order, 
one has a problem.

Two solutions: make the order of how the pyste files are specified on 
the command line affect the order in _main.cpp. Or more preferably, 
pyste knows what bases<> it's specified and automatically orders them 
correctly.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031017/c78df227/attachment.pgp>

From s_sourceforge at nedprod.com  Fri Oct 17 20:00:56 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 17 Oct 2003 19:00:56 +0100
Subject: [C++-sig] Very large binaries
Message-ID: <3F903C68.24702.2ED1EB05@localhost>

Just did my very first ever link and was rather shocked to see a 23Mb 
DLL. No debug info, /Og optimisation.

Just compiling now will full optimisation and COMDAT folding 
(optimising for smallness obviously). But I'd doubt if it gets below 
18Mb.

Anything else I can do? That's seriously large wrap for only a 2Mb 
C++ library.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031017/72499231/attachment.pgp>

From s_sourceforge at nedprod.com  Fri Oct 17 22:09:41 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 17 Oct 2003 21:09:41 +0100
Subject: [C++-sig] RTTI and image size
Message-ID: <3F905A95.8070.2F47C9E2@localhost>

Been doing some poking around, and it seems a good proportion of the 
huge binary is RTTI info. I'm seeing lots of repeating sections of 
data with very little variance.

How well does BPL work if RTTI is disabled?

I /really/ wish RTTI info was filterable ...

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031017/342c5cf7/attachment.pgp>

From mike at nospam.com  Fri Oct 17 22:24:19 2003
From: mike at nospam.com (Mike Rovner)
Date: Fri, 17 Oct 2003 13:24:19 -0700
Subject: [C++-sig] Re: Duplicate "ignore"(again...) and more. (Latest CVS,
	VC .NET 2003)
References: <43176117328.20031017125113@hotbox.ru>
Message-ID: <bmpj5b$moi$1@sea.gmane.org>

Kerim Borchaev wrote:
> As I get it VC7.1 also has this bug with anonymous namespace:

It's only happend with PCH on.

> #if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) ||
> But VC7.1 is compiled with tuple_basic.hpp that has no such
> a workaround.

Either change 1300 to 1310 or turn PCH off.

HTH,
Mike






From dirk at gerrits.homeip.net  Fri Oct 17 22:45:24 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Fri, 17 Oct 2003 22:45:24 +0200
Subject: [C++-sig] Re: getting result from the interpreter -- boost-python
In-Reply-To: <upth0xay6.fsf@boost-consulting.com>
References: <200310141121.39776.collar@gamic.com>
	<upth0xay6.fsf@boost-consulting.com>
Message-ID: <3F9054E4.7020803@gerrits.homeip.net>

Sorry for my slow response, hectic week...

David Abrahams wrote:
[...]
> The problem is that the line declaring "main_namespace" is declaring
> a function which returns a dict.  But where did you get that line?
> It's not in any of the docs I can find.

Oh it's there. :\ At the time, I was using MSVC7 or Intel7 I think, so 
apparently this slipped through the maze of standard non-compliance, and 
I didn't see it either. But GCC 3.3.2 on my GNU/Linux Debian 
installation indeed complains about this, and rightly so.

Sorry.

> I'd write:
>     
>     // Retrieve the main module
>     python::object main_module = python::extract<python::object>(
>         PyImport_AddModule("__main__")
>     );
>     
>     // Retrieve the main module's namespace
>     python::object main_namespace = main_module.attr("__dict__");
>     
> or, if your code has to run on broken compilers like vc6:
> 
>     // Retrieve the main module
>     python::object main_module = python::extract<python::object>(
>         PyImport_AddModule("__main__")
>     )();
>     
>     // Retrieve the main module's namespace
>     python::object main_namespace(main_module.attr("__dict__"));
> 
> In fact, I would like it very much if we could change the examples in
> the tutorial to use this style.  It's far simpler and clearer, IMO.

I concur. Fixes the bug and removes some of the nasty syntax. I'll make 
a patch and send it to you.

Joel, should I correct quickstart.txt or the HTML files generated from 
it? If the former, then I'd like the modified quickdoc you used to build 
the HTML files, to verify my changes. If the latter, what's 
quickstart.txt still doing there? :)

I'll also edit embedding.cpp, if that's okay. It's not broken, but it 
could use the same stylistic enhancements.

Dirk Gerrits





From nicodemus at globalite.com.br  Fri Oct 17 23:46:27 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 17 Oct 2003 18:46:27 -0300
Subject: [C++-sig] Pyste problem: ordering of inits
In-Reply-To: <3F902AC9.18696.2E8D16A8@localhost>
References: <3F902AC9.18696.2E8D16A8@localhost>
Message-ID: <3F906333.5040800@globalite.com.br>

Hi Niall,

Niall Douglas wrote:

>Unfortunately if pyste produces class_ registrations with a bases<> 
>member, BPL requires the base to be registered before its subclasses. 
>As pyste orders its writing of _main.cpp based on alphabetical order, 
>one has a problem.
>

Have you read the new documentation, specially about the new "Import" 
function? If so, then we have a bug.

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Sat Oct 18 00:20:10 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 17 Oct 2003 19:20:10 -0300
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F8744CA.21752.BCAAACF@localhost>
References: <3F871321.4787.B08AD10@localhost>
	<3F8744CA.21752.BCAAACF@localhost>
Message-ID: <3F906B1A.70102@globalite.com.br>

Hi Niall,

Niall Douglas wrote:

>>The generated file:
>>
>>// PCH 
>>=================================================================> #include "common.h"
>>#ifdef _MSC_VER
>>#pragma hdrstop
>>#endif
>>
>>// Includes 
>>=================================================================> #include <A.h>
>>...
>>    
>>
>
>The PCH file must be the FIRST include and the ONLY precompiled 
>header for v3.4 of GCC at least (I'm guessing they'll improve this 
>with time). For MSVC you can have as many headers as you like before 
>the #pragma hdrstop. It should be the user's responsibility to ensure 
>common.h includes <boost/python.hpp> and anything else.
>
>The above gives the maximum flexibility to users AFAICS. Comments 
>from the group?
>

I implemented this on CVS (sorry about the delay)... you can use 
PCHInclude with one or more parameters:

Class('A', 'A.h')
PCHInclude('common.h', 'common2.h')

will generate:

// PCH 
=========================================================================
#include <common.h>
#include <common2.h>
#ifdef _MSC_VER
#pragma hdrstop
#endif

// Includes 
====================================================================
#include <A.h>


If we comment out the PCHInclude function, we will get:

// Boost Includes 
==============================================================
#include <boost/python.hpp>
#include <boost/cstdint.hpp>

// Includes 
====================================================================
#include <A.h>


ie, the old behaviour. The user must include <boost/python.hpp> and 
<boost/cstdint.hpp> in the precompiled header for this scheme to work. 
Opinions?

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Sat Oct 18 00:20:22 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 17 Oct 2003 19:20:22 -0300
Subject: [C++-sig] pyste suggestion: easier overriding of exporters
In-Reply-To: <200310140244.h9E2i2N81017569@d0mino.fnal.gov>
References: <200310140244.h9E2i2N81017569@d0mino.fnal.gov>
Message-ID: <3F906B26.7030805@globalite.com.br>

Hi Scott,

scott snyder wrote:

>hi -
>
>In the course of playing with pyste, i've made numerous minor
>fixes and extensions.  In such cases, i'd like to be able to keep
>my new code in the .pyste file (or something imported from there)
>rather than having to change the pyste code itself.
>
>One way of extending pyste is to use one's own Exporter classes.
>In most cases, these can derive from the existing ones, modifying
>any needed behaviors.
>
>There is, however, no clean way to specify in a .pyste file that you
>want to use a custom exporter class.  In the past, i've done this
>by duplicating the classes that derive from DeclarationInfo and
>changing the Exporter class, i.e., doing something like this:
>
>class Class (DeclarationInfo):
>    def __init__(self, name, include, tail=None, otherInfo=None):
>        DeclarationInfo.__init__(self, otherInfo)
>        self._Attribute('name', name)
>        self._Attribute('include', include)
>        self._Attribute('exclude', False)
>        # create a ClassExporter
>        exporter = My_Class_Exporter(InfoWrapper(self), tail)
>        exporters.exporters.append(exporter)
>        exporter.interface_file = exporters.current_interface
>
>and then importing this into the pyste file.
>
>This is not entirely satisfactory, due to the pyste code that must
>be duplicated here.  One also runs into a problem with ClassExporter,
>as its ExportNestedClasses method also has a reference to
>`ClassExporter' literally coded.
>
>I would suggest allowing for such extensions by adding an (optional)
>argument to the constructors of the info classes giving the class
>to use for the exporter.  Thus, if someone wants to use a non-standard
>exporter for a particular declaration, it can just be specified
>in the Class() or whatever call.  Then if i want all classes to use
>my custom exporter, i can do something like this:
>
>def Class (name, include, tail=None, otherInfo=None):
>    return ClassInfo (name, include, tail, otherInfo,
>                      exporter_class = My_Class_Exporter)
>
>avoiding having to duplicate the code from ClassInfo.
>
>The patches below implement this.
>I added an optional parameter `exporter_class' to the info class
>constructors, giving the class to use for the exporter.  I also
>modified ClassExporter.ExportNestedClasses to create the nested
>class exporters using the same class as the current exporter,
>rather than hardwiring in ClassExporter.
>  
>

(Sorry about the delay in responding)

Thanks a lot for your patch, it has been applied! Thanks again.

><snip patch>
>  
>

Regards,
Nicodemus.




From s_sourceforge at nedprod.com  Sat Oct 18 00:21:01 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 17 Oct 2003 23:21:01 +0100
Subject: [C++-sig] Pyste problem: ordering of inits
In-Reply-To: <3F906333.5040800@globalite.com.br>
References: <3F902AC9.18696.2E8D16A8@localhost>
Message-ID: <3F90795D.4105.2FC00790@localhost>

On 17 Oct 2003 at 18:46, Nicodemus wrote:

> >Unfortunately if pyste produces class_ registrations with a bases<>
> >member, BPL requires the base to be registered before its subclasses.
> > As pyste orders its writing of _main.cpp based on alphabetical
> >order, one has a problem.
> 
> Have you read the new documentation, specially about the new "Import"
> function? If so, then we have a bug.

Ooo, that's new.

I'll get back to you on this. BTW everyone, disabling RTTI takes a 
26.4Mb DLL down to only 9.7Mb!

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031017/0bd4ebb8/attachment.pgp>

From s_sourceforge at nedprod.com  Sat Oct 18 00:31:48 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 17 Oct 2003 23:31:48 +0100
Subject: [C++-sig] Pyste suggestion: MSVC precompiled headers support
In-Reply-To: <3F906B1A.70102@globalite.com.br>
References: <3F8744CA.21752.BCAAACF@localhost>
Message-ID: <3F907BE4.31798.2FC9E5FD@localhost>

On 17 Oct 2003 at 19:20, Nicodemus wrote:

> ie, the old behaviour. The user must include <boost/python.hpp> and
> <boost/cstdint.hpp> in the precompiled header for this scheme to work.
> Opinions?

Outstanding, and thank you. I'll test it with GCC v3.4 and let you 
know.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031017/d2ab159d/attachment.pgp>

From blais at iro.umontreal.ca  Sat Oct 18 01:39:20 2003
From: blais at iro.umontreal.ca (Martin Blais)
Date: Fri, 17 Oct 2003 19:39:20 -0400
Subject: [C++-sig] (OT) compiling python with msvc 7.1?
Message-ID: <bmpuj9$uel$1@sea.gmane.org>

hi guys

just wondering, does anyone know how to build python (itself) with msvc 7.1?

i think i've looked everywhere, there are no instructions in the Python 
distribution itself, the PCbuild directory contains files for msvc 6.0, 
the PC directory for older versions, and googling away and grepping for 
quite a while only turns up a few threads on whether the official build 
should eventually become a 7.0/7.1 build.

surely one of the Boost.Python gurus must have hacked a jam file to do 
that at some point...

(i've got the infamous problem of passing C-runtime objects across the 
runtime boundary (python built with msvc 6.0, and my extension modules 
build with msvc 7.1).  an easy solution would be to build my python 
itself with 7.1.)

thanks for any hint/help.
cheers,





From mike at nospam.com  Sat Oct 18 01:49:24 2003
From: mike at nospam.com (Mike Rovner)
Date: Fri, 17 Oct 2003 16:49:24 -0700
Subject: [C++-sig] Re: (OT) compiling python with msvc 7.1?
References: <bmpuj9$uel$1@sea.gmane.org>
Message-ID: <bmpv5t$v77$1@sea.gmane.org>

Martin Blais wrote:
> just wondering, does anyone know how to build python (itself) with
> msvc 7.1?

Just did it ;)

> the PCbuild directory contains files for msvc 6.0,

I just created emplty .sln and added all old vc6 projects to it.

tkinter went fine with ActiveTcl 8.4.1.0 installed (for includes and libs),
which happend to reside on my disk

HTH,
Mike






From s_sourceforge at nedprod.com  Sat Oct 18 05:08:51 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 18 Oct 2003 04:08:51 +0100
Subject: [C++-sig] Pyste (or GCCXML) bug: Fails to wrap inherited members
	defined inline
Message-ID: <3F90BCD3.2713.30C78B47@localhost>

Not sure if it's pyste or GCCXML, but sometimes (not always, about 
25% of the time) pyste's wrappings won't specify members inherited 
from a base class when they were defined in the bass class' header 
file.

Is this a known problem, or is it GCCXML? Typically when I run GCCXML 
on its own it always gives me what appears to be the right output, 
but it could be slightly different and I'd never know.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031018/8c1947bc/attachment.pgp>

From s_sourceforge at nedprod.com  Sat Oct 18 04:46:12 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 18 Oct 2003 03:46:12 +0100
Subject: [C++-sig] Pyste and member documentation
Message-ID: <3F90B784.19010.30B2CFA9@localhost>

I've just been looking through doxygen's XML output and I believe 
it's more than sufficient for pyste to compare against the GCCXML 
output so that they could be matched.

Then personally I'd prefer a URL as the docstring to keep the DLL 
size down but from what I can see, you merely append a .html to the 
XML id and you have the equivalent HTML file with anchor.

Thoughts?

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031018/aa3ce1e0/attachment.pgp>

From s_sourceforge at nedprod.com  Sat Oct 18 03:18:03 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 18 Oct 2003 02:18:03 +0100
Subject: [C++-sig] Enumerating items in pyste
Message-ID: <3F90A2DB.26708.30621C3D@localhost>

When I go:

cclass=Class('MyClassB', 'myinclude.h')

... and myinclude.h contains two class definitions (MyClassB and 
MyClassA), I notice that pyste sets the one you asked for as the 
default so cclass refers to cclass.MyClassB. However, cclass.MyClassA 
is still available.

Pushing past this, does Class() merely extract classes from the 
header file and nothing else? What about enums? And how can I 
enumerate cclass eg;

classes=Class('MyClassB', 'myinclude.h')
for cclass in classes.contents():
    execfile('Policies/'+cclass.name()+'.py')
    eval(cclass.name()+'.apply()')

AFAICS, the internal dictionary DeclarationInfo in infos.py uses 
can't offer out its contents so I couldn't enumerate like above. Or 
am I missing something?

(If this can't be done yet, then the above is basically what I want 
to do with AllFromHeader() when it gets fixed)

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031018/7e8fbc48/attachment.pgp>

From s_sourceforge at nedprod.com  Sat Oct 18 06:02:48 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 18 Oct 2003 05:02:48 +0100
Subject: [C++-sig] More weird pyste behaviour
Message-ID: <3F90C978.23319.30F8F0C9@localhost>

I'll ensure this is still the case with CVS pyste when boost-
consulting gets updated tomorrow, but since I added the Import() 
directives pyste is outputting in some cases 42 repeats of identical 
wrappings into the same cpp file.

Of course, it could be my modifications, so I'll check with CVS pyste 
tomorrow.

If BTW I work around this by invoking pyste on each pyste file 
individually, then the int's in UniqueInt<> in each unnamed enum all 
start from zero. Doesn't that cause conflicts?

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031018/b42d7687/attachment.pgp>

From dave at boost-consulting.com  Sat Oct 18 15:17:09 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 18 Oct 2003 09:17:09 -0400
Subject: [C++-sig] Re: RTTI and image size
References: <3F905A95.8070.2F47C9E2@localhost>
Message-ID: <uad7yadnu.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Been doing some poking around, and it seems a good proportion of the 
> huge binary is RTTI info. I'm seeing lots of repeating sections of 
> data with very little variance.
>
> How well does BPL work if RTTI is disabled?

It doesn't.  RTTI is an integral part of how Boost.Python works.

> I /really/ wish RTTI info was filterable ...

When and if Daniel Wallin and I get the Luabind/Boost.Python
integration done, there will be some support for users to plug in
their own hand-rolled type identification mechanisms... but don't
expect it to be pretty.  You'll have to supply some C++ code.  For
example, using Pyste to generate bindings using 100% Pure Python
won't be an option.

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




From dave at boost-consulting.com  Sat Oct 18 15:21:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 18 Oct 2003 09:21:22 -0400
Subject: [C++-sig] Re: More weird pyste behaviour
References: <3F90C978.23319.30F8F0C9@localhost>
Message-ID: <u4qy6adgt.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> I'll ensure this is still the case with CVS pyste when boost-
> consulting gets updated tomorrow, but since I added the Import() 
> directives pyste is outputting in some cases 42 repeats of identical 
> wrappings into the same cpp file.

The Boost Consulting CVS mirror isn't getting updated because of a
problem at SourceForge: the "CVS tarball" they're publishing for us
is only about 100 bytes long.

I suggest using the bzipped snapshot at
http://www.boost.org/boost.tar.bz2, which is updated hourly.


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




From s_sourceforge at nedprod.com  Sat Oct 18 07:24:54 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 18 Oct 2003 06:24:54 +0100
Subject: [C++-sig] Re: Pyste bug: Fails to pull in inherited members
Message-ID: <3F90DCB6.16849.31441DA9@localhost>

On 18 Oct 2003 at 3:49, c++-sig at python.org wrote:

> I have absolutely no idea why, but when you feed all the pyste files
> to pyste at once it fails to wrap inherited members for my FXIODeviceS
> class, the ones it inherited from FXIODevice.
> 
> But when you pass FXIODeviceS.pyste on its own, it works fine. Very
> odd.
> 
> I'm afraid I've not been able to localise this one Bruno, so I'm
> guessing the only choice is to download v0.4 when it's released in the
> next week or so and work with that. Sorry about that.

Scratch that, I've found it!

In FXIODevice, I have the following:

virtual FXuval readBlock(char *data, FXuval maxlen)=0;

and its convenience overload:

FXuval readBlock(FXuchar *data, FXuval maxlen) { return 
readBlock((char *) data, maxlen); }

FXIODeviceS inherits from FXIODevice and pyste generates for it 
(IODeviceS):

        .def("readBlock", pure_virtual(&FX::FXIODevice::readBlock))

This is ambiguous. It should be:

        .def("readBlock", pure_virtual((long unsigned int 
(FX::FXIODevice::*)(char*, long unsigned int) 
)&FX::FXIODevice::readBlock))

... which is what pyste generates for FXIODevice.

I'm guessing pyste is somehow not noticing the base class overloads 
despite the use of Import()?

BTW, it was erratic before because sometimes IODevice was defined 
before IODeviceS, other times not.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031018/ba7b3e4e/attachment.pgp>

From datafeedNOSPAM at SoftHome.net  Sat Oct 18 22:30:56 2003
From: datafeedNOSPAM at SoftHome.net (M. Evans)
Date: Sat, 18 Oct 2003 13:30:56 -0700
Subject: [C++-sig] Chandler PIM Project
Message-ID: <302175487.20031018133056@SoftHome.net>


Chandler is an ambitious, but well-financed and well-staffed,
open-source effort to build "a next-generation Personal Information
Manager."

http://www.osafoundation.org/Chandler-Product_FAQ.htm
http://www.osafoundation.org/OSAF_Our_Vision.htm

It's of interest because the architecture is a combination of Python
and C++. The GUI is wxWindows.

There are some major IT industry luminaries associated with this
project.

Mark




From s_sourceforge at nedprod.com  Sun Oct 19 01:59:42 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 19 Oct 2003 00:59:42 +0100
Subject: [C++-sig] Re: More weird pyste behaviour
In-Reply-To: <u4qy6adgt.fsf@boost-consulting.com>
Message-ID: <3F91E1FE.15369.3540BE9A@localhost>

On 18 Oct 2003 at 9:21, David Abrahams wrote:

> > I'll ensure this is still the case with CVS pyste when boost-
> > consulting gets updated tomorrow, but since I added the Import()
> > directives pyste is outputting in some cases 42 repeats of identical
> > wrappings into the same cpp file.
> 
> The Boost Consulting CVS mirror isn't getting updated because of a
> problem at SourceForge: the "CVS tarball" they're publishing for us is
> only about 100 bytes long.
> 
> I suggest using the bzipped snapshot at
> http://www.boost.org/boost.tar.bz2, which is updated hourly.

I always get that, I strongly dislike CVS plus it's much faster by 
modem.

Q: Any chance of including the new indexing suite in that binary? My 
edition doesn't have Raoul's latest changes which I haven't been able 
to find on ViewCVS.

Since this is likely to be a continuing problem, is Raoul's stuff 
under some special tag or branch and if so, how do I select it from 
the ViewCVS webpage? I'm fine with downloading each file individually 
if needs be (it appears to be bug-free, which is outstanding + don't 
need to keep downloading new copies).

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031019/f2de1275/attachment.pgp>

From s_sourceforge at nedprod.com  Sun Oct 19 01:52:51 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 19 Oct 2003 00:52:51 +0100
Subject: [C++-sig] Re: RTTI and image size
In-Reply-To: <uad7yadnu.fsf@boost-consulting.com>
Message-ID: <3F91E063.13340.353A7819@localhost>

On 18 Oct 2003 at 9:17, David Abrahams wrote:

> > How well does BPL work if RTTI is disabled?
> 
> It doesn't.  RTTI is an integral part of how Boost.Python works.

Sorry, I should have been clearer - does BPL need to obtain derived 
polymorphic information from base classes or is it fine with just 
static type info ie; the static type of whatever it has?

I'm assuming from your mention of luabind that the answer is yes.

> > I /really/ wish RTTI info was filterable ...
> 
> When and if Daniel Wallin and I get the Luabind/Boost.Python
> integration done, there will be some support for users to plug in
> their own hand-rolled type identification mechanisms... but don't
> expect it to be pretty.  You'll have to supply some C++ code.  For
> example, using Pyste to generate bindings using 100% Pure Python won't
> be an option.

Sounds to me like GCCXML is again the answer - where it sees calls to 
some luabind function with some type, it outputs the type into a file 
from where luabind can assign it a unique id.

I've noticed that on MSVC, if you disable RTTI it in fact only 
disables the polymorphic support bit - static type queries still work 
fine. Thus if BPL didn't need to know derived classes, you could 
safely leave it off and all those volumes of worst case scenario data 
could be left out because MSVC would only include info for those 
types queried (I've inspected assembly outputs under the various 
cases and this seems to be true).

GCC as far as I understand it totally disables RTTI completely when 
you say so. I'm already having nightmarish visions of 50Mb .so's ... 
:(

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031019/3415c12f/attachment.pgp>

From RaoulGough at yahoo.co.uk  Sun Oct 19 12:22:38 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sun, 19 Oct 2003 11:22:38 +0100
Subject: [C++-sig] Re: C arrays mk 2
References: <3F8CB32C.2681.2101D79B@localhost> <bmjvoo$7bi$1@sea.gmane.org>
	<u1xteiajb.fsf@yahoo.co.uk> <bmk6ru$lsj$1@sea.gmane.org>
	<uwub6gpo1.fsf@yahoo.co.uk> <bmkg3r$tpt$1@sea.gmane.org>
	<uoewigmnf.fsf@yahoo.co.uk> <bmkkl0$5i3$1@sea.gmane.org>
	<ufzhtgo1j.fsf@yahoo.co.uk> <bmn0c5$bvd$1@sea.gmane.org>
	<u4qy8gjxz.fsf@yahoo.co.uk> <bmoqk7$b7$1@sea.gmane.org>
Message-ID: <uptgtfrwx.fsf@yahoo.co.uk>

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

> Raoul Gough wrote:
>
>> David Abrahams <dave at boost-consulting.com> writes:
[snip]
>>>No, it's not.  Its list-ness affects externally visible properties
>>>like complexity of insert, iterator invalidation, etc.  If you can
>>>build something with the same properties using a different data
>>>structure, by all means go ahead and call it "list".
>> OK, but apply the same reasoning to "iterator_pair" and there is no
>> problem with that name either. The iterator-pairness of my container
>> affects important semantic properties, mainly the fact that it
>> references external objects. e.g.
>> int a[10] = { 0 };
>> &iterator_pair<int *>(a, a + 10)[0] == a
>
> Nothing about its interface exposes its pairness or the underlying
> iterators.  Can you ask it to increment its its first or last
> iterator? At least with list the name tells you there's a sequence.

I don't think you're looking very hard. For instance, constant time
construction means that it contains a fixed number of objects
regardless of the length of sequence it represents. Also, in the face
of iterator invalidation in the "real" container, only invalidating
the begin and end of the range necessarily affects the validity of the
iterator pair. For a range within std::list, for instance, you could
erase intermediate elements and still have a valid iterator_pair.

>
>> This is an important property in terms of usefulness, but also in
>> terms of object lifetime management, unless you want to risk having
>> dangling references. For instance you need to consider what would
>> happen if you have an iterator_pair that references the contents of a
>> standard container - any operations on the container that invalidate
>> iterators within the range will affect the iterator_pair.
>
> There are too many other ways to realize that property.  Maybe "list"
> is badly named also; it's the only such example in the standard
> containers. The tradition in container collections is to go with
> more-generic names like "bag".
>
> But, enough of this; I don't believe in the name "iterator_pair" --
> that should be reserved for something like pair<iterator,iterator> --
> but if I can't convince you, so be it.

As I stated originally, I already had reservations about the name
because it did not capture the requirement for having two iterators
into the same container. It's not that I think the original name is
perfect, I just don't think we started off discussing the right
problem with it.

>
>>>>Anyway, paragraph one of the container requirements says:
>>>>  "Containers are objects that store other objects. They control
>>>>  allocation and deallocation of these objects through constructors,
>>>>  destructors, insert and erase operations."
>>>>There is also no way that ~iterator_pair is going to "apply the
>>>>destructor to every element", as is required of containers.
>>>
>>>OK, point taken.
>>>
>>>
>>>>>>Also, I'm also not sure that it could really be called immutable,
>>>>>>since you can replace elements (just not insert or delete them).
>>>>>>Anyway, can you suggest an alternative name?
>>>>>
>>>>>container ;->
>>>
>>>Well, I'm stumped for a name at the moment.  I think we need a new
>>>concept in the hierarchy, less-refined than Container.
>> How about "iterator_pair" :-)
>
> Yuck.
>
>> Actually, I now think "iterator_range" might have been better
>
> Yes.
>
>> , because
>> it hints that the two iterators must define a range. However, I can't
>> conceive of any sensible implementation with similar semantics that
>> *doesn't* store a pair of iterators, so I don't see anything to be
>> gained by trying to hide this behind a new abstraction.
>
> Ah, I just realized what the right name is:
>
>       range_view
>
> or, if you insist
>
>       iterator_range_view
>
> see http://www.zib.de/weiser/vtl/ for precedent.

Within the context of the View Template Library, I'm sure range_view
is the appropriate name. Coincidentally, there's an article by Jon
Jagger in the latest ACCU Overload magazine that introduces an
iterator pair just called "range" - and that's really just a pair that
happens to provide accessors called "begin" and "end". I think I'm
going to go with iterator_range in our case, since the "view" suffix
might be slightly obscure in this context.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Sun Oct 19 12:37:21 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sun, 19 Oct 2003 11:37:21 +0100
Subject: [C++-sig] Re: More weird pyste behaviour
References: <u4qy6adgt.fsf@boost-consulting.com>
	<3F91E1FE.15369.3540BE9A@localhost>
Message-ID: <ullrhfr8e.fsf@yahoo.co.uk>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 18 Oct 2003 at 9:21, David Abrahams wrote:
>
>> > I'll ensure this is still the case with CVS pyste when boost-
>> > consulting gets updated tomorrow, but since I added the Import()
>> > directives pyste is outputting in some cases 42 repeats of identical
>> > wrappings into the same cpp file.
>> 
>> The Boost Consulting CVS mirror isn't getting updated because of a
>> problem at SourceForge: the "CVS tarball" they're publishing for us is
>> only about 100 bytes long.
>> 
>> I suggest using the bzipped snapshot at
>> http://www.boost.org/boost.tar.bz2, which is updated hourly.
>
> I always get that, I strongly dislike CVS plus it's much faster by 
> modem.
>
> Q: Any chance of including the new indexing suite in that binary? My 
> edition doesn't have Raoul's latest changes which I haven't been able 
> to find on ViewCVS.
>
> Since this is likely to be a continuing problem, is Raoul's stuff 
> under some special tag or branch and if so, how do I select it from 
> the ViewCVS webpage? I'm fine with downloading each file individually 
> if needs be (it appears to be bug-free, which is outstanding + don't 
> need to keep downloading new copies).

Yes, I had a look at ViewCVS a few days ago. IIRC, you need to select
manually between the branches (with the "Show files using tag"
selection box near the bottom of the page). What you're looking for is
the "indexing_v2" branch, which only exists within
boost/boost/python/suite/indexing (you'll need everything in this
subdir) and boost/libs/python (you'll need build/Jamfile and
everything in src/indexing from this subdir).

BTW, iterator_pair will probably be renamed "iterator_range" within
the next few days - this will probably affect you if you upgrade
later.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From yakumoklesk at yahoo.es  Sun Oct 19 19:01:24 2003
From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es)
Date: Sun, 19 Oct 2003 19:01:24 +0200
Subject: [C++-sig] Re: More weird pyste behaviour
In-Reply-To: <ullrhfr8e.fsf@yahoo.co.uk>
Message-ID: <3F92DF84.7243.99C55@localhost>

I have automatically wrapped a C++ class using pyste. Now I have it 
inside the code of my program which embeds python, but when I 
compile, Microsoft Visual C++ cl.exe compiler says that has reached 
the heap limit.

I have tested with Zm, but the most I can put is /Zm1400 and it is not 
enugh. What can I do to compile it?

David.



From yakumoklesk at yahoo.es  Sun Oct 19 19:26:05 2003
From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es)
Date: Sun, 19 Oct 2003 19:26:05 +0200
Subject: [C++-sig] Sorry the mistaked Subject
In-Reply-To: <3F92DF84.7243.99C55@localhost>
References: <ullrhfr8e.fsf@yahoo.co.uk>
Message-ID: <3F92E54D.5966.20379A@localhost>

I forgot to change the subject of the previous email. Sorry.

David.




From dave at boost-consulting.com  Sun Oct 19 23:01:50 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 19 Oct 2003 17:01:50 -0400
Subject: [C++-sig] Re: RTTI and image size
References: <uad7yadnu.fsf@boost-consulting.com>
	<3F91E063.13340.353A7819@localhost>
Message-ID: <u65il7xhd.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 18 Oct 2003 at 9:17, David Abrahams wrote:
>
>> > How well does BPL work if RTTI is disabled?
>> 
>> It doesn't.  RTTI is an integral part of how Boost.Python works.
>
> Sorry, I should have been clearer - does BPL need to obtain derived 
> polymorphic information from base classes or is it fine with just 
> static type info ie; the static type of whatever it has?
>
> I'm assuming from your mention of luabind that the answer is yes.

The answer is no.  Quite a few Boost.Python features depend on the use
of dynamic_cast.  You should not expect inheritance relationships or
shared_ptr conversions to work properly without dynamic RTTI... at
least.  I'm not sure what else may depend on it.

The only thing I can recommend is that you use separate compilation
for the C++ guts of your project, and turn RTTI off there, then turn
it on for the compilation units that use Boost.Python.  No
guarantees, of course, but it seems more likely to work than just
shutting it off altogether.

>> > I /really/ wish RTTI info was filterable ...
>> 
>> When and if Daniel Wallin and I get the Luabind/Boost.Python
>> integration done, there will be some support for users to plug in
>> their own hand-rolled type identification mechanisms... but don't
>> expect it to be pretty.  You'll have to supply some C++ code.  For
>> example, using Pyste to generate bindings using 100% Pure Python won't
>> be an option.
>
> Sounds to me like GCCXML is again the answer - where it sees calls to 
> some luabind function with some type, it outputs the type into a file 
> from where luabind can assign it a unique id.

I assume you mean Boost.Python, not luabind.

Anyway, you're essentially assuming that someone can figure out how to
generate smaller RTTI information than MSVC does already.  "Don't
assume you can do the job better than the compiler already does" is a
cardinal rule for embedded programmers using C++; I don't see why it
shouldn't apply here just as well.

> I've noticed that on MSVC, if you disable RTTI it in fact only 
> disables the polymorphic support bit - static type queries still work 
> fine. Thus if BPL didn't need to know derived classes, you could 
> safely leave it off and all those volumes of worst case scenario data 
> could be left out because MSVC would only include info for those 
> types queried (I've inspected assembly outputs under the various 
> cases and this seems to be true).
>
> GCC as far as I understand it totally disables RTTI completely when 
> you say so. I'm already having nightmarish visions of 50Mb .so's ... 
> :(

GCC generates gigantic .so's if you leave debug info in them.  Have
you tried MSVC with optimizations and no debug info?

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




From s_sourceforge at nedprod.com  Sun Oct 19 22:07:28 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 19 Oct 2003 21:07:28 +0100
Subject: [C++-sig] Re: More weird pyste behaviour
In-Reply-To: <ullrhfr8e.fsf@yahoo.co.uk>
Message-ID: <3F92FD10.15128.39927C5E@localhost>

On 19 Oct 2003 at 11:37, Raoul Gough wrote:

> Yes, I had a look at ViewCVS a few days ago. IIRC, you need to select
> manually between the branches (with the "Show files using tag"
> selection box near the bottom of the page). What you're looking for is
> the "indexing_v2" branch, which only exists within
> boost/boost/python/suite/indexing (you'll need everything in this
> subdir) and boost/libs/python (you'll need build/Jamfile and
> everything in src/indexing from this subdir).

Outstanding, thanks for that. Today I'll be writing my very first GUI 
application in python to test the framework and provide an example.

> BTW, iterator_pair will probably be renamed "iterator_range" within
> the next few days - this will probably affect you if you upgrade
> later.

I should be making a release in the next week. It's testing, testing, 
testing from hereonin.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031019/cd0e3461/attachment.pgp>

From s_sourceforge at nedprod.com  Sun Oct 19 22:03:31 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 19 Oct 2003 21:03:31 +0100
Subject: Debug limit reached (was: Re: [C++-sig] Re: More weird pyste
	behaviour)
In-Reply-To: <3F92DF84.7243.99C55@localhost>
References: <ullrhfr8e.fsf@yahoo.co.uk>
Message-ID: <3F92FC23.1474.398EDBB7@localhost>

On 19 Oct 2003 at 19:01, yakumoklesk at yahoo.es wrote:

> I have automatically wrapped a C++ class using pyste. Now I have it
> inside the code of my program which embeds python, but when I compile,
> Microsoft Visual C++ cl.exe compiler says that has reached the heap
> limit.
> 
> I have tested with Zm, but the most I can put is /Zm1400 and it is not
> enugh. What can I do to compile it?

See the BPL FAQ in its docs.

Past that, disable debug info, incremental linking and precompiled 
headers. Some optimisations will need to go too.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031019/06e55600/attachment.pgp>

From s_sourceforge at nedprod.com  Mon Oct 20 03:36:55 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 20 Oct 2003 02:36:55 +0100
Subject: [C++-sig] Re: RTTI and image size
In-Reply-To: <u65il7xhd.fsf@boost-consulting.com>
Message-ID: <3F934A47.21635.1C2060@localhost>

On 19 Oct 2003 at 17:01, David Abrahams wrote:

> > Sounds to me like GCCXML is again the answer - where it sees calls
> > to some luabind function with some type, it outputs the type into a
> > file from where luabind can assign it a unique id.
> 
> I assume you mean Boost.Python, not luabind.

I meant luabind which from my cursory reading of the docs spoke about 
assigning unique integers to types.

> Anyway, you're essentially assuming that someone can figure out how to
> generate smaller RTTI information than MSVC does already.  "Don't
> assume you can do the job better than the compiler already does" is a
> cardinal rule for embedded programmers using C++; I don't see why it
> shouldn't apply here just as well.

It has, because of the standard, to generate RTTI for anything which 
could be queried, including by something loading it in as a DLL. Now 
I know that can't happen and that all use of RTTI it does is limited 
to what it does, so therefore there is great scope for cutting stuff 
out.

> GCC generates gigantic .so's if you leave debug info in them.  Have
> you tried MSVC with optimizations and no debug info?

MSVC7.1 won't compile them with PDB turned on (exceeds limits) - and 
with COFF debug info it's very, very slow (as in linking ran for 
twenty hours and still wasn't done). So basically realistically I can 
only compile with all debug info off.

It's throwing an attribute error exception when I import into python 
now which is new and didn't happen before. And I can't see anything 
which might have caused it (nothing's changed :( ).

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031020/4bd76413/attachment.pgp>

From dave at boost-consulting.com  Mon Oct 20 11:47:34 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 20 Oct 2003 05:47:34 -0400
Subject: [C++-sig] Re: RTTI and image size
References: <u65il7xhd.fsf@boost-consulting.com>
	<3F934A47.21635.1C2060@localhost>
Message-ID: <ud6cs2qbt.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 19 Oct 2003 at 17:01, David Abrahams wrote:
>
>> > Sounds to me like GCCXML is again the answer - where it sees calls
>> > to some luabind function with some type, it outputs the type into a
>> > file from where luabind can assign it a unique id.
>> 
>> I assume you mean Boost.Python, not luabind.
>
> I meant luabind which from my cursory reading of the docs spoke about 
> assigning unique integers to types.

Won't help you much if you're interested in Python, though.

>> Anyway, you're essentially assuming that someone can figure out how to
>> generate smaller RTTI information than MSVC does already.  "Don't
>> assume you can do the job better than the compiler already does" is a
>> cardinal rule for embedded programmers using C++; I don't see why it
>> shouldn't apply here just as well.
>
> It has, because of the standard, to generate RTTI for anything which 
> could be queried, including by something loading it in as a DLL. 

The standard doesn't cover DLLs at all, so all bets are off in that
case... but that's a technicality.

> Now I know that can't happen and that all use of RTTI it does is
> limited to what it does, so therefore there is great scope for
> cutting stuff out.

Yeah, you don't really need to compile most of your extension module
for export as a DLL; extension modules are loaded by name and only a
single entry point is used.  There really should be a way to get the
linker to strip the RTTI you don't need, or at least much of it.

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




From atulkshirsagar at yahoo.com  Mon Oct 20 17:16:05 2003
From: atulkshirsagar at yahoo.com (Atul Kshirsagar)
Date: Mon, 20 Oct 2003 08:16:05 -0700 (PDT)
Subject: [C++-sig] Can I import a module in C++ and use in python script ?
Message-ID: <20031020151605.17222.qmail@web40014.mail.yahoo.com>

I have following code in my C++ application using
python extension module "FlPythonModulesud".

Py_Initialize();
PyObject *m, *d, *m2;
m = PyImport_AddModule ("__main__");
d = PyModule_GetDict (m);
m2 = PyImport_ImportModuleEx ("FlPythonModulesud", d,
d, NULL);
PyDict_SetItemString (d, "FlPythonModulesud", m2);


I use python in multithreaded environment. I have
embedded a few C++ classes within pthon using Swig. I
run python expressions using PyRun_String().

A sample python expression looks like this;

from FlPythonModulesud import *

# Get collection pointer
collection = FlDataCollectionPtr(Collection)
# get collection size (num records in collection)
numRecords = collection.size()
print numRecords

Here FlDataCollectionPtr is a embedded class pointer
and Collection is a variable passed to python.

What I am trying to do is get rid OFF statement 
from FlPythonModulesud import * 
in the script programatically.

But the above PyImport_ImportModuleEx() doesn't serve
my purpose.

Any help will be appreciated !!!
Atul



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From pierre.barbier at cirad.fr  Mon Oct 20 17:37:07 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 20 Oct 2003 17:37:07 +0200
Subject: [C++-sig] Can I import a module in C++ and use in python script ?
In-Reply-To: <20031020151605.17222.qmail@web40014.mail.yahoo.com>
References: <20031020151605.17222.qmail@web40014.mail.yahoo.com>
Message-ID: <1066664227.604.4.camel@pbarbier>

Le lun 20/10/2003 ? 17:16, Atul Kshirsagar a ?crit :
> I have following code in my C++ application using
> python extension module "FlPythonModulesud".
> 
> Py_Initialize();
> PyObject *m, *d, *m2;
> m = PyImport_AddModule ("__main__");
> d = PyModule_GetDict (m);
> m2 = PyImport_ImportModuleEx ("FlPythonModulesud", d,
> d, NULL);
> PyDict_SetItemString (d, "FlPythonModulesud", m2);
> 
> 
> I use python in multithreaded environment. I have
> embedded a few C++ classes within pthon using Swig. I
> run python expressions using PyRun_String().
> 
> A sample python expression looks like this;
> 
> from FlPythonModulesud import *
> 
> # Get collection pointer
> collection = FlDataCollectionPtr(Collection)
> # get collection size (num records in collection)
> numRecords = collection.size()
> print numRecords
> 
> Here FlDataCollectionPtr is a embedded class pointer
> and Collection is a variable passed to python.
> 
> What I am trying to do is get rid OFF statement 
> from FlPythonModulesud import * 
> in the script programatically.
> 
> But the above PyImport_ImportModuleEx() doesn't serve
> my purpose.
> 
> Any help will be appreciated !!!
> Atul

You have to call the module init function once python is started. In
your case it should be :

initFlPythonModulesud()

Then you can call the "from FlPythonModulesud import *" using
PyRun_String ! (At least that's what I do and it workd well)

-- 
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 lutz_p at gmx.net  Mon Oct 20 17:45:55 2003
From: lutz_p at gmx.net (Lutz Paelike)
Date: Mon, 20 Oct 2003 17:45:55 +0200
Subject: [C++-sig] Problem with reinit of Numeric in embedded Python
Message-ID: <3F940333.50301@gmx.net>

Hi,

i have a problem with a strange error. Maybe somebody has experienced something similar,
or maybe it's a bug of boost i don't know...

The problem is that i embedded python in my application and it works just fine on the first time i run it.
But my application itself is a plugin and is loaded and unloaded into the host application.

Now if i load my plugin (works like expexted), unload and load again it doesn't work anymore.
I guess that something is not properly reinitialised, but stepping through in the debugger
shows that python is correctly unloaded (Py_Finalize is called) and reloaded (Py_Initialize is called again).

I can even run python code after the reinit, but it breaks when it comes to this call.

So here are the ingredients:

I get this exception while calling back from python into my c++ code

   File "C:\test_particles.py", line 24, in compute
     baseP = currentField.getPositionAt(basePNum)
ImportError: No module named 'Numeric' or its type 'ArrayType' did not follow the NumPy protocol

---

this is the corresponding c++ method:

	object getFromPython_PointAt(int index){
  		if (pPoints!=NULL) {
			MVectorArray &pp = *pPoints;

			const MVector &p = pp[index];
			return numeric::array( make_tuple(p.x, p.y, p.z) );
		} else {
			throw InitialisationException();
		}
	}

if step trough the corresponding c++ code  when the call from python is made it all works
until the
		return numeric::array( make_tuple(p.x, p.y, p.z) );

is made. So for me looks like a problem of the numeric module of boost.python.
Could this be a bug or did i forgot to initialise numeric somehow ?

Thanks for your help,

Lutz




From atulkshirsagar at yahoo.com  Mon Oct 20 18:36:47 2003
From: atulkshirsagar at yahoo.com (Atul Kshirsagar)
Date: Mon, 20 Oct 2003 09:36:47 -0700 (PDT)
Subject: [C++-sig] Can I import a module in C++ and use in python script ?
Message-ID: <20031020163647.33203.qmail@web40017.mail.yahoo.com>

Thanks much !
I was already calling initFlPythonModulesud()but;
PyRun_String("from FlPythonModulesud import *") worked
for me.
Atul


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From s_sourceforge at nedprod.com  Mon Oct 20 18:40:56 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 20 Oct 2003 17:40:56 +0100
Subject: [C++-sig] Pyste bug: const data not made read only
Message-ID: <3F941E28.30272.357C7E5@localhost>

In a class which has:

static const type variable;

... pyste is outputting def_readwrite() where it should be outputting 
def_readonly(). The def_readwrite() fails to compile (correctly) and 
so until changed public data members like this are a problem.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031020/765801a8/attachment.pgp>

From eric.anderson at comcast.net  Mon Oct 20 21:23:41 2003
From: eric.anderson at comcast.net (=?iso-8859-1?Q?eric_andersonT?=)
Date: Mon, 20 Oct 2003 12:23:41 -0700
Subject: [C++-sig] cl.exe heap limit (was: Re: More weird pyste behaviour)
References: <3F92DF84.7243.99C55@localhost>
Message-ID: <00b401c3973f$ac9b5260$bf01a8c0@ea1xp>

This may sound crazy, but try lowering it to /Zm1000.

eric

----- Original Message ----- 
From: <yakumoklesk at yahoo.es>
To: "Development of Python/C++ integration" <c++-sig at python.org>
Sent: Sunday, October 19, 2003 10:01 AM
Subject: Re: [C++-sig] Re: More weird pyste behaviour


> I have automatically wrapped a C++ class using pyste. Now I have it 
> inside the code of my program which embeds python, but when I 
> compile, Microsoft Visual C++ cl.exe compiler says that has reached 
> the heap limit.
> 
> I have tested with Zm, but the most I can put is /Zm1400 and it is not 
> enugh. What can I do to compile it?
> 
> David.
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From dave at boost-consulting.com  Tue Oct 21 18:25:38 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Oct 2003 12:25:38 -0400
Subject: [C++-sig] Re: Duplicate "ignore"(again...) and more. (Latest CVS,
 VC .NET 2003)
References: <43176117328.20031017125113@hotbox.ru>
Message-ID: <u7k2ya77h.fsf@boost-consulting.com>

Kerim,

This report should probably go to the main Boost developers' list.  A
small reproducible test case would also help a lot.

Thanks,
Dave


Kerim Borchaev <warkid at hotbox.ru> writes:

> Hello c++-sig,
>
> As I get it VC7.1 also has this bug with anonymous namespace:
>
> ... : error LNK2005:
> "struct swallow_assign::boost::detail::swallow_assign
> boost::tuples::`anonymous namespace'::ignore"
> ... already defined in ...
>
> I've read the archives and found that this bug has already been fixed
> for Visual C version <=7 in tuple_basic_no_partial_spec.hpp:
>
>     namespace {
> #if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) || (defined(__DECCXX_VER) && __DECCXX_VER <= 60590031)
>       static
> #endif 
>       detail::swallow_assign ignore;
>     }
>
> But VC7.1 is compiled with tuple_basic.hpp that has no such
> a workaround.
>
> And another one:
> ... : error LNK2005:
> "class boost::arg<6> `anonymous namespace'::_6"
> ... already defined in ...
>
> fixes if BOOST_MSVC <= 1300  replaced with BOOST_MSVC <= 1310 in
> boost/bind/placeholders.hpp line 39
>
> It would be nice if the patch was supplied by someone with knowledge
> of how to do it:-)
>
> Best regards,
>  Kerim                          mailto:warkid at hotbox.ru

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




From joel at boost-consulting.com  Tue Oct 21 19:10:22 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Wed, 22 Oct 2003 01:10:22 +0800
Subject: [C++-sig] Re: Duplicate "ignore"(again...) and more. (Latest CVS,
	VC .NET 2003)
References: <43176117328.20031017125113@hotbox.ru>
	<u7k2ya77h.fsf@boost-consulting.com>
Message-ID: <015801c397f6$39226410$64646464@godzilla>

David Abrahams <dave at boost-consulting.com> wrote:
> Kerim,
> 
> This report should probably go to the main Boost developers' list.  A
> small reproducible test case would also help a lot.
> 
> Thanks,
> Dave
> 
> 
> Kerim Borchaev <warkid at hotbox.ru> writes:
> 
>> Hello c++-sig,
>> 
>> As I get it VC7.1 also has this bug with anonymous namespace:

This is a known problem of the old tuples. The fix is to change:

namespace {
 detail::swallow_assign ignore;
}

To:

detail::swallow_assign const ignore = detail::swallow_assign();

To avoid linker errors. This is what I do in Fusion.

HTH,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



From nickm at sitius.com  Tue Oct 21 19:54:49 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Tue, 21 Oct 2003 13:54:49 -0400
Subject: [C++-sig] Pickling object from nested class
Message-ID: <3F9572E9.EB5D0AA7@sitius.com>

Hi,

I have class View with nested class Data  exported with BPL in module
objects.
When I try to pickle object of the nested class I get the following
PicklingError:

>>> dump(d,out)
Traceback (most recent call last):
  File "<console>", line 1, in ?
  File "D:\Python22\Lib\pickle.py", line 973, in dump
    Pickler(file, bin).dump(object)
  File "D:\Python22\Lib\pickle.py", line 115, in dump
    self.save(object)
  File "D:\Python22\Lib\pickle.py", line 219, in save
    self.save_reduce(callable, arg_tup, state)
  File "D:\Python22\Lib\pickle.py", line 244, in save_reduce
    save(callable)
  File "D:\Python22\Lib\pickle.py", line 171, in save
    self.save_global(object)
  File "D:\Python22\Lib\pickle.py", line 519, in save_global
    raise PicklingError(
PicklingError: Can't pickle <class 'objects.Data'>: it's not found as
objects.Data

This worked with native Python classes.
How can this be made to work?

Nikolay




From dave at boost-consulting.com  Tue Oct 21 19:52:33 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Oct 2003 13:52:33 -0400
Subject: [C++-sig] Re: Pickling object from nested class
References: <3F9572E9.EB5D0AA7@sitius.com>
Message-ID: <uwuay8om6.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> Hi,
>
> I have class View with nested class Data  exported with BPL in module
> objects.
> When I try to pickle object of the nested class I get the following
> PicklingError:
>
>>>> dump(d,out)
> Traceback (most recent call last):
>   File "<console>", line 1, in ?
>   File "D:\Python22\Lib\pickle.py", line 973, in dump
>     Pickler(file, bin).dump(object)
>   File "D:\Python22\Lib\pickle.py", line 115, in dump
>     self.save(object)
>   File "D:\Python22\Lib\pickle.py", line 219, in save
>     self.save_reduce(callable, arg_tup, state)
>   File "D:\Python22\Lib\pickle.py", line 244, in save_reduce
>     save(callable)
>   File "D:\Python22\Lib\pickle.py", line 171, in save
>     self.save_global(object)
>   File "D:\Python22\Lib\pickle.py", line 519, in save_global
>     raise PicklingError(
> PicklingError: Can't pickle <class 'objects.Data'>: it's not found as
> objects.Data
>
> This worked with native Python classes.
> How can this be made to work?

Reproducible example, please.

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




From s_sourceforge at nedprod.com  Tue Oct 21 21:53:07 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 21 Oct 2003 20:53:07 +0100
Subject: [C++-sig] The "return always existing pointer throws dangling
	error" problem
Message-ID: <3F959CB3.29629.92E171B@localhost>

Just run into this one myself whereby when querying a FXObject 
subclass for its metadata (a FXMetaClass) it throws "attempt to 
return dangling pointer". I've read Dave's comments at 
http://mail.python.org/pipermail/c++-sig/2003-August/005288.html & 
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1781761 and I 
was wondering, surely it is fairly trivial for BPL to know when a 
python object holding a reference to a C++ thing is holding it in a 
non-ownership way?

Let me clarify: From what I understand, most return policies destroy 
their associated C++ object instance when its python representation 
expires. Mostly that's a copy of the C++ object instance and when 
this is the case, the throwing of the error is correct.

However, if the object instance was allocated by new (and thus its 
policy was manage_new_object), then doesn't that strongly imply that 
the receiving object takes ownership of a newed pointer as well 
because the return policy setting is an artifact of how the C++ code 
works? Therefore in this situation auto_ptr style transference would 
be more useful.

return_internal_reference is also different - if you attach lifetime 
to self which most do, then when a virtual override in python returns 
an internal reference to either C++ or python code invoking that 
function, surely BPL is attaching the lifetime of the internal 
reference to the "self" instance and not to the temporary object 
created during call_method? Therefore surely the error is reporting 
the wrong thing dangling?

Lastly looking through the docs I encountered a thing called ptr<> 
which while it appears to help me in C++, if I were to subclass 
FXObject with my own class in python (whereupon I must provide my own 
custom FXMetaClass to describe it) I'd be smack bang right back into 
problem-land.

Thoughts? I appreciate that this has been addressed before, and that 
Dave who is uber-intelligent has said he's not sure about the correct 
solution. But I can't see how BPL doesn't know where one of its own 
pointer containers got its pointer from?

If I'm missing something tragically obvious, perhaps some sort of 
ownership policy might be needed?

Lastly, while the posts I referred to promise workarounds, I can't 
see any which don't involve altering the original C++. Can I 
explicitly disable the dangling pointer check? Though, ideally, I'd 
still want to always tie any returned FXMetaClass always to its 
associated FXObject.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031021/aacf5bbf/attachment.pgp>

From rwgk at yahoo.com  Tue Oct 21 22:33:05 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 21 Oct 2003 13:33:05 -0700 (PDT)
Subject: [C++-sig] Pickling object from nested class
In-Reply-To: <3F9572E9.EB5D0AA7@sitius.com>
Message-ID: <20031021203305.94469.qmail@web20204.mail.yahoo.com>

You don't mention the pickle suite. Are you aware of this?
http://www.boost.org/libs/python/doc/v2/pickle.html
David, this page isn't advertised very well. There are links only from the
class_ reference section and from the acknowledgement page. I think it would be
good to (re?)introduce a link at the front page. Later we could do something
like this:
- Suites
      - Indexing
      - Pickling
Ralf

--- Nikolay Mladenov <nickm at sitius.com> wrote:
> Hi,
> 
> I have class View with nested class Data  exported with BPL in module
> objects.
> When I try to pickle object of the nested class I get the following
> PicklingError:
> 
> >>> dump(d,out)
> Traceback (most recent call last):
>   File "<console>", line 1, in ?
>   File "D:\Python22\Lib\pickle.py", line 973, in dump
>     Pickler(file, bin).dump(object)
>   File "D:\Python22\Lib\pickle.py", line 115, in dump
>     self.save(object)
>   File "D:\Python22\Lib\pickle.py", line 219, in save
>     self.save_reduce(callable, arg_tup, state)
>   File "D:\Python22\Lib\pickle.py", line 244, in save_reduce
>     save(callable)
>   File "D:\Python22\Lib\pickle.py", line 171, in save
>     self.save_global(object)
>   File "D:\Python22\Lib\pickle.py", line 519, in save_global
>     raise PicklingError(
> PicklingError: Can't pickle <class 'objects.Data'>: it's not found as
> objects.Data
> 
> This worked with native Python classes.
> How can this be made to work?
> 
> Nikolay


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From dave at boost-consulting.com  Tue Oct 21 22:30:50 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Oct 2003 16:30:50 -0400
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
 error" problem
References: <3F959CB3.29629.92E171B@localhost>
Message-ID: <u4qy272px.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> Just run into this one myself whereby when querying a FXObject 
> subclass for its metadata (a FXMetaClass) it throws "attempt to 
> return dangling pointer". I've read Dave's comments at 
> http://mail.python.org/pipermail/c++-sig/2003-August/005288.html & 
> http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1781761 and I 
> was wondering, surely it is fairly trivial for BPL to know when a 
> python object holding a reference to a C++ thing is holding it in a 
> non-ownership way?
>
> Let me clarify: From what I understand, most return policies destroy 
> their associated C++ object instance when its python representation 
> expires. Mostly that's a copy of the C++ object instance and when 
> this is the case, the throwing of the error is correct.
>
> However, if the object instance was allocated by new (and thus its 
> policy was manage_new_object), 

Objects don't have call policies; those are associated with
methods/functions.

> then doesn't that strongly imply that the receiving object 
> takes ownership of a newed pointer as well

What do you mean by "receiving object?"  If you mean *this in some
member function:

       void X::f(Y*) {...}

where the Python Y object was created by returning a pointer with the
manage_new_object policy, then no it does not.  Objects held by
pointer or by value are equivalent from the Python side and you can
easily have both for objects of the same type.  If the "taking
ownership" behavior of called methods depended on how the source
object was held, reliability would be horribly compromised.

> because the return policy setting is an artifact of how the C++ code
> works? Therefore in this situation auto_ptr style transference would
> be more useful.

Whether or not auto_ptr-style transference is appropriate is a
property of the called function, not its parameters.  Sorry, if you
want that, make the function (or a thin wrapper) take an auto_ptr
parameter.

When Daniel and I finish the langbinding integration, all C++ objects,
even those *copied* into Python objects, will be held via a pointer to
dynamically-allocated memory so that ownership transfer semantics
will always be available (unless shared_ptr is used, I guess).
However, that will be selectable by a policy on the called function,
not as a function of how the argument is created.

> return_internal_reference is also different - if you attach lifetime 
> to self which most do, then when a virtual override in python returns 
> an internal reference 

?? huh ??
A virtual override in Python can only return a Python object.
There's no such thing as an "internal reference" in that context.

> to either C++ or python code invoking that function

When a virtual function overridden in Python is invoked from Python,
C++ and BPL are never involved.  The function is simply looked up and
called in the usual Python way.  When invoked from C++, the call
policies are never involved, since they only apply to wrapped C++
functions and a Python function is actually being called.

> surely BPL is attaching the lifetime of the internal reference to
> the "self" instance and not to the temporary object created during
> call_method?  Therefore surely the error is reporting the wrong
> thing dangling?

Given everything I've written above, what you're saying makes no
sense to me.

> Lastly looking through the docs I encountered a thing called ptr<> 
> which while it appears to help me in C++

How, and with what problem?

> if I were to subclass 
> FXObject with my own class in python (whereupon I must provide my own 
> custom FXMetaClass to describe it) I'd be smack bang right back into 
> problem-land.
>
> Thoughts? 

More details about your problem are needed.  My suggestion: for the
time-being, stop trying to second-guess the design of Boost.Python and
just describe what you're trying to do with a *minimal example*.  If
we can't come up with a good solution, then we can talk about design
changes.

> I appreciate that this has been addressed before, and that Dave who
> is <censored> has said he's not sure about the correct
> solution.  But I can't see how BPL doesn't know where one of its own
> pointer containers got its pointer from?

I'm not sure whether "where it came from" is relevant, but I guess
we'll see.

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




From dave at boost-consulting.com  Tue Oct 21 23:31:04 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Oct 2003 17:31:04 -0400
Subject: [C++-sig] Re: Pickling object from nested class
References: <3F9572E9.EB5D0AA7@sitius.com>
	<20031021203305.94469.qmail@web20204.mail.yahoo.com>
Message-ID: <ubrsa5ld3.fsf@boost-consulting.com>

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

> David, this page isn't advertised very well. There are links only
> from the class_ reference section and from the acknowledgement
> page. I think it would be good to (re?)introduce a link at the front
> page. Later we could do something like this:
>
> - Suites
>       - Indexing
>       - Pickling

Maybe we should do something like that right now?  Why don't you
check in a change and give me a heads-up so I can look at it?

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




From s_sourceforge at nedprod.com  Wed Oct 22 00:45:00 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 21 Oct 2003 23:45:00 +0100
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
	error" problem
In-Reply-To: <u4qy272px.fsf@boost-consulting.com>
Message-ID: <3F95C4FC.20365.9CB726E@localhost>

On 21 Oct 2003 at 16:30, David Abrahams wrote:

> > Let me clarify: From what I understand, most return policies destroy
> > their associated C++ object instance when its python representation
> > expires. Mostly that's a copy of the C++ object instance and when
> > this is the case, the throwing of the error is correct.
> >
> > However, if the object instance was allocated by new (and thus its
> > policy was manage_new_object), 
> 
> Objects don't have call policies; those are associated with
> methods/functions.

I had thought that when a function with a return policy returns 
object X, the lifetime ie; validity of X is tied to something else?

> > return_internal_reference is also different - if you attach lifetime
> > to self which most do, then when a virtual override in python
> > returns an internal reference 
> 
> ?? huh ??
> A virtual override in Python can only return a Python object.
> There's no such thing as an "internal reference" in that context.

So when there is a virtual MyObject *MyClass::foo() and my wrapper of 
MyClass overrides default foo() with one calling call_method<MyObject 
*>(self, "foo") then call_method is returning a python object?

How can that possibly be when foo() and all overrides of it must 
return MyObject * (with the exception of covariant returns)?

> > to either C++ or python code invoking that function
> 
> When a virtual function overridden in Python is invoked from Python,
> C++ and BPL are never involved.  The function is simply looked up and
> called in the usual Python way.  When invoked from C++, the call
> policies are never involved, since they only apply to wrapped C++
> functions and a Python function is actually being called.

So you're saying that the _class.def() part has absolutely zero 
relation to the call_method part? They are two bits of absolutely 
unrelated code?

If so, then wow. How could any transient objects created by 
call_method know their contents are destined for C++ world? Maybe 
that's actually the problem?

> > surely BPL is attaching the lifetime of the internal reference to
> > the "self" instance and not to the temporary object created during
> > call_method?  Therefore surely the error is reporting the wrong
> > thing dangling?
> 
> Given everything I've written above, what you're saying makes no
> sense to me.

Once again, I appear to misunderstand how BPL works :(

> More details about your problem are needed.  My suggestion: for the
> time-being, stop trying to second-guess the design of Boost.Python and
> just describe what you're trying to do with a *minimal example*.  If
> we can't come up with a good solution, then we can talk about design
> changes.

Done below.

> > I appreciate that this has been addressed before, and that Dave who
> > is <censored> has said he's not sure about the correct solution. 
> > But I can't see how BPL doesn't know where one of its own pointer
> > containers got its pointer from?

Err, the <censored> bit was saying a compliment, not anything 
negative in any way whatsoever - I was using a construct borrowed 
from German (consequence of being European). My apologies if you took 
offense at that.

Ok, my problem in condensed form (identical to the two problems as 
referenced in the initial post):

namespace FX {
class FXMetaClass;

class FXObject
{
public:
    static const FXMetaClass metaClass; // metadata for this subclass
    virtual const FXMetaClass *getMetaClass() const { return 
&metaClass; } // metadata for most derived subclass
};

class FXApp : public FXObject
{ ... };
};

struct FX_FXObject_Wrapper: FX::FXObject
{
    const FX::FXMetaClass* getMetaClass() const {
        return call_method< const FX::FXMetaClass* >(self, 
"getMetaClass");
    }

    const FX::FXMetaClass* default_getMetaClass() const {
        return FX::FXObject::getMetaClass();
    }
};

...
void Export_FXObject()
{
    class_< FX::FXObject, FX_FXObject_Wrapper >("FXObject", init<  
>())
        .def("getMetaClass", &FX::FXObject::getMetaClass, 
&FX_FXObject_Wrapper::default_getMetaClass, 
return_internal_reference< 1 >())
        ;
    class_< FX::FXMetaClass >("FXMetaClass", init< const 
FX::FXMetaClass& >())
    ...
}

And when you do in python:
a=FXApp()
a.init();

And in FXApp::init(), it queries its metadata:
FXMetaClass *mc=getMetaClass();

... BPL calls FX_FXObject_Wrapper::getMetaClass(), which calls 
python's self.getMetaClass() by call_method (except there isn't one 
and thus it calls the C++ default). However on return from 
call_method, it throws:

ReferenceError: Attempt to return dangling pointer to object of type: 
class FX::FXMetaClass

As I previously said, it's the identical problem as previous posts 
have had. However, in none of those previous posts did I see what a 
solution would be including permitting the python side to subclass 
FXApp say and provide its own custom FXMetaClass.

BTW, the code design of FXObject's and FXMetaClass' is all not mine, 
it is of the underlying GUI toolkit FOX.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031021/0cc5784e/attachment.pgp>

From dave at boost-consulting.com  Wed Oct 22 01:15:08 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Oct 2003 19:15:08 -0400
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
 error" problem
References: <u4qy272px.fsf@boost-consulting.com>
	<3F95C4FC.20365.9CB726E@localhost>
Message-ID: <ullre41z7.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 21 Oct 2003 at 16:30, David Abrahams wrote:
>
>> > Let me clarify: From what I understand, most return policies destroy
>> > their associated C++ object instance when its python representation
>> > expires. Mostly that's a copy of the C++ object instance and when
>> > this is the case, the throwing of the error is correct.
>> >
>> > However, if the object instance was allocated by new (and thus its
>> > policy was manage_new_object), 
>> 
>> Objects don't have call policies; those are associated with
>> methods/functions.
>
> I had thought that when a function with a return policy returns 
> object X, the lifetime ie; validity of X is tied to something else?

Sometimes, if that's what the policy says to do with it.  That doesn't
mean the policy is associated with the object.  In the case of
manage_new_object the resulting Python object holds the C++ object
with an auto_ptr, and all information about the policy is lost.  There
are other ways to get an identical Python object without using
manage_new_object.

>> > return_internal_reference is also different - if you attach
>> > lifetime to self which most do, then when a virtual override in
>> > python returns an internal reference
>> 
>> ?? huh ??
>> A virtual override in Python can only return a Python object.
>> There's no such thing as an "internal reference" in that context.
>
> So when there is a virtual MyObject *MyClass::foo() and my wrapper of 
> MyClass overrides default foo() with one calling call_method<MyObject 
> *>(self, "foo") then call_method is returning a python object?

No, call_method is clearly returning a MyObject*.  The "virtual
override in Python" is returning a Python object.

> How can that possibly be when foo() and all overrides of it must 
> return MyObject * (with the exception of covariant returns)?

Well, of course the Python function doesn't literally override the C++
one; you can't do that since the two languages don't (and couldn't)
have a common ABI.  The last actual override of the C++ virtual
function is the one you implement, which invokes call_method.  That,
in turn, looks up a Python method with the appropriate name and
invokes it.  The only way C++ gets involved again before call_method
picks up the resulting Python object and converts it to C++ is when
that Python method either happens to be a wrapped C++ function
(e.g. the default implementation of MyClass::foo forwarded from the
wrapper class), or when the Python method happens to call some
wrapped C++ function directly or indirectly.

>> > to either C++ or python code invoking that function
>> 
>> When a virtual function overridden in Python is invoked from Python,
>> C++ and BPL are never involved.  The function is simply looked up and
>> called in the usual Python way.  When invoked from C++, the call
>> policies are never involved, since they only apply to wrapped C++
>> functions and a Python function is actually being called.
>
> So you're saying that the _class.def() part has absolutely zero 
> relation to the call_method part? They are two bits of absolutely 
> unrelated code?

No, they have many relationships.  I'm not sure which kind of
relationship you have in mind, though.

> If so, then wow. How could any transient objects created by 
> call_method know their contents are destined for C++ world? 

They don't.

> Maybe that's actually the problem?

I have no idea yet.  Maybe when you post some *compilable*, *testable*
sample code I'll have some idea.

>> > surely BPL is attaching the lifetime of the internal reference to
>> > the "self" instance and not to the temporary object created during
>> > call_method?  Therefore surely the error is reporting the wrong
>> > thing dangling?
>> 
>> Given everything I've written above, what you're saying makes no
>> sense to me.
>
> Once again, I appear to misunderstand how BPL works :(
>
>> More details about your problem are needed.  My suggestion: for the
>> time-being, stop trying to second-guess the design of Boost.Python and
>> just describe what you're trying to do with a *minimal example*.  If
>> we can't come up with a good solution, then we can talk about design
>> changes.
>
> Done below.

I should've said "minimal but complete".

>> > I appreciate that this has been addressed before, and that Dave who
>> > is <censored> has said he's not sure about the correct solution. 
>> > But I can't see how BPL doesn't know where one of its own pointer
>> > containers got its pointer from?
>
> Err, the <censored> bit was saying a compliment, not anything 
> negative in any way whatsoever - I was using a construct borrowed 
> from German (consequence of being European). My apologies if you took 
> offense at that.

I didn't at all; I was just too embarrassed to quote you saying that
;->

>
> Ok, my problem in condensed form (identical to the two problems as 
> referenced in the initial post):

I'll be the judge of that... when you post a complete example.

> namespace FX {
> class FXMetaClass;
>
> class FXObject
> {
> public:
>     static const FXMetaClass metaClass; // metadata for this subclass
>     virtual const FXMetaClass *getMetaClass() const { return 
> &metaClass; } // metadata for most derived subclass
> };
>
> class FXApp : public FXObject
> { ... };
> };
>
> struct FX_FXObject_Wrapper: FX::FXObject
> {
>     const FX::FXMetaClass* getMetaClass() const {
>         return call_method< const FX::FXMetaClass* >(self, 
> "getMetaClass");
>     }
>
>     const FX::FXMetaClass* default_getMetaClass() const {
>         return FX::FXObject::getMetaClass();
>     }
> };
>
> ...
> void Export_FXObject()
> {
>     class_< FX::FXObject, FX_FXObject_Wrapper >("FXObject", init<  
>>())
>         .def("getMetaClass", &FX::FXObject::getMetaClass, 
> &FX_FXObject_Wrapper::default_getMetaClass, 
> return_internal_reference< 1 >())
>         ;
>     class_< FX::FXMetaClass >("FXMetaClass", init< const 
> FX::FXMetaClass& >())
>     ...
> }
>
> And when you do in python:
> a=FXApp()
  ^^^^^^^^^
You haven't even given me the code needed to make this line possible.
Please try to make it easy to help you.


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




From s_sourceforge at nedprod.com  Wed Oct 22 02:43:52 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 22 Oct 2003 01:43:52 +0100
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
	error" problem
In-Reply-To: <ullre41z7.fsf@boost-consulting.com>
Message-ID: <3F95E0D8.26085.A3844A6@localhost>

On 21 Oct 2003 at 19:15, David Abrahams wrote:

> > So you're saying that the _class.def() part has absolutely zero
> > relation to the call_method part? They are two bits of absolutely
> > unrelated code?
> 
> No, they have many relationships.  I'm not sure which kind of
> relationship you have in mind, though.

I'm just surprised, that's all. I personally wouldn't have done it 
the way you did, that's all. I had imagined that in the situation of 
C++ calling Python calling C++, some form of metadata would need to 
accompany the data obtained from C++ so you know you can throw away 
its temporarily constructed container as the data reenters the C++ 
world. Maybe, in fact, this is still what is needed.

> I should've said "minimal but complete".

I, like you, tend to assume the other person can infer the detail 
from cursory explanations we post as it's more efficient that way. 
However, you and I clearly don't think similarly - we view solutions 
in completely different fashions which are quite incompatible. I 
daresay that if we were working in a team, either we'd complement 
each other superbly or really really badly. It would be either 
extreme. Very interesting, and very uncommon - most people who don't 
understand me are technically inferior, whereas you most certainly 
are not.

> > Ok, my problem in condensed form (identical to the two problems as
> > referenced in the initial post):
> 
> I'll be the judge of that... when you post a complete example.

Sent to you personally as python.org rejects attachments I send (I 
said sourceforge in the email I sent you, I meant this particular 
mailing list)

> > And when you do in python:
> > a=FXApp()
>   ^^^^^^^^^
> You haven't even given me the code needed to make this line possible.
> Please try to make it easy to help you.

I am very appreciative of your help. I had assumed that once the 
blasted thing compiled, it would be out the door within days. It's 
becoming clear that won't be happening quite yet :(

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031022/e0309b89/attachment.pgp>

From rwgk at yahoo.com  Wed Oct 22 02:51:48 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 21 Oct 2003 17:51:48 -0700 (PDT)
Subject: [C++-sig] Re: Pickling object from nested class
In-Reply-To: <ubrsa5ld3.fsf@boost-consulting.com>
Message-ID: <20031022005148.21427.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > David, this page isn't advertised very well. There are links only
> > from the class_ reference section and from the acknowledgement
> > page. I think it would be good to (re?)introduce a link at the front
> > page. Later we could do something like this:
> >
> > - Suites
> >       - Indexing
> >       - Pickling
> 
> Maybe we should do something like that right now?  Why don't you
> check in a change and give me a heads-up so I can look at it?

I'll add this to my todo list until Raoul has merged the indexing_v2 branch
into the HEAD.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From dave at boost-consulting.com  Wed Oct 22 03:37:31 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Oct 2003 21:37:31 -0400
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
 error" problem
References: <ullre41z7.fsf@boost-consulting.com>
	<3F95E0D8.26085.A3844A6@localhost>
Message-ID: <u65iif3xg.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 21 Oct 2003 at 19:15, David Abrahams wrote:
>
>> > So you're saying that the _class.def() part has absolutely zero
>> > relation to the call_method part? They are two bits of absolutely
>> > unrelated code?
>> 
>> No, they have many relationships.  I'm not sure which kind of
>> relationship you have in mind, though.
>
> I'm just surprised, that's all. 

I haven't confirmed your thought about "zero relationship", so what is
there to be surprised about?  I don't know what you mean, and you
don't know what Boost.Python is doing AFAICT.

> I personally wouldn't have done it the way you did, that's all. 

How do you know what I did?

> I had imagined that in the situation of C++ calling Python calling
> C++, some form of metadata would need to accompany the data obtained
> from C++ so you know you can throw away its temporarily constructed
> container as the data reenters the C++ world. 

<sigh> Specifics and precision, please.  Guessing what you mean when
you say things like "the data obtained from C++" in a context where
data flows through the Python/C++ boundary twice in each direction is
interesting, but not very productive.

> Maybe, in fact, this is still what is needed.

Hard to say until we know what your problem is.

>> I should've said "minimal but complete".
>
> I, like you, tend to assume the other person can infer the detail 
> from cursory explanations we post as it's more efficient that way. 

It's more efficient for you and less efficient for me.  Since it's my
volunteer time, I'm asking you to do the work to make sure I don't
waste a lot of time trying to figure out what you need and going down
blind alleys.

> However, you and I clearly don't think similarly - we view solutions
> in completely different fashions which are quite incompatible. I
> daresay that if we were working in a team, either we'd complement
> each other superbly or really really badly. It would be either
> extreme. Very interesting, and very uncommon - most people who don't
> understand me are technically inferior, whereas you most certainly
> are not.

Especially in a two-language (C++/Python) world, there is so much
room for ambiguity that it can be very difficult to communicate.  I
request that you make an extra effort to give me everything I need to
help you and avoid misinterpretation.

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




From s_sourceforge at nedprod.com  Wed Oct 22 04:43:26 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 22 Oct 2003 03:43:26 +0100
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
	error" problem
In-Reply-To: <u65iif3xg.fsf@boost-consulting.com>
Message-ID: <3F95FCDE.5229.AA5BC54@localhost>

On 21 Oct 2003 at 21:37, David Abrahams wrote:

> >> No, they have many relationships.  I'm not sure which kind of
> >> relationship you have in mind, though.
> >
> > I'm just surprised, that's all. 
> 
> I haven't confirmed your thought about "zero relationship", so what is
> there to be surprised about?  I don't know what you mean, and you
> don't know what Boost.Python is doing AFAICT.

I based that statement on what you had previously described as the 
operatings of BPL, just there in what I replied to.

> > I personally wouldn't have done it the way you did, that's all. 
> 
> How do you know what I did?

That's what's so very interesting in our dialogues. You explain 
something because I didn't understand. I then read your explanation 
and either (a) make statements from what your explanation infers 
which turn out to be wrong or (b) apply your statements to what /you/ 
consider to be a completely different topic of conversation and 
again, I get it wrong.

This must result from you seeing everything in terms which subdivide 
& isolate neatly. I clearly not just consider each email I've sent 
and you've sent as an interrelated whole, but also in context of 
every email I've ever read you write both recently and across the 
archives to anyone else. That's very interesting.

> > I had imagined that in the situation of C++ calling Python calling
> > C++, some form of metadata would need to accompany the data obtained
> > from C++ so you know you can throw away its temporarily constructed
> > container as the data reenters the C++ world. 
> 
> <sigh> Specifics and precision, please.  Guessing what you mean when
> you say things like "the data obtained from C++" in a context where
> data flows through the Python/C++ boundary twice in each direction is
> interesting, but not very productive.

To me at least, it was extremely clear from across the three emails I 
have posted prior to stating that statement that "the data obtained 
from C++" was that which the python function (invoked by call_method 
which was invoked by a virtual function call) had obtained by calling 
C++.

To frame this in terms of the example I sent you, the python .def 
getMetaClass() must return a FXMetaClass in order to fufil its 
interface contract. That FXMetaClass is "the data obtained from C++" 
because python must call C++ to get one (since it's not a wholly 
python class). Therefore, C++ calls virtual C++ method 
getMetaClass(), virtual C++ method getMetaClass() calls python .def 
getMetaClass(), and it must return a FXMetaClass.

I really, really hope you know what I mean now?

> >> I should've said "minimal but complete".
> >
> > I, like you, tend to assume the other person can infer the detail
> > from cursory explanations we post as it's more efficient that way. 
> 
> It's more efficient for you and less efficient for me.  Since it's my
> volunteer time, I'm asking you to do the work to make sure I don't
> waste a lot of time trying to figure out what you need and going down
> blind alleys.

But you must acknowledge that you do it just as much as me. I know 
that when you explain something you think it's blatently clear. 
However, if you examine the archives of this list, it is very clear 
from the long threads that people just don't get it first time, or 
even second and third time.

Neither you nor I do this intentionally. I thought I was being 
incredibly precise and clear when I wrote what I did - I run through 
every email three times ensuring the logic is correct, references 
complete and that there are no contradictions - and of course that 
anyone could get the jist of the thread immediately by adding 
parenthesisised "leaders" to enhance mental pattern recognition.

> Especially in a two-language (C++/Python) world, there is so much room
> for ambiguity that it can be very difficult to communicate.  I request
> that you make an extra effort to give me everything I need to help you
> and avoid misinterpretation.

I have never been on a mailing list on all my years where I've had so 
much trouble making myself understood or understanding what is being 
said - and I know from political, religious and philosophy debates on 
non-technical lists plus live debating & toastmastering competitions 
plus my work as a politician that I am normally extraordinarily clear 
in my arguments. From a psychological POV, it is extremely 
interesting and I'd just love to start a research project into it.

I must emphasise that I am not saying that I am being clear and you 
are not. I can see a great deal of clarity and preciseness in 
everything you say and have said. In many ways that's what's so 
frustrating - you have much I would like to learn and are clearly an 
expert - but it's almost like a western geometry book and a chinese 
geometry book - same thing, but totally different ways of explaining 
and framing it (ie; the /context/ is different).

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031022/72cc0407/attachment.pgp>

From nico_ml at mgdesign.org  Wed Oct 22 12:03:26 2003
From: nico_ml at mgdesign.org (Nicolas LELONG)
Date: Wed, 22 Oct 2003 12:03:26 +0200
Subject: [C++-sig] CVS lagging : boost-consulting vs. sourceforge
References: <3F95FCDE.5229.AA5BC54@localhost>
Message-ID: <018801c39883$bd05fd90$cd00a8c0@nico>

Hi everyone,

for some time now, I've been using the boost-consulting CVS mirror for my
updates, as it seemed to me that the sourceforge CVS was suffering of
problems with anonymous accesses and was lagging.

This morning, I wanted to get the revision of 'object_core.hpp' including
the patch Dave created last week for the '
problem with scope().attr(xxx)'.

I'm quite annoyed to see that the boost-consulting CVS did not contain this
patch (rev 1.37) while the sourceforge CVS contained the patch (rev 1.38) !

Is there any general rule of thumb concerning the CVS to use these days ?!

Thanks,
Nicolas.




From dave at boost-consulting.com  Wed Oct 22 14:10:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 22 Oct 2003 08:10:00 -0400
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
 error" problem
References: <u65iif3xg.fsf@boost-consulting.com>
	<3F95FCDE.5229.AA5BC54@localhost>
Message-ID: <ufzhleanb.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 21 Oct 2003 at 21:37, David Abrahams wrote:
>
>> >> No, they have many relationships.  I'm not sure which kind of
>> >> relationship you have in mind, though.
>> >
>> > I'm just surprised, that's all. 
>> 
>> I haven't confirmed your thought about "zero relationship", so what is
>> there to be surprised about?  I don't know what you mean, and you
>> don't know what Boost.Python is doing AFAICT.
>
> I based that statement on what you had previously described as the 
> operatings of BPL, just there in what I replied to.
>
> That's what's so very interesting in our dialogues. 

I'm much less interested in the sociological aspects of this than you
are, but...

> You explain something because I didn't understand. I then read your
> explanation and either (a) make statements from what your
> explanation infers which turn out to be wrong or (b) apply your
> statements to what /you/ consider to be a completely different topic
> of conversation and again, I get it wrong.

...in *one* concession to your interest, and in the hope that you'll
reevaluate the way you're posting, I'll point out that I think your
analysis of is happening between us is much more complicated than it
needs to be.  A simpler analysis might yeild better results:

  You asked a question "are you saying they have absolutely zero
  relationship?", and then, regardless of the fact that I told you
  that they are very related, you told me you're surprised.
  Presumably, you're surprised to hear that "they have absolutely zero
  relationship", something I just got finished denying in terms that
  couldn't be plainer.  Unless my presumption about the reason for
  your surprise is wrong, you've simply failed to read or respond to
  what I actually wrote.

In any case, I'm done discussing our communication disconnect, and
I'm returning to technical issues for the remainder of this thread.

>> > I had imagined that in the situation of C++ calling Python calling
>> > C++, some form of metadata would need to accompany the data obtained
>> > from C++ so you know you can throw away its temporarily constructed
>> > container as the data reenters the C++ world. 
>> 
>> <sigh> Specifics and precision, please.  Guessing what you mean when
>> you say things like "the data obtained from C++" in a context where
>> data flows through the Python/C++ boundary twice in each direction is
>> interesting, but not very productive.
>
> To me at least, it was extremely clear from across the three emails I 
> have posted prior to stating that statement that "the data obtained 
> from C++" was that which the python function (invoked by call_method 
> which was invoked by a virtual function call) had obtained by calling 
> C++.
>
> To frame this in terms of the example I sent you, the python .def 
> getMetaClass() must return a FXMetaClass in order to fufil its 
> interface contract. That FXMetaClass is "the data obtained from C++" 
> because python must call C++ to get one (since it's not a wholly 
> python class). Therefore, C++ calls virtual C++ method 
> getMetaClass(), virtual C++ method getMetaClass() calls python .def 
> getMetaClass(), and it must return a FXMetaClass.
>
> I really, really hope you know what I mean now?

Close enough, I hope.  You said "C++ calling Python calling C++", but
the chain you just described starts with a Python call and ends with a
Python call.  I'm going to assume that "C++ calling Python calling
C++" begins after the word "Therefore" above and you left off the last
call in the chain, where the implementation of the Python getMetaClass
method which calls the C++ default implementation.

I've done some more thinking about this problem and I think I
understand how it should be solved.  By way of explanation, let me
show why I think the "metadata" approach isn't the best solution.  In
the example you sent me, as you surmised, the immediate problem is
that, at the there's no knowledge of the true ownership relationship
between the returned Python FXMetaClass object and the C++ object it
holds at the point where the Python result object must be converted to
C++ inside of call_method.

Even if you were to get past that problem, however, you'll have a
worse problem when you try to call its getClassName member function,
for a similar reason (**).  getClassName returns a char const*, so the
virtual function wrapper override invokes

  call_method<char const*>(...)

which invokes a Python wrapper function for the C++ default
implementation, which returns M's className member, a char const*.
This char const* must be converted into a Python string, and there's
simply no way for a Python string to hold its contents by reference:
they *will* be copied; that's out of my control.  Even if I could
attach metadata to the Python string describing its origin, it
wouldn't do any good (***).

Furthermore, the metadata approach, like the one the library currently
takes, misses an optimization opportunity, causing Boost.Python
virtual functions that *haven't* been overridden in Python to be much
slower than they could be.  IMO the best way to solve your problem is
to prevent any Python code at all from executing in the case where the
virtual function is not overridden in Python.  In other words, a C++
override which invokes call_method should first check to see if the
function's Python implementation has been overridden, and if not,
invoke the default implementation instead.

This actually has the potential to considerably simplify wrapper
class construction, as a separate default function implementation
wouldn't be needed.  It might look like:

  struct FX_FXApp_Wrapper
      : FX::FXApp, boost::python::dispatcher<FX::FXApp>
  {
      FX_FXApp_Wrapper(PyObject* self_):
          FX::FXApp(), boost::python::dispatcher<FX::FXApp>(self_) {}

      const FX::FXMetaClass* getMetaClass() const
      {
          if (method<const FX::FXMetaClass*> m = get_override("getMetaClass"))
              return m();
          else
              return FXapp::getMetaClass();
      }
  };


or even, possibly:

  struct FX_FXApp_Wrapper
      : boost::python::dispatcher<FX::FXApp>
  {
      FX_FXApp_Wrapper(PyObject* self_)
        : boost::python::dispatcher<FX::FXApp>(self_) {}

      const FX::FXMetaClass* getMetaClass() const
      {
          if (method m = get_override("getMetaClass"))
              return m();
          else
              return FXapp::getMetaClass();
      }
  };

None of this is to say that there's something wrong with the
"metadata" approach. My proposal isn't completely general - it doesn't
apply in cases where virtual function default implementations aren't
involved.  The metadata probably would be implemented with a virtual
function on Holder classes which would return true iff the lifetime of
the held C++ object was dependent on that of the Python object.

Sadly, I don't know when I'd have time to implement any of this; I'm
desperately trying not to fall behind on a book I'm writing.

(**) I'm assuming that in the interests of minimality, your example
leaves the "virtual" off of FXMetaclass::getClassName, but if I'm
wrong please just imagine that it is a virtual function for the sake
of argument -- it's certainly a common case to have virtual functions
returning char const*.

(***) yes, we might be able to build a subclass of Python's string
which contains an char const* pointing to the original characters in
addition to the copied characters, but that's a hack because the
original characters can go out-of-synch with the copied ones.

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




From dave at boost-consulting.com  Wed Oct 22 14:11:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 22 Oct 2003 08:11:52 -0400
Subject: [C++-sig] Re: CVS lagging : boost-consulting vs. sourceforge
References: <3F95FCDE.5229.AA5BC54@localhost>
	<018801c39883$bd05fd90$cd00a8c0@nico>
Message-ID: <uad7teak7.fsf@boost-consulting.com>

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

> Hi everyone,
>
> for some time now, I've been using the boost-consulting CVS mirror for my
> updates, as it seemed to me that the sourceforge CVS was suffering of
> problems with anonymous accesses and was lagging.
>
> This morning, I wanted to get the revision of 'object_core.hpp' including
> the patch Dave created last week for the '
> problem with scope().attr(xxx)'.
>
> I'm quite annoyed to see that the boost-consulting CVS did not contain this
> patch (rev 1.37) while the sourceforge CVS contained the patch (rev 1.38) !
>
> Is there any general rule of thumb concerning the CVS to use these days ?!

SF has been having trouble publishing usable CVS tarballs for us to
mirror, so we're lagging at the moment. They're also fixing their
anonymous CVS, so at some point SF will become the definitively
better option.  It may already have happened.

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




From nickm at sitius.com  Wed Oct 22 15:28:22 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Wed, 22 Oct 2003 09:28:22 -0400
Subject: [C++-sig] Re: Pickling object from nested class
References: <3F9572E9.EB5D0AA7@sitius.com> <uwuay8om6.fsf@boost-consulting.com>
Message-ID: <3F9685F6.C2158485@sitius.com>

Here it is:

cpp:

struct OBJ{
public :
    struct PROP{
        PROP(int i=0):p(i){}
        int p;
        operator int ()const{return p;}
    };
    OBJ(int p=0):prop(p){}
    PROP prop;
    operator int ()const{return prop.p;}
};

#include <boost/python.hpp>

using namespace boost::python;

template <class T>
struct pickle_suite_: pickle_suite
{
    static tuple getinitargs(const T &t){
        return make_tuple((int)t);
    }
};

BOOST_PYTHON_MODULE(inner)
{
    scope s(
        class_<OBJ>("OBJ", init<optional<int> >())
            .def_pickle(pickle_suite_<OBJ>())
        );
    class_<OBJ::PROP> ("PROP", init<optional<int> >())
        .def_pickle(pickle_suite_<OBJ::PROP>());
    
}
//////////////////////////////////////




py:

import inner
from sys import stdout as out
from pickle import dump
dump(inner.OBJ.PROP(),out)
#   ----------
#   stacktrace
#   ----------
#dump(inner.OBJ(), out) works fine




From nlelong at mgdesign.org  Wed Oct 22 18:13:51 2003
From: nlelong at mgdesign.org (Nicolas LELONG)
Date: Wed, 22 Oct 2003 18:13:51 +0200
Subject: [C++-sig] Re: CVS lagging : boost-consulting vs. sourceforge
References: <3F95FCDE.5229.AA5BC54@localhost><018801c39883$bd05fd90$cd00a8c0@nico>
	<uad7teak7.fsf@boost-consulting.com>
Message-ID: <04c101c398b7$842f10e0$cd00a8c0@nico>

> > Is there any general rule of thumb concerning the CVS to use these days
?!
>
> SF has been having trouble publishing usable CVS tarballs for us to
> mirror, so we're lagging at the moment. They're also fixing their
> anonymous CVS, so at some point SF will become the definitively
> better option.  It may already have happened.

OK, thanks , I take note and get ready to change my update scripts :)
Nicolas.




From s_sourceforge at nedprod.com  Wed Oct 22 20:05:54 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 22 Oct 2003 19:05:54 +0100
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
	error" problem
In-Reply-To: <ufzhleanb.fsf@boost-consulting.com>
Message-ID: <3F96D512.22275.DF248CC@localhost>

On 22 Oct 2003 at 8:10, David Abrahams wrote:

> In any case, I'm done discussing our communication disconnect, and I'm
> returning to technical issues for the remainder of this thread.

No problem, and thanks for indulging my off-topic interest in this 
matter. Someday I'll write a book on managing IT projects where I'll 
hopefully improve on "The Mythical Man Month".

> None of this is to say that there's something wrong with the
> "metadata" approach. My proposal isn't completely general - it doesn't
> apply in cases where virtual function default implementations aren't
> involved.  The metadata probably would be implemented with a virtual
> function on Holder classes which would return true iff the lifetime of
> the held C++ object was dependent on that of the Python object.

Interesting, and a source of ideas for my own solution.

> Sadly, I don't know when I'd have time to implement any of this; I'm
> desperately trying not to fall behind on a book I'm writing.

I'm thinking the best short-term stop-gap solution is an alternate 
call_method which basically disables the dangling pointer check. Then 
you can mark off functions in pyste which would fall foul of this 
particular problem on a case-by-case basis.

The:
       object self(handle<>(borrowed(m_self)));
       return extract<Foo*>(self.attr("f")());

... solution I previously mentioned is of course unsuitable because 
attr() cannot take parameters.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031022/28835640/attachment.pgp>

From dave at boost-consulting.com  Wed Oct 22 21:12:40 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 22 Oct 2003 15:12:40 -0400
Subject: [C++-sig] Re: The "return always existing pointer throws dangling
 error" problem
References: <ufzhleanb.fsf@boost-consulting.com>
	<3F96D512.22275.DF248CC@localhost>
Message-ID: <ullrd6q8n.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> The:
>        object self(handle<>(borrowed(m_self)));
>        return extract<Foo*>(self.attr("f")());
>
> ... solution I previously mentioned is of course unsuitable because 
> attr() cannot take parameters.

???

Of course it takes 1 parameter, as shown in your snippet above.

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




From RaoulGough at yahoo.co.uk  Thu Oct 23 13:56:24 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 23 Oct 2003 12:56:24 +0100
Subject: [C++-sig] Extension DLLs nonfunctioning with MSVC 7.1 (beta)
Message-ID: <uwuawf9qv.fsf@yahoo.co.uk>

When I build the Python tests with MSVC (7.1 beta, version 13.10.2292)
I get non-functioning DLLs. With a debug build, importing an extension
module into Python aborts silently, and with the release builds it
reports "ImportError: DLL load failed: Invalid access to memory
location." I'm reasonably sure this was working a couple of weeks ago.

I can report more details if necessary, but maybe somebody already has
experience with this happening? A sample link and test run follows
(lines manually wrapped). I'm using the indexing_v2 branch in
boost/python/suite/indexing and libs/python, and the CVS head
everywhere else. The problem occurs with the new indexing tests and
the existing tests I've tried as well (e.g. crossmod_exception.py).


D:\CVS\boost\boost\libs\python\test>..\..\..\tools\build\jam_src\
bin.ntx86.msvc\bjam -sTOOLS=vc7.1 -d2 -sBUILD="release" -sVC71_ROOT=
"D:\Program Files\Microsoft Visual Studio .NET 2003\VC7" test
...patience...
...found 3831 targets...
...updating 765 targets...

[snip]

"link"  /nologo /INCREMENTAL:NO  /DLL /subsystem:console
/out:"..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.pyd\
vc7.1\release\test_indexing_const_ext.pyd"
/IMPLIB:"..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.pyd\
vc7.1\release\test_indexing_const_ext.lib"
/LIBPATH:"f:\Python22\libs"
/LIBPATH:"..\..\..\bin\boost\libs\python\build\boost_python.dll\vc7.1\release"
/LIBPATH:"D:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib"
"python22.lib" "boost_python.lib"
@"..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.pyd
\vc7.1\release\test_indexing_const_ext.CMD"

Creating library ..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.
pyd\vc7.1\release\test_indexing_const_ext.lib and object ..\..\..\bin\boost\
libs\python\test\test_indexing_const_ext.pyd\vc7.1\release\
test_indexing_const_ext.exp
LINK : warning LNK4089: all references to 'dh.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00101.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00162.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00166.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00222.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00236.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00243.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00257.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00385.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00457.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00475.o' discarded by /OPT:REF
LINK : warning LNK4089: all references to 'ds00710.o' discarded by /OPT:REF

python-test-target ..\..\..\bin\boost\libs\python\test\
test_indexing_const.test\vc7.1\release\test_indexing_const.test

set PATH="f:\Python22\libs;..\..\..\bin\boost\libs\python\build\
boost_python.dll\vc7.1\release;..\..\..\bin\boost\libs\python\test\
test_indexing_const_ext.pyd\vc7.1\release;";%PATH%

    set PYTHONPATH=f:\Python22\libs;..\..\..\bin\boost\libs\python\
build\boost_python.dll\vc7.1\release;..\..\..\bin\boost\libs\python\
test\test_indexing_const_ext.pyd\vc7.1\release;..\..\..\libs\python\test;;

     "f:/Python22\python.exe"   "test_indexing_const.py"

running...
*****************************************************************
Failure in example: from test_indexing_const_ext import *
from line #0 of __main__
Exception raised:
Traceback (most recent call last):
  File "f:\Python22\lib\doctest.py", line 430, in _run_examples_inner
    compileflags, 1) in globs
  File "<string>", line 1, in ?
ImportError: DLL load failed: Invalid access to memory location.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Thu Oct 23 15:39:42 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 23 Oct 2003 09:39:42 -0400
Subject: [C++-sig] Re: Extension DLLs nonfunctioning with MSVC 7.1 (beta)
References: <uwuawf9qv.fsf@yahoo.co.uk>
Message-ID: <uk76w3wf5.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> When I build the Python tests with MSVC (7.1 beta, version 13.10.2292)
> I get non-functioning DLLs. With a debug build, importing an extension
> module into Python aborts silently, and with the release builds it
> reports "ImportError: DLL load failed: Invalid access to memory
> location." I'm reasonably sure this was working a couple of weeks ago.
>
> I can report more details if necessary, but maybe somebody already has
> experience with this happening? A sample link and test run follows
> (lines manually wrapped). I'm using the indexing_v2 branch in
> boost/python/suite/indexing and libs/python, and the CVS head
> everywhere else. The problem occurs with the new indexing tests and
> the existing tests I've tried as well (e.g. crossmod_exception.py).


It's working for me with vc7.1 release and a debug-python build:

cd c:/boost/libs/python/test/
myjam -sTOOLS=vc7.1 -sBUILD=debug-python test
...patience...
...found 3623 targets...
...updating 304 targets...
...
vc-Link c:\build\bin\boost\libs\python\test\embedding.test\vc7.1\debug-python\embedding.exe
   Creating library c:\build\bin\boost\libs\python\test\embedding.test\vc7.1\debug-python\embedding.lib and object c:\build\bin\boost\libs\python\test\embedding.test\vc7.1\debug-python\embedding.exp
execute-test c:\build\bin\boost\libs\python\test\embedding.test\vc7.1\debug-python\embedding.run
        1 file(s) copied.
**passed** c:\build\bin\boost\libs\python\test\embedding.test\vc7.1\debug-python\embedding.test
vc-C++ c:\build\bin\boost\libs\python\test\crossmod_exception_a.pyd\vc7.1\debug-python\crossmod_exception_a.obj
crossmod_exception_a.cpp
vc-Link c:\build\bin\boost\libs\python\test\crossmod_exception_a.pyd\vc7.1\debug-python\crossmod_exception_a_d.pyd c:\build\bin\boost\libs\python\test\crossmod_exception_a.pyd\vc7.1\debug-python\crossmod_exception_a.lib
   Creating library c:\build\bin\boost\libs\python\test\crossmod_exception_a.pyd\vc7.1\debug-python\crossmod_exception_a.lib and object c:\build\bin\boost\libs\python\test\crossmod_exception_a.pyd\vc7.1\debug-python\crossmod_exception_a.exp
vc-C++ c:\build\bin\boost\libs\python\test\crossmod_exception_b.pyd\vc7.1\debug-python\crossmod_exception_b.obj
crossmod_exception_b.cpp
vc-Link c:\build\bin\boost\libs\python\test\crossmod_exception_b.pyd\vc7.1\debug-python\crossmod_exception_b_d.pyd c:\build\bin\boost\libs\python\test\crossmod_exception_b.pyd\vc7.1\debug-python\crossmod_exception_b.lib
   Creating library c:\build\bin\boost\libs\python\test\crossmod_exception_b.pyd\vc7.1\debug-python\crossmod_exception_b.lib and object c:\build\bin\boost\libs\python\test\crossmod_exception_b.pyd\vc7.1\debug-python\crossmod_exception_b.exp
python-test-target c:\build\bin\boost\libs\python\test\crossmod_exception.test\vc7.1\debug-python\crossmod_exception.test
running...
Done.
[5420 refs]
...

I'm testing the release build now, but I expect similar results.

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




From s_sourceforge at nedprod.com  Thu Oct 23 19:53:55 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 23 Oct 2003 18:53:55 +0100
Subject: [C++-sig] Extension DLLs nonfunctioning with MSVC 7.1 (beta)
In-Reply-To: <uwuawf9qv.fsf@yahoo.co.uk>
Message-ID: <3F9823C3.2998.130DADDA@localhost>

On 23 Oct 2003 at 12:56, Raoul Gough wrote:

> When I build the Python tests with MSVC (7.1 beta, version 13.10.2292)
> I get non-functioning DLLs. With a debug build, importing an extension
> module into Python aborts silently, and with the release builds it
> reports "ImportError: DLL load failed: Invalid access to memory
> location." I'm reasonably sure this was working a couple of weeks ago.
> 
> I can report more details if necessary, but maybe somebody already has
> experience with this happening? A sample link and test run follows
> (lines manually wrapped). I'm using the indexing_v2 branch in
> boost/python/suite/indexing and libs/python, and the CVS head
> everywhere else. The problem occurs with the new indexing tests and
> the existing tests I've tried as well (e.g. crossmod_exception.py).

I can tell you it works here fine too, though I have a CVS version 
from about two weeks ago and I have BPL as a static library. And my 
wrappers are so big they break MSVC if you include any debug info at 
all!

Try enabling kernel loader snaps - these will tell you where it's 
faulting. Find an article on MSDN by Matt Pietrek - ignore all that 
modern crap in MSDN, it's a 1996 or thereabouts article which 
typically MS have expunged from the latest MSDN's with MSVC7.1 :(

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031023/e98b61a6/attachment.pgp>

From RaoulGough at yahoo.co.uk  Thu Oct 23 20:40:02 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 23 Oct 2003 19:40:02 +0100
Subject: [C++-sig] Re: Extension DLLs nonfunctioning with MSVC 7.1 (beta)
References: <uwuawf9qv.fsf@yahoo.co.uk> <uk76w3wf5.fsf@boost-consulting.com>
Message-ID: <usmljg5ml.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> When I build the Python tests with MSVC (7.1 beta, version 13.10.2292)
>> I get non-functioning DLLs. With a debug build, importing an extension
>> module into Python aborts silently, and with the release builds it
>> reports "ImportError: DLL load failed: Invalid access to memory
>> location." I'm reasonably sure this was working a couple of weeks ago.
[snip]
> It's working for me with vc7.1 release and a debug-python build:
[snip]

Niall Douglas also reports that it works for him. I guess I must have
trashed something in my environment, so I'll have to track it down
locally. Thanks to you both for confirming this.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From nicodemus at esss.com.br  Fri Oct 24 00:27:59 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Thu, 23 Oct 2003 19:27:59 -0300
Subject: [C++-sig] Pyste bug: const data not made read only
In-Reply-To: <3F941E28.30272.357C7E5@localhost>
References: <3F941E28.30272.357C7E5@localhost>
Message-ID: <3F9855EF.4010701@esss.com.br>

Hi Niall, sorry about the delay (I was out of town),

Niall Douglas wrote:

>In a class which has:
>
>static const type variable;
>
>... pyste is outputting def_readwrite() where it should be outputting 
>def_readonly(). The def_readwrite() fails to compile (correctly) and 
>so until changed public data members like this are a problem.
>

Can you post a reproductible case? I tried to reproduce this bug, 
however the generated code seems correct:

struct A
{
    static const int variable;
};

Generates:

    class_< A >("A", init<  >())
        .def(init< const A& >())
        .def_readonly("variable", &A::variable)
    ;

Regards,
Nicodemus.




From mike at nospam.com  Fri Oct 24 00:34:59 2003
From: mike at nospam.com (Mike Rovner)
Date: Thu, 23 Oct 2003 15:34:59 -0700
Subject: [C++-sig] fat class decoration
Message-ID: <bn9l2k$rug$1@sea.gmane.org>

Hi,

I solicit a criticism and possible better solutions to the following
problem.

I have a nonmodifyable C++ class

class T
{
   public:
     Color* getColor(const char* name);
     void     setColor(const char* name, const Color* value);

     Line*  getLine(const char* name);
     void     setLine(const char* name, const Line* value);

     //and so on
};
with a bunch of classes Color, Line, etc.

I want pretend in Python interface that T has bunch of attributes 'color',
'line', etc.
that behave like mappings each, i.e. I want to be able to say in Python:

t=T()
t.color["a"]=Color(...)
print t.line["b"]

For that purpose I created helper classes and generator functions

class TColorHelper
{
    T& _t;
public:
    TColorHelper(T& t) : _t(t) {}
    Color* get(const char* name) { return _t.getColor(name); }
    void     set(const char* name, const Color* value)
{_t.setColor(name,value);}
};
TColorHelper color(T& t) { return TColorHelper(t); }

class TLineHelper {...}; line(){...} //and so on for each property

wrap them:

 class_<TColorHelper>("TColorHelper", no_init)
  .def("__getitem__", &TColorHelper::get, return_internal_ref<>())
  .def("__setitem__", &TColorHelper::set)
  ;
//...
class_<T>("T")
  .add_property("color", color)
  .add_property("line", line)
  ;

which works fairly well.

So what do think about it?
Maybe you have had similar problem and solved it differently.
I appreciate your comments.

Thanks,
Mike






From nicodemus at esss.com.br  Fri Oct 24 01:39:00 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Thu, 23 Oct 2003 20:39:00 -0300
Subject: [C++-sig] Re: Pyste bug: Fails to pull in inherited members
In-Reply-To: <3F90DCB6.16849.31441DA9@localhost>
References: <3F90DCB6.16849.31441DA9@localhost>
Message-ID: <3F986694.5060003@esss.com.br>

Hi Niall,

Niall Douglas wrote:

>On 18 Oct 2003 at 3:49, c++-sig at python.org wrote:
>
>  
>
>>I have absolutely no idea why, but when you feed all the pyste files
>>to pyste at once it fails to wrap inherited members for my FXIODeviceS
>>class, the ones it inherited from FXIODevice.
>>
>>But when you pass FXIODeviceS.pyste on its own, it works fine. Very
>>odd.
>>
>>I'm afraid I've not been able to localise this one Bruno, so I'm
>>guessing the only choice is to download v0.4 when it's released in the
>>next week or so and work with that. Sorry about that.
>>    
>>
>
>Scratch that, I've found it!
>
>In FXIODevice, I have the following:
>
>virtual FXuval readBlock(char *data, FXuval maxlen)=0;
>
>and its convenience overload:
>
>FXuval readBlock(FXuchar *data, FXuval maxlen) { return 
>readBlock((char *) data, maxlen); }
>
>FXIODeviceS inherits from FXIODevice and pyste generates for it 
>(IODeviceS):
>
>        .def("readBlock", pure_virtual(&FX::FXIODevice::readBlock))
>
>This is ambiguous. It should be:
>
>        .def("readBlock", pure_virtual((long unsigned int 
>(FX::FXIODevice::*)(char*, long unsigned int) 
>)&FX::FXIODevice::readBlock))
>
>... which is what pyste generates for FXIODevice.
>
>I'm guessing pyste is somehow not noticing the base class overloads 
>despite the use of Import()?
>
>BTW, it was erratic before because sometimes IODevice was defined 
>before IODeviceS, other times not.
>

I couldn't reproduce this example either. 8(
However I did find that bug you mentioned about Pyste generating several 
class_ for the same class, and I've commited a fix.

Thanks,
Nicodemus.




From nicodemus at esss.com.br  Fri Oct 24 02:01:22 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Thu, 23 Oct 2003 21:01:22 -0300
Subject: [C++-sig] Enumerating items in pyste
In-Reply-To: <3F90A2DB.26708.30621C3D@localhost>
References: <3F90A2DB.26708.30621C3D@localhost>
Message-ID: <3F986BD2.6010508@esss.com.br>

Niall Douglas wrote:

>When I go:
>
>cclass=Class('MyClassB', 'myinclude.h')
>
>... and myinclude.h contains two class definitions (MyClassB and 
>MyClassA), I notice that pyste sets the one you asked for as the 
>default so cclass refers to cclass.MyClassB. However, cclass.MyClassA 
>is still available.
>
>Pushing past this, does Class() merely extract classes from the 
>header file and nothing else? What about enums? And how can I 
>enumerate cclass eg;
>
>classes=Class('MyClassB', 'myinclude.h')
>for cclass in classes.contents():
>    execfile('Policies/'+cclass.name()+'.py')
>    eval(cclass.name()+'.apply()')
>  
>

Pyste doesn't support this yet. The actual parsing is done later, so at 
the point where the Pyste file is being executed, it doesn't know about 
the members of the class MyClassB. 8/
I intend to support what you want, but not in the near future.

Regards,
Nicodemus.




From alellem at uwaterloo.ca  Fri Oct 24 01:58:49 2003
From: alellem at uwaterloo.ca (Andrew Ellem)
Date: Thu, 23 Oct 2003 19:58:49 -0400
Subject: [C++-sig] Exporting STL List to Python
Message-ID: <000001c399c1$9b1e54e0$0600a8c0@bender>


I'm trying to export a STL list to Python, but I'm having problems
when the list type is a pointer.  So, list<int> works, but list<int *>
causes the error:
TypeError: No to_python (by-value) converter found for C++ type: int *

Is there something special I have to do with pointers?

I've attached my sample program (which works as expected if the int*
list is changed to int).

Thanks,
Andrew Ellem


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

From mike at nospam.com  Fri Oct 24 02:25:24 2003
From: mike at nospam.com (Mike Rovner)
Date: Thu, 23 Oct 2003 17:25:24 -0700
Subject: [C++-sig] Re: Exporting STL List to Python
References: <000001c399c1$9b1e54e0$0600a8c0@bender>
Message-ID: <bn9rhk$6r0$1@sea.gmane.org>

Andrew Ellem wrote:
>> I'm trying to export a STL list to Python, but I'm having problems
>> when the list type is a pointer.  So, list<int> works, but list<int
>> *> causes the error:
>> TypeError: No to_python (by-value) converter found for C++ type: int*

Pointer is a foreign concept for Python, so you need help the BPL a little
bit.
Numbers in Python are immutable, unlike the int*, so bpl doesn't know enough
about your intents.

>> Is there something special I have to do with pointers?

Yes.  Generally you have to specify return_value_policy when returning a
pointer
to tell bpl how to handle it. See docs about it.

Answer the questions:
- who manages the memory,
- is that pointer an lvalue,
- how pointers shall be (if ever) copyed
to start with.

Try create your own type

struct IntP { int* pi; };

wrap it and see what happened.

HTH,
Mike






From nickm at sitius.com  Fri Oct 24 18:02:34 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 24 Oct 2003 12:02:34 -0400
Subject: [C++-sig] Re: Pickling object from nested class
References: <3F9572E9.EB5D0AA7@sitius.com> <uwuay8om6.fsf@boost-consulting.com>
	<3F9685F6.C2158485@sitius.com>
Message-ID: <3F994D1A.5643819F@sitius.com>

Ralf, Dave, help!




From s_sourceforge at nedprod.com  Fri Oct 24 04:21:00 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 24 Oct 2003 03:21:00 +0100
Subject: [C++-sig] Setting policies on overloads in pyste
Message-ID: <3F989A9C.17414.14DDEA46@localhost>

Any idea when the solution of making multiple functions with the same 
name a list and therefore individually addressable?

My current solution of applying a large GNU patch file every time I 
generate wrappings is getting painful (stupid thing is increasingly 
rejecting patches) :(

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031024/a78883f3/attachment.pgp>

From dave at boost-consulting.com  Fri Oct 24 19:17:34 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 24 Oct 2003 13:17:34 -0400
Subject: [C++-sig] Re: Pickling object from nested class
References: <3F9572E9.EB5D0AA7@sitius.com> <uwuay8om6.fsf@boost-consulting.com>
	<3F9685F6.C2158485@sitius.com> <3F994D1A.5643819F@sitius.com>
Message-ID: <uk76usggh.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> Ralf, Dave, help!

I'm packing for the C++ committee meeting and can't do much for a few
days.

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




From rwgk at yahoo.com  Fri Oct 24 20:16:53 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 24 Oct 2003 11:16:53 -0700 (PDT)
Subject: [C++-sig] Re: Pickling object from nested class
In-Reply-To: <3F9685F6.C2158485@sitius.com>
Message-ID: <20031024181653.46765.qmail@web20204.mail.yahoo.com>

Hi Nikolay,

I thought you can only pickle objects of top-level classes:

http://www.python.org/doc/current/lib/node64.html

> The following types can be pickled:
>   ...
>   - classes that are defined at the top level of a module

% cat outer_inner.py 
class outer:

  class inner:
    pass

% cat pickle_inner.py
import outer_inner
import pickle

i = outer_inner.outer.inner()
s = pickle.dumps(i)
j = pickle.loads(s)

% python pickle_inner.py
Traceback (most recent call last):
  File "pickle_inner.py", line 6, in ?
    j = pickle.loads(s)
  File "/usr/lib/python2.2/pickle.py", line 985, in loads
    return Unpickler(file).load()
  File "/usr/lib/python2.2/pickle.py", line 596, in load
    dispatch[key](self)
  File "/usr/lib/python2.2/pickle.py", line 766, in load_inst
    klass = self.find_class(module, name)
  File "/usr/lib/python2.2/pickle.py", line 823, in find_class
    klass = getattr(mod, name)
AttributeError: 'module' object has no attribute 'inner'

I cannot explain why this fails only at pickle.loads() while your example seems
to fail already at the dump stage. But anyway, I'd not expect pickling of
nested classes to work.

I'd try wrapping outer.inner as outer_inner:

% cat outer_inner.py
class outer_inner:
  pass

class outer:

  inner = outer_inner

This makes my little example work.

Ralf
 
--- Nikolay Mladenov <nickm at sitius.com> wrote:
> Here it is:
> 
> cpp:
> 
> struct OBJ{
> public :
>     struct PROP{
>         PROP(int i=0):p(i){}
>         int p;
>         operator int ()const{return p;}
>     };
>     OBJ(int p=0):prop(p){}
>     PROP prop;
>     operator int ()const{return prop.p;}
> };
> 
> #include <boost/python.hpp>
> 
> using namespace boost::python;
> 
> template <class T>
> struct pickle_suite_: pickle_suite
> {
>     static tuple getinitargs(const T &t){
>         return make_tuple((int)t);
>     }
> };
> 
> BOOST_PYTHON_MODULE(inner)
> {
>     scope s(
>         class_<OBJ>("OBJ", init<optional<int> >())
>             .def_pickle(pickle_suite_<OBJ>())
>         );
>     class_<OBJ::PROP> ("PROP", init<optional<int> >())
>         .def_pickle(pickle_suite_<OBJ::PROP>());
>     
> }
> //////////////////////////////////////
> 
> 
> 
> 
> py:
> 
> import inner
> from sys import stdout as out
> from pickle import dump
> dump(inner.OBJ.PROP(),out)
> #   ----------
> #   stacktrace
> #   ----------
> #dump(inner.OBJ(), out) works fine


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From llywelyn.geo at yahoo.com  Fri Oct 24 23:02:27 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Fri, 24 Oct 2003 14:02:27 -0700
Subject: [C++-sig] Extracting C++ objects: documentation example fails.
Message-ID: <bnc413$m7o$1@sea.gmane.org>

Hi there,

I'm trying to extract some wrapped objects from a python script in C++.
I've tried running the example from the docs to see how extract works, but
it wont compile:

struct X
{
   X(int x) : v(x) {}
   int value() { return v; }
 private:
   int v;
};

foo()
{
    object x_class(
       class_<X>("X", init<int>())
          .def("value", &X::value))
          ;

    // Instantiate an X object through the Python interface.
    // Its lifetime is now managed by x_obj.
    object x_obj = x_class(3);

    // Get a reference to the C++ object out of the Python object
    X& x = extract<X&>(x_obj);
    assert(x.value() == 3);
}

I keep getting this error:

d:\dev\samples\python\pythonlibtest\main.cpp(91): error C2440:
'initializing' : cannot convert from 'boost::python::extract<T>' to 'X &'
        with
        [
            T=X &
        ]


I'm using VC 7.  Is there something separate that I have to do to get this
example to compile?

Thanks,
Joel






From llywelyn.geo at yahoo.com  Fri Oct 24 23:37:33 2003
From: llywelyn.geo at yahoo.com (Joel Gerard)
Date: Fri, 24 Oct 2003 14:37:33 -0700 (PDT)
Subject: [C++-sig] Extracting C++ objects: documentation example fails.
In-Reply-To: <bnc413$m7o$1@sea.gmane.org>
Message-ID: <20031024213733.19326.qmail@web41506.mail.yahoo.com>

Nevermind. I've seen the answer in a different post.

http://mail.python.org/pipermail/c++-sig/2003-September/005510.html

I think the documentation could benefit from this piece of information though.  It seems unusual
to me that ANSI C++ leaves the () off. Really?  It seems more logical that they appear.

Joel

--- Joel Gerard <llywelyn.geo at yahoo.com> wrote:
> Hi there,
> 
> I'm trying to extract some wrapped objects from a python script in C++.
> I've tried running the example from the docs to see how extract works, but
> it wont compile:
> 
> struct X
> {
>    X(int x) : v(x) {}
>    int value() { return v; }
>  private:
>    int v;
> };
> 
> foo()
> {
>     object x_class(
>        class_<X>("X", init<int>())
>           .def("value", &X::value))
>           ;
> 
>     // Instantiate an X object through the Python interface.
>     // Its lifetime is now managed by x_obj.
>     object x_obj = x_class(3);
> 
>     // Get a reference to the C++ object out of the Python object
>     X& x = extract<X&>(x_obj);
>     assert(x.value() == 3);
> }
> 
> I keep getting this error:
> 
> d:\dev\samples\python\pythonlibtest\main.cpp(91): error C2440:
> 'initializing' : cannot convert from 'boost::python::extract<T>' to 'X &'
>         with
>         [
>             T=X &
>         ]
> 
> 
> I'm using VC 7.  Is there something separate that I have to do to get this
> example to compile?
> 
> Thanks,
> Joel
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


=====


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From mike at nospam.com  Sat Oct 25 00:33:51 2003
From: mike at nospam.com (Mike Rovner)
Date: Fri, 24 Oct 2003 15:33:51 -0700
Subject: [C++-sig] Re: Extracting C++ objects: documentation example fails.
References: <bnc413$m7o$1@sea.gmane.org>
Message-ID: <bnc9ce$kuv$1@sea.gmane.org>

Joel Gerard wrote:

> I'm trying to extract some wrapped objects from a python script in
> C++. I've tried running the example from the docs to see how extract
> works, but it wont compile:
>
> struct X
> {
>    X(int x) : v(x) {}
>    int value() { return v; }
>  private:
>    int v;
> };
>
> foo()
> {
>     object x_class(
>        class_<X>("X", init<int>())
>           .def("value", &X::value))
>           ;
>
>     // Instantiate an X object through the Python interface.
>     // Its lifetime is now managed by x_obj.
>     object x_obj = x_class(3);
>
>     // Get a reference to the C++ object out of the Python object
>     X& x = extract<X&>(x_obj);
>     assert(x.value() == 3);

Extract means smthng different, e.g. extracting a value

      int x = extract<int>(x.obj.attr("value"));

> I'm using VC 7.

Don't! Use VC7.1

HTH,
Mike






From s_sourceforge at nedprod.com  Sat Oct 25 03:45:55 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 25 Oct 2003 02:45:55 +0100
Subject: [C++-sig] Re: Pyste bug: Fails to pull in inherited members
In-Reply-To: <3F986694.5060003@esss.com.br>
References: <3F90DCB6.16849.31441DA9@localhost>
Message-ID: <3F99E3E3.1694.19E42869@localhost>

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

Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

On 23 Oct 2003 at 20:39, Nicodemus wrote:

> I couldn't reproduce this example either. 8(
> However I did find that bug you mentioned about Pyste generating
> several class_ for the same class, and I've commited a fix.

I'll get onto this shortly (both of them). Currently preparing house 
for guests - lots of scrubbing of toilets and cleaning and stuff for 
the next few days.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP5nV08EcvDLFGKbPEQLj6wCgmJlqJHI/TnP7O4WlU0qa1bgnCmUAoJeI
tHVtmjqL8wvLpXQj8GquB3YP
=h6kG
-----END PGP SIGNATURE-----



From rwgk at yahoo.com  Sat Oct 25 16:06:20 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 25 Oct 2003 07:06:20 -0700 (PDT)
Subject: [C++-sig] container suite feedback & ideas
Message-ID: <20031025140620.54583.qmail@web20206.mail.yahoo.com>

Hi Raoul,

Using your documentation I've had no problems wrapping three custom
linear array types with your container suite. Just a couple of minor
remarks:

static boost::python::indexing::IndexStyle const index_style
                                ^

typedef std::map<std::string, int> Container;
                                   ^

typedef indexing::map_algorithms<simple_map_traits> Algorithms;
                                                    ^

I believe according to the boost naming conventions these identifiers
must be all lower case. But I am not really an authority in this
matter. David?

> #include "algo_selector.hpp"
> #include "visitor.hpp"

Should probably be #include <boost/...>. It wasn't clear to me
what I had to include. Eventually just including

#include <boost/python/suite/indexing/container_suite.hpp>

worked for my purposes. Is this what I should be doing?
Should this be added to <boost/python.hpp>?

There are two important features I am wondering about:

1. Just doing this

   class_<my_container>("my_container")
     .def(indexing::container_suite<my_container, my_algorithms>())
   ;

   doesn't enable me to initialize the instances with Python
   lists or tuples. Have you thought about this already?
   My first idea would be to define custom rvalue converters from
   Python sequences to the wrapped container type
   (http://www.boost.org/libs/python/doc/v2/faq.html#question2).
   Then one could pass a Python sequence anywhere the wrapped container
   is used as a const& or by-value argument. Simply define Python
   bindings for the C++ copy constructor to enable initialization with
   Python sequences.

2. Pickling of the wrapped types. This is a big issue but I find
   it absolutely essential. I have a fairly general solution
   that I'd be happy to share and extend if there is an interest.
   If you are curious, it is a three-layer system:
   The low-level serialization code for built-in types is here:
    
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/serialization/
   This is designed to maximize portability but is also very fast.
   The second layer is here:
    
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/
   pickle_single_buffered.h and pickle_double_buffered.h.
   A top layer for a particular array type is here:
    
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/
   flex_pickle_single_buffered.h, flex_pickle_double_buffered.h.
   The system also works for user-defined types (the user has
   to supply some code).
   Adapting this system for the container suite would probably
   require significant changes only to the top layer.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



From s_sourceforge at nedprod.com  Sun Oct 26 05:26:15 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 26 Oct 2003 04:26:15 -0000
Subject: [C++-sig] Re: The "return always existing pointer throws
	dangling	error" problem
In-Reply-To: <3F96D512.22275.DF248CC@localhost>
References: <ufzhleanb.fsf@boost-consulting.com>
Message-ID: <3F9B4CE7.10502.1F9D4DAE@localhost>

On 22 Oct 2003 at 19:05, Niall Douglas wrote:

> I'm thinking the best short-term stop-gap solution is an alternate
> call_method which basically disables the dangling pointer check. Then
> you can mark off functions in pyste which would fall foul of this
> particular problem on a case-by-case basis.

Just for reference for anyone searching the archives for a solution 
to this problem, mine was to add the following to call_method.hpp:

template <
    class R
    BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, class A)
    >
typename detail::returnable<R>::type
call_method2(PyObject* self, char const* name
    BOOST_PP_COMMA_IF(N) BOOST_PP_ENUM_BINARY_PARAMS_Z(1, N, A, 
const& a)
    , boost::type<R>* = 0
    )
{
    PyObject* const result = 
        PyEval_CallMethod(
            self
            , const_cast<char*>(name)
            , const_cast<char*>("(" BOOST_PP_REPEAT_1ST(N, 
BOOST_PYTHON_FIXED, "O") ")")
            BOOST_PP_REPEAT_1ST(N, 
BOOST_PYTHON_FAST_ARG_TO_PYTHON_GET, nil)
            );

	object refincfix(handle<>(borrowed(result)));
    converter::return_from_python<R> converter;
    return converter(result);
}

Then you use call_method2<> instead of call_method when calling 
virtual overridable methods in python.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031026/018996f7/attachment.pgp>

From s_sourceforge at nedprod.com  Sun Oct 26 05:29:09 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 26 Oct 2003 04:29:09 -0000
Subject: [C++-sig] Improved version of Lijun Qin's multithreading patch
Message-ID: <3F9B4D95.6355.1F9FF8AA@localhost>

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  invoke.hpp
     Date:  26 Oct 2003, 1:15
     Size:  6043 bytes.
     Type:  Unknown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invoke.hpp
Type: application/octet-stream
Size: 6043 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031026/94d61d75/attachment.obj>

From s_sourceforge at nedprod.com  Sun Oct 26 05:01:36 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 26 Oct 2003 04:01:36 -0000
Subject: [C++-sig] Pyste bug: protected virtual methods
Message-ID: <3F9B4720.2535.1F86BDFC@localhost>

Ok, there's FXWindow which provides a virtual method GetClass() but 
it's protected so pyste doesn't wrap it in the definition for 
FXWindow.

However, FXMainWindow inherits off FXWindow and in 
FXMainWindow_Wrapper there's an override for GetClass()! Needless to 
say, because python doesn't know of GetClass it can't call the 
default method :(

Solution: Don't generate items in X_Wrapper unless they're public. 
This is overkill however, because technically protected methods 
should be available to python if a python class inherits off it.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031026/8b0c7382/attachment.pgp>

From s_sourceforge at nedprod.com  Sun Oct 26 05:29:09 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 26 Oct 2003 04:29:09 -0000
Subject: [C++-sig] Improved version of Lijun Qin's multithreading patch
Message-ID: <3F9B4D95.29095.1F9FF8E8@localhost>

Attached is an improved version of Lijun Qin's patched invoke.hpp for 
multithreading. This version solves the following problems:

1. I couldn't find any member function traits in Boost. Odd they 
should be missing, but missing they are from all copies I have.
2. Even if you /do/ have both sets of function traits, they only go 
up to 10 parameters, not BPL's max arity.
3. If you had member variables eg; def_readwrite(), the old patch 
failed to compile.
4. The old patch failed when the parameter types did not have a copy 
constructor.
5. The old patch wrapped each call in a try...catch() which is 
inefficient.

Steps taken:

1 & 2: I've added my own custom partial specialisation for functions 
and member functions using the exact same preprocessor repeat as 
invoke.hpp uses. Thus the full range of parameters is available.
3: I've added specialisations of detail::member and detail::datum 
with type extractions.
4: I've utilised call_traits to hold converted parameters as 
references where possible. As the C++ standard guarantees an object 
must exist as long as a reference created initialised to it, this is 
fine.
5. There's now an object which RAII.

Q: Should I make the return type also a reference? Should save a copy 
construction, but I would need to take call_traits<>::param_type and 
remove the const-ness.

Cheers,
Niall






From dave at boost-consulting.com  Sun Oct 26 20:14:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 26 Oct 2003 14:14:37 -0500
Subject: [C++-sig] Re: Extracting C++ objects: documentation example fails.
References: <bnc413$m7o$1@sea.gmane.org>
	<20031024213733.19326.qmail@web41506.mail.yahoo.com>
Message-ID: <ud6cjvmjm.fsf@boost-consulting.com>

Joel Gerard <llywelyn.geo at yahoo.com> writes:

> Nevermind. I've seen the answer in a different post.
>
> http://mail.python.org/pipermail/c++-sig/2003-September/005510.html
>
> I think the documentation could benefit from this piece of information
> though.  It seems unusual to me that ANSI C++ leaves the ()
> off. Really?  It seems more logical that they appear.

ANSI C++ doesn't "leave them off".  If you look at the reference
documentation for extract you'll see that there's an implicit
conversion operator which makes them unneccessary.  There's also a bug
in your compiler which makes the implicit conversion operator fail to
work under some circumstances.

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




From dave at boost-consulting.com  Sun Oct 26 20:18:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 26 Oct 2003 14:18:48 -0500
Subject: [C++-sig] Re: fat class decoration
References: <bn9l2k$rug$1@sea.gmane.org>
Message-ID: <u7k2rvmcn.fsf@boost-consulting.com>

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

> Hi,
>
> I solicit a criticism and possible better solutions to the following
> problem.
>

<...>

> So what do think about it?
> Maybe you have had similar problem and solved it differently.
> I appreciate your comments.

Seems like you could generate the TColorHelper classes with templates
and save a lot of code.

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




From s_sourceforge at nedprod.com  Mon Oct 27 06:00:16 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 27 Oct 2003 05:00:16 -0000
Subject: [C++-sig] Pyste suggestion: handling void * arguments
Message-ID: <3F9CA660.7238.24E2D088@localhost>

Any chance of pyste doing http://mail.python.org/pipermail/c++-
sig/2003-April/003781.html for us automatically?

Even a cast to opaque type VOIDPTR would be fine by me.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031027/2a3e47f1/attachment.pgp>

From chezdique at yahoo.com  Mon Oct 27 10:02:14 2003
From: chezdique at yahoo.com (dique)
Date: Mon, 27 Oct 2003 01:02:14 -0800 (PST)
Subject: [C++-sig] Make C++-created object accessible by embeded Python
	Script
Message-ID: <20031027090214.50574.qmail@web41508.mail.yahoo.com>

Hi all,

I have several C++ objects (created with C++ code) and
I want them to be accessible and manipulatable by an
embeded python script. So far I only manage to let the
embeded script access a _copy_ of the C++ object.
Hence whatever changes done to the C++ object in the
python script wouldn't have any effect on the C++
object running in C++ code. How do I make the embeded
script able to access and manipulate the C++ object
directly?

I hope the code below would demonstrate what I mean.

#include <string>
#include <iostream>
#include <boost/python.hpp>

using namespace boost::python;

BOOST_PYTHON_MODULE(_pyembed)
{
    // To define useful functions.
}

class PythonScript
{
public:
    PythonScript()
    {
        PyImport_AppendInittab("_pyembed",
init_pyembed);
        Py_Initialize();
        handle<> mainModule(borrowed(
PyImport_AddModule("__main__") ));
        mainNamespace_ = dict(handle<>(borrowed(
PyModule_GetDict(mainModule.get()))));
    }
    
    virtual ~PythonScript()
    {
        Py_Finalize();
    }

    //! Add a named object which will be accessible by
the script.
    virtual void addNamedObject(const std::string&
name, object& obj)
    {
        dict_[name] = obj;
    }
    
    //! Run the script.
    virtual void run(const std::string& script)
    {
        mainNamespace_.update(dict_);
        try
        {
            object result(handle<>(
PyRun_String(script.c_str(), Py_file_input,
                            mainNamespace_.ptr(),
mainNamespace_.ptr()) ));
        }
        catch(error_already_set)
        {
            PyErr_Print();
        }
    }

private:
    dict dict_;
    dict mainNamespace_;

};

class Test
{
public:
    Test(int i) : i_(i) {}
    int add(int j)
    {
        return i_ += j;
    }
private:
    int i_;
};

class Test2
{
public:
    Test2(int i) : i_(i) {}
    int add(int j)
    {
        return i_ += j;
    }
private:
    int i_;
};

int main(int argc, char* argv[])
{
    PythonScript pythonScript;
    
    // This works nicely. But only limited to objects
created by Python.
    object testClass = class_<Test>("Test",
init<int>())
        .def("add", &Test::add);
    object testObject = testClass(10);
    pythonScript.addNamedObject("test", testObject);
    Test& test = extract<Test&>(testObject)();
    std::cout << "C++: " << test.add(10) << std::endl;
    pythonScript.run("print 'Python:',
test.add(10)\n");
    std::cout << "C++: " << test.add(10) << std::endl;

    // Below doesn't work as expected,
    // as Python and C++ maintain separate copies of
test1.
    Test test1(10);
    object testObject1(test1);
    pythonScript.addNamedObject("test1", testObject1);
    std::cout << "C++: " << test1.add(10) <<
std::endl;
    pythonScript.run("print 'Python:',
test1.add(10)\n");
    std::cout << "C++: " << test1.add(10) <<
std::endl;

    // Another attempt which failed too.
    try
    {
        Test2 test2(10);
        object testClass2 = class_<Test2,
boost::noncopyable>("Test2", init<int>())
            .def("add", &Test2::add);
        object testObject2(test2);
        pythonScript.addNamedObject("test2",
testObject2);
        std::cout << "C++: " << test2.add(10) <<
std::endl;
        pythonScript.run("print 'Python:',
test2.add(10)\n");
        std::cout << "C++: " << test2.add(10) <<
std::endl;
    }
    catch(error_already_set)
    {
        PyErr_Print();
    }
    
    return 0;
}

Thanks,
Dique C.

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/



From pierre.barbier at cirad.fr  Mon Oct 27 10:53:12 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 27 Oct 2003 10:53:12 +0100
Subject: [C++-sig] Call policy with constructor
Message-ID: <1067248392.1010.5.camel@pbarbier>

I want to define a constructor that takes a pointer a keep a reference
on it. So I need a call policy like 'with_custodian_and_ward<1,2>()'.

But it fails at compile time. Here's me Boost.Python code :

class_<RCPtr<Class> >(name, doc, init<optional<Class*> >())
      .def(init<RCPtr<Class> >())
      .def( init<Class*>(), with_custodian_and_ward<1,2>() )
      ;

Is there something wrong with what I did ? What sould I do ?

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 RaoulGough at yahoo.co.uk  Mon Oct 27 15:41:23 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 27 Oct 2003 14:41:23 +0000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com>
Message-ID: <uoew2eoa4.fsf@yahoo.co.uk>

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

> Hi Raoul,
>
> Using your documentation I've had no problems wrapping three custom
> linear array types with your container suite.

That's great! Did you have to provide a new Algorithms implementation,
or was a custom ContainerTraits enough? The default_algorithms
template tries to be as undemanding as possible, so that almost
anything with an STL-iterator-style interface should work.

> Just a couple of minor remarks:
>
> static boost::python::indexing::IndexStyle const index_style
>                                 ^
>
> typedef std::map<std::string, int> Container;
>                                    ^
>
> typedef indexing::map_algorithms<simple_map_traits> Algorithms;
>                                                     ^
>
> I believe according to the boost naming conventions these identifiers
> must be all lower case. But I am not really an authority in this
> matter. David?

You're absolutely right here. I thought I'd already cleared out the
mis-placed MixedCaseIdentifiers, but I obviously missed a few. Thanks
for pointing these out.

>
>> #include "algo_selector.hpp"
>> #include "visitor.hpp"
>
> Should probably be #include <boost/...>. It wasn't clear to me
> what I had to include.

Well, I started the documentation when the headers were all in a
private directory outside of the boost tree, so that was how I used to
include them. I'll fix this in the documentation (it was already fixed
in the real headers).

> Eventually just including
>
> #include <boost/python/suite/indexing/container_suite.hpp>
>
> worked for my purposes. Is this what I should be doing?
> Should this be added to <boost/python.hpp>?

Yes, that's what the documentation should have said. I would tend not
to include it from boost/python.hpp, for two reasons.  Firstly, it is
in the "suite" subdirectory, and I would guess that implies that it
currently has the status of an optional add-on. Secondly, it
(indirectly) includes all of the STL container headers (<map>, <set>,
<vector>, etc.) which makes for a big compile-time hit if you don't
otherwise need them. This could be avoided by splitting algo_selector
into multiple parts, and requiring the user to include headers like
<.../indexing/map_support.hpp> and <.../indexing/vector_support.hpp>
to get automatic algorithm selection for those containers.
Alternatively, algo_selector could try to forward-declare the
container templates itself, but I don't know if this is such a good
idea.

>
> There are two important features I am wondering about:
>
> 1. Just doing this
>
>    class_<my_container>("my_container")
>      .def(indexing::container_suite<my_container, my_algorithms>())
>    ;
>
>    doesn't enable me to initialize the instances with Python
>    lists or tuples. Have you thought about this already?
>    My first idea would be to define custom rvalue converters from
>    Python sequences to the wrapped container type
>    (http://www.boost.org/libs/python/doc/v2/faq.html#question2).
>    Then one could pass a Python sequence anywhere the wrapped container
>    is used as a const& or by-value argument. Simply define Python
>    bindings for the C++ copy constructor to enable initialization with
>    Python sequences.

The first thing I notice from your current code is that I should have
been using PyObject_GetIter myself in the python_iterator class,
instead of manually checking for an __iter__ or __getitem__ method.

I hadn't thought about constructing directly from a Python sequence
before, but I think it raises some interesting issues. BTW, if your
container supports slices, what you already *can* do is this:

>>> Vector v
>>> v[:] = [1,2,3]

-or-

>>> v.extend ([1,2,3])

Of course, that's not quite the same thing as construction from a
Python sequence. However, should such a conversion happen implicitly?
I assume the custom rvalue conversions happen automatically, so code
like this would work as follows:

>>> Vector v ([1,2,3])

Boost.Python sees the vector<int>::vector(vector<int> const &) copy
constructor, decides to construct an rvalue from the Python list using
the custom converter and passes this to the copy constructor. So two
copies happen here. It would be ggod if we could tie into the
templated iterator-pair constructor of the container, passing in
something that terates over the Python sequence. This might be
possible using some kind of magic precall policy that would turn a
single Python iterable object into two separate arguments. I'm not
sure exactly how this would work, though.

The other question is how to recognise when the conversion should take
place. For instance, should it only be considered for built-in Python
sequences, or should iterable user-defined containers also work?

>
> 2. Pickling of the wrapped types. This is a big issue but I find
>    it absolutely essential. I have a fairly general solution
>    that I'd be happy to share and extend if there is an interest.
>    If you are curious, it is a three-layer system:
>    The low-level serialization code for built-in types is here:
>     
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/serialization/
>    This is designed to maximize portability but is also very fast.
>    The second layer is here:
>     
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/
>    pickle_single_buffered.h and pickle_double_buffered.h.
>    A top layer for a particular array type is here:
>     
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/
>    flex_pickle_single_buffered.h, flex_pickle_double_buffered.h.
>    The system also works for user-defined types (the user has
>    to supply some code).
>    Adapting this system for the container suite would probably
>    require significant changes only to the top layer.

I don't have any experience with Python pickles. If it is simply a
matter of defining a new method for the container, you might be able
to do this via the visitor_helper hook in the Algorithms argument
supplied to container_suite (or directly to indexing::visitor). Is it
that easy, or does the container itself have to provide extra support
features? I suppose the de-pickling phase is also closely related to
the construction issue.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From mike at nospam.com  Mon Oct 27 18:17:04 2003
From: mike at nospam.com (Mike Rovner)
Date: Mon, 27 Oct 2003 09:17:04 -0800
Subject: [C++-sig] Re: fat class decoration
References: <bn9l2k$rug$1@sea.gmane.org> <u7k2rvmcn.fsf@boost-consulting.com>
Message-ID: <bnjjue$h2q$1@sea.gmane.org>

Thanks, Dave. Do you consider that implementation right for the task?

David Abrahams wrote:
> Seems like you could generate the TColorHelper classes with templates
> and save a lot of code.

Unfortunately they differ in implementation:

TColorHelper {  get/set()  { fat->get/set Color{}; } };
TLineHelper   { get/set () { fat->get/set Line{}; } };

so they folded to macro definition.

Mike






From mike at nospam.com  Mon Oct 27 19:11:28 2003
From: mike at nospam.com (Mike Rovner)
Date: Mon, 27 Oct 2003 10:11:28 -0800
Subject: [C++-sig] Re: Call policy with constructor
References: <1067248392.1010.5.camel@pbarbier>
Message-ID: <bnjn4e$pt4$1@sea.gmane.org>

Pierre Barbier de Reuille wrote:
> I want to define a constructor that takes a pointer a keep a reference
> on it. So I need a call policy like 'with_custodian_and_ward<1,2>()'.
>
> But it fails at compile time. Here's me Boost.Python code :
>
> class_<RCPtr<Class> >(name, doc, init<optional<Class*> >())
>       .def(init<RCPtr<Class> >())
>       .def( init<Class*>(), with_custodian_and_ward<1,2>() )
>       ;

You have to use different syntax:

      .def( init<Class*>()[with_custodian_and_ward<1,2>()] )

See reference at www.boost.org/libs/python/doc/v2/init.html#init-spec

Mike






From nicodemus at esss.com.br  Mon Oct 27 20:30:31 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 27 Oct 2003 16:30:31 -0300
Subject: [C++-sig] Pyste and member documentation
In-Reply-To: <3F90B784.19010.30B2CFA9@localhost>
References: <3F90B784.19010.30B2CFA9@localhost>
Message-ID: <3F9D7257.3080901@esss.com.br>

Niall Douglas wrote:

>I've just been looking through doxygen's XML output and I believe 
>it's more than sufficient for pyste to compare against the GCCXML 
>output so that they could be matched.
>

Doxygen outputs only documentation? I thought that it outputted more 
information too.

>Then personally I'd prefer a URL as the docstring to keep the DLL 
>size down but from what I can see, you merely append a .html to the 
>XML id and you have the equivalent HTML file with anchor.
>

I have no plans to include documentation in Pyste, though (no time to do 
it 8( . However I will happily accept patches, of course. 8)

Regards,
Nicodemus.




From dave at boost-consulting.com  Mon Oct 27 19:51:18 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 27 Oct 2003 08:51:18 -1000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com>
	<uoew2eoa4.fsf@yahoo.co.uk>
Message-ID: <uismapl95.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> This could be avoided by splitting algo_selector
> into multiple parts, and requiring the user to include headers like
> <.../indexing/map_support.hpp> and <.../indexing/vector_support.hpp>
> to get automatic algorithm selection for those containers.

I think that makes sense.

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




From nicodemus at esss.com.br  Mon Oct 27 20:55:35 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 27 Oct 2003 16:55:35 -0300
Subject: [C++-sig] Pyste (or GCCXML) bug: Fails to wrap inherited members
	defined inline
In-Reply-To: <3F90BCD3.2713.30C78B47@localhost>
References: <3F90BCD3.2713.30C78B47@localhost>
Message-ID: <3F9D7837.2000805@esss.com.br>

Niall Douglas wrote:

>Not sure if it's pyste or GCCXML, but sometimes (not always, about 
>25% of the time) pyste's wrappings won't specify members inherited 
>from a base class when they were defined in the bass class' header 
>file.
>
>Is this a known problem, or is it GCCXML? Typically when I run GCCXML 
>on its own it always gives me what appears to be the right output, 
>but it could be slightly different and I'd never know.
>

Couldn't reproduce it, so I wouldn't know. 8(
More likely it's a Pyste bug, perhaps not related to inlining, but some 
other property of the member function that you didn't notice.

Regards,
Nicodemus.




From dave at boost-consulting.com  Mon Oct 27 19:58:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 27 Oct 2003 08:58:14 -1000
Subject: [C++-sig] Re: Call policy with constructor
References: <1067248392.1010.5.camel@pbarbier> <bnjn4e$pt4$1@sea.gmane.org>
Message-ID: <ud6cipkxl.fsf@boost-consulting.com>

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

> Pierre Barbier de Reuille wrote:
>> I want to define a constructor that takes a pointer a keep a reference
>> on it. So I need a call policy like 'with_custodian_and_ward<1,2>()'.
>>
>> But it fails at compile time. Here's me Boost.Python code :
>>
>> class_<RCPtr<Class> >(name, doc, init<optional<Class*> >())
>>       .def(init<RCPtr<Class> >())
>>       .def( init<Class*>(), with_custodian_and_ward<1,2>() )
>>       ;
>
> You have to use different syntax:
>
>       .def( init<Class*>()[with_custodian_and_ward<1,2>()] )
>
> See reference at www.boost.org/libs/python/doc/v2/init.html#init-spec

...and you probably don't want the optional<Class*> in the first
init<...>.


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




From nicodemus at esss.com.br  Mon Oct 27 20:58:40 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 27 Oct 2003 16:58:40 -0300
Subject: [C++-sig] Pyste bug: protected virtual methods
In-Reply-To: <3F9B4720.2535.1F86BDFC@localhost>
References: <3F9B4720.2535.1F86BDFC@localhost>
Message-ID: <3F9D78F0.4060702@esss.com.br>

Niall Douglas wrote:

>Ok, there's FXWindow which provides a virtual method GetClass() but 
>it's protected so pyste doesn't wrap it in the definition for 
>FXWindow.
>
>However, FXMainWindow inherits off FXWindow and in 
>FXMainWindow_Wrapper there's an override for GetClass()! Needless to 
>say, because python doesn't know of GetClass it can't call the 
>default method :(
>
>Solution: Don't generate items in X_Wrapper unless they're public. 
>This is overkill however, because technically protected methods 
>should be available to python if a python class inherits off it.
>

Another solution would be to expose the protected members, but that 
would make them public in Python. I think this solution is more 
flexible, since the purpose of a protected method is to allow subclasses 
to call it... and the user can always rename the methods to prepend an 
"_", following Python's convention. What do you think?

Regards,
Nicodemus.




From nicodemus at esss.com.br  Mon Oct 27 21:14:45 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 27 Oct 2003 17:14:45 -0300
Subject: [C++-sig] Pyste suggestion: handling void * arguments
In-Reply-To: <3F9CA660.7238.24E2D088@localhost>
References: <3F9CA660.7238.24E2D088@localhost>
Message-ID: <3F9D7CB5.60700@esss.com.br>

Niall Douglas wrote:

>Any chance of pyste doing http://mail.python.org/pipermail/c++-
>sig/2003-April/003781.html for us automatically?
>
>Even a cast to opaque type VOIDPTR would be fine by me.
>  
>

How about this code (based on Dave's suggestion) for this foo:

void* foo(void *x) { return x; }

generated:

struct void_ptr{
    void_ptr(void* it_): it(it_) {}
    void* it;   
};


void_ptr* foo_w(void_ptr* x) { return new void_ptr(foo(x->it)); }

BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_ptr);

BOOST_PYTHON_MODULE(test)
{
    def("foo", foo_w, return_value_policy<return_opaque_pointer>());
}
 

Obviously, the point of it is to only work around the limitation that 
opaque_pointer's doesn't support void*. If you want to some how fiddle 
with the contents of the void*, you will have to write some wrappers 
that do some conversion on the C++ side.

Opinions? If everyone is fine with it, I can implement this in the next 
couple of days.

Regards,
Nicodemus.





From dave at boost-consulting.com  Mon Oct 27 20:58:13 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 27 Oct 2003 09:58:13 -1000
Subject: [C++-sig] Re: fat class decoration
References: <bn9l2k$rug$1@sea.gmane.org> <u7k2rvmcn.fsf@boost-consulting.com>
	<bnjjue$h2q$1@sea.gmane.org>
Message-ID: <uwuaqmp0q.fsf@boost-consulting.com>

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

> Thanks, Dave. Do you consider that implementation right for the task?
>
> David Abrahams wrote:
>> Seems like you could generate the TColorHelper classes with templates
>> and save a lot of code.
>
> Unfortunately they differ in implementation:
>
> TColorHelper {  get/set()  { fat->get/set Color{}; } };
> TLineHelper   { get/set () { fat->get/set Line{}; } };
>
> so they folded to macro definition.

You can't use member pointer template parameters to make them the same?

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




From RaoulGough at yahoo.co.uk  Mon Oct 27 23:33:37 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 27 Oct 2003 22:33:37 +0000
Subject: [C++-sig] Re: Make C++-created object accessible by embeded Python
	Script
References: <20031027090214.50574.qmail@web41508.mail.yahoo.com>
Message-ID: <ubrs2e2f2.fsf@yahoo.co.uk>

dique <chezdique at yahoo.com> writes:

> Hi all,
>
> I have several C++ objects (created with C++ code) and
> I want them to be accessible and manipulatable by an
> embeded python script. So far I only manage to let the
> embeded script access a _copy_ of the C++ object.
> Hence whatever changes done to the C++ object in the
> python script wouldn't have any effect on the C++
> object running in C++ code. How do I make the embeded
> script able to access and manipulate the C++ object
> directly?
>
> I hope the code below would demonstrate what I mean.
>
> #include <string>
> #include <iostream>
> #include <boost/python.hpp>
>
> using namespace boost::python;
[snip]
>     // This works nicely. But only limited to objects
> created by Python.
>     object testClass = class_<Test>("Test",
> init<int>())
>         .def("add", &Test::add);
>     object testObject = testClass(10);
>     pythonScript.addNamedObject("test", testObject);
>     Test& test = extract<Test&>(testObject)();
>     std::cout << "C++: " << test.add(10) << std::endl;
>     pythonScript.run("print 'Python:',
> test.add(10)\n");
>     std::cout << "C++: " << test.add(10) << std::endl;
>
>     // Below doesn't work as expected,
>     // as Python and C++ maintain separate copies of test1.
>     Test test1(10);
>     object testObject1(test1);
>     pythonScript.addNamedObject("test1", testObject1);
>     std::cout << "C++: " << test1.add(10) <<
> std::endl;
>     pythonScript.run("print 'Python:',
> test1.add(10)\n");
>     std::cout << "C++: " << test1.add(10) <<
> std::endl;

You could probably get what you want using boost::shared_ptr as the
"HeldType" for use in the Python object. Basically, the problem is
that you want to embed a reference of some sort to the C++ object
within the Python object. This is dangerous unless you have some way
of linking the lifetime of the C++ object to that of the Python object
that references it. I think it would just be a matter of doing it like
this:

object testClass = class_<Test, std::shared_ptr<Test> >(
   "Test", init<int>())
   .def("add", &Test::add);

boost::shared_ptr<Test> test1ptr (new Test (10));
object testObject1 (test1ptr); // ?
// ...

Not too sure of the exact details, but hopefully that gives you the
basic idea. See the libs/python/doc/v2/class.html for details.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From pub1 at abbas.org  Tue Oct 28 02:44:54 2003
From: pub1 at abbas.org (Greg Abbas)
Date: Mon, 27 Oct 2003 17:44:54 -0800
Subject: [C++-sig] Re: [boost] how to do from_python in v2?
Message-ID: <AEEHLFDMDPBPFHLGJGGAIEHDDPAA.pub1@abbas.org>

What's the state of the question that HellcatV wrote on 18 Dec 2002?
(http://lists.boost.org/MailArchives/boost/msg40923.php) Like him, I'm
porting V1 code, and want to register my own converters so that boost knows
what to do when I register a method that takes an argument like HellcatV's
Vector. In my case, I've got a library that (for instance) uses its own
string class (not std::string) and I need to teach boost to call a routine
that creates a C++ string object out of a python string.

I found http://lists.boost.org/MailArchives/boost/msg40934.php and got
Dave's "QVector_convertible, QVector_construct" suggestion working, but is
that still the best way? I see
(http://www.boost.org/libs/python/doc/v2/Apr2002.html#insights) that Dave is
thinking about this... what's the current status?

Thanks,
-greg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031027/eaf17335/attachment.htm>

From s_sourceforge at nedprod.com  Tue Oct 28 02:46:35 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 28 Oct 2003 01:46:35 -0000
Subject: [C++-sig] Pyste suggestion: handling void * arguments
In-Reply-To: <3F9D7CB5.60700@esss.com.br>
References: <3F9CA660.7238.24E2D088@localhost>
Message-ID: <3F9DCA7B.21864.2957DADB@localhost>

On 27 Oct 2003 at 17:14, Nicodemus wrote:

> void* foo(void *x) { return x; }
> 
> generated:
> 
> struct void_ptr{
>     void_ptr(void* it_): it(it_) {}
>     void* it;   
> };
> 
> 
> void_ptr* foo_w(void_ptr* x) { return new void_ptr(foo(x->it)); }
> 
> BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_ptr);
> 
> BOOST_PYTHON_MODULE(test)
> {
>     def("foo", foo_w, return_value_policy<return_opaque_pointer>()); }

You're nearly there. I foresee two options here - either make void * 
a container where python can access the pointer or make it an opaque 
type. Mixing the two creates confusion IMHO.

If you're going for opaque, you don't define void_ptr at all. This 
lets you catch when you're returning void * but have forgotten to 
specify return_opaque_pointer. Even better if pyste does this for you 
automagically.

> Obviously, the point of it is to only work around the limitation that
> opaque_pointer's doesn't support void*. If you want to some how fiddle
> with the contents of the void*, you will have to write some wrappers
> that do some conversion on the C++ side.
> 
> Opinions? If everyone is fine with it, I can implement this in the
> next couple of days.

I went ahead with a solution here which inserts casts to void_ptr * 
wherever pyste sees void *. And it works fine, except for overloaded 
methods because BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS() isn't aware 
of what I'm doing (yet, about to add another cast there too).

Your problem with generating wrappers is passing parameters in a 
fashion which doesn't cause problems. Most specifically, you must 
avoid copy construction when parameters are entering any C++ code. 
I've found call_traits::param_type to be useful here, but I'd imagine 
pyste would know when it can pass by reference and when not without 
that.

If however you choose the casting route (which is technically 
undefined behaviour, but I can't see many modern systems 
differentiating between types of pointers) I can send you my altered 
pyste. Remember that virtual method overrides in wrapper classes will 
have to cast anyway no matter what.

BTW, what happened to being able to distinguish between overloads by 
array index?

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031028/74c89451/attachment.pgp>

From s_sourceforge at nedprod.com  Tue Oct 28 02:34:52 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 28 Oct 2003 01:34:52 -0000
Subject: [C++-sig] Pyste bug: protected virtual methods
In-Reply-To: <3F9D78F0.4060702@esss.com.br>
References: <3F9B4720.2535.1F86BDFC@localhost>
Message-ID: <3F9DC7BC.32072.294D1F9A@localhost>

On 27 Oct 2003 at 16:58, Nicodemus wrote:

> Another solution would be to expose the protected members, but that
> would make them public in Python. I think this solution is more
> flexible, since the purpose of a protected method is to allow
> subclasses to call it... and the user can always rename the methods to
> prepend an "_", following Python's convention. What do you think?

Well you can promote protected or private members to public when 
subclassing, so this looks like a good idea.

If you wanted to make it really pretty, you could make all protected 
members exposed using "_" as you suggest. They are after all not for 
public use.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031028/ddb19936/attachment.pgp>

From s_sourceforge at nedprod.com  Tue Oct 28 02:48:34 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 28 Oct 2003 01:48:34 -0000
Subject: [C++-sig] Pyste and member documentation
In-Reply-To: <3F9D7257.3080901@esss.com.br>
References: <3F90B784.19010.30B2CFA9@localhost>
Message-ID: <3F9DCAF2.6811.2959A877@localhost>

On 27 Oct 2003 at 16:30, Nicodemus wrote:

> >I've just been looking through doxygen's XML output and I believe
> >it's more than sufficient for pyste to compare against the GCCXML
> >output so that they could be matched.
> 
> Doxygen outputs only documentation? I thought that it outputted more
> information too.

Its most verbose option to my knowledge is the XML output. But yes, 
only documentation (the XML output nears GCCXML in detail).

> >Then personally I'd prefer a URL as the docstring to keep the DLL
> >size down but from what I can see, you merely append a .html to the
> >XML id and you have the equivalent HTML file with anchor.
> 
> I have no plans to include documentation in Pyste, though (no time to
> do it 8( . However I will happily accept patches, of course. 8)

Hmm, cool. I'll put it on my "may do if have time" list.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031028/7caf6373/attachment.pgp>

From pierre.barbier at cirad.fr  Tue Oct 28 16:32:55 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Tue, 28 Oct 2003 16:32:55 +0100
Subject: [C++-sig] Naming arguments of exported methods
Message-ID: <1067355175.7279.13.camel@pbarbier>

I'm trying to use the "arg" object as descibed in the CVS documentation
in "libs/python/doc/v2/args.html" (in your boost directory). It says not
to use args. But I cannot succeed in making it compile with g++-3.2
Instead, I have the errors put at the end of the text. For all these
errors, I just modified the line :

	.def( "neighbors", cg3d_neighbors)

into :

	.def( "neighbors", cg3d_neighbors , py_arg( "cell" ) )

I should add that I needed to define:

typedef boost::python::arg py_arg;

because 'arg' is already used in the STL and in boost itself. I hope
there is enough details.

Thanks,

Pierre Barbier de Reuille

Error 1 :

*************************************************************************
/home/barbier/apps/boost/boost/python/detail/caller.hpp|196|
instantiated from `PyObject*
boost::python::detail::caller_arity<2>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = boost::python::tuple
(*)(CellGraph3D*, int), Policies = boost::python::arg, Sig =
boost::mpl::vector3<boost::python::tuple, CellGraph3D*, int>]'
/home/barbier/apps/boost/boost/python/object/py_function.hpp|39|
instantiated from `PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<boost::python::tuple (*)(CellGraph3D*, int), boost::python::arg, boost::mpl::vector3<boost::python::tuple, CellGraph3D*, int> >]'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|186|
instantiated from here
/home/barbier/apps/boost/boost/python/detail/caller.hpp|196| no type
named `
||    result_converter' in `struct boost::python::arg'
|| /home/barbier/apps/boost/boost/python/detail/caller.hpp: In member
function 
||    `PyObject* boost::python::detail::caller_arity<2>::impl<F,
Policies, 
||    Sig>::operator()(PyObject*, PyObject*) [with F =
boost::python::tuple 
||    (*)(CellGraph3D*, int), Policies = boost::python::arg, Sig = 
||    boost::mpl::vector3<boost::python::tuple, CellGraph3D*, int>]':
*************************************************************************

Error 2 :

*************************************************************************
/home/barbier/apps/boost/boost/python/object/py_function.hpp|39|
instantiated from `PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<boost::python::tuple (*)(CellGraph3D*, int), boost::python::arg, boost::mpl::vector3<boost::python::tuple, CellGraph3D*, int> >]'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|186|
instantiated from here
/home/barbier/apps/boost/boost/python/detail/caller.hpp|196| no type
named `
||    type' in `struct 
||    boost::python::detail::select_result_converter<boost::python::arg,
||    boost::python::tuple>'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|197| no type
named `
||    argument_package' in `struct boost::python::arg'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|199| no type
named `
||    argument_package' in `struct boost::python::arg'
*************************************************************************

Error 3 :

*************************************************************************
/home/barbier/apps/boost/boost/python/object/py_function.hpp|39|
instantiated from `PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<boost::python::tuple (*)(CellGraph3D*, int), boost::python::arg, boost::mpl::vector3<boost::python::tuple, CellGraph3D*, int> >]'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|186|
instantiated from here
/home/barbier/apps/boost/boost/python/detail/caller.hpp|35| `inner_args'
||    undeclared (first use this function)
/home/barbier/apps/boost/boost/python/detail/caller.hpp|35| (Each
undeclared 
||    identifier is reported only once for each function it appears in.)
*************************************************************************

Error 4 :

*************************************************************************
/home/barbier/apps/boost/boost/python/object/py_function.hpp|39|
instantiated from `PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<boost::python::tuple (*)(CellGraph3D*, int), boost::python::arg, boost::mpl::vector3<boost::python::tuple, CellGraph3D*, int> >]'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|186|
instantiated from here
/home/barbier/apps/boost/boost/python/detail/caller.hpp|216| no type
named `
||    type' in `struct 
||    boost::python::detail::select_result_converter<boost::python::arg,
||    boost::python::tuple>'
/home/barbier/apps/boost/boost/python/detail/caller.hpp|216| no type
named `
||    type' in `struct 
||    boost::python::detail::select_result_converter<boost::python::arg,
||    boost::python::tuple>'
|| /home/barbier/apps/boost/boost/python/detail/caller.hpp: In function 
||    `ResultConverter
boost::python::detail::create_result_converter(const 
||    ArgPackage&, ResultConverter*, ...) [with ArgPackage = PyObject*, 
||    ResultConverter = void_result_to_python]':
*************************************************************************


-- 
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 RaoulGough at yahoo.co.uk  Tue Oct 28 17:30:53 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 28 Oct 2003 16:30:53 +0000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com>
	<uoew2eoa4.fsf@yahoo.co.uk> <uismapl95.fsf@boost-consulting.com>
Message-ID: <uoew12uki.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> This could be avoided by splitting algo_selector
>> into multiple parts, and requiring the user to include headers like
>> <.../indexing/map_support.hpp> and <.../indexing/vector_support.hpp>
>> to get automatic algorithm selection for those containers.
>
> I think that makes sense.

Now done. I'll also have to update the documentation for this
change.

I notice from the developers list that Beman Dawes is thinking about a
release branch on November 3. Any thoughts about whether the new
indexing suite should go into the next release or not? My only slight
reservation is that it hasn't yet been tested on a compiler without
partial template specialization support.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From dave at boost-consulting.com  Tue Oct 28 20:26:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Oct 2003 09:26:21 -1000
Subject: [C++-sig] Re: [boost] how to do from_python in v2?
References: <AEEHLFDMDPBPFHLGJGGAIEHDDPAA.pub1@abbas.org>
Message-ID: <u1xsxjh9e.fsf@boost-consulting.com>

"Greg Abbas" <pub1 at abbas.org> writes:

> I found http://lists.boost.org/MailArchives/boost/msg40934.php and got
> Dave's "QVector_convertible, QVector_construct" suggestion working, but is
> that still the best way? I see
> (http://www.boost.org/libs/python/doc/v2/Apr2002.html#insights) that Dave is
> thinking about this... what's the current status?

Have you seen

http://www.boost.org/libs/python/doc/v2/faq.html#question2

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




From nicodemus at esss.com.br  Tue Oct 28 23:05:13 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Tue, 28 Oct 2003 19:05:13 -0300
Subject: [C++-sig] Pyste suggestion: handling void * arguments
In-Reply-To: <3F9DCA7B.21864.2957DADB@localhost>
References: <3F9CA660.7238.24E2D088@localhost>
	<3F9DCA7B.21864.2957DADB@localhost>
Message-ID: <3F9EE819.3000803@esss.com.br>

Niall Douglas wrote:

>On 27 Oct 2003 at 17:14, Nicodemus wrote:
>
>  
>
>>void* foo(void *x) { return x; }
>>
>>generated:
>>
>>struct void_ptr{
>>    void_ptr(void* it_): it(it_) {}
>>    void* it;   
>>};
>>
>>
>>void_ptr* foo_w(void_ptr* x) { return new void_ptr(foo(x->it)); }
>>
>>BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_ptr);
>>
>>BOOST_PYTHON_MODULE(test)
>>{
>>    def("foo", foo_w, return_value_policy<return_opaque_pointer>()); }
>>    
>>
>
>You're nearly there. I foresee two options here - either make void * 
>a container where python can access the pointer or make it an opaque 
>type. Mixing the two creates confusion IMHO.
>

Acess void* in Python? What for? You won't be able to do anything with 
it, except pass it to other C++ functions that accept void* too. And 
then the code above would take care of that, creating automatic wrappers 
for this functions too.

>If you're going for opaque, you don't define void_ptr at all. This 
>lets you catch when you're returning void * but have forgotten to 
>specify return_opaque_pointer. Even better if pyste does this for you 
>automagically.
>

Sorry, I didn't understand you. You mean that when a function returns 
void*, Pyste could automatically set its default policy for 
return_opaque_pointer? That would be the optimal solution, but 
return_opaque_pointer doesn't work with void*, or am I wrong?

>I went ahead with a solution here which inserts casts to void_ptr * 
>wherever pyste sees void *. And it works fine, except for overloaded 
>methods because BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS() isn't aware 
>of what I'm doing (yet, about to add another cast there too).
>
>Your problem with generating wrappers is passing parameters in a 
>fashion which doesn't cause problems. Most specifically, you must 
>avoid copy construction when parameters are entering any C++ code. 
>I've found call_traits::param_type to be useful here, but I'd imagine 
>pyste would know when it can pass by reference and when not without 
>that.
>

Hmm, I see. But what's the problem with extra copy construction? You 
mean performance, or some other problem?

>If however you choose the casting route (which is technically 
>undefined behaviour, but I can't see many modern systems 
>differentiating between types of pointers) I can send you my altered 
>pyste. Remember that virtual method overrides in wrapper classes will 
>have to cast anyway no matter what.
>

I don't know, "undefined behaviour" is never good. Dave, what's your 
opinion on this?

>BTW, what happened to being able to distinguish between overloads by 
>array index?
>

Sorry, just responded to that post.

Regards,
Nicodemus.




From nicodemus at esss.com.br  Tue Oct 28 23:07:18 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Tue, 28 Oct 2003 19:07:18 -0300
Subject: [C++-sig] Setting policies on overloads in pyste
In-Reply-To: <3F989A9C.17414.14DDEA46@localhost>
References: <3F989A9C.17414.14DDEA46@localhost>
Message-ID: <3F9EE896.1060507@esss.com.br>

Niall Douglas wrote:

>Any idea when the solution of making multiple functions with the same 
>name a list and therefore individually addressable?
>
>My current solution of applying a large GNU patch file every time I 
>generate wrappings is getting painful (stupid thing is increasingly 
>rejecting patches) :(
>

Sorry Niall, I'm in a pretty busy month, with college and work, so I 
really have no idea when I can implement this... 8(
It's in my TODO, thought, so I promise I will get to it as soon as I get 
the time. I recognize that it is indeed an important problem to be solved.

Regards,
Nicodemus.




From saspicer at mac.com  Tue Oct 28 23:12:52 2003
From: saspicer at mac.com (Sean Spicer)
Date: Tue, 28 Oct 2003 16:12:52 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
Message-ID: <DFE7A28A-0993-11D8-BE52-000A95C4839C@mac.com>

Hi Everyone,

I've just managed to get boost.python built on Mac OS X 10.3 (Panther) 
using the default Xcode tools that shipped with with the OS.  To do so 
however, I've had to do a nasty hack, and I'm wondering if someone can 
point me to a better way of doing things.

Namely, the hack involves modifying the (CVS head) 
<boostroot>/tools/build/darwin-tools.jam file so that lines 160 & 172 
read:

-framework Python

instead of

-framework$(_)$FRAMEWORKS

This was the only thing that allowed me to avoid the following link 
line when compiling:

-framework 
/System/Library/Frameworks/Python.framework/Versions/2.3/Python

which does not exist.

I tried the command line option to bjam, e.g....

bjam "-sTOOLS=darwin <framework>Python"

to no avail.  Anyone have any hints as to how to avoid this nastiness ?

cheers,

sean


_______________________________________________________________________
Sean A. Spicer

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
15859D54)




From grafik.list at redshift-software.com  Tue Oct 28 23:21:38 2003
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Tue, 28 Oct 2003 16:21:38 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <DFE7A28A-0993-11D8-BE52-000A95C4839C@mac.com>
Message-ID: <20031028162139-r01010800-41354069-0860-0108@12.100.89.43>

[2003-10-28] Sean Spicer wrote:

>Hi Everyone,
>
>I've just managed to get boost.python built on Mac OS X 10.3 (Panther) 
>using the default Xcode tools that shipped with with the OS.  To do so 
>however, I've had to do a nasty hack, and I'm wondering if someone can 
>point me to a better way of doing things.
>
>Namely, the hack involves modifying the (CVS head) 
><boostroot>/tools/build/darwin-tools.jam file so that lines 160 & 172 
>read:
>
>-framework Python
>
>instead of
>
>-framework$(_)$FRAMEWORKS
>
>This was the only thing that allowed me to avoid the following link 
>line when compiling:
>
>-framework 
>/System/Library/Frameworks/Python.framework/Versions/2.3/Python
>
>which does not exist.

Where does your Python framework live? What are you setting PYTHON_ROOT to,
if anything?

I'm asking because if it's not there I'm not sure how you are getting the
includes to work at all.


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



From saspicer at mac.com  Tue Oct 28 23:33:19 2003
From: saspicer at mac.com (Sean Spicer)
Date: Tue, 28 Oct 2003 16:33:19 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028162139-r01010800-41354069-0860-0108@12.100.89.43>
References: <20031028162139-r01010800-41354069-0860-0108@12.100.89.43>
Message-ID: <BB3213E4-0996-11D8-ACD2-000A95C4839C@mac.com>


Hi Rene,

I'm setting PYTHON_ROOT to /System/Library/Frameworks/Python.framework

which is the default install location (e.g. installed by the slick 
installer) for python on mint OS X 10.3 systems.

sean

On Oct 28, 2003, at 4:21 PM, Rene Rivera wrote:

> [2003-10-28] Sean Spicer wrote:
>
>> Hi Everyone,
>>
>> I've just managed to get boost.python built on Mac OS X 10.3 (Panther)
>> using the default Xcode tools that shipped with with the OS.  To do so
>> however, I've had to do a nasty hack, and I'm wondering if someone can
>> point me to a better way of doing things.
>>
>> Namely, the hack involves modifying the (CVS head)
>> <boostroot>/tools/build/darwin-tools.jam file so that lines 160 & 172
>> read:
>>
>> -framework Python
>>
>> instead of
>>
>> -framework$(_)$FRAMEWORKS
>>
>> This was the only thing that allowed me to avoid the following link
>> line when compiling:
>>
>> -framework
>> /System/Library/Frameworks/Python.framework/Versions/2.3/Python
>>
>> which does not exist.
>
> Where does your Python framework live? What are you setting 
> PYTHON_ROOT to,
> if anything?
>
> I'm asking because if it's not there I'm not sure how you are getting 
> the
> includes to work at all.
>
>
> -- grafik - Don't Assume Anything
> -- rrivera (at) acm.org - grafik (at) redshift-software.com
> -- 102708583 (at) icq
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
________________________________________________________________
Sean Spicer
Sr. Development Lead
Magic Earth, Inc (A Halliburton Company)
www.magic-earth.com

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
15859D54)




From rwgk at yahoo.com  Tue Oct 28 23:45:56 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 28 Oct 2003 14:45:56 -0800 (PST)
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <BB3213E4-0996-11D8-ACD2-000A95C4839C@mac.com>
Message-ID: <20031028224556.33363.qmail@web20202.mail.yahoo.com>

This is really cool news. Which version of gcc ships with the XCode tools?

I am asking because I promised to update the FAQ item on OS X before the Boost
1.31 release.

Ralf

--- Sean Spicer <saspicer at mac.com> wrote:
> 
> Hi Rene,
> 
> I'm setting PYTHON_ROOT to /System/Library/Frameworks/Python.framework
> 
> which is the default install location (e.g. installed by the slick 
> installer) for python on mint OS X 10.3 systems.
> 
> sean
> 
> On Oct 28, 2003, at 4:21 PM, Rene Rivera wrote:
> 
> > [2003-10-28] Sean Spicer wrote:
> >
> >> Hi Everyone,
> >>
> >> I've just managed to get boost.python built on Mac OS X 10.3 (Panther)
> >> using the default Xcode tools that shipped with with the OS.  To do so
> >> however, I've had to do a nasty hack, and I'm wondering if someone can
> >> point me to a better way of doing things.
> >>
> >> Namely, the hack involves modifying the (CVS head)
> >> <boostroot>/tools/build/darwin-tools.jam file so that lines 160 & 172
> >> read:
> >>
> >> -framework Python
> >>
> >> instead of
> >>
> >> -framework$(_)$FRAMEWORKS
> >>
> >> This was the only thing that allowed me to avoid the following link
> >> line when compiling:
> >>
> >> -framework
> >> /System/Library/Frameworks/Python.framework/Versions/2.3/Python
> >>
> >> which does not exist.
> >
> > Where does your Python framework live? What are you setting 
> > PYTHON_ROOT to,
> > if anything?
> >
> > I'm asking because if it's not there I'm not sure how you are getting 
> > the
> > includes to work at all.
> >
> >
> > -- grafik - Don't Assume Anything
> > -- rrivera (at) acm.org - grafik (at) redshift-software.com
> > -- 102708583 (at) icq
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
> ________________________________________________________________
> Sean Spicer
> Sr. Development Lead
> Magic Earth, Inc (A Halliburton Company)
> www.magic-earth.com
> 
> pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
> pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
> 15859D54)
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/



From grafik.list at redshift-software.com  Tue Oct 28 23:48:18 2003
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Tue, 28 Oct 2003 16:48:18 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <BB3213E4-0996-11D8-ACD2-000A95C4839C@mac.com>
Message-ID: <20031028164819-r01010800-98a1bd09-0860-0108@12.100.89.43>

[2003-10-28] Sean Spicer wrote:

>
>Hi Rene,
>
>I'm setting PYTHON_ROOT to /System/Library/Frameworks/Python.framework
>
>which is the default install location (e.g. installed by the slick 
>installer) for python on mint OS X 10.3 systems.

To answer your original question, there's no other clean way to set that
particular framework than the one you mentioned. The only other way is to
change python.jam to not use <framework>$(PYTHON_ROOT)/Python.

OK, more questions for possibly fixing this in the future...

What does your PYTHON_ROOT directory structure look like? (just the
directories)


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



From saspicer at mac.com  Tue Oct 28 23:52:40 2003
From: saspicer at mac.com (Sean Spicer)
Date: Tue, 28 Oct 2003 16:52:40 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028224556.33363.qmail@web20202.mail.yahoo.com>
References: <20031028224556.33363.qmail@web20202.mail.yahoo.com>
Message-ID: <6EDF8DAA-0999-11D8-ACD2-000A95C4839C@mac.com>


Ralf,

gcc -v reports:

gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)

I'd really like to help out and get boost.python running nicely on OS 
X...but I just started trying today <sheepish grin>, so I may need some 
hand-holding.

sean

On Oct 28, 2003, at 4:45 PM, Ralf W. Grosse-Kunstleve wrote:

> This is really cool news. Which version of gcc ships with the XCode 
> tools?
>
> I am asking because I promised to update the FAQ item on OS X before 
> the Boost
> 1.31 release.
>
> Ralf
>
> --- Sean Spicer <saspicer at mac.com> wrote:
>>
>> Hi Rene,
>>
>> I'm setting PYTHON_ROOT to /System/Library/Frameworks/Python.framework
>>
>> which is the default install location (e.g. installed by the slick
>> installer) for python on mint OS X 10.3 systems.
>>
>> sean
>>
>> On Oct 28, 2003, at 4:21 PM, Rene Rivera wrote:
>>
>>> [2003-10-28] Sean Spicer wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> I've just managed to get boost.python built on Mac OS X 10.3 
>>>> (Panther)
>>>> using the default Xcode tools that shipped with with the OS.  To do 
>>>> so
>>>> however, I've had to do a nasty hack, and I'm wondering if someone 
>>>> can
>>>> point me to a better way of doing things.
>>>>
>>>> Namely, the hack involves modifying the (CVS head)
>>>> <boostroot>/tools/build/darwin-tools.jam file so that lines 160 & 
>>>> 172
>>>> read:
>>>>
>>>> -framework Python
>>>>
>>>> instead of
>>>>
>>>> -framework$(_)$FRAMEWORKS
>>>>
>>>> This was the only thing that allowed me to avoid the following link
>>>> line when compiling:
>>>>
>>>> -framework
>>>> /System/Library/Frameworks/Python.framework/Versions/2.3/Python
>>>>
>>>> which does not exist.
>>>
>>> Where does your Python framework live? What are you setting
>>> PYTHON_ROOT to,
>>> if anything?
>>>
>>> I'm asking because if it's not there I'm not sure how you are getting
>>> the
>>> includes to work at all.
>>>
>>>
>>> -- grafik - Don't Assume Anything
>>> -- rrivera (at) acm.org - grafik (at) redshift-software.com
>>> -- 102708583 (at) icq
>>>
>>> _______________________________________________
>>> C++-sig mailing list
>>> C++-sig at python.org
>>> http://mail.python.org/mailman/listinfo/c++-sig
>>>
>> ________________________________________________________________
>> Sean Spicer
>> Sr. Development Lead
>> Magic Earth, Inc (A Halliburton Company)
>> www.magic-earth.com
>>
>> pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 
>> 9D54
>> pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID:
>> 15859D54)
>>
>>
>> _______________________________________________
>> C++-sig mailing list
>> C++-sig at python.org
>> http://mail.python.org/mailman/listinfo/c++-sig
>
>
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
_______________________________________________________________________
Sean A. Spicer

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
15859D54)




From saspicer at mac.com  Tue Oct 28 23:56:39 2003
From: saspicer at mac.com (Sean Spicer)
Date: Tue, 28 Oct 2003 16:56:39 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028164819-r01010800-98a1bd09-0860-0108@12.100.89.43>
References: <20031028164819-r01010800-98a1bd09-0860-0108@12.100.89.43>
Message-ID: <FDC4F79E-0999-11D8-ACD2-000A95C4839C@mac.com>


Okay, I'll do my best...

/System/Libraries/Frameworks/Python.framework:

lrwxr-xr-x  1 root  wheel   24 25 Oct 11:44 Headers -> 
Versions/Current/Headers
lrwxr-xr-x  1 root  wheel   23 24 Oct 16:37 Python -> 
Versions/Current/Python
lrwxr-xr-x  1 root  wheel   26 24 Oct 16:37 Resources -> 
Versions/Current/Resources
drwxr-xr-x  4 root  wheel  136 13 Sep 21:40 Versions

I believe the relevant location is Versions/Current:

lrwxr-xr-x  1 root  wheel       17 25 Oct 11:44 Headers -> 
include/python2.3
drwxr-xr-x  3 root  wheel      102 27 Sep 04:39 Mac
-rwxr-xr-x  1 root  wheel  1088276 26 Sep 01:40 Python
drwxr-xr-x  7 root  wheel      238 27 Sep 04:39 Resources
drwxr-xr-x  6 root  wheel      204 27 Sep 04:38 bin
drwxr-xr-x  3 root  wheel      102 27 Sep 04:38 include
drwxr-xr-x  3 root  wheel      102 13 Sep 21:40 lib

Each of these directories looks pretty much like you'd find on Linux in 
/usr/local/

Does that help ?

On Oct 28, 2003, at 4:48 PM, Rene Rivera wrote:

> [2003-10-28] Sean Spicer wrote:
>
>>
>> Hi Rene,
>>
>> I'm setting PYTHON_ROOT to /System/Library/Frameworks/Python.framework
>>
>> which is the default install location (e.g. installed by the slick
>> installer) for python on mint OS X 10.3 systems.
>
> To answer your original question, there's no other clean way to set 
> that
> particular framework than the one you mentioned. The only other way is 
> to
> change python.jam to not use <framework>$(PYTHON_ROOT)/Python.
>
> OK, more questions for possibly fixing this in the future...
>
> What does your PYTHON_ROOT directory structure look like? (just the
> directories)
>
>
> -- grafik - Don't Assume Anything
> -- rrivera (at) acm.org - grafik (at) redshift-software.com
> -- 102708583 (at) icq
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
_______________________________________________________________________
Sean A. Spicer

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
15859D54)




From saspicer at mac.com  Wed Oct 29 00:16:19 2003
From: saspicer at mac.com (Sean Spicer)
Date: Tue, 28 Oct 2003 17:16:19 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028164819-r01010800-98a1bd09-0860-0108@12.100.89.43>
References: <20031028164819-r01010800-98a1bd09-0860-0108@12.100.89.43>
Message-ID: <BCC50EC1-099C-11D8-ACD2-000A95C4839C@mac.com>


> The only other way is to change python.jam to not use 
> <framework>$(PYTHON_ROOT)/Python.

Well, that was the ticket !  I changed it to:

<framework>Python

And things build like a charm now, and no nasty hacks to darwin-tools!

Thanks !

One other question, what's the standard protocol for 
setting(DY)LD_LIBRARY_PATH so that I can pickup the boost libs? There 
seems to be pretty sparse documentation of this on the web.

sean

On Oct 28, 2003, at 4:48 PM, Rene Rivera wrote:

________________________________________________________________
Sean Spicer
Sr. Development Lead
Magic Earth, Inc (A Halliburton Company)
www.magic-earth.com

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
15859D54)




From rwgk at yahoo.com  Wed Oct 29 00:47:55 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 28 Oct 2003 15:47:55 -0800 (PST)
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <6EDF8DAA-0999-11D8-ACD2-000A95C4839C@mac.com>
Message-ID: <20031028234755.22716.qmail@web20203.mail.yahoo.com>

--- Sean Spicer <saspicer at mac.com> wrote:
> 
> Ralf,
> 
> gcc -v reports:
> 
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
> 
> I'd really like to help out and get boost.python running nicely on OS 
> X...but I just started trying today <sheepish grin>, so I may need some 
> hand-holding.

That's the same version I had so much fun with:

http://cci.lbl.gov/~rwgk/boost_python/

See the first link in the list under Mac OS 10. I am wondering if Apple has
fixed some of the problems:

- Does the optimizer work? (it works, btw, with gcc 3.3.1)
- Is it possible to link and run all tests in boost/libs/python/test?
- Is the horrendous problem fixed that we have to work around in
  boost/libs/python/src/converter/registry.cpp (look for
  BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND)?

Since you seem to have bjam working, could you try all tests? cd to
boost/libs/python/test, issue the bjam command that you worked out, followed by
the word test. Here is what worked for me a while ago:

bjam -sPYTHON_VERSION=2.3 -sTOOLS=darwin -sBUILD=debug -sRUN_ALL_TESTS=1 test

Unfortunately, trying this with the most current cvs I get
<@boost!libs!python!test>crossmod_exception_a.so: required property
<warnings>off incompatible with <warnings>on

Maybe Rene can help?

Ralf


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/



From dave at boost-consulting.com  Wed Oct 29 01:46:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Oct 2003 14:46:52 -1000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com>
	<uoew2eoa4.fsf@yahoo.co.uk>
	<uismapl95.fsf@boost-consulting.com> <uoew12uki.fsf@yahoo.co.uk>
Message-ID: <uptggj2f7.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> This could be avoided by splitting algo_selector
>>> into multiple parts, and requiring the user to include headers like
>>> <.../indexing/map_support.hpp> and <.../indexing/vector_support.hpp>
>>> to get automatic algorithm selection for those containers.
>>
>> I think that makes sense.
>
> Now done. I'll also have to update the documentation for this
> change.
>
> I notice from the developers list that Beman Dawes is thinking about a
> release branch on November 3. Any thoughts about whether the new
> indexing suite should go into the next release or not? My only slight
> reservation is that it hasn't yet been tested on a compiler without
> partial template specialization support.

So let's test it!

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




From saspicer at mac.com  Wed Oct 29 02:09:12 2003
From: saspicer at mac.com (Sean Spicer)
Date: Tue, 28 Oct 2003 19:09:12 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
References: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
Message-ID: <81AEB7C5-09AC-11D8-898E-000A95C4839C@mac.com>


Hi Ralf,

I'll give it a shot tomorrow...I know the build number 1409 had a lot 
of problems, but 1495 has been rock solid for me.

cheers,

sean

On Oct 28, 2003, at 5:47 PM, Ralf W. Grosse-Kunstleve wrote:

> --- Sean Spicer <saspicer at mac.com> wrote:
>>
>> Ralf,
>>
>> gcc -v reports:
>>
>> gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
>>
>> I'd really like to help out and get boost.python running nicely on OS
>> X...but I just started trying today <sheepish grin>, so I may need 
>> some
>> hand-holding.
>
> That's the same version I had so much fun with:
>
> http://cci.lbl.gov/~rwgk/boost_python/
>
> See the first link in the list under Mac OS 10. I am wondering if 
> Apple has
> fixed some of the problems:
>
> - Does the optimizer work? (it works, btw, with gcc 3.3.1)
> - Is it possible to link and run all tests in boost/libs/python/test?
> - Is the horrendous problem fixed that we have to work around in
>   boost/libs/python/src/converter/registry.cpp (look for
>   BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND)?
>
> Since you seem to have bjam working, could you try all tests? cd to
> boost/libs/python/test, issue the bjam command that you worked out, 
> followed by
> the word test. Here is what worked for me a while ago:
>
> bjam -sPYTHON_VERSION=2.3 -sTOOLS=darwin -sBUILD=debug 
> -sRUN_ALL_TESTS=1 test
>
> Unfortunately, trying this with the most current cvs I get
> <@boost!libs!python!test>crossmod_exception_a.so: required property
> <warnings>off incompatible with <warnings>on
>
> Maybe Rene can help?
>
> Ralf
>
>
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
_______________________________________________________________________
Sean A. Spicer

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 
15859D54)




From dave at boost-consulting.com  Wed Oct 29 03:40:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Oct 2003 16:40:26 -1000
Subject: [C++-sig] Re: Pyste suggestion: handling void * arguments
In-Reply-To: <3F9EE819.3000803@esss.com.br> (nicodemus@esss.com.br's message
	of "Tue, 28 Oct 2003 19:05:13 -0300")
References: <3F9CA660.7238.24E2D088@localhost>
	<3F9DCA7B.21864.2957DADB@localhost> <3F9EE819.3000803@esss.com.br>
Message-ID: <uhe1sg411.fsf@boost-consulting.com>

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

>> If however you choose the casting route (which is technically
>> undefined behaviour, but I can't see many modern systems
>> differentiating between types of pointers) I can send you my altered
>> pyste. Remember that virtual method overrides in wrapper classes
>> will have to cast anyway no matter what.
>>
>
> I don't know, "undefined behaviour" is never good. Dave, what's your
> opinion on this?

The library should never invoke undefined behavior unless the user
violates its preconditions.

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




From jbrandmeyer at earthlink.net  Wed Oct 29 04:17:59 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Tue, 28 Oct 2003 22:17:59 -0500
Subject: [C++-sig] class_<>::add_property() on CVS-HEAD
Message-ID: <1067397479.30557.10.camel@illuvatar>

The following example demonstrates a method of using add_property that
works with Boost.Python 1.30 but not CVS-HEAD (from sourceforge CVS). 
The example posted is somewhat useless as-is, but demonstrates something
that I started using for properties with non-trivial accessors.

Is there a replacement for this functionality?

Thanks,
Jonathan Brandmeyer

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

namespace test {

// Hmm.  return_internal_reference<>() wants to wrap a real class.
class ret_type
{
 public:
	double i;
};

class crash_me
{
	private:
		ret_type i;
	public:
		ret_type& get_i() { return i; }
};

}

BOOST_PYTHON_MODULE( crash_test)
{
	using namespace boost::python;
	
	class_< test::ret_type>( "ret_type")
		.def_readwrite( "i", &test::ret_type::i)
		;
	
	class_< test::crash_me> crash_me_wrapper( "crash_me");
	
	crash_me_wrapper
		.def( "get_i", &test::crash_me::get_i , return_internal_reference<>())
		;
	
	// The following works under Boost 1.30, but not CVS-HEAD 
	// (sourceforge repository).
	crash_me_wrapper.add_property( "i", crash_me_wrapper.attr("get_i"));
}

--------------------------------------------------------
Testing with G++ 3.3.2 (Debian) results in the following error using
CVS-HEAD:

/home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp: In
member
   function `boost::python::api::object boost::python::class_<T, X1, X2,
   X3>::make_fn(const F&) [with F =
   boost::python::api::proxy<boost::python::api::attribute_policies>, T
=
   test::crash_me, X1 = boost::python::detail::not_specified, X2 =
   boost::python::detail::not_specified, X3 =
   boost::python::detail::not_specified]':
/home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp:365:  
instantiated from `boost::python::class_<T, X1, X2, X3>&
boost::python::class_<T, X1, X2, X3>::add_property(const char*, Get)
[with Get =
boost::python::api::proxy<boost::python::api::attribute_policies>, T =
test::crash_me, X1 = boost::python::detail::not_specified, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]'
crashme.cpp:38:   instantiated from here
/home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp:429:
error: no
   matching function for call to `get_signature(const
   boost::python::api::proxy<boost::python::api::attribute_policies>&,
   test::crash_me*)'




From lutz_p at gmx.net  Wed Oct 29 12:33:09 2003
From: lutz_p at gmx.net (Lutz Paelike)
Date: Wed, 29 Oct 2003 12:33:09 +0100
Subject: [C++-sig] strange sideeffect or bug of boost.python
Message-ID: <3F9FA575.8070704@gmx.net>

Hi,

i encountered a strange thing when i wanted to create a dictionary object from c++.
The error is after creating the dict with no errors (result!=NULL) a simple PyDict_Check fails with no reason.
I tracked this down through the Python Sources and extracted the essential source of PyDict_Check and inserted
it into the example code below. In the Debugger i see that the ob_type of the new object is somehow screwed up.
And now the strange thing: This error goes away and the code works like expected if i remove the boost include.

Am I missing something or is this a strange side effect ?

I'm using Visual Studio 6 SP5 and a recent boost cvs checkout (about 1-2 weeks old)

Thanks for your help,

Lutz

Here is the code:

///////////////////////////snip//////////////////////////////////////
#include <boost/python.hpp> // comment this out to make it work

#include <string>
#include <iostream>
#include <fstream>
#include <exception>
#include <stdexcept>

#include <Python.h>
#include <compile.h>
#include <eval.h>
#include <dictobject.h>


int main()
{
     Py_Initialize();

	PyObject *the_dict = PyDict_New ();

	if (NULL!=the_dict){

		Py_INCREF(the_dict);

		_typeobject  * dt = &PyDict_Type;

		// PyDict_Check does this. Why isn't this working here?
		bool isT  = ((the_dict)->ob_type == (&PyDict_Type));
		bool isST = PyType_IsSubtype((the_dict)->ob_type, (&PyDict_Type));

		if (isT) printf("the_dict is of type PyDict_Type\n");
		else printf("the_dict is not of type PyDict_Type! Boost.Python Bug?\n");
		
		if (isST) printf("the_dict is of subtype PyDict_Type\n");
		else printf("the_dict is not of subtype PyDict_Type! Boost.Python Bug?\n");

		Py_DECREF(the_dict);

	} else printf("Error creating new dict\n");

	Py_Finalize();

     return 0;
}

///////////////////////////snip//////////////////////////////////////





From RaoulGough at yahoo.co.uk  Wed Oct 29 13:03:06 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 29 Oct 2003 12:03:06 +0000
Subject: [C++-sig] FAQ patch for debugging with gdb under Windows
Message-ID: <uhe1s2qv9.fsf@yahoo.co.uk>

I've written an update to the FAQ which details how to use recent
Windows gdb versions (Cygwin or MinGW) containing my patches for DLL
symbol extraction to debug Python extensions. OK to commit these
changes to the mainline?

----8<---------
*** faq.html.~1.17.~	Fri May 23 22:06:22 2003
--- faq.html	Wed Oct 29 12:00:56 2003
***************
*** 368,378 ****
      solid and "just works" without requiring any special tricks from the
      user.</p>
  
!     <p>Unfortunately for Cygwin and MinGW users, as of this writing gdb on
!     Windows has a very hard time dealing with shared libraries, which could
!     make Greg's approach next to useless for you. My best advice for you is
!     to use Metrowerks C++ for compiler conformance and Microsoft Visual
!     Studio as a debugger when you need one.</p>
  
      <h3>Debugging extensions through Boost.Build</h3>
      If you are launching your extension module tests with <a href=
--- 368,427 ----
      solid and "just works" without requiring any special tricks from the
      user.</p>
  
!     <p>Raoul Gough has provided the following for gdb on Windows:</p>
! 
!     <blockquote>
! 
!       <p>gdb support for Windows DLLs has improved lately, so it is
!       now possible to debug Python extensions using a few
!       tricks. Firstly, you will need an up-to-date gdb with support
!       for minimal symbol extraction from a DLL. Any gdb from version 6
!       onwards, or Cygwin gdb-20030214-1 and onwards should do. A
!       suitable release will have a section in the gdb.info file under
!       Configuration &ndash; Native &ndash; Cygwin Native &ndash;
!       Non-debug DLL symbols. Refer to that info section for more
!       details of the procedures outlined here.</p>
! 
!       <p>Secondly, it seems necessary to set a breakpoint in the
!       Python interpreter, rather than using ^C to break execution. A
!       good place to set this breakpoint is PyOS_Readline, which will
!       stop execution immediately before reading each interactive
!       Python command. You have to let Python start once under the
!       debugger, so that it loads its own DLL, before you can set the
!       breakpoint:
! 
! <pre>
! $ gdb python
! GNU gdb 2003-09-02-cvs (cygwin-special)
! [...]
! 
! (gdb) run
! Starting program: /cygdrive/c/Python22/python.exe
! Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
! Type "help", "copyright", "credits" or "license" for more information.
! &gt;&gt;&gt; ^Z
! 
! 
! Program exited normally.
! (gdb) break *&PyOS_Readline
! Breakpoint 1 at 0x1e04eff0
! (gdb) run
! Starting program: /cygdrive/c/Python22/python.exe
! Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
! Type "help", "copyright", "credits" or "license" for more information.
! 
! Breakpoint 1, 0x1e04eff0 in python22!PyOS_Readline ()
!    from /cygdrive/c/WINNT/system32/python22.dll
! (gdb) cont
! Continuing.
! &gt;&gt;&gt; from my_ext import *
! 
! Breakpoint 1, 0x1e04eff0 in python22!PyOS_Readline ()
!    from /cygdrive/c/WINNT/system32/python22.dll
! (gdb) # my_ext now loaded (with any debugging symbols it contains)
! </pre>
! 
!     </blockquote>
  
      <h3>Debugging extensions through Boost.Build</h3>
      If you are launching your extension module tests with <a href=
----8<---------

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From yakumoklesk at yahoo.es  Wed Oct 29 13:31:01 2003
From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es)
Date: Wed, 29 Oct 2003 13:31:01 +0100
Subject: [C++-sig] strange sideeffect or bug of boost.python
In-Reply-To: <3F9FA575.8070704@gmx.net>
Message-ID: <3F9FC115.11882.389782@localhost>

Something like this happened to me. Maybe youo are compiling a Debug version of your 
application. As boost python makes a wrap include of "python.h" in order to avoid 
compilin with the python_d debug library, you are compiling a debug version without a 
debug python library. To avoid this, in your precompiler definitions in the project in 
visual C just define: BOOST_DEBUG_PYTHON. With this definition you can include the 
necessary bost/python.hpp include file in order to work with bost::python namespace 
objects.

I hope this helped you.

David.

On 29 Oct 2003 at 12:33, Lutz Paelike wrote:

> Hi,
> 
> i encountered a strange thing when i wanted to create a dictionary object from c++.
> The error is after creating the dict with no errors (result!=NULL) a simple PyDict_Check fails with no reason.
> I tracked this down through the Python Sources and extracted the essential source of PyDict_Check and inserted
> it into the example code below. In the Debugger i see that the ob_type of the new object is somehow screwed up.
> And now the strange thing: This error goes away and the code works like expected if i remove the boost include.
> 
> Am I missing something or is this a strange side effect ?
> 
> I'm using Visual Studio 6 SP5 and a recent boost cvs checkout (about 1-2 weeks old)
> 
> Thanks for your help,
> 
> Lutz
> 
> Here is the code:
> 
> ///////////////////////////snip//////////////////////////////////////
> #include <boost/python.hpp> // comment this out to make it work
> 
> #include <string>
> #include <iostream>
> #include <fstream>
> #include <exception>
> #include <stdexcept>
> 
> #include <Python.h>
> #include <compile.h>
> #include <eval.h>
> #include <dictobject.h>
> 
> 
> int main()
> {
>      Py_Initialize();
> 
> 	PyObject *the_dict = PyDict_New ();
> 
> 	if (NULL!=the_dict){
> 
> 		Py_INCREF(the_dict);
> 
> 		_typeobject  * dt = &PyDict_Type;
> 
> 		// PyDict_Check does this. Why isn't this working here?
> 		bool isT  = ((the_dict)->ob_type == (&PyDict_Type));
> 		bool isST = PyType_IsSubtype((the_dict)->ob_type, (&PyDict_Type));
> 
> 		if (isT) printf("the_dict is of type PyDict_Type\n");
> 		else printf("the_dict is not of type PyDict_Type! Boost.Python Bug?\n");
> 		
> 		if (isST) printf("the_dict is of subtype PyDict_Type\n");
> 		else printf("the_dict is not of subtype PyDict_Type! Boost.Python Bug?\n");
> 
> 		Py_DECREF(the_dict);
> 
> 	} else printf("Error creating new dict\n");
> 
> 	Py_Finalize();
> 
>      return 0;
> }
> 
> ///////////////////////////snip//////////////////////////////////////
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig






From lutz_p at gmx.net  Wed Oct 29 15:32:30 2003
From: lutz_p at gmx.net (Lutz Paelike)
Date: Wed, 29 Oct 2003 15:32:30 +0100
Subject: [C++-sig] strange sideeffect or bug of boost.python
In-Reply-To: <3F9FC115.11882.389782@localhost>
References: <3F9FC115.11882.389782@localhost>
Message-ID: <3F9FCF7E.905@gmx.net>

Hi David,

that solved the problem indeed. I isolated some code for debugging in an extra project and forgot to include the 
BOOST_DEBUG_PYTHON definition. Thank you.

Cheers,

Lutz

yakumoklesk at yahoo.es schrieb:

> Something like this happened to me. Maybe youo are compiling a Debug version of your 
> application. As boost python makes a wrap include of "python.h" in order to avoid 
> compilin with the python_d debug library, you are compiling a debug version without a 
> debug python library. To avoid this, in your precompiler definitions in the project in 
> visual C just define: BOOST_DEBUG_PYTHON. With this definition you can include the 
> necessary bost/python.hpp include file in order to work with bost::python namespace 
> objects.
> 
> I hope this helped you.
> 
> David.
> 
> On 29 Oct 2003 at 12:33, Lutz Paelike wrote:
> 
> 
>>Hi,
>>
>>i encountered a strange thing when i wanted to create a dictionary object from c++.
>>The error is after creating the dict with no errors (result!=NULL) a simple PyDict_Check fails with no reason.
>>I tracked this down through the Python Sources and extracted the essential source of PyDict_Check and inserted
>>it into the example code below. In the Debugger i see that the ob_type of the new object is somehow screwed up.
>>And now the strange thing: This error goes away and the code works like expected if i remove the boost include.
>>
>>Am I missing something or is this a strange side effect ?
>>
>>I'm using Visual Studio 6 SP5 and a recent boost cvs checkout (about 1-2 weeks old)
>>
>>Thanks for your help,
>>
>>Lutz
>>
>>Here is the code:
>>
>>///////////////////////////snip//////////////////////////////////////
>>#include <boost/python.hpp> // comment this out to make it work
>>
>>#include <string>
>>#include <iostream>
>>#include <fstream>
>>#include <exception>
>>#include <stdexcept>
>>
>>#include <Python.h>
>>#include <compile.h>
>>#include <eval.h>
>>#include <dictobject.h>
>>
>>
>>int main()
>>{
>>     Py_Initialize();
>>
>>	PyObject *the_dict = PyDict_New ();
>>
>>	if (NULL!=the_dict){
>>
>>		Py_INCREF(the_dict);
>>
>>		_typeobject  * dt = &PyDict_Type;
>>
>>		// PyDict_Check does this. Why isn't this working here?
>>		bool isT  = ((the_dict)->ob_type == (&PyDict_Type));
>>		bool isST = PyType_IsSubtype((the_dict)->ob_type, (&PyDict_Type));
>>
>>		if (isT) printf("the_dict is of type PyDict_Type\n");
>>		else printf("the_dict is not of type PyDict_Type! Boost.Python Bug?\n");
>>		
>>		if (isST) printf("the_dict is of subtype PyDict_Type\n");
>>		else printf("the_dict is not of subtype PyDict_Type! Boost.Python Bug?\n");
>>
>>		Py_DECREF(the_dict);
>>
>>	} else printf("Error creating new dict\n");
>>
>>	Py_Finalize();
>>
>>     return 0;
>>}
>>
>>///////////////////////////snip//////////////////////////////////////
>>
>>
>>
>>_______________________________________________
>>C++-sig mailing list
>>C++-sig at python.org
>>http://mail.python.org/mailman/listinfo/c++-sig
> 
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 
> 






From saspicer at mac.com  Wed Oct 29 17:00:34 2003
From: saspicer at mac.com (Sean Spicer)
Date: Wed, 29 Oct 2003 10:00:34 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
References: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
Message-ID: <07C53A9C-0A29-11D8-92D9-000A95C4839C@mac.com>


Well nuts...looks like I get the same error - I'm not too familiar with 
bjam, and in searching for the origination of the error I can't really 
find much other than the following lines in the Jamfile:

bpl-test crossmod_exception
   : crossmod_exception.py crossmod_exception_a.cpp 
crossmod_exception_b.cpp
   ;

which, I must confess, I don't quite understand.

The error sounds quite simple though, it's looks like it's just a 
conflict between the <warnings> setting (on v. off)

Perhaps I'm missing something though ? I'll keep digging...

sean

On Oct 28, 2003, at 5:47 PM, Ralf W. Grosse-Kunstleve wrote:

> --- Sean Spicer <saspicer at mac.com> wrote:
>>
>> Ralf,
>>
>> gcc -v reports:
>>
>> gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
>>
>> I'd really like to help out and get boost.python running nicely on OS
>> X...but I just started trying today <sheepish grin>, so I may need 
>> some
>> hand-holding.
>
> That's the same version I had so much fun with:
>
> http://cci.lbl.gov/~rwgk/boost_python/
>
> See the first link in the list under Mac OS 10. I am wondering if 
> Apple has
> fixed some of the problems:
>
> - Does the optimizer work? (it works, btw, with gcc 3.3.1)
> - Is it possible to link and run all tests in boost/libs/python/test?
> - Is the horrendous problem fixed that we have to work around in
>   boost/libs/python/src/converter/registry.cpp (look for
>   BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND)?
>
> Since you seem to have bjam working, could you try all tests? cd to
> boost/libs/python/test, issue the bjam command that you worked out, 
> followed by
> the word test. Here is what worked for me a while ago:
>
> bjam -sPYTHON_VERSION=2.3 -sTOOLS=darwin -sBUILD=debug 
> -sRUN_ALL_TESTS=1 test
>
> Unfortunately, trying this with the most current cvs I get
> <@boost!libs!python!test>crossmod_exception_a.so: required property
> <warnings>off incompatible with <warnings>on
>
> Maybe Rene can help?
>
> Ralf
>
>
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
_______________________________________________________________________
Sean A. Spicer

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgpkeys.mit.edu (KEY 
ID: 15859D54)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031029/73da7add/attachment.pgp>

From Harri.Hakula at arabianranta.com  Wed Oct 29 19:40:45 2003
From: Harri.Hakula at arabianranta.com (Harri Hakula)
Date: Wed, 29 Oct 2003 20:40:45 +0200
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
References: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
Message-ID: <68227290-0A3F-11D8-81CD-0050E4601908@arabianranta.com>


On Oct 29, 2003, at 1:47 AM, Ralf W. Grosse-Kunstleve wrote:

>
> Since you seem to have bjam working, could you try all tests? cd to
> boost/libs/python/test, issue the bjam command that you worked out, 
> followed by
> the word test. Here is what worked for me a while ago:
>
> bjam -sPYTHON_VERSION=2.3 -sTOOLS=darwin -sBUILD=debug 
> -sRUN_ALL_TESTS=1 test
>
> Unfortunately, trying this with the most current cvs I get
> <@boost!libs!python!test>crossmod_exception_a.so: required property
> <warnings>off incompatible with <warnings>on
>
With the latest compiler from Apple everything builds even on Jaguar.
I got most of the tests I tried running, but had to compile everything 
manually.
(I feel guilty for never reporting this on the list...)

> Maybe Rene can help?
Once the build system works for Panther/Jaguar we're first class 
citizens.
Or, most likely, we'll find the next stumbling blocks :-)

Cheers,
Harri Hakula




From dave at boost-consulting.com  Wed Oct 29 01:45:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Oct 2003 14:45:00 -1000
Subject: [C++-sig] Re: Naming arguments of exported methods
References: <1067355175.7279.13.camel@pbarbier>
Message-ID: <uvfq8j2ib.fsf@boost-consulting.com>

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

> I'm trying to use the "arg" object as descibed in the CVS documentation
> in "libs/python/doc/v2/args.html" (in your boost directory). It says not
> to use args. But I cannot succeed in making it compile with g++-3.2
> Instead, I have the errors put at the end of the text. For all these
> errors, I just modified the line :
>
> 	.def( "neighbors", cg3d_neighbors)
>
> into :
>
> 	.def( "neighbors", cg3d_neighbors , py_arg( "cell" ) )

It's a bug, which the enclosed patch fixes (yes, I'm checking it in,
nobody needs to ask me).

> I should add that I needed to define:
>
> typedef boost::python::arg py_arg;
>
> because 'arg' is already used in the STL and in boost itself. I hope
> there is enough details.

That's only because you've written using-directives to bring all those
namespaces in without qualification (a bad idea).  You can get around
the problem by adding

    using boost::python::arg;

inside your module initialization function.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: args.patch
Type: text/x-patch
Size: 5576 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031028/0096768c/attachment.bin>
-------------- next part --------------


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

From dave at boost-consulting.com  Wed Oct 29 03:40:15 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Oct 2003 16:40:15 -1000
Subject: [C++-sig] Re: Pyste suggestion: handling void * arguments
References: <3F9CA660.7238.24E2D088@localhost>
	<3F9DCA7B.21864.2957DADB@localhost> <3F9EE819.3000803@esss.com.br>
Message-ID: <uk76og41c.fsf@boost-consulting.com>

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

>> If however you choose the casting route (which is technically
>> undefined behaviour, but I can't see many modern systems
>> differentiating between types of pointers) I can send you my altered
>> pyste. Remember that virtual method overrides in wrapper classes
>> will have to cast anyway no matter what.
>>
>
> I don't know, "undefined behaviour" is never good. Dave, what's your
> opinion on this?

The library should never invoke undefined behavior unless the user
violates its preconditions.

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




From dave at boost-consulting.com  Wed Oct 29 21:14:08 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Oct 2003 10:14:08 -1000
Subject: [C++-sig] Re: FAQ patch for debugging with gdb under Windows
References: <uhe1s2qv9.fsf@yahoo.co.uk>
Message-ID: <un0bjer8v.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> I've written an update to the FAQ which details how to use recent
> Windows gdb versions (Cygwin or MinGW) containing my patches for DLL
> symbol extraction to debug Python extensions. OK to commit these
> changes to the mainline?
Sounds FABULOUS!

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




From RaoulGough at yahoo.co.uk  Wed Oct 29 22:54:18 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 29 Oct 2003 21:54:18 +0000
Subject: [C++-sig] Re: FAQ patch for debugging with gdb under Windows
References: <uhe1s2qv9.fsf@yahoo.co.uk> <un0bjer8v.fsf@boost-consulting.com>
Message-ID: <un0bjbth1.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> I've written an update to the FAQ which details how to use recent
>> Windows gdb versions (Cygwin or MinGW) containing my patches for DLL
>> symbol extraction to debug Python extensions. OK to commit these
>> changes to the mainline?
> Sounds FABULOUS!

OK - it's now checked in on HEAD. I should probably have updated the
"Revised" date at the bottom, but didn't see this in time. Immediately
after committing it, I also noticed that two existing links at the
bottom are broken (on my working copy of CVS, anyway). They reference
nonexistent files in the tutorial section,
reducing_compiling_time.html and creating_packages.html.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Wed Oct 29 23:04:59 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 29 Oct 2003 22:04:59 +0000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com>
	<uoew2eoa4.fsf@yahoo.co.uk>
	<uismapl95.fsf@boost-consulting.com> <uoew12uki.fsf@yahoo.co.uk>
	<uptggj2f7.fsf@boost-consulting.com>
Message-ID: <uism7bsz8.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> My only slight reservation is that it hasn't yet been tested on a
>> compiler without partial template specialization support.
>
> So let's test it!

I don't currently have access to MSVC6, but I think Ralf is going to
try and help me out in this regard. Hopefully will know more about
what problems it presents tomorrow.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From mike at nospam.com  Wed Oct 29 23:13:32 2003
From: mike at nospam.com (Mike Rovner)
Date: Wed, 29 Oct 2003 14:13:32 -0800
Subject: [C++-sig] Anon CVS at SF (was Re: Naming arguments of exported
	methods)
References: <1067355175.7279.13.camel@pbarbier>
	<uvfq8j2ib.fsf@boost-consulting.com>
Message-ID: <bnpe2d$rp2$1@sea.gmane.org>

David Abrahams wrote:
>> It's a bug, which the enclosed patch fixes (yes, I'm checking it in,
>> nobody needs to ask me).

FWIW sf.net anonimous cvs access is pretty good now.
As time of writing this patch already available.

Mike






From saspicer at mac.com  Wed Oct 29 23:19:28 2003
From: saspicer at mac.com (Sean Spicer)
Date: Wed, 29 Oct 2003 16:19:28 -0600
Subject: [C++-sig] Some pyste errors, Question...
Message-ID: <F61664EE-0A5D-11D8-92D9-000A95C4839C@mac.com>


...whom is the appropriate person for me to mail a tarball containing 
errors from a pyste run to (including xml files from pyste.py --debug) 
?

sean

_______________________________________________________________________
Sean A. Spicer

"Your mind is a shovel, use it."  -anonymous

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgpkeys.mit.edu (KEY 
ID: 15859D54)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031029/eb531d54/attachment.pgp>

From mike at nospam.com  Wed Oct 29 23:34:28 2003
From: mike at nospam.com (Mike Rovner)
Date: Wed, 29 Oct 2003 14:34:28 -0800
Subject: [C++-sig] BPL on MSVC7.1 -w3 warnings
Message-ID: <bnpf9k$br0$1@sea.gmane.org>

Dave, are you aware of warnings:

class.cpp
\boost\libs\python\src\object\class.cpp(320) : warning C4146: unary minus
operator applied to unsigned type, result still unsigned

builtin_converters.cpp
\boost\libs\python\src\converter\builtin_converters.cpp(78) : warning C4244:
'initializing' : conversion from 'double' to 'float', possible loss of data
\boost\libs\python\src\converter\builtin_converters.cpp(71) : while
compiling class-template member function 'void
boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python<T,S
lotPolicy>::construct(PyObject
*,boost::python::converter::rvalue_from_python_stage1_data *)'
with
[
T=float,
SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_fro
m_python
]
\boost\libs\python\src\converter\builtin_converters.cpp(397) : see reference
to class template instantiation
'boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python<T,
SlotPolicy>' being compiled
with
[
T=float,
SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_fro
m_python
]

\boost\python\converter\builtin_converters.hpp(114) : warning C4267:
'argument' : conversion from 'size_t' to 'int', possible loss of data
\boost\python\converter\builtin_converters.hpp(116) : warning C4267:
'argument' : conversion from 'size_t' to 'int', possible loss of data

Regards,
Mike






From dave at boost-consulting.com  Thu Oct 30 00:13:27 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Oct 2003 13:13:27 -1000
Subject: [C++-sig] Re: FAQ patch for debugging with gdb under Windows
References: <uhe1s2qv9.fsf@yahoo.co.uk> <un0bjer8v.fsf@boost-consulting.com>
	<un0bjbth1.fsf@yahoo.co.uk>
Message-ID: <usmlbd4dk.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> I've written an update to the FAQ which details how to use recent
>>> Windows gdb versions (Cygwin or MinGW) containing my patches for DLL
>>> symbol extraction to debug Python extensions. OK to commit these
>>> changes to the mainline?
>> Sounds FABULOUS!
>
> OK - it's now checked in on HEAD. I should probably have updated the
> "Revised" date at the bottom, but didn't see this in time. Immediately
> after committing it, I also noticed that two existing links at the
> bottom are broken (on my working copy of CVS, anyway). They reference
> nonexistent files in the tutorial section,
> reducing_compiling_time.html and creating_packages.html.

Hmm, these appear to be Bruno's text.  What's up with that, Bruno?
 
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu Oct 30 00:18:03 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Oct 2003 13:18:03 -1000
Subject: [C++-sig] Re: BPL on MSVC7.1 -w3 warnings
References: <bnpf9k$br0$1@sea.gmane.org>
Message-ID: <uhe1rd45w.fsf@boost-consulting.com>

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

> Dave, are you aware of warnings:
>
> class.cpp
> \boost\libs\python\src\object\class.cpp(320) : warning C4146: unary minus
> operator applied to unsigned type, result still unsigned
  ...

I'm not surprised.  I don't really have time to issue the magic
incantations (mostly static_casts) to silence the warnings right now,
but if you submit a patch I could probably apply it.

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




From dave at boost-consulting.com  Thu Oct 30 00:24:06 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Oct 2003 13:24:06 -1000
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
References: <20031028234755.22716.qmail@web20203.mail.yahoo.com>
	<07C53A9C-0A29-11D8-92D9-000A95C4839C@mac.com>
Message-ID: <ubrrzd3vt.fsf@boost-consulting.com>

Sean Spicer <saspicer at mac.com> writes:

> Well nuts...looks like I get the same error - I'm not too familiar
> with bjam, and in searching for the origination of the error I can't
> really find much other than the following lines in the Jamfile:
>
> bpl-test crossmod_exception
>    : crossmod_exception.py crossmod_exception_a.cpp
>    crossmod_exception_b.cpp
>    ;
>
> which, I must confess, I don't quite understand.
>
> The error sounds quite simple though, it's looks like it's just a
> conflict between the <warnings> setting (on v. off)
>
> Perhaps I'm missing something though ? I'll keep digging...

I don't know why Rene added the <warnings>off requirement for OSX, but
you can deal with this by adding it to the BUILD request:

    bjam ... "-sBUILD=<warnings>off"

for example.

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




From dave at boost-consulting.com  Thu Oct 30 00:14:07 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Oct 2003 13:14:07 -1000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com>
	<uoew2eoa4.fsf@yahoo.co.uk>
	<uismapl95.fsf@boost-consulting.com> <uoew12uki.fsf@yahoo.co.uk>
	<uptggj2f7.fsf@boost-consulting.com> <uism7bsz8.fsf@yahoo.co.uk>
Message-ID: <un0bjd4cg.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
> [snip]
>>> My only slight reservation is that it hasn't yet been tested on a
>>> compiler without partial template specialization support.
>>
>> So let's test it!
>
> I don't currently have access to MSVC6, but I think Ralf is going to
> try and help me out in this regard. Hopefully will know more about
> what problems it presents tomorrow.

I can run the tests if you tell me how to get them on my machine.  I
believe Joel also has vc6.

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




From mike at nospam.com  Thu Oct 30 01:22:51 2003
From: mike at nospam.com (Mike Rovner)
Date: Wed, 29 Oct 2003 16:22:51 -0800
Subject: [C++-sig] Re: BPL on MSVC7.1 -w3 warnings
References: <bnpf9k$br0$1@sea.gmane.org> <uhe1rd45w.fsf@boost-consulting.com>
Message-ID: <bnplks$p3k$1@sea.gmane.org>

David Abrahams wrote:
> "Mike Rovner" <mike at nospam.com> writes:

>> class.cpp
> I'm not surprised.  I don't really have time to issue the magic
> incantations (mostly static_casts) to silence the warnings right now,
> but if you submit a patch I could probably apply it.

Here.



begin 666 bpl.patch
M26YD97 at Z(&QI8G,O<'ET:&]N+W-R8R]O8FIE8W0O8VQA<W,N8W!P"CT]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T*4D-3(&9I;&4Z("]C=G-R;V]T+V)O;W-T+V)O
M;W-T+VQI8G,O<'ET:&]N+W-R8R]O8FIE8W0O8VQA<W,N8W!P+'8*<F5T<FEE
M=FEN9R!R979I<VEO;B Q+C4X"F1I9F8 at +74@+7(Q+C4X(&-L87-S+F-P< HM
M+2T@;&EB<R]P>71H;VXO<W)C+V]B:F5C="]C;&%S<RYC<' ),3D at 075G(#(P
M,#,@,34Z-#0Z,S @+3 P,# ),2XU. HK*RL@;&EB<R]P>71H;VXO<W)C+V]B
M:F5C="]C;&%S<RYC<' ),S @3V-T(#(P,#,@,# Z,C Z-#@@+3 P,# *0$ @
M+3,Q-RPW("LS,3<L-R! 0 H@(" @(" @(" @(" @(" O+R!L:6ME+"!S;R!W
M92=L;"!S=&]R92!T:&4@=&]T86P@<VEZ92!O9B!T:&4@;V)J96-T"B @(" @
M(" @(" @(" @("\O('1H97)E+B!!(&YE9V%T:79E(&YU;6)E<B!I;F1I8V%T
M97,@=&AA="!T:&4 at 97AT<F$*(" @(" @(" @(" @(" @+R\@:6YS=&%N8V4@
M;65M;W)Y(&ES(&YO="!Y970 at 86QL;V-A=&5D('1O(&%N>2!H;VQD97)S+ at HM
M(" @(" @(" @(" @("!R97-U;'0M/F]B7W-I>F4@/2 M*&]F9G-E=&]F*&EN
M<W1A;F-E/#XL<W1O<F%G92D@*R!I;G-T86YC95]S:7IE*3L**R @(" @(" @
M(" @(" @<F5S=6QT+3YO8E]S:7IE(#T at +6EN<W1A;F-E7W-I>F4M;V9F<V5T
M;V8H:6YS=&%N8V4\/BQS=&]R86=E*3L*(" @(" @(" @("!]"B @(" @(" @
F(" @<F5T=7)N("A0>4]B:F5C="HI<F5S=6QT.PH@(" @(" @?0H`
`
end





From grafik.list at redshift-software.com  Thu Oct 30 01:25:52 2003
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Wed, 29 Oct 2003 18:25:52 -0600
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
In-Reply-To: <ubrrzd3vt.fsf@boost-consulting.com>
Message-ID: <20031029182554-r01010800-5f419914-0860-0108@12.100.89.43>

[2003-10-29] David Abrahams wrote:

>Sean Spicer <saspicer at mac.com> writes:
>
>> Well nuts...looks like I get the same error - I'm not too familiar
>> with bjam, and in searching for the origination of the error I can't
>> really find much other than the following lines in the Jamfile:
>>
>> bpl-test crossmod_exception
>>    : crossmod_exception.py crossmod_exception_a.cpp
>>    crossmod_exception_b.cpp
>>    ;
>>
>> which, I must confess, I don't quite understand.
>>
>> The error sounds quite simple though, it's looks like it's just a
>> conflict between the <warnings> setting (on v. off)
>>
>> Perhaps I'm missing something though ? I'll keep digging...
>
>I don't know why Rene added the <warnings>off requirement for OSX, but
>you can deal with this by adding it to the BUILD request:
>
>    bjam ... "-sBUILD=<warnings>off"
>
>for example.

I'm not sure why I added it either ;-) All I can think of now is that once
upon a time the build was getting so many warnings that it would fail.

I'll go remove that requirement as soon as I get a chance.


PS. It's good to hear that things are improving in the MacOSX world... It
gives me hope that I'll be able to port my software :-)


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



From saspicer at mac.com  Thu Oct 30 03:36:29 2003
From: saspicer at mac.com (Sean Spicer)
Date: Wed, 29 Oct 2003 20:36:29 -0600
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031029182554-r01010800-5f419914-0860-0108@12.100.89.43>
References: <20031029182554-r01010800-5f419914-0860-0108@12.100.89.43>
Message-ID: <DDB229D4-0A81-11D8-95BA-000A95C4839C@mac.com>


Okay...this is what I get now:

boxster.local 13> bjam "-sTOOLS=darwin -sBUILD=debug 
-sBUILD=<warnings>off -sRUN_ALL_TESTS=1 test"
-sBUILD=debug-tools.jam: No such file or directory
-sBUILD=<warnings>off-tools.jam: No such file or directory
-sRUN_ALL_TESTS=1-tools.jam: No such file or directory
test-tools.jam: No such file or directory
-sBUILD=debug-tools.jam: No such file or directory
-sBUILD=debug-tools.jam: No such file or directory
-sBUILD=<warnings>off-tools.jam: No such file or directory
-sBUILD=<warnings>off-tools.jam: No such file or directory
-sRUN_ALL_TESTS=1-tools.jam: No such file or directory
-sRUN_ALL_TESTS=1-tools.jam: No such file or directory
test-tools.jam: No such file or directory
test-tools.jam: No such file or directory
-sBUILD=debug-tools.jam: No such file or directory
-sBUILD=debug-tools.jam: No such file or directory
-sBUILD=<warnings>off-tools.jam: No such file or directory
-sBUILD=<warnings>off-tools.jam: No such file or directory
-sRUN_ALL_TESTS=1-tools.jam: No such file or directory
-sRUN_ALL_TESTS=1-tools.jam: No such file or directory
test-tools.jam: No such file or directory
test-tools.jam: No such file or directory
-sBUILD=debug-tools.jam: No such file or directory
-sBUILD=<warnings>off-tools.jam: No such file or directory
-sRUN_ALL_TESTS=1-tools.jam: No such file or directory
test-tools.jam: No such file or directory
<@boost!libs!python!test>crossmod_exception_a.so: required property 
<warnings>off incompatible with <warnings>on

Not much further....

sean

On Oct 29, 2003, at 6:25 PM, Rene Rivera wrote:

> [2003-10-29] David Abrahams wrote:
>
>> Sean Spicer <saspicer at mac.com> writes:
>>
>>> Well nuts...looks like I get the same error - I'm not too familiar
>>> with bjam, and in searching for the origination of the error I can't
>>> really find much other than the following lines in the Jamfile:
>>>
>>> bpl-test crossmod_exception
>>>    : crossmod_exception.py crossmod_exception_a.cpp
>>>    crossmod_exception_b.cpp
>>>    ;
>>>
>>> which, I must confess, I don't quite understand.
>>>
>>> The error sounds quite simple though, it's looks like it's just a
>>> conflict between the <warnings> setting (on v. off)
>>>
>>> Perhaps I'm missing something though ? I'll keep digging...
>>
>> I don't know why Rene added the <warnings>off requirement for OSX, but
>> you can deal with this by adding it to the BUILD request:
>>
>>    bjam ... "-sBUILD=<warnings>off"
>>
>> for example.
>
> I'm not sure why I added it either ;-) All I can think of now is that 
> once
> upon a time the build was getting so many warnings that it would fail.
>
> I'll go remove that requirement as soon as I get a chance.
>
>
> PS. It's good to hear that things are improving in the MacOSX world... 
> It
> gives me hope that I'll be able to port my software :-)
>
>
> -- grafik - Don't Assume Anything
> -- rrivera (at) acm.org - grafik (at) redshift-software.com
> -- 102708583 (at) icq
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
_______________________________________________________________________
Sean A. Spicer

"Your mind is a shovel, use it."  -anonymous

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgpkeys.mit.edu (KEY 
ID: 15859D54)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031029/fb923d43/attachment.pgp>

From grafik.list at redshift-software.com  Thu Oct 30 04:04:53 2003
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Wed, 29 Oct 2003 21:04:53 -0600
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
In-Reply-To: <DDB229D4-0A81-11D8-95BA-000A95C4839C@mac.com>
Message-ID: <20031029210454-r01010800-5b5d5e91-0860-0108@12.100.89.43>

[2003-10-29] Sean Spicer wrote:

>
>Okay...this is what I get now:
>
>boxster.local 13> bjam "-sTOOLS=darwin -sBUILD=debug 
>-sBUILD=<warnings>off -sRUN_ALL_TESTS=1 test"

Very entertaining...

Those are supposed to be _separate_ arguments ;-)

bjam "-sTOOLS=darwin" "-sBUILD=debug <warnings>off" "-sRUN_ALL_TESTS=1"
"test"


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



From rwgk at yahoo.com  Thu Oct 30 07:16:24 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 29 Oct 2003 22:16:24 -0800 (PST)
Subject: [C++-sig] Re: container suite feedback & ideas
In-Reply-To: <un0bjd4cg.fsf@boost-consulting.com>
Message-ID: <20031030061624.82729.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > I don't currently have access to MSVC6, but I think Ralf is going to
> > try and help me out in this regard. Hopefully will know more about
> > what problems it presents tomorrow.

Sorry, I couldn't make it to work today b/o a bug in my biological unit.
(To establish the account for Raoul I need direct access to the machine.)

> I can run the tests if you tell me how to get them on my machine.  I
> believe Joel also has vc6.

Easy!

cd boost
cvs update -d -r indexing_v2 boost/python/suite/indexing libs/python

And now the VC6 forecast: hurricanes, tornados, tsunamis, bad words; all at
once, note the plurals; but still all taking place in the confinement of your
cranium; been there before, moved to VC71 land where I live happily ever since.

Ralf


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/



From joel at boost-consulting.com  Thu Oct 30 07:24:13 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Thu, 30 Oct 2003 14:24:13 +0800
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031025140620.54583.qmail@web20206.mail.yahoo.com><uoew2eoa4.fsf@yahoo.co.uk><uismapl95.fsf@boost-consulting.com>
	<uoew12uki.fsf@yahoo.co.uk><uptggj2f7.fsf@boost-consulting.com>
	<uism7bsz8.fsf@yahoo.co.uk> <un0bjd4cg.fsf@boost-consulting.com>
Message-ID: <00c201c39eae$776e20b0$64646464@godzilla>

David Abrahams <dave at boost-consulting.com> wrote:
> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
> 
>> David Abrahams <dave at boost-consulting.com> writes:
>> 
>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>> [snip]
>>>> My only slight reservation is that it hasn't yet been tested on a
>>>> compiler without partial template specialization support.
>>> 
>>> So let's test it!
>> 
>> I don't currently have access to MSVC6, but I think Ralf is going to
>> try and help me out in this regard. Hopefully will know more about
>> what problems it presents tomorrow.
> 
> I can run the tests if you tell me how to get them on my machine.  I
> believe Joel also has vc6.

I have VC6 but I'm afraid I won't be of help in the next few days because 
I am also currently running after the Nov 3 deadline to get Spirit in shape 
for the boost 1.31.0 release.  

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From joel at boost-consulting.com  Thu Oct 30 07:32:21 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Thu, 30 Oct 2003 14:32:21 +0800
Subject: [C++-sig] Re: container suite feedback & ideas
References: <20031030061624.82729.qmail@web20201.mail.yahoo.com>
Message-ID: <00c701c39eaf$9a70e060$64646464@godzilla>

Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
> And now the VC6 forecast: hurricanes, tornados, tsunamis, bad words; all at
> once, note the plurals; but still all taking place in the confinement of your
> cranium; been there before, moved to VC71 land where I live happily ever
> since. 

In my experience, I sometimes spend more time porting a project to VC6
than developing the project itself with a fairly compliant compiler. This is
especially true if you haven't coded the project with VC6's limitations in mind.
Ahhh... and... don't forget VC7! Fortunately, BPL does not involve itself with 
Borland. Others are not so lucky :(

hurricanes, tornados, tsunamis, bad words; all at once!!!
now multiply that to the power of 10!!!

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From pierre.barbier at cirad.fr  Thu Oct 30 11:52:39 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Thu, 30 Oct 2003 11:52:39 +0100
Subject: [C++-sig] Re: Naming arguments of exported methods
In-Reply-To: <uvfq8j2ib.fsf@boost-consulting.com>
References: <1067355175.7279.13.camel@pbarbier>
	<uvfq8j2ib.fsf@boost-consulting.com>
Message-ID: <1067511157.7002.35.camel@pbarbier>

Thanks, it works fine now :)

And, as Mike Rovner pointed out, the anonymous CVS of SourceForge works
well as well !

Le mer 29/10/2003 ? 01:45, David Abrahams a ?crit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
> 
> > I'm trying to use the "arg" object as descibed in the CVS documentation
> > in "libs/python/doc/v2/args.html" (in your boost directory). It says not
> > to use args. But I cannot succeed in making it compile with g++-3.2
> > Instead, I have the errors put at the end of the text. For all these
> > errors, I just modified the line :
> >
> > 	.def( "neighbors", cg3d_neighbors)
> >
> > into :
> >
> > 	.def( "neighbors", cg3d_neighbors , py_arg( "cell" ) )
> 
> It's a bug, which the enclosed patch fixes (yes, I'm checking it in,
> nobody needs to ask me).
> 
> > I should add that I needed to define:
> >
> > typedef boost::python::arg py_arg;
> >
> > because 'arg' is already used in the STL and in boost itself. I hope
> > there is enough details.
> 
> That's only because you've written using-directives to bring all those
> namespaces in without qualification (a bad idea).  You can get around
> the problem by adding
> 
>     using boost::python::arg;
> 
> inside your module initialization function.
> 
> 
> ______________________________________________________________________
-- 
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 saspicer at mac.com  Thu Oct 30 14:25:52 2003
From: saspicer at mac.com (Sean Spicer)
Date: Thu, 30 Oct 2003 07:25:52 -0600
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031029210454-r01010800-5b5d5e91-0860-0108@12.100.89.43>
References: <20031029210454-r01010800-5b5d5e91-0860-0108@12.100.89.43>
Message-ID: <956223C4-0ADC-11D8-AEA6-000A95C4839C@mac.com>


Glad I could be "entertaining" Grin.

Here's the test result.  Machine is a Powerbook G4 1.25 GHz, OS-X 10.3  
(Panther) with the latest XCode tools.  Only one failed test.

cheers,

sean

...found 3675 targets...
...updating 46 targets...
python-test-target  
../../../bin/boost/libs/python/test/crossmod_exception.test/darwin/ 
debug/warnings-off/crossmod_exception.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/injected.test/darwin/debug/ 
warnings-off/injected.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/properties.test/darwin/debug/ 
warnings-off/properties.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/return_arg.test/darwin/debug/ 
warnings-off/return_arg.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/staticmethod.test/darwin/debug/ 
warnings-off/staticmethod.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/shared_ptr.test/darwin/debug/ 
warnings-off/shared_ptr.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/polymorphism.test/darwin/debug/ 
warnings-off/polymorphism.test
......
----------------------------------------------------------------------
Ran 6 tests in 0.018s

OK
python-test-target  
../../../bin/boost/libs/python/test/auto_ptr.test/darwin/debug/ 
warnings-off/auto_ptr.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/minimal.test/darwin/debug/warnings- 
off/minimal.test
IMPORTING minimal_ext
DONE IMPORTING minimal_ext
python-test-target  
../../../bin/boost/libs/python/test/args.test/darwin/debug/warnings- 
off/args.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/numpy.test/darwin/debug/warnings- 
off/numpy.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/enum.test/darwin/debug/warnings- 
off/enum.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/exception_translator.test/darwin/ 
debug/warnings-off/exception_translator.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/pearu1.test/darwin/debug/warnings- 
off/pearu1.test
b= cltree.basic()
s= <cltree.symbol object at 0x53d50>
c= cltree.constant()
v= cltree.wrapped_variable()
ok
python-test-target  
../../../bin/boost/libs/python/test/try.test/darwin/debug/warnings-off/ 
try.test
running...
constructing complicated: hello, world, 99
constructing complicated: hello, world, 0
destroying complicated: hello, world, 0
destroying complicated: hello, world, 99
Done.
python-test-target  
../../../bin/boost/libs/python/test/keywords.test/darwin/debug/ 
warnings-off/keywords.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/builtin_converters.test/darwin/ 
debug/warnings-off/builtin_converters.test
running...
LONG_LONG supported, testing...
Done.
python-test-target  
../../../bin/boost/libs/python/test/test_pointer_adoption.test/darwin/ 
debug/warnings-off/test_pointer_adoption.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/operators.test/darwin/debug/ 
warnings-off/operators.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/callbacks.test/darwin/debug/ 
warnings-off/callbacks.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/defaults.test/darwin/debug/ 
warnings-off/defaults.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/object.test/darwin/debug/warnings- 
off/object.test
running...
*****************************************************************
Failure in example: class(ref_to_noncopyable())
from line #3 of __main__
Exception raised:
Traceback (most recent call last):
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/doctest.py", line 441, in _run_examples_inner
     compileflags, 1) in globs
   File "<string>", line 1
      class(ref_to_noncopyable())
           ^
  SyntaxError: invalid syntax
*****************************************************************
1 items had failures:
    1 of  55 in __main__
***Test Failed*** 1 failures.

      
PATH="../../../bin/boost/libs/python/build/libboost_python.dylib/ 
darwin/debug/shared-linkable-true/warnings-off:../../../bin/boost/libs/ 
python/test/object_ext.so/darwin/debug/shared-linkable-true/warnings- 
off:":$PATH
     export PATH
      
DYLD_LIBRARY_PATH="../../../bin/boost/libs/python/build/ 
libboost_python.dylib/darwin/debug/shared-linkable-true/warnings- 
off:../../../bin/boost/libs/python/test/object_ext.so/darwin/debug/ 
shared-linkable-true/warnings-off":$DYLD_LIBRARY_PATH
     export DYLD_LIBRARY_PATH
      
PYTHONPATH=../../../bin/boost/libs/python/build/libboost_python.dylib/ 
darwin/debug/shared-linkable-true/warnings-off:../../../bin/boost/libs/ 
python/test/object_ext.so/darwin/debug/shared-linkable-true/warnings- 
off:../../../libs/python/test::
     export PYTHONPATH
       
"/System/Library/Frameworks/Python.framework/Versions/2.3//bin/python"   
  "object.py"

...failed python-test-target  
../../../bin/boost/libs/python/test/object.test/darwin/debug/warnings- 
off/object.test...
python-test-target  
../../../bin/boost/libs/python/test/list.test/darwin/debug/warnings- 
off/list.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/long.test/darwin/debug/warnings- 
off/long.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/dict.test/darwin/debug/warnings- 
off/dict.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/tuple.test/darwin/debug/warnings- 
off/tuple.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/str.test/darwin/debug/warnings-off/ 
str.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/virtual_functions.test/darwin/ 
debug/warnings-off/virtual_functions.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/back_reference.test/darwin/debug/ 
warnings-off/back_reference.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/implicit.test/darwin/debug/ 
warnings-off/implicit.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/data_members.test/darwin/debug/ 
warnings-off/data_members.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/ben_scott1.test/darwin/debug/ 
warnings-off/ben_scott1.test
Name: 11CreatorWrap
python-test-target  
../../../bin/boost/libs/python/test/bienstman1.test/darwin/debug/ 
warnings-off/bienstman1.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/bienstman2.test/darwin/debug/ 
warnings-off/bienstman2.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/bienstman3.test/darwin/debug/ 
warnings-off/bienstman3.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/multi_arg_constructor.test/darwin/ 
debug/warnings-off/multi_arg_constructor.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/iterator.test/darwin/debug/ 
warnings-off/iterator.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/extract.test/darwin/debug/warnings- 
off/extract.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/opaque.test/darwin/debug/warnings- 
off/opaque.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/pickle1.test/darwin/debug/warnings- 
off/pickle1.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/pickle2.test/darwin/debug/warnings- 
off/pickle2.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/pickle3.test/darwin/debug/warnings- 
off/pickle3.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/nested.test/darwin/debug/warnings- 
off/nested.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/docstring.test/darwin/debug/ 
warnings-off/docstring.test
running...
printing module help:
NAME
     docstring_ext

FILE
      
/Users/sspicer/src/boost/bin/boost/libs/python/test/docstring_ext.so/ 
darwin/debug/shared-linkable-true/warnings-off/docstring_ext.so

DESCRIPTION
     A simple test module for documentation strings
     Exercised by docstring.py

CLASSES
     Boost.Python.instance(__builtin__.object)
         X

     class X(Boost.Python.instance)
      |  A simple class wrapper around a C++ int
      |  includes some error-checking
      |
      |  Method resolution order:
      |      X
      |      Boost.Python.instance
      |      __builtin__.object
      |
      |  Methods defined here:
      |
      |  __init__(...)
      |      this is the __init__ function
      |      its documentation has two lines.
      |
      |  value(...)
      |      gets the value of the object
      |
      |   
----------------------------------------------------------------------
      |  Data and other attributes defined here:
      |
      |  __instance_size__ = 20
      |
      |   
----------------------------------------------------------------------
      |  Data and other attributes inherited from Boost.Python.instance:
      |
      |  __dict__ = <dictproxy object at 0x2d1290>
      |
      |  __new__ = <built-in method __new__ of Boost.Python.class object  
at 0x2...
      |      T.__new__(S, ...) -> a new object with type S, a subtype of  
T
      |
      |  __weakref__ = <member '__weakref__' of 'Boost.Python.instance'  
objects...


Done.
python-test-target  
../../../bin/boost/libs/python/test/vector_indexing_suite.test/darwin/ 
debug/warnings-off/vector_indexing_suite.test
running...
Done.
python-test-target  
../../../bin/boost/libs/python/test/map_indexing_suite.test/darwin/ 
debug/warnings-off/map_indexing_suite.test
running...
Done.
...failed updating 1 target...
...updated 45 targets...

On Oct 29, 2003, at 9:04 PM, Rene Rivera wrote:

> bjam "-sTOOLS=darwin" "-sBUILD=debug <warnings>off" "-sRUN_ALL_TESTS=1"

_______________________________________________________________________
Sean A. Spicer

"Your mind is a shovel, use it."  -anonymous

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgpkeys.mit.edu (KEY  
ID: 15859D54)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031030/ce531055/attachment.pgp>

From lutz_p at gmx.net  Thu Oct 30 15:25:18 2003
From: lutz_p at gmx.net (Lutz Paelike)
Date: Thu, 30 Oct 2003 15:25:18 +0100
Subject: [C++-sig] Handling namespaces and dicts in embedded python
Message-ID: <3FA11F4E.9030904@gmx.net>

Hi,

i have the same problem as described in this posting:

http://aspn.activestate.com/ASPN/Mail/Message/python-list/766049

I load a script like this :
#############################
global a

class MyClass:
	def run(self):
		pass
def init(arg):
	global a
	a = MyClass()
def compute(arg):
	a.run()
def destroy(arg):
	del a

init(None)
print a
# prints: <__main__.MyClass instance at 0x008FA800>
#################################

compile it via Py_CompileString and store the codeobject in individual objects.

After that i want to call the compute  function on a regular basis.

I have local dicts associated with the individual objects and a shared global dict

I managed to call the init function inside the compiled code object, but i get this exception:

exceptions.NameError
global name 'MyClass' is not defined
Traceback (most recent call last):
   File "F:/simple_test.py", line 14, in ?
     init(None)
   File "F:/simple_test.py", line 8, in init
     a = MyClass()
NameError: global name 'MyClass' is not defined

Somehow the definitions of my functions and of the class are not stored neither in the local dict nor in the shared 
global dict. However if i add this line to my python code:

globals()["MyClass"] = MyClass

It works, but my program crashes in PyFrame_New then.

Can anybody explain how the namespace is handled in this situation and how to resolve this problem ?

btw i use python 2.3.2 , a recent boost cvs checkout and msvc 6 sp5

If run the script with the normal interpreter it works like expected.

Thanks for your help,

Lutz




From grafik.list at redshift-software.com  Thu Oct 30 15:46:58 2003
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Thu, 30 Oct 2003 08:46:58 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <FDC4F79E-0999-11D8-ACD2-000A95C4839C@mac.com>
Message-ID: <20031030084659-r01010800-d2a47351-0860-0108@12.100.89.43>

[2003-10-28] Sean Spicer wrote:

>
>Okay, I'll do my best...
>
>/System/Libraries/Frameworks/Python.framework:
>
>lrwxr-xr-x  1 root  wheel   24 25 Oct 11:44 Headers -> 
>Versions/Current/Headers
>lrwxr-xr-x  1 root  wheel   23 24 Oct 16:37 Python -> 
>Versions/Current/Python
>lrwxr-xr-x  1 root  wheel   26 24 Oct 16:37 Resources -> 
>Versions/Current/Resources
>drwxr-xr-x  4 root  wheel  136 13 Sep 21:40 Versions
>
>I believe the relevant location is Versions/Current:
>
>lrwxr-xr-x  1 root  wheel       17 25 Oct 11:44 Headers -> 
>include/python2.3
>drwxr-xr-x  3 root  wheel      102 27 Sep 04:39 Mac
>-rwxr-xr-x  1 root  wheel  1088276 26 Sep 01:40 Python
>drwxr-xr-x  7 root  wheel      238 27 Sep 04:39 Resources
>drwxr-xr-x  6 root  wheel      204 27 Sep 04:38 bin
>drwxr-xr-x  3 root  wheel      102 27 Sep 04:38 include
>drwxr-xr-x  3 root  wheel      102 13 Sep 21:40 lib
>
>Each of these directories looks pretty much like you'd find on Linux in 
>/usr/local/
>
>Does that help ?

Only a little :-(

I'm changin the code now but I need a bit more info. Specifically I need to
know how we can specify the framework so that we get the specific version
(2.3) instead of the default (Current).

Could try specifying the framework as:

    <framework>Python/Versions/2.3

And for that matter could you check to see if you have:

    /System/Libraries/Frameworks/Python.framework/Versions/2.3

Or if that versioned path doesn't exist try this framework spec:

<framework>/System/Libraries/Frameworks/Python.framework/Versions/Current


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



From RaoulGough at yahoo.co.uk  Thu Oct 30 16:08:16 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 30 Oct 2003 15:08:16 +0000
Subject: [C++-sig] Re: container suite feedback & ideas
References: <un0bjd4cg.fsf@boost-consulting.com>
	<20031030061624.82729.qmail@web20201.mail.yahoo.com>
Message-ID: <ubrryrcf3.fsf@yahoo.co.uk>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> > I don't currently have access to MSVC6, but I think Ralf is going to
>> > try and help me out in this regard. Hopefully will know more about
>> > what problems it presents tomorrow.
>
> Sorry, I couldn't make it to work today b/o a bug in my biological unit.
> (To establish the account for Raoul I need direct access to the machine.)

Funny, I've just gotten over a cold, but I didn't think I could give
it to anyone via a mailing list!

>
>> I can run the tests if you tell me how to get them on my machine.  I
>> believe Joel also has vc6.
>
> Easy!
>
> cd boost
> cvs update -d -r indexing_v2 boost/python/suite/indexing libs/python
>
> And now the VC6 forecast: hurricanes, tornados, tsunamis, bad words;
> all at once, note the plurals; but still all taking place in the
> confinement of your cranium; been there before, moved to VC71 land
> where I live happily ever since.

If anyone does want to try it out in the mean time, I would suggest
starting with testnonlinear.cpp - it already attempts to workaround
the partial specialization limitation (untested, of course). I suspect
there will be issues with this anyway (in particular, there is a
specialized value_traits for the container_proxy value type), not to
mention all the other VC6 limitations I don't know about.

How important is MSVC6 support with respect to putting indexing_v2
into the next release? Time is getting a bit short, if this compiler
is going to present as many difficulties as everybody seems to think.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From sspicer at magic-earth.com  Thu Oct 30 16:34:52 2003
From: sspicer at magic-earth.com (Sean Spicer)
Date: Thu, 30 Oct 2003 09:34:52 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <20031030084659-r01010800-d2a47351-0860-0108@12.100.89.43>
References: <20031030084659-r01010800-d2a47351-0860-0108@12.100.89.43>
Message-ID: <9AA9020E-0AEE-11D8-B47F-000A95C4839C@magic-earth.com>


Hi Rene,

On Oct 30, 2003, at 8:46 AM, Rene Rivera wrote:

> [2003-10-28] Sean Spicer wrote:
>
>>
>> Okay, I'll do my best...
>>
>> /System/Libraries/Frameworks/Python.framework:
>>
>> lrwxr-xr-x  1 root  wheel   24 25 Oct 11:44 Headers ->
>> Versions/Current/Headers
>> lrwxr-xr-x  1 root  wheel   23 24 Oct 16:37 Python ->
>> Versions/Current/Python
>> lrwxr-xr-x  1 root  wheel   26 24 Oct 16:37 Resources ->
>> Versions/Current/Resources
>> drwxr-xr-x  4 root  wheel  136 13 Sep 21:40 Versions
>>
>> I believe the relevant location is Versions/Current:
>>
>> lrwxr-xr-x  1 root  wheel       17 25 Oct 11:44 Headers ->
>> include/python2.3
>> drwxr-xr-x  3 root  wheel      102 27 Sep 04:39 Mac
>> -rwxr-xr-x  1 root  wheel  1088276 26 Sep 01:40 Python
>> drwxr-xr-x  7 root  wheel      238 27 Sep 04:39 Resources
>> drwxr-xr-x  6 root  wheel      204 27 Sep 04:38 bin
>> drwxr-xr-x  3 root  wheel      102 27 Sep 04:38 include
>> drwxr-xr-x  3 root  wheel      102 13 Sep 21:40 lib
>>
>> Each of these directories looks pretty much like you'd find on Linux  
>> in
>> /usr/local/
>>
>> Does that help ?
>
> Only a little :-(
>
> I'm changin the code now but I need a bit more info. Specifically I  
> need to
> know how we can specify the framework so that we get the specific  
> version
> (2.3) instead of the default (Current).
>
> Could try specifying the framework as:
>
>     <framework>Python/Versions/2.3

Done, no go.

> And for that matter could you check to see if you have:
>
>     /System/Libraries/Frameworks/Python.framework/Versions/2.3

Nope, but I have  
/System/Library/Frameworks/Python.framework/Versions/2.3. Grin.
                                                       ^^^

> Or if that versioned path doesn't exist try this framework spec:
>
> <framework>/System/Libraries/Frameworks/Python.framework/Versions/ 
> Current
>

This one doesn't work either.

I think with 10.3 what you really want to specify on the compile line  
is "-framework Python" it won't take a path switch.  There's some way  
to setup the versioning match in then environment with the  
$HOME/.MacOSX/environment.plist stuff, but I'm having trouble finding  
it via google this morning.

Of course, if your an old UNIX hack like me, you can also just build  
python by hand (use the --enable-framework switch) and update your  
frameworks manually. Grin.

cheers,

sean

________________________________________________________________
Sean Spicer
Sr. Development Lead
Magic Earth, Inc (A Halliburton Company)
www.magic-earth.com

pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8  FB11 E044 F6B8 1585 9D54
pgp public key available at www.keyserver.net or pgpkeys.mit.edu (KEY  
ID: 15859D54)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031030/c6d9b8bd/attachment.pgp>

From joel at boost-consulting.com  Thu Oct 30 17:18:55 2003
From: joel at boost-consulting.com (Joel de Guzman)
Date: Fri, 31 Oct 2003 00:18:55 +0800
Subject: [C++-sig] Re: container suite feedback & ideas
References: <un0bjd4cg.fsf@boost-consulting.com><20031030061624.82729.qmail@web20201.mail.yahoo.com>
	<ubrryrcf3.fsf@yahoo.co.uk>
Message-ID: <008001c39f01$88cff6a0$64646464@godzilla>

Raoul Gough <RaoulGough at yahoo.co.uk> wrote:

> If anyone does want to try it out in the mean time, I would suggest
> starting with testnonlinear.cpp - it already attempts to workaround
> the partial specialization limitation (untested, of course). I suspect
> there will be issues with this anyway (in particular, there is a
> specialized value_traits for the container_proxy value type), not to
> mention all the other VC6 limitations I don't know about.
> 
> How important is MSVC6 support with respect to putting indexing_v2
> into the next release? Time is getting a bit short, if this compiler
> is going to present as many difficulties as everybody seems to think.

FWIW, the current indexing suite works on VC6 and 7. Why hurry?

One thing that I don't quite understand with the new indexing suite
is why it didn't build up on what's already existing. Support for these
compilers has been there from the start. It seems rather wasteful
to throw away what has been developed. Porting to VC6/7 is something
that you'd not want to repeat.

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net




From grafik.list at redshift-software.com  Thu Oct 30 17:29:23 2003
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Thu, 30 Oct 2003 10:29:23 -0600
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <9AA9020E-0AEE-11D8-B47F-000A95C4839C@magic-earth.com>
Message-ID: <20031030102923-r01010800-d07adb48-0860-0108@12.100.89.43>

[2003-10-30] Sean Spicer wrote:

>
>Hi Rene,
>
>On Oct 30, 2003, at 8:46 AM, Rene Rivera wrote:
>
>> Could try specifying the framework as:
>>
>>     <framework>Python/Versions/2.3
>
>Done, no go.
>
>> And for that matter could you check to see if you have:
>>
>>     /System/Libraries/Frameworks/Python.framework/Versions/2.3
>
>Nope, but I have  
>/System/Library/Frameworks/Python.framework/Versions/2.3. Grin.
>                                                       ^^^

Well that's strange.

>> Or if that versioned path doesn't exist try this framework spec:
>>
>> <framework>/System/Libraries/Frameworks/Python.framework/Versions/ 
>> Current
>>
>
>This one doesn't work either.
>
>I think with 10.3 what you really want to specify on the compile line  
>is "-framework Python" it won't take a path switch.  There's some way  
>to setup the versioning match in then environment with the  
>$HOME/.MacOSX/environment.plist stuff, but I'm having trouble finding  
>it via google this morning.

It looks like they changed this for 10.3/gcc-3.3 :-( Just like Apple to keep
breaking things.

But reading some of the new 10.3 docs I have something else for you to
try... Instead of just the <framework>Python use:

    <framework>Python
    <linkflags>-F/System/Library/Frameworks/Python.framework/Versions/2.3.

>Of course, if your an old UNIX hack like me, you can also just build  
>python by hand (use the --enable-framework switch) and update your  
>frameworks manually. Grin.

Well, yes, but having it work without any user changes is the goal ;-)


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



From nickm at sitius.com  Thu Oct 30 19:41:05 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Thu, 30 Oct 2003 13:41:05 -0500
Subject: [C++-sig] bad iterator related warning
Message-ID: <3FA15B41.921185A0@sitius.com>

I updated from the CVS and now I am getting scary warning 
wherever I have used python::iterator<>:

d:\shared\boost_1_31_0\boost\boost\python\object\iterator.hpp(66) :
warning C4172: returning address of local variable or temporary
       
d:\projects\boost_1_31_0\boost\boost\python\object\iterator.hpp(63) :
while compiling class-template member function 'struct OBJ &__thiscall
boost::python::objects::iterator_range<struct
boost::python::return_value_policy<struct boost
::python::return_by_value,struct
boost::python::default_call_policies>,struct
OBJARR::iterator>::next::operator ()(struct
boost::python::objects::iterator_range<struct
boost::python::return_value_policy<struct
boost::python::return_by_value,struct b
oost::python::default_call_policies>,struct OBJARR::iterator> &)'

the sample code reproducing it follows

Thanks,

Nikolay Mladenov



#include <boost/python.hpp>

struct OBJ{
public :
    OBJ(int p=0):prop(p){}
    int prop;
};

struct OBJARR{
    struct iterator : std::iterator<std::input_iterator_tag, OBJ>{
		bool operator == (const iterator &other)const {return other.p==p;}
		bool operator != (const iterator &other)const {return other.p!=p;}
		OBJ operator *() const {return *p;}
		iterator &operator ++() {++p; return *this;}
		iterator operator ++(int) {iterator res = *this ; ++p; return res;}

        iterator(int *ptr):p(ptr){}
    private:
        int *p;
    };
    iterator begin() { return iterator(p); }
    iterator end() { return iterator(p+10); }
private:
        int p[10];
};


namespace python = boost::python;

BOOST_PYTHON_MODULE(iter)
{
        python::class_<OBJ>("OBJ", python::init<int> ());
        python::class_<OBJARR>("OBJARR")
            .def("__iter__",
python::iterator<OBJARR,python::return_value_policy<python::return_by_value>
>() );
        ;
    
}




From dave at boost-consulting.com  Thu Oct 30 19:39:35 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 30 Oct 2003 08:39:35 -1000
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
References: <20031029210454-r01010800-5b5d5e91-0860-0108@12.100.89.43>
	<956223C4-0ADC-11D8-AEA6-000A95C4839C@mac.com>
Message-ID: <uoevy6048.fsf@boost-consulting.com>

Sean Spicer <saspicer at mac.com> writes:

> *****************************************************************
> Failure in example: class(ref_to_noncopyable())
> from line #3 of __main__
> Exception raised:
> Traceback (most recent call last):
>    File
>    "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
>    python2.3/doctest.py", line 441, in _run_examples_inner
>      compileflags, 1) in globs
>    File "<string>", line 1
>       class(ref_to_noncopyable())
>            ^
>   SyntaxError: invalid syntax
> *****************************************************************

Hmm, I wonder when that became illegal and why I didn't notice it
sooner.

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




From rwgk at yahoo.com  Thu Oct 30 19:45:21 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 Oct 2003 10:45:21 -0800 (PST)
Subject: [C++-sig] Re: boost.python on OS X 10.3 (Panther)
In-Reply-To: <uoevy6048.fsf@boost-consulting.com>
Message-ID: <20031030184521.94205.qmail@web20205.mail.yahoo.com>

The same syntax error happens under Redhat 8, gcc 3.2, Python 2.2.1.
I believe it probably never worked anywhere. How about this:

>>> type(ref_to_noncopyable())
<class 'object_ext.NotCopyable'>


--- David Abrahams <dave at boost-consulting.com> wrote:
> Sean Spicer <saspicer at mac.com> writes:
> 
> > *****************************************************************
> > Failure in example: class(ref_to_noncopyable())
> > from line #3 of __main__
> > Exception raised:
> > Traceback (most recent call last):
> >    File
> >    "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
> >    python2.3/doctest.py", line 441, in _run_examples_inner
> >      compileflags, 1) in globs
> >    File "<string>", line 1
> >       class(ref_to_noncopyable())
> >            ^
> >   SyntaxError: invalid syntax
> > *****************************************************************
> 
> Hmm, I wonder when that became illegal and why I didn't notice it
> sooner.


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/



From rwgk at yahoo.com  Thu Oct 30 20:38:02 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 Oct 2003 11:38:02 -0800 (PST)
Subject: [C++-sig] boost.python on OS X 10.3 (Panther)
In-Reply-To: <68227290-0A3F-11D8-81CD-0050E4601908@arabianranta.com>
Message-ID: <20031030193802.6897.qmail@web20205.mail.yahoo.com>

--- Harri Hakula <Harri.Hakula at arabianranta.com> wrote:
> With the latest compiler from Apple everything builds even on Jaguar.
> I got most of the tests I tried running, but had to compile everything 
> manually.

I am trying to reproduce this. I have Mac OS 10.2.8 with the August 2003 gcc
update from Apple's web site. Compilation is fine but I am having trouble
linking libboost_python.dylib. Could you please post the commands that you
issued manually?
Thanks,
        Ralf


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/



From nickm at sitius.com  Thu Oct 30 23:39:13 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Thu, 30 Oct 2003 17:39:13 -0500
Subject: [C++-sig] Re: bad iterator related warning - Solved
References: <3FA15B41.921185A0@sitius.com>
Message-ID: <3FA19311.C19DC158@sitius.com>

I specified void as reference type of the std::iterator and it worked.
I guess this kind of iterators shouldn't really use the default template
params anyway. 

Thanks




From rcalaga at bnl.gov  Fri Oct 31 01:18:44 2003
From: rcalaga at bnl.gov (Rama Calaga)
Date: Thu, 30 Oct 2003 19:18:44 -0500
Subject: [C++-sig] c++/python
Message-ID: <3FA1AA64.7030703@bnl.gov>

Hi, I use mainly python for my research work and only recently had to 
integrate some of my code to c++ code that is already existing. 
Basically, I would like to call (run) "xyz.py" from inside some existing 
C++ code, take an array of values as input arg into xyz.py and output a 
list of numbers that will be used in the latter part of the c++ code. 
Can someone suggest a good and easy way to implement this.
I use Numeric, MLab, LinearAlgebra and some generic python modules in my 
python code.

thanks
ram




From s_sourceforge at nedprod.com  Fri Oct 31 03:28:10 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 31 Oct 2003 02:28:10 -0000
Subject: [C++-sig] Pyste suggestion: handling void * arguments
In-Reply-To: <3F9EE819.3000803@esss.com.br>
References: <3F9DCA7B.21864.2957DADB@localhost>
Message-ID: <3FA1C8BA.25020.38F0FEF0@localhost>

On 28 Oct 2003 at 19:05, Nicodemus wrote:

> >You're nearly there. I foresee two options here - either make void *
> >a container where python can access the pointer or make it an opaque
> >type. Mixing the two creates confusion IMHO.
> 
> Acess void* in Python? What for? You won't be able to do anything with
> it, except pass it to other C++ functions that accept void* too. And
> then the code above would take care of that, creating automatic
> wrappers for this functions too.

You can alter it like an long integer - add and subtract offsets, set 
to fixed locations etc. I'm not saying it's all that common, but it 
would offer the ability for python to use pointers*

(*: Many would consider adding pointers to python a real retrograde 
step. I'm not saying it's a good idea, but it is useful in selected 
instances)

> >If you're going for opaque, you don't define void_ptr at all. This
> >lets you catch when you're returning void * but have forgotten to
> >specify return_opaque_pointer. Even better if pyste does this for you
> > automagically.
> 
> Sorry, I didn't understand you. You mean that when a function returns
> void*, Pyste could automatically set its default policy for
> return_opaque_pointer? That would be the optimal solution, but
> return_opaque_pointer doesn't work with void*, or am I wrong?

Sorry, I wasn't being clear. If you declare a type (can't be void *) 
to be opaque under BPL, then you don't define it. You just do:

struct void_ptr;

... and that's it. Best to leave it undefined because then failing to 
set return_opaque_pointer policy causes a compile-time error and 
until you add the array-indexed policy setting, we need errors where 
at least one overload returns void *.

> >Your problem with generating wrappers is passing parameters in a
> >fashion which doesn't cause problems. Most specifically, you must
> >avoid copy construction when parameters are entering any C++ code.
> >I've found call_traits::param_type to be useful here, but I'd imagine
> > pyste would know when it can pass by reference and when not without
> >that.
> 
> Hmm, I see. But what's the problem with extra copy construction? You
> mean performance, or some other problem?

More that some classes either (a) don't implement copying and worse 
(b) their copy constructor does a destructive copy. Especially in the 
latter case a copy construction is *fatal* to continued program 
operation as it alters the semantics of the C++ ABI.

See the multithreading patch to invoke.hpp I posted here a week or so 
ago. You'll note the care I went to to avoid copy construction in the 
parameters (returns may need it too, though that's rare).

> >If however you choose the casting route (which is technically 
> >undefined behaviour, but I can't see many modern systems 
> >differentiating between types of pointers) I can send you my altered
> >pyste. Remember that virtual method overrides in wrapper classes will
> > have to cast anyway no matter what.
> 
> I don't know, "undefined behaviour" is never good. Dave, what's your
> opinion on this?

It's no more undefined than the is_polymorphic trick in type_traits.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031031/04cdc042/attachment.pgp>

From RaoulGough at yahoo.co.uk  Fri Oct 31 15:56:31 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 31 Oct 2003 14:56:31 +0000
Subject: [C++-sig] boost::python::range and duplicate comdat under MSVC 6
Message-ID: <u8yn1h2w0.fsf@yahoo.co.uk>

Thanks once again to Ralf, I'm working with indexing_v2 under MSVC6. I
have succeeded in compiling one of the test programs (testnonlinear)
but in the process noticed a bug that seems to crop up whenever a
module defines two or more instances of boost::python::range with the
same call policies. It results in a link-time error like the
following:

iterator.obj : fatal error LNK1179: invalid or corrupt file: duplicate comdat
"?registration@?$shared_ptr_from_python at U?$iterator_range at U?$return_value_policy at Ureturn_by_value@python at boost@@$D"

Neither dumpbin nor undname make any sense of the identifier, and I
haven't tracked down where the symbol is getting defined. I can only
think that there's a template getting instantiated without the
iterator_range template arguments, and therefore comes out as the same
"decorated" symbol in all cases...  Any ideas what's really going on
here?

Demo program (heavily edited libs/python/test/iterator.cpp)

-------8<-------------------
#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/python/iterator.hpp>
#include <list>

typedef std::list<int> list_int;
typedef std::list<double> list_double;

list_int::iterator begin_list_int (list_int& x) { return x.begin(); }
list_int::iterator end_list_int (list_int& x) { return x.end(); }
list_double::iterator begin_list_double (list_double& x) { return x.begin(); }
list_double::iterator end_list_double (list_double& x) { return x.end(); }

BOOST_PYTHON_MODULE(iterator_ext)
{
  using namespace boost::python;

  class_<list_int>("list_int")
    .def("__iter__", range (&begin_list_int, &end_list_int))
    ;

  class_<list_double>("list_double")
    .def("__iter__", range (begin_list_double, end_list_double))
    ;
}
-------8<-------------------

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)




From nickm at sitius.com  Fri Oct 31 18:00:20 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 31 Oct 2003 12:00:20 -0500
Subject: [C++-sig] function::argument_error / overloads & docstrings
Message-ID: <3FA29524.7B88DEA6@sitius.com>

I had to change function::argument_error because it was throwing
exception (MSVC6.5 built)

$ cvs diff function.cpp
Index: function.cpp
===================================================================
RCS file: /boost/boost/libs/python/src/object/function.cpp,v
retrieving revision 1.36
diff -r1.36 function.cpp
266c266
<                 str(s[n].basename) + (s[n].lvalue ? " {lvalue}" : "")
---
>                 str(s[n].basename) + (s[n].lvalue ? str(" {lvalue}") : istr(""))



Then I played a bit and end up with this:

$ cvs diff function.cpp
Index: function.cpp
===================================================================
RCS file: /boost/boost/libs/python/src/object/function.cpp,v
retrieving revision 1.36
diff -r1.36 function.cpp
256c256,257
<
---
>
>         bool f_has_keywords = f->m_arg_names.ptr()!= Py_None && PyTuple_Size(f->m_arg_names.ptr()) != 0;
263,267c264,281
<             }
<
<             formal.append(
<                 str(s[n].basename) + (s[n].lvalue ? " {lvalue}" : "")
<                 );
---
>             }
>
>             object arg(s[n].lvalue ? str(" {lvalue}") : str(""));
>             if( f_has_keywords ){
>                 PyObject* kv = PyTuple_GET_ITEM(f->m_arg_names.ptr(), n-1);
>                 if(kv != Py_None)
>                     if(PyTuple_Size(kv) == 1)
>                         arg = " %s"% object(handle<>(incref(kv)));
>                     else{
>                         if(PyString_CheckExact(PyTuple_GET_ITEM(kv, 1)))
>                             arg = " %s=\"%s\""% object(handle<>(incref(kv)));
>                         else
>                             arg = " %s=%s"% object(handle<>(incref(kv)));
>                     }
>             }
>             formal.append(
>                 str(s[n].basename) + arg
>                 );



It formats the functions to include the arg names and the default arg
values if available.
Like that:

>>> kwd.Foo(.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    Foo.__init__(Foo, float)
did not match C++ signature:
    __init__(struct _object *, int a=0, double b=0.0, class
_STL::basic_string<c
har,struct std::char_traits<char>,class _STL::allocator<char> > n="")
>>> kwd.Bar(.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    Bar.__init__(Bar, float)
did not match C++ signature:
    __init__(struct _object *, int a=0, double b=0.0, struct Foo
n=<keywords.Foo
 object at 0x007B73A0>)
>>>


What do you think about it. Is it a useful patch.
I am thinking that something like that can be done for the document
strings
when there are function overloads. It is probably possible to print the
list of the
overloads with the corresponding docstrings instead of just printing one
docstring.


Nikolay Mladenov




From nickm at sitius.com  Fri Oct 31 18:11:25 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 31 Oct 2003 12:11:25 -0500
Subject: [C++-sig] Re: boost::python::range and duplicate comdat under MSVC 6
References: <u8yn1h2w0.fsf@yahoo.co.uk>
Message-ID: <3FA297BD.7E9F6431@sitius.com>

I have seen this couple of times. 
I seems the MSVC cuts the names to a certain position and 
when you have many namespaces and templates you can end up with two
names 
that are different after this cutting point.
I was solving it by rearranging the names.

Nikolay Mladenov


Raoul Gough wrote:
> 
> Thanks once again to Ralf, I'm working with indexing_v2 under MSVC6. I
> have succeeded in compiling one of the test programs (testnonlinear)
> but in the process noticed a bug that seems to crop up whenever a
> module defines two or more instances of boost::python::range with the
> same call policies. It results in a link-time error like the
> following:
> 
> iterator.obj : fatal error LNK1179: invalid or corrupt file: duplicate comdat
> "?registration@?$shared_ptr_from_python at U?$iterator_range at U?$return_value_policy at Ureturn_by_value@python at boost@@$D"
> 
> Neither dumpbin nor undname make any sense of the identifier, and I
> haven't tracked down where the symbol is getting defined. I can only
> think that there's a template getting instantiated without the
> iterator_range template arguments, and therefore comes out as the same
> "decorated" symbol in all cases...  Any ideas what's really going on
> here?
> 
> Demo program (heavily edited libs/python/test/iterator.cpp)
> 
> -------8<-------------------
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/iterator.hpp>
> #include <list>
> 
> typedef std::list<int> list_int;
> typedef std::list<double> list_double;
> 
> list_int::iterator begin_list_int (list_int& x) { return x.begin(); }
> list_int::iterator end_list_int (list_int& x) { return x.end(); }
> list_double::iterator begin_list_double (list_double& x) { return x.begin(); }
> list_double::iterator end_list_double (list_double& x) { return x.end(); }
> 
> BOOST_PYTHON_MODULE(iterator_ext)
> {
>   using namespace boost::python;
> 
>   class_<list_int>("list_int")
>     .def("__iter__", range (&begin_list_int, &end_list_int))
>     ;
> 
>   class_<list_double>("list_double")
>     .def("__iter__", range (begin_list_double, end_list_double))
>     ;
> }
> -------8<-------------------
> 
> --
> Raoul Gough.
> (setq dabbrev-case-fold-search nil)




From RaoulGough at yahoo.co.uk  Fri Oct 31 20:19:16 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Fri, 31 Oct 2003 19:19:16 +0000
Subject: [C++-sig] Re: boost::python::range and duplicate comdat under MSVC 6
References: <u8yn1h2w0.fsf@yahoo.co.uk> <3FA297BD.7E9F6431@sitius.com>
Message-ID: <u1xstgqq3.fsf@yahoo.co.uk>

Nikolay Mladenov <nickm at sitius.com> writes:

> Raoul Gough wrote:
>> iterator.obj : fatal error LNK1179: invalid or corrupt file:
>> duplicate comdat
>> "?registration@?$shared_ptr_from_python at U?$iterator_range at U?$return_
value_policy at Ureturn_by_value@python at boost@@$D"
>> 
> I have seen this couple of times.  I seems the MSVC cuts the names
> to a certain position and when you have many namespaces and
> templates you can end up with two names that are different after
> this cutting point.  I was solving it by rearranging the names.

Hmmm... The symbol that the linker complains about is only about 120
characters long (at least that's the symbol it is reporting). I'm sure
the compiler can successfully handle names much longer than that.

Since you mention it though, I've now tried changing the example to
use int * and double * as iterators instead of list iterators to
reduce the length of any mangled names. The linker problem persists,
and using "dumpbin /symbols", I can see some (working) identifiers
that include the full iterator_range type info, e.g.:

?converters@?$registered_base at AAU?$iterator_range at U?$return_value
_policy at Ureturn_by_value@python at boost@@Udefault_call_policies at 23@
@python at boost@@PAPAN at objects@python at boost@@@detail at converter@pyth
on at boost@@2ABUregistration at 345@B
(public: static struct boost::python::converter::registration con
st & const  boost::python::converter::detail::registered_base<str
uct boost::python::objects::iterator_range<struct boost::python::
return_value_policy<struct boost::python::return_by_value,struct 
boost::python::default_call_policies>,double * *> &>::converters)

However, the problematic symbol doesn't demangle (or "undecorate")
properly:

?registration@?$shared_ptr_from_python at U?$iterator_range at U?$retur
n_value_policy at Ureturn_by_value@python at boost@@$E
( ??  ?? :: ?? ::registration)

Weird. I'd be interested to know where the symbol comes from - there
might be some way to force the two instaces of it to get different
names.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)