From foo.Clark at gmail.com  Fri Jul  1 04:08:29 2005
From: foo.Clark at gmail.com (Clark)
Date: Fri, 1 Jul 2005 10:08:29 +0800
Subject: [C++-sig] How to deal with array?
Message-ID: <20050701020828.GA14499@BigDell>

Hi,
Can I expose a C++ array to python with Boost.Python? And Can I use a
python list conveniently in C++? 

For example, there is a C++ class as follows
    class A
    {
    private:
        int c[4];
    public:
        int d[10];

        void set(int *n)
        {
            for(int i = 0; i < 4; ++i)
                c[i] = n[i]
        }
    }
and I want use class A above in Python like this
    a = A()
    print a.d[2]
    n = [1, 2, ,3, 4]
    a.set(n)

Can you give me some hints?


From rwgk at yahoo.com  Fri Jul  1 09:01:32 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Jul 2005 00:01:32 -0700 (PDT)
Subject: [C++-sig] How to deal with array?
In-Reply-To: <20050701020828.GA14499@BigDell>
Message-ID: <20050701070132.44458.qmail@web31509.mail.mud.yahoo.com>

There are a number of possible solutions. One that I explored recently and is
particularly non-intrusive goes like this:

1. Copy this file to your space (remove the #include <gltbx/...> if it is still
version 1.1.1.1) and change the namespaces to your liking:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/gltbx/pointer_args_bpl.h?view=markup

2. Implement a thin wrapper like this (untested):

  void
  A_set(A& self, boost::python::object const& py_n)
  {
    boost_python::converter<int> n_proxy("n", py_n, 4, false);
    int* n = n_proxy.get();
    A.set(n);
  }

3. Wrap like this (also untested):

  class_<A>("A")
    .def("set", A_set)
  ;

HTH,
        Ralf

--- Clark <foo.Clark at gmail.com> wrote:

> Hi,
> Can I expose a C++ array to python with Boost.Python? And Can I use a
> python list conveniently in C++? 
> 
> For example, there is a C++ class as follows
>     class A
>     {
>     private:
>         int c[4];
>     public:
>         int d[10];
> 
>         void set(int *n)
>         {
>             for(int i = 0; i < 4; ++i)
>                 c[i] = n[i]
>         }
>     }
> and I want use class A above in Python like this
>     a = A()
>     print a.d[2]
>     n = [1, 2, ,3, 4]
>     a.set(n)
> 
> Can you give me some hints?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From markus.schoepflin at comsoft.de  Fri Jul  1 16:41:23 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Fri, 01 Jul 2005 16:41:23 +0200
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
Message-ID: <da3k88$dsj$1@sea.gmane.org>

Is boost.python compatible with boost.bind (see example below)? If yes, 
what am I doing wrong? The compiler used is g++ 3.2.3, boost version is 1.32.

Example:

int foo(int bar) { return bar; }
...
def("foo", foo); // compiles ok
def("foo", boost::bind(foo, _1)); // gives error

The error message boils down to:

boost/python/make_function.hpp:103: error: no matching function for call to 
`get_signature(boost::_bi::bind_t<int, int (*)(int), 
boost::_bi::list1<boost::arg<1> > >&)'

TIA, Markus



From petrucio at hoplon.com  Fri Jul  1 17:40:09 2005
From: petrucio at hoplon.com (Petrucio)
Date: Fri, 01 Jul 2005 12:40:09 -0300
Subject: [C++-sig] How to deal with array?
In-Reply-To: <20050701020828.GA14499@BigDell>
References: <20050701020828.GA14499@BigDell>
Message-ID: <6.0.2.0.1.20050701123336.01d32a20@mail.hoplon.com>

Just like the similar quation about argument pointers returning values, to 
solve this kind of problem I found SWIG to be easier, using pre-made 
typemaps under carrays.i:

http://www.swig.org/Doc1.3/Library.html#Library_nn5

PS: Sorry about bringing SWIG all the time in a Boost.Pyhon list. I just 
think it's best suited for a lower-level, basic typed heavy API.

At 23:08 30/6/2005, you wrote:
>Hi,
>Can I expose a C++ array to python with Boost.Python? And Can I use a
>python list conveniently in C++?
>
>For example, there is a C++ class as follows
>     class A
>     {
>     private:
>         int c[4];
>     public:
>         int d[10];
>
>         void set(int *n)
>         {
>             for(int i = 0; i < 4; ++i)
>                 c[i] = n[i]
>         }
>     }
>and I want use class A above in Python like this
>     a = A()
>     print a.d[2]
>     n = [1, 2, ,3, 4]
>     a.set(n)
>
>Can you give me some hints?
>_______________________________________________
>C++-sig mailing list
>C++-sig at python.org
>http://mail.python.org/mailman/listinfo/c++-sig



From paul at pecm.nl  Fri Jul  1 20:00:07 2005
From: paul at pecm.nl (Paul Melis)
Date: Fri, 01 Jul 2005 20:00:07 +0200
Subject: [C++-sig] Wrapping std::vector<AbstractClass*>
Message-ID: <42C584A7.3030607@pecm.nl>

Hello,
I have an abstract class and a std::vector<> of pointers to this class. 
A routine in my c++ code fills a vector with objects of classes derived 
from the abstract class.
I'd like to iterate over the vector in python and use each of the items 
in the vector depending on the type of derived class.

I have the following:

#include <vector>
#include <boost/python.hpp>
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>

using namespace boost::python;

class Abstract
{
public:   
    virtual void    f() =0;
};

class Concrete1 : public Abstract
{
public:   
    virtual void    f()    { }
};

typedef std::vector<Abstract*>   ListOfObjects;

class DoesSomething
{
public:
    DoesSomething()    {}
   
    ListOfObjects   returnList()    { ListOfObjects lst; 
lst.push_back(new Concrete1()); return lst; }
};


BOOST_PYTHON_MODULE(test)
{       
class_<Abstract, boost::noncopyable>("Abstract", no_init)
    ;

class_<ListOfObjects>("ListOfObjects")
   .def( vector_indexing_suite<ListOfObjects>() )  
    ;

class_<DoesSomething>("DoesSomething")
    .def("returnList", &DoesSomething::returnList)
    ;
}




Now, when I put this stuff in a python module and try to use it I get:

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import test
 >>> dir(test)
['Abstract', 'DoesSomething', 'ListOfObjects', '__doc__', '__file__', 
'__name__']
 >>> d = test.DoesSomething()
 >>> d.returnList()
<test.ListOfObjects object at 0x009C5588>
 >>> lst = d.returnList()
 >>> lst[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: No to_python (by-value) converter found for C++ type: class 
Abstract
 >>>

I suspect that boost.python will wrap the return value of returnList() 
as a pointer to Abstract, without the possibility at runtime to look at 
the actual object type. Is this something I would have to code by hand? 
For example, by making a routine that takes a pointer to Abstract and 
uses dynamic_cast<> to test which of the concrete classes the object 
actually is from?

Paul


From dirgesh.patel at hp.com  Sat Jul  2 00:07:50 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Fri, 1 Jul 2005 15:07:50 -0700
Subject: [C++-sig] using libtool in boost.python
Message-ID: <da4ed9$mdt$1@sea.gmane.org>

how can i use libtool in boost.python with Jamfile





From rwgk at yahoo.com  Sat Jul  2 01:20:42 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Jul 2005 16:20:42 -0700 (PDT)
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
In-Reply-To: <da3k88$dsj$1@sea.gmane.org>
Message-ID: <20050701232042.88012.qmail@web31504.mail.mud.yahoo.com>

I don't know where David is...
Until he replies a potentially silly suggestion (since I don't understand
boost::bind very much): is it besides the point to make a thin wrapper

int
bound_foo(int bar)
{
  boost::bind(foo, _1)(bar);
}

and to

.def("foo", bound_foo);

?

--- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:

> Is boost.python compatible with boost.bind (see example below)? If yes, 
> what am I doing wrong? The compiler used is g++ 3.2.3, boost version is 1.32.
> 
> Example:
> 
> int foo(int bar) { return bar; }
> ...
> def("foo", foo); // compiles ok
> def("foo", boost::bind(foo, _1)); // gives error
> 
> The error message boils down to:
> 
> boost/python/make_function.hpp:103: error: no matching function for call to 
> `get_signature(boost::_bi::bind_t<int, int (*)(int), 
> boost::_bi::list1<boost::arg<1> > >&)'
> 
> TIA, Markus



		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com


From dave at boost-consulting.com  Sat Jul  2 02:07:51 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 01 Jul 2005 20:07:51 -0400
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
References: <da3k88$dsj$1@sea.gmane.org>
Message-ID: <ufyuy6pew.fsf@boost-consulting.com>

Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

> Is boost.python compatible with boost.bind (see example below)? 

Not in that way, no.  The requirements of def() are clearly spelled
out in http://www.boost.org/libs/python/doc/v2/def.html#def-spec, and
bind_t<> specializations do not meet them ... mostly because I don't
have a way to deduce the signature of a bind expression.

However, you can do:

    def(
        "foo"
      , make_function(
            bind(foo,_1)
          , default_call_policies()
          , boost::mpl::vector<int,int>()
        )
    )

See http://www.boost.org/libs/python/doc/v2/make_function.html

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



From dave at boost-consulting.com  Sat Jul  2 02:09:14 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 01 Jul 2005 20:09:14 -0400
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
References: <da3k88$dsj$1@sea.gmane.org>
	<20050701232042.88012.qmail@web31504.mail.mud.yahoo.com>
Message-ID: <uacl66pcl.fsf@boost-consulting.com>

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

> I don't know where David is...

Somerville, as usual?

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



From foo.Clark at gmail.com  Sat Jul  2 19:39:28 2005
From: foo.Clark at gmail.com (Clark)
Date: Sun, 3 Jul 2005 01:39:28 +0800
Subject: [C++-sig] How to deal with array?
In-Reply-To: <20050701070132.44458.qmail@web31509.mail.mud.yahoo.com>
References: <20050701020828.GA14499@BigDell>
	<20050701070132.44458.qmail@web31509.mail.mud.yahoo.com>
Message-ID: <20050702173928.GA21740@BigDell>

Thanks. I'll try it. And can you give me somthing about other solutions?

On Fri, Jul 01, 2005 at 12:01:32AM -0700, Ralf W. Grosse-Kunstleve wrote:
> There are a number of possible solutions. One that I explored recently and is
> particularly non-intrusive goes like this:
> 
> 1. Copy this file to your space (remove the #include <gltbx/...> if it is still
> version 1.1.1.1) and change the namespaces to your liking:
> 
>  
> http://cvs.sourceforge.net/viewcvs.py/cctbx/gltbx/pointer_args_bpl.h?view=markup
> 
> 2. Implement a thin wrapper like this (untested):
> 
>   void
>   A_set(A& self, boost::python::object const& py_n)
>   {
>     boost_python::converter<int> n_proxy("n", py_n, 4, false);
>     int* n = n_proxy.get();
>     A.set(n);
>   }
> 
> 3. Wrap like this (also untested):
> 
>   class_<A>("A")
>     .def("set", A_set)
>   ;
> 
> HTH,
>         Ralf
> 
> --- Clark <foo.Clark at gmail.com> wrote:
> 
> > Hi,
> > Can I expose a C++ array to python with Boost.Python? And Can I use a
> > python list conveniently in C++? 
> > 
> > For example, there is a C++ class as follows
> >     class A
> >     {
> >     private:
> >         int c[4];
> >     public:
> >         int d[10];
> > 
> >         void set(int *n)
> >         {
> >             for(int i = 0; i < 4; ++i)
> >                 c[i] = n[i]
> >         }
> >     }
> > and I want use class A above in Python like this
> >     a = A()
> >     print a.d[2]
> >     n = [1, 2, ,3, 4]
> >     a.set(n)
> > 
> > Can you give me some hints?
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


From dave at boost-consulting.com  Sun Jul  3 03:53:10 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 02 Jul 2005 21:53:10 -0400
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
References: <20050630150541.GA12758@BigDell>
	<20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>
Message-ID: <ud5q064ft.fsf@boost-consulting.com>

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

> Thanks for posting this. It is very interesting!
>
> David, how difficult would it be to provide something like
>
>   boost::python::arg_from_swig_object<Foo>();
>
> so that we could wrap functions taking SWIG-wrapped arguments
> directly?

I don't know enough about what SWIG does to say for sure, but I
presume it is generating a type object for each class you wrap... (**)

> I guess there is no easy way to construct SWIG-wrapped return values without a
> lot of support from SWIG, 

Perhaps not; I don't know what SWIG provides.

> but automatically extracting the pointer to turn it
> into a T*, T&, const T*, const T& argument seems like something that may not be
> too hard... true?
>
> Looking some more, isn't this almost it?
>
>   http://www.boost.org/libs/python/doc/v2/lvalue_from_pytype.html

Yes.

> But we want to do it without having the equivalent of
> noddy_NoddyType, 

(**) ...just like noddy_NoddyType.  Are you sure we don't want to have
the equivalent of that?

> just knowing that ((PySwigObject*)obj.ptr())->ptr gives us the T*.

Oh, I see; all Swig objects have the same type?

Well you need some way to identify the Python objects for which the
above statement is true, unless you want to forego all error checking
and just allow a crash if a Swig-wrapped Foo is passed where a
Swig-wrapped Bar is expected.  

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



From rwgk at yahoo.com  Sun Jul  3 16:20:18 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 3 Jul 2005 07:20:18 -0700 (PDT)
Subject: [C++-sig] How to deal with array?
In-Reply-To: <20050702173928.GA21740@BigDell>
Message-ID: <20050703142018.41016.qmail@web31514.mail.mud.yahoo.com>

--- Clark <foo.Clark at gmail.com> wrote:

> Thanks. I'll try it. And can you give me somthing about other solutions?

Can you change the wrapped classes? If yes, you could use boost::array<int, 4>
instead of the plain C int [4]. The signature of your method would become
set(boost::array<int, 4> const&) instead of set(int*). Then you could use this
file (no dependencies other than Boost):

   
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?view=markup

to define automatic list or tuple -> boost::array<int, 4> conversions. I.e. you
could wrap your set method directly. See also:

    http://www.boost.org/libs/python/doc/v2/faq.html#question2

I've mentioned this many times before on this list. Google for
container_conversions to find the messages.

This doesn't support write_back, though (the previous suggestion does).
You could use both what I suggested before and what I am suggesting here at the
same time, I believe.

There is also the vector indexing suite which comes with Boost.Python (see
docs), but this is more for large arrays.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From rwgk at yahoo.com  Sun Jul  3 20:56:12 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 3 Jul 2005 11:56:12 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <ud5q064ft.fsf@boost-consulting.com>
Message-ID: <20050703185612.96550.qmail@web31508.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Looking some more, isn't this almost it?
> >
> >   http://www.boost.org/libs/python/doc/v2/lvalue_from_pytype.html
> 
> Yes.

Cool!

> > just knowing that ((PySwigObject*)obj.ptr())->ptr gives us the T*.
>
> Oh, I see; all Swig objects have the same type?

Yes!

> Well you need some way to identify the Python objects for which the
> above statement is true, unless you want to forego all error checking
> and just allow a crash if a Swig-wrapped Foo is passed where a
> Swig-wrapped Bar is expected.

I hadn't though of that. Thanks, David!

Encouraged by your "Yes" above I gave it a good push. Here is the
result:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/swig_args_ext.cpp?view=markup

  (Also attached.)

This solution is based on what I found in SWIG-1.3.24/Lib/python/pyrun.swg.
At the heart of the solution is this simple fragment:

    static void* extract(PyObject* op) \
    { \
        if (std::strcmp(op->ob_type->tp_name, "PySwigObject") != 0) return 0; \
        PySwigObject* swig_obj_ptr = reinterpret_cast<PySwigObject*>(op); \
        if (std::strcmp(swig_obj_ptr->desc, "_p_" # T) != 0) return 0; \
        return swig_obj_ptr->ptr; \
    } \

And here is the corresponding test script:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/tst_swig_args.py?view=markup

The test script slightly edited:

    import example # SWIG-1.3.24/Examples/python/class
    import boost_python_swig_args_ext

    c = example.Circle(10)
    c.x = 20
    c.y = 30

    s = example.Square(10)
    s.x = -10
    s.y = 5

    boost_python_swig_args_ext.show(c.this)
    boost_python_swig_args_ext.show(s.this)

The test runs successfully under Linux. It proves that the overloaded
show() function works correctly, which means the simple strcmp() logic
in the C++ fragment above works as it should. I also used valgrind and
did a leak check. If someone wants to reproduce:

    gunzip -c swig-1.3.24.tar.gz | tar xf -
    cd SWIG-1.3.24
    ./configure
    make
    cd Examples/python/class
    make
    cp _example.so example.py <somewhere on PYTHONPATH>
    ar r libswig_class_example.a example.o

Then compile and link boost_python_swig_args_ext with
-lswig_class_example.

David, would you want to include the core of swig_args_ext.cpp in,
e.g., boost/python/swig_arg.h? I think it would be a valuable
addition. There are many SWIG-wrapped libraries. People could easily
use them while writing their own extensions with Boost.Python.

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: swig_args_ext.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050703/c65d2991/attachment.txt>

From dave at boost-consulting.com  Mon Jul  4 01:31:19 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 03 Jul 2005 19:31:19 -0400
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
References: <ud5q064ft.fsf@boost-consulting.com>
	<20050703185612.96550.qmail@web31508.mail.mud.yahoo.com>
Message-ID: <u3bqv4gc8.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> > Looking some more, isn't this almost it?
>> >
>> >   http://www.boost.org/libs/python/doc/v2/lvalue_from_pytype.html
>> 
>> Yes.
>
> Cool!
>
>> > just knowing that ((PySwigObject*)obj.ptr())->ptr gives us the T*.
>>
>> Oh, I see; all Swig objects have the same type?
>
> Yes!
>
>> Well you need some way to identify the Python objects for which the
>> above statement is true, unless you want to forego all error checking
>> and just allow a crash if a Swig-wrapped Foo is passed where a
>> Swig-wrapped Bar is expected.
>
> I hadn't though of that. Thanks, David!
>
> Encouraged by your "Yes" above I gave it a good push. Here is the
> result:
>
>  
> http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/swig_args_ext.cpp?view=markup
>
>   (Also attached.)
>
> This solution is based on what I found in SWIG-1.3.24/Lib/python/pyrun.swg.
> At the heart of the solution is this simple fragment:
>
>     static void* extract(PyObject* op) \
>     { \
>         if (std::strcmp(op->ob_type->tp_name, "PySwigObject") != 0)
>     return 0; \

Isn't there a type object somewhere you can compare ob_type with?

>         PySwigObject* swig_obj_ptr = reinterpret_cast<PySwigObject*>(op); \

This should be static_cast.

>         if (std::strcmp(swig_obj_ptr->desc, "_p_" # T) != 0) return 0; \

Heh, so that's how they do it.  Pretty lame, IMO.  Well, inheritance
won't work; a swig-wrapped Derived won't be able to be passed where a
Base is expected.  If that doesn't matter, it's fine.

>         return swig_obj_ptr->ptr; \
>     } \
>
> And here is the corresponding test script:
>
>  
> http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/tst_swig_args.py?view=markup
>
> The test script slightly edited:
>
>     import example # SWIG-1.3.24/Examples/python/class
>     import boost_python_swig_args_ext
>
>     c = example.Circle(10)
>     c.x = 20
>     c.y = 30
>
>     s = example.Square(10)
>     s.x = -10
>     s.y = 5
>
>     boost_python_swig_args_ext.show(c.this)
>     boost_python_swig_args_ext.show(s.this)

You should have part of the test that shows non-matching types are
rejected.

> The test runs successfully under Linux. It proves that the overloaded
> show() function works correctly, which means the simple strcmp() logic
> in the C++ fragment above works as it should. I also used valgrind and
> did a leak check. If someone wants to reproduce:
>
>     gunzip -c swig-1.3.24.tar.gz | tar xf -
>     cd SWIG-1.3.24
>     ./configure
>     make
>     cd Examples/python/class
>     make
>     cp _example.so example.py <somewhere on PYTHONPATH>
>     ar r libswig_class_example.a example.o
>
> Then compile and link boost_python_swig_args_ext with
> -lswig_class_example.
>
> David, would you want to include the core of swig_args_ext.cpp in,
> e.g., boost/python/swig_arg.h? I think it would be a valuable
> addition. There are many SWIG-wrapped libraries. People could easily
> use them while writing their own extensions with Boost.Python.

Sounds great!  Needs docs, of course ;-)

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



From foo.Clark at gmail.com  Mon Jul  4 05:46:11 2005
From: foo.Clark at gmail.com (Clark)
Date: Mon, 4 Jul 2005 11:46:11 +0800
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>
References: <20050630150541.GA12758@BigDell>
	<20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>
Message-ID: <20050704034611.GA31236@BigDell>

On Thu, Jun 30, 2005 at 02:17:02PM -0700, Ralf W. Grosse-Kunstleve wrote:
> Thanks for posting this. It is very interesting!
> 
> David, how difficult would it be to provide something like
> 
>   boost::python::arg_from_swig_object<Foo>();
> 
> so that we could wrap functions taking SWIG-wrapped arguments directly?
> I guess there is no easy way to construct SWIG-wrapped return values without a
> lot of support from SWIG, but automatically extracting the pointer to turn it
Yes. But we can still emulate what SWIG does to make a C++ Object be a
Python Object, and then return it.

> into a T*, T&, const T*, const T& argument seems like something that may not be
> too hard... true?
> 
> Looking some more, isn't this almost it?
> 
>   http://www.boost.org/libs/python/doc/v2/lvalue_from_pytype.html
> 
> But we want to do it without having the equivalent of noddy_NoddyType, just
> knowing that ((PySwigObject*)obj.ptr())->ptr gives us the T*.
> 
> Cheers,
>         Ralf
> 
> --- Clark <foo.Clark at gmail.com> wrote:
> 
> > It takes much time of me to solve this problem.
> > 
> > The answer is: 
> > A class member named "this" is added to every python class wrapped by
> > SWIG. The "this" is a "PySwigObject", which has a member points to 
> > the C++ 'this' pointer.
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Read only the mail you want - Yahoo! Mail SpamGuard. 
> http://promotions.yahoo.com/new_mail 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


From foo.Clark at gmail.com  Mon Jul  4 06:07:36 2005
From: foo.Clark at gmail.com (Clark)
Date: Mon, 4 Jul 2005 12:07:36 +0800
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <ud5q064ft.fsf@boost-consulting.com>
References: <20050630150541.GA12758@BigDell>
	<20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>
	<ud5q064ft.fsf@boost-consulting.com>
Message-ID: <20050704040736.GB31236@BigDell>

On Sat, Jul 02, 2005 at 09:53:10PM -0400, David Abrahams wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > Thanks for posting this. It is very interesting!
> >
> > David, how difficult would it be to provide something like
> >
> >   boost::python::arg_from_swig_object<Foo>();
> >
> > so that we could wrap functions taking SWIG-wrapped arguments
> > directly?
> 
> I don't know enough about what SWIG does to say for sure, but I
> presume it is generating a type object for each class you wrap... (**)
> 
> > I guess there is no easy way to construct SWIG-wrapped return values without a
> > lot of support from SWIG, 
> 
> Perhaps not; I don't know what SWIG provides.
> 
> > but automatically extracting the pointer to turn it
> > into a T*, T&, const T*, const T& argument seems like something that may not be
> > too hard... true?
> >
> > Looking some more, isn't this almost it?
> >
> >   http://www.boost.org/libs/python/doc/v2/lvalue_from_pytype.html
> 
> Yes.
> 
> > But we want to do it without having the equivalent of
> > noddy_NoddyType, 
> 
> (**) ...just like noddy_NoddyType.  Are you sure we don't want to have
> the equivalent of that?
> 
> > just knowing that ((PySwigObject*)obj.ptr())->ptr gives us the T*.
> 
> Oh, I see; all Swig objects have the same type?
Yes, they are all PySwigObject.
> 
> Well you need some way to identify the Python objects for which the
> above statement is true, unless you want to forego all error checking
> and just allow a crash if a Swig-wrapped Foo is passed where a
> Swig-wrapped Bar is expected.
Sometimes it's critical. For example, to paint on screen efficiently, we must
use the DC's methods in C++ directly. But because usually the GUI or framework
is written in Python, we can only get the DC as a Python Object.

Maybe we can also emulate the behaviors of SWIG to do error checking and
it may not be very easy. It may not be implemented in Boost.Python
soon. And I can't wait any more for my project has began. 

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


From markus.schoepflin at comsoft.de  Mon Jul  4 13:17:19 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Mon, 04 Jul 2005 13:17:19 +0200
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
In-Reply-To: <20050701232042.88012.qmail@web31504.mail.mud.yahoo.com>
References: <da3k88$dsj$1@sea.gmane.org>
	<20050701232042.88012.qmail@web31504.mail.mud.yahoo.com>
Message-ID: <dab5s0$bh9$1@sea.gmane.org>

Ralf W. Grosse-Kunstleve wrote:

> I don't know where David is...
> Until he replies a potentially silly suggestion (since I don't understand
> boost::bind very much): is it besides the point to make a thin wrapper
> 
> int
> bound_foo(int bar)
> {
>   boost::bind(foo, _1)(bar);
> }
> 
> and to
> 
> .def("foo", bound_foo);
> 
> ?

Thanks for the suggestion, but the use of bind was meant to avoid the need 
for a wrapper function.

Markus



From markus.schoepflin at comsoft.de  Mon Jul  4 13:21:37 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Mon, 04 Jul 2005 13:21:37 +0200
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
In-Reply-To: <ufyuy6pew.fsf@boost-consulting.com>
References: <da3k88$dsj$1@sea.gmane.org> <ufyuy6pew.fsf@boost-consulting.com>
Message-ID: <dab641$c6r$1@sea.gmane.org>

David Abrahams wrote:

> Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

>>Is boost.python compatible with boost.bind (see example below)? 

> Not in that way, no.  The requirements of def() are clearly spelled
> out in http://www.boost.org/libs/python/doc/v2/def.html#def-spec, and
> bind_t<> specializations do not meet them ... mostly because I don't
> have a way to deduce the signature of a bind expression.
> 
> However, you can do:
> 
>     def(
>         "foo"
>       , make_function(
>             bind(foo,_1)
>           , default_call_policies()
>           , boost::mpl::vector<int,int>()
>         )
>     )
> 
> See http://www.boost.org/libs/python/doc/v2/make_function.html

Thanks for the answer, Dave. IOW, if there would be a way to get the 
signature of the bind expression, maybe via some support from bind itself, 
there would be a way to make to original example work, right?

Markus





From dave at boost-consulting.com  Mon Jul  4 14:22:12 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 08:22:12 -0400
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
References: <20050630150541.GA12758@BigDell>
	<20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>
	<ud5q064ft.fsf@boost-consulting.com> <20050704040736.GB31236@BigDell>
Message-ID: <uwto6222z.fsf@boost-consulting.com>

Clark <foo.Clark at gmail.com> writes:

>> 
>> Oh, I see; all Swig objects have the same type?
> Yes, they are all PySwigObject.

Please try to leave a blank line above and below quoted material;
otherwise it's hard to pick out what you're saying.

>> Well you need some way to identify the Python objects for which the
>> above statement is true, unless you want to forego all error checking
>> and just allow a crash if a Swig-wrapped Foo is passed where a
>> Swig-wrapped Bar is expected.
> Sometimes it's critical. 

Sometimes it's critical to... identify the Python objects for which
the above statement is true?  Forego all error checking and allow a
crash?  Something else?

> For example, to paint on screen efficiently, we must use the DC's
> methods in C++ directly. But because usually the GUI or framework is
> written in Python, we can only get the DC as a Python Object.

I don't see the connection between that scenario and anything we're
discussing.

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



From dave at boost-consulting.com  Mon Jul  4 14:24:00 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 08:24:00 -0400
Subject: [C++-sig] [boost.python] Interoperability with boost.bind
References: <da3k88$dsj$1@sea.gmane.org> <ufyuy6pew.fsf@boost-consulting.com>
	<dab641$c6r$1@sea.gmane.org>
Message-ID: <ur7ee21zz.fsf@boost-consulting.com>

Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

> David Abrahams wrote:
>
>> Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:
>
>>>Is boost.python compatible with boost.bind (see example below)? 
>
>> Not in that way, no.  The requirements of def() are clearly spelled
>> out in http://www.boost.org/libs/python/doc/v2/def.html#def-spec, and
>> bind_t<> specializations do not meet them ... mostly because I don't
>> have a way to deduce the signature of a bind expression.
>> 
>> However, you can do:
>> 
>>     def(
>>         "foo"
>>       , make_function(
>>             bind(foo,_1)
>>           , default_call_policies()
>>           , boost::mpl::vector<int,int>()
>>         )
>>     )
>> 
>> See http://www.boost.org/libs/python/doc/v2/make_function.html
>
> Thanks for the answer, Dave. IOW, if there would be a way to get the 
> signature of the bind expression, 

There is none. Consider that you can wrap function objects with
templated operator():

   struct F
   {
       template <class T>
       T* operator()(T) const;
   };

what is the signature of

     bind(F(),_1)

?

> maybe via some support from bind itself, there would be a way to
> make to original example work, right?

Right.  But there is no way to do it.

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



From markus.schoepflin at comsoft.de  Mon Jul  4 16:07:27 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Mon, 04 Jul 2005 16:07:27 +0200
Subject: [C++-sig] [boost.python] char arrays in structs
Message-ID: <dabfqv$7a9$1@sea.gmane.org>

Using gcc-3.4.3 and boost.python 1.32.0. Full example:

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

typedef char bar_t[4];

struct foo
{
   bar_t bar;
   foo() {
     bar[0] = 'b'; bar[1] = 'a';
     bar[2] = 'r'; bar[3] = 0;
   }
};

BOOST_PYTHON_MODULE(test)
{
   using namespace boost::python;

   class_<foo>("foo")
     .def_readonly("bar", &foo::bar)
     ;
}
--->%---

The compiles and links ok, but when using it from python I get the 
following error:

Python 2.3 (#1, Jul 30 2003, 14:14:00)
[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from test import *
 >>> print foo().bar
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: No to_python (by-value) converter found for C++ type: char [4]

So I went ahead and added a custom converter for bar_t like so:

struct bar_t_to_python_str
{
   static PyObject* convert(bar_t const &s)
   {
     return boost::python::incref(boost::python::object(s).ptr());
   }
};

and in BOOST_PYTHON_MODULE(test):

   to_python_converter<bar_t, bar_t_to_python_str>();

Is it to be expected that I do need a custom type converter for this? Or do 
I miss something?

TIA, Markus



From rwgk at yahoo.com  Mon Jul  4 17:26:11 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 4 Jul 2005 08:26:11 -0700 (PDT)
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <dabfqv$7a9$1@sea.gmane.org>
Message-ID: <20050704152611.9065.qmail@web31507.mail.mud.yahoo.com>

--- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:

> Using gcc-3.4.3 and boost.python 1.32.0. Full example:
> 
> ---%<---
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> 
> typedef char bar_t[4];

Could you make it a boost::array<char, 4>?

> struct foo
> {
>    bar_t bar;
>    foo() {
>      bar[0] = 'b'; bar[1] = 'a';
>      bar[2] = 'r'; bar[3] = 0;
>    }
> };
> 
> BOOST_PYTHON_MODULE(test)
> {
>    using namespace boost::python;
> 
>    class_<foo>("foo")
>      .def_readonly("bar", &foo::bar)
>      ;
> }
> --->%---
> 
> The compiles and links ok, but when using it from python I get the 
> following error:
> 
> Python 2.3 (#1, Jul 30 2003, 14:14:00)
> [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> from test import *
>  >>> print foo().bar
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> TypeError: No to_python (by-value) converter found for C++ type: char [4]
> 
> So I went ahead and added a custom converter for bar_t like so:
> 
> struct bar_t_to_python_str
> {
>    static PyObject* convert(bar_t const &s)

Here bar_t is equivalent to a plain char*. The size information is lost. This
due to the C heritage.

>    {
>      return boost::python::incref(boost::python::object(s).ptr());
>    }
> };
> 
> and in BOOST_PYTHON_MODULE(test):
> 
>    to_python_converter<bar_t, bar_t_to_python_str>();
> 
> Is it to be expected that I do need a custom type converter for this? Or do 
> I miss something?

You'd need a custom converter for boost::array<char, 4> if that is an option.
The converter would also do the from_python conversion.

If the C++ interface is fixed, you'd have to work with thin wrappers. As long
as you stay exclusively within the framework of C++, as Boost.Python does, this
is the only option.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From markus.schoepflin at comsoft.de  Mon Jul  4 17:42:29 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Mon, 04 Jul 2005 17:42:29 +0200
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <20050704152611.9065.qmail@web31507.mail.mud.yahoo.com>
References: <dabfqv$7a9$1@sea.gmane.org>
	<20050704152611.9065.qmail@web31507.mail.mud.yahoo.com>
Message-ID: <dabld5$o04$1@sea.gmane.org>

Ralf W. Grosse-Kunstleve wrote:

> --- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:

>>Using gcc-3.4.3 and boost.python 1.32.0. Full example:
>>
>>---%<---
>>#include <boost/python/module.hpp>
>>#include <boost/python/class.hpp>
>>
>>typedef char bar_t[4];

> Could you make it a boost::array<char, 4>?

Not really, because in reality it's an external fixed API.

>>struct foo
>>{
>>   bar_t bar;
>>   foo() {
>>     bar[0] = 'b'; bar[1] = 'a';
>>     bar[2] = 'r'; bar[3] = 0;
>>   }
>>};
>>
>>BOOST_PYTHON_MODULE(test)
>>{
>>   using namespace boost::python;
>>
>>   class_<foo>("foo")
>>     .def_readonly("bar", &foo::bar)
>>     ;
>>}
>>--->%---
>>
>>The compiles and links ok, but when using it from python I get the 
>>following error:
>>
>>Python 2.3 (#1, Jul 30 2003, 14:14:00)
>>[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
>>Type "help", "copyright", "credits" or "license" for more information.
>> >>> from test import *
>> >>> print foo().bar
>>Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>TypeError: No to_python (by-value) converter found for C++ type: char [4]
>>
>>So I went ahead and added a custom converter for bar_t like so:
>>
>>struct bar_t_to_python_str
>>{
>>   static PyObject* convert(bar_t const &s)
> 
> 
> Here bar_t is equivalent to a plain char*. The size information is lost. This
> due to the C heritage.

Duh, I keep forgetting about that. But this makes me wondering why the 
custom converter indeed does the trick in my example.

> 
> 
>>   {
>>     return boost::python::incref(boost::python::object(s).ptr());
>>   }
>>};
>>
>>and in BOOST_PYTHON_MODULE(test):
>>
>>   to_python_converter<bar_t, bar_t_to_python_str>();
>>
>>Is it to be expected that I do need a custom type converter for this? Or do 
>>I miss something?

> You'd need a custom converter for boost::array<char, 4> if that is an option.
> The converter would also do the from_python conversion.
> 
> If the C++ interface is fixed, you'd have to work with thin wrappers. As long
> as you stay exclusively within the framework of C++, as Boost.Python does, this
> is the only option.

You mean thin wrapper as follows?

struct wrap_foo : public foo
{
   char const *get_bar() { return bar; }
};

and then

class_<foo_derived>("foo")
   .def_property("bar", &foo_derived::get_bar)
   ;

> 
> Cheers,
>         Ralf

Thanks, Markus



From dave at boost-consulting.com  Mon Jul  4 18:30:44 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 12:30:44 -0400
Subject: [C++-sig] [boost.python] char arrays in structs
References: <dabfqv$7a9$1@sea.gmane.org>
	<20050704152611.9065.qmail@web31507.mail.mud.yahoo.com>
Message-ID: <ubr5izg7f.fsf@boost-consulting.com>

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

>
> Here bar_t is equivalent to a plain char*. The size information is lost. This
> due to the C heritage.

That's incorrect.

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



From rwgk at yahoo.com  Mon Jul  4 18:34:57 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 4 Jul 2005 09:34:57 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <u3bqv4gc8.fsf@boost-consulting.com>
Message-ID: <20050704163457.67879.qmail@web31503.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > This solution is based on what I found in SWIG-1.3.24/Lib/python/pyrun.swg.
> > At the heart of the solution is this simple fragment:
> >
> >     static void* extract(PyObject* op) \
> >     { \
> >         if (std::strcmp(op->ob_type->tp_name, "PySwigObject") != 0)
> >     return 0; \
> 
> Isn't there a type object somewhere you can compare ob_type with?

It seemed hard to me. Here is what I understand:

SWIG is a wrapper generator (more similar to Pyste than to Boost.Python). In
the SWIG-1.3.24/Examples/python/class that I was using, SWIG copies a big chunk
of code into the generated example_wrap.cxx. This includes the complete
definition of the type object for PySwigObject. The type definition is
implemented as a group of static objects in this function: 

SWIGRUNTIME PyTypeObject*
PySwigObject_GetType();

We'd have to get hold of this function, which I believe will complicate the
linking severely. But even if we did, it wouldn't get us very far since each
SWIG-generated extension has its own version of the type object, with its own
address. That's probably why I found this function:

SWIGRUNTIMEINLINE int
PySwigObject_Check(PyObject *op) {
  return ((op)->ob_type == PySwigObject_GetType())
    || (strcmp((op)->ob_type->tp_name,"PySwigObject") == 0);
}

I am still wondering why SWIG does "one or the other" and not simply the more
general "other". The best explanation I can find for myself is optimization for
speed (pointer equivalence vs. string comparison). Anyway, for me the
conclusion was clear: it is definitely not worth complicating the build process
for such a minute gain. If the Python/C++ combination is used sensibly the
runtime difference will be unmeasurable anyway.

> >         PySwigObject* swig_obj_ptr = reinterpret_cast<PySwigObject*>(op); \
> 
> This should be static_cast.

I tried it but it doesn't work:

g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3
-ffast-math -DBOOST_PYTHON_MAX_BASES=2 -I/net/legless/scratch1/rwgk/dist/boost
-I/usr/local_cci/Python-2.4.1_ticker_simple/include/python2.4 -c -o
boost_adaptbx/swig_args_ext.os
/net/legless/scratch1/rwgk/dist/boost_adaptbx/swig_args_ext.cpp
/net/legless/scratch1/rwgk/dist/boost_adaptbx/swig_args_ext.cpp: In static 
   member function `static void* 
   boost::python::swig_arg<Circle>::extract(PyObject*)':
/net/legless/scratch1/rwgk/dist/boost_adaptbx/swig_args_ext.cpp:112: invalid 
   static_cast from type `PyObject*' to type `PySwigObject*'
/net/legless/scratch1/rwgk/dist/boost_adaptbx/swig_args_ext.cpp: In static 
   member function `static void* 
   boost::python::swig_arg<Square>::extract(PyObject*)':
/net/legless/scratch1/rwgk/dist/boost_adaptbx/swig_args_ext.cpp:113: invalid 
   static_cast from type `PyObject*' to type `PySwigObject*'

> >         if (std::strcmp(swig_obj_ptr->desc, "_p_" # T) != 0) return 0; \
> 
> Heh, so that's how they do it.  Pretty lame, IMO.

Hey, let's be politically correct: Pretty basic, at that level.
They decided to put all their energy into a special parser, which clearly has
some advantages if you have to deal a lot with C-style interfaces. E.g. the
int* question is coming up a lot.

> Well, inheritance
> won't work; a swig-wrapped Derived won't be able to be passed where a
> Base is expected.  If that doesn't matter, it's fine.

Is there a way to write something like:

    bases_of<Circle, mpl::vector<Shape> >();

> >     boost_python_swig_args_ext.show(c.this)
> >     boost_python_swig_args_ext.show(s.this)
> 
> You should have part of the test that shows non-matching types are
> rejected.

I figured rejection is tested since the overload resolution couldn't work
otherwise. What exactly do you have in mind?

> > David, would you want to include the core of swig_args_ext.cpp in,
> > e.g., boost/python/swig_arg.h? I think it would be a valuable
> > addition. There are many SWIG-wrapped libraries. People could easily
> > use them while writing their own extensions with Boost.Python.
> 
> Sounds great!  Needs docs, of course ;-)

Would you be happy with a page like I wrote for the pickle suite,
linked from the main page, e.g. "SWIG interoperability"?

But I still have a question. I don't really like the interface I came up with
since it requires two steps:

1. BOOST_PYTHON_SWIG_ARG(Circle)

2. swig_arg<Circle>();

It would be nicer if one could simply write

  swig_arg<Circle>("Circle");

Is there any way this could be achieved?

Actually, here is another question: would it be best to wait until Boost 1.33
is out?

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From rwgk at yahoo.com  Mon Jul  4 18:56:34 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 4 Jul 2005 09:56:34 -0700 (PDT)
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <ubr5izg7f.fsf@boost-consulting.com>
Message-ID: <20050704165634.81204.qmail@web31501.mail.mud.yahoo.com>

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

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> >
> > Here bar_t is equivalent to a plain char*. The size information is lost.
> This
> > due to the C heritage.
> 
> That's incorrect.

Oh, sorry.
What is correct then?
Why would I want to use "boost::array<char, 4>" instead of "typedef char[4]"?



		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com


From dave at boost-consulting.com  Mon Jul  4 18:58:11 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 12:58:11 -0400
Subject: [C++-sig] [boost.python] char arrays in structs
References: <dabfqv$7a9$1@sea.gmane.org>
Message-ID: <u64vqzexo.fsf@boost-consulting.com>

Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

> Is it to be expected that I do need a custom type converter for this? Or do 
> I miss something?

It's "expected" in the sense that I never thought of implementing
automatic conversions for char arrays.  It should be possible to do,
although that would probably get me into the position of implementing
generalized array conversions (e.g. from Python lists).  It's a little
bit messy and not something I can get to right away.

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



From rwgk at yahoo.com  Mon Jul  4 19:12:07 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 4 Jul 2005 10:12:07 -0700 (PDT)
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <dabld5$o04$1@sea.gmane.org>
Message-ID: <20050704171207.34997.qmail@web31504.mail.mud.yahoo.com>

--- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:
> > Here bar_t is equivalent to a plain char*. The size information is lost.
> This
> > due to the C heritage.
> 
> Duh, I keep forgetting about that. But this makes me wondering why the 
> custom converter indeed does the trick in my example.

Sorry, David corrected me here. Apparently there is a difference between

  foo(char s[4])

and what you have. I wasn't aware of that.

> You mean thin wrapper as follows?
> 
> struct wrap_foo : public foo
> {
>    char const *get_bar() { return bar; }
> };
> 
> and then
> 
> class_<foo_derived>("foo")
>    .def_property("bar", &foo_derived::get_bar)
>    ;

You don't have to use inheritance just to provide a wrapper. An unbound
function  will also work if the first argument is foo& or foo const& (and maybe
even foo* etc., I am not sure):

char const*
get_bar(foo& self) { return foo.bar(); }

Then:

  class<foo>("foo")
    .def("get_bar", get_bar)
  ;


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From rwgk at yahoo.com  Mon Jul  4 19:25:29 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 4 Jul 2005 10:25:29 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <20050704034611.GA31236@BigDell>
Message-ID: <20050704172529.10260.qmail@web31509.mail.mud.yahoo.com>

--- Clark <foo.Clark at gmail.com> wrote:
> Yes. But we can still emulate what SWIG does to make a C++ Object be a
> Python Object, and then return it.

I don't think it would be very hard if the SWIG license allows us to copy
fragments from SWIG-1.3.24/Lib/python/python.swg. I didn't check the license,
and I am not in a position to do the legwork... all I can offer is to add my
swig_arg code to the boost tree.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From foo.Clark at gmail.com  Mon Jul  4 20:59:30 2005
From: foo.Clark at gmail.com (Clark)
Date: Tue, 5 Jul 2005 02:59:30 +0800
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <uwto6222z.fsf@boost-consulting.com>
References: <20050630150541.GA12758@BigDell>
	<20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>
	<ud5q064ft.fsf@boost-consulting.com>
	<20050704040736.GB31236@BigDell>
	<uwto6222z.fsf@boost-consulting.com>
Message-ID: <20050704185930.GA693@BigDell>

On Mon, Jul 04, 2005 at 08:22:12AM -0400, David Abrahams wrote:
> Clark <foo.Clark at gmail.com> writes:
> 
> >> 
> >> Oh, I see; all Swig objects have the same type?
> > Yes, they are all PySwigObject.
> 
> Please try to leave a blank line above and below quoted material;
> otherwise it's hard to pick out what you're saying.

Thanks for your advice. Actually, I'm a mail list newbie at present. 
I think most of the people here are very kindly. They would like to
help others for nothing.

> 
> >> Well you need some way to identify the Python objects for which the
> >> above statement is true, unless you want to forego all error checking
> >> and just allow a crash if a Swig-wrapped Foo is passed where a
> >> Swig-wrapped Bar is expected.
> > Sometimes it's critical. 
> 
> Sometimes it's critical to... identify the Python objects for which
> the above statement is true?  Forego all error checking and allow a
> crash?  Something else?

to extract a C++ "this" pointer from a SWIG-wrapped object. 

> 
> > For example, to paint on screen efficiently, we must use the DC's
> > methods in C++ directly. But because usually the GUI or framework is
> > written in Python, we can only get the DC as a Python Object.
> 
> I don't see the connection between that scenario and anything we're
> discussing.

en... The GUI library I used is wxPython, which is wrapped by SWIG. And
other parts of my program is wrapped by Boost.Python. I need extract a
C++ pointer wxDC * from a wxPython's DC. 

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


From dave at boost-consulting.com  Mon Jul  4 22:59:37 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 16:59:37 -0400
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
References: <u3bqv4gc8.fsf@boost-consulting.com>
	<20050704163457.67879.qmail@web31503.mail.mud.yahoo.com>
Message-ID: <u64vqxp6u.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> > This solution is based on what I found in SWIG-1.3.24/Lib/python/pyrun.swg.
>> > At the heart of the solution is this simple fragment:
>> >
>> >     static void* extract(PyObject* op) \
>> >     { \
>> >         if (std::strcmp(op->ob_type->tp_name, "PySwigObject") != 0)
>> >     return 0; \
>> 
>> Isn't there a type object somewhere you can compare ob_type with?
>
> It seemed hard to me. Here is what I understand:
>
> SWIG is a wrapper generator (more similar to Pyste than to Boost.Python). In
> the SWIG-1.3.24/Examples/python/class that I was using, SWIG copies a big chunk
> of code into the generated example_wrap.cxx. This includes the complete
> definition of the type object for PySwigObject. The type definition is
> implemented as a group of static objects in this function: 
>
> SWIGRUNTIME PyTypeObject*
> PySwigObject_GetType();
>
> We'd have to get hold of this function, which I believe will complicate the
> linking severely. But even if we did, it wouldn't get us very far since each
> SWIG-generated extension has its own version of the type object, with its own
> address. That's probably why I found this function:
>
> SWIGRUNTIMEINLINE int
> PySwigObject_Check(PyObject *op) {
>   return ((op)->ob_type == PySwigObject_GetType())
>     || (strcmp((op)->ob_type->tp_name,"PySwigObject") == 0);
> }
>
> I am still wondering why SWIG does "one or the other" and not simply the more
> general "other". The best explanation I can find for myself is optimization for
> speed (pointer equivalence vs. string comparison). Anyway, for me the
> conclusion was clear: it is definitely not worth complicating the build process
> for such a minute gain. If the Python/C++ combination is used sensibly the
> runtime difference will be unmeasurable anyway.

You have grown very wise, O grasshopper.

>> Heh, so that's how they do it.  Pretty lame, IMO.
>
> Hey, let's be politically correct: Pretty basic, at that level.
> They decided to put all their energy into a special parser, which
> clearly has some advantages if you have to deal a lot with C-style
> interfaces. E.g. the int* question is coming up a lot.

You shall now be my master.

>> Well, inheritance
>> won't work; a swig-wrapped Derived won't be able to be passed where a
>> Base is expected.  If that doesn't matter, it's fine.
>
> Is there a way to write something like:
>
>     bases_of<Circle, mpl::vector<Shape> >();

In principle, yes, but it would take some nontrivial coding.

>> >     boost_python_swig_args_ext.show(c.this)
>> >     boost_python_swig_args_ext.show(s.this)
>> 
>> You should have part of the test that shows non-matching types are
>> rejected.
>
> I figured rejection is tested since the overload resolution couldn't work
> otherwise. 

Oh, are you testing overload resolution?  If so, that's enough.

> What exactly do you have in mind?
>
>> > David, would you want to include the core of swig_args_ext.cpp in,
>> > e.g., boost/python/swig_arg.h? I think it would be a valuable
>> > addition. There are many SWIG-wrapped libraries. People could easily
>> > use them while writing their own extensions with Boost.Python.
>> 
>> Sounds great!  Needs docs, of course ;-)
>
> Would you be happy with a page like I wrote for the pickle suite,
> linked from the main page, e.g. "SWIG interoperability"?

Great!

> But I still have a question. I don't really like the interface I came up with
> since it requires two steps:
>
> 1. BOOST_PYTHON_SWIG_ARG(Circle)
>
> 2. swig_arg<Circle>();
>
> It would be nicer if one could simply write
>
>   swig_arg<Circle>("Circle");
>
> Is there any way this could be achieved?

Well of course! No need to build a specialization of swig_arg; the
only thing you're doing with that specialzation is prepending "t" to
the name.  You can just build the string inside the swig_arg ctor.

Are you sure you want to write "Circle" twice?  Seems to me that

      BOOST_PYTHON_SWIG_ARG(Circle)

might be better.

> Actually, here is another question: would it be best to wait until Boost 1.33
> is out?

We are in a main trunk feature-freeze, but doing it now on a branch
would be better than waiting.

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



From dave at boost-consulting.com  Mon Jul  4 23:01:08 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 17:01:08 -0400
Subject: [C++-sig] [boost.python] char arrays in structs
References: <ubr5izg7f.fsf@boost-consulting.com>
	<20050704165634.81204.qmail@web31501.mail.mud.yahoo.com>
Message-ID: <uzmt2wajv.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>
>> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
>> 
>> >
>> > Here bar_t is equivalent to a plain char*. The size information is lost.
>> This
>> > due to the C heritage.
>> 
>> That's incorrect.
>
> Oh, sorry.
> What is correct then?

The size information is not lost; the parameter type is 

  char const(&)[4]

> Why would I want to use "boost::array<char, 4>" instead of "typedef
> char[4]"?

I don't know; I never suggested that idea.  Wasn't that your
suggestion?

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



From dave at boost-consulting.com  Mon Jul  4 23:02:28 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 04 Jul 2005 17:02:28 -0400
Subject: [C++-sig] [boost.python] char arrays in structs
References: <dabld5$o04$1@sea.gmane.org>
	<20050704171207.34997.qmail@web31504.mail.mud.yahoo.com>
Message-ID: <uu0jawahn.fsf@boost-consulting.com>

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

>> You mean thin wrapper as follows?
>> 
>> struct wrap_foo : public foo
>> {
>>    char const *get_bar() { return bar; }
>> };
>> 
>> and then
>> 
>> class_<foo_derived>("foo")
>>    .def_property("bar", &foo_derived::get_bar)
>>    ;
>
> You don't have to use inheritance just to provide a wrapper. 

In fact, it won't work in this case.  You can't call a wrap_foo member
function on a foo object.

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



From markus.schoepflin at comsoft.de  Tue Jul  5 10:08:09 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 05 Jul 2005 10:08:09 +0200
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <20050704171207.34997.qmail@web31504.mail.mud.yahoo.com>
References: <dabld5$o04$1@sea.gmane.org>
	<20050704171207.34997.qmail@web31504.mail.mud.yahoo.com>
Message-ID: <dadf59$kdn$1@sea.gmane.org>

Ralf W. Grosse-Kunstleve wrote:

> You don't have to use inheritance just to provide a wrapper. An unbound
> function  will also work if the first argument is foo& or foo const& (and maybe
> even foo* etc., I am not sure):
> 
> char const*
> get_bar(foo& self) { return foo.bar(); }
> 
> Then:
> 
>   class<foo>("foo")
>     .def("get_bar", get_bar)
>   ;

Yes, this works nicely. Thanks.

Markus



From markus.schoepflin at comsoft.de  Tue Jul  5 10:12:45 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 05 Jul 2005 10:12:45 +0200
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <u64vqzexo.fsf@boost-consulting.com>
References: <dabfqv$7a9$1@sea.gmane.org> <u64vqzexo.fsf@boost-consulting.com>
Message-ID: <dadfdu$l45$2@sea.gmane.org>

David Abrahams wrote:

> Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

>> Is it to be expected that I do need a custom type converter for this?
>> Or do I miss something?

> It's "expected" in the sense that I never thought of implementing 
> automatic conversions for char arrays.

Ok, that's what I wanted to know.

> It should be possible to do, although that would probably get me into
> the position of implementing generalized array conversions (e.g. from
> Python lists).  It's a little bit messy and not something I can get to
> right away.

But it would be a nice thing to have. ;-)

Thanks, Markus



From markus.schoepflin at comsoft.de  Tue Jul  5 10:11:23 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 05 Jul 2005 10:11:23 +0200
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <uu0jawahn.fsf@boost-consulting.com>
References: <dabld5$o04$1@sea.gmane.org>	<20050704171207.34997.qmail@web31504.mail.mud.yahoo.com>
	<uu0jawahn.fsf@boost-consulting.com>
Message-ID: <dadfbb$l45$1@sea.gmane.org>

David Abrahams wrote:

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> 
>>>You mean thin wrapper as follows?
>>>
>>>struct wrap_foo : public foo
>>>{
>>>   char const *get_bar() { return bar; }
>>>};
>>>
>>>and then
>>>
>>>class_<foo_derived>("foo")
>>>   .def_property("bar", &foo_derived::get_bar)
>>>   ;
>>
>>You don't have to use inheritance just to provide a wrapper. 
> 
> In fact, it won't work in this case.  You can't call a wrap_foo member
> function on a foo object.

In fact I wanted to write:

struct wrap_foo : public foo
{
   char const *get_bar() const { return bar; }
};

...

   class_<wrap_foo>("foo")
     .add_property("bar", &wrap_foo::get_bar)
     ;

This works like a charm.

Thanks, Markus



From rwgk at yahoo.com  Tue Jul  5 11:11:28 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 5 Jul 2005 02:11:28 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <20050704185930.GA693@BigDell>
Message-ID: <20050705091128.53267.qmail@web31502.mail.mud.yahoo.com>

--- Clark <foo.Clark at gmail.com> wrote:
> en... The GUI library I used is wxPython, which is wrapped by SWIG. And
> other parts of my program is wrapped by Boost.Python. I need extract a
> C++ pointer wxDC * from a wxPython's DC. 

I have some interest in this, too. Just like you we are using both wxPython and
Boost.Python.

I just checked in a simplified version of my BOOST_PYTHON_SWIG_ARG() macro.
Look here for revision 1.1 of swig_arg.hpp (it may take a couple of hours to
show up, therefore I am also attaching the file):

    http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/

Copy the file somewhere into your source tree (the license is BSD-style open
source). #include "swig_arg.hpp" and write

  BOOST_PYTHON_SWIG_ARG(wxDC)

somewhere in your module's init function. Simply .def() your functions with
wxDC* arguments. In Python, pass dc.this to your wrapped function. See also
swig_args_ext.cpp and tst_swig_args.py in the CVS directory above.

Is this all you need? Or do you also want to pass wxDC* and other wx* objects
to a function with a common base class as argument? That you could do easily
with thin wrappers (one-liners), e.g.:

  void foo(wxObject* obj);
  void foo_dc(wxDC* obj) { foo(obj); }
  void foo_nb(wxNotebook* obj) { foo(obj); }

In your init function:

  BOOST_PYTHON_SWIG_ARG(wxDC);
  BOOST_PYTHON_SWIG_ARG(wxNotebook);
  def("foo", foo_dc);
  def("foo", foo_nb);

Cheers,
        Ralf



		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: swig_arg.hpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/43c267f1/attachment.txt>

From rwgk at yahoo.com  Tue Jul  5 11:14:30 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 5 Jul 2005 02:14:30 -0700 (PDT)
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <uzmt2wajv.fsf@boost-consulting.com>
Message-ID: <20050705091430.7715.qmail@web31513.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> The size information is not lost; the parameter type is 
> 
>   char const(&)[4]

Interesting. I don't think I would have figured this out myself. Thanks!

> > Why would I want to use "boost::array<char, 4>" instead of "typedef
> > char[4]"?
> 
> I don't know; I never suggested that idea.  Wasn't that your
> suggestion?

Yes, because I didn't know about the char const(&)[4] trick.

I played around a bit with char const(&)[N] conversions, starting
with Markus' converter. I got both to_python and from_python
conversions to work under Linux and Tru64 Unix. Here is the
code if anyone is interested:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/char_array_ext.cpp?rev=1.1&view=auto

For the records: I encountered two problems:

- Under Redhat WS 3 (gcc 3.2.3) the char[4] converters
  work with -O0 -g, but not with -O3 -ffast-math.
  char[3] and char[5] work both with and without optimization.

- It compiles but doesn't work under Windows. I don't know why; no
  time to investigate right now. At the moment I just wanted to find
  out if it works in principle.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From rwgk at yahoo.com  Tue Jul  5 11:24:41 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 5 Jul 2005 02:24:41 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <u64vqxp6u.fsf@boost-consulting.com>
Message-ID: <20050705092441.7015.qmail@web31508.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Well of course! No need to build a specialization of swig_arg; the
> only thing you're doing with that specialzation is prepending "t" to
> the name.  You can just build the string inside the swig_arg ctor.
> 
> Are you sure you want to write "Circle" twice?  Seems to me that
> 
>       BOOST_PYTHON_SWIG_ARG(Circle)
> 
> might be better.

I was asking because I wasn't sure about a static template member
being used from a static template member function. But now I am.
See my other posting, or swig_arg.hpp revision 1.1 once it shows up:

  http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/

It is so simple now I could explain it to my grandma.
BTW: I've also tested under Tru64 Unix with cxx (to make sure my
static member handling is kosher).

> > Actually, here is another question: would it be best to wait until Boost
> 1.33
> > is out?
> 
> We are in a main trunk feature-freeze, but doing it now on a branch
> would be better than waiting.

Branch...? Shudder. I'll wait. If someone wants it now it is easy
enough to get (link above).

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From markus.schoepflin at comsoft.de  Tue Jul  5 11:31:26 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 05 Jul 2005 11:31:26 +0200
Subject: [C++-sig] [boost.python] char arrays in structs
In-Reply-To: <dadf59$kdn$1@sea.gmane.org>
References: <dabld5$o04$1@sea.gmane.org>	<20050704171207.34997.qmail@web31504.mail.mud.yahoo.com>
	<dadf59$kdn$1@sea.gmane.org>
Message-ID: <dadk1f$2ba$1@sea.gmane.org>

Markus Sch?pflin wrote:
> Ralf W. Grosse-Kunstleve wrote:
> 
> 
>>You don't have to use inheritance just to provide a wrapper. An unbound
>>function  will also work if the first argument is foo& or foo const& (and maybe
>>even foo* etc., I am not sure):
>>
>>char const*
>>get_bar(foo& self) { return foo.bar(); }
>>
>>Then:
>>
>>  class<foo>("foo")
>>    .def("get_bar", get_bar)
>>  ;

I played with that a little and now I have:

template <class T, class R, R (T::*p)>
char const *get(T const &self)
{
   return self.*p;
}

class_<foo>("foo")
   .add_property("bar", get<foo, char[4], &foo::bar>);

I wonder if there is a way to somehow get rid of specifying char[4] and 
probably foo manually.

Markus



From danny280279 at netscape.net  Tue Jul  5 13:15:19 2005
From: danny280279 at netscape.net (danny280279 at netscape.net)
Date: Tue, 05 Jul 2005 07:15:19 -0400
Subject: [C++-sig] c + python interchangable?
Message-ID: <331A084B.31EAC710.48B2A67E@netscape.net>

hi all i know that c and python are closely interchangable, so I was wondering if there are any docs that could help me change python code over to c code.

__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp


From djowel at gmail.com  Tue Jul  5 13:37:27 2005
From: djowel at gmail.com (Joel de Guzman)
Date: Tue, 05 Jul 2005 19:37:27 +0800
Subject: [C++-sig] Wrapping std::vector<AbstractClass*>
In-Reply-To: <42C584A7.3030607@pecm.nl>
References: <42C584A7.3030607@pecm.nl>
Message-ID: <42CA70F7.9020903@boost-consulting.com>

Paul Melis wrote:
> Hello,
> I have an abstract class and a std::vector<> of pointers to this class. 
> A routine in my c++ code fills a vector with objects of classes derived 
> from the abstract class.
> I'd like to iterate over the vector in python and use each of the items 
> in the vector depending on the type of derived class.
> 
[...]
> 
> I suspect that boost.python will wrap the return value of returnList() 
> as a pointer to Abstract, without the possibility at runtime to look at 
> the actual object type. Is this something I would have to code by hand? 
> For example, by making a routine that takes a pointer to Abstract and 
> uses dynamic_cast<> to test which of the concrete classes the object 
> actually is from?

Pardon the delay. It's been a while. I'm investigating the problem
in more detail. I'll get back to you on this, ok?

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


From dave at boost-consulting.com  Tue Jul  5 15:10:06 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 05 Jul 2005 09:10:06 -0400
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
References: <u64vqxp6u.fsf@boost-consulting.com>
	<20050705092441.7015.qmail@web31508.mail.mud.yahoo.com>
Message-ID: <uhdf9s8k1.fsf@boost-consulting.com>

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

>> We are in a main trunk feature-freeze, but doing it now on a branch
>> would be better than waiting.
>
> Branch...? Shudder. I'll wait. If someone wants it now it is easy
> enough to get (link above).

Why do people fear branching so?

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



From Yves_Secretan at inrs-ete.uquebec.ca  Tue Jul  5 17:30:23 2005
From: Yves_Secretan at inrs-ete.uquebec.ca (Yves Secretan)
Date: Tue, 5 Jul 2005 11:30:23 -0400
Subject: [C++-sig] Same opaque pointer used in 2 modules provoques an
	assertion error
Message-ID: <IOENLEGGNAMHEFJODOADKEDJEBAA.Yves_Secretan@inrs-ete.uquebec.ca>

Hi,

I have a container of pointers and would like to add pointers to this
container from Python using an opaque pointer.
Everything works fine if I have only one module, but if I split the code in
more modules, I get a failed assertion message:
File: 
registry.cpp
Line: 161
Expression: slot ==0
and ignoring the exception:
test.py:11: RuntimeWarning: to-Python converter for struct void_ * already
registered; second conversion method ignored.

My understanding is that each module tries to register a converter, and I
could not find a way to prevent it.

My environnement: boost-1.32.0; Python 2.3; msvc7.0

I join the simplest example I could build: data1.cpp is the first module;
data2.cpp the second module; test.py should display the problem.

Thanks for any help
Yves

---------------------------------------------------------------
Yves Secretan, Professeur
INRS-ETE
490, rue de la Couronne
Qu?bec, Qu?bec
G1K 9A9 CANADA

tel: (418) 654 38 48   fax: (418) 654 26 00
e-mail: Yves_Secretan at ete.inrs.ca
---------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/1190ce73/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data1.cpp
Type: application/octet-stream
Size: 609 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/1190ce73/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data2.cpp
Type: application/octet-stream
Size: 356 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/1190ce73/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jamfile
Type: application/octet-stream
Size: 583 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/1190ce73/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: application/octet-stream
Size: 146 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/1190ce73/attachment-0003.obj>

From dave at boost-consulting.com  Tue Jul  5 17:59:22 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 05 Jul 2005 11:59:22 -0400
Subject: [C++-sig] Same opaque pointer used in 2 modules provoques an
	assertion error
References: <IOENLEGGNAMHEFJODOADKEDJEBAA.Yves_Secretan@inrs-ete.uquebec.ca>
Message-ID: <umzp1p7l1.fsf@boost-consulting.com>

"Yves Secretan" <Yves_Secretan at inrs-ete.uquebec.ca> writes:

> Hi,
>
> I have a container of pointers and would like to add pointers to this
> container from Python using an opaque pointer.
> Everything works fine if I have only one module, but if I split the code in
> more modules, I get a failed assertion message:
> File: 
registry.cpp
> Line: 161
> Expression: slot ==0
> and ignoring the exception:
> test.py:11: RuntimeWarning: to-Python converter for struct void_ * already
> registered; second conversion method ignored.
>
> My understanding is that each module tries to register a converter, and I
> could not find a way to prevent it.
>
> My environnement: boost-1.32.0; Python 2.3; msvc7.0
>
> I join the simplest example I could build: data1.cpp is the first module;
> data2.cpp the second module; test.py should display the problem.
>
> Thanks for any help
> Yves

I think this is a bug in the return value policy.  Looking at it, each
time you use it in a new module the converter will try to register
itself.

What happens when you stop using the return value policy and instead
construct an opaque_pointer_converter<void_*>("void_") in the first of
the two modules to be loaded?

Gottfried,
http://www.boost.org/libs/python/doc/v2/opaque_pointer_converter.html
refers me to
http://www.boost.org/libs/python/doc/v2/return_opaque_pointer.html#example
for an example, but there's no example of the use of
opaque_pointer_converter there.  What should we do about this?

> ---------------------------------------------------------------
> Yves Secretan, Professeur
> INRS-ETE
> 490, rue de la Couronne
> Qu?bec, Qu?bec
> G1K 9A9 CANADA
>
> tel: (418) 654 38 48   fax: (418) 654 26 00
> e-mail: Yves_Secretan at ete.inrs.ca
> ---------------------------------------------------------------
>
>
> #include <boost/python.hpp>
> #include <iostream>
>
> struct container
> {
> 	void add(void* p) { std::cerr << "Adding " << p << std::endl; }
> };
>
> struct data1
> {
> };
>
> struct void_;
> BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_);
>
> void container_add(container& c, void_* p) 
> {
> 	c.add((void*) p); 
> }
>
> void_* data1_asVoid(data1& d) 
> {
> 	return (void_*)(&d); 
> }
>
>
> BOOST_PYTHON_MODULE(data1)
> {
>    using namespace boost::python;
>
>    class_< container >("container")
>       .def("add", &container_add)
>    ;
>
>    class_< data1 >("data1")
>       .def("asVoid", &data1_asVoid, return_value_policy< return_opaque_pointer >())
>    ;
>
> }
>
>
> #include <boost/python.hpp>
>
> struct data2
> {
> };
>
> struct void_;
> BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_);
>
> void_* data2_asVoid(data2& d) 
> {
> 	return (void_*)(&d); 
> }
>
>
> BOOST_PYTHON_MODULE(data2)
> {
>    using namespace boost::python;
>
>    class_< data2 >("data2")
>       .def("asVoid", &data2_asVoid, return_value_policy< return_opaque_pointer >())
>    ;
>
> }
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig

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



From rwgk at yahoo.com  Tue Jul  5 18:45:51 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 5 Jul 2005 09:45:51 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <uhdf9s8k1.fsf@boost-consulting.com>
Message-ID: <20050705164551.27288.qmail@web31514.mail.mud.yahoo.com>

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

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> >> We are in a main trunk feature-freeze, but doing it now on a branch
> >> would be better than waiting.
> >
> > Branch...? Shudder. I'll wait. If someone wants it now it is easy
> > enough to get (link above).
> 
> Why do people fear branching so?

Me: because I found it very difficult to branch individual files, and because
clean incremental merging requires excessive tagging. I hope it is going to be
a lot better with subversion.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From ganssauge at gmx.de  Tue Jul  5 18:55:47 2005
From: ganssauge at gmx.de (=?UTF-8?B?R290dGZyaWVkIEdhbsOfYXVnZQ==?=)
Date: Tue, 05 Jul 2005 18:55:47 +0200
Subject: [C++-sig] Same opaque pointer used in 2 modules provoques an
 assertion error
In-Reply-To: <umzp1p7l1.fsf@boost-consulting.com>
References: <IOENLEGGNAMHEFJODOADKEDJEBAA.Yves_Secretan@inrs-ete.uquebec.ca>
	<umzp1p7l1.fsf@boost-consulting.com>
Message-ID: <42CABB93.3010405@gmx.de>

David Abrahams writes:
...
> 
> Gottfried,
> http://www.boost.org/libs/python/doc/v2/opaque_pointer_converter.html
> refers me to
> http://www.boost.org/libs/python/doc/v2/return_opaque_pointer.html#example
> for an example, but there's no example of the use of
> opaque_pointer_converter there.  What should we do about this?
I can't say too much about the problem itself but the example definitely
isn't missing but instead is referred to by a wrong name.
Attached find a patch to correct it.

Cheers,

Gottfried
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opaque_pointer_converter.html.patch
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050705/8edb3a11/attachment.txt>

From grobinson at goombah.com  Tue Jul  5 19:26:56 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Tue, 5 Jul 2005 13:26:56 -0400
Subject: [C++-sig] setup.py denies VS6 installed
Message-ID: <20050705132656.161076.957b15bb@goombah.com>

Hi,

I have installed Visual Studio 6 on my XP box.

I'm trying to build an extension with setup.py. 

When I enter

    python setup.py build

at the command prompt, it says:

    error: Python was built with Version 6 of Visual Studio, 
    and extensions need to be built with the same version 
    of the compiler, but it isn't installed.

As I said, it IS installed -- at least in the sense that I can bring up 
Visual Studio 6 from the Start menu. Also, the path variable contains  
Visual Studio stuff which I assume was put there by the installer.


Any ideas for how I can get setup.py builds working on my machine?

Thanks,
Gary


-- 

Gary Robinson
CTO
Emergent Music, LLC
grobinson at goombah.com
207-942-3463
Company: http://www.goombah.com
Blog:    http://www.garyrobinson.net


From jkankiewicz at advpubtech.com  Tue Jul  5 20:35:25 2005
From: jkankiewicz at advpubtech.com (Jason Kankiewicz)
Date: Tue, 05 Jul 2005 11:35:25 -0700
Subject: [C++-sig] c + python interchangable?
In-Reply-To: <331A084B.31EAC710.48B2A67E@netscape.net>
References: <331A084B.31EAC710.48B2A67E@netscape.net>
Message-ID: <daeju3$6rl$1@sea.gmane.org>

They're interchangeable in a sense because Python is implemented in C 
and therefore any Python program must have an equivalent C 
implementation. They're not interchangeable in a sense because Python is 
an interpreted, dynamically-typed, garbage-collected language and not a 
compiled, statically-typed, non-garbage-collected language like C.

Python complements C by addressing its weaknesses. Python's greatest 
weakness is speed but this can be addressed by re-coding the slowest 
parts of a Python program in C (or C++ using Boost.Python or SWIG) as an 
extension module. This "hybrid programming" approach should take much 
less work and yield similar results to re-coding an entire Python 
program in C.

danny280279 at netscape.net wrote:
> hi all i know that c and python are closely interchangable, so I was wondering if there are any docs that could help me change python code over to c code.
> 
> __________________________________________________________________
> Switch to Netscape Internet Service.
> As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register
> 
> Netscape. Just the Net You Need.
> 
> New! Netscape Toolbar for Internet Explorer
> Search from anywhere on the Web and block those annoying pop-ups.
> Download now at http://channels.netscape.com/ns/search/install.jsp



From grobinson at goombah.com  Tue Jul  5 21:29:08 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Tue, 5 Jul 2005 15:29:08 -0400
Subject: [C++-sig] setup.py denies VS6 installed
In-Reply-To: <20050705132656.161076.957b15bb@goombah.com>
References: <20050705132656.161076.957b15bb@goombah.com>
Message-ID: <20050705152908.462285.090398c3@goombah.com>

> Any ideas for how I can get setup.py builds working on my machine?

Never mind. I have it working now. Sorry for asking so many questions 
-- we're under an intense deadline here and so I'm swallowing my pride 
asking for help where I think it might  save a lot of time. Hopefully 
when I know more I'll be able to contribute here myself.

Gary

-- 

Gary Robinson
CTO
Emergent Music, LLC
grobinson at goombah.com
207-942-3463
Company: http://www.goombah.com
Blog:    http://www.garyrobinson.net



From dave at boost-consulting.com  Tue Jul  5 21:44:06 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 05 Jul 2005 15:44:06 -0400
Subject: [C++-sig] Same opaque pointer used in 2 modules provoques an
	assertion error
References: <IOENLEGGNAMHEFJODOADKEDJEBAA.Yves_Secretan@inrs-ete.uquebec.ca>
	<umzp1p7l1.fsf@boost-consulting.com> <42CABB93.3010405@gmx.de>
Message-ID: <u8y0lm41l.fsf@boost-consulting.com>

Gottfried Gan?auge <ganssauge at gmx.de> writes:

> David Abrahams writes:
> ...
>> 
>> Gottfried,
>> http://www.boost.org/libs/python/doc/v2/opaque_pointer_converter.html
>> refers me to
>> http://www.boost.org/libs/python/doc/v2/return_opaque_pointer.html#example
>> for an example, but there's no example of the use of
>> opaque_pointer_converter there.  What should we do about this?
>
> I can't say too much about the problem itself but the example definitely
> isn't missing but instead is referred to by a wrong name.

It certainly is missing, if the example is supposed to show the user
anything about opaque_pointer_converter.  The only place that
identifier is mentioned on the page is in a "See Also" section.

> Attached find a patch to correct it.

That doesn't really fix the problem I'm referring to.


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



From dave at boost-consulting.com  Tue Jul  5 21:45:22 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 05 Jul 2005 15:45:22 -0400
Subject: [C++-sig] setup.py denies VS6 installed
References: <20050705132656.161076.957b15bb@goombah.com>
Message-ID: <u1x6dm3zh.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> Hi,
>
> I have installed Visual Studio 6 on my XP box.
>
> I'm trying to build an extension with setup.py. 
>
> When I enter
>
>     python setup.py build
>
> at the command prompt, it says:
>
>     error: Python was built with Version 6 of Visual Studio, 
>     and extensions need to be built with the same version 
>     of the compiler, but it isn't installed.

This is a distutils question AFAICT.  You should ask the provider of
the specific setup.py script you're invoking.

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



From dave at boost-consulting.com  Tue Jul  5 21:45:01 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 05 Jul 2005 15:45:01 -0400
Subject: [C++-sig] setup.py denies VS6 installed
References: <20050705132656.161076.957b15bb@goombah.com>
Message-ID: <u3bqtm402.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> Hi,
>
> I have installed Visual Studio 6 on my XP box.
>
> I'm trying to build an extension with setup.py. 
>
> When I enter
>
>     python setup.py build
>
> at the command prompt, it says:
>
>     error: Python was built with Version 6 of Visual Studio, 
>     and extensions need to be built with the same version 
>     of the compiler, but it isn't installed.

This is a distutils question AFAICT.  You should ask the provider of
the specific setup.py script you're invoking.

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



From danny280279 at netscape.net  Wed Jul  6 02:18:19 2005
From: danny280279 at netscape.net (danny280279 at netscape.net)
Date: Tue, 05 Jul 2005 20:18:19 -0400
Subject: [C++-sig] c + python interchangable?
Message-ID: <588965E5.0665FDA2.48B2A67E@netscape.net>

Jason Kankiewicz <jkankiewicz at advpubtech.com> wrote:

>They're interchangeable in a sense because Python is implemented in C 
>and therefore any Python program must have an equivalent C 
>implementation. They're not interchangeable in a sense because Python is 
>an interpreted, dynamically-typed, garbage-collected language and not a 
>compiled, statically-typed, non-garbage-collected language like C.

So what your saying is (code here:)

#define DEBUG

#include 
#include 
#include 
#include 
#include 
#include 

are static links to code comapred to 

def debug

import
import
import

because to me they seem the same, or am i just being stupid?

if that's the case then are there any docs on hybrid programming, because then i could implement all of it in hybrid python/c.

>
>Python complements C by addressing its weaknesses. Python's greatest 
>weakness is speed but this can be addressed by re-coding the slowest 
>parts of a Python program in C (or C++ using Boost.Python or SWIG) as an 
>extension module. This "hybrid programming" approach should take much 
>less work and yield similar results to re-coding an entire Python 
>program in C.
>
my code for findfiles - this is to be renamed and reimplemented as search, a natural language command that can be integrated with package management software to do something like "search package install run". but this still doesn't do what the commands meant to:  Search (the net) (find)Package Install(package) Run(package), type the name of a package in your browser and it comes up with a site that contains that package:  this is a search for autotools (gnu) http://sources.redhat.com/autobook/ now if you could do that using the search command then you could get "search autotools install run" and it would directly go for the above url, query the site, download, and install the files, then run the application, actually here i think you get a docbook that can be run in yelp or something.

#define DEBUG

#include 
#include 
#include 
#include 
#include 
#include 

static ERROR CMDInit(OBJECTPTR, struct KernelBase *);
static ERROR CMDExpunge(void);

#define VER_FINDFILES 1.0

MODULE_HEADER = {
   MODULE_HEADER_V1, CMDInit, NULL, NULL, CMDExpunge,
   JMP_DEFAULT, 0, CPU_PC, VER_FINDFILES, VER_KERNEL,
   "",
   "",
   "",
   ""
};

static struct KernelBase *KernelBase;
static struct FileSystemBase *FileSystemBase;
static struct StringsBase *StringsBase;
static OBJECTPTR modFile = NULL, modStrings = NULL;
static OBJECTPTR FindFilesClass = NULL;
static FIELD FID_SrcFile, FID_DestFile;

struct FindFiles {
   OBJECT_HEADER       
   OBJECTID OutputID;
   LONG     Static;
   LONG     Operation;
   LONG     Response;
   LONG     Flags;

   PRIVATE_FIELDS
   UBYTE Location[300];   
   UBYTE Filter[40];      
   UBYTE Content[60];     
   UBYTE prvFile[160];    
   UBYTE Dest[300];
   BYTE  Stop;
   LONG  TotalChildren;      
   STRING ConfirmScript;
   STRING ErrorScript;
   UBYTE *DataBuffer;
   struct ChildEntry ChildList[10];
};

enum {
   FOP_NONE=0,
   FOP_COPY,
   FOP_MOVE,
   FOP_DELETE
};

enum {
   RSP_NONE=0,
   RSP_CANCEL,
   RSP_YES,
   RSP_YESALL,
   RSP_NO
};

static ERROR GET_ConfirmScript(struct FindFiles *, STRING *);
static ERROR GET_Dest(struct FindFiles *, STRING *);
static ERROR GET_ErrorScript(struct FindFiles *, STRING *);
static ERROR GET_File(struct FindFiles *, STRING *);
static ERROR GET_FileContent(struct FindFiles *, STRING *);
static ERROR GET_Filter(struct FindFiles *, STRING *);
static ERROR GET_Location(struct FindFiles *, STRING *);

static ERROR SET_ConfirmScript(struct FindFiles *, STRING);
static ERROR SET_Dest(struct FindFiles *, STRING);
static ERROR SET_ErrorScript(struct FindFiles *, STRING);
static ERROR SET_FileContent(struct FindFiles *, STRING);
static ERROR SET_Filter(struct FindFiles *, STRING);
static ERROR SET_Location(struct FindFiles *, STRING);

#define FF_FORCEDIR     0x00000001
#define FF_INCLUDEROOT  0x00000002
#define FF_XML          0x00000004
#define FF_NOACTIVATE   0x00000008 
#define FF_SCANLINKS    0x00000010 
#define FF_MATCHFOLDERS 0x00000020 
#define FF_IGNOREFILES  0x00000040 

static struct FieldDef FindFlags[] = {
   { "FORCEDIR",     FF_FORCEDIR },
   { "INCLUDEROOT",  FF_INCLUDEROOT },
   { "XML",          FF_XML },
   { "NOACTIVATE",   FF_NOACTIVATE },
   { "SCANLINKS",    FF_SCANLINKS },
   { "MATCHFOLDERS", FF_MATCHFOLDERS },
   { "IGNOREFILES",  FF_IGNOREFILES },
   { NULL, NULL }
};

static struct FieldDef OperationLookup[] = {
   { "NONE",   NULL },
   { "COPY",   FOP_COPY },
   { "MOVE",   FOP_MOVE },
   { "DELETE", FOP_DELETE },
   { NULL, NULL }
};

static struct FieldDef ResponseLookup[] = {
   { "CANCEL", RSP_CANCEL },
   { "YES",    RSP_YES },
   { "YESALL", RSP_YESALL },
   { "NO",     RSP_NO },
   { "NOALL",  RSP_CANCEL },
   { NULL, NULL }
};

static struct FieldArray FindFilesFields[] = {
   { "Output",        0, FDF_OBJECTID|FDF_RW,  0, NULL, NULL },
   { "Static",        0, FDF_LONG|FDF_RW,      0, NULL, NULL },
   { "Operation",     0, FDF_LONG|FDF_LOOKUP|FDF_RW, (LONG)&OperationLookup, NULL, NULL },
   { "Response",      0, FDF_LONG|FDF_LOOKUP|FDF_RW, (LONG)&ResponseLookup, NULL, NULL },
   { "Flags",         0, FDF_LONGFLAGS|FDF_RW, (LONG)&FindFlags, NULL, NULL },
   { "ConfirmScript", 0, FDF_STRING|FDF_RW, 0, GET_ConfirmScript, SET_ConfirmScript },
   { "Dest",          0, FDF_STRING|FDF_RW, 0, GET_Dest,          SET_Dest },
   { "ErrorScript",   0, FDF_STRING|FDF_RW, 0, GET_ErrorScript,   SET_ErrorScript },
   { "File",          0, FDF_STRING|FDF_R,  0, GET_File,          NULL },
   { "FileContent",   0, FDF_STRING|FDF_RW, 0, GET_FileContent,   SET_FileContent },
   { "Filter",        0, FDF_STRING|FDF_RW, 0, GET_Filter,        SET_Filter },
   { "Location",      0, FDF_STRING|FDF_RW, 0, GET_Location,      SET_Location },
   { "Src",           0, FDF_STRING|FDF_RW, 0, GET_Location,      SET_Location },
    END_FIELD
};

static ERROR FIND_Activate(struct FindFiles *, APTR);
static ERROR FIND_ClosingTag(struct FindFiles *, APTR);
static ERROR FIND_Deactivate(struct FindFiles *, APTR);
static ERROR FIND_Free(struct FindFiles *, APTR);
static ERROR FIND_Init(struct FindFiles *, APTR);

static struct ActionArray FindFilesActions[] = {
   { AC_Activate,      FIND_Activate },
   { AC_ClosingTag,    FIND_ClosingTag },
   { AC_Deactivate,    FIND_Deactivate },
   { AC_Free,          FIND_Free },
   { AC_Init,          FIND_Init },
   { NULL, NULL }
};

#define MT_AddLocation -1

struct mtAddLocation {
   STRING Location;
};

static struct FunctionField argsAddLocation[] = { { "Location", ARG_STRING }, { NULL, NULL } };

static ERROR FIND_AddLocation(struct FindFiles *, struct mtAddLocation *);

static struct MethodArray FindFilesMethods[] = {
   { MT_AddLocation, FIND_AddLocation, "AddLocation", argsAddLocation, sizeof(struct mtAddLocation) },
   { NULL, NULL, NULL, NULL }
};

static LONG ContentMatch(struct FindFiles *, STRING, STRING, UBYTE *);
static void FileMatched(struct FindFiles *, STRING, STRING, OBJECTPTR, struct DirInfo *);
static void OutputText(struct FindFiles *, STRING);
static void ScanLocation(struct FindFiles *, STRING, OBJECTPTR);
static void UserConfirmation(struct FindFiles *, STRING, STRING);
static void UserError(struct FindFiles *, STRING, ERROR);
static ERROR FileCopy(struct FindFiles *, STRING, STRING);
static ERROR FileDelete(struct FindFiles *, STRING);
static ERROR FileMove(struct FindFiles *, STRING, STRING);

static BYTE FindFilesUsage[] = {
"USAGE: findfiles [src]=filename [content]=filecontent [filter]=namefilter\n\
\n\
Use the FindFiles command to search for files in your system.  At a minimum you should supply the directory location from which you wish to start the search.  Optionally you can also search on file content and filter on file names.  Here is an example that searches for PNG files:\n\
\n\
  findfiles src=athene:pictures/ filter=*.png\n\
\n\
If you do not specify the starting location, the search will start from the home: location."
};

static ERROR CMDInit(OBJECTPTR argModule, struct KernelBase *argKernelBase)
{
   KernelBase = argKernelBase;

   if (CreateObject(ID_MODULE, NULL, &modStrings, NULL,
      FID_Name|TSTRING,   "strings",
      FID_Version|TFLOAT, MODVERSION_STRINGS,
      TAGEND) IS ERR_Okay) {
      if (GetField(modStrings, FID_ModBase, FT_POINTER, &StringsBase) != ERR_Okay) {
         return(ObjectError(argModule, ERH_InitModule, ERR_GetField));
      }
   }
   else return(ObjectError(argModule, ERH_InitModule, ERR_CreateObject));

   if (CreateObject(ID_MODULE, NULL, &modFile, NULL,
      FID_Name|TSTRING,   "filesystem",
      FID_Version|TFLOAT, MODVERSION_FILESYSTEM,
      TAGEND) IS ERR_Okay) {
      if (GetField(modFile, FID_ModBase, FT_POINTER, &FileSystemBase) != ERR_Okay) {
         return(ObjectError(argModule, ERH_InitModule, ERR_GetField));
      }
   }
   else return(ObjectError(argModule, ERH_InitModule, ERR_CreateObject));

   ResolveFields("SrcFile",  &FID_SrcFile,
                 "DestFile", &FID_DestFile,
                 TAGEND);

   return(CreateObject(ID_CLASS, NULL, (OBJECTPTR *)&FindFilesClass, NULL,
      FID_BaseClassID|TLONG, ID_FINDFILES,
      FID_Version|TFLOAT,    VER_FINDFILES,
      FID_Name|TSTRING,      "FindFiles",
      FID_Category|TLONG,    CCF_COMMAND,
      FID_Usage|TSTRING,     FindFilesUsage,
      FID_Actions|TPTR,      FindFilesActions,
      FID_Methods|TPTR,      FindFilesMethods,
      FID_Fields|TPTR,       FindFilesFields,
      FID_Size|TLONG,        sizeof(struct FindFiles),
      TAGEND));
}

static ERROR CMDExpunge(void)
{
   if (FindFilesClass) { acFree(FindFilesClass); FindFilesClass = NULL; }
   if (modFile)        { acFree(modFile); modFile = NULL; }
   if (modStrings)     { acFree(modStrings); modStrings = NULL; }
   return(ERR_Okay);
}

static BYTE IsDirectory(STRING Path)
{
   WORD i;

   if (!Path) return(FALSE);

   for (i=0; Path[i]; i++);
   if ((Path[i-1] IS '/') OR (Path[i-1] IS '\\') OR (Path[i-1] IS ':')) return(TRUE);
   return(FALSE);
}

#define BUFFER_SIZE 4096

static ERROR FIND_Activate(struct FindFiles *Self, APTR Void)
{
   struct DirInfo list;
   OBJECTPTR output;
   STRING buffer;
   ERROR error;
   WORD len, i, k;

   if (!Self->Location) {
      if (SetField(Self, FID_Location, FT_STRING, "athene:") != ERR_Okay) {
         OutputText(Self, "Error: You have not given me a location.");
         return(ERR_FieldNotSet);
      }
   }

   if (Self->TotalChildren IS -1) {
      Self->TotalChildren = ARRAYSIZE(Self->ChildList);
      ListChildren(Self->Head.UniqueID, Self->ChildList, &Self->TotalChildren);
   }

   if (!Self->Response) Self->Response = RSP_YES;
   else {

      if (Self->Response IS RSP_CANCEL) return(ERR_Okay);
   }

   if ((Self->Operation IS FOP_DELETE) AND (Self->ConfirmScript)) {
      if (Self->Response != RSP_YESALL) {
         UserConfirmation(Self, Self->Location, Self->Location);
      }
      if ((Self->Response != RSP_YES) AND (Self->Response != RSP_YESALL)) {
         DPrintF("FindFiles:","User cancelled deletion of this file - response %d.", Self->Response);
         return(ERR_Okay);
      }
   }

   output = NULL;
   if (Self->OutputID) {
      if (AccessObject(Self->OutputID, 3000, &output) != ERR_Okay) {
         return(ObjectError(Self, ERH_Activate, ERR_AccessObject));
      }
      Action(AC_Clear, output, NULL);
   }

   DPrintF("~Activate()","[FindFiles:%d] Filter: %s, Location: %s, Content: %s, Operation: %s", GetUniqueID(Self), Self->Filter, Self->Location, Self->Content, OperationLookup[Self->Operation]);

   if (AllocMemory(BUFFER_SIZE, MEM_STRING|MEM_NOCLEAR, (APTR *)&buffer, NULL) IS ERR_Okay) {
      if (AllocMemory(BUFFER_SIZE, MEM_STRING|MEM_NOCLEAR, (APTR *)&Self->DataBuffer, NULL) IS ERR_Okay) {

         Self->Stop = FALSE;

         error = ERR_Okay;

         for (len=0; Self->Location[len]; len++) buffer[len] = Self->Location[len];
         buffer[len] = 0;

         if (IsDirectory(Self->Location) IS TRUE) {

            k = StrLength(Self->Dest);
            if (Self->Flags & FF_INCLUDEROOT) {
               if ((buffer[len-1] IS '/') OR (buffer[len-1] IS '\\')) {
                  i = len-1;
                  while ((i > 0) AND (buffer[i-1] != ':') AND (buffer[i-1] != '/') AND (buffer[i-1] != '\\')) i--;
                  StrCopy(buffer+i, Self->Dest+k, sizeof(Self->Dest)-k);
               }
            }

            #ifndef DEBUG
               DebugState(FALSE, -1);
            #endif

            ScanLocation(Self, buffer, output);

            #ifndef DEBUG
               DebugState(TRUE, -1);
            #endif

            Self->Dest[k] = 0;
         }
         else {

            while ((len > 0) AND (buffer[len-1] != '/') AND (buffer[len-1] != ':') AND (buffer[len-1] != '\\')) len--;

            if ((!Self->Filter[0]) OR (StrCompare(Self->Filter, buffer+len, 0, STR_WILDCARD) IS ERR_Okay)) {
               if (ContentMatch(Self, buffer, Self->Content, Self->DataBuffer) IS TRUE) {
                  UBYTE filename[256];
                  StrCopy(buffer+len, filename, sizeof(filename));
                  buffer[len] = 0;
                  ClearMemory(&list, sizeof(list));
                  FileMatched(Self, buffer, filename, output, &list);
               }
            }
         }

         FreeMemory(Self->DataBuffer);
         Self->DataBuffer = NULL;
      }
      else error = ObjectError(Self, ERH_Activate, ERR_AllocMemory);

      FreeMemory(buffer);
   }
   else error = ObjectError(Self, ERH_Activate, ERR_AllocMemory);

   if (output) ReleaseObject(output);

   StepBack();
   return(error);
}

static ERROR FIND_AddLocation(struct FindFiles *Self, struct mtAddLocation *Args)
{
   if ((!Args) OR (!Args->Location)) return(ERR_Args);



   return(ERR_Okay);
}

static ERROR FIND_ClosingTag(struct FindFiles *Self, APTR Void)
{
   Self->TotalChildren = ARRAYSIZE(Self->ChildList);
   ListChildren(Self->Head.UniqueID, Self->ChildList, &Self->TotalChildren);

   if (Self->Static IS FALSE) {
      Action(AC_Activate, Self, NULL);
      Action(AC_Free, Self, NULL);
   }

   return(ERR_Okay);
}

static ERROR FIND_Deactivate(struct FindFiles *Self, APTR Void)
{
   Self->Stop = TRUE;
   return(ERR_Okay);
}

static ERROR FIND_Free(struct FindFiles *Self, APTR Void)
{
   if (Self->ConfirmScript) {
      FreeMemory(Self->ConfirmScript);
      Self->ConfirmScript = NULL;
   }

   if (Self->ErrorScript) {
      FreeMemory(Self->ErrorScript);
      Self->ErrorScript = NULL;
   }

   return(ERR_Okay);
}

static ERROR FIND_Init(struct FindFiles *Self, APTR Void)
{
   Self->TotalChildren = -1;
   return(ERR_Okay);
}

static ERROR GET_ConfirmScript(struct FindFiles *Self, STRING *Value)
{
   if ((*Value = Self->ConfirmScript)) {
      *Value = Self->ConfirmScript;
      return(ERR_Okay);
   }
   else return(ERR_FieldNotSet);

   return(ERR_Okay);
}

static ERROR SET_ConfirmScript(struct FindFiles *Self, STRING Value)
{
   LONG i;

   if (Self->ConfirmScript) { FreeMemory(Self->ConfirmScript); Self->ConfirmScript = NULL; }

   if ((Value) AND (*Value)) {
      for (i=0; Value[i]; i++);
      if (AllocMemory(i+1, MEM_STRING|MEM_NOCLEAR, (void **)&Self->ConfirmScript, NULL) IS ERR_Okay) {
         for (i=0; Value[i]; i++) Self->ConfirmScript[i] = Value[i];
         Self->ConfirmScript[i] = 0;
         return(ERR_Okay);
      }
      else return(ObjectError(Self, ERH_SetField, ERR_AllocMemory));
   }
   return(ERR_Okay);
}

static ERROR GET_Dest(struct FindFiles *Self, STRING *Value)
{
   if (Self->Dest[0]) {
      *Value = Self->Dest;
      return(ERR_Okay);
   }
   else return(ERR_FieldNotSet);
}

static ERROR SET_Dest(struct FindFiles *Self, STRING Value)
{
   WORD i;

   if (Value) {
      for (i=0; (i < sizeof(Self->Dest)-1) AND (Value[i]); i++) Self->Dest[i] = Value[i];
      Self->Dest[i] = 0;
   }
   else Self->Dest[0] = 0;

   return(ERR_Okay);
}

static ERROR GET_ErrorScript(struct FindFiles *Self, STRING *Value)
{
   if ((*Value = Self->ErrorScript)) {
      *Value = Self->ErrorScript;
      return(ERR_Okay);
   }
   else return(ERR_FieldNotSet);
}

static ERROR SET_ErrorScript(struct FindFiles *Self, STRING Value)
{
   LONG i;

   if (Self->ErrorScript) { FreeMemory(Self->ErrorScript); Self->ErrorScript = NULL; }

   if ((Value) AND (*Value)) {
      for (i=0; Value[i]; i++);
      if (AllocMemory(i+1, MEM_STRING|MEM_NOCLEAR, (void **)&Self->ErrorScript, NULL) IS ERR_Okay) {
         for (i=0; Value[i]; i++) Self->ErrorScript[i] = Value[i];
         Self->ErrorScript[i] = 0;
         return(ERR_Okay);
      }
      else return(ObjectError(Self, ERH_SetField, ERR_AllocMemory));
   }
   return(ERR_Okay);
}

static ERROR GET_File(struct FindFiles *Self, STRING *Value)
{
   if ((*Value = Self->prvFile)) return(ERR_Okay);
   else return(ERR_FieldNotSet);
}

static ERROR GET_FileContent(struct FindFiles *Self, STRING *Value)
{
   if (Self->Content[0]) {
      *Value = Self->Content;
      return(ERR_Okay);
   }
   else {
      *Value = NULL;
      return(ERR_FieldNotSet);
   }
}

static ERROR SET_FileContent(struct FindFiles *Self, STRING Value)
{
   WORD i;

   if (Value) {
      for (i=0; (i < sizeof(Self->Content)-1) AND (Value[i]); i++) Self->Content[i] = Value[i];
      Self->Content[i] = 0;
   }
   else Self->Content[0] = 0;

   return(ERR_Okay);
}

static ERROR GET_Filter(struct FindFiles *Self, STRING *Value)
{
   if (Self->Filter[0]) {
      *Value = Self->Filter;
      return(ERR_Okay);
   }
   else {
      *Value = NULL;
      return(ERR_FieldNotSet);
   }
}

static ERROR SET_Filter(struct FindFiles *Self, STRING Value)
{
   WORD i;

   if (Value) {
      for (i=0; (i < sizeof(Self->Filter)-1) AND (Value[i]); i++) Self->Filter[i] = Value[i];
      Self->Filter[i] = 0;
   }
   else Self->Filter[0] = 0;

   return(ERR_Okay);
}

static ERROR GET_Location(struct FindFiles *Self, STRING *Value)
{
   if (Self->Location[0]) {
      *Value = Self->Location;
      return(ERR_Okay);
   }
   else {
      *Value = NULL;
      return(ERR_FieldNotSet);
   }
   return(ERR_Okay);
}

static ERROR SET_Location(struct FindFiles *Self, STRING Value)
{
   WORD i;

   if ((Value) AND (*Value)) {
      for (i=0; (i < sizeof(Self->Location)-2) AND (Value[i]); i++) Self->Location[i] = Value[i];
      if (Self->Flags & FF_FORCEDIR) if ((Value[i-1] != '/') AND (Value[i-1] != ':') AND (Value[i-1] != '\\')) Self->Location[i++] = '/';
      Self->Location[i] = 0;
   }
   else Self->Location[0] = 0;

   return(ERR_Okay);
}

static void OutputText(struct FindFiles *Self, STRING Buffer)
{
   struct acDataChannel channel;

   if (Self->OutputID) {
      /*** Send the data to the output object ***/

      ActionMsg(AC_Clear, Self->OutputID, NULL);

      channel.ObjectID     = GetUniqueID(Self);
      channel.DataType     = DATA_TEXT;
      channel.Version      = 1;
      channel.TotalEntries = 1;
      channel.Buffer       = Buffer;
      channel.Size         = StrLength(Buffer) + 1;
      ActionMsg(AC_DataChannel, Self->OutputID, &channel);
   }
}

static LONG ContentMatch(struct FindFiles *Self, STRING Location, STRING Content, UBYTE *DataBuffer)
{
   struct acRead read;
   struct File *file;
   LONG size;
   WORD k, j;

   if ((!Content) OR (!*Content)) return(TRUE);

   if (CreateObject(ID_FILE, NULL, &file, NULL,
      FID_Location|TSTRING, Location,
      FID_Flags|TLONG,      FL_READ,
      TAGEND) IS ERR_Okay) {

      if ((file->Flags & FL_SYMLINK) AND (!(Self->Flags & FF_SCANLINKS))) {
         acFree(file);
         return(FALSE);
      }

      GetField(file, FID_Size, FT_LONG, &size);
      k = 0;
      while (size > 0) {
         read.Buffer = DataBuffer;
         if (size < BUFFER_SIZE) read.Length = size;
         else read.Length = BUFFER_SIZE;
         Action(AC_Read, file, &read);
         for (j=0; (j < size) AND (j < BUFFER_SIZE); j++) {
            if (lcase(DataBuffer[j]) != lcase(Content[k])) k = 0;
            else {
               k++;
               if (!Content[k]) {
                  acFree(file);
                  return(TRUE);
               }
            }
         }

         ProcessMessages(NULL, NULL);
         if (Self->Stop IS TRUE) break;

         size -= BUFFER_SIZE;
      }
      acFree(file);
   }

   return(FALSE);
}

static void FileMatched(struct FindFiles *Self, STRING Path, STRING Filename, OBJECTPTR Output, struct DirInfo *Info)
{
   UBYTE buffer[256];
   OBJECTPTR object;
   WORD j, pathlen, filelen, fullpath_len;

   for (pathlen=0; Path[pathlen]; pathlen++);
   for (filelen=0; Filename[filelen]; filelen++);

   fullpath_len = StrCopy(Path, Self->prvFile, sizeof(Self->prvFile));
   StrCopy(Filename, Self->prvFile + fullpath_len, sizeof(Self->prvFile) - fullpath_len);

   if (Output) {
      if (Self->Flags & FF_XML) {
         StrFormat(buffer, sizeof(buffer), "<file icon=\"%s\">%s<folder>%s</folder><size sort=\"%.10d\">%d</size><date>%4d%2d%2d %d:%d:%d</date></file>", GetFileIcon(Self->prvFile), Filename, Path, (LONG)Info->Size, (LONG)Info->Size, Info->Time.Year, Info->Time.Month, Info->Time.Day, Info->Time.Hour, Info->Time.Minute, Info->Time.Second);
         ActionTags(AC_DataChannel, Output, Self->Head.UniqueID, DATA_XML, 1, buffer, StrLength(buffer)+1, 1);
      }
      else ActionTags(AC_DataChannel, Output, Self->Head.UniqueID, DATA_TEXT, 1, Self->prvFile, StrLength(Self->prvFile) + 1, 1);
   }

   if ((Self->TotalChildren > 0) AND (!(Self->Flags & FF_NOACTIVATE))) {
      
      for (j=0; j < Self->TotalChildren; j++) {
         if (AccessObject(Self->ChildList[j].ObjectID, 0, &object) IS ERR_Okay) {
            acActivate(object);
            ReleaseObject(object);
         }
      }
   }

   if (Self->Operation) {
      switch (Self->Operation) {
         case FOP_DELETE:
            FileDelete(Self, Self->prvFile);
            break;

         case FOP_COPY:
            FileCopy(Self, Self->prvFile, Filename);
            break;

         case FOP_MOVE:
            FileMove(Self, Self->prvFile, Filename);
            break;
      }
   }
}

static void ScanLocation(struct FindFiles *Self, STRING Buffer, OBJECTPTR output)
{
   struct DirInfo *info;
   LONG k, bufferlen, count, flags;
   WORD root, len, insert, dest_created;
   ERROR error;

   if (Self->Dest[0]) DPrintF("ScanLocation()","%s TO %s", Buffer, Self->Dest);
   else DPrintF("ScanLocation()","%s", Buffer);

   if ((Buffer[0] IS ':') OR (!Buffer[0])) root = TRUE;
   else root = FALSE;

   if (Self->Stop IS TRUE) return;

   for (len=0; Buffer[len]; len++);

   count = 0;
   dest_created = FALSE;
   flags = RDF_FILE|RDF_SIZE|RDF_DATE|RDF_PERMISSIONS;
   if (Self->Flags & FF_MATCHFOLDERS) flags |= RDF_DIRECTORY|RDF_QUALIFY;
   if (Self->Flags & FF_IGNOREFILES) flags &= ~RDF_FILE;
   
   if (OpenDirectory(Buffer, flags, &info) IS ERR_Okay) {
      while (ScanDirectory(info) IS ERR_Okay) {
         count++;
         ProcessMessages(NULL, NULL);

         for (k=0; info->Name[k]; k++) Buffer[len+k] = info->Name[k];
         Buffer[len+k] = 0;
         bufferlen = len+k;

         if (StrCompare(Self->Filter, info->Name, 0, STR_WILDCARD) != ERR_Okay) {
            #ifdef DEBUG
               DPrintF("ScanDir:","File \"%s\" does not match filter \"%s\"", info->Name, Self->Filter);
            #endif
            continue;
         }

         if (info->Flags & RDF_FILE) {
            if (ContentMatch(Self, Buffer, Self->Content, Self->DataBuffer) IS FALSE) {
               #ifdef DEBUG
                  DPrintF("ScanDir:","Content of file %s is not a match.", info->Name);
               #endif
               continue;
            }
         }

         if (Self->Operation IS FOP_MOVE) {
            if (dest_created IS FALSE) {
               dest_created = TRUE;
               if (IsDirectory(Self->Dest)) MakeDirectory(Self->Dest, info->Permissions | PERMIT_USER);
            }
         }

         Buffer[len] = 0;

         FileMatched(Self, Buffer, info->Name, output, info);

         if (Self->Response IS RSP_CANCEL) Self->Stop = TRUE;

         if (Self->Stop IS TRUE) break;
      }

      Buffer[len] = 0;
      CloseDirectory(info);
   }

   if (Self->Stop IS TRUE) {
      #ifdef DEBUG
      DPrintF("ScanDirectory:","Stopping search.");
      #endif
      return;
   }

   if (OpenDirectory(Buffer, RDF_DIRECTORY|RDF_QUALIFY, &info) IS ERR_Okay) {

      insert = -1;
      if (Self->Dest[0]) {
         for (insert=0; Self->Dest[insert]; insert++);
         if ((Self->Dest[insert-1] != '/') AND (Self->Dest[insert-1] != '\\') AND
             (Self->Dest[insert-1] != ':')) {
            insert = -1;
         }
      }

      while (ScanDirectory(info) IS ERR_Okay) {
         count++;
         if (info->Flags & RDF_LINK) continue; 
         
         ProcessMessages(NULL, NULL);

         if (root IS TRUE) {
            for (k=0; info->Name[k]; k++) Buffer[k] = info->Name[k];
            Buffer[k] = 0;
         }
         else {
            for (k=0; info->Name[k]; k++) Buffer[len+k] = info->Name[k];
            Buffer[len+k] = 0;
         }

         if (insert != -1) {
            StrCopy(info->Name, Self->Dest+insert, sizeof(Self->Dest) - insert);
         }

         ScanLocation(Self, Buffer, output);
         if (Self->Stop IS TRUE) break;

         if (insert != -1) Self->Dest[insert] = 0;
      }
      CloseDirectory(info);
   }
   #ifdef DEBUG
   else DPrintF("ScanDirectory()","No folders in %s", Buffer);
   #endif

   Buffer[len] = 0;

   if ((!count) AND ((Self->Operation IS FOP_COPY) OR (Self->Operation IS FOP_MOVE))) {
      if (IsDirectory(Self->Dest)) {
        
        BYTE save;
         for (len=0; Self->Dest[len]; len++);
         save = Self->Dest[len-1];
         Self->Dest[len-1] = 0;

        //DPrintF("ScanDirectory:","Empty dir \"%s\" TO \"%s\"", Buffer, Self->Dest);

         if (Self->Operation IS FOP_COPY) error = CopyLocation(Buffer, Self->Dest);
         else error = MoveLocation(Buffer, Self->Dest);

         Self->Dest[len-1] = save;

         if (error != ERR_Okay) {
            DPrintF("ScanDirectory:","Error %d returned.", error);
            Self->Stop = TRUE;
            Self->Response = RSP_CANCEL;
            UserError(Self, Buffer, error);
            return;
         }
      }

      ProcessMessages(NULL, NULL); 
   }
   else {
      
      if ((Self->Operation IS FOP_DELETE) AND (!Self->Filter[0]) AND (!Self->Content[0])) {
         DeleteFile(Buffer);
      }
      else if ((Self->Operation IS FOP_MOVE) AND (!Self->Filter[0]) AND (!Self->Content[0])) {
         DeleteFile(Buffer);
      }

      if (!count) ProcessMessages(NULL, NULL); 
   }
}

static ERROR FileCopy(struct FindFiles *Self, STRING Location, STRING File)
{
   UBYTE dest[300];
   LONG type;
   ERROR error;
   WORD i;

   if (!Self->Dest[0]) return(ERR_Okay);

   i = StrCopy(Self->Dest, dest, sizeof(dest)-1);

   if ((dest[i-1] IS '/') OR (dest[i-1] IS '\\') OR (dest[i-1] IS ':')) {
      i += StrCopy(File, dest+i, sizeof(dest)-i);
   }

   if ((Self->ConfirmScript) AND (Self->Response != RSP_YESALL)) {
      if ((AnalyseLocation(dest, &type) IS ERR_Okay) AND ((type IS LOC_FILE) OR (type IS LOC_DIRECTORY))) {
         UserConfirmation(Self, Location, dest);
      }
   }

   if ((Self->Response != RSP_YES) AND (Self->Response != RSP_YESALL)) {
      DPrintF("FindFiles:","Skipping file %s, response %d", Location, Self->Response);
      return(ERR_Okay);
   }

   error = CopyLocation(Location, dest);

   if (error) {
      Self->Stop = TRUE;
      Self->Response = RSP_CANCEL;
      UserError(Self, Location, error);
   }

   return(ERR_Okay);
}

static ERROR FileDelete(struct FindFiles *Self, STRING Location)
{
   ERROR error;

   if ((Self->Response IS RSP_CANCEL) OR (Self->Stop IS TRUE)) return(ERR_Okay);

   error = DeleteFile(Location);

   if (error) UserError(Self, Location, error);

   return(ERR_Okay);
}

static ERROR FileMove(struct FindFiles *Self, STRING Location, STRING File)
{
   UBYTE dest[300];
   LONG type;
   ERROR error;
   WORD i;

   DPrintF("FileMove()","%s, File: %s", Location, File);

   if (!Self->Dest[0]) return(ERR_Okay);

   i = StrCopy(Self->Dest, dest, sizeof(dest)-1);

   if ((dest[i-1] IS '/') OR (dest[i-1] IS '\\') OR (dest[i-1] IS ':')) {
      i += StrCopy(File, dest+i, sizeof(dest)-i);
   }

   if ((Self->ConfirmScript) AND (Self->Response != RSP_YESALL)) {
      if ((AnalyseLocation(dest, &type) IS ERR_Okay) AND ((type IS LOC_FILE) OR (type IS LOC_DIRECTORY))) {
         UserConfirmation(Self, Location, dest);
      }
   }

   if ((Self->Response != RSP_YES) AND (Self->Response != RSP_YESALL)) {
      DPrintF("FindFiles:","Skipping file %s, response %d", Location, Self->Response);
      return(ERR_Okay);
   }

   error = MoveLocation(Location, dest);

   if (error) {
      Self->Stop = TRUE;
      Self->Response = RSP_CANCEL;
      UserError(Self, Location, error);
   }

   return(ERR_Okay);
}

static void UserConfirmation(struct FindFiles *Self, STRING SrcFile, STRING DestFile)
{
   OBJECTPTR script;

   if (Self->Response IS RSP_YESALL) return;

   if (!Self->ConfirmScript) {
      Self->Response = RSP_YES;
      return;
   }

   Self->Response = RSP_CANCEL;
   if (CreateObject(ID_SCRIPT, NF_CHILD, &script, NULL,
         FID_Location|TSTRING,   Self->ConfirmScript,
         FID_SrcFile|TUNLISTED,  SrcFile,
         FID_DestFile|TUNLISTED, DestFile,
         TAGEND) IS ERR_Okay) {
      acActivate(script);
      acFree(script);
   }
}

static void UserError(struct FindFiles *Self, STRING Location, ERROR ErrorCode)
{
   OBJECTPTR script;

   if (!Self->ErrorScript) return;

   if (CreateObject(ID_SCRIPT, NF_CHILD, &script, NULL,
         FID_Location|TSTRING, Self->ErrorScript,
         FID_File|TUNLISTED,   Location,
         TAGEND) IS ERR_Okay) {
      acActivate(script);
      acFree(script);
   }
}

I know that this is going to take up a bit of space and time but I mean if I can implement this easier the way I want to then so much the better.  It would be easier for someone like yourself to use too, if you were to type "wget http://url/package" "gunzip package" "cd dir" "./configure" "make" "make clean" "make install" "package", compared to "search package install run" using natural language commands that you expect to be there.  That's the hope anyway, but as you can see this just finds files on your local system, and doesn't do any of the stuff that I wanted it to, I did mainly lift it from gnu find but i've got another load of dirs under the same command dir 1 is for wget, 1 is for findfiles (the file I sent you), 1 is for nlp code so that find/search are accepted as the actual commands in bash instead of all of the above, etc etc so now I'm going to do it right and send that to gnu.  Any docs you can point me in the direction of?  


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

From grafik.list at redshift-software.com  Wed Jul  6 05:04:15 2005
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Tue, 05 Jul 2005 22:04:15 -0500
Subject: [C++-sig] using libtool with boost.python
In-Reply-To: <da0vua$fbn$1@sea.gmane.org>
References: <da0vua$fbn$1@sea.gmane.org>
Message-ID: <42CB4A2F.6010004@redshift-software.com>

Dirgesh Patel wrote:
> if i want to use libtool to compile and link all of my files in the JAMFILE
> with boost.python...how can i do so, here is what my Jamfile looks like
> currently.
> 
> extension MaskUtil
> :  # sources
>    MaskUtil.cpp
> 
>   # requirements and dependencies for Boost.Python extensions
>   <template>@boost/libs/python/build/extension
>   ;
> 
> # Declare a test for the extension module
> boost-python-runtest test2
>     : # extension modules to use
>     <pyd>MaskUtil ;

First bear with me I'm fairly ignorant as to libtool specifics, other 
than it's yet another wrapper shell script around compilers and linkers.

AFAICT your question is:

How to make Boost.Build, this is the Boost tool component that knows how 
to call the compiler, use the "libtool" executable instead of calling 
gcc directly?

The start of an answer:

The documentation at: http://www.boost.org/tools/build/v1/gcc-tools.html 
mentions the way to override what to use when invoking gcc. It has two 
variables you specify "GXX" and "GCC" to correspond when compiling a C++ 
source file, and C source file respectively. For example you could 
invoke bjam as:

     bjam -sTOOLS=gcc "-sGXX=libtool g++"

"GXX" is used by Boost.Build to both compile and link ELF objects, so 
any time a file is compiled or a shared library is linked it's going to 
call it. Now I don't know all that much about how libtool does things 
but if it doesn't understand the that using the "-c" option in GCC makes 
it compile instead of link the above will not work. If libtool requires 
additional options than those given to GCC you have two choices: a) 
write a wrappers script around libtool that figures out the correct 
options based on the GCC command line, or b) write a new Boost.Build 
toolset that specifically supports libtool.

Such a libtool toolset might start like so:

===gcc-libtool-tools.jam===
extends-toolset gcc ;

actions gcc-Link-action bind NEEDLIBS NEEDIMPS
{
   libtool ... g++ ...
}

actions gcc-Cc-action
{
   libtool ... gcc ...
}

actions gcc-C++-action
{
   libtool ... g++ ...
}

actions updated together piecemeal gcc-Archive-action
{
   libtool ... ar ...
}
===gcc-libtool-tools.jam===

Basically you would be creating a toolset that mostly behaves like the 
current gcc toolset, the functionality of which you get from the 
"extends-toolset" invocation above, but overriding the four commands 
used to do whatever libtool requires you to do.

I'm not sure how much I can explain without knowing how much you are 
willing to do, and learn, when it comes to Boost.Build. And for that 
matter why you want to use libtool at all, given that you are using 
Boost.Build.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org



From grafik.list at redshift-software.com  Wed Jul  6 05:07:54 2005
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Tue, 05 Jul 2005 22:07:54 -0500
Subject: [C++-sig] Linking to ".la" file in Linux with JAMFILE
In-Reply-To: <d9v9om$dki$1@sea.gmane.org>
References: <d9v9om$dki$1@sea.gmane.org>
Message-ID: <42CB4B0A.8050704@redshift-software.com>

Dirgesh Patel wrote:
> I am using BOOST in Linux with C++ and have sucessfully created my .cpp
> file.
> 
> but now i want to take that cpp file and link it with a ".la" file that has
> been created
> from other sources. is there a way in the JamFile i can tell the "bjam"
> compiler to
> LINK the .cpp file with the .la file when done.
> 
> please advice

Se my other post for a partial answer.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org



From grafik.list at redshift-software.com  Wed Jul  6 05:26:13 2005
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Tue, 05 Jul 2005 22:26:13 -0500
Subject: [C++-sig] linking with a ".a" file with boost.python
In-Reply-To: <da0v31$ceo$1@sea.gmane.org>
References: <da0v31$ceo$1@sea.gmane.org>
Message-ID: <42CB4F55.50601@redshift-software.com>

Dirgesh Patel wrote:
> i also have a choice of linking with a ".a" file or a ".so" file...how can i
> link with those kinds of file in my Jamfile?
> 
> please advice

Ok those are easier to deal with... To link to "external" libraries, and 
by external I mean something not built within the Boost.Build tool, you 
need to tell Boost.Build two things: a) how to find the external 
library, and b) the name of the external library.

For (a) you can specify any number of paths to search for the library by 
adding "<library-path>/some/path" feature to the requirements section of 
the target. And what all those terms means is described here:

http://www.boost.org/tools/build/v1/build_system.htm#main_targets

Altering the example at: 
http://www.boost.org/tools/build/v1/example/lib_use/Jamfile slightly it 
could be like so:

exe simple
     :
         # SOURCES
         simple.cpp
     :
         # REQUIREMENTS
         <threading>multi
         <library-path>/usr/local
         <library-path>./.libs
     :
         # DEFAULT BUILDS
     ;

And to go along with that you also need to tell it (b) the name of the 
library to link to by adding a "<find-library>somelib" again to the 
requirements section. To continue the same example:

exe simple
     :
         # SOURCES
         simple.cpp
     :
         # REQUIREMENTS
         <threading>multi
         <library-path>/usr/local
         <library-path>./.libs
         <find-library>somelib
     :
         # DEFAULT BUILDS
     ;

In the above case the type of library, .a vs .so, is determined by the 
linker.

Alternatively you can do both (a) and (b) in one if you know the 
complete path to the library. In this case you can add a 
"<library-file>./.libs/libsomelib.so" instead:

exe simple
     :
         # SOURCES
         simple.cpp
     :
         # REQUIREMENTS
         <threading>multi
         <library-file>./.libs/libsomelib.so
     :
         # DEFAULT BUILDS
     ;

The complete set of features you can use are currently only documented 
in the source code at:

http://www.boost.org/tools/build/v1/features.jam

HTH.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org



From jkankiewicz at advpubtech.com  Wed Jul  6 18:33:01 2005
From: jkankiewicz at advpubtech.com (Jason Kankiewicz)
Date: Wed, 06 Jul 2005 09:33:01 -0700
Subject: [C++-sig] c + python interchangable?
In-Reply-To: <588965E5.0665FDA2.48B2A67E@netscape.net>
References: <588965E5.0665FDA2.48B2A67E@netscape.net>
Message-ID: <dah14k$ivv$1@sea.gmane.org>

danny280279 at netscape.net wrote:
> So what your saying is (code here:)
> 
> #define DEBUG
> 
> #include 
> #include 
> #include 
> 
> are static links to code comapred to 
> 
> def debug
> 
> import
> import
> import
> 
> because to me they seem the same, or am i just being stupid?
There's a huge difference between the two. In C, all external linkage 
(except for shared libraries) is established at the time the program is 
compiled into an executable binary form. In Python, all external linkage 
is established at the time that the program is run.

The "#include" directive is, in fact, causing the preprocessor to 
substitute it with the contents of the entire file that it's specifying. 
The contents of header files are typically contained within a
#ifndef A_UNIQUE_LABEL\n#define A_UNIQUE_LABEL\n...#endif\n block in 
order to prevent them from being inserted multiple times because of 
redundant "#include" directives. Your C program would have to be 
re-compiled for any subsequent changes to an included header to have any 
effect on it because a compiled program, except for any shared libraries 
  that it links to, is completely self-contained.

Python's "import" statement, on the other hand, dynamically loads a 
module which must be present in a directory specified within Python's 
path environment variable. If an imported module is modified and then 
re-imported its changes will have an effect on your program. Your Python 
program is not self-contained; any scripts and/or extensions that it 
imports must be distributed along with it.

> if that's the case then are there any docs on hybrid programming, because then i could implement all of it in hybrid python/c.
I see hybrid programming as an iterative process.
1) Write your entire program in Python because you'll get a working 
product together faster than if you wrote it in C or C++ both in terms 
of initial implementation and debugging.
2) If the program is too slow, use Python's profiling tools to identify 
the part of your program that is running the slowest.
3) Move the slowest function or method into its own module and add an 
"import" statement to the module where it used to reside so that it will 
still be visible there. If it's a method it'll have to be declared as a 
standalone function in the external module so also add an assignment 
statement to its former class' implementation module that binds it to 
the class as a method.
4) Here comes the hybrid part: re-implement the "hot spot" module as a 
Python extension. Because it will be compiled directly to machine code 
instead of being interpreted, the re-implementated code should run a lot 
faster than the original.
5) Repeat steps 2-4 until the program is fast enough.

I recommend that you use C++ instead of C because it is more similar to 
Python and it will therefore be easier for you to translate Python code 
into C++ than it would be for you to translate it into C. C++ has 
std::vector which approximates Python's list, std::map which 
approximates Python's dictionary, std::string which approximates 
Python's string, etc. C just has the array. Python's extension API is 
for C only but the Boost.Python library, which this very mailing list is 
all about, allows you to use C++ for writing Python extensions instead.
It's a fantastic piece of work.

> I know that this is going to take up a bit of space and time but I mean if I can implement this easier the way I want to then so much the better.  It would be easier for someone like yourself to use too, if you were to type "wget http://url/package" "gunzip package" "cd dir" "./configure" "make" "make clean" "make install" "package", compared to "search package install run" using natural language commands that you expect to be there.  That's the hope anyway, but as you can see this just finds files on your local system, and doesn't do any of the stuff that I wanted it to, I did mainly lift it from gnu find but i've got another load of dirs under the same command dir 1 is for wget, 1 is for findfiles (the file I sent you), 1 is for nlp code so that find/search are accepted as the actual commands in bash instead of all of the above, etc etc so now I'm going to do it right and send that to 
>  gnu.  Any docs you can point me in the direction of?  
For an introduction to hybrid programming with Boost.Python read this 
article http://www.boost-consulting.com/writing/bpl.html.



From dave at boost-consulting.com  Thu Jul  7 04:22:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 06 Jul 2005 22:22:45 -0400
Subject: [C++-sig] GCC version compatibility
Message-ID: <u8y0jz762.fsf@boost-consulting.com>

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


Recently people testing Boost.Python with GCC on Linux have reported
that the extensions being tested have to be compiled with exactly the
same version of GCC as the Python they're being loaded into, or they
get mysterious crashes.

That doesn't correspond to my past experience; it has always been true
that, as long as the compiler used to build Python and the one used to
build the extension have compatible 'C' ABIs, we've been okay.  Yes,
if you were going to pass types like FILE* across the Python/C API,
then you additionally need to be sure that the two compilers are using
the same 'C' library.  That said, none of the Boost.Python tests do
that.

I'm wondering if there has been a well-known recent change either in Python
or GCC that would account for these new reports.  Any relevant
information would be appreciated.

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


From s_sourceforge at nedprod.com  Thu Jul  7 15:15:38 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 07 Jul 2005 14:15:38 +0100
Subject: [C++-sig] GCC version compatibility
In-Reply-To: <u8y0jz762.fsf@boost-consulting.com>
Message-ID: <42CD390A.29937.D6F93@localhost>

On 6 Jul 2005 at 22:22, David Abrahams wrote:

> I'm wondering if there has been a well-known recent change either in
> Python or GCC that would account for these new reports.  Any relevant
> information would be appreciated.

If you use -fvisibility=hidden and don't mark thrown types as always 
visible, you get fatal application exits should that exception cross 
a shared object boundary. I'm pretty sure that's not a problem for 
BPL though.

Cheers,
Niall





From djowel at gmail.com  Thu Jul  7 16:07:03 2005
From: djowel at gmail.com (Joel de Guzman)
Date: Thu, 07 Jul 2005 22:07:03 +0800
Subject: [C++-sig] Wrapping std::vector<AbstractClass*>
In-Reply-To: <42CA70F7.9020903@boost-consulting.com>
References: <42C584A7.3030607@pecm.nl> <42CA70F7.9020903@boost-consulting.com>
Message-ID: <42CD3707.2010700@boost-consulting.com>

Joel de Guzman wrote:
> Paul Melis wrote:
> 
>>Hello,
>>I have an abstract class and a std::vector<> of pointers to this class. 
>>A routine in my c++ code fills a vector with objects of classes derived 
>>from the abstract class.
>>I'd like to iterate over the vector in python and use each of the items 
>>in the vector depending on the type of derived class.
>>
> 
> [...]
> 
>>I suspect that boost.python will wrap the return value of returnList() 
>>as a pointer to Abstract, without the possibility at runtime to look at 
>>the actual object type. Is this something I would have to code by hand? 
>>For example, by making a routine that takes a pointer to Abstract and 
>>uses dynamic_cast<> to test which of the concrete classes the object 
>>actually is from?
> 
> 
> Pardon the delay. It's been a while. I'm investigating the problem
> in more detail. I'll get back to you on this, ok?

Ok... Replying to myself...

I committed a fix. The problem occurs when lst[0] tries to return
a copy and there's no way to provide a call policy. So, the
behavior now is for wrapped containers of pointers to always
return by internal reference.

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


From markus.schoepflin at comsoft.de  Thu Jul  7 17:50:26 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Thu, 07 Jul 2005 17:50:26 +0200
Subject: [C++-sig] [boost.python] Exposing contants at the module level
Message-ID: <dajj03$gag$1@sea.gmane.org>

I need to do something similar like the errno module from python, namely 
exponse a bunch of integer constants at the module level.

I had a look at how the errno module does the job, and basically, it does 
it like this:

PyMODINIT_FUNC
initerrno(void)
{
	PyObject *m, *d;
	m = Py_InitModule3("errno", errno_methods, errno__doc__);
	d = PyModule_GetDict(m);
	...
	repeat for each name and code:
		PyObject *u = PyString_FromString(name);
		PyObject *v = PyInt_FromLong((long) code);
		PyDict_SetItem(d, u, v);
	...
}

Is there some way in boost.python to get at the module dictionary, or at 
the module object?

Or is there a better way to achieve this in boost.python?

TIA, Markus



From rwgk at yahoo.com  Thu Jul  7 18:24:37 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 7 Jul 2005 09:24:37 -0700 (PDT)
Subject: [C++-sig] [boost.python] Exposing contants at the module level
In-Reply-To: <dajj03$gag$1@sea.gmane.org>
Message-ID: <20050707162437.36335.qmail@web31509.mail.mud.yahoo.com>

--- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:
> I need to do something similar like the errno module from python, namely 
> exponse a bunch of integer constants at the module level.

I think you are looking for

boost::python::scope().attr("name") = code;



		
____________________________________________________
Sell on Yahoo! Auctions ? no fees. Bid on great items.  
http://auctions.yahoo.com/


From nickm at sitius.com  Thu Jul  7 19:08:06 2005
From: nickm at sitius.com (Nikolay Mladenov)
Date: Thu, 07 Jul 2005 13:08:06 -0400
Subject: [C++-sig] Letting exception through
Message-ID: <42CD6176.97E43DD5@sitius.com>

Hi,

I have a python interpreter running as a plugin to at third party
software,
and I use boost.python to expose some functionality of this software to
python.

I am having the following problem. At times they (the third party
software) 
throw std::exception which they apparently expect to catch, because when 
boost.python catches it on the boundary between python and  C++, the
software 
crashes. 

So my question is is there a way to have certain exceptions flow through
the 
boost.python boundary?

Thanks,

Nikolay



From dirgesh.patel at hp.com  Thu Jul  7 20:35:38 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Thu, 7 Jul 2005 11:35:38 -0700
Subject: [C++-sig] creating ".so" module with LIBTOOL
Message-ID: <dajsls$hpv$1@sea.gmane.org>

I was wondering if anyone knows about this...

i am trying to make a ".so" library from a .cpp file i created so i can
import it in python.

i am using boost but was told i can use LIBTOOL to create the  ".so"
library...

is this true?...does anyone have any examples?





From dave at boost-consulting.com  Thu Jul  7 21:09:38 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 15:09:38 -0400
Subject: [C++-sig] Letting exception through
References: <42CD6176.97E43DD5@sitius.com>
Message-ID: <u1x6atoul.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> Hi,
>
> I have a python interpreter running as a plugin to at third party
> software, and I use boost.python to expose some functionality of
> this software to python.

Let's see:

  3rd-party app                           <----------+
    calls Python interpreter in your plugin          |
      which calls a Boost.Python extension module ---+
         (which calls back into the 3rd party app to expose its
          functionality)

??
         
> I am having the following problem. At times they (the third party
> software) throw std::exception which they apparently expect to
> catch,


> because when boost.python catches it on the boundary between
> python and C++, the software crashes.

You conclude that they expect to catch the exception because the
application crashes at the moment that Boost.Python catches the
exception?  That conclusion seems highly suspect.  In general any
intermediate library should be able to catch an exception and rethrow
it without the 3rd party app being any the wiser, so if the crash is
really happening at the catch point, something else is wrong.

> So my question is is there a way to have certain exceptions flow
> through the boost.python boundary?

Maybe you could do it by registering a special exception
translator... 

... but don't do it; it would be very, very wrong!  It will 
certainly crash Python if a C++ exception propagates into it.  What
you need to do, if my picture is right, is translate the exception
into something that Python can propagate (e.g. by serializing it), and
then ressurect the exception (e.g. by deserializing it) in your
plugin, and throw that.

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



From dave at boost-consulting.com  Thu Jul  7 21:11:07 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 15:11:07 -0400
Subject: [C++-sig] creating ".so" module with LIBTOOL
References: <dajsls$hpv$1@sea.gmane.org>
Message-ID: <uvf3msa7o.fsf@boost-consulting.com>

"Dirgesh Patel" <dirgesh.patel at hp.com> writes:

> I was wondering if anyone knows about this...
>
> i am trying to make a ".so" library from a .cpp file i created so i can
> import it in python.
>
> i am using boost but was told i can use LIBTOOL to create the  ".so"
> library...
>
> is this true?...does anyone have any examples?

Did you miss Rene's reply to your earlier post?
http://mail.python.org/pipermail/c++-sig/2005-July/009171.html

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



From nickm at sitius.com  Thu Jul  7 22:27:31 2005
From: nickm at sitius.com (Nikolay Mladenov)
Date: Thu, 07 Jul 2005 16:27:31 -0400
Subject: [C++-sig] Letting exception through
References: <42CD6176.97E43DD5@sitius.com> <u1x6atoul.fsf@boost-consulting.com>
Message-ID: <42CD9033.148438B8@sitius.com>

Hi David,

David Abrahams wrote:
> 
> Nikolay Mladenov <nickm at sitius.com> writes:
> 
> > Hi,
> >
> > I have a python interpreter running as a plugin to at third party
> > software, and I use boost.python to expose some functionality of
> > this software to python.
> 
> Let's see:
> 
>   3rd-party app                           <----------+
>     calls Python interpreter in your plugin          |
>       which calls a Boost.Python extension module ---+
>          (which calls back into the 3rd party app to expose its
>           functionality)
> 
> ??

That is in principle correct, but because the exposed functionality
includes
UI, there are some additional callbacks crossing the boundary back and
forth.


> 
> > I am having the following problem. At times they (the third party
> > software) throw std::exception which they apparently expect to
> > catch,
> 
> > because when boost.python catches it on the boundary between
> > python and C++, the software crashes.
> 
> You conclude that they expect to catch the exception because the
> application crashes at the moment that Boost.Python catches the
> exception?  That conclusion seems highly suspect.  In general any
> intermediate library should be able to catch an exception and rethrow
> it without the 3rd party app being any the wiser, so if the crash is
> really happening at the catch point, something else is wrong.



I changed the errors.cpp / handle_exception catch block like that:
	..............
           PyErr_SetString(PyExc_IndexError, x.what());
	}
        catch(const std::exception& x)
        {
		bool rethrow = false;
		if(rethrow)
			throw;
                PyErr_SetString(PyExc_RuntimeError, x.what());
        }
        catch(...)
        {
             PyErr_SetString(PyExc_RuntimeError, "unidentifiable C++
exception");
        ...........

and from the debugger changed the rethrow to true when this particular
exception was handled.
They didn't crash. And it seemed the exception went through python
without a problem?

> 
> > So my question is is there a way to have certain exceptions flow
> > through the boost.python boundary?
> 
> Maybe you could do it by registering a special exception
> translator...

I have one big problem - the only thing I now about this exception is,
that it is derived from
std::exception, so translator does not seem like an option. 


> 
> ... but don't do it; it would be very, very wrong!  It will
> certainly crash Python if a C++ exception propagates into it.  What
> you need to do, if my picture is right, is translate the exception
> into something that Python can propagate (e.g. by serializing it), and
> then ressurect the exception (e.g. by deserializing it) in your
> plugin, and throw that.
> 


And I have the same problem here. How can I serialize it without knowing
it ?


Isn't it always appropriate to rethrow exceptions not coming from your
code?
And following this isn't it better to leave the std::exception out of
the 
handle_exception( one can always register translator) ?




Thanks and regards,

Nikolay



From martin at v.loewis.de  Fri Jul  8 00:01:56 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Jul 2005 00:01:56 +0200
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <u8y0jz762.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com>
Message-ID: <42CDA654.2080106@v.loewis.de>

David Abrahams wrote:
> I'm wondering if there has been a well-known recent change either in Python
> or GCC that would account for these new reports.  Any relevant
> information would be appreciated.

So what about the theory that it may be that different versions of
libstdc++ get linked? Python is linked with g++ if configure thinks
this is necessary, and the g++ used to link the extension might be
different.

I'd like to see a backtrace of one such mysterious crash.

Regards,
Martin


From dave at boost-consulting.com  Fri Jul  8 00:27:46 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 18:27:46 -0400
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <42CDA654.2080106@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Fri, 08 Jul 2005 00:01:56 +0200")
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
Message-ID: <uu0j6p7z1.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>> I'm wondering if there has been a well-known recent change either in Python
>> or GCC that would account for these new reports.  Any relevant
>> information would be appreciated.
>
> So what about the theory that it may be that different versions of
> libstdc++ get linked? 

That's been confirmed.

> Python is linked with g++ if configure thinks this is necessary

Right.  The question is, when should configure "think it's necessary?"

> and the g++ used to link the extension might be different.
>
> I'd like to see a backtrace of one such mysterious crash.

I don't have it, but ldd confirms that the crash happens when the
versions of libstdc++ in python and in the extension module are
different.  A C++ exception thrown from the extension module into the
Boost.Python library to which it is linked (both compiled and linked
with the same g++) without passing through any of Python's code (of
course) will cause a crash unless Python is using the same libstdc++
as everything else, or unless Python isn't linked with libstdc++.

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


From dave at boost-consulting.com  Fri Jul  8 00:37:51 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 18:37:51 -0400
Subject: [C++-sig] Letting exception through
References: <42CD6176.97E43DD5@sitius.com>
	<u1x6atoul.fsf@boost-consulting.com> <42CD9033.148438B8@sitius.com>
Message-ID: <ull4ip7i8.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> I changed the errors.cpp / handle_exception catch block like that:
> 	..............
>            PyErr_SetString(PyExc_IndexError, x.what());
> 	}
>         catch(const std::exception& x)
>         {
> 		bool rethrow = false;
> 		if(rethrow)
> 			throw;
>                 PyErr_SetString(PyExc_RuntimeError, x.what());
>         }
>         catch(...)
>         {
>              PyErr_SetString(PyExc_RuntimeError, "unidentifiable C++
> exception");
>         ...........
>
> and from the debugger changed the rethrow to true when this particular
> exception was handled.
> They didn't crash. And it seemed the exception went through python
> without a problem?

That is completely unreliable.  'C' code isn't written with the
expectation that functions might fail to complete because of an
exception.  Invariants may be broken temporarily and never restored.
Furthermore the 'C' runtime isn't -- in general -- built to deal with
C++ exceptions and the C++ runtime isn't -- in general -- built to
deal with C stack frames.

If you feel the need to follow that road, be my guest, but I can't
support it.

>> ... but don't do it; it would be very, very wrong!  It will
>> certainly crash Python if a C++ exception propagates into it.  What
>> you need to do, if my picture is right, is translate the exception
>> into something that Python can propagate (e.g. by serializing it), and
>> then ressurect the exception (e.g. by deserializing it) in your
>> plugin, and throw that.
>> 
>
> And I have the same problem here. How can I serialize it without knowing
> it ?

Yep, you have a problem.
>
> Isn't it always appropriate to rethrow exceptions not coming from
> your code?  

No.  And especially not if it means they propagate into code that is
not prepared to deal with exceptions.

> And following this isn't it better to leave the std::exception out
> of the handle_exception( one can always register translator) ?

No.  We'd still need catch(...) to stop the exceptions from
propagating into 'C' code.

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



From paul at pecm.nl  Fri Jul  8 00:40:16 2005
From: paul at pecm.nl (Paul Melis)
Date: Fri, 08 Jul 2005 00:40:16 +0200
Subject: [C++-sig] Wrapping std::vector<AbstractClass*>
In-Reply-To: <42CD3707.2010700@boost-consulting.com>
References: <42C584A7.3030607@pecm.nl> <42CA70F7.9020903@boost-consulting.com>
	<42CD3707.2010700@boost-consulting.com>
Message-ID: <42CDAF50.4080507@pecm.nl>



Joel de Guzman wrote:

>Joel de Guzman wrote:
>  
>
>>Paul Melis wrote:
>>
>>    
>>
>>>Hello,
>>>I have an abstract class and a std::vector<> of pointers to this class. 
>>>A routine in my c++ code fills a vector with objects of classes derived 
>>>      
>>>
>>>from the abstract class.
>>    
>>
>>>I'd like to iterate over the vector in python and use each of the items 
>>>in the vector depending on the type of derived class.
>>>
>>>      
>>>
>>[...]
>>
>>    
>>
>>>I suspect that boost.python will wrap the return value of returnList() 
>>>as a pointer to Abstract, without the possibility at runtime to look at 
>>>the actual object type. Is this something I would have to code by hand? 
>>>For example, by making a routine that takes a pointer to Abstract and 
>>>uses dynamic_cast<> to test which of the concrete classes the object 
>>>actually is from?
>>>      
>>>
>>Pardon the delay. It's been a while. I'm investigating the problem
>>in more detail. I'll get back to you on this, ok?
>>    
>>
>
>Ok... Replying to myself...
>
>I committed a fix. The problem occurs when lst[0] tries to return
>a copy and there's no way to provide a call policy. So, the
>behavior now is for wrapped containers of pointers to always
>return by internal reference.
>
>Cheers,
>  
>
Hi,
I'll check after I get back from holidays (in a month ;-))

Thanks,
Paul


From cludwig at cdc.informatik.tu-darmstadt.de  Fri Jul  8 09:28:08 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Fri, 8 Jul 2005 09:28:08 +0200
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <uu0j6p7z1.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
Message-ID: <20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>

On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote:
> "Martin v. L?wis" <martin at v.loewis.de> writes:
> 
> > David Abrahams wrote:
> >> I'm wondering if there has been a well-known recent change either in Python
> >> or GCC that would account for these new reports.  Any relevant
> >> information would be appreciated.
[...]
> > Python is linked with g++ if configure thinks this is necessary
> 
> Right.  The question is, when should configure "think it's necessary?"

Just to add to the confusion... I encountered the case that configure decided
to use gcc for linking but it should have used g++. (It is Python 
PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with
g++ 3.4.2.)

Background: The description of --with-cxx in the README of the Python 2.4.1
source distribution made me think that I need to configure my Python
installation with --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use
C++ extensions built with this compiler. (That was possibly a misunderstanding
on my part, but Python should build with this option anyway.) 

configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when
linking the python executable due to an unresolved reference to
__gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC
to finish the build of Python.

When I looked into this problem I saw that configure in fact builds a test
executable that included an object file compiled with g++. If the link step
with gcc succeeds then LINKCC is set as above, otherwise CXX is
used. Obviously, on my system this test was successful so configure decided
to link with gcc. However, minimal changes to the source of the test program
caused the link step to fail. It was not obvious to me at all why the latter
source code should cause a dependency on the C++ runtime if the original
code does not. My conclusion was that this test is fragile and should be
skipped. If Python is built with --with-cxx then it should be linked with CXX
as well.

I gather from posts on the Boost mailing lists that you can import
Boost.Python extensions even if Python was configured --without-cxx. (On
ELF based Linux/x86, at least.) That leaves me wondering
 * when is --with-cxx really necessary?
 * what happens if I import extensions built with different g++ versions? Will
   there be a conflict between the different versions of libstdc++ those
   extensions depend on?

Regards

Christoph

-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From markus.schoepflin at comsoft.de  Fri Jul  8 11:31:58 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Fri, 08 Jul 2005 11:31:58 +0200
Subject: [C++-sig] [boost.python] Exposing contants at the module level
In-Reply-To: <20050707162437.36335.qmail@web31509.mail.mud.yahoo.com>
References: <dajj03$gag$1@sea.gmane.org>
	<20050707162437.36335.qmail@web31509.mail.mud.yahoo.com>
Message-ID: <dalh6f$cr7$1@sea.gmane.org>

Ralf W. Grosse-Kunstleve wrote:

> --- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:
> 
>>I need to do something similar like the errno module from python, namely 
>>exponse a bunch of integer constants at the module level.
> 
> 
> I think you are looking for
> 
> boost::python::scope().attr("name") = code;

Yep, that's exactly what I need. Playing around with boost.pp, I got:

#include <boost/preprocessor/seq/for_each.hpp>
#define DEFINE_CONSTANT(X) scope().attr(#X) = X
#define DEFINE_CONSTANTS_HELPER(R, DATA, X) DEFINE_CONSTANT(X);
#define DEFINE_CONSTANTS(SEQ) \
BOOST_PP_SEQ_FOR_EACH(DEFINE_CONSTANTS_HELPER, , SEQ)

which enables you to write:

DEFINE_CONSTANTS((EPERM)(ENOENT)(ESRCH)(EIO)...)

Maybe someone can make use of it.

Thanks, Markus



From nickm at sitius.com  Fri Jul  8 16:38:55 2005
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 08 Jul 2005 10:38:55 -0400
Subject: [C++-sig] Letting exception through
References: <42CD6176.97E43DD5@sitius.com>
	<u1x6atoul.fsf@boost-consulting.com> <42CD9033.148438B8@sitius.com>
	<ull4ip7i8.fsf@boost-consulting.com>
Message-ID: <42CE8FFF.17AE47C3@sitius.com>



David Abrahams wrote:
> 
> Nikolay Mladenov <nickm at sitius.com> writes:
> 
> > I changed the errors.cpp / handle_exception catch block like that:
> >       ..............
> >            PyErr_SetString(PyExc_IndexError, x.what());
> >       }
> >         catch(const std::exception& x)
> >         {
> >               bool rethrow = false;
> >               if(rethrow)
> >                       throw;
> >                 PyErr_SetString(PyExc_RuntimeError, x.what());
> >         }
> >         catch(...)
> >         {
> >              PyErr_SetString(PyExc_RuntimeError, "unidentifiable C++
> > exception");
> >         ...........
> >
> > and from the debugger changed the rethrow to true when this particular
> > exception was handled.
> > They didn't crash. And it seemed the exception went through python
> > without a problem?
> 
> That is completely unreliable.  'C' code isn't written with the
> expectation that functions might fail to complete because of an
> exception.  Invariants may be broken temporarily and never restored.
> Furthermore the 'C' runtime isn't -- in general -- built to deal with
> C++ exceptions and the C++ runtime isn't -- in general -- built to
> deal with C stack frames.
> 


I get it.

Thanks,


Nikolay



From dave at boost-consulting.com  Fri Jul  8 17:15:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 11:15:57 -0400
Subject: [C++-sig] [Python-Dev] GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <u8y0hl45u.fsf@boost-consulting.com>


[Christoph, please keep the python-dev list in the loop here, at least
until they get annoyed and decide we're off-topic.  I think this is
crucial to the way they package and deliver Python]

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote:
>> "Martin v. L?wis" <martin at v.loewis.de> writes:
>> 
>> > David Abrahams wrote:
>> >> I'm wondering if there has been a well-known recent change either in Python
>> >> or GCC that would account for these new reports.  Any relevant
>> >> information would be appreciated.
> [...]
>> > Python is linked with g++ if configure thinks this is necessary
>> 
>> Right.  The question is, when should configure "think it's necessary?"
>
> Just to add to the confusion... I encountered the case that configure decided
> to use gcc for linking but it should have used g++. (It is Python 
> PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with
> g++ 3.4.2.)
>
> Background: The description of --with-cxx in the README of the
> Python 2.4.1 source distribution made me think that I need to
> configure my Python installation with
> --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++
> extensions built with this compiler. (That was possibly a
> misunderstanding on my part, 

AFAICT, yes.

> but Python should build with this option anyway.)
>
> configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when
> linking the python executable due to an unresolved reference to
> __gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC
> to finish the build of Python.
>
> When I looked into this problem I saw that configure in fact builds a test
> executable that included an object file compiled with g++. If the link step
> with gcc succeeds then LINKCC is set as above, otherwise CXX is
> used. Obviously, on my system this test was successful so configure decided
> to link with gcc. However, minimal changes to the source of the test program
> caused the link step to fail. It was not obvious to me at all why the latter
> source code should cause a dependency on the C++ runtime if the original
> code does not. My conclusion was that this test is fragile and should be
> skipped. 

Sounds like it.  I have never understood what the test was really
checking for since the moment it was first described to me, FWIW.

> If Python is built with --with-cxx then it should be linked with CXX
> as well.

U betcha.

> I gather from posts on the Boost mailing lists that you can import
> Boost.Python extensions even if Python was configured
> --without-cxx. 

Yes, all the tests are passing that way.

> (On ELF based Linux/x86, at least.) That leaves me wondering
>
>  * when is --with-cxx really necessary?

I think it's plausible that if you set sys.dlopenflags to share
symbols it *might* end up being necessary, but IIRC Ralf does use
sys.dlopenflags with a standard build of Python (no
--with-cxx)... right, Ralf?

>  * what happens if I import extensions built with different g++ versions? Will
>    there be a conflict between the different versions of libstdc++ those
>    extensions depend on?

Not unless you set sys.dlopenflags to share symbols.  

It's conceivable that they might conflict through their shared use of
libboost_python.so, but I think you have to accept that an extension
module and the libboost_python.so it is linked with have to be built
with compatible ABIs anyway.  So in that case you may need to make
sure each group of extensions built with a given ABI use their own
libboost_python.so (or just link statically to libboost_python.a if
you don't need cross-module conversions).

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



From dave at boost-consulting.com  Fri Jul  8 17:17:09 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 11:17:09 -0400
Subject: [C++-sig] [boost.python] Exposing contants at the module level
References: <dajj03$gag$1@sea.gmane.org>
	<20050707162437.36335.qmail@web31509.mail.mud.yahoo.com>
	<dalh6f$cr7$1@sea.gmane.org>
Message-ID: <u3bqpl43u.fsf@boost-consulting.com>

Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

> Ralf W. Grosse-Kunstleve wrote:
>
>> --- Markus Sch?pflin <markus.schoepflin at comsoft.de> wrote:
>> 
>>>I need to do something similar like the errno module from python, namely 
>>>exponse a bunch of integer constants at the module level.
>> 
>> 
>> I think you are looking for
>> 
>> boost::python::scope().attr("name") = code;
>
> Yep, that's exactly what I need. Playing around with boost.pp, I got:
>
> #include <boost/preprocessor/seq/for_each.hpp>
> #define DEFINE_CONSTANT(X) scope().attr(#X) = X
> #define DEFINE_CONSTANTS_HELPER(R, DATA, X) DEFINE_CONSTANT(X);
> #define DEFINE_CONSTANTS(SEQ) \
> BOOST_PP_SEQ_FOR_EACH(DEFINE_CONSTANTS_HELPER, , SEQ)
                                                
Empty macro arguments aren't legal in C++.  Just pass a dummy token
like '~'.

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



From cimca at canberra.edu.au  Thu Jul  7 14:39:06 2005
From: cimca at canberra.edu.au (cimca)
Date: Thu, 7 Jul 2005 22:39:06 +1000
Subject: [C++-sig] CFP: IEEE in cooperated International Conference on
	Computational Intelligence for Modelling, Control and Automation
Message-ID: <088D96D6E422174EAABF7B27D94F3EE70102106D@hera.ucstaff.win.canberra.edu.au>

CFP: IEEE in cooperated International Conference on Computational Intelligence for Modelling, Control and Automation

                           CALL FOR PAPERS

 

International Conference on Computational Intelligence for Modelling,

                    Control and Automation

              28 - 30 November 2005 Vienna, Austria

                         http://www.ise.canberra.edu.au/conferences/cimca05/

 

In co-operation with:

IEEE Computational Intelligence Society

Conference Proceedings will be published as books by IEEE in USA

 

Sponsored by:

European Society for Fuzzy Logic and Technology - EUFLAT

International Association for Fuzzy Set in Management and Economy - SIGEF 

Japan Society for Fuzzy Theory and Intelligent Informatics - SOFT

Taiwan Fuzzy Systems Association - TFSA

World Wide Web Business Intelligence - W3BI

Hungarian Fuzzy Association - HFA 

University of Canberra

 

                             Jointly with

International Conference on Intelligent Agents, Web Technologies

                         and Internet Commerce

             http://www.ise.canberra.edu.au/conferences/iawtic05/                          

 

Honorary Chair:

Lotfi A. Zadeh, University of California, USA

Stephen Grossberg, Boston University, USA

 

 

The international conference on computational intelligence for modelling, control and automation will be held in Vienna, 

Austria on 28 to 30 November 2005. The conference provides a medium for the exchange of ideas between theoreticians and 

practitioners to address the important issues in computational intelligence, modelling, control and automation. 

The conference will consist of both plenary sessions and contributory sessions, focusing on theory, implementation 

and applications of computational intelligence techniques to modelling, control and automation. For contributory 

sessions, papers (4 pages or more) are being solicited. Several well-known keynote speakers will address the

 conference. 

 

Conference Proceedings will be published as books by IEEE (The Institute of Electrical and Electronic Engineering) in USA 

and will be index world wide. All papers will be peer reviewed by at least two reviewers. 

Topics of the conference include, but are not limited to, the following areas:

 

Modern and Advanced Control Strategies:

Neural Networks Control,

Fuzzy Logic Control,

Genetic Algorithms and Evolutionary Control,

Model-Predictive Control,

Adaptive and Optimal Control,

Intelligent Control Systems,

Robotics and Automation,

Fault Diagnosis,

Intelligent agents,

Industrial Automations

 

Hybrid Systems:

Fuzzy Evolutionary Systems,

Fuzzy Expert Systems,

Fuzzy Neural Systems,

Neural Genetic Systems,

Neural-Fuzzy-Genetic Systems,

Hybrid Systems for Optimisation

 

Data Analysis, Prediction and Model Identification:

Signal Processing,

Prediction and Time Series Analysis,

System Identification,

Data Fusion and Mining,

Knowledge Discovery,

Intelligent Information Systems,

Image Processing, and Image Understanding,

Parallel Computing applications in Identification & Control,

Pattern Recognition,

Clustering and Classification

 

Decision Making and Information Retrieval:

Case-Based Reasoning,

Decision Analysis,

Intelligent Databases & Information Retrieval,

Dynamic Systems Modelling,

Decision Support Systems,

Multi-criteria Decision Making,

Qualitative and Approximate-Reasoning

 

Paper Submission

Papers will be selected based on their originality, significance, correctness, and clarity of presentation. Papers (4 pages or more) should be submitted to the following e-mail or the following address: 

CIMCA'2005 Secretariat

School of Information Sciences and Engineering

University of Canberra, Canberra, 2616, ACT, Australia

E-mail: cimca at canberra.edu.au

 

Electronic submission of papers (either by E-mail or through conference website) is preferred. Draft papers should present original work, which has not been published or being reviewed for other conferences.

 

Important Dates

31 August 2005 Submission of draft papers

30 September 2005 Notification of acceptance

21 October 2005 Deadline for camera-ready copies of accepted papers

28-30 November 2005 Conference sessions

 

Special Sessions and Tutorials

Special sessions and tutorials will be organised at the conference. The conference is calling for special sessions and tutorial proposals. All special session proposals should be sent to the conference chair (by email to: masoud.mohammadian at canberra.edu.au) on or before 5th of August 2005. CIMCA'05 will also include a special poster session devoted to recent work and work-in-progress. Abstracts are solicited for this session. Abstracts (3 pages limit) may be submitted up to 30 days before the conference date.

 

Visits and social events

Sightseeing visits will be arranged for the delegates and guests. A separate program will be arranged for companions during the conference.

 

Further Information

For further information either contact cimca at ise.canberra.edu.au or see the conference homepage at: http://www.ise.canberra.edu.au/conferences/cimca05/default.htm

 

Organising Committee Chair:

Masoud Mohammadian, University of

Canberra, Australia

 

International Program Committee:

H. Adeli, The Ohio State University, USA

W. Pedrycz, University of Manitoba, Canada

A. Agah, The University of Kansas, USA

T. Fukuda, Nagoya University, Japan

J. Bezdek, University of West Florida, USA

R. C. Eberhart, Purdue University, USA

F. Herrera, University of Granada, Spain

T. Furuhashi, Nagoya University, Japan

A. Agah, The University of Kansas, US

E. Andr?, Universit?t Augsburg, Germany

A. Kandel, University of South Florida, USA

J. P. Bigus, IBM T. J. Watson Research Center, USA

J. Liu, Hong Kong Baptist University, Hong Kong

A. Namatame, National Defense Academy, Japan

K. Sycara, Carnegie Mellon University, USA

B. Kosko, University of Southern California, USA

T. Baeck, Informatic Centrum Dortmund, Germany

K. Hirota, Tokyo Institute of Technology, Japan

E. Oja, Helsinki University of Technology, Finland

H. R. Berenji, NASA Ames Research Center, USA

H. Liljenstrom, Royal Institute of Technology, Sweden

A. Bulsari, AB Nonlinear Solutions OY, Finland

J. Fernandez de Ca?ete, University of Malaga, Spain

W. Duch, Nicholas Copernicus University, Poland

E. Tulunay, Middle East Technical University, Turkey

C. Kuroda, Tokyo Institute of Technology, Japan

T. Yamakawa, Kyushu Institute of Technology, Japan

J. Liu, Hong Kong Baptist University, Hong Kong

A. Namatame, National Defense Academy, Japan

A. Aamodt, Norwegian University of Science & Technology, Norway

 

International Liaison:

Canada and USA Liaison:

Robert John, De Montfort University, UK

Nasser Jazdi, Institut f?r Automatisierungs- und

Softwaretechnik, Germany

 

Europe Liaison:

Dr. Eng. Djamel Khadraoui, Centre de Recherche Public, Luxembourg 

Frank Zimmer, SES ASTRA, Luxembourg

 

Asia Liaison:

Renzo Gobbin, University of Canberra, Australia

R. Amin Sarker, ADFA, Australia

 

Local Arrangements and

Public Relation:

Zohreh Pahlavani, AVIP, Austria

C Meier, Australia

 

Publicity:

C. Meier, Australia

Zohreh Pahlavani, AVIP, Austria

 

Publication:

Masoud Mohammadian, Australia

 

In cooperation with:

IEEE Computational Intelligence Society

Conference Proceedings will be published as books by IEEE in USA

University of Canberra, (Masoud Mohammadian)

Universidad Carlos III de Madrid, (Jos?-Luis Fern?ndez-Villaca?as Mart?n)

University of Guelph, (Simon X. Yang)

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

From rwgk at yahoo.com  Fri Jul  8 23:40:00 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 8 Jul 2005 14:40:00 -0700 (PDT)
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <u8y0hl45u.fsf@boost-consulting.com>
Message-ID: <20050708214000.29643.qmail@web31514.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Yes, all the tests are passing that way.
> 
> > (On ELF based Linux/x86, at least.) That leaves me wondering
> >
> >  * when is --with-cxx really necessary?
> 
> I think it's plausible that if you set sys.dlopenflags to share
> symbols it *might* end up being necessary, but IIRC Ralf does use
> sys.dlopenflags with a standard build of Python (no
> --with-cxx)... right, Ralf?

Yes, I am using sys.setdlopenflags like this:

  if (sys.platform == "linux2"):
    sys.setdlopenflags(0x100|0x2)

/usr/include/bits/dlfcn.h:#define RTLD_GLOBAL      0x00100
/usr/include/bits/dlfcn.h:#define RTLD_NOW 0x00002

Note that the default Python 2.4.1 installation links python with g++. I've
never had any problems with this configuration under any Linux version, at
least: Redhat 7.3, 8.0, 9.0, WS3, SuSE 9.2, Fedora Core 3, and some other
versions I am not sure about.

Specifically for this posting I've installed Python 2.4.1 --without-cxx. All of
our 50 Boost.Python extensions still work without a problem.

Cheers,
        Ralf



		
____________________________________________________
Sell on Yahoo! Auctions ? no fees. Bid on great items.  
http://auctions.yahoo.com/


From martin at v.loewis.de  Sat Jul  9 00:08:08 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 09 Jul 2005 00:08:08 +0200
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <u8y0hl45u.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com>	<42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com>
Message-ID: <42CEF948.3010908@v.loewis.de>

David Abrahams wrote:
>>When I looked into this problem I saw that configure in fact builds a test
>>executable that included an object file compiled with g++. If the link step
>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>used. Obviously, on my system this test was successful so configure decided
>>to link with gcc. However, minimal changes to the source of the test program
>>caused the link step to fail. It was not obvious to me at all why the latter
>>source code should cause a dependency on the C++ runtime if the original
>>code does not. My conclusion was that this test is fragile and should be
>>skipped. 
> 
> 
> Sounds like it.  I have never understood what the test was really
> checking for since the moment it was first described to me, FWIW.

I'll describe it once more: *If* a program is compiled with the C++
compiler, is it *then* possible to still link it with the C compiler?
This is the question this test tries to answer.

>>If Python is built with --with-cxx then it should be linked with CXX
>>as well.
> 
> 
> U betcha.

Wrong. The test was introduced in response to complaints that Python
unnecessarily links with libstdc++ on some Linux systems. On these
Linux systems, it was well possible to build main() with a C++ compiler,
and still link the entire thing with gcc. Since main() doesn't use
any libstdc++ functionality, and since collect2/__main isn't used,
one would indeed expect that linking with CXX is not necessary.

>>(On ELF based Linux/x86, at least.) That leaves me wondering
>>
>> * when is --with-cxx really necessary?
> 
> 
> I think it's plausible that if you set sys.dlopenflags

This has no relationship at all. --with-cxx is much older than
sys.dlopenflags. It is used on systems where main() must be a
C++ program for C++ extension modules to work (e.g. some Linux
systems).

Regards,
Martin


From dave at boost-consulting.com  Sat Jul  9 03:38:44 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 21:38:44 -0400
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <42CEF948.3010908@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sat, 09 Jul 2005 00:08:08 +0200")
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
Message-ID: <u3bqohi6z.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>>When I looked into this problem I saw that configure in fact builds a test
>>>executable that included an object file compiled with g++. If the link step
>>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>>used. Obviously, on my system this test was successful so configure decided
>>>to link with gcc. However, minimal changes to the source of the test program
>>>caused the link step to fail. It was not obvious to me at all why the latter
>>>source code should cause a dependency on the C++ runtime if the original
>>>code does not. My conclusion was that this test is fragile and should be
>>>skipped. 
>> 
>> 
>> Sounds like it.  I have never understood what the test was really
>> checking for since the moment it was first described to me, FWIW.
>
> I'll describe it once more: *If* a program is compiled with the C++
> compiler, is it *then* possible to still link it with the C compiler?
> This is the question this test tries to answer.

Okay, I understand that.  What I have never understood is why that
should be an appropriate thing to test for the Python executable.
There's no reason to compile any of Python with a C++ compiler.

>>>If Python is built with --with-cxx then it should be linked with CXX
>>>as well.
>> 
>> U betcha.
>
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. 

Apparently it still does.

> On these Linux systems, it was well possible to build main() with a
> C++ compiler

Nobody would need to build Python's main() with a C++ compiler, if
you'd just comment out the 'extern "C"'.

> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.

It isn't.

>>>(On ELF based Linux/x86, at least.) That leaves me wondering
>>>
>>> * when is --with-cxx really necessary?
>> 
>> 
>> I think it's plausible that if you set sys.dlopenflags
>
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).

I have tested Boost.Python and C++ extension modules on a wide variety
of Linux systems, and have seen this phenomenon.  Everyone who is
testing it on Linux is finding that if they build Python
--without-cxx, everything works.  And, yes, the mechanisms at the very
*core* of Boost.Python rely on static initializers being run properly,
so if there were anything wrong with that mechanism the tests would be
breaking left and right.

I think either the ELF Linux loader changed substantially since 1995,
or whoever introduced this test was just confused.

C++ extension modules get their static initializers run when they are
loaded by dlopen (or, strictly speaking, sometime between then and the
time their code begins to execute) which happens long after main or
__main are invoked.  The executable doesn't know about these extension
modules until they are loaded, and when it loads them it can't get its
hooks into anything other than the initmodulename entry point.  The
executable does not trigger the static initializers; the dynamic
loader does.  Therefore, it doesn't matter whether the executable is
linked with the C++ runtime.  An appropriate C++ runtime is linked to
the extension module and that is what gets invoked when the module is
loaded.

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


From cludwig at cdc.informatik.tu-darmstadt.de  Sat Jul  9 12:20:11 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sat, 9 Jul 2005 12:20:11 +0200
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <42CEF948.3010908@v.loewis.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
Message-ID: <20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>

On Sat, Jul 09, 2005 at 12:08:08AM +0200, "Martin v. L?wis" wrote:
> David Abrahams wrote:
> >>When I looked into this problem I saw that configure in fact builds a test
> >>executable that included an object file compiled with g++. If the link step
> >>with gcc succeeds then LINKCC is set as above, otherwise CXX is
> >>used. Obviously, on my system this test was successful so configure decided
> >>to link with gcc. However, minimal changes to the source of the test program
> >>caused the link step to fail. It was not obvious to me at all why the latter
> >>source code should cause a dependency on the C++ runtime if the original
> >>code does not. My conclusion was that this test is fragile and should be
> >>skipped. 
> > 
> > 
> > Sounds like it.  I have never understood what the test was really
> > checking for since the moment it was first described to me, FWIW.
> 
> I'll describe it once more: *If* a program is compiled with the C++
> compiler, is it *then* possible to still link it with the C compiler?
> This is the question this test tries to answer.

The keyword here is "tries" - my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:

configure writes the following conftest.cc on the disk (whitespaces added for
better readability):

  cludwig at lap200:~/tmp/python-config> cat conftest.cc
  void foo();

  int main() {
    foo();
  }

  void foo() {
  } 

This TU is compiled with the C++ compiler and then linked with the C compiler:

  cludwig at lap200:~/tmp/python-config> g++ -o conftest.o -c conftest.cc
  cludwig at lap200:~/tmp/python-config> gcc -o conftest conftest.o

Note that there is *no* reference to any symbol in another TU. The compiler
can detect that foo() won't throw any exceptions, that there is no need for RTTI
and whatever else the C++ runtime provides. Consequently, the object file
produced by g++ does not contain any reference to symbols in libstdc++.

However, python.c does reference a function from other TUs, in particular
extern "C" int Py_Main(int, char**). The following test shows that in this
situation you must link with g++:

  cludwig at lap200:~/tmp/python-config> cat conftest_a.cc
  extern "C" void foo();

  int main() {
    foo();
  }
  cludwig at lap200:~/tmp/python-config> cat conftest_b.c
  void foo() {
  }
  cludwig at lap200:~/tmp/python-config> g++ -o conftest_a.o -c conftest_a.cc
  cludwig at lap200:~/tmp/python-config> gcc -o conftest_b.o -c conftest_b.c
  cludwig at lap200:~/tmp/python-config> gcc -o conftest conftest_a.o conftest_b.o
  conftest_a.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
  collect2: ld gab 1 als Ende-Status zur?ck

(I ran this test with g++ 3.3.1, 3.4.2, and 4.0.0 with identical results.) The
reason is, I guess, that even though foo() is delared to have "C" linkage, it
still can throw a C++ exception. 

> >>If Python is built with --with-cxx then it should be linked with CXX
> >>as well.
> > 
> > 
> > U betcha.
> 
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. On these
> Linux systems, it was well possible to build main() with a C++ compiler,
> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.

Of course, if you insist on this "dependency optimization" then you can try to
fix Python's configure.in by using the second test above. But I would still
not trust it to cover all configurations on all platforms supported by
Python. 

> >>(On ELF based Linux/x86, at least.) That leaves me wondering
> >>
> >> * when is --with-cxx really necessary?
> > 
> > 
> > I think it's plausible that if you set sys.dlopenflags
> 
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).

Can you provide a concrete examples of such systems? The explanation of
--with-cxx in the README mentions a.out. Are there other systems?

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From shahrouz at student.chalmers.se  Sun Jul 10 02:14:19 2005
From: shahrouz at student.chalmers.se (Shahrouz Zolfaghari)
Date: Sun, 10 Jul 2005 02:14:19 +0200 (CEST)
Subject: [C++-sig] Wrapping already constructed c++ objects.
Message-ID: <2743.212.181.39.25.1120954459.squirrel@webmail.chalmers.se>

Hello,

I would like to know if it is possible to use boost.python to wrap an
already created c++ object and make it available though the embedded
python interpreter?

So the instance "foo" the class "Foo" should be exposed to the python
interpreter as a module.

Here is a little example with the wrapping manually done, using Python/C api:

class Foo
{
public:
        void method() { ... }
};

Foo foo;

PyObject * foo_method_wrap(PyObject *self,PyObject * argv)
{
        foo.method();
        return Py_None;
}

static PyMethodDef foo_methods[] = {
    {"method",  foo_method_wrap, METH_VARARGS, "Call foo.method()."},
    {NULL, NULL, 0, NULL}
};

int main()
{
        Py_Initialize();
        Py_InitModule("foo",foo_methods);
        PyRun_SimpleString( "import foo\n"
                            "foo.method()\n");
        Py_Finalize();
}

Thanks,
Eracce



From martin at v.loewis.de  Sun Jul 10 09:21:23 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 09:21:23 +0200
Subject: [C++-sig] [Python-Dev] GCC version compatibility
In-Reply-To: <u3bqohi6z.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com>	<42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de> <u3bqohi6z.fsf@boost-consulting.com>
Message-ID: <42D0CC73.90407@v.loewis.de>

David Abrahams wrote:
>>I'll describe it once more: *If* a program is compiled with the C++
>>compiler, is it *then* possible to still link it with the C compiler?
>>This is the question this test tries to answer.
> 
> 
> Okay, I understand that.  What I have never understood is why that
> should be an appropriate thing to test for the Python executable.
> There's no reason to compile any of Python with a C++ compiler.

I hope you understand now: it is necessary if you want to link
C++ extension modules into a Python interpreter (statically, not
dynamically).

>>Wrong. The test was introduced in response to complaints that Python
>>unnecessarily links with libstdc++ on some Linux systems. 
> 
> 
> Apparently it still does.

Not "still", but "again", since recent changes in gcc.

>>On these Linux systems, it was well possible to build main() with a
>>C++ compiler
> 
> 
> Nobody would need to build Python's main() with a C++ compiler, if
> you'd just comment out the 'extern "C"'.

Wrong. People that statically link C++ extensions modules on systems
where the C++ compiler requires main to be compiled as C++ need
to do such a thing. One such compiler is gcc on systems where the
binary format does not support .init sections.

>>and still link the entire thing with gcc. Since main() doesn't use
>>any libstdc++ functionality, and since collect2/__main isn't used,
>>one would indeed expect that linking with CXX is not necessary.
> 
> 
> It isn't.

Hmmm. It is. Try for yourself. You get an unresolved gxx_personality_v0.

> I have tested Boost.Python and C++ extension modules on a wide variety
> of Linux systems, and have seen this phenomenon.

Did you try on Linux systems released 1994? That don't use ELF as
the binary format?

> I think either the ELF Linux loader changed substantially since 1995,
> or whoever introduced this test was just confused.

No. The ELF loader was *introduced* since 1995. Dynamic loading was
not available before.

Regards,
Martin


From martin at v.loewis.de  Sun Jul 10 09:45:25 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 09:45:25 +0200
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de>	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D0D215.9000708@v.loewis.de>

Christoph Ludwig wrote:
>>I'll describe it once more: *If* a program is compiled with the C++
>>compiler, is it *then* possible to still link it with the C compiler?
>>This is the question this test tries to answer.
> 
> 
> The keyword here is "tries"

Any such test would only "try": to really determine whether this is
necessary for all possible programs, one would have to test all possible
programs. Since there is an infinite number of programs, this test could
take a while.

The original test, on the original system, would cause __main to be
undefined, and then decide to use C++. For a long time, on systems
that don't use collect2, the test *correctly* determined that linking
with g++ was not necessary.

It is only recent changes to g++ that break the test, namely the
introduction of this __gxx_personality_v0 thing.


> - my bug report #1189330 exihibts that the test
> fails to do its job. And looking at the test that's certainly no surprise:

However, it *is* a surprise that your modified test fixes the problem.

> Note that there is *no* reference to any symbol in another TU. The compiler
> can detect that foo() won't throw any exceptions, that there is no need for RTTI
> and whatever else the C++ runtime provides. Consequently, the object file
> produced by g++ does not contain any reference to symbols in libstdc++.

You are assuming implementation details here. I have seen
implementations of C++ (eg. g++ with collect2) where the test determines
that linking with C++ is necessary (because __main was undefined), as
well as systems where the test decides *correctly* that linking with
C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
compiler introduces the C++ runtime if some C function may throw an
exception is a very specific detail of this C++ compiler.

> Of course, if you insist on this "dependency optimization" then you can try to
> fix Python's configure.in by using the second test above. But I would still
> not trust it to cover all configurations on all platforms supported by
> Python. 

Of couse not. This is just autoconf: it does not allow magical porting
to all possible future operating systems. Instead, from time to time,
explicit porting activity is necessary. This is not just about this
specific detail, but about many other details. Each new operation
system, library, or compiler version might break the build process.

> Can you provide a concrete examples of such systems? The explanation of
> --with-cxx in the README mentions a.out. Are there other systems?

I'm not sure. I think HP-UX (with OMF, and aCC) might have required
the same code, as may have SysVR3 (with COFF).

Regards,
Martin


From mw8329 at yahoo.com.au  Sun Jul 10 14:40:23 2005
From: mw8329 at yahoo.com.au (Martin Wille)
Date: Sun, 10 Jul 2005 14:40:23 +0200
Subject: [C++-sig] [Boost.Python][documentation] _ vs __
Message-ID: <42D11737.60202@yahoo.com.au>

Hi,

the tutorial uses '_' at several places where '__' should be used
(e.g. on
libs/python/doc/tutorial/doc/html/python/techniques.html#python.creating_packages
_init_.py instead of __init__.py)

Perhaps, this is a Quickbook problem. The HTML code reads:
<span class="underline">_init</span>_.py



Regards,
m

Send instant messages to your online friends http://au.messenger.yahoo.com 


From cludwig at cdc.informatik.tu-darmstadt.de  Sun Jul 10 14:54:59 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sun, 10 Jul 2005 14:54:59 +0200
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <42D0D215.9000708@v.loewis.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
Message-ID: <20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 10, 2005 at 09:45:25AM +0200, "Martin v. L?wis" wrote:
> Christoph Ludwig wrote:
> >>I'll describe it once more: *If* a program is compiled with the C++
> >>compiler, is it *then* possible to still link it with the C compiler?
> >>This is the question this test tries to answer.
> > 
> > 
> > The keyword here is "tries"
> 
> Any such test would only "try": to really determine whether this is
> necessary for all possible programs, one would have to test all possible
> programs. Since there is an infinite number of programs, this test could
> take a while.

Sure. You cannot write a test that gives the correct result for all platforms
you can think of, covering every compiler / linker quirk. I never claimed that
is possible.

My point is: The test implemented in the 2.4.1 configure script gives a wrong
result if your platform happens to be x86 Linux with ELF binaries and 
g++ 4.0. 

> The original test, on the original system, would cause __main to be
> undefined, and then decide to use C++. For a long time, on systems
> that don't use collect2, the test *correctly* determined that linking
> with g++ was not necessary.
> 
> It is only recent changes to g++ that break the test, namely the
> introduction of this __gxx_personality_v0 thing.

The test broke due to a change in GCC 4.0, but the "__gxx_personality_v0
thing" was introduced long before. It is merely a symptom. I ran the tests
with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:

  GCC version       1 TU        2 TUs
    3.3.1            g++         g++
    3.4.2            g++         g++
    4.0.0            gcc         g++

(1 TU: test with one translation unit, as in Python 2.4.1.
 2 TUs: test with two translation units, as in my last posting.
 g++ / gcc: test indicates linking the executable requires g++ / gcc,
 respectively.)

With GCC 3.3.1 and 3.4.2, linking of the executable conftest in the 1 TU test
fails because of an unresolved symbol __gxx_personality_v0. Therefore, python
is linked with g++.

The change that makes GCC 4.0.0 break the 1 TU test is that the compiler
apparently does a better job eliminating unreachable code. In the 1 TU test,
it recognizes __gxx_personality_v0 (or the code that refers to this symbol) is
unreachable and removes it. It seems there are no other symbols left that
depend on libstdc++ so suddenly conftest can be linked with gcc.

> > - my bug report #1189330 exihibts that the test
> > fails to do its job. And looking at the test that's certainly no surprise:
> 
> However, it *is* a surprise that your modified test fixes the problem.
> 
> > Note that there is *no* reference to any symbol in another TU. The compiler
> > can detect that foo() won't throw any exceptions, that there is no need for RTTI
> > and whatever else the C++ runtime provides. Consequently, the object file
> > produced by g++ does not contain any reference to symbols in libstdc++.
> 
> You are assuming implementation details here. I have seen
> implementations of C++ (eg. g++ with collect2) where the test determines
> that linking with C++ is necessary (because __main was undefined), as
> well as systems where the test decides *correctly* that linking with
> C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
> compiler introduces the C++ runtime if some C function may throw an
> exception is a very specific detail of this C++ compiler.

I am not aware of any rule that makes the following program ill-formed:

  // in a.cc:
  extern "C" void foo();

  int main() {
    foo();
  }

  // in b.cc
  extern "C" void foo() {
    throw 1;
  }

Provided the compiler does not do optimizations across translation units, it
has no way to determine in a.cc whether foo() is really a C function (i.e.,
compiled by a C compiler) or a C++ function with "C" linkage. I think a
conforming C++ compiler has to provide for the case that foo() might throw. It
was a very specific detail of gcc 2.x if it failed to do so. (A venial
omission, I admit.)


But I digress. It's not that important for our discussion whether a C++
compiler must / should / is allowed to add exception handling code to the
call of an extern "C" function. The point is that some do *unless* they see
the function definition. I contend the test involving two TUs matches more
closely the situation with ccpython.cc than the current test.

I do not claim the 2 TUs test will cover all possible scenarios. I am not even
sure this decision should be left to an automated test. Because if the test
breaks for some reason then the user is left with a linker error that is
time-consuming to track down.

> > Of course, if you insist on this "dependency optimization" then you can try to
> > fix Python's configure.in by using the second test above. But I would still
> > not trust it to cover all configurations on all platforms supported by
> > Python. 
> 
> Of couse not. This is just autoconf: it does not allow magical porting
> to all possible future operating systems. Instead, from time to time,
> explicit porting activity is necessary. This is not just about this
> specific detail, but about many other details. Each new operation
> system, library, or compiler version might break the build process.

Instead of having yet another test in configure.in that may break on a new
platform and that needs maintenance wouldn't it be better to assume that
--with-cxx implies linking with the C++ compiler and telling users how to
override this assumption? Would it cause so much inconvenience to users
provided the explanation of --with-cxx in the README would be modified?

I think of an explanation along the lines of:

--with-cxx=<compiler>: If you plan to use C++ extension modules, then on some
        platform you need to compile python's main() function with the C++
        compiler. With this option, make will use <compiler> to compile main()
        *and* to link the python executable. It is likely that the resulting
        executable depends on the C++ runtime library of <compiler>.

        Note there are platforms that do not require you to build Python with
        a C++ compiler in order to use C++ extension modules. E.g., x86 Linux
        with ELF shared binaries and GCC 3.x, 4.x is such a platform. We
        recommend that you configure Python --without-cxx on those platforms
        to avoid unnecessary dependencies.

        If you need to compile main() with <compiler>, but your platform does
        not require that you also link the python executable with <compiler> 
        (e.g., <example platform>), then set LINKCC='$(PURIFY) $(CC)' prior to
        calling make. Then the python executable will not depend on the C++
        runtime library of <compiler>.


BTW, I'd also change the short explanation output by `configure --help'.
Something like:

  AC_HELP_STRING(--with-cxx=<compiler>, 
                 use <compiler> to compile and link main())

In Python 2.4.1, the help message says "enable C++ support". That made me use
this option even though it turned out it is not necessary on my platform.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From dave at boost-consulting.com  Sun Jul 10 15:35:33 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 09:35:33 -0400
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <u64vidbru.fsf@boost-consulting.com>

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> I do not claim the 2 TUs test will cover all possible scenarios. I am not even
> sure this decision should be left to an automated test. Because if the test
> breaks for some reason then the user is left with a linker error that is
> time-consuming to track down.

However, at least by the usual hierarchy of values, the sort of
runtime error that results from the current needless linking with C++
on ELF/Linux is even worse.

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



From rwgk at yahoo.com  Sun Jul 10 16:13:02 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 10 Jul 2005 07:13:02 -0700 (PDT)
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <u64vidbru.fsf@boost-consulting.com>
Message-ID: <20050710141302.73934.qmail@web31507.mail.mud.yahoo.com>

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

> Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:
> 
> > I do not claim the 2 TUs test will cover all possible scenarios. I am not
> even
> > sure this decision should be left to an automated test. Because if the test
> > breaks for some reason then the user is left with a linker error that is
> > time-consuming to track down.
> 
> However, at least by the usual hierarchy of values, the sort of
> runtime error that results from the current needless linking with C++
> on ELF/Linux is even worse.

Indeed. A few months ago the current configure behavior lead to a major loss of
our time, probably a whole week between 4-5 people.
The problem was that a Python compiled under RH 8.0 was used to build and run
new C++ extensions under Fedroa Core 3. Some extensions ran OK, others crashed
without warning after running to a certain point. It was very confusing.
To avoid this situation in the future, we permanently added a test to our setup
scripts, comparing the result of ldd python | grep libstdc++ to the
corresponding output for extension modules.

Cheers,
        Ralf


		
____________________________________________________
Sell on Yahoo! Auctions ? no fees. Bid on great items.  
http://auctions.yahoo.com/


From dave at boost-consulting.com  Sun Jul 10 15:38:35 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 09:38:35 -0400
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <uzmsubx2c.fsf@boost-consulting.com>

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> --with-cxx=<compiler>: If you plan to use C++ extension modules, then on some
>         platform you need to compile python's main() function with the C++
>         compiler. With this option, make will use <compiler> to compile main()
>         *and* to link the python executable. It is likely that the resulting
>         executable depends on the C++ runtime library of <compiler>.
>
>         Note there are platforms that do not require you to build Python with
>         a C++ compiler in order to use C++ extension modules. E.g., x86 Linux
>         with ELF shared binaries and GCC 3.x, 4.x is such a platform. We
>         recommend that you configure Python --without-cxx on those platforms
>         to avoid unnecessary dependencies.

I don't think that's strong enough.  What happens is that dynamically
loaded Python extension modules built with other, ABI-compatible
versions of G++ may *crash*.

>         If you need to compile main() with <compiler>, but your platform does
>         not require that you also link the python executable with <compiler> 
>         (e.g., <example platform>), then set LINKCC='$(PURIFY) $(CC)' prior to
>         calling make. Then the python executable will not depend on the C++
>         runtime library of <compiler>.

Are we sure we have an actual use case for the above?  Doesn't
--without-cxx cover all the actual cases we know about?

> BTW, I'd also change the short explanation output by `configure --help'.
> Something like:
>
>   AC_HELP_STRING(--with-cxx=<compiler>, 
>                  use <compiler> to compile and link main())
>
> In Python 2.4.1, the help message says "enable C++ support". That made me use
> this option even though it turned out it is not necessary on my platform.

Your suggestion is simple and powerful; I like it!

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



From cludwig at cdc.informatik.tu-darmstadt.de  Sun Jul 10 16:49:47 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sun, 10 Jul 2005 16:49:47 +0200
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <u64vidbru.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
Message-ID: <20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 10, 2005 at 09:35:33AM -0400, David Abrahams wrote:
> Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:
> 
> > I do not claim the 2 TUs test will cover all possible scenarios. I am not even
> > sure this decision should be left to an automated test. Because if the test
> > breaks for some reason then the user is left with a linker error that is
> > time-consuming to track down.
> 
> However, at least by the usual hierarchy of values, the sort of
> runtime error that results from the current needless linking with C++
> on ELF/Linux is even worse.

Yes, but on ELF/Linux the default configuration should be --without-cxx
in the first place. If the build instructions make it sufficiently clear that
you should prefer this configuration whenever possible then this should be a
non-issue on platforms like ELF/Linux.

We learned that there are indeed platforms that require --with-cxx. There is
not much we can do for user on platforms that that also require the final
executable to be linked with the C++ compiler. They have to live with the
dependency on the C++ runtime and the likely runtime errors if the import
extension modules built with a different C++ compiler.

What about the platforms that require compilation of main() with a C++
compiler but allow you to link with the C compiler - can you import a C++
extension module built with C++ compiler version X if the main() function of
the Python interpreter was compiled with C++ compiler version Y, X != Y?
If not, then we are back to the runtime error, no matter whether there is a
dependency on the C++ runtime library or not.

So the automated test in configure could spare users runtime errors if they
must configure --with-cxx and if they can link with the C compiler and if the
C++ compiler versions used for building the Python interpreter and the
extension module do not need to coincide. I don't know how large the subset of
platforms is that satisfy these conditions.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From martin at v.loewis.de  Sun Jul 10 19:41:06 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 19:41:06 +0200
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D15DB2.3020300@v.loewis.de>

Christoph Ludwig wrote:
> My point is: The test implemented in the 2.4.1 configure script gives a wrong
> result if your platform happens to be x86 Linux with ELF binaries and 
> g++ 4.0. 

Point well taken.

>>It is only recent changes to g++ that break the test, namely the
>>introduction of this __gxx_personality_v0 thing.
> 
> 
> The test broke due to a change in GCC 4.0, but the "__gxx_personality_v0
> thing" was introduced long before. It is merely a symptom. I ran the tests
> with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:

As I say: it's a recent change (GCC 3.3 *is* recent).

>>You are assuming implementation details here. 
> 
> I am not aware of any rule that makes the following program ill-formed:

And I didn't suggest that such a rules exists. Your proposed
modification to the test program is fine with me.

> But I digress. It's not that important for our discussion whether a C++
> compiler must / should / is allowed to add exception handling code to the
> call of an extern "C" function. The point is that some do *unless* they see
> the function definition. I contend the test involving two TUs matches more
> closely the situation with ccpython.cc than the current test.

Maybe. For Python 2.4, feel free to contribute a more complex test. For
Python 2.5, I would prefer if the entire code around ccpython.cc was
removed.

> Instead of having yet another test in configure.in that may break on a new
> platform and that needs maintenance wouldn't it be better to assume that
> --with-cxx implies linking with the C++ compiler and telling users how to
> override this assumption? Would it cause so much inconvenience to users
> provided the explanation of --with-cxx in the README would be modified?

*If* the configure algorithm is modified, I think I would prefer if the
feature was removed entirely.

> In Python 2.4.1, the help message says "enable C++ support". That made me use
> this option even though it turned out it is not necessary on my platform.

For 2.4.2, things should essentially stay the way they are, except
perhaps for fixing bugs. For 2.5, more radical changes are possible.

Regards,
Martin


From markus.schoepflin at comsoft.de  Mon Jul 11 10:41:51 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Mon, 11 Jul 2005 10:41:51 +0200
Subject: [C++-sig] [boost.python] Exposing contants at the module level
In-Reply-To: <u3bqpl43u.fsf@boost-consulting.com>
References: <dajj03$gag$1@sea.gmane.org>	<20050707162437.36335.qmail@web31509.mail.mud.yahoo.com>	<dalh6f$cr7$1@sea.gmane.org>
	<u3bqpl43u.fsf@boost-consulting.com>
Message-ID: <datbcf$d0j$1@sea.gmane.org>

David Abrahams wrote:

> Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:

>>Yep, that's exactly what I need. Playing around with boost.pp, I got:
>>
>>#include <boost/preprocessor/seq/for_each.hpp>
>>#define DEFINE_CONSTANT(X) scope().attr(#X) = X
>>#define DEFINE_CONSTANTS_HELPER(R, DATA, X) DEFINE_CONSTANT(X);
>>#define DEFINE_CONSTANTS(SEQ) \
>>BOOST_PP_SEQ_FOR_EACH(DEFINE_CONSTANTS_HELPER, , SEQ)

> Empty macro arguments aren't legal in C++.  Just pass a dummy token
> like '~'.

Thanks for the hint.

Markus



From Abdel.Khiati at tourisme.gouv.fr  Mon Jul 11 15:12:06 2005
From: Abdel.Khiati at tourisme.gouv.fr (Abdel.Khiati at tourisme.gouv.fr)
Date: Mon, 11 Jul 2005 15:12:06 +0200
Subject: [C++-sig]  Arnaud PICARD/IMA/DER/EDFGDF/FR est absent
Message-ID: <9DE7A2F71532D4118C3600D0B74D64980132E4F3@dt-mel.dt.ritac.net>

Bonjour,
	Je cherche ? joindre Mr Noceir Slimane , qui ?tait affect? ? la DER
clamart, puis dans une "banlieue lointaine" toujours chez EDF-GDF.
	Merci pour Votre aide.
Abdel Khiati
Conseiller scientifique
abdel.khiati at equipement.gouv.fr


From pierre.barbier at cirad.fr  Mon Jul 11 16:44:26 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 11 Jul 2005 16:44:26 +0200
Subject: [C++-sig] Wrapping already constructed c++ objects.
In-Reply-To: <2743.212.181.39.25.1120954459.squirrel@webmail.chalmers.se>
References: <2743.212.181.39.25.1120954459.squirrel@webmail.chalmers.se>
Message-ID: <42D285CA.1040504@cirad.fr>

Well, what to do depend where and when you want to put your object ^_^

Simplest: if you want to add it to your module at import time !

You just have to use the scope object :

   scope current;

Then, you can add objects in it :

   current.attr("foo") = object(Foo());

(see : http://www.boost.org/libs/python/doc/v2/scope.html for details).

To add the object at runtime, you have to get the __main__ module :

object main_module = object(handle<>(PyImport_AddModule("__main__")));
dict main_namespace = extract<dict>( object( handle<>( PyModule_GetDict(
main_module.ptr()))));

Then, you can add objects directly in the dictionnary of the __main__
module :

   main_namespace["foo"] = object(Foo());

Pierre

Shahrouz Zolfaghari a ?crit :
> Hello,
> 
> I would like to know if it is possible to use boost.python to wrap an
> already created c++ object and make it available though the embedded
> python interpreter?
> 
> So the instance "foo" the class "Foo" should be exposed to the python
> interpreter as a module.
> 
> Here is a little example with the wrapping manually done, using Python/C api:
> 
> class Foo
> {
> public:
>         void method() { ... }
> };
> 
> Foo foo;
> 
> PyObject * foo_method_wrap(PyObject *self,PyObject * argv)
> {
>         foo.method();
>         return Py_None;
> }
> 
> static PyMethodDef foo_methods[] = {
>     {"method",  foo_method_wrap, METH_VARARGS, "Call foo.method()."},
>     {NULL, NULL, 0, NULL}
> };
> 
> int main()
> {
>         Py_Initialize();
>         Py_InitModule("foo",foo_methods);
>         PyRun_SimpleString( "import foo\n"
>                             "foo.method()\n");
>         Py_Finalize();
> }
> 
> Thanks,
> Eracce
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
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 martin at v.loewis.de  Tue Jul 12 01:07:56 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Jul 2005 01:07:56 +0200
Subject: [C++-sig] [Python-Dev]     GCC version compatibility
In-Reply-To: <20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de>	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de>	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>	<42D0D215.9000708@v.loewis.de>	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D2FBCC.2090301@v.loewis.de>

Christoph Ludwig wrote:
> Yes, but on ELF/Linux the default configuration should be --without-cxx
> in the first place. If the build instructions make it sufficiently clear that
> you should prefer this configuration whenever possible then this should be a
> non-issue on platforms like ELF/Linux.

Some users will complain about this. Specifying --without-cxx also
causes configure not to look for a C++ compiler, meaning that distutils
won't know what the C++ compiler is, meaning that it will link extension
modules with the C compiler instead.

Regards,
Martin


From cludwig at cdc.informatik.tu-darmstadt.de  Tue Jul 12 09:47:55 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Tue, 12 Jul 2005 09:47:55 +0200
Subject: [C++-sig] [Python-Dev]     GCC version compatibility
In-Reply-To: <42D2FBCC.2090301@v.loewis.de>
References: <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D2FBCC.2090301@v.loewis.de>
Message-ID: <20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>

On Tue, Jul 12, 2005 at 01:07:56AM +0200, "Martin v. L?wis" wrote:
> Christoph Ludwig wrote:
> > Yes, but on ELF/Linux the default configuration should be --without-cxx
> > in the first place. If the build instructions make it sufficiently clear that
> > you should prefer this configuration whenever possible then this should be a
> > non-issue on platforms like ELF/Linux.
> 
> Some users will complain about this. Specifying --without-cxx also
> causes configure not to look for a C++ compiler, meaning that distutils
> won't know what the C++ compiler is, meaning that it will link extension
> modules with the C compiler instead.

If I understood Dave Abraham's reply somewhere above in this thread correctly
then you can build different C++ extension modules with different C++
compilers on ELF/Linux. (I don't have the time right now to actually try it,
sorry.) There is no need to fix the C++ compiler as soon as python is built.

If distutils builds C++ extensions with the C compiler then I consider this a
bug in distutils because it is unlikely to work. (Unless the compiler can
figure out from the source file suffixes in the compilation step *and* some
info in the object files in the linking step that it is supposed to act like a
C++ compiler. None of the compilers I am familiar with does the latter.)
distutils should rather look for a C++ compiler in the PATH or explicitly ask
the user to specify the command that calls the C++ compiler.

It is different if --with-cxx=<compiler> was used. I agree that in this case
distutils should use <compiler> to build C++ extensions.

(distutils does not behave correctly when building C++ extensions anyway. It
calls the C compiler to compile the C++ source files and passes options that
gcc accepts only in C mode. The compiler version I am using is docile and only
issues warnings. But these warnings are unnecessary and and I would not blame
gcc if the next compiler release refused to compile C++ sources if the command
line contains C specific options. But the distutils mailing list is a better
place to bring this eventually up, I guess.)

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From martin at v.loewis.de  Tue Jul 12 10:19:20 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Jul 2005 10:19:20 +0200
Subject: [C++-sig] [Python-Dev]     GCC version compatibility
In-Reply-To: <20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
References: <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D2FBCC.2090301@v.loewis.de>
	<20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D37D08.8020405@v.loewis.de>

Christoph Ludwig wrote:
> If I understood Dave Abraham's reply somewhere above in this thread correctly
> then you can build different C++ extension modules with different C++
> compilers on ELF/Linux. (I don't have the time right now to actually try it,
> sorry.) There is no need to fix the C++ compiler as soon as python is built.

There is, somewhat: how do you know the name of the C++ compiler?

> If distutils builds C++ extensions with the C compiler then I consider this a
> bug in distutils because it is unlikely to work. (Unless the compiler can
> figure out from the source file suffixes in the compilation step *and* some
> info in the object files in the linking step that it is supposed to act like a
> C++ compiler. None of the compilers I am familiar with does the latter.)
> distutils should rather look for a C++ compiler in the PATH or explicitly ask
> the user to specify the command that calls the C++ compiler.

How should it do that? The logic is quite involved, and currently,
distutils relies on configure to figure it out. If you think this should
be changed, please contribute a patch.

> (distutils does not behave correctly when building C++ extensions anyway. It
> calls the C compiler to compile the C++ source files and passes options that
> gcc accepts only in C mode. The compiler version I am using is docile and only
> issues warnings. But these warnings are unnecessary and and I would not blame
> gcc if the next compiler release refused to compile C++ sources if the command
> line contains C specific options. But the distutils mailing list is a better
> place to bring this eventually up, I guess.)

The best way to "bring this up" is to contribute a patch. "Bringing it
up" in the sense of sending an email message to some mailing list likely
has no effect whatsoever.

Regards,
Martin


From roman.yakovenko at gmail.com  Tue Jul 12 12:46:32 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 12 Jul 2005 13:46:32 +0300
Subject: [C++-sig] [Announce] py++ first public release
Message-ID: <7465b61705071203464a827d2a@mail.gmail.com>

Hi,

I would like to introduce a new code generator for the boost.python
library, called py++ .

py++ is a framework of components for creating a C++ code generator
for boost.python .
Code generation with the py++ framework is a very flexible and highly
configurable process.

You can find an introduction to py++ at: 

1. http://tinyurl.com/bpe2o
2. http://cvs.sourceforge.net/viewcvs.py/*checkout*/pygccxml/source/pyplusplus/docs/py%2B%2B.html

Status:

First of all, this project is under active development. 
py++ can export the following declarations:
    enums ( named and unnamed )
    global variables
    operators ( partially )
    free functions
    member functions
    classes
py++ does not allow the user to override virtual functions from Python
for exported classes, i.e. py++ does not create a wrapper class for
exported classes.

Currently, py++ does not have its own homepage. You can download py++
from http://sourceforge.net/projects/pygccxml.
Please note that pyplusplus-0.0.1 requires pygccxml-0.6.4 .

Installation instructions:
    for pygccxml there is a setup.py file, so installation should be a
simple task.
    for py++ there is no setup yet. py++ is a regular python package,
so place it somewhere and add its location to sys.path .

Ideas, comments, suggestions or help are welcomed.

Roman Yakovenko


From nick.bastin at gmail.com  Tue Jul 12 17:20:39 2005
From: nick.bastin at gmail.com (Nicholas Bastin)
Date: Tue, 12 Jul 2005 11:20:39 -0400
Subject: [C++-sig] [Python-Dev]  GCC version compatibility
In-Reply-To: <20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
References: <uu0j6p7z1.fsf@boost-consulting.com>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D2FBCC.2090301@v.loewis.de>
	<20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <66d0a6e1050712082033087799@mail.gmail.com>

On 7/12/05, Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> wrote:
> If distutils builds C++ extensions with the C compiler then I consider this a
> bug in distutils because it is unlikely to work. (Unless the compiler can
> figure out from the source file suffixes in the compilation step *and* some
> info in the object files in the linking step that it is supposed to act like a
> C++ compiler. None of the compilers I am familiar with does the latter.)
> distutils should rather look for a C++ compiler in the PATH or explicitly ask
> the user to specify the command that calls the C++ compiler.

You practically always have to use --compiler with distutils when
building C++ extensions anyhow, and even then it rarely does what I
would consider 'The Right Thing(tm)'.  The problem is the distutils
core assumption that you want to build extension modules with the same
compiler options that you built Python with, is in many cases the
wrong thing to do for C++ extension modules, even if you built Python
with --with-cxx.  This is even worse on windows where the MSVC
compiler, until very recently, was crap for C++, and you really needed
to use another compiler for C++, but Python was always built using
MSVC (unless you jumped through hoops of fire).

The problem is that this is much more complicated than it seems - you
can't just ask the user for the C++ compiler, you really need to
provide an abstraction layer for all of the compiler and linker flags,
so that a user could specify what those flags are for their compiler
of choice.  Of course, once you've done that, the user might as well
have just written a new Compiler class for distutils, which wouldn't
pay any attention to how Python was built (other than where Python.h
is).

--
Nick


From martin at v.loewis.de  Wed Jul 13 08:10:33 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 13 Jul 2005 08:10:33 +0200
Subject: [C++-sig] [Python-Dev]  GCC version compatibility
In-Reply-To: <66d0a6e1050712082033087799@mail.gmail.com>
References: <uu0j6p7z1.fsf@boost-consulting.com>	
	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de>	
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>	
	<42D0D215.9000708@v.loewis.de>	
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>	
	<u64vidbru.fsf@boost-consulting.com>	
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>	
	<42D2FBCC.2090301@v.loewis.de>	
	<20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
	<66d0a6e1050712082033087799@mail.gmail.com>
Message-ID: <42D4B059.1080303@v.loewis.de>

Nicholas Bastin wrote:
> You practically always have to use --compiler with distutils when
> building C++ extensions anyhow, and even then it rarely does what I
> would consider 'The Right Thing(tm)'.  

I see. In that case, I think something should be done about distutils
as well (assuming somebody volunteers): it would be best if this worked
in the usual cases, with some easy way for the setup.py author to
indicate the preferences.

Regards,
Martin


From cludwig at cdc.informatik.tu-darmstadt.de  Sat Jul 16 12:13:58 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sat, 16 Jul 2005 12:13:58 +0200
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <42D15DB2.3020300@v.loewis.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D15DB2.3020300@v.loewis.de>
Message-ID: <20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 10, 2005 at 07:41:06PM +0200, "Martin v. L?wis" wrote:
> Christoph Ludwig wrote:
> > My point is: The test implemented in the 2.4.1 configure script gives a wrong
> > result if your platform happens to be x86 Linux with ELF binaries and 
> > g++ 4.0. 
[...]
> > But I digress. It's not that important for our discussion whether a C++
> > compiler must / should / is allowed to add exception handling code to the
> > call of an extern "C" function. The point is that some do *unless* they see
> > the function definition. I contend the test involving two TUs matches more
> > closely the situation with ccpython.cc than the current test.
> 
> Maybe. For Python 2.4, feel free to contribute a more complex test. For
> Python 2.5, I would prefer if the entire code around ccpython.cc was
> removed.

I submitted patch #1239112 that implements the test involving two TUs for
Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
that will take some time.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From dave at boost-consulting.com  Sat Jul 16 21:02:50 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 16 Jul 2005 15:02:50 -0400
Subject: [C++-sig] GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D15DB2.3020300@v.loewis.de>
	<20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <ull46bmlh.fsf@boost-consulting.com>

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> I submitted patch #1239112 that implements the test involving two TUs for
> Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
> that will take some time.

Thanks very much for your efforts, Christoph!

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



From anthony at interlink.com.au  Sun Jul 17 08:01:20 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun, 17 Jul 2005 16:01:20 +1000
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42D15DB2.3020300@v.loewis.de>
	<20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <200507171601.23780.anthony@interlink.com.au>

On Saturday 16 July 2005 20:13, Christoph Ludwig wrote:
> I submitted patch #1239112 that implements the test involving two TUs for
> Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
> that will take some time.

I'm only vaguely aware of all of the issues here with linking, but if this
is to be considered for 2.4.2, it needs to be low risk of breaking anything.
2.4.2 is a bugfix release, and I'd hate to have this break other systems that 
work...

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


From cludwig at cdc.informatik.tu-darmstadt.de  Sun Jul 17 12:06:09 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sun, 17 Jul 2005 12:06:09 +0200
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <200507171601.23780.anthony@interlink.com.au>
References: <u8y0jz762.fsf@boost-consulting.com> <42D15DB2.3020300@v.loewis.de>
	<20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
	<200507171601.23780.anthony@interlink.com.au>
Message-ID: <20050717100609.GB3581@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 17, 2005 at 04:01:20PM +1000, Anthony Baxter wrote:
> On Saturday 16 July 2005 20:13, Christoph Ludwig wrote:
> > I submitted patch #1239112 that implements the test involving two TUs for
> > Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
> > that will take some time.
> 
> I'm only vaguely aware of all of the issues here with linking, but if this
> is to be considered for 2.4.2, it needs to be low risk of breaking anything.
> 2.4.2 is a bugfix release, and I'd hate to have this break other systems that 
> work...

I prepared the patch for 2.4.2 since it is indeed a bugfix. The current test
produces wrong results if the compiler is GCC 4.0 which inhibits a successful
build of Python 2.4.

I tested the patch with GCC 2.95, 3.3 and 4.0 - those are the only compilers I
have easy access to right now. I do not see how this patch could cause
regressions on other platforms because it mimics the situation
w.r.t. ccpython.cc: A C++ translation unit calls from main() an extern "C"
function in a separate C translation unit. The test determines whether it is
possible to produce an intact executable if the C compiler is used as linker
driver. If this test causes problems on some platform then you'd expect
trouble when linking the python executable out of ccpython.o and all the other
C object modules anyway.

But, of course, I might be wrong. I do not claim that I am familiar with every
platform's peculiarities. That's why the patch is up for review. I'd appreciate
if users on other platforms test it.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html



From anthony at interlink.com.au  Sun Jul 17 15:21:28 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun, 17 Jul 2005 23:21:28 +1000
Subject: [C++-sig] [Python-Dev]   GCC version compatibility
In-Reply-To: <20050717100609.GB3581@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com>
	<200507171601.23780.anthony@interlink.com.au>
	<20050717100609.GB3581@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <200507172321.31665.anthony@interlink.com.au>


> I prepared the patch for 2.4.2 since it is indeed a bugfix. The current
> test produces wrong results if the compiler is GCC 4.0 which inhibits a
> successful build of Python 2.4.

I should probably add that I'm not flagging that I think there's a problem
here. I'm mostly urging caution - I hate having to cut brown-paper-bag 
releases <wink>. If possible, can the folks on c++-sig try this patch
out and put their results in the patch discussion? If you're keen, you 
could try jumping onto HP's testdrive systems (http://www.testdrive.hp.com/).
From what I recall, they have a bunch of systems with non-gcc C++ compilers,
including the DEC^WDigital^Compaq^WHP one on the alphas, and the HP C++ 
compiler on the HP/UX boxes[1].

(and, it should be added, I very much appreciate the work you've put into
fixing this problem)


Anthony


[1] dunno how useful the HP/UX C++ compiler is going to be - last time I
was exposed to it, many years ago, it was... not good. 
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From ult at mundane.org  Mon Jul 18 17:11:58 2005
From: ult at mundane.org (Ult Mundane)
Date: Mon, 18 Jul 2005 11:11:58 -0400
Subject: [C++-sig] Providing a Package from a single Extension?
Message-ID: <42DBC6BE.4060908@mundane.org>

Hi there,

I would like to create a single python extension that provides a package 
structure (multiple submodules).

Here's why I think this is the best thing to do, please advise if there's a 
better way to achieve the same result:

I'm embedding python in a statically linked application. Because the python 
modules will be statically linking to common libraries and I'd like only one 
copy of each library at runtime, I'm statically linking the modules into the 
application.

My question is, what's the best way to provide a package from a static 
application embedding python?

The following code is how I'm approximating it. It allows python code running in 
the embedded interpreter to "import pyext" which in turn provides 
"pyext.submodule". It doesn't, however, allow "import pyext.submodule", which a 
real package made of multiple shared modules would allow. Are there any other 
ways I might be disturbing the order of things by this unconventional approach? 
Is there a more conventional approach to do the same thing?

Thanks,

Ult

---

#include <Python.h>
#include <boost/python.hpp>

#include <iostream>

using namespace boost::python;

void func(char const * str)
{
   std::cout << str << std::endl;
}

BOOST_PYTHON_MODULE(submodule)
{
   def("func", func);
}

BOOST_PYTHON_MODULE(pyext)
{
   def("func", func);

   initsubmodule();

   object submodule((
       handle<>(borrowed(PyImport_AddModule("submodule")))));

   scope().attr("submodule") = submodule;
}

int main(int argc, char * argv[])
{
   Py_Initialize();

   initpyext();

   Py_Main(argc, argv);

   Py_Finalize();
}


From abentley at panoramicfeedback.com  Mon Jul 18 17:45:53 2005
From: abentley at panoramicfeedback.com (Aaron Bentley)
Date: Mon, 18 Jul 2005 11:45:53 -0400
Subject: [C++-sig] Auto-converting to a custom string type?
Message-ID: <dbgiri$lcp$1@sea.gmane.org>

Our library uses a custom unicode string type called 'StringBuffer'.
I'd like to be able to auto-convert python unicode objects into
StringBuffers, because the alternative (AFAICT) it to wrap every
function that takes a StringBuffer parameter.

I thought I might be able to declare Python objects as implicitly
convertible to StringBuffer, but it doesn't quite work

---
StringBuffer make_StringBuffer(PyObject * uni_str)
{
   const char *utf8str = call_method<const char *>(uni_str, "encode",
"UTF-8");
   const char *end = utf8str + strlen(utf8str);
   StringBuffer sb;
   stringfunction::fromUTF8(sb.back_inserter(), utf8str, end);
   return sb;
}

then

def("make_StringBuffer", make_StringBuffer);

implicitly_convertible<PyObject *, StringBuffer>();
---

But what I get is

---
/home/abentley/develc/boost/boost/python/implicit.hpp:22:   instantiated
from `void boost::python::implicitly_convertible(boost::type<Target>*,
boost::type<U>*) [with Source = PyObject*, Target = StringBuffer]'
/home/abentley/develc/engine/python/pfengine.cpp:562:   instantiated
from here
/home/abentley/develc/boost/boost/python/converter/implicit.hpp:34: no
matching function for call to `StringBuffer::StringBuffer(PyObject*)'
---

It appears to insist that I provide a constructor
StringBuffer::StringBuffer(PyObject*), but I would rather do this
wrapping without altering the StringBuffer class.

Is there a better way?

Aaron
-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.



From abentley at panoramicfeedback.com  Mon Jul 18 18:56:00 2005
From: abentley at panoramicfeedback.com (Aaron Bentley)
Date: Mon, 18 Jul 2005 12:56:00 -0400
Subject: [C++-sig] Auto-converting to a custom string type?
In-Reply-To: <dbgiri$lcp$1@sea.gmane.org>
References: <dbgiri$lcp$1@sea.gmane.org>
Message-ID: <dbgmv1$2q7$1@sea.gmane.org>

Aaron Bentley wrote:
> Our library uses a custom unicode string type called 'StringBuffer'.
> I'd like to be able to auto-convert python unicode objects into
> StringBuffers, because the alternative (AFAICT) it to wrap every
> function that takes a StringBuffer parameter.

Not solved yet, but progress:
I found Ralf Grosse-Kunstleve's approach, and I got it to work
http://mail.python.org/pipermail/c++-sig/2002-November/002640.html

class StringBufferPy: public StringBuffer
{
   public:
   StringBufferPy(PyObject *mine, PyObject *uni_str)
   {
      string utf8str = call_method<string>(uni_str, "encode", "UTF-8");
      pythonhelp::appendUTF8(*this, utf8str);
   }
   StringBufferPy(PyObject *mine, StringBuffer const &sb)
      :
   StringBuffer(sb)
   {
   }
};

And then
   ///Wrap the StringBuffer class
   class_<StringBuffer, StringBufferPy>("StringBuffer", no_init)
      .def(init<StringBuffer const &>())
      .def(init<const char *>())
      .def(init<PyObject *>())

Etc.

So now the problem is that if I construct a StringBuffer from a
StringBuffer, it tries (and fails) to invoke StringBuffer.encode.  I
don't really want to support StringBuffer.encode, since repeated
encodes/decodes are pretty inefficient....

Aaron
-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.



From rwgk at yahoo.com  Mon Jul 18 20:17:21 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 18 Jul 2005 11:17:21 -0700 (PDT)
Subject: [C++-sig] Auto-converting to a custom string type?
In-Reply-To: <dbgmv1$2q7$1@sea.gmane.org>
Message-ID: <20050718181721.29365.qmail@web31501.mail.mud.yahoo.com>

--- Aaron Bentley <abentley at panoramicfeedback.com> wrote:

> Aaron Bentley wrote:
> > Our library uses a custom unicode string type called 'StringBuffer'.
> > I'd like to be able to auto-convert python unicode objects into
> > StringBuffers, because the alternative (AFAICT) it to wrap every
> > function that takes a StringBuffer parameter.
> 
> Not solved yet, but progress:
> I found Ralf Grosse-Kunstleve's approach, and I got it to work
> http://mail.python.org/pipermail/c++-sig/2002-November/002640.html

This may be a better approach (but I haven't looked at your code very closely):

http://mail.python.org/pipermail/c++-sig/2003-May/004133.html

> So now the problem is that if I construct a StringBuffer from a
> StringBuffer, it tries (and fails) to invoke StringBuffer.encode.  I
> don't really want to support StringBuffer.encode, since repeated
> encodes/decodes are pretty inefficient....

Let us know if the URL above doesn't help.

Cheers,
        Ralf



		
__________________________________ 
Yahoo! Mail for Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 


From ult at mundane.org  Mon Jul 18 20:52:38 2005
From: ult at mundane.org (Ult Mundane)
Date: Mon, 18 Jul 2005 14:52:38 -0400
Subject: [C++-sig] Providing a Package from a single Extension?
In-Reply-To: <42DBC6BE.4060908@mundane.org>
References: <42DBC6BE.4060908@mundane.org>
Message-ID: <42DBFA76.5080307@mundane.org>

For the record:

Here was a helpful URL:

http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/f929d6d8221c6ec7/f3ca352ae523a163?q=Py_InitModule+submodule&rnum=1&hl=en#f3ca352ae523a163

And here's a modification of my earlier code, which demonstrates creating a 
package using Boost.Python, statically linked into an application which embeds 
python. The static embedding part is not necessary for the example, however; a 
regular Python extension should be able to do the same thing.

Ult

---

#include <Python.h>
#include <boost/python.hpp>

#include <iostream>

using namespace boost::python;

void func(char const * str)
{
   std::cout << "@@@ " << str << std::endl;
}

BOOST_PYTHON_MODULE(mymodule)
{
   def("func", func);
}

void init_mypackage_mymodule()
{
   boost::python::detail::init_module("mypackage.mymodule", initmymodule);
}

BOOST_PYTHON_MODULE(mypackage)
{
   def("func", func);
   scope().attr("__path__") = "mypackage";

   init_mypackage_mymodule();

   object mymodule((
       handle<>(borrowed(PyImport_AddModule("mymodule")))));

   scope().attr("mymodule") = mymodule;
}

int main(int argc, char * argv[])
{
   PyImport_AppendInittab("mypackage", initmypackage);

   Py_Initialize();

   Py_Main(argc, argv);

   Py_Finalize();
}


From abentley at panoramicfeedback.com  Mon Jul 18 22:51:42 2005
From: abentley at panoramicfeedback.com (Aaron Bentley)
Date: Mon, 18 Jul 2005 16:51:42 -0400
Subject: [C++-sig] slots != 0
Message-ID: <dbh4ov$eff$1@sea.gmane.org>

Hi all,

I seem to have encountered a condition that should be impossible, in
Boost 1.31 Python.

I was getting assertion failures on registry.cpp, line 162:

      assert(slot == 0); // we have a problem otherwise

Commenting it out, I got a big stack of warnings about various things in
my _xml module being imported twice.  I can't see how this could happen,
and I don't know whether this is my bug or boost's.  Any suggestion of
the type of thing that could cause this would be appreciated.

So far, it's defying attempts to produce a reasonable test case.  There
may be circular dependencies, or something wacky like that.

Aaron

$ ppython pflib/report_gen.py
/home/abentley/programming/python/pflib/pfxml.py:3: RuntimeWarning:
to-Python converter for 7xmlList already registered; second conversion
method ignored.
  import _xml
/home/abentley/programming/python/pflib/pfxml.py:3: RuntimeWarning:
to-Python converter for N3xml8XmlTableE already registered; second
conversion method ignored.
  import _xml
/home/abentley/programming/python/pflib/pfxml.py:3: RuntimeWarning:
to-Python converter for St8auto_ptrIN3xml8XmlTableEE already registered;
second conversion method ignored.
  import _xml

-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.



From sram at qualcomm.com  Tue Jul 19 01:52:05 2005
From: sram at qualcomm.com (Ram, Siddharth)
Date: Mon, 18 Jul 2005 16:52:05 -0700
Subject: [C++-sig] Overloaded [] operator
Message-ID: <EC9142D53269D6428CC3BC573E1B584602C94175@NAEX01.na.qualcomm.com>

I have a C++ class which defines the following method:

CORBA::Octet &operator[] (CORBA::ULong);

I am trying to figure out how to export this to python using
pyste/Boost.Python.
http://www.boost.org/libs/python/doc/v2/operators.html does not include
the square bracket operator in the list of operators. Is this not a
supported operation ? How do I specify a  python method which would
result in this method being invoked in C++ ?

Thanks
Siddharth


From nick at ilm.com  Tue Jul 19 02:25:10 2005
From: nick at ilm.com (Nick Rasmussen)
Date: Mon, 18 Jul 2005 17:25:10 -0700
Subject: [C++-sig] Overloaded [] operator
In-Reply-To: <EC9142D53269D6428CC3BC573E1B584602C94175@NAEX01.na.qualcomm.com>
References: <EC9142D53269D6428CC3BC573E1B584602C94175@NAEX01.na.qualcomm.com>
Message-ID: <20050719002510.GH14096@steyr.lucasdigital.com>

you can overload "__getitem__" and "__setitem__" for the [] operator.

-nick

On Mon, 18 Jul 2005, Ram, Siddharth wrote:

> I have a C++ class which defines the following method:
> 
> CORBA::Octet &operator[] (CORBA::ULong);
> 
> I am trying to figure out how to export this to python using
> pyste/Boost.Python.
> http://www.boost.org/libs/python/doc/v2/operators.html does not include
> the square bracket operator in the list of operators. Is this not a
> supported operation ? How do I specify a  python method which would
> result in this method being invoked in C++ ?
> 
> Thanks
> Siddharth
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From dave at boost-consulting.com  Tue Jul 19 05:06:05 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 18 Jul 2005 23:06:05 -0400
Subject: [C++-sig] slots != 0
References: <dbh4ov$eff$1@sea.gmane.org>
Message-ID: <ur7dv336q.fsf@boost-consulting.com>

Aaron Bentley <abentley at panoramicfeedback.com> writes:

> Hi all,
>
> I seem to have encountered a condition that should be impossible, in
> Boost 1.31 Python.
>
> I was getting assertion failures on registry.cpp, line 162:
>
>       assert(slot == 0); // we have a problem otherwise
>
> Commenting it out, I got a big stack of warnings about various things in
> my _xml module being imported twice.  

I'm pretty sure that's not what the warnings said.  Probably something
more like


  "to-Python converter for xxx already registered; second conversion method ignored."

> I can't see how this could happen, and I don't know whether this is
> my bug or boost's.  Any suggestion of the type of thing that could
> cause this would be appreciated.

Exposing the same type to Python twice (usually from two separate
extension modules linked to the same libboost_python) will do it.

> So far, it's defying attempts to produce a reasonable test case.  There
> may be circular dependencies, or something wacky like that.
>
> Aaron
>
> $ ppython pflib/report_gen.py
> /home/abentley/programming/python/pflib/pfxml.py:3: RuntimeWarning:
> to-Python converter for 7xmlList already registered; second conversion
> method ignored.
>   import _xml
> /home/abentley/programming/python/pflib/pfxml.py:3: RuntimeWarning:
> to-Python converter for N3xml8XmlTableE already registered; second
> conversion method ignored.
>   import _xml
> /home/abentley/programming/python/pflib/pfxml.py:3: RuntimeWarning:
> to-Python converter for St8auto_ptrIN3xml8XmlTableEE already registered;
> second conversion method ignored.
>   import _xml

I suggest you recompile registry.cpp with BOOST_PYTHON_TRACE_REGISTRY
defined and look at the output to see where xmlList is exposed to
python the first and second times.

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



From nicodemus at esss.com.br  Tue Jul 19 13:28:10 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Tue, 19 Jul 2005 08:28:10 -0300
Subject: [C++-sig] Overloaded [] operator
In-Reply-To: <20050719002510.GH14096@steyr.lucasdigital.com>
References: <EC9142D53269D6428CC3BC573E1B584602C94175@NAEX01.na.qualcomm.com>
	<20050719002510.GH14096@steyr.lucasdigital.com>
Message-ID: <42DCE3CA.8050205@esss.com.br>

For some sample code (untested):

Octet& MyClass__getitem__(MyClass& c, ULong p)
{
    if (p < 0) {
       p = c.size() + p; // negative index
    }
    if (p > c.size()-1) {
        PyErr_SetString( PyExc_IndexError, "index out of range" 
);                                            
        boost::python::throw_error_already_set();   
    }
    return c[p];
}


BOOST_PYTHON_MODULE(mymodule)
{
   class_<MyClass, ...>(...)
      .def( "__getitem__", &MyClass__getitem__)
   ;
}

__setitem__ should be similar.

HTH,
Nicodemus.


Nick Rasmussen wrote:

>you can overload "__getitem__" and "__setitem__" for the [] operator.
>
>-nick
>
>On Mon, 18 Jul 2005, Ram, Siddharth wrote:
>
>  
>
>>I have a C++ class which defines the following method:
>>
>>CORBA::Octet &operator[] (CORBA::ULong);
>>
>>I am trying to figure out how to export this to python using
>>pyste/Boost.Python.
>>http://www.boost.org/libs/python/doc/v2/operators.html does not include
>>the square bracket operator in the list of operators. Is this not a
>>supported operation ? How do I specify a  python method which would
>>result in this method being invoked in C++ ?
>>
>>Thanks
>>Siddharth
>>_______________________________________________
>>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 abentley at panoramicfeedback.com  Tue Jul 19 21:22:29 2005
From: abentley at panoramicfeedback.com (Aaron Bentley)
Date: Tue, 19 Jul 2005 15:22:29 -0400
Subject: [C++-sig] slots != 0
In-Reply-To: <ur7dv336q.fsf@boost-consulting.com>
References: <dbh4ov$eff$1@sea.gmane.org> <ur7dv336q.fsf@boost-consulting.com>
Message-ID: <dbjjtm$5pl$1@sea.gmane.org>

David Abrahams wrote:

> I suggest you recompile registry.cpp with BOOST_PYTHON_TRACE_REGISTRY
> defined and look at the output to see where xmlList is exposed to
> python the first and second times.

Thanks for the tip.  Fortunately, this seems to be some kind of
build-process bogosity, and rebuilding everything (boost, our libraries,
and the boost wrappers) has fix it.

Aaron

-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.



From rwgk at yahoo.com  Wed Jul 20 02:17:26 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 19 Jul 2005 17:17:26 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
Message-ID: <20050720001726.52179.qmail@web31501.mail.mud.yahoo.com>

Hi David,

Often I'd like to quickly find out the signatures of C++ functions wrapped with
Boost.Python. Usually I use one of two approaches: 1. look in the wrapper
sources, 2. call the function with no or bogus arguments to provoke a
traceback, e.g.:

% python
Python 2.4.1 (#1, Apr  7 2005, 10:15:30) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from boost import rational
>>> rational.lcm()    
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    boost_rational_ext.lcm()
did not match C++ signature:
    lcm(int, int)
>>> 

Both options are not very elegant. I'd really like something more direct and
easier to explain. This lead me to the idea of implementing
Boost.Python.function.__signatures__:

http://cci.lbl.gov/~rwgk/boost_python/signatures/

Here you'll find the diffs for function.hpp and function.cpp, and also the
patched versions of both.

It works like this:

>>> print boost_rational_ext.lcm.__signatures__
['lcm(int, int)']


I.e. __signatures__ returns a list of strings with the signatures formatted as
in the traceback. Is this a good direction to take?

I know it needs more work (similar patch for member functions (?), tests on all
platforms, updated docs). I'll do this if I get positive feedback.

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From dave at boost-consulting.com  Wed Jul 20 15:09:58 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 20 Jul 2005 09:09:58 -0400
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050720001726.52179.qmail@web31501.mail.mud.yahoo.com> (Ralf
	W. Grosse-Kunstleve's message of "Tue,
	19 Jul 2005 17:17:26 -0700 (PDT)")
References: <20050720001726.52179.qmail@web31501.mail.mud.yahoo.com>
Message-ID: <u64v5lj2x.fsf@boost-consulting.com>

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

> I know it needs more work (similar patch for member functions (?), tests on all
> platforms, updated docs). I'll do this if I get positive feedback.

a. I basically support the idea; haven't looked at your code.

b. Wouldn't you want to get a sequence of sequences, where each
   element is the type of an argument or return type?

c. Should you look for ways to get this integrated into the stuff that
   Python normally puts on built-in Python functions, i.e. the stuff
   that help(f) uses?  This is a vague thought.

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


From skottmckay at gmail.com  Wed Jul 20 18:00:54 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Wed, 20 Jul 2005 10:00:54 -0600
Subject: [C++-sig] handling const uint8_t* return type
Message-ID: <51d01787050720090032ca75ab@mail.gmail.com>

I have a class with the following method:

class X {
...
  public:
    
    const uint8_t *data( size_t *length = NULL ) const;
...
}

Using pyste, I added a wrapper...

str dataWrapper( X *x ) {
    size_t len = 0;
    const uint8_t *data = x->data( &len );
    return ( str( reinterpret_cast<const char*>(data), len ) );
}

with 

set_wrapper( X.data, dataWrapper )

First question. Should pyste check for a wrapper being set before
emitting the 'Error - no policy specified' message, or are there time
when you want that error? As there's a wrapper the method is not
returning a pointer any more.

Second question. Is this the best way to handle a const uint8_t *
return which is returning an internally held buffer (that is
essentially a string), or could I do this with a more general
convertor that could be used anywhere?


FWIW The relevant bits of the generated code is the simple...

    class_< X >("X", init<  >())
        .def(init< const X& >())
        .def("data", &dataWrapper)
...
    

Thanks

S


From rwgk at yahoo.com  Wed Jul 20 18:26:15 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 20 Jul 2005 09:26:15 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <u64v5lj2x.fsf@boost-consulting.com>
Message-ID: <20050720162615.10663.qmail@web31515.mail.mud.yahoo.com>

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

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > I know it needs more work (similar patch for member functions (?), tests on
> all
> > platforms, updated docs). I'll do this if I get positive feedback.
> 
> a. I basically support the idea; haven't looked at your code.

The changes are very simple. In function.hpp I've just added a

  class list;

forward declaration in the boost::python namespace, along with a new
function::signatures() member function declaration.

In function.cpp I've moved your code for generating the list of strings with
the signatures into the new function::signatures() member function, almost
unchanged. I am calling this function from the old place (in
function::argument_error()). Finally I added the new function

    static PyObject* function_get_signatures(PyObject* op, void*)
    {
        function* f = downcast<function>(op);
        return python::incref(f->signatures().ptr());
    }

to

static PyGetSetDef function_getsetlist[] = {
    //...
    {"__signatures__", (getter)function_get_signatures, 0 },
    {NULL} /* Sentinel */
};

That's all.

> b. Wouldn't you want to get a sequence of sequences, where each
>    element is the type of an argument or return type?

I think it is an unneeded complication. I don't know where the extra level of
detail would be helpful. To get help the strings are just what you want. It is
easy enough to use split("(", 1) and split(",") in Python if more detail is
required, but I am having difficulties imagining a use case.

> c. Should you look for ways to get this integrated into the stuff that
>    Python normally puts on built-in Python functions, i.e. the stuff
>    that help(f) uses?  This is a vague thought.

I thought about this initially and looked in the pydoc and inspect sources. It
wasn't a match because Python doesn't have function overloading. inspect looks
at, e.g., func_defaults and expects exactly one answer (a tuple). However,
Boost.Python has multiple answers, one for each overload.

My plan is: 1. patch Boost.Python to provide the signature information, 2. try
to convince the Python folks to support __signatures__ in pydoc/inspect. I hope
1. is easy, I guess 2. will be much harder. In the meantime I'll give my users
a signatures() built-in that will work the same for regular Python functions
and Boost.Python functions. I need this soon because I'll be teaching at a
school in a four weeks. I don't want everybody to look at the wrapper sources
to figure out the signatures; and of course, as always, there is no time to
write documentation for everything. Easily accessible just-in-time help is the
best option, I believe.

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From mrovner at propel.com  Wed Jul 20 19:43:37 2005
From: mrovner at propel.com (Mike Rovner)
Date: Wed, 20 Jul 2005 10:43:37 -0700
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050720162615.10663.qmail@web31515.mail.mud.yahoo.com>
References: <u64v5lj2x.fsf@boost-consulting.com>
	<20050720162615.10663.qmail@web31515.mail.mud.yahoo.com>
Message-ID: <dbm2h5$hat$1@sea.gmane.org>

Ralf W. Grosse-Kunstleve wrote:
> My plan is: 1. patch Boost.Python to provide the signature information, 2. try
> to convince the Python folks to support __signatures__ in pydoc/inspect. I hope
> 1. is easy, I guess 2. will be much harder. In the meantime I'll give my users
> a signatures() built-in that will work the same for regular Python functions
> and Boost.Python functions. I need this soon because I'll be teaching at a
> school in a four weeks. I don't want everybody to look at the wrapper sources
> to figure out the signatures; and of course, as always, there is no time to
> write documentation for everything. Easily accessible just-in-time help is the
> best option, I believe.

Python has no nothion of multiple callable signatures (and method 
resolution) so I regard it unpythonic. Having mutiple signatures in BPL 
is an implementation detail, so probably __signature__ can make it into 
pydoc with more ease.

My .02

Mike



From rwgk at yahoo.com  Wed Jul 20 20:30:17 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 20 Jul 2005 11:30:17 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <dbm2h5$hat$1@sea.gmane.org>
Message-ID: <20050720183018.73962.qmail@web31504.mail.mud.yahoo.com>

--- Mike Rovner <mrovner at propel.com> wrote:
> Python has no nothion of multiple callable signatures (and method 
> resolution) so I regard it unpythonic.

Very often I wish Python would support overloads. The alternative *args,
**keyword_args approach is unreadable. It forces you to look at __doc__. In my
mind that's a sign of a poor design. One of the main advantages of modern
languages is that they formalize what you used to find in comments in older
code. E.g.:

  http://www.netlib.org/slatec/src/avint.f

Input -> const, Output -> members of struct, IERR -> exception, etc. Of course,
Python is a long way from this stone-age code. But I wish it could go even
further.

All that said, I am not going to fight this battle. :)

> Having mutiple signatures in BPL 
> is an implementation detail, so probably __signature__ can make it into 
> pydoc with more ease.

That would be nice. I am just worried because the Python folks tend to be
really rough, at least compared to the folks I tend to meet in my home
universe.

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From nick at ilm.com  Wed Jul 20 20:46:34 2005
From: nick at ilm.com (Nick Rasmussen)
Date: Wed, 20 Jul 2005 11:46:34 -0700
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050720162615.10663.qmail@web31515.mail.mud.yahoo.com>
References: <u64v5lj2x.fsf@boost-consulting.com>
	<20050720162615.10663.qmail@web31515.mail.mud.yahoo.com>
Message-ID: <20050720184633.GV14096@steyr.lucasdigital.com>

On Wed, 20 Jul 2005, Ralf W. Grosse-Kunstleve wrote:

> My plan is: 1. patch Boost.Python to provide the signature information, 2. try
> to convince the Python folks to support __signatures__ in pydoc/inspect. I hope
> 1. is easy, I guess 2. will be much harder. In the meantime I'll give my users
> a signatures() built-in that will work the same for regular Python functions
> and Boost.Python functions. I need this soon because I'll be teaching at a
> school in a four weeks. I don't want everybody to look at the wrapper sources
> to figure out the signatures; and of course, as always, there is no time to
> write documentation for everything. Easily accessible just-in-time help is the
> best option, I believe.
> 

If better docstrings is what you're after, why not just prepend the function
signature (either optionally or automatically) to the docstring. That way the
help() mechanism will give you the list of all the the overloads like you're
looking for even for functions where the docstring wasn't explictly specified,
and no change to python is needed.

-nick



From rwgk at yahoo.com  Wed Jul 20 21:24:25 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 20 Jul 2005 12:24:25 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050720184633.GV14096@steyr.lucasdigital.com>
Message-ID: <20050720192425.31891.qmail@web31509.mail.mud.yahoo.com>

--- Nick Rasmussen <nick at ilm.com> wrote:
> If better docstrings is what you're after, why not just prepend the function
> signature (either optionally or automatically) to the docstring. That way the
> help() mechanism will give you the list of all the the overloads like you're
> looking for even for functions where the docstring wasn't explictly
> specified, and no change to python is needed.

That's an interesting idea. I can think of a couple of issues, though:

- Quite often the signatures are unwieldy, e.g. (this is not made up):

    max(scitbx::af::versa<double, scitbx::af::flex_grid<scitbx::af::small<long,
10ul> > >)
    max(scitbx::af::versa<float, scitbx::af::flex_grid<scitbx::af::small<long,
10ul> > >)
    max(scitbx::af::versa<long, scitbx::af::flex_grid<scitbx::af::small<long,
10ul> > >)
    max(scitbx::af::versa<int, scitbx::af::flex_grid<scitbx::af::small<long,
10ul> > >)
    max(scitbx::af::versa<unsigned long,
scitbx::af::flex_grid<scitbx::af::small<long, 10ul> > >)

  It may be hard to find where the real documentation starts.
  Maybe appending is better?

- I guess currently the docstrings are static. They'd have to become dynamic.
  This seems to be a bigger project. I think we'd need a volunteer.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From nick at ilm.com  Wed Jul 20 22:01:41 2005
From: nick at ilm.com (Nick Rasmussen)
Date: Wed, 20 Jul 2005 13:01:41 -0700
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050720192425.31891.qmail@web31509.mail.mud.yahoo.com>
References: <20050720184633.GV14096@steyr.lucasdigital.com>
	<20050720192425.31891.qmail@web31509.mail.mud.yahoo.com>
Message-ID: <20050720200141.GX14096@steyr.lucasdigital.com>

On Wed, 20 Jul 2005, Ralf W. Grosse-Kunstleve wrote:

> --- Nick Rasmussen <nick at ilm.com> wrote:
> > If better docstrings is what you're after, why not just prepend the function
> > signature (either optionally or automatically) to the docstring. That way the
> > help() mechanism will give you the list of all the the overloads like you're
> > looking for even for functions where the docstring wasn't explictly
> > specified, and no change to python is needed.
> 
> That's an interesting idea. I can think of a couple of issues, though:
> 
> - Quite often the signatures are unwieldy, e.g. (this is not made up):
> 
>     max(scitbx::af::versa<double, scitbx::af::flex_grid<scitbx::af::small<long,
> 10ul> > >)
>     max(scitbx::af::versa<float, scitbx::af::flex_grid<scitbx::af::small<long,
> 10ul> > >)
>     max(scitbx::af::versa<long, scitbx::af::flex_grid<scitbx::af::small<long,
> 10ul> > >)
>     max(scitbx::af::versa<int, scitbx::af::flex_grid<scitbx::af::small<long,
> 10ul> > >)
>     max(scitbx::af::versa<unsigned long,
> scitbx::af::flex_grid<scitbx::af::small<long, 10ul> > >)
> 
>   It may be hard to find where the real documentation starts.
>   Maybe appending is better?

Not to over-complicate matters, but perhaps it'd be best to do something like:

int foo(int x) {}
...
     .def("foo",&foo,"foo(x) -> value\nC++ signature: " + signature())

where signature() is an indicator to .def as a place to substitute in the C++
signature, resulting in pydoc showing:

    foo(...)
        foo(x) -> value
        C++ signature: foo(int) -> int

   
and make:

     .def("foo",&foo) // no docstring

and:
     .def("foo",&foo,signature())

be equivalent, resulting in:

    foo(...)
        foo(int) -> int

That way people with existing docstrings will have help() output remain unchanged.
If you want to insert the signature into your docstring you have the choice of
how to use it, and for people that haven't put docstrings on their code, they
at least get some info in their docstrings.

> - I guess currently the docstrings are static. They'd have to become dynamic.
>   This seems to be a bigger project. I think we'd need a volunteer.

I'm not sure what you mean by dynamic, the docstrings are constructed
at .def time via src/object/function.cpp:

void function::add_to_namespace(
    object const& name_space, char const* name_, object const& attribute, char const* doc)
{
    add_to_namespace(name_space, name_, attribute);
    if (doc != 0)
    {
        object attr_copy(attribute);
        if (PyObject_HasAttrString(attr_copy.ptr(), "__doc__") && attr_copy.attr("__doc__")) {
            attr_copy.attr("__doc__") += "\n\n";
            attr_copy.attr("__doc__") += doc;
        }
        else
            attr_copy.attr("__doc__") = doc;
    }
}

I'm sure we already know the signature at that point.

-nick



From rwgk at yahoo.com  Thu Jul 21 04:35:29 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 20 Jul 2005 19:35:29 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050720200141.GX14096@steyr.lucasdigital.com>
Message-ID: <20050721023529.60789.qmail@web31515.mail.mud.yahoo.com>

--- Nick Rasmussen <nick at ilm.com> wrote:
> > - I guess currently the docstrings are static. They'd have to become
> dynamic.
> >   This seems to be a bigger project. I think we'd need a volunteer.
> 
> I'm not sure what you mean by dynamic,

It turns out my guess was wrong. Sorry.

I looked some more and here is the result:

http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.hpp_2005_07_20_1909_diff
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.hpp_2005_07_20_1909

http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.cpp_2005_07_20_1909_diff
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.cpp_2005_07_20_1909

Summary:

- I've removed my __signatures__ method.

- I've patched the getter for __doc__ to *always* append the list of
signatures. E.g.:

>>> help(rational.lcm)

Help on built-in function lcm:

lcm(...)
    C++ signature:
    lcm(int, int) -> int

>>> help(rational.int().numerator)

Help on method numerator:

numerator(...) method of boost_rational_ext.int instance
    C++ signature:
    numerator(boost::rational<int> {lvalue}) -> int


This looks like *the* solution to me. Thanks a lot for your brilliant idea,
Nick!

Personally I don't think we need the facilities to disable appending the
signatures. Are there other opinions?

Dave, could you please briefly review my patch? It is still very simple:
forward class list in function.hpp + list signatures(bool
show_return_type=false) const; declaration; in function.cpp I've move some code
from the body of argument_error() to the new signatures() function and I've
patched the body of function_get_doc() to append the result of signatures().

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From yys2000 at yahoo.com  Thu Jul 21 15:12:59 2005
From: yys2000 at yahoo.com (Yongsheng Yang)
Date: Thu, 21 Jul 2005 06:12:59 -0700 (PDT)
Subject: [C++-sig] C++ call python class
Message-ID: <20050721131259.20574.qmail@web41003.mail.yahoo.com>

hi all:

Right now, I want to use C++ to call a python class.
There is a sample or tutorial here?

thanks!




		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 


From dave at boost-consulting.com  Thu Jul 21 15:34:41 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 21 Jul 2005 09:34:41 -0400
Subject: [C++-sig] Boost.Python.function.__signatures__
References: <20050720200141.GX14096@steyr.lucasdigital.com>
	<20050721023529.60789.qmail@web31515.mail.mud.yahoo.com>
Message-ID: <uwtnkp9ji.fsf@boost-consulting.com>

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

> Dave, could you please briefly review my patch? It is still very simple:
> forward class list in function.hpp + list signatures(bool
> show_return_type=false) const; declaration; 

It's good practice to supply the user with everything he needs to use
a function declared in a given header.  That would mean including the
full definition of list.  Any reason not to?

> in function.cpp I've move some code
> from the body of argument_error() to the new signatures() function and I've
> patched the body of function_get_doc() to append the result of signatures().

It would be nice if the if(show_return_type) statement appeared to
have less apparent boilerplate repetition in its two branches, but
aside from that it seems fine.

Thanks for doing this!

Naturally, it can't go on the trunk until after 1.33 is released.

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



From rwgk at yahoo.com  Thu Jul 21 15:53:08 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 21 Jul 2005 06:53:08 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <uwtnkp9ji.fsf@boost-consulting.com>
Message-ID: <20050721135308.45395.qmail@web31512.mail.mud.yahoo.com>

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

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > Dave, could you please briefly review my patch? It is still very simple:
> > forward class list in function.hpp + list signatures(bool
> > show_return_type=false) const; declaration; 
> 
> It's good practice to supply the user with everything he needs to use
> a function declared in a given header.  That would mean including the
> full definition of list.  Any reason not to?

Bringing in a new header file sometimes leads to trouble with broken compilers.
Initially I just wanted to be as non-intrusive as possible. But I am 100% on
your side. I'll move the list.hpp include from function.cpp to function.hpp.
Thanks.

> > in function.cpp I've move some code
> > from the body of argument_error() to the new signatures() function and I've
> > patched the body of function_get_doc() to append the result of
> signatures().
> 
> It would be nice if the if(show_return_type) statement appeared to
> have less apparent boilerplate repetition in its two branches, but
> aside from that it seems fine.

I thought about this, but came to the conclusion that the version with
less-boilerplate is going to be longer and less obvious to the reader.

> Thanks for doing this!

Can you (or anybody else!) think of a suitable place to mention the automatic
appending to __doc__ in the documentation?

> Naturally, it can't go on the trunk until after 1.33 is released.

OK. I am also sitting on my SWIG compatibility patch. I hope 1.33 is released
soon. Otherwise I'll be out of town and the patches are not likely to get
integrated before the end of September.

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From beyer at imb-jena.de  Thu Jul 21 18:30:01 2005
From: beyer at imb-jena.de (Andreas Beyer)
Date: Thu, 21 Jul 2005 09:30:01 -0700
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <20050721135308.45395.qmail@web31512.mail.mud.yahoo.com>
References: <20050721135308.45395.qmail@web31512.mail.mud.yahoo.com>
Message-ID: <42DFCD89.1030906@imb-jena.de>

Ralf W. Grosse-Kunstleve wrote:

>
>Can you (or anybody else!) think of a suitable place to mention the automatic
>appending to __doc__ in the documentation?
>
>  
>
I guess a good place would be where you also document how to add custom 
doc-strings to functions, that is here:
http://www.boost.org/libs/python/doc/v2/def.html#functions

BTW I couldn't find any location in the tutorial where the possibility 
to Python-document your wrapper is even mentioned. Maybe that could be 
added to the hello-world example?

Andreas



From Bill at SynectixLtd.com  Thu Jul 21 18:38:25 2005
From: Bill at SynectixLtd.com (Bill Davy)
Date: Thu, 21 Jul 2005 17:38:25 +0100
Subject: [C++-sig] A 'WCHAR *' is expected, 'unicode(SerNo.0001)' is received
Message-ID: <200507211638.BHY96525@C2bthomr05.btconnect.com>

I've extracted the following from a larger program:

Class SomethingC
	{
	public:
enum SerialNumberLengthE
		{
		SerialNumberCharacters = 10
		};
typedef enum {mt_EEPROM, mt_RAM} MemoryTypeT;
int WriteIntelHexFileToMemory(
             const TCHAR *IntelHexFileName, 
		const WCHAR SerialNumber[SerialNumberCharacters], 
		const MemoryTypeT MemoryType);
	};

In the wrapper, I have:

typedef char TCHAR;
typedef wchar_t WCHAR;

In Python, I do:

FileName = r'E:\Husky\Cypress\Target\V1\Start1.hex'
SerialNumber = u'SerNo.0001'
MemoryType = SHIP.HuskyUsbC.mt_RAM
esult =
SomethingC.WriteIntelHexFileToMemory(FileName,SerialNumber,MemoryType)

But at runtime I get:

TypeError: argument number 3: a 'WCHAR *' is expected, 'unicode(SerNo.0001)'
is received

I'm using SWIG-1.3.24 and Python 2.4.1

Suggestions, please.

Tia,
	Bill

~*""*~.,,.~*""*~.,,~*""*~.,,.~*""*~.,,~*""*~.,,.~*""*~.,,.~*""*~.,

Privileged/Confidential information may be contained in this message. If you
are not the addressee indicated in this message (or responsible for delivery
of the message to such person), you may not copy or deliver this message to
anyone. In such case, you should destroy this message, and please notify us
immediately. Please advise immediately if you or your employer does not
consent to Internet e-mail for messages of this kind.

Opinions, conclusions and other information expressed in this message are
not given or endorsed by my firm or employer unless otherwise indicated by
an authorised representative independent of this message.

Although we utilise the most up to date virus checking procedures you should
carry out your own virus check before opening any attachment. We accept no
liability for any loss or damage which may be caused by software viruses.

~*""*~.,,.~*""*~.,,~*""*~.,,.~*""*~.,,~*""*~.,,.~*""*~.,,.~*""*~.,

Bill Davy, Synectix Limited, 12 King Alfred Way, Cheltenham, GL52 6QP,
England

Telephone: +44 (0)1242 254411, Mobile: +44 (0)7866 451568, Fax: +44 (0)1242
256611

Work: mailto:Bill at SynectixLtd.com

Home: mailto:Bill at XchelSys.co.uk

Web: http://www.synectixltd.com/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5202 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050721/d0b80bf6/attachment.bin>

From nickm at sitius.com  Thu Jul 21 19:38:58 2005
From: nickm at sitius.com (Nikolay Mladenov)
Date: Thu, 21 Jul 2005 13:38:58 -0400
Subject: [C++-sig] Boost.Python.function.__signatures__
References: <20050720001726.52179.qmail@web31501.mail.mud.yahoo.com>
Message-ID: <42DFDDB2.403E049D@sitius.com>

I worked on that a bit in the past and I had some initial work committed
in branch function_signature_patches_1_31. I also have some more
uncommitted changes.
A week ago I started to work on it again and I will try to merge it with
the main branch.

Currently help on our boost.python modules is working like that:

>>> help(samath.Plane3.normal)
Help on method normal:

normal(...) unbound sitius.samath.Plane3 method
    normal( (Plane3)self) -> Vector3
    normal( (Plane3)self, (Vector3)dir [, (int)is_unit=0]) -> Plane3


It is using the Pythonic type names and the argument names and default
values if available.


Nikolay

"Ralf W. Grosse-Kunstleve" wrote:
> 
> Hi David,
> 
> Often I'd like to quickly find out the signatures of C++ functions wrapped with
> Boost.Python. Usually I use one of two approaches: 1. look in the wrapper
> sources, 2. call the function with no or bogus arguments to provoke a
> traceback, e.g.:
> 
> % python
> Python 2.4.1 (#1, Apr  7 2005, 10:15:30)
> [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from boost import rational
> >>> rational.lcm()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> Boost.Python.ArgumentError: Python argument types in
>     boost_rational_ext.lcm()
> did not match C++ signature:
>     lcm(int, int)
> >>>
> 
> Both options are not very elegant. I'd really like something more direct and
> easier to explain. This lead me to the idea of implementing
> Boost.Python.function.__signatures__:
> 
> http://cci.lbl.gov/~rwgk/boost_python/signatures/
> 
> Here you'll find the diffs for function.hpp and function.cpp, and also the
> patched versions of both.
> 
> It works like this:
> 
> >>> print boost_rational_ext.lcm.__signatures__
> ['lcm(int, int)']
> 
> I.e. __signatures__ returns a list of strings with the signatures formatted as
> in the traceback. Is this a good direction to take?
> 
> I know it needs more work (similar patch for member functions (?), tests on all
> platforms, updated docs). I'll do this if I get positive feedback.
> 
> Cheers,
>         Ralf
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com



From rwgk at yahoo.com  Thu Jul 21 20:50:40 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 21 Jul 2005 11:50:40 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <42DFDDB2.403E049D@sitius.com>
Message-ID: <20050721185040.83516.qmail@web31508.mail.mud.yahoo.com>

--- Nikolay Mladenov <nickm at sitius.com> wrote:

> I worked on that a bit in the past and I had some initial work committed
> in branch function_signature_patches_1_31. I also have some more
> uncommitted changes.
> A week ago I started to work on it again and I will try to merge it with
> the main branch.
> 
> Currently help on our boost.python modules is working like that:
> 
> >>> help(samath.Plane3.normal)
> Help on method normal:
> 
> normal(...) unbound sitius.samath.Plane3 method
>     normal( (Plane3)self) -> Vector3
>     normal( (Plane3)self, (Vector3)dir [, (int)is_unit=0]) -> Plane3
> 
> 
> It is using the Pythonic type names and the argument names and default
> values if available.

Cool!
What does "Pythonic type names" mean exactly?
Did you also patch the __doc__ getter?
Are you appending or prepending? Can this be customized? (Not that I think
customization is very important; I am just wondering.)

Cheers,
        Ralf



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 


From Paul_Kunz at slac.stanford.edu  Thu Jul 21 21:01:29 2005
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 21 Jul 2005 12:01:29 -0700
Subject: [C++-sig] Trying to clone Python object from C++ (again)
Message-ID: <200507211901.j6LJ1T0F005132@libra3.slac.stanford.edu>

   I'm trying once again to clone a Python object whose class is
derived from an exposed C++ base class from C++.  After I call from
C++ clone() on the base class pointer, I wind up here...

FunctionBase *
FunctionWrap::
clone () const
{
#ifndef HAVE_OLD_PYTHON
  PyGILState_STATE state = PyGILState_Ensure ();
  object py_result;

  if (override clone = this->get_override("clone"))
    {
      try {
	// The Python class author overrode clone; do
	// whatever she says
	py_result = clone();
      }
      catch ( error_already_set & e ) {
	return 0;
      }
    }
  else

(thanks to Dave for essentially writing this for me).

The problem is that the exception is thrown.   The Python code looks
like...

class Linear ( FunctionBase ) :
    def __init__ ( self, other = None ) :
        if other : # copy constructor
            FunctionBase.__init__( self, other )
        else : # default constructor
            FunctionBase.__init__( self )
            print "default called"
            self.initialize ()

    def clone ( self ) :
        print "clone called"
        return Linear ()
    
Where FunctionBase is the exposed C++ class.   Both print states are
executed when I call clone() from C++.

Suggestions?


From dave at boost-consulting.com  Thu Jul 21 21:27:59 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 21 Jul 2005 15:27:59 -0400
Subject: [C++-sig] Trying to clone Python object from C++ (again)
References: <200507211901.j6LJ1T0F005132@libra3.slac.stanford.edu>
Message-ID: <ubr4wq7r4.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:

>    I'm trying once again to clone a Python object whose class is
> derived from an exposed C++ base class from C++.  After I call from
> C++ clone() on the base class pointer, I wind up here...
>
> FunctionBase *
> FunctionWrap::
> clone () const
> {
> #ifndef HAVE_OLD_PYTHON
>   PyGILState_STATE state = PyGILState_Ensure ();
>   object py_result;
>
>   if (override clone = this->get_override("clone"))
>     {
>       try {
> 	// The Python class author overrode clone; do
> 	// whatever she says
> 	py_result = clone();
>       }
>       catch ( error_already_set & e ) {
> 	return 0;
>       }
>     }
>   else
>
> (thanks to Dave for essentially writing this for me).

I wrote that??  I wouldn't want to take responsibility for that
try/catch block.  It just discards all the information about what
happened.

> The problem is that the exception is thrown.   

Which exception?

> The Python code looks like...
>
> class Linear ( FunctionBase ) :
>     def __init__ ( self, other = None ) :
>         if other : # copy constructor
>             FunctionBase.__init__( self, other )
>         else : # default constructor
>             FunctionBase.__init__( self )
>             print "default called"
>             self.initialize ()
>
>     def clone ( self ) :
>         print "clone called"
>         return Linear ()
>     
> Where FunctionBase is the exposed C++ class.   Both print states are
> executed when I call clone() from C++.
>
> Suggestions?

  if (override clone = this->get_override("clone"))
  {
        // The Python class author overrode clone; do
        // whatever she says
        py_result = clone();
  }
  else

??

Or, at the very least,

  if (override clone = this->get_override("clone"))
  {
        // The Python class author overrode clone; do
        // whatever she says
        try { py_result = clone(); }
       catch ( error_already_set & e ) { PyErr_Print(); return 0  }
  }
  else


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



From Paul_Kunz at slac.stanford.edu  Thu Jul 21 22:01:30 2005
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 21 Jul 2005 13:01:30 -0700
Subject: [C++-sig] Trying to clone Python object from C++ (again)
In-Reply-To: <ubr4wq7r4.fsf@boost-consulting.com> (message from David Abrahams
	on Thu, 21 Jul 2005 15:27:59 -0400)
References: <200507211901.j6LJ1T0F005132@libra3.slac.stanford.edu>
	<ubr4wq7r4.fsf@boost-consulting.com>
Message-ID: <200507212001.j6LK1UtN005249@libra3.slac.stanford.edu>

>>>>> On Thu, 21 Jul 2005 15:27:59 -0400, David Abrahams <dave at boost-consulting.com> said:

> "Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:
>> I'm trying once again to clone a Python object whose class is
>> derived from an exposed C++ base class from C++.  After I call from
>> C++ clone() on the base class pointer, I wind up here...
>> 
>> FunctionBase * FunctionWrap:: clone () const { #ifndef
>> HAVE_OLD_PYTHON PyGILState_STATE state = PyGILState_Ensure ();
>> object py_result;
>> 
>> if (override clone = this->get_override("clone"))
>>  { 
>>    try { 
>>   // The Python class author overrode clone; do
>>    // whatever she says
>>      py_result = clone();
>>    } catch ( error_already_set & e )  { 
>>      return 0;
>>    }
>>  } else
>> 
>> (thanks to Dave for essentially writing this for me).

> I wrote that??  I wouldn't want to take responsibility for that
> try/catch block.  It just discards all the information about what
> happened.

   Ok, *I* added the try/catch block around the code you helped me
with a long time ago.   Apologies.

>> The problem is that the exception is thrown.

> Which exception?

The error_already_set exception is always thrown.

>   if (override clone = this->get_override("clone")) { // The Python
> class author overrode clone; do // whatever she says try { py_result
> = clone(); } catch ( error_already_set & e ) { PyErr_Print(); return
> 0 } } else

   I'll try the PyErr_Print to see what I get.   Thanks.


From Paul_Kunz at slac.stanford.edu  Thu Jul 21 22:05:15 2005
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 21 Jul 2005 13:05:15 -0700
Subject: [C++-sig] Trying to clone Python object from C++ (again)
In-Reply-To: <ubr4wq7r4.fsf@boost-consulting.com> (message from David Abrahams
	on Thu, 21 Jul 2005 15:27:59 -0400)
References: <200507211901.j6LJ1T0F005132@libra3.slac.stanford.edu>
	<ubr4wq7r4.fsf@boost-consulting.com>
Message-ID: <200507212005.j6LK5FBU005253@libra3.slac.stanford.edu>

Here's the error message I get from PyErr_Print()

ReferenceError: Attempt to return dangling reference to object of type: boost::python::api::object


From pythondeveloper at gmail.com  Thu Jul 21 22:38:07 2005
From: pythondeveloper at gmail.com (Scott Kaplan)
Date: Thu, 21 Jul 2005 16:38:07 -0400
Subject: [C++-sig] which has a faster execution time?
Message-ID: <86afeadf05072113386ee777b6@mail.gmail.com>

I am new to Python, but I am an experienced c++ developer.

>From the research that I have done on Python, it appears that I can

1) Embed Python into a C++ application or
2) write c++ modules to extend Python

Which one, if either, will has better performance.

This is for a website.

Thanks in advance,


From rwgk at yahoo.com  Thu Jul 21 22:47:15 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 21 Jul 2005 13:47:15 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <42E0068E.7AB6C68F@sitius.com>
Message-ID: <20050721204715.12268.qmail@web31507.mail.mud.yahoo.com>

--- Nikolay Mladenov <nickm at sitius.com> wrote:
> > Are you appending or prepending? Can this be customized? (Not that I think
> > customization is very important; I am just wondering.)
> 
> I am appending the docstring after the signature, but it is a bit more
> complicated than that. 
> It involves sorting the overloads based on the default arguments.

Sometimes the order determines which overload is actually used. If you present
a different order it may be very difficult to figure out why things don't work
as expected. I'd stick to the given order.

> There is no customization, but I was thinking of '"" % ()' style
> formatting.

Very interesting idea.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From bso at inf.ufsc.br  Fri Jul 22 02:17:28 2005
From: bso at inf.ufsc.br (Bruno da Silva de Oliveira)
Date: Thu, 21 Jul 2005 22:17:28 -0200
Subject: [C++-sig] Pyste: Help Wanted
Message-ID: <42E03B18.90005@inf.ufsc.br>

Hi Folks,

As most of you know, I haven't had time to work on Pyste in a few 
months. The main reason is lack of time: I haven't have much free time 
left, between my work and my social life. Another reason is that I 
simply don't use it; at work we use Boost.Python extensivily, but can't 
rely on Pyste because it doesn't work very well on windows, which is our 
main development platform.

That said, I really would hate to see this project simply go to waste 
because of my lack of dedication. I would like to pass it on, if anybody 
in the Boost.Python community would like to do so. I will of course be 
avaiable to help with the current code if someone is willing to take it 
over, or support those who are starting an entire project of its own 
(I'm looking at you Roman ;)). After all, I'm not abandoning the 
community, just looking for someone to take over the project, or at 
least help applying patches and fixing bugs.

Anyway, I would like to just thank everyone in this great community, 
specially Dave, for the wonderful Boost.Python library and incentive at 
the start of the projetct. Lots of people also contributed to this 
project, in form of patchs, bug reports, etc, and I would also like to 
thank them all.

That's it. Best Regards,
Nicodemus.


From nicodemus at esss.com.br  Fri Jul 22 02:38:34 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Thu, 21 Jul 2005 22:38:34 -0200
Subject: [C++-sig] Pyste: Help Wanted
Message-ID: <42E0400A.9000300@esss.com.br>

Hi Folks,

As most of you know, I haven't had time to work on Pyste in a few
months. The main reason is lack of time: I haven't have much free time
left, between my work and my social life. Another reason is that I
simply don't use it; at work we use Boost.Python extensivily, but can't
rely on Pyste because it doesn't work very well on windows, which is our
main development platform.

That said, I really would hate to see this project simply go to waste
because of my lack of dedication. I would like to pass it on, if anybody
in the Boost.Python community would like to do so. I will of course be
avaiable to help with the current code if someone is willing to take it
over, or support those who are starting an entire project of its own
(I'm looking at you Roman ;)). After all, I'm not abandoning the
community, just looking for someone to take over the project, or at
least help applying patches and fixing bugs.

Anyway, I would like to just thank everyone in this great community,
specially Dave, for the wonderful Boost.Python library and incentive at
the start of the projetct. Lots of people also contributed to this
project, in form of patchs, bug reports, etc, and I would also like to
thank them all.

That's it. Best Regards,
Nicodemus.



From josephwinston at mac.com  Fri Jul 22 05:10:52 2005
From: josephwinston at mac.com (Joseph Winston)
Date: Thu, 21 Jul 2005 22:10:52 -0500
Subject: [C++-sig] Problems with cross module problems with current boost
	CVS, Python 2.3, OS 10.3.9, and gcc 3.3
Message-ID: <BF05CDEC.9A2%josephwinston@mac.com>

I built boost from cvs as follows:

$  bjam "-sTOOLS=darwin"

And then installed it.

But I'm having problems with the following simple program:

--- Base.hpp ---
#include <iostream>

class Base 
{
public:
   Base() 
   { 
      std::cerr << "Base()" << std::endl;
   }
   virtual ~Base() 
   { 
      std::cerr << "~Base()" << std::endl;
   }
   virtual void printMessage() const
   { 
      std::cerr << "Base instance @ " << this << std::endl;
   }
};

--- Base.cpp ---
#include "Base.hpp"
#include <boost/python.hpp>

using namespace boost::python;

BOOST_PYTHON_MODULE(Base)
{
   class_<Base>("Base", init<>())
      .def("printMessage", &Base::printMessage)
      ;
}

--- Derived.hpp ---
#include <iostream>
#include "Base.hpp"

class Derived: public Base
{
public:
   Derived(): Base()
   { 
      std::cerr << "Derived()" << std::endl;
   }
   virtual ~Derived()
   { 
      std::cerr << "~Derived()" << std::endl;
   }
   virtual void printMessage() const
   { 
      std::cerr << "Derived instance @ " << this << std::endl;
   }
};

--- Derived.cpp ---
#include "Derived.hpp"
#include <boost/python.hpp>

using namespace boost::python;

BOOST_PYTHON_MODULE(Derived)
{
   class_<Derived, bases<Base> >("Derived", init<>());
}

The two programs were compiled using:

$ g++ -fPIC -no-cpp-precomp -finline-functions -Wno-long-double
-F/System/Library/Frameworks -ftemplate-depth-256 -DBOOST_PYTHON_DYNAMIC_LIB
-fPIC 
-I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3
-I/Users/josephwinston/src/OpenAvionics/powerpc-apple-darwin7.9.0/include -c
-o Base.os Base.cpp
$ g++ -fPIC -no-cpp-precomp -finline-functions -Wno-long-double
-F/System/Library/Frameworks -ftemplate-depth-256 -DBOOST_PYTHON_DYNAMIC_LIB
-fPIC 
-I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3
-I/Users/josephwinston/src/OpenAvionics/powerpc-apple-darwin7.9.0/include -c
-o Derived.os Derived.cpp

And linked into two modules:

$ g++ -bundle -flat_namespace -undefined suppress -o Base.so Base.os -lm
-lstdc++ -ldl 
-L/Users/josephwinston/src/OpenAvionics/powerpc-apple-darwin7.9.0/lib
-lboost_python
$ g++ -bundle -flat_namespace -undefined suppress -o Derived.so Derived.os
-lm -lstdc++ -ldl 
-L/Users/josephwinston/src/OpenAvionics/powerpc-apple-darwin7.9.0/lib
-lboost_python

Loaded into python:

$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Base
>>> import Derived
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: extension class wrapper for base class Base has not been
created yet

Obviously, I'm either not building boost correctly or I'm not linking
correctly.  Does anybody see what I'm doing wrong?

Thanks
 





From seefeld at sympatico.ca  Fri Jul 22 09:27:16 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 22 Jul 2005 03:27:16 -0400
Subject: [C++-sig] which has a faster execution time?
In-Reply-To: <86afeadf05072113386ee777b6@mail.gmail.com>
References: <86afeadf05072113386ee777b6@mail.gmail.com>
Message-ID: <42E09FD4.9000704@sympatico.ca>

Scott Kaplan wrote:
> I am new to Python, but I am an experienced c++ developer.
> 
>>From the research that I have done on Python, it appears that I can
> 
> 1) Embed Python into a C++ application or
> 2) write c++ modules to extend Python
> 
> Which one, if either, will has better performance.

I don't quite understand the question. It appears you are trying
to compare apples and oranges.

The two techniques you are referring to serve quite distinct
use cases. The former is a means to provide scripting capabilities
to a C++ application, so the concern is hardly performance.
The latter lets a python application run code implemented in C++,
which typically results in much better performance compared to
the same functionality being implemented and run in python.

If you could describe what problem you are trying to solve
it might be easier to suggest what approach to take, but if
the question is strictly about how to gain performance in
a pure python environment, using C++ extension modules sounds
like a good idea.

HTH,
		Stefan


From seefeld at sympatico.ca  Fri Jul 22 09:32:38 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 22 Jul 2005 03:32:38 -0400
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <42E0400A.9000300@esss.com.br>
References: <42E0400A.9000300@esss.com.br>
Message-ID: <42E0A116.20307@sympatico.ca>

Nicodemus wrote:
> Hi Folks,
> 
> As most of you know, I haven't had time to work on Pyste in a few
> months. The main reason is lack of time: I haven't have much free time
> left, between my work and my social life. Another reason is that I
> simply don't use it; at work we use Boost.Python extensivily, but can't
> rely on Pyste because it doesn't work very well on windows, which is our
> main development platform.
> 
> That said, I really would hate to see this project simply go to waste
> because of my lack of dedication. I would like to pass it on, if anybody
> in the Boost.Python community would like to do so. I will of course be
> avaiable to help with the current code if someone is willing to take it
> over, or support those who are starting an entire project of its own
> (I'm looking at you Roman ;)). After all, I'm not abandoning the
> community, just looking for someone to take over the project, or at
> least help applying patches and fixing bugs.

I would certainly like to help to maintain pyste. As we discussed earlier,
there are a number of ideas I'd like to try out to make pyste more flexible
and independent from gccxml.

I'm not sure I'm ready / able to maintain pyste on my own, but you can
definitely count on me for a co-maintainership.

Regards,
		Stefan


From dave at boost-consulting.com  Fri Jul 22 13:48:43 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 22 Jul 2005 07:48:43 -0400
Subject: [C++-sig] Trying to clone Python object from C++ (again)
References: <200507211901.j6LJ1T0F005132@libra3.slac.stanford.edu>
	<ubr4wq7r4.fsf@boost-consulting.com>
	<200507212005.j6LK5FBU005253@libra3.slac.stanford.edu>
Message-ID: <ull3znjs4.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:

> Here's the error message I get from PyErr_Print()
>
> ReferenceError: Attempt to return dangling reference to object of type: boost::python::api::object

Right.

Have you read FAQ #1?

http://www.boost.org/libs/python/doc/v2/faq.html#dangling

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



From dave at boost-consulting.com  Fri Jul 22 13:55:01 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 22 Jul 2005 07:55:01 -0400
Subject: [C++-sig] which has a faster execution time?
References: <86afeadf05072113386ee777b6@mail.gmail.com>
Message-ID: <u1x5rnjhm.fsf@boost-consulting.com>

Scott Kaplan <pythondeveloper at gmail.com> writes:

> I am new to Python, but I am an experienced c++ developer.
>
>>From the research that I have done on Python, it appears that I can
>
> 1) Embed Python into a C++ application or
> 2) write c++ modules to extend Python
>
> Which one, if either, will has better performance.

There's no reason to think either one will be faster.

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



From dave at boost-consulting.com  Fri Jul 22 13:50:10 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 22 Jul 2005 07:50:10 -0400
Subject: [C++-sig] Pyste: Help Wanted
References: <42E03B18.90005@inf.ufsc.br>
Message-ID: <ufyu7njpp.fsf@boost-consulting.com>

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

> Hi Folks,
>
> As most of you know, I haven't had time to work on Pyste in a few 
> months. The main reason is lack of time: I haven't have much free time 
> left, between my work and my social life. Another reason is that I 
> simply don't use it; at work we use Boost.Python extensivily, but can't 
> rely on Pyste because it doesn't work very well on windows, which is our 
> main development platform.

What's the problem on Windows?

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



From dave at boost-consulting.com  Fri Jul 22 13:53:53 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 22 Jul 2005 07:53:53 -0400
Subject: [C++-sig] Problems with cross module problems with current
	boost CVS, Python 2.3, OS 10.3.9, and gcc 3.3
References: <BF05CDEC.9A2%josephwinston@mac.com>
Message-ID: <uackfnjji.fsf@boost-consulting.com>

Joseph Winston <josephwinston at mac.com> writes:

> I built boost from cvs as follows:
...
> Obviously, I'm either not building boost correctly or I'm not linking
> correctly.  Does anybody see what I'm doing wrong?

No, but:

1. as the tutorial says
   (http://boost.org/libs/python/doc/tutorial/doc/html/python/hello.html),

         Take note however that the preferred build tool for
         Boost.Python is bjam. There are so many ways to set up the
         build incorrectly. Experience shows that 90% of the "I can't
         build Boost.Python" problems come from people who had to use
         a different tool.


2. Your problem could be caused by linking with a static
   libboost_python instead of a dynamic one.

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



From dave at boost-consulting.com  Fri Jul 22 16:08:17 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 22 Jul 2005 10:08:17 -0400
Subject: [C++-sig] C++ call python class
References: <20050721131259.20574.qmail@web41003.mail.yahoo.com>
Message-ID: <ud5pbkk6m.fsf@boost-consulting.com>

Yongsheng Yang <yys2000 at yahoo.com> writes:

> hi all:
>
> Right now, I want to use C++ to call a python class.
> There is a sample or tutorial here?

    // Retrieve the Python module called "some_module"
    python::object some_module((
        python::handle<>(python::borrowed(PyImport_AddModule("some_module")))));

    python::object some_class = some_module.attr("some_class");

    // assuming __init__ takes only a "self" argument
    python::object instance_of_some_class = some_class();

    // call instance_of_some_class.foo(3.14)
    instance_of_some_class.attr("foo")(3.14);

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



From Paul_Kunz at slac.stanford.edu  Fri Jul 22 17:05:59 2005
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Fri, 22 Jul 2005 08:05:59 -0700
Subject: [C++-sig] Trying to clone Python object from C++ (again)
In-Reply-To: <ull3znjs4.fsf@boost-consulting.com> (message from David Abrahams
	on Fri, 22 Jul 2005 07:48:43 -0400)
References: <200507211901.j6LJ1T0F005132@libra3.slac.stanford.edu>
	<ubr4wq7r4.fsf@boost-consulting.com>
	<200507212005.j6LK5FBU005253@libra3.slac.stanford.edu>
	<ull3znjs4.fsf@boost-consulting.com>
Message-ID: <200507221505.j6MF5xhK008017@libra3.slac.stanford.edu>

>>>>> On Fri, 22 Jul 2005 07:48:43 -0400, David Abrahams <dave at boost-consulting.com> said:

> "Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:
>> Here's the error message I get from PyErr_Print()
>> 
>> ReferenceError: Attempt to return dangling reference to object of
>> type: boost::python::api::object

> Right.

> Have you read FAQ #1?

> http://www.boost.org/libs/python/doc/v2/faq.html#dangling

   I have now, thanks for the pointer.   Actually, it is #2.

   Anyway, I found an alternative to what was trying to be
accomplished, so I don't need this clone() function anymore.

   Thanks again for your help.


From nickm at sitius.com  Fri Jul 22 18:22:31 2005
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 22 Jul 2005 12:22:31 -0400
Subject: [C++-sig] Boost.Python.function.__signatures__
References: <20050721204715.12268.qmail@web31507.mail.mud.yahoo.com>
Message-ID: <42E11D47.77785809@sitius.com>



"Ralf W. Grosse-Kunstleve" wrote:
> 
> --- Nikolay Mladenov <nickm at sitius.com> wrote:
> > > Are you appending or prepending? Can this be customized? (Not that I think
> > > customization is very important; I am just wondering.)
> >
> > I am appending the docstring after the signature, but it is a bit more
> > complicated than that.
> > It involves sorting the overloads based on the default arguments.
> 
> Sometimes the order determines which overload is actually used. If you present
> a different order it may be very difficult to figure out why things don't work
> as expected. I'd stick to the given order.

Don't you think relying on the order of overloads is a problem by
itself?

I do the sorting so I can write:
func( arg1 [, arg2 [, arg3[ ...]]]])
instead of n lines with one arg difference.
And I do not reorder the overloads.

Nikolay


From petrucio at hoplon.com  Fri Jul 22 18:25:37 2005
From: petrucio at hoplon.com (Petrucio)
Date: Fri, 22 Jul 2005 13:25:37 -0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <ufyu7njpp.fsf@boost-consulting.com>
References: <42E03B18.90005@inf.ufsc.br> <ufyu7njpp.fsf@boost-consulting.com>
Message-ID: <6.0.2.0.1.20050722132024.01b71700@mail.hoplon.com>

At 08:50 22/7/2005, you wrote:
>Bruno da Silva de Oliveira <bso at inf.ufsc.br> writes:
>
> > Hi Folks,
> >
> > As most of you know, I haven't had time to work on Pyste in a few
> > months. The main reason is lack of time: I haven't have much free time
> > left, between my work and my social life. Another reason is that I
> > simply don't use it; at work we use Boost.Python extensivily, but can't
> > rely on Pyste because it doesn't work very well on windows, which is our
> > main development platform.
>
>What's the problem on Windows?

gccxml has problems parsing more complex header files, like std::xyz headers,
windows headers, or even Boost.Python header files.

You could parse them under Linux and compile the resulting Boost.Python
wrappers in Windows, but that isn't very practical.

Bruno, tinha me esquecido de ti: formatura minha dia 30 de Julho, nao vai
rolar baile, mas depois da cola??o vou fazer um super churras no Paula
Ramos, tais afim?

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



From rwgk at yahoo.com  Fri Jul 22 22:15:57 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 22 Jul 2005 13:15:57 -0700 (PDT)
Subject: [C++-sig] Boost.Python.function.__signatures__
In-Reply-To: <42E11D47.77785809@sitius.com>
Message-ID: <20050722201558.36812.qmail@web31502.mail.mud.yahoo.com>

--- Nikolay Mladenov <nickm at sitius.com> wrote:
> Don't you think relying on the order of overloads is a problem by
> itself?

Well, yes, but that's the way Boost.Python works at the moment, and I had a few
situations where I had to get the order right to achieve what I wanted.

> I do the sorting so I can write:
> func( arg1 [, arg2 [, arg3[ ...]]]])
> instead of n lines with one arg difference.
> And I do not reorder the overloads.

That's very nice, but couldn't you also do this without sorting? In most cases
you'd probably get the same result anyway, but you wouldn't undo the work
someone may have done in ordering the overloads.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From dave at boost-consulting.com  Fri Jul 22 23:00:36 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 22 Jul 2005 17:00:36 -0400
Subject: [C++-sig] Pyste: Help Wanted
References: <42E03B18.90005@inf.ufsc.br> <ufyu7njpp.fsf@boost-consulting.com>
	<6.0.2.0.1.20050722132024.01b71700@mail.hoplon.com>
Message-ID: <u4qamfte3.fsf@boost-consulting.com>

Petrucio <petrucio at hoplon.com> writes:

> At 08:50 22/7/2005, you wrote:
>>Bruno da Silva de Oliveira <bso at inf.ufsc.br> writes:
>>
>> > Hi Folks,
>> >
>> > As most of you know, I haven't had time to work on Pyste in a few
>> > months. The main reason is lack of time: I haven't have much free time
>> > left, between my work and my social life. Another reason is that I
>> > simply don't use it; at work we use Boost.Python extensivily, but can't
>> > rely on Pyste because it doesn't work very well on windows, which is our
>> > main development platform.
>>
>>What's the problem on Windows?
>
> gccxml has problems parsing more complex header files, like std::xyz
> headers,

I don't know what you mean by those.

> windows headers, 

Because they use nonstandard constructs?

> or even Boost.Python header files.

That makes no sense.  Cygwing/MingW GCC parses Boost.Python just
fine.  What gives?

> You could parse them under Linux 

I don't see how that could help, especially not with the windows
headers if I've guessed the problem correctly.

> and compile the resulting Boost.Python wrappers in Windows, but that
> isn't very practical.

No it isn't.

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



From petrucio at hoplon.com  Fri Jul 22 23:24:36 2005
From: petrucio at hoplon.com (Petrucio)
Date: Fri, 22 Jul 2005 18:24:36 -0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <u4qamfte3.fsf@boost-consulting.com>
References: <42E03B18.90005@inf.ufsc.br> <ufyu7njpp.fsf@boost-consulting.com>
	<6.0.2.0.1.20050722132024.01b71700@mail.hoplon.com>
	<u4qamfte3.fsf@boost-consulting.com>
Message-ID: <6.0.2.0.1.20050722181040.01b2b958@mail.hoplon.com>

At 18:00 22/7/2005, you wrote:
>Petrucio <petrucio at hoplon.com> writes:
>
> > At 08:50 22/7/2005, you wrote:
> >>Bruno da Silva de Oliveira <bso at inf.ufsc.br> writes:
> >>
> >> > Hi Folks,
> >> >
> >> > As most of you know, I haven't had time to work on Pyste in a few
> >> > months. The main reason is lack of time: I haven't have much free time
> >> > left, between my work and my social life. Another reason is that I
> >> > simply don't use it; at work we use Boost.Python extensivily, but can't
> >> > rely on Pyste because it doesn't work very well on windows, which is our
> >> > main development platform.
> >>
> >>What's the problem on Windows?
> >
> > gccxml has problems parsing more complex header files, like std::xyz
> > headers,
>
>I don't know what you mean by those.

<vector>, <map>, <string>, etc.


> > windows headers,
>
>Because they use nonstandard constructs?

Not sure why, didn't investigate. But couldn't parse them.


> > or even Boost.Python header files.
>
>That makes no sense.  Cygwing/MingW GCC parses Boost.Python just
>fine.  What gives?

I didn't try to parse those, this is something Nicodemus told me he 
happened to him, you'd have to ask him.


> > You could parse them under Linux
>
>I don't see how that could help, especially not with the windows
>headers if I've guessed the problem correctly.

No, not with the windows ones, but would help with the std headers, which 
were my case.


> > and compile the resulting Boost.Python wrappers in Windows, but that
> > isn't very practical.
>
>No it isn't.
>
>--
>Dave Abrahams
>Boost Consulting
>www.boost-consulting.com
>
>_______________________________________________
>C++-sig mailing list
>C++-sig at python.org
>http://mail.python.org/mailman/listinfo/c++-sig



From Paul_Kunz at slac.stanford.edu  Sat Jul 23 02:38:41 2005
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Fri, 22 Jul 2005 17:38:41 -0700
Subject: [C++-sig] How to tell in member function exists in Python class
Message-ID: <200507230038.j6N0cfKQ011443@libra3.slac.stanford.edu>

I have a virtual C++ base class which I"m exposing to Python so that
derived classes can be written in Python.   Some virtual functions may
be overriden in Python and some not.   So in my C++ class which makes
the interface between Pyton and C++, I would like to test if the
Python class  has implemented a member function or not.   I've done
the following, following Dave Abrahams' advice on a previous topic...

unsigned int
FunctionWrap::
dimensions () const
{
  unsigned int dims = 0;

  if ( override member = this -> get_override ( "dimensions" ) ) {
    dims = member(); // calls the Python function
  }
  else { // didn't override it
    dims = FunctionBase::dimensions (); // calls the C++ base class
  }
  return dims;
}

This works.   But, I can't find `get_override()' in the Boost.Python
documeenation.    Maybe I miessed it.   But if not, what should I be
using to test if the Python member function has been implemented?


From nickm at sitius.com  Sat Jul 23 04:37:30 2005
From: nickm at sitius.com (Nikolay Mladenov)
Date: Fri, 22 Jul 2005 22:37:30 -0400
Subject: [C++-sig] Boost.Python.function.__signatures__
References: <42E11D47.77785809@sitius.com>
	<20050722201558.36812.qmail@web31502.mail.mud.yahoo.com>
Message-ID: <42E1AD6A.C372EB9E@sitius.com>



"Ralf W. Grosse-Kunstleve" wrote:
> 
> --- Nikolay Mladenov <nickm at sitius.com> wrote:
> > Don't you think relying on the order of overloads is a problem by
> > itself?
> 
> Well, yes, but that's the way Boost.Python works at the moment, and I had a few
> situations where I had to get the order right to achieve what I wanted.
> 
> > I do the sorting so I can write:
> > func( arg1 [, arg2 [, arg3[ ...]]]])
> > instead of n lines with one arg difference.
> > And I do not reorder the overloads.
> 
> That's very nice, but couldn't you also do this without sorting? In most cases
> you'd probably get the same result anyway, but you wouldn't undo the work
> someone may have done in ordering the overloads.

Yes, you are probably right. I will see if I can remove the sorting. I
have to check how 
the overload generators order their overloads(they should be with
increasing number of args).
But in all cases the sorting is not really mandatory, although it is
nice.

I have also used the ordering to achieve better performance, but I never
had a case where 
the ordering affects the logical behavior.


Nikolay



From s_sourceforge at nedprod.com  Sat Jul 23 13:13:53 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 23 Jul 2005 12:13:53 +0100
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <42E0A116.20307@sympatico.ca>
References: <42E0400A.9000300@esss.com.br>
Message-ID: <42E23481.10869.493B1@localhost>

On 22 Jul 2005 at 3:32, Stefan Seefeld wrote:

> > As most of you know, I haven't had time to work on Pyste in a few
> > months. The main reason is lack of time: I haven't have much free
> > time left, between my work and my social life. Another reason is
> > that I simply don't use it; at work we use Boost.Python extensivily,
> > but can't rely on Pyste because it doesn't work very well on
> > windows, which is our main development platform.

Can't say I've noticed any difference between Windows and Unix for 
pyste. Works just fine on both.

> > That said, I really would hate to see this project simply go to
> > waste because of my lack of dedication. I would like to pass it on,
> > if anybody in the Boost.Python community would like to do so. I will
> > of course be avaiable to help with the current code if someone is
> > willing to take it over, or support those who are starting an entire
> > project of its own (I'm looking at you Roman ;)). After all, I'm not
> > abandoning the community, just looking for someone to take over the
> > project, or at least help applying patches and fixing bugs.
> 
> I would certainly like to help to maintain pyste. As we discussed
> earlier, there are a number of ideas I'd like to try out to make pyste
> more flexible and independent from gccxml.
> 
> I'm not sure I'm ready / able to maintain pyste on my own, but you can
> definitely count on me for a co-maintainership.

As you may have noticed, I have been independently patching pyste to 
add things for a while now. You can always get the latest version of 
my pyste from SVN at http://www.nedprod.com/TnFOX/ (look for 
BoostPatches.zip in the Python directory).

Cheers,
Niall





From roman.yakovenko at gmail.com  Sun Jul 24 06:42:47 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 24 Jul 2005 07:42:47 +0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <42E0400A.9000300@esss.com.br>
References: <42E0400A.9000300@esss.com.br>
Message-ID: <7465b617050723214222186f0e@mail.gmail.com>

On 7/22/05, Nicodemus <nicodemus at esss.com.br> wrote:
> Hi Folks,
> 
> As most of you know, I haven't had time to work on Pyste in a few
> months. The main reason is lack of time: I haven't have much free time
> left, between my work and my social life. Another reason is that I
> simply don't use it; at work we use Boost.Python extensivily, but can't
> rely on Pyste because it doesn't work very well on windows, which is our
> main development platform.

Nicodemus, I would like to say thank you for your efforts. Without Pyste
my job was harder. Yes Pyste has a few points that could be improved. 
One of them is back-end. Could you to be more explicit about the problems
with GCC-XML? By the way, the idea to add additional back-end, is not
bad at all.
I though about this and desided: I am going to add an other back-end
to my project,
based on Microsoft bsc files. 

> That said, I really would hate to see this project simply go to waste
> because of my lack of dedication. I would like to pass it on, if anybody
> in the Boost.Python community would like to do so. I will of course be
> avaiable to help with the current code if someone is willing to take it
> over, or support those who are starting an entire project of its own
> (I'm looking at you Roman ;)). After all, I'm not abandoning the
> community, just looking for someone to take over the project, or at
> least help applying patches and fixing bugs.

May be you don't know but you are helping continuously: 
1. mailing list have a lot of threads about improving pyste
2. Pyste code contains a lot of usefull ideas
 
> Anyway, I would like to just thank everyone in this great community,
> specially Dave, for the wonderful Boost.Python library and incentive at
> the start of the projetct. Lots of people also contributed to this
> project, in form of patchs, bug reports, etc, and I would also like to
> thank them all.
>
> That's it. Best Regards,
> Nicodemus.

Roman Yakovenko


From dave at boost-consulting.com  Sun Jul 24 10:53:34 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 24 Jul 2005 04:53:34 -0400
Subject: [C++-sig] Pyste: Help Wanted
References: <42E0400A.9000300@esss.com.br>
	<7465b617050723214222186f0e@mail.gmail.com>
Message-ID: <u4qak8u0h.fsf@boost-consulting.com>

Roman Yakovenko <roman.yakovenko at gmail.com> writes:

> Nicodemus, I would like to say thank you for your efforts.

Indeed!  Without Pyste, Boost.Python would not be nearly as popular as
it is today.  Pyste also acts as a great instructor in the use of
Boost.Python itself.  Thanks for everything (so far), Nicodemus.

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



From ericjardim at gmail.com  Mon Jul 25 02:23:43 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Sun, 24 Jul 2005 21:23:43 -0300
Subject: [C++-sig] Automatic argument conversion
Message-ID: <432ec6c5050724172349cb92f8@mail.gmail.com>

Hi,
this may be easy to do, but I don't know how to acomplish it.

If i have a function like:

void
 SomeClass::my_print(std::string s)
{
 std::cout << s << std::endl;
}

And if I declare inside the module:

class_<SomeClass>("SomeClas")
.def ("my_print", my_print)

it will work correctly, because Boost.Python know how (somehow) to convert 
"std::string"s to Python "str" strings and vice-versa.
So in python shell:
>>> import m
>>> c = m.SomeClass()
>>> c.my_print('Eric')
Eric

But if I have a function, like that one, but instead of a known type I have 
another string type:

void
SomeClass::my_print(const QString& s)
{
...
}

How do I say to Boost.Python that everytime it sees a "QString" argument, 
and it have a Python "str", I can apply a simple converter, just like 
"std::string"?

By now, all I can do is write wrappers to method and do the converstion 
manually.
Ex:

void
 SomeClassWrapper::my_print(std::string s)
{
 SomeClass::my_print(QString::fromStdString(s));
 ...
}

Besides, I did not find in the rerefence manual a way to it. I was looking 
at the Boost.Python include directories for this kind of conversion and 
found a interesting named dir:
/usr/include/boost/python/converter/

But then, I realised that these headers are not all documented. Is it right, 
or I did not searched correctly?

Thanks for any help.

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050724/e41c8640/attachment.htm>

From ericjardim at gmail.com  Mon Jul 25 12:40:59 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 25 Jul 2005 07:40:59 -0300
Subject: [C++-sig] One object, many references
Message-ID: <432ec6c50507250340556d4226@mail.gmail.com>

Hi,

I have wrapped some classes of the Qt4 library and some funny things 
happend.

For example. The classic QObject class. You can create some QObjects, and 
say if they have a parent or not. Its parent is another QObject. (the memory 
addresses are ficticious):

>>> from Qt import QObject
>>> a = QObject(None) # have no parent
>>> b = QObject(a) # a is the parent
>>> a
<Qt.QObject at '0x00000001'>
>>> b
<Qt.QObject at '0x00000002'>
>>> print a.parent()
None
>>> print b.parent()
<Qt.QObject at '0x00000003'>

The funny is that it is another python object representing the same C++ 
object. If I do this (objectName is a property with setter and getter):
>>> a.objectName = QString('Eric')
>>> QString_to_str(print b.parent.objectName)
'Eric'

So it is the same object. Why does this happens? I have tried many 
combinations (but not all) of return value policies but lead to the same 
thing. Sometimes when the Python shell closes it segfaults.

Is this intended to be like this? How do I assure that the objects are the 
same? Overload the "==" operator?

Thanks in advance.

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050725/5f19d177/attachment.htm>

From roman.yakovenko at gmail.com  Mon Jul 25 13:02:11 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 25 Jul 2005 14:02:11 +0300
Subject: [C++-sig] py++ status
Message-ID: <7465b617050725040234e6c616@mail.gmail.com>

Hi. In light of the recent event ( see posting "Pyste: Help Wanted" ) 
I decided to report status of py++ project.

First of all what is this?
py++ is a framework of components for creating C++ code generator for 
boost.python library.

What is the status? 
py++ has reached the state when it has something to propose to an user. 
py++ has:
    introduction guide
    unit tests
    example. 
As an example I choose to expose Trolltech Qt4 QtXml module. It was
pretty easy.
Use this link http://pygccxml.sourceforge.net/pyplusplus/py++.html to read more 
about py++ and to see the example.

What it does not have ( main futures ):
1. py++ does not allow the user to override virtual functions from Python
   for exported classes, i.e. py++ does not create a wrapper class for
   exported classes

2. py++ does not have multiple files mode, as Pyste has.


Key Features:

1. py++ is Python package, hence
    1. An user uses Python language to express/create code generation process. 
    2. Easy integration between processes.    

2. py++ does not involved in parsing C++ files ==> an other back-end could be 
   added, without modifying py++ sources. For example Microsoft bsc
files reader
   or synopsis parser. 

3. py++ has clear separation between different functionalities: 
        code creators - what code should be created in order to export some C++ 
                        declaration. 
                        
        module creator - what could be exported and what is the order
of exported
                         declarations. Example base class should be exported 
                         before its derived. Function that takes as argument a 
                         pointer to function could not be exported
                         
        file creators - classes that use different strategy to create files 
                        on disk
                        
4. py++ allows easy integration between user hand written and generated code.

5. py++ has a lot of futures that allows generated code to look like human 
   written code.
   
6. py++ can have some nice GUI, that will guide user through code generation 
   process.
   
What about Pyste? I think that in a few months I will have all functionality 
that Pyste has in py++. So I prefer not to invest my time into Pyste. 

Ideas, comments, suggestions or help are welcomed.

Roman Yakovenko


From s_sourceforge at nedprod.com  Mon Jul 25 13:52:52 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 25 Jul 2005 12:52:52 +0100
Subject: [C++-sig] One object, many references
In-Reply-To: <432ec6c50507250340556d4226@mail.gmail.com>
Message-ID: <42E4E0A4.10145.5A941C@localhost>

On 25 Jul 2005 at 7:40, Eric Jardim wrote:

> I have wrapped some classes of the Qt4 library and some funny things
> happend.

For all these kinds of questions, please see how the TnFOX library 
does it at http://www.nedprod.com/TnFOX. It wraps an extensive GUI 
toolkit library, some of whose API is identical to Qt as it happens. 
It also shows how to wrap QString, and the QTL such that they appear 
as python strings and python native containers.

Cheers,
Niall





From nicodemus at esss.com.br  Mon Jul 25 14:11:53 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 25 Jul 2005 09:11:53 -0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <42E23481.10869.493B1@localhost>
References: <42E0400A.9000300@esss.com.br> <42E23481.10869.493B1@localhost>
Message-ID: <42E4D709.3060403@esss.com.br>

Niall Douglas wrote:

>On 22 Jul 2005 at 3:32, Stefan Seefeld wrote:
>
>  
>
>>>As most of you know, I haven't had time to work on Pyste in a few
>>>months. The main reason is lack of time: I haven't have much free
>>>time left, between my work and my social life. Another reason is
>>>that I simply don't use it; at work we use Boost.Python extensivily,
>>>but can't rely on Pyste because it doesn't work very well on
>>>windows, which is our main development platform.
>>>      
>>>
>
>Can't say I've noticed any difference between Windows and Unix for 
>pyste. Works just fine on both.
>  
>

I have, unfortunately. Trying to simply parse <boost/python.hpp> gives a 
ton of errors. I can't say why thought.

>As you may have noticed, I have been independently patching pyste to 
>add things for a while now. You can always get the latest version of 
>my pyste from SVN at http://www.nedprod.com/TnFOX/ (look for 
>BoostPatches.zip in the Python directory).
>  
>

I did. Thanks for the always appreciated patches Niall!

Regards,
Nicodemus.


From nicodemus at esss.com.br  Mon Jul 25 14:12:44 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 25 Jul 2005 09:12:44 -0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <42E0A116.20307@sympatico.ca>
References: <42E0400A.9000300@esss.com.br> <42E0A116.20307@sympatico.ca>
Message-ID: <42E4D73C.9030801@esss.com.br>

Stefan Seefeld wrote:

>I would certainly like to help to maintain pyste. As we discussed earlier,
>there are a number of ideas I'd like to try out to make pyste more flexible
>and independent from gccxml.
>  
>

Stefan, any help will certainly be appreciated. Email me privately so we 
can discuss this.

Best Regards,
Nicodemus.


From nicodemus at esss.com.br  Mon Jul 25 14:16:48 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 25 Jul 2005 09:16:48 -0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <7465b617050723214222186f0e@mail.gmail.com>
References: <42E0400A.9000300@esss.com.br>
	<7465b617050723214222186f0e@mail.gmail.com>
Message-ID: <42E4D830.3070507@esss.com.br>



Roman Yakovenko wrote:

>One of them is back-end. Could you to be more explicit about the problems
>with GCC-XML? By the way, the idea to add additional back-end, is not
>bad at all.
>I though about this and desided: I am going to add an other back-end
>to my project,
>based on Microsoft bsc files. 
>  
>

Yes, Stefan contacted me with this idea. He works on the Synopsis 
project, and it would be nice to run Pyste on top of it.


Roman, thanks for your always appreciated support, and good luck with 
py++: looking forward to it!

Regards,
Nicodemus.


From nicodemus at esss.com.br  Mon Jul 25 14:19:32 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 25 Jul 2005 09:19:32 -0300
Subject: [C++-sig] Pyste: Help Wanted
In-Reply-To: <u4qamfte3.fsf@boost-consulting.com>
References: <42E03B18.90005@inf.ufsc.br>
	<ufyu7njpp.fsf@boost-consulting.com>	<6.0.2.0.1.20050722132024.01b71700@mail.hoplon.com>
	<u4qamfte3.fsf@boost-consulting.com>
Message-ID: <42E4D8D4.3000701@esss.com.br>



David Abrahams wrote:

>That makes no sense.  Cygwing/MingW GCC parses Boost.Python just
>fine.  What gives?
>  
>

I have no idea why David; but I remember simply trying to parse 
<boost/python.hpp> directly on the command line, and it wouldn't work, 
giving tons of errors. I don't have gccxml here at work, so I can't post 
the errors. I will do that when I get home.

Regards,
Nicodemus.


From sheig222 at gmail.com  Mon Jul 25 14:45:11 2005
From: sheig222 at gmail.com (Ira)
Date: Mon, 25 Jul 2005 15:45:11 +0300
Subject: [C++-sig] std streams!?
Message-ID: <dc2msa$gbr$1@sea.gmane.org>

Hi,

What I'm attempting to do is build some sort of demo that uses my company's
MFC/GDI based window/gui MMI and generate evrerything from script via
python.

I have a basic MFC dialog app that holds an instance for the MMI and a
python interpreter.

Now when I give the interpreter jobs to do it may result in an exception at
which point I wish to call PyErr_Print(). As I understand this is suppose to
go to the console but I don't *have* a console. I added a console with
win32's AllocateConsole() and although I can write errors in there
PyErr_Print() still doesn't do what I think it's suppose to.

Am I missing something?
does PyErr_Print() write to stderr?
How can I change the python output streams (If I can do that then I think my
problem is solved).

Thanks,
Ira






From sheig222 at gmail.com  Mon Jul 25 14:45:11 2005
From: sheig222 at gmail.com (Ira)
Date: Mon, 25 Jul 2005 15:45:11 +0300
Subject: [C++-sig] std streams!?
Message-ID: <dc2mto$gi9$1@sea.gmane.org>

Hi,

What I'm attempting to do is build some sort of demo that uses my company's
MFC/GDI based window/gui MMI and generate evrerything from script via
python.

I have a basic MFC dialog app that holds an instance for the MMI and a
python interpreter.

Now when I give the interpreter jobs to do it may result in an exception at
which point I wish to call PyErr_Print(). As I understand this is suppose to
go to the console but I don't *have* a console. I added a console with
win32's AllocateConsole() and although I can write errors in there
PyErr_Print() still doesn't do what I think it's suppose to.

Am I missing something?
does PyErr_Print() write to stderr?
How can I change the python output streams (If I can do that then I think my
problem is solved).

Thanks,
Ira






From rwgk at yahoo.com  Mon Jul 25 15:04:14 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 25 Jul 2005 06:04:14 -0700 (PDT)
Subject: [C++-sig] Automatic argument conversion
In-Reply-To: <432ec6c5050724172349cb92f8@mail.gmail.com>
Message-ID: <20050725130414.30783.qmail@web31512.mail.mud.yahoo.com>

Hi Eric,

--- Eric Jardim <ericjardim at gmail.com> wrote:

> it will work correctly, because Boost.Python know how (somehow) to convert 
> "std::string"s to Python "str" strings and vice-versa.

Boost.Python comes with built-in converters for the C++ built-in types and a
few other types like std::string and std::complex<> with a Python counterpart.

> But if I have a function, like that one, but instead of a known type I have 
> another string type:
> 
> void
> SomeClass::my_print(const QString& s)
> {
> ...
> }
> 
> How do I say to Boost.Python that everytime it sees a "QString" argument, 
> and it have a Python "str", I can apply a simple converter, just like 
> "std::string"?

I think this will answer your question:

http://mail.python.org/pipermail/c++-sig/2003-May/004133.html

Cheers,
        Ralf



		
__________________________________ 
Yahoo! Mail for Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 


From seefeld at sympatico.ca  Mon Jul 25 15:18:35 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 25 Jul 2005 09:18:35 -0400
Subject: [C++-sig] py++ status
In-Reply-To: <7465b617050725040234e6c616@mail.gmail.com>
References: <7465b617050725040234e6c616@mail.gmail.com>
Message-ID: <42E4E6AB.7090505@sympatico.ca>

Roman Yakovenko wrote:

> What about Pyste? I think that in a few months I will have all functionality 
> that Pyste has in py++. So I prefer not to invest my time into Pyste. 

What about the users who invested into their code and build system relying on pyste ?

While the features you mention seem to me quite worthwhile, I'm not sure such a
list alone is reason enough for people to switch. Is there no way to enhance pyste
itself to sport the same features you mention ?
What about the underlaying design ? How does that compare to that of pyste ?

I'm certainly going to look at py++, at least for inspiration. It would be
interesting to know how big pyste's user base is, and what could be done to
mitigate any changes that are imposed on users, i.e. how to provide a smooth
migration path, if possible.

Regards,
		Stefan



From roman.yakovenko at gmail.com  Mon Jul 25 17:27:48 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 25 Jul 2005 18:27:48 +0300
Subject: [C++-sig] py++ status
In-Reply-To: <42E4E6AB.7090505@sympatico.ca>
References: <7465b617050725040234e6c616@mail.gmail.com>
	<42E4E6AB.7090505@sympatico.ca>
Message-ID: <7465b617050725082734bedd48@mail.gmail.com>

On 7/25/05, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Roman Yakovenko wrote:
> 
> > What about Pyste? I think that in a few months I will have all functionality
> > that Pyste has in py++. So I prefer not to invest my time into Pyste.
> 
> What about the users who invested into their code and build system relying on pyste ?

I thought about it. And here is my plan:
Pyste scripts is python scripts. I can implement all Pyste interface
functions using
py++. The question is, as you already asked, how big pyste's user base is ?

> While the features you mention seem to me quite worthwhile, I'm not sure such a
> list alone is reason enough for people to switch.

My personal opinion on this subject is: does current software work for you ? 
If the answer is yes, then don't change it. If the answer is no, then ...

> Is there no way to enhance pyste itself to sport the same features you mention ?

Yes, there is such way, but is not as simple as it seems.

> What about the underlaying design ? How does that compare to that of pyste ?

py++ does not depend on C++ parser, Pyste integrated with GCC-XML parser
If we take for example ClassExporter class from Pyste, then this class
has next responsibilities:
     1. to define the order of classes to be exported
     2. It knows everything about internal declarations, that should be exported

Pyste, also does not have clear separation between code creation and
code dumping
to file. This is one of the reason why this is so difficult to
implement multiple file mode.

In py++ code_creators.class_t has only one responsibility: to create code.
There is an other package, that is responsible to save code within files.

I can continue the list.

> I'm certainly going to look at py++, at least for inspiration. It would be
> interesting to know how big pyste's user base is, and what could be done to
> mitigate any changes that are imposed on users, i.e. how to provide a smooth
> migration path, if possible.
> 
> Regards,
>                 Stefan

Roman Yakovenko.


From pythondeveloper at gmail.com  Mon Jul 25 17:45:02 2005
From: pythondeveloper at gmail.com (Scott Kaplan)
Date: Mon, 25 Jul 2005 11:45:02 -0400
Subject: [C++-sig] which has a faster execution time?
In-Reply-To: <42E09FD4.9000704@sympatico.ca>
References: <86afeadf05072113386ee777b6@mail.gmail.com>
	<42E09FD4.9000704@sympatico.ca>
Message-ID: <86afeadf05072508452ddf8f3e@mail.gmail.com>

Thanks Stefan.  The more I think about it, it doesn't really make
sense to talk about a C++ app when developing a website.  It makes
more sense to write C++ to extend Python.

On 7/22/05, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Scott Kaplan wrote:
> > I am new to Python, but I am an experienced c++ developer.
> >
> >>From the research that I have done on Python, it appears that I can
> >
> > 1) Embed Python into a C++ application or
> > 2) write c++ modules to extend Python
> >
> > Which one, if either, will has better performance.
> 
> I don't quite understand the question. It appears you are trying
> to compare apples and oranges.
> 
> The two techniques you are referring to serve quite distinct
> use cases. The former is a means to provide scripting capabilities
> to a C++ application, so the concern is hardly performance.
> The latter lets a python application run code implemented in C++,
> which typically results in much better performance compared to
> the same functionality being implemented and run in python.
> 
> If you could describe what problem you are trying to solve
> it might be easier to suggest what approach to take, but if
> the question is strictly about how to gain performance in
> a pure python environment, using C++ extension modules sounds
> like a good idea.
> 
> HTH,
>                Stefan
>


From pythondeveloper at gmail.com  Mon Jul 25 17:48:42 2005
From: pythondeveloper at gmail.com (Scott Kaplan)
Date: Mon, 25 Jul 2005 11:48:42 -0400
Subject: [C++-sig] which has a faster execution time?
In-Reply-To: <u1x5rnjhm.fsf@boost-consulting.com>
References: <86afeadf05072113386ee777b6@mail.gmail.com>
	<u1x5rnjhm.fsf@boost-consulting.com>
Message-ID: <86afeadf0507250848483f29c2@mail.gmail.com>

Thanks Dave.  I had a suspicion that was the answer and it makes sense.

On 7/22/05, David Abrahams <dave at boost-consulting.com> wrote:
> Scott Kaplan <pythondeveloper at gmail.com> writes:
> 
> > I am new to Python, but I am an experienced c++ developer.
> >
> >>From the research that I have done on Python, it appears that I can
> >
> > 1) Embed Python into a C++ application or
> > 2) write c++ modules to extend Python
> >
> > Which one, if either, will has better performance.
> 
> There's no reason to think either one will be faster.
> 
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>


From dave at boost-consulting.com  Mon Jul 25 20:22:58 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 25 Jul 2005 14:22:58 -0400
Subject: [C++-sig] std streams!?
References: <dc2mto$gi9$1@sea.gmane.org>
Message-ID: <uwtnelp8d.fsf@boost-consulting.com>

"Ira" <sheig222 at gmail.com> writes:

> Hi,
>
> What I'm attempting to do is build some sort of demo that uses my company's
> MFC/GDI based window/gui MMI and generate evrerything from script via
> python.
>
> I have a basic MFC dialog app that holds an instance for the MMI and a
> python interpreter.
>
> Now when I give the interpreter jobs to do it may result in an exception at
> which point I wish to call PyErr_Print(). As I understand this is suppose to
> go to the console but I don't *have* a console. I added a console with
> win32's AllocateConsole() and although I can write errors in there
> PyErr_Print() still doesn't do what I think it's suppose to.
>
> Am I missing something?
> does PyErr_Print() write to stderr?
> How can I change the python output streams (If I can do that then I think my
> problem is solved).

Suggestion: since this is not Python/C++-specific, you might get
better help in the regular python-list (same as comp.lang.python).

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



From dave at boost-consulting.com  Mon Jul 25 20:24:03 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 25 Jul 2005 14:24:03 -0400
Subject: [C++-sig] Automatic argument conversion
References: <432ec6c5050724172349cb92f8@mail.gmail.com>
	<20050725130414.30783.qmail@web31512.mail.mud.yahoo.com>
Message-ID: <ur7dmlp6k.fsf@boost-consulting.com>

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

> I think this will answer your question:
>
> http://mail.python.org/pipermail/c++-sig/2003-May/004133.html

Hey, Ralf, do you think this would make a good FAQ? (hinty-hinty) ;-)
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From rwgk at yahoo.com  Mon Jul 25 21:38:00 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 25 Jul 2005 12:38:00 -0700 (PDT)
Subject: [C++-sig] Automatic argument conversion
In-Reply-To: <ur7dmlp6k.fsf@boost-consulting.com>
Message-ID: <20050725193801.75516.qmail@web31506.mail.mud.yahoo.com>

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

> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > I think this will answer your question:
> >
> > http://mail.python.org/pipermail/c++-sig/2003-May/004133.html
> 
> Hey, Ralf, do you think this would make a good FAQ? (hinty-hinty) ;-)

Actually, it is there already (I forgot ...):

http://www.boost.org/libs/python/doc/v2/faq.html#custom_string


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From ericjardim at gmail.com  Mon Jul 25 23:29:22 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 25 Jul 2005 18:29:22 -0300
Subject: [C++-sig] One object, many references
In-Reply-To: <42E4E0A4.10145.5A941C@localhost>
References: <432ec6c50507250340556d4226@mail.gmail.com>
	<42E4E0A4.10145.5A941C@localhost>
Message-ID: <432ec6c505072514295ae57d01@mail.gmail.com>

2005/7/25, Niall Douglas <s_sourceforge at nedprod.com>:
> 
> For all these kinds of questions, please see how the TnFOX library
> does it at http://www.nedprod.com/TnFOX. It wraps an extensive GUI
> toolkit library, some of whose API is identical to Qt as it happens.
> It also shows how to wrap QString, and the QTL such that they appear
> as python strings and python native containers.
> 

Oh, thanks!

I'll study it!

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050725/e21f78e9/attachment.htm>

From alexander.borghgraef.rma at gmail.com  Tue Jul 26 11:28:49 2005
From: alexander.borghgraef.rma at gmail.com (Alexander Borghgraef)
Date: Tue, 26 Jul 2005 11:28:49 +0200
Subject: [C++-sig] Error message: undefined reference to '_Py_NoneStruct'
Message-ID: <9e8c52a2050726022824d39fa@mail.gmail.com>

Hi all,

 I'm new to using boost.python, so I'm just trying out the library at
the moment. Unfortunately, things are going wrong at the very
beginning. I made a little hello world program, which included, but
didn't use boost/python.hpp, and as a result I get the following error
messages:

/usr/include/boost/python/object_core.hpp:424: undefined reference to
`_Py_NoneStruct'
/usr/include/boost/python/cast.hpp:89: undefined reference to `_Py_NoneStruct'
*** Exited with status: 2 ***

Does this mean I have a broken version of boost.python installed? Or
is it a compiler problem?
I found some reference in the FAQ stating that there could be problems
with the python C API when using compilers other than MSVC. If that's
the case, I'm using gcc 3.4.3, so what do I
have to do to get this thing running? Any help would be appreciated.

--
Alex Borghgraef


From dave at boost-consulting.com  Tue Jul 26 17:31:10 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 26 Jul 2005 11:31:10 -0400
Subject: [C++-sig] Error message: undefined reference to '_Py_NoneStruct'
References: <9e8c52a2050726022824d39fa@mail.gmail.com>
Message-ID: <ufyu1shxd.fsf@boost-consulting.com>

Alexander Borghgraef <alexander.borghgraef.rma at gmail.com> writes:

> Hi all,
>
>  I'm new to using boost.python, so I'm just trying out the library at
> the moment. Unfortunately, things are going wrong at the very
> beginning. I made a little hello world program, which included, but
> didn't use boost/python.hpp, and as a result I get the following error
> messages:
>
> /usr/include/boost/python/object_core.hpp:424: undefined reference to
> `_Py_NoneStruct'
> /usr/include/boost/python/cast.hpp:89: undefined reference to `_Py_NoneStruct'
> *** Exited with status: 2 ***
>
> Does this mean I have a broken version of boost.python installed? Or
> is it a compiler problem?

It means you didn't link with the Python DLL.  Are you using
Boost.Build or trying to do the build by hand?

> I found some reference in the FAQ stating that there could be problems
> with the python C API when using compilers other than MSVC. If that's
> the case, I'm using gcc 3.4.3, so what do I
> have to do to get this thing running? Any help would be appreciated.

Are you using Cygwin GCC?  Did you follow the instructions at
http://www.boost.org/libs/python/doc/building.html
?


>
> --
> Alex Borghgraef

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



From ericjardim at gmail.com  Wed Jul 27 08:05:43 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Wed, 27 Jul 2005 03:05:43 -0300
Subject: [C++-sig] Automatic argument conversion
In-Reply-To: <ur7dmlp6k.fsf@boost-consulting.com>
References: <432ec6c5050724172349cb92f8@mail.gmail.com>
	<20050725130414.30783.qmail@web31512.mail.mud.yahoo.com>
	<ur7dmlp6k.fsf@boost-consulting.com>
Message-ID: <432ec6c5050726230545e113ae@mail.gmail.com>

2005/7/25, David Abrahams <dave at boost-consulting.com>:
> 
> > http://mail.python.org/pipermail/c++-sig/2003-May/004133.html
> Hey, Ralf, do you think this would make a good FAQ? (hinty-hinty) ;-)
> 

Oh, man! I just replaced custom_string with QString, and changed the 
".value()" to ".toStdString()" specific QString method and... it worked. Not 
even compiler errors.

Boost.Python is incredible :)

I will later need to use this same approach to other types like tuples <-> 
QSize(x,y). But I'll try myself first. I hope it work too.

Thanks <David, Ralf, and_everybody>() ["that make it possible"].

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050727/a8686c46/attachment.htm>

From sheig222 at gmail.com  Wed Jul 27 08:16:42 2005
From: sheig222 at gmail.com (Ira)
Date: Wed, 27 Jul 2005 09:16:42 +0300
Subject: [C++-sig] Exposing classes
Message-ID: <dc78s3$hip$1@sea.gmane.org>

A question on basics...

Do all my exposed C++ symbols need to be in .dll format (win32 of course)?

What I mean is, can I have an exe running a python intrpreter where exposed
symbols are compiled *inside* the exe and somehow be able to access them
from the python scripts?

How would I import the modules in such a case?

Thanks,
Ira





From pierre.barbier at cirad.fr  Wed Jul 27 09:02:40 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 27 Jul 2005 09:02:40 +0200
Subject: [C++-sig] Exposing classes
In-Reply-To: <dc78s3$hip$1@sea.gmane.org>
References: <dc78s3$hip$1@sea.gmane.org>
Message-ID: <42E73190.2020708@cirad.fr>

Well, don't know for windows, but for Linux if your symbols are defined
inside your executable file, it works well ! Even your whole module can
be defined in your executable file. You just have to initialise it from
the C API with the low level functions (i.e. the ones who won't try to
look for a file named after your module name ...). Also, once your
module is loaded, every other "normal" import will just work !

Pierre

Ira a ?crit :
> A question on basics...
> 
> Do all my exposed C++ symbols need to be in .dll format (win32 of course)?
> 
> What I mean is, can I have an exe running a python intrpreter where exposed
> symbols are compiled *inside* the exe and somehow be able to access them
> from the python scripts?
> 
> How would I import the modules in such a case?
> 
> Thanks,
> Ira
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
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 sheig222 at gmail.com  Wed Jul 27 09:59:22 2005
From: sheig222 at gmail.com (Ira Holtzer)
Date: Wed, 27 Jul 2005 10:59:22 +0300
Subject: [C++-sig] Exposing classes
References: <dc78s3$hip$1@sea.gmane.org> <42E73190.2020708@cirad.fr>
Message-ID: <00ba01c59281$28b69ce0$a7ffa8c0@randomlogic.com>

OK, I'm new at this so please bear with me.

First off, I'm using boost::python so what low level functions do you mean
(can you give me one name so I know where to start looking)?

Second, what I did is the following:
Created an exe file (SimplePython.exe ) what has a standard greet() function
and the boost::python declaration:
BOOST_PYTHON_MODULE(hello)
{
    def("greet", greet);
}

I run the exe which feeds the interpreter with the script (via
PyRun_String):
import hello
print hello.greet()

To which the interpreter returns an exception saying "ImportError: No module
named hello.

Can this be a path problem, do I somehow need to specify a dll/exe that has
c++ exported symbols?

Thanks,
Ira

----- Original Message ----- 
From: "Pierre Barbier de Reuille" <pierre.barbier at cirad.fr>
Newsgroups: gmane.comp.python.c++
Sent: Wednesday, July 27, 2005 10:02 AM
Subject: Re: Exposing classes


Well, don't know for windows, but for Linux if your symbols are defined
inside your executable file, it works well ! Even your whole module can
be defined in your executable file. You just have to initialise it from
the C API with the low level functions (i.e. the ones who won't try to
look for a file named after your module name ...). Also, once your
module is loaded, every other "normal" import will just work !

Pierre

Ira a ?crit :
> A question on basics...
>
> Do all my exposed C++ symbols need to be in .dll format (win32 of course)?
>
> What I mean is, can I have an exe running a python intrpreter where
exposed
> symbols are compiled *inside* the exe and somehow be able to access them
> from the python scripts?
>
> How would I import the modules in such a case?
>
> Thanks,
> Ira
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>

-- 
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 alexander.borghgraef.rma at gmail.com  Wed Jul 27 10:22:24 2005
From: alexander.borghgraef.rma at gmail.com (Alexander Borghgraef)
Date: Wed, 27 Jul 2005 10:22:24 +0200
Subject: [C++-sig] Error message: undefined reference to '_Py_NoneStruct'
In-Reply-To: <ufyu1shxd.fsf@boost-consulting.com>
References: <9e8c52a2050726022824d39fa@mail.gmail.com>
	<ufyu1shxd.fsf@boost-consulting.com>
Message-ID: <9e8c52a2050727012259a53602@mail.gmail.com>

On 7/26/05, David Abrahams <dave at boost-consulting.com> wrote:
>
> It means you didn't link with the Python DLL.  Are you using
> Boost.Build or trying to do the build by hand?
<snip>
> Are you using Cygwin GCC?  Did you follow the instructions at
> http://www.boost.org/libs/python/doc/building.html
> ?

 I'm working on a Fedora linux machine on which boost was already installed, 
and on which I don't have root privileges, so I have no clue how it
was installed.
Maybe from rpm, is that possible? So I guess the best thing to do would be to 
build a local boost.python install in my home directory, see if that
works, and then
badger the sysadmin to correct the error globally? I'll try that for now.

-- 
Alex Borghgraef


From pierre.barbier at cirad.fr  Wed Jul 27 16:14:50 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 27 Jul 2005 16:14:50 +0200
Subject: [C++-sig] Exposing classes
In-Reply-To: <00ba01c59281$28b69ce0$a7ffa8c0@randomlogic.com>
References: <dc78s3$hip$1@sea.gmane.org> <42E73190.2020708@cirad.fr>
	<00ba01c59281$28b69ce0$a7ffa8c0@randomlogic.com>
Message-ID: <42E796DA.10901@cirad.fr>

Ok, the problem is not about how you export your C++ functions, it's how
you import the module !

When you use the Python "import" statement, Python will look for a file
! And that you don't want as your module is inside your program (and not
as a separate file). So you need to use the C API of Python to import
it. The function is called PyImport_AppendInittab.

Another possibility is to create a DLL with the Boost.Python code (and
not the actual C++ code ...) so there is a hello.dll or hell.pyd file to
load when you use the import statement. However, I really don't know how
well it will work on Windows !

Pierre

Ira Holtzer a ?crit :
> OK, I'm new at this so please bear with me.
> 
> First off, I'm using boost::python so what low level functions do you mean
> (can you give me one name so I know where to start looking)?
> 
> Second, what I did is the following:
> Created an exe file (SimplePython.exe ) what has a standard greet() function
> and the boost::python declaration:
> BOOST_PYTHON_MODULE(hello)
> {
>     def("greet", greet);
> }
> 
> I run the exe which feeds the interpreter with the script (via
> PyRun_String):
> import hello
> print hello.greet()
> 
> To which the interpreter returns an exception saying "ImportError: No module
> named hello.
> 
> Can this be a path problem, do I somehow need to specify a dll/exe that has
> c++ exported symbols?
> 
> Thanks,
> Ira
> 
> ----- Original Message ----- 
> From: "Pierre Barbier de Reuille" <pierre.barbier at cirad.fr>
> Newsgroups: gmane.comp.python.c++
> Sent: Wednesday, July 27, 2005 10:02 AM
> Subject: Re: Exposing classes
> 
> 
> Well, don't know for windows, but for Linux if your symbols are defined
> inside your executable file, it works well ! Even your whole module can
> be defined in your executable file. You just have to initialise it from
> the C API with the low level functions (i.e. the ones who won't try to
> look for a file named after your module name ...). Also, once your
> module is loaded, every other "normal" import will just work !
> 
> Pierre
> 
> Ira a ?crit :
> 
>>A question on basics...
>>
>>Do all my exposed C++ symbols need to be in .dll format (win32 of course)?
>>
>>What I mean is, can I have an exe running a python intrpreter where
> 
> exposed
> 
>>symbols are compiled *inside* the exe and somehow be able to access them
>>from the python scripts?
>>
>>How would I import the modules in such a case?
>>
>>Thanks,
>>Ira
>>
>>
>>
>>_______________________________________________
>>C++-sig mailing list
>>C++-sig at python.org
>>http://mail.python.org/mailman/listinfo/c++-sig
>>
> 
> 

-- 
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  Wed Jul 27 19:42:18 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 27 Jul 2005 13:42:18 -0400
Subject: [C++-sig] Exposing classes
References: <dc78s3$hip$1@sea.gmane.org>
Message-ID: <ufyu0jgcl.fsf@boost-consulting.com>

"Ira" <sheig222 at gmail.com> writes:

> A question on basics...
>
> Do all my exposed C++ symbols need to be in .dll format (win32 of
> course)?

No.

> What I mean is, can I have an exe running a python intrpreter where exposed
> symbols are compiled *inside* the exe and somehow be able to access them
> from the python scripts?

Yes.

> How would I import the modules in such a case?

Just use import in your Python code, but of course your C/C++ code
needs to register the module first.  There's an example of this in the
libs/python/test/ directory.  See embedding.cpp.  The awful Jamfile
incantation needed to build and run it portably is:

    import testing ;

    run ../test/embedding.cpp <lib>../build/boost_python
      : # program args
      : # input files
      : # requirements
      $(PYTHON_PROPERTIES)
        <define>BOOST_PYTHON_STATIC_LIB
        <define>BOOST_PYTHON_STATIC_MODULE
        <library-path>$(PYTHON_LIB_PATH)
          <$(gcc-compilers)><debug-python><library-path>$(CYGWIN_PYTHON_DEBUG_DLL_PATH)
            <$(gcc-compilers)><*><library-path>$(CYGWIN_PYTHON_DLL_PATH)
              <find-library>$(PYTHON_EMBEDDED_LIBRARY)
      ;

HTH,

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



From dave at boost-consulting.com  Wed Jul 27 19:45:27 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 27 Jul 2005 13:45:27 -0400
Subject: [C++-sig] Error message: undefined reference to '_Py_NoneStruct'
References: <9e8c52a2050726022824d39fa@mail.gmail.com>
	<ufyu1shxd.fsf@boost-consulting.com>
	<9e8c52a2050727012259a53602@mail.gmail.com>
Message-ID: <uack8jg7c.fsf@boost-consulting.com>

Alexander Borghgraef <alexander.borghgraef.rma at gmail.com> writes:

>  I'm working on a Fedora linux machine on which boost was already installed, 
> and on which I don't have root privileges, so I have no clue how it
> was installed.
> Maybe from rpm, is that possible? So I guess the best thing to do would be to 
> build a local boost.python install in my home directory, see if that
> works, and then
> badger the sysadmin to correct the error globally? 

That's a possibility, but I'm less concerned about your
libboost_python installation than about how you're assembling your
own extension module or executable.  The simplest possible answer to
your problem is that you're not linking with Python or you're using a
different Python than libboost_python was compiled against.

> I'll try that for now.

Are you trying to do embedding or extending?

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



From dave at boost-consulting.com  Wed Jul 27 20:08:13 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 27 Jul 2005 14:08:13 -0400
Subject: [C++-sig] [Python] some questions in boost instalation and
	example building
References: <u3bq2n3zd.fsf@boost-consulting.com> <dc82kv+pkvh@eGroups.com>
Message-ID: <ubr4oi0ky.fsf@boost-consulting.com>

"weininghao" <weininghao at yahoo.com.cn> writes:

> Hi,
>
> Thanks.
>
> I found the reason why my configure "using gcc" cannot be recognized:
> I always modfied the user-config.jam file under the root directory of
> Boost.Build, but neglected another user-config.jam file has existed in
> the HOME directory. 
> 1) Now I add "using gcc" into the latter file, it works. But I still
> get the warning:
> warning: Python location is not configured
> warning: the Boost.Python library won't be built
>
> I have done: export PYTHON_ROOT=/usr, why got such warning?

Because that is the way you configure Boost.Build v1 to know about
Python.  In BBv2 you put

         using python ... ;

in your user-config.  See the comment in
tools/build/v2/tools/python.jam for how to invoke it.

> 2) Does that mean the file user-config.jam under HOME directory will
> be checked firstly, and if it is existed, the one under Boost.Build
> root directory will not be checked? 
> (In step3 at http://boost.org/doc/html/bbv2/installation.html, it says
> that the user-config.jam file is in the Boost.Build root directory )
>
> 3) I want to use Boost.Build.V2 , but I started to work from
> http://www.boost.org/more/getting_started.html. There are some
> comamnds such as "bjam "-sTOOLS=gcc" install"(in step5), which has not
> been mentioned is special for v1. So I use it with configuring 
> user-cinfig.jam at the same time. 
> Then the correct way to use v2 is totally following
> http://boost.org/doc/html/bbv2/installation.html, am I right?

BBv2 isn't officially supported by any of the library-specific build
instructions on the Boost website, because it hasn't been released
yet.

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



From alexander.borghgraef.rma at gmail.com  Thu Jul 28 09:23:31 2005
From: alexander.borghgraef.rma at gmail.com (Alexander Borghgraef)
Date: Thu, 28 Jul 2005 09:23:31 +0200
Subject: [C++-sig] Error message: undefined reference to '_Py_NoneStruct'
In-Reply-To: <uack8jg7c.fsf@boost-consulting.com>
References: <9e8c52a2050726022824d39fa@mail.gmail.com>
	<ufyu1shxd.fsf@boost-consulting.com>
	<9e8c52a2050727012259a53602@mail.gmail.com>
	<uack8jg7c.fsf@boost-consulting.com>
Message-ID: <9e8c52a205072800233c98fb1b@mail.gmail.com>

On 7/27/05, David Abrahams <dave at boost-consulting.com> wrote:
> Alexander Borghgraef <alexander.borghgraef.rma at gmail.com> writes:
>
> That's a possibility, but I'm less concerned about your
> libboost_python installation than about how you're assembling your
> own extension module or executable.  The simplest possible answer to
> your problem is that you're not linking with Python or you're using a
> different Python than libboost_python was compiled against.

 <Slaps forehead> I am an idiot. Added -lpython2.3 and -lboost_python
to the makefile, now everything links fine. Been too long since I've
done any C++. That, and I assumed boost.python worked just like the
other boost libraries I'd used before, everything in the header file.
Oh well, live and learn. Thanks a lot for the help.
 
> > I'll try that for now.
> 
> Are you trying to do embedding or extending?

 Embedding, I guess. I'm trying to access a python config file parser
class from my Qt project, since python has better regexp support, and
hell, I love the language, so I want to learn how to make hybrid apps
:-)

-- 
Alex Borghgraef


From dave at boost-consulting.com  Thu Jul 28 22:56:36 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 28 Jul 2005 16:56:36 -0400
Subject: [C++-sig] How to tell in member function exists in Python class
References: <200507230038.j6N0cfKQ011443@libra3.slac.stanford.edu>
Message-ID: <uslxyejjv.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:

> I have a virtual C++ base class which I"m exposing to Python so that
> derived classes can be written in Python.   Some virtual functions may
> be overriden in Python and some not.   So in my C++ class which makes
> the interface between Pyton and C++, I would like to test if the
> Python class  has implemented a member function or not.   I've done
> the following, following Dave Abrahams' advice on a previous topic...
>
> unsigned int
> FunctionWrap::
> dimensions () const
> {
>   unsigned int dims = 0;
>
>   if ( override member = this -> get_override ( "dimensions" ) ) {
>     dims = member(); // calls the Python function
>   }
>   else { // didn't override it
>     dims = FunctionBase::dimensions (); // calls the C++ base class
>   }
>   return dims;
> }
>
> This works.   But, I can't find `get_override()' in the Boost.Python
> documeenation.    Maybe I miessed it.   

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

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



From Paul_Kunz at slac.stanford.edu  Thu Jul 28 23:32:10 2005
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 28 Jul 2005 14:32:10 -0700
Subject: [C++-sig] How to tell in member function exists in Python class
In-Reply-To: <uslxyejjv.fsf@boost-consulting.com> (message from David Abrahams
	on Thu, 28 Jul 2005 16:56:36 -0400)
References: <200507230038.j6N0cfKQ011443@libra3.slac.stanford.edu>
	<uslxyejjv.fsf@boost-consulting.com>
Message-ID: <200507282132.j6SLWAtQ018629@libra3.slac.stanford.edu>

>>>>> On Thu, 28 Jul 2005 16:56:36 -0400, David Abrahams <dave at boost-consulting.com> said:


> http://www.boost.org/libs/python/doc/v2/wrapper.html#wrapper-spec-synopsis

   Thanks, found it.


From dave at boost-consulting.com  Fri Jul 29 13:07:52 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 29 Jul 2005 07:07:52 -0400
Subject: [C++-sig] exporting __stdcall methods
References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com>
	<422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org>
	<005101c52759$ee9cc030$37ce4e51@MIKESPC01> <42337D6E.2010505@paniq.org>
	<ud5u41l6n.fsf@boost-consulting.com>
	<024f01c52a4b$5caa5df0$0dc66b51@fuji>
	<uwts672h4.fsf@boost-consulting.com>
	<110901c5678f$814a1f70$de00a8c0@nico>
Message-ID: <ubr4lg99z.fsf@boost-consulting.com>

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

> Hi !
>
> as I have some time ahead, I upgraded my codebase to latest boost snapshot. 
> I was quite surprised to see that, by default, BPL still can't export 
> __stdcall & __fastcall functions, or, at least, I could not find anything 
> that allows that !...
>
> I thought that it may be useful to send my patch to deal with these calling 
> conventions...
>
> I improved somewhat the patch I used before to handle the situation a little 
> bit like type_traits lib does, by adding two defines that should sit in BPL 
> config.hpp : BOOST_PYTHON_ENABLE_STDCALL and BOOST_PYTHON_ENABLE_FASTCALL.
>
> I did not go on tweaking or adding a specific test, as I first wanted to 
> have some feedback about the usefulness of such a patch and about the 
> quality of the one I'm proposing.
>
> Any thoughts ?

Nicolas,

I think it would be great to support these other calling conventions.
Your patch looks good, but I'm quite surprised that it's so small.  Is
that really all that's required to implement full stdcall/fastcall
support?

P.S. Sorry this reply is so late!

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



From rwgk at yahoo.com  Fri Jul 29 16:00:18 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 29 Jul 2005 07:00:18 -0700 (PDT)
Subject: [C++-sig] boost::optional to_and_from_python converters (help
	wanted)
Message-ID: <20050729140018.2497.qmail@web31503.mail.mud.yahoo.com>

I've whipped up custom Python converters for boost::optional<>, free for
everyone to copy:

http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/optional_conversions.h?rev=1.2&view=auto

Here is the corresponding extension + minimal exercise:

http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/optional_ext.cpp?rev=1.2&view=auto

This is known to work on a large number of platforms. It enables for example
(made up):

boost::optional<double>
safe_acos(double arg)
{
  if (arg < -1 || arg > 1) return boost::optional<double>();
  return boost::optional<double>(std::acos(arg));
}

...

def("safe_acos", save_acos);

In python:

>>> safe_acos(-2)
None
>>> safe_acos(0)
1.5707963267948966

HELP WANTED:

Of course, boost::optional<> converters for the built-in types + std::complex<>
and std::string really should be part of Boost.Python. Could someone out here
help with this project?

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From oleg_python at yahoo.de  Fri Jul 29 16:11:53 2005
From: oleg_python at yahoo.de (Oleg Novychny)
Date: Fri, 29 Jul 2005 16:11:53 +0200 (CEST)
Subject: [C++-sig] Problems with Implementing Callback Python/C++-DLL
Message-ID: <20050729141153.38621.qmail@web25705.mail.ukl.yahoo.com>


Dear friends,

I?m hoping to receive some tips to my problem. At the moment I?m trying to implement a callback between Python and my C++-DLL.

My DLL calculates permanently some values and stores them in member-variables in one of the DLL-classes. 

There are some exported functions in my DLL for starting and ending the evaluating and for reading out of values from the member-variables of my DLL.

My wish is to implement my DLL in such a way that my Python-script witch I use for starting my DLL will receive a notice from my DLL to that time when the new values were calculated. I can call then my Python-Function for reading out the values from the DLL synchronized.

 

This is my DLL-header:

 

SOUNDPROCLIB_API int StartProcessing(int fSourceRec, int fNoiseRec, int fCrackRec, int fAudioOnRec, int fBeepRec, unsigned long ulTimeMS );

 

SOUNDPROCLIB_API int GetResults(unsigned long* ulHz, double* dNoise, int* bAudio, int* bCrackFlag, double* dSNR, int* bBeep);

 

SOUNDPROCLIB_API int EndProcessing(void);

 

So I want to call my GetResults function from Python only if my DLL ?tells? to my Python-Script ?do it?.

Here is my Python-DLL-wrapper:

 

from ctypes import*

import sys

 

            

class SoundProcLib(object):

    def __init__(self, library):

        self.library = library

        

        @cdecl(c_int, library, [c_int, c_int, c_int, c_int, c_int, c_ulong])

        def StartProcessing(f1, f2, f3, f4, f5, ul1):           

            if 0 == StartProcessing._api_(f1, f2, f3, f4, f5, ul1):

                raise WinError()

            return None

        self.StartProcessing = StartProcessing

 

        @cdecl(c_int, library, [POINTER(c_ulong), POINTER(c_double), POINTER(c_int), POINTER(c_int), POINTER(c_double), POINTER(c_int)])

        def GetResults():

            ulHz,dNoise,bAudio,bCrackFlag,dSNR,bBeep = c_ulong(), c_double(), c_int(), c_int(), c_double(), c_int()

            if 0 == GetResults._api_(byref(ulHz),byref(dNoise),byref(bAudio),byref(bCrackFlag),byref(dSNR),byref(bBeep)):

                raise WinError()

            return ulHz.value,dNoise.value,bAudio.value,bCrackFlag.value,dSNR.value,bBeep.value

        self.GetResults = GetResults

 

        @cdecl(c_int, library, [c_void_p])

        def EndProcessing():

            if 0 == EndProcessing._api_(None):

                raise WinError()

            return None

        self.EndProcessing = EndProcessing

 

        @cdecl(c_void_p, library, [c_void_p])

        def inittestcallback():

            if 0 == inittestcallback._api_(None):

                raise WinError()

            return None

        self.inittestcallback = inittestcallback

 

At the moment I started to implement my callback in such a way (I found it in a python-tutorial):

 

PyObject *ppyobjArgList;

PyObject *ppyobjResult;

 

static PyObject *my_callback = NULL;

static PyObject *my_set_callback(PyObject *dummy, PyObject *args)

{

    PyObject *result = NULL;

    PyObject *temp;

 

    if (PyArg_ParseTuple(args, "O:set_callback", &temp)) {

        if (!PyCallable_Check(temp)) {

            PyErr_SetString(PyExc_TypeError, "parameter must be callable");

            return NULL;

        }

        Py_XINCREF(temp);         /* Add a reference to new callback */

        Py_XDECREF(my_callback);  /* Dispose of previous callback */

        my_callback = temp;       /* Remember new callback */

        /* Boilerplate to return "None" */

        Py_INCREF(Py_None);

        result = Py_None;

 

        bPyCallBackFlag = true;

    }

    return result;

 

};

static PyMethodDef SoundMethods[] = {

    {"callback",  my_set_callback, METH_VARARGS,

     "Execute a callback."},

 

    {NULL, NULL, 0, NULL}        /* Sentinel */

};

 

 

So I?m not sure how can I ?register? my_set_callback function in the already started Python-Interpreter and to ?explain? my DLL which Python-Function is to call when the new values in my DLL were calculated.

 

Thank you very much for your suggestions

Oleg


		
---------------------------------
Gesendet von Yahoo! Mail - Jetzt mit 1GB kostenlosem Speicher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050729/bae427f2/attachment.htm>

From ericjardim at gmail.com  Fri Jul 29 16:28:57 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Fri, 29 Jul 2005 11:28:57 -0300
Subject: [C++-sig] Custom memory management
Message-ID: <432ec6c505072907287d0db36e@mail.gmail.com>

Hi,
as you may know I am wrapping the Qt4 library. 

Things are going well, but sometimes when the application ends it 
seg_faults.

The problem is that Qt has a light "garbage collection" scheme. Every 
"QObject" object that you create must has a "parent" object (except 
toplevels). When the object is deleted, it clean all the mess of its 
children and so on.

Maybe, child objects are beeing killed too soon and the parents can't find 
them. I am using the with custodian and ward at the constructors, but 
sometimes I do not create the object.

Besides, I suspect that I reference the same C++ object more than one time 
which might be a problem.

Any ideas of what I can do to manage this memory problem? I dropped here the 
backtrace of one the segfaults.

#0 0xb7eda0bd in mallopt () from /lib/tls/libc.so.6
#1 0xb7ed98fb in mallopt () from /lib/tls/libc.so.6
#2 0xb7eda2e6 in mallopt () from /lib/tls/libc.so.6
#3 0xb7ed8f02 in realloc () from /lib/tls/libc.so.6
#4 0xb721739d in qRealloc (ptr=0x821da28, size=512) at 
global/qglobal.cpp:1098
#5 0xb7232797 in QListData::realloc (this=0x821ba00, alloc=123) at 
tools/qlistdata.cpp:73
#6 0xb7232ad4 in QListData::prepend (this=0x821ba00) at 
tools/qlistdata.cpp:115
#7 0xb72c8a2b in QList<int>::prepend (this=0x821ba00, t=@0xbffff480) at 
qlist.h:408
#8 0xb72c3cac in QConnectionList::remove (this=0x821b9f0, object=0x8266808)
at kernel/qobject.cpp:174
#9 0xb72c66b6 in ~QObject (this=0x8266808) at kernel/qobject.cpp:642
#10 0xb72a9e95 in ~QAbstractItemModel (this=0x8266808) at 
kernel/qabstractitemmodel.cpp:887
#11 0xb72aa4fb in ~QAbstractListModel (this=0x8266808) at 
kernel/qabstractitemmodel.cpp:1975
#12 0xb79e8139 in ~QListModel (this=0x8266808) at 
itemviews/qlistwidget.cpp:102
#13 0xb76ab867 in ~QWidget (this=0x8253518) at kernel/qwidget.cpp:898
#14 0xb78c91e7 in ~QFrame (this=0x8253518) at widgets/qframe.cpp:209
#15 0xb7948777 in ~QAbstractScrollArea (this=0x8253518) at 
widgets/qabstractscrollarea.cpp:209
#16 0xb79a1ed7 in ~QAbstractItemView (this=0x8253518) at 
itemviews/qabstractitemview.cpp:408
#17 0xb79b445b in ~QListView (this=0x8253518) at itemviews/qlistview.cpp:247
#18 0xb79e4923 in ~QListWidget (this=0x8253518) at 
itemviews/qlistwidget.cpp:982
#19 0xb76ab093 in ~QWidget (this=0x8240be0) at kernel/qwidget.cpp:898
#20 0xb7d85e92 in ~auto_ptr (this=0xb7de7f2c) at memory:259
#21 0xb7d8694b in ~pointer_holder (this=0xb7de7f24) at pointer_holder.hpp:55
#22 0xb7ccfb2b in boost::python::instance_holder::instance_holder ()
from /usr/lib/libboost_python-gcc-mt-1_33.so.1.33.0
... there are more backtraces but are just like "0x000000 in ?? ()"

Thanks,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050729/0cf9030a/attachment.htm>

From rwgk at yahoo.com  Fri Jul 29 16:55:46 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 29 Jul 2005 07:55:46 -0700 (PDT)
Subject: [C++-sig] Custom memory management
In-Reply-To: <432ec6c505072907287d0db36e@mail.gmail.com>
Message-ID: <20050729145546.78709.qmail@web31514.mail.mud.yahoo.com>

--- Eric Jardim <ericjardim at gmail.com> wrote:
> as you may know I am wrapping the Qt4 library. 
> 
> Things are going well, but sometimes when the application ends it 
> seg_faults.

I cannot answer your question specificly, but I hope this helps: I found
"valgrind" invaluable for tracking down memory management problems:

http://valgrind.org/

I am not sure how well it works with threaded applications, but it is
definitely worth a try. Installation takes only a few seconds (the usual
./configure; make; make install).

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From ahrivera at yahoo.com  Fri Jul 29 19:26:11 2005
From: ahrivera at yahoo.com (Alexis H. Rivera-Rios)
Date: Fri, 29 Jul 2005 10:26:11 -0700 (PDT)
Subject: [C++-sig] better way of returning python objects
Message-ID: <20050729172613.42678.qmail@web30703.mail.mud.yahoo.com>

Hi,

This is my situation.  There is a C++ library called
gmtl that has been ported to python using Pyste and
Boost.Python.
In my code, I have a C++ class that looks like this

--- question #1 ---

class Entity
{
private:
    gmtl::Point3d position;
    gmtl::Vec3d velocity;
    gmtl::Vec3d acceleration;
public:
    void SetPosition(const gmtl::Point3d& pos) ...
    gmtl::Point3d GetPosition() const ...
    void SetVelocity(const gmtl::Vec3d& vel) ...
    gmtl::Vec3d GetVelocity() const ...
    void SetAcceleration(const gmtl::Vec3d& acc) ...
    gmtl::Vec3d GetAcceleration() const ...
};


I want to be able to do this in python

import gmtl; <-- this I can do already because the
library has python bindings
from MyModule import *

t = Entity
t.SetPosition(gmtl.Point3d(1,2,3))  
y = t.GetPosition()

The only way I've figure to do this is the following:
(this is an excerpt of what pyste generated, I changed
the Get/Set methods to this)

 scope* StatATA_Entity_scope = new scope(
    class_< StatATA::Entity, boost::noncopyable,
StatATA_Entity_Wrapper >("Entity", init<  >())
	.def("SetPosition", &SetPosition)
        .def("GetPosition", &GetPosition)
    );

Where,

void SetPosition(  StatATA::Entity &e, const object
&pos )
{
	gmtl::Point3d
p(extract<double>(pos.attr("__getitem__")(0)),
					extract<double>(pos.attr("__getitem__")(1)),
					extract<double>(pos.attr("__getitem__")(2)));
	e.SetPosition(p);	
}

object GetPosition(  StatATA::Entity &e )
{
	object main_module((
   
handle<>(borrowed(PyImport_AddModule("__main__")))));
	object main_namespace = main_module.attr("__dict__");

	object result((handle<>(
    PyRun_String("gmtl.Point3d()"
        , Py_eval_input
        , main_namespace.ptr()
        , main_namespace.ptr()))
	));
	gmtl::Point3d t (e.GetPosition());
	result[0] = t[0];
	result[1] = t[1];
	result[2] = t[2];
	return result;
}

This works. But, is there a better way?

---- question #2 ---

Now, my entity has additional member variables with
other gmtl types.  
It seems that I have to repeat the same process with
each type.

I want to generalize that function so I can specify
the object function to call and the destination type:

class_< StatATA::Entity, boost::noncopyable,
StatATA_Entity_Wrapper >("Entity", init<  >())
	.def("SetPosition",
&GenericSet<Entity::SetPosition,gmtl::Point3d>)
	.def("SetVelocity",
&GenericSet<Entity::SetVelocity,gmtl::Vec3d>)
    );

The closest I've got to do that is this class:

template <class Object>
struct GenSet
{
	typedef void (Object::*MemberFunc) (const
gmtl::Point3d&) ;
	MemberFunc f;

	GenSet(MemberFunc x)
	{
		f = x;
	};
	void operator()(Object &obj, const object &pos)
	{
		gmtl::Point3d
p(extract<double>(pos.attr("__getitem__")(0)),
					extract<double>(pos.attr("__getitem__")(1)),
					extract<double>(pos.attr("__getitem__")(2)));
		(obj.*f)(p);	
	}

};


So in theory I can do the following:

GenSet<Entity> xxx(&Entity::SetPosition)
xxx(myobject, bla)

But I run into the following problems when I try to
use this in the code:

1) declaring an object without the variable name gives
a syntax error:

GenSet<Entity> (&Entity::SetPosition)

c:\Development\PyStatATA\pystatata.cpp(119): 
error C2761: 'void StatATA::Entity::SetPosition(const
gmtl::Point3d &)' : member function redeclaration not
allowed

Why does that mean?

2) Passing the class to the .def function doesn't
compile either:

GenSet<Entity> xxx(&Entity::SetPosition)
class_< StatATA::Entity, boost::noncopyable,
StatATA_Entity_Wrapper >("Entity", init<  >())
	.def("SetPosition", &xxx)

c:\Boost\include\boost-1_32\boost\python\class.hpp(500)
: error C2784:
'boost::mpl::vector17<RT,most_derived<Target,ClassT>::type&,T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14>
boost::python::detail::get_signature(RT (__thiscall
ClassT::*
)(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14)
volatile const,Target *)' : could not deduce template
argument for 'T2 (__thiscall T3::*
)(T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18)
volatile const' from
'`anonymous-namespace'::GenSet<Object>  with
[Object=StatATA::Entity]';
c:\Boost\include\boost-1_32\boost\python\signature.hpp(164)
: see declaration of
'boost::python::detail::get_signature';
c:\Boost\include\boost-1_32\boost\python\class.hpp(237)
: see reference to function template instantiation
'void
boost::python::class_<W,X1,X2>::def_impl<W,F,boost::python::detail::def_helper<T1>>(T
*,const char *,Fn,const Helper &,...) with
[W=StatATA::Entity,X1=boost::noncopyable,X2=`anonymous-namespace'::StatATA_Entity_Wrapper,F=`anonymous-namespace'::GenSet<StatATA::Entity>
*__w64 ,T1=const char
*,T=StatATA::Entity,Fn=`anonymous-namespace'::GenSet<StatATA::Entity>
*__w64 ,Helper=boost::python::detail::def_helper<const
char *>]' being compiled;
c:\Development\PyStatATA\pystatata.cpp(140) : see
reference to function template instantiation
'boost::python::class_<W,X1,X2>::self
&boost::python::class_<W,X1,X2>::def<`anonymous-namespace'::GenSet<Object>*__w64
>(const char *,F) with
[W=StatATA::Entity,X1=boost::noncopyable,X2=`anonymous-namespace'::StatATA_Entity_Wrapper,Object=StatATA::Entity,F=`anonymous-namespace'::GenSet<StatATA::Entity>
*__w64 ]' being compiled
c:\Boost\include\boost-1_32\boost\python\class.hpp(500)
: error C2780:
'boost::mpl::vector17<RT,ClassT&,T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14>
boost::python::detail::get_signature(RT (__thiscall
ClassT::*
)(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14)
volatile const)' : expects 1 arguments - 2 provided;
c:\Boost\include\boost-1_32\boost\python\signature.hpp(146)
: see declaration of
'boost::python::detail::get_signature'
c:\Boost\include\boost-1_32\boost\python\class.hpp(500)
: error C2784:
'boost::mpl::vector17<RT,most_derived<Target,ClassT>::type&,T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14>
boost::python::detail::get_signature(RT (__thiscall
ClassT::*
)(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14)
volatile,Target *)' : could not deduce template
argument for 'T2 (__thiscall T3::*
)(T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18)
volatile' from '`anonymous-namespace'::GenSet<Object> 
with [Object=StatATA::Entity]';
c:\Boost\include\boost-1_32\boost\python\signature.hpp(164)
: see declaration of
'boost::python::detail::get_signature'
c:\Boost\include\boost-1_32\boost\python\class.hpp(500)
: error C2780:
'boost::mpl::vector17<RT,ClassT&,T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14>
boost::python::detail::get_signature(RT (__thiscall
ClassT::*
)(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14)
volatile)' : expects 1 arguments - 2 provided;
c:\Boost\include\boost-1_32\boost\python\signature.hpp(146)
: see declaration of
'boost::python::detail::get_signature'
... 

So I guess it means we can't pass functors to the .def
functions?


In summary, 

- Is there a better way to convert a c++ object to its
respective python object without me having to 
expose the type since that has been done for me?
- Assuming that my solution for the previous question
is acceptable,
how can I generatize my setposition function so its
parameterized on the gmtl type, and object function in
a way that works
with the .def function?

Any comments or feedback will be greatly appreciated,

Alexis








Programming Tutorial:
In Python: To do this, do this
In Perl: To do this, do this or this or this or this...
In C: To do this, do this, but be careful
In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 


From ahrivera at yahoo.com  Fri Jul 29 21:24:09 2005
From: ahrivera at yahoo.com (Alexis H. Rivera-Rios)
Date: Fri, 29 Jul 2005 12:24:09 -0700 (PDT)
Subject: [C++-sig] pyste, gccxml and boost ublas, random number generator etc
Message-ID: <20050729192409.21308.qmail@web30701.mail.mud.yahoo.com>

Hi,

Has anybody used pyste to expose C++ code that
contained boost code from the random number generator
libraries, ublas, shared_ptr?

It seems when pyste compiles my code the gccxml cannot
compile the libraries.  I think this happens because
the boost libraries that I have in windows are setup
to compile with VC 7.1 and gccxml is based on another
compiler so compiling the templates gets messed up.

Example of compiler errors are:

C:\Development\PyStatATA>pyste.py --module=PyStatATA
-I c:\opt\Bayes++ -I ..\Sta
tATA -I c:\usr\local\include -I
C:\Boost\include\boost-1_32 -I C:\opt\newmat ..\
StatATA\pystatata.pyste
In file included from
C:/Boost/include/boost-1_32/boost/numeric/ublas/config.hpp
:29,
                 from
C:/Boost/include/boost-1_32/boost/numeric/ublas/vector.hpp
:22,
                 from
c:/opt/Bayes++/BayesFilter/matSupSub.hpp:41,
                 from
c:/opt/Bayes++/BayesFilter/bayesFlt.hpp:21,
                 from
c:/opt/Bayes++/BayesFilter/UDFlt.hpp:28,
                 from
c:/opt/Bayes++/BayesFilter/allFilters.hpp:19:
C:/Boost/include/boost-1_32/boost/mpl/and.hpp:32:13:
operator "defined" requires
 an identifier
C:/Boost/include/boost-1_32/boost/mpl/and.hpp:32:13:
("and" is an alternative to
ken for "&&" in C++)
C:/Boost/include/boost-1_32/boost/mpl/and.hpp:32:16:
missing '(' in expression
C:/Boost/include/boost-1_32/boost/mpl/and.hpp:43:13:
operator "defined" requires
 an identifier
C:/Boost/include/boost-1_32/boost/mpl/and.hpp:43:13:
("and" is an alternative to
ken for "&&" in C++)
C:/Boost/include/boost-1_32/boost/mpl/and.hpp:43:16:
missing '(' in expression
In file included from
C:/Boost/include/boost-1_32/boost/numeric/ublas/returntype
_deduction.hpp:15,
                 from
C:/Boost/include/boost-1_32/boost/numeric/ublas/traits.hpp
:27,
                 from
C:/Boost/include/boost-1_32/boost/numeric/ublas/storage.hp
p:29,
                 from
C:/Boost/include/boost-1_32/boost/numeric/ublas/vector.hpp
:23,
                 from
c:/opt/Bayes++/BayesFilter/matSupSub.hpp:41,
                 from
c:/opt/Bayes++/BayesFilter/bayesFlt.hpp:21,
                 from
c:/opt/Bayes++/BayesFilter/UDFlt.hpp:28,
                 from
c:/opt/Bayes++/BayesFilter/allFilters.hpp:19:
C:/Boost/include/boost-1_32/boost/mpl/or.hpp:33:13:
operator "defined" requires
...

In file included from
C:/Boost/include/boost-1_32/boost/random/linear_congruential.hpp:25,
                 from
C:/Boost/include/boost-1_32/boost/random.hpp:36,
                 from
../StatATA/random_number_generator.h:6:
C:/Boost/include/boost-1_32/boost/random/detail/const_mod.hpp:
In static member 
   function `static IntType
boost::random::const_mod<IntType, 
   m>::invert_euclidian(IntType)':
C:/Boost/include/boost-1_32/boost/random/detail/const_mod.hpp:152:
error: conflicting
   types for `typedef struct
boost::static_assert_test<sizeof 
  
(boost::STATIC_ASSERTION_FAILURE<(bool)(boost::integer_traits<T>::is_signed)>)>
   boost_static_assert_typedef___COUNTER__'
C:/Boost/include/boost-1_32/boost/random/detail/const_mod.hpp:148:
error: previous
   declaration as `typedef struct
boost::static_assert_test<sizeof 
   (boost::STATIC_ASSERTION_FAILURE<(bool)((m > 0))>)>

...

C:/Boost/include/boost-1_32/boost/shared_ptr.hpp:247:
error: invalid conversion 
   from `void*' to `const char*'
...

The guys from gccxml think it's because they define
their compiler as __GCCXML__ and boost doesn't
recognize this.

Has anybody run into this?

Thanks,
Alexis




Programming Tutorial:
In Python: To do this, do this
In Perl: To do this, do this or this or this or this...
In C: To do this, do this, but be careful
In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From nicodemus at esss.com.br  Fri Jul 29 23:14:15 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Fri, 29 Jul 2005 18:14:15 -0300
Subject: [C++-sig] pyste, gccxml and boost ublas,
 random number generator etc
In-Reply-To: <20050729192409.21308.qmail@web30701.mail.mud.yahoo.com>
References: <20050729192409.21308.qmail@web30701.mail.mud.yahoo.com>
Message-ID: <42EA9C27.7080406@esss.com.br>

Hi Alexis,

Alexis H. Rivera-Rios wrote:

>It seems when pyste compiles my code the gccxml cannot
>compile the libraries.  I think this happens because
>the boost libraries that I have in windows are setup
>to compile with VC 7.1 and gccxml is based on another
>compiler so compiling the templates gets messed up.
>  
>

I always had the same problem, and unfortunatelly it seems there is 
nothing you can do about it. :(

That's the problem mentioned by Petrucio in another thread: standard 
headers and even boost itself upset GCCXML on Windows. One solution 
would be to generate your bindings on Linux, and them compile them on 
windows (that seems to work fine, at least in simple cases). Another 
option would be to get your headers "clean", only with the code to wrap, 
but that may be harder to accomplish, specially if you're wrapping a 3rd 
party library.

Best Regards,
Nicodemus.


From s_sourceforge at nedprod.com  Sat Jul 30 02:52:46 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 30 Jul 2005 01:52:46 +0100
Subject: [C++-sig] Custom memory management
In-Reply-To: <432ec6c505072907287d0db36e@mail.gmail.com>
Message-ID: <42EADD6E.18893.2A65C95@localhost>

On 29 Jul 2005 at 11:28, Eric Jardim wrote:

> The problem is that Qt has a light "garbage collection" scheme. Every
> "QObject" object that you create must has a "parent" object (except
> toplevels). When the object is deleted, it clean all the mess of its
> children and so on.
> 
> Maybe, child objects are beeing killed too soon and the parents can't
> find them. I am using the with custodian and ward at the constructors,
> but sometimes I do not create the object.

Custodian and ward won't help you here. This is happening because 
python likes to manage the lifetime of its objects and doesn't know 
when Qt deletes them from underneath it.

> Besides, I suspect that I reference the same C++ object more than one
> time which might be a problem.

Shouldn't be. BPL refcounts.

> Any ideas of what I can do to manage this memory problem? I dropped
> here the backtrace of one the segfaults.

Make your wrappers hold an auto_ptr to your Qt objects. This works as 
you'd expect it. Upcall when Qt deletes an object to the python layer 
so it zeros the auto_ptr so python won't delete anything later. If 
you want to see it in action, see how TnFOX does it at 
http://www.nedprod.com/TnFOX/ (get the most recent snapshot).

Cheers,
Niall





From mhammond at skippinet.com.au  Sat Jul 30 07:28:46 2005
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 30 Jul 2005 15:28:46 +1000
Subject: [C++-sig] [python-win32] Problems with Implementing Callback
	Python/C++-DLL
In-Reply-To: <20050729141153.38621.qmail@web25705.mail.ukl.yahoo.com>
Message-ID: <DAELJHBGPBHPJKEBGGLNCEKDFIAD.mhammond@skippinet.com.au>

> So I?m not sure how can I ?register? my_set_callback function in the
already
> started Python-Interpreter and to ?explain? my DLL which Python-Function
is
> to call when the new values in my DLL were calculated.

I'm not sure I understand your problem.  The tail of the code you posted
looks like a standard Python module - although you did not show the "module
init" code.  Assuming this was a normal module, Python code would be able to
say:

import foo
foo.callback(some_func)

Which is how my_set_callback will be called.  However, if you have no module
init code, there will be no entry point to the function.  How is your DLL
loaded by Python (or is it your DLL that loads Python?).

Mark