From lists at nabble.com  Wed Jan  4 01:02:19 2006
From: lists at nabble.com (EXTEIDE (sent by Nabble.com))
Date: Tue, 3 Jan 2006 16:02:19 -0800 (PST)
Subject: [C++-sig] The New Extension IDE - EXTEIDE
Message-ID: <2193915.post@talk.nabble.com>


EXTEIDE is freeware. Anyone can download now.

Please visit http://www.exteide.com

Thanks.

--
Sent from the Python - c++-sig forum at Nabble.com:
http://www.nabble.com/The-New-Extension-IDE---EXTEIDE-t846323.html#a2193915
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060103/d517cfa8/attachment.htm>

From reddy at pixar.com  Wed Jan  4 00:14:27 2006
From: reddy at pixar.com (Martin Reddy)
Date: Tue, 3 Jan 2006 15:14:27 -0800 (PST)
Subject: [C++-sig] Using python doc tools on boost-generated functions
Message-ID: <Pine.LNX.4.63.0601031500470.32601@dalwhinnie.pixar.com>


Hey there,

We are using boost.python to create Python bindings to C++ code. We'd like to 
produce automatic Python API docs using a tool like epydoc or pydoc. However,
we've been running into a number of problems, such as epydoc not picking up 
any free functions that are generated by boost.python.

Checking the C++-sig archives, I found a message from Sep 2004 saying that 
boost.python functions are not generated with the same set of attributes on 
them as built-in python functions, and the doc tools like epydoc rely on 
those attributes.

   http://mail.python.org/pipermail/c++-sig/2004-September/008137.html

It looks like this is still an issue today. I'm just wondering if anyone has 
come up with any workarounds for using tools like epydoc or pydoc with 
boost.python functions, or what would be involved to fix this in 
boost.python?

Cheers,

Martin.


---------------------------------------------------------------------------
Martin Reddy                                        Pixar Animation Studios
                                                     1200 Park Avenue
reddy at pixar.com                                     Emeryville, CA 94608
http://MartinReddy.net/                             Tel. (510) 752 4093


From ndbecker2 at gmail.com  Wed Jan  4 02:37:19 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 03 Jan 2006 20:37:19 -0500
Subject: [C++-sig] Using python doc tools on boost-generated functions
References: <Pine.LNX.4.63.0601031500470.32601@dalwhinnie.pixar.com>
Message-ID: <dpf8rv$cdb$1@sea.gmane.org>

Martin Reddy wrote:

> 
> Hey there,
> 
> We are using boost.python to create Python bindings to C++ code. We'd like
> to produce automatic Python API docs using a tool like epydoc or pydoc.
> However, we've been running into a number of problems, such as epydoc not
> picking up any free functions that are generated by boost.python.
> 
> Checking the C++-sig archives, I found a message from Sep 2004 saying that
> boost.python functions are not generated with the same set of attributes
> on them as built-in python functions, and the doc tools like epydoc rely
> on those attributes.
> 
>    http://mail.python.org/pipermail/c++-sig/2004-September/008137.html
> 
> It looks like this is still an issue today. I'm just wondering if anyone
> has come up with any workarounds for using tools like epydoc or pydoc with
> boost.python functions, or what would be involved to fix this in
> boost.python?
> 
> Cheers,
> 

I did explore a few approaches.  Probably the simplest is something like
this:
This is an excerpt from some of my code:

  scope().attr("__doc__") = 
    "Module for Block Interleavers\n";

  class_<BlockInterleaver<int> > ("block_interleaver",  "Block Interleaver", 
                                  init<int, int, int>((arg ("size"), arg ("rows"), arg ("cols")),
                                                      "__init__(size,rows,cols)\n"
                                                      "Construct a Block Interleaver.\n"
                                                      "Only full arrays are supported.\n"
                                                      "@param size: array size\n"
                                                      "@type size: int\n"
                                                      "@param rows: rows\n"
                                                      "@type rows: int\n"
                                                      "@param cols: cols\n"
                                                      "@type cols: int\n"
                                                      )
                                  )
    .def ("v", &BlockInterleaver<int>::GetV)
    .def ("vinv", &BlockInterleaver<int>::GetVinv)
    //    .def_readonly ("v", &BlockInterleaver<int>::v)
    //    .def_readonly ("vinv", &BlockInterleaver<int>::vinv)
    ;

  def ("interleave", &interleave_block<ublas::vector<int>,
ublas::vector<int> >,
       "interleave(inter,x)\n"
       "Interleave input I{x} using interleaver I{inter}"
       "@param inter: stuff\n"
       );

Then running PYTHONPATH=./ epydoc <modulename> seems to work OK.




From Mathieu.Lacage at sophia.inria.fr  Wed Jan  4 09:34:14 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 04 Jan 2006 09:34:14 +0100
Subject: [C++-sig] binding a userspace thread library
Message-ID: <1136363654.6155.64.camel@chronos>

hi,

I am trying to bind a c/c++ userspace thread library. My test python
code:

class MyThread(yans.Thread):
    def run(self):
        print "before sleep";
        sleep_s (1.0);
        print "after sleep";
MyThread ("test");
simulator.run ()
simulator.destroy ();

The class Thread, and the simulator package are implemented as c++ code.
Thread is a wrapper around the yans::Thread C++ class:

class Thread {
public:
        Thread (char const *name);
        virtual ~Thread ();


        void yield (void);

        void sleep_s (double delta);
        void sleep_us (uint64_t delta);

        double time_s (void);

private:
        virtual void run (void) = 0;

        Fiber *m_fiber;
        Semaphore *m_sleep_sem;
};

The wrapping code looks like this:

struct ThreadWrap : Thread {
        ThreadWrap (PyObject *self, char const *name)
                : Thread (name),
                  m_self (self)
        {
                Py_INCREF(m_self);
        }
        ThreadWrap::~ThreadWrap()
        {
                Py_DECREF(m_self);
        }
private:
        virtual void run (void) {
                call_method<void>(m_self, "run");
        }
        PyObject *m_self;
};

/* specialize has_back_reference for ThreadWrap to make
   sure a PyObject* is passed to its constructor
*/
namespace boost { namespace python {
        template <>
        struct has_back_reference<ThreadWrap>
                : mpl::true_ {};
}}


void
export_thread (void)
{
        class_<ThreadWrap, boost::noncopyable> thread ("Thread",
init<char const *> ());
        thread.def ("yield", &Thread::yield);
        thread.def ("sleep_s", &Thread::sleep_s);
        thread.def ("sleep_us", &Thread::sleep_us);
        thread.def ("time_s", &Thread::time_s);
}


I get this backtrace when running the sample python code shown above:
#0  0xb7fda402 in __kernel_vsyscall ()
#1  0x008627d5 in raise () from /lib/tls/libc.so.6
#2  0x00864149 in abort () from /lib/tls/libc.so.6
#3  0x00cf31db in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#4  0x00cf0ef1 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#5  0x00cf0f26 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0x00cf106f in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0xb7d0e35a in boost::python::throw_error_already_set () from /usr/lib/libboost_python.so.1
#8  0xb7cfdd82 in boost::python::converter::void_result_from_python () from /usr/lib/libboost_python.so.1
#9  0xb7d3523d in boost::python::converter::return_from_python<void>::operator() (this=0x9361297, x=0x0) at return_from_python.hpp:101
#10 0xb7d35226 in boost::python::call_method<void> (self=0xb7f4c70c, name=0xb7d36ef6 "run") at call_method.hpp:73
#11 0xb7d351f3 in ThreadWrap::run (this=0x935f2f8) at python/export-thread.cc:41


I have to say I did not really expect this to work because I can imagine
thousands of reasons why the python interpreter or the boost python
bindings would yell at me when having their stack being switched from
under them. However, I would be happy to understand why I get this
exception being thrown at me by the boost wrapper.

As far as I can tell, the backtrace seems to happen from within the
python method MyThread.run when Thread.sleep_s is called (which should
call yans::Thread::sleep_s). Putting a breakpoint in
yans::Thread::sleep_s shows that it is never called.

Suggestions about a way to debug this ?

Mathieu
-- 



From Mathieu.Lacage at sophia.inria.fr  Wed Jan  4 11:30:16 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 04 Jan 2006 11:30:16 +0100
Subject: [C++-sig] binding a userspace thread library
In-Reply-To: <1136363654.6155.64.camel@chronos>
References: <1136363654.6155.64.camel@chronos>
Message-ID: <1136370616.6155.73.camel@chronos>

On Wed, 2006-01-04 at 09:34 +0100, Mathieu Lacage wrote:
> class MyThread(yans.Thread):
>     def run(self):
>         print "before sleep";
>         sleep_s (1.0);
>         print "after sleep";
> MyThread ("test");
> simulator.run ()
> simulator.destroy ();

[snip]

> Suggestions about a way to debug this ?

After quite a bit of debugging (I learned quite a few things about
Boost.Python and the python c interface), it appears that the error here
is that the python script does not qualify the calls to sleep_s with
self.

That is, the following script works flawlessly:
class MyThread(yans.Thread):
    def run(self):
        print "before sleep";
        self.sleep_s (1.0);
        print "after sleep %f" % self.time_s ();
thread = MyThread ("test");
simulator.run ()
simulator.destroy ();


I have to say that the python interpreter gives a better error message
only when run under the debugger. i.e.:
[mathieu at mathieu yans-current]$ python -m pdb ./bin/python/test-thread.py
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(3)?()
-> import yans;
(Pdb) n
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(4)?()
-> from yans import *;
(Pdb)
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(6)?()
-> class MyThread(yans.Thread):
(Pdb)
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(16)?()
-> thread = MyThread ("test");
(Pdb) b MyThread.run
Breakpoint 1 at /home/mathieu/code/yans-current/bin/python/test-thread.py:8
(Pdb) c
SCHED leave main enter "test" active
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(9)run()
-> print "before sleep";
(Pdb) n
before sleep
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(12)run()
-> print "after sleep %f" % time_s ();
(Pdb)
NameError: "global name 'time_s' is not defined"
 > /home/mathieu/code/yans-current/bin/python/test-thread.py(12)run()
-> print "after sleep %f" % time_s ();
(Pdb)

The lack of a better error message by default for such a mistake is...
annoying... Is there a way to improve this ?

Mathieu
-- 



From W.d.Jonge at cebra.tue.nl  Wed Jan  4 12:34:11 2006
From: W.d.Jonge at cebra.tue.nl (Jonge, W. de (Cebra))
Date: Wed, 4 Jan 2006 12:34:11 +0100
Subject: [C++-sig] return reference to same python object
Message-ID: <E10A558B6004FF429FDD464C57E1483608B0A7@campusx3.campus.tue.nl>

Hi,

I have interfaced a C++ class to Python, and have a function to get to
existing C++ objects. However every time a retrieval for a C++ object is
done a new Python wrapper object is constructed and I need this to be a
reference to the same python object so I can add attributes in Python
that will still exist when a new retrieval for the object is done.

I have something like this in C++:

typedef boost::shared_ptr<VT_Client> ClientPtr;

class VT_Client : public boost::enable_shared_from_this<VT_Client>
{
...
}

ClientPtr getClient(const std::string& username);

def("getClient", getClient);


When I now retrieve an object in Python, and assign an extra attribute:

a = getClient("joe");
a.some_attribute = 1

I will lose the python object and attribute when a goes out of scope.
What I need is that the underlying python object stays alive and that
that is returned next time instead of a new one. So later on in my
script I want to be able to do:

b = getClient("joe")
print b.some_attribute # should work here, but doesn't as explained
above

How can I make this work?

Any help is greatly appreciated.

Thanks,

Willem




From beyer at fli-leibniz.de  Wed Jan  4 14:30:21 2006
From: beyer at fli-leibniz.de (Andreas Beyer)
Date: Wed, 04 Jan 2006 14:30:21 +0100
Subject: [C++-sig] return reference to same python object
In-Reply-To: <E10A558B6004FF429FDD464C57E1483608B0A7@campusx3.campus.tue.nl>
References: <E10A558B6004FF429FDD464C57E1483608B0A7@campusx3.campus.tue.nl>
Message-ID: <43BBCDED.80109@fli-leibniz.de>

You may want to take a look at these threads:
http://mail.python.org/pipermail/c++-sig/2003-August/005173.html
http://mail.python.org/pipermail/c++-sig/2005-April/008805.html

Note that they deal with two different problems, but I think it is a 
good idea to know both of them. Which of the solutions works depends on 
who (C++ code or Python code?) is constructing the VT_Client instances.

Andreas

Jonge, W. de (Cebra) wrote:

>Hi,
>
>I have interfaced a C++ class to Python, and have a function to get to
>existing C++ objects. However every time a retrieval for a C++ object is
>done a new Python wrapper object is constructed and I need this to be a
>reference to the same python object so I can add attributes in Python
>that will still exist when a new retrieval for the object is done.
>
>I have something like this in C++:
>
>typedef boost::shared_ptr<VT_Client> ClientPtr;
>
>class VT_Client : public boost::enable_shared_from_this<VT_Client>
>{
>...
>}
>
>ClientPtr getClient(const std::string& username);
>
>def("getClient", getClient);
>
>
>When I now retrieve an object in Python, and assign an extra attribute:
>
>a = getClient("joe");
>a.some_attribute = 1
>
>I will lose the python object and attribute when a goes out of scope.
>What I need is that the underlying python object stays alive and that
>that is returned next time instead of a new one. So later on in my
>script I want to be able to do:
>
>b = getClient("joe")
>print b.some_attribute # should work here, but doesn't as explained
>above
>
>How can I make this work?
>
>Any help is greatly appreciated.
>  
>




From seefeld at sympatico.ca  Wed Jan  4 15:06:41 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 04 Jan 2006 09:06:41 -0500
Subject: [C++-sig] binding a userspace thread library
In-Reply-To: <1136370616.6155.73.camel@chronos>
References: <1136363654.6155.64.camel@chronos>
	<1136370616.6155.73.camel@chronos>
Message-ID: <43BBD671.6000604@sympatico.ca>

Mathieu Lacage wrote:
> On Wed, 2006-01-04 at 09:34 +0100, Mathieu Lacage wrote:
> 
>>class MyThread(yans.Thread):
>>    def run(self):
>>        print "before sleep";
>>        sleep_s (1.0);
>>        print "after sleep";
>>MyThread ("test");
>>simulator.run ()
>>simulator.destroy ();

[ no need for all those ';' here,  by the way ]

> After quite a bit of debugging (I learned quite a few things about
> Boost.Python and the python c interface), it appears that the error here
> is that the python script does not qualify the calls to sleep_s with
> self.

Indeed, though that is neither related to Boost.Python nor the C interface,
it's simply the way Python works.

> I have to say that the python interpreter gives a better error message
> only when run under the debugger. i.e.:

You didn't actually print the error message you get in the original
(i.e. non-pdb) session, only the stack trace.


> The lack of a better error message by default for such a mistake is...
> annoying... Is there a way to improve this ?

The error itself is generated by the python runtime. Boost.Python
then only throws an 'error_already_set' exception to properly
unwind the stack inside the C++ layer in between the two python
layers, but that should be fully transparent (well, beside the
stack trace, of course).

The problem, IIUC, is that you don't catch 'error_already_set'
exceptions inside the worker thread, and so the C++ runtime
aborts with the unexpected handler.

When running inside bdp that won't happen because the debugger
will catch the python exception before it leaves the inner
python layer.

So: if you prepare your thread's private 'run' method to catch
errors (by terminating the thread properly, probably), you will
get much nicer error messages.

HTH,
		Stefan


From W.d.Jonge at cebra.tue.nl  Wed Jan  4 15:10:33 2006
From: W.d.Jonge at cebra.tue.nl (Jonge, W. de (Cebra))
Date: Wed, 4 Jan 2006 15:10:33 +0100
Subject: [C++-sig] return reference to same python object
Message-ID: <E10A558B6004FF429FDD464C57E1483608B0F3@campusx3.campus.tue.nl>

Hi Andreas,

Thanks for the reply, as my objects are created in C++ space I think the
latter thread applies
(http://mail.python.org/pipermail/c++-sig/2005-April/008805.html). 
Did you ever got something working, and if so how? With or without using
the to_python_converter, this sounds as a good solution to me and I
would also think to use a global map mapping C++ pointers to already
existing python wrappers.

Thanks,

Willem

> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]
On
> Behalf Of Andreas Beyer
> Sent: Wednesday, January 04, 2006 2:30 PM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] return reference to same python object
> 
> You may want to take a look at these threads:
> http://mail.python.org/pipermail/c++-sig/2003-August/005173.html
> http://mail.python.org/pipermail/c++-sig/2005-April/008805.html
> 
> Note that they deal with two different problems, but I think it is a
> good idea to know both of them. Which of the solutions works depends
on
> who (C++ code or Python code?) is constructing the VT_Client
instances.
> 
> Andreas
> 
> Jonge, W. de (Cebra) wrote:
> 
> >Hi,
> >
> >I have interfaced a C++ class to Python, and have a function to get
to
> >existing C++ objects. However every time a retrieval for a C++ object
is
> >done a new Python wrapper object is constructed and I need this to be
a
> >reference to the same python object so I can add attributes in Python
> >that will still exist when a new retrieval for the object is done.
> >
> >I have something like this in C++:
> >
> >typedef boost::shared_ptr<VT_Client> ClientPtr;
> >
> >class VT_Client : public boost::enable_shared_from_this<VT_Client>
> >{
> >...
> >}
> >
> >ClientPtr getClient(const std::string& username);
> >
> >def("getClient", getClient);
> >
> >
> >When I now retrieve an object in Python, and assign an extra
attribute:
> >
> >a = getClient("joe");
> >a.some_attribute = 1
> >
> >I will lose the python object and attribute when a goes out of scope.
> >What I need is that the underlying python object stays alive and that
> >that is returned next time instead of a new one. So later on in my
> >script I want to be able to do:
> >
> >b = getClient("joe")
> >print b.some_attribute # should work here, but doesn't as explained
> >above
> >
> >How can I make this work?
> >
> >Any help is greatly appreciated.
> >
> >
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From rwgk at yahoo.com  Wed Jan  4 15:43:38 2006
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 4 Jan 2006 06:43:38 -0800 (PST)
Subject: [C++-sig] Using python doc tools on boost-generated functions
In-Reply-To: <Pine.LNX.4.63.0601031500470.32601@dalwhinnie.pixar.com>
Message-ID: <20060104144338.65057.qmail@web31507.mail.mud.yahoo.com>

--- Martin Reddy <reddy at pixar.com> wrote:

> We are using boost.python to create Python bindings to C++ code. We'd like to
> 
> produce automatic Python API docs using a tool like epydoc or pydoc. However,
> we've been running into a number of problems, such as epydoc not picking up 
> any free functions that are generated by boost.python.
> 
> Checking the C++-sig archives, I found a message from Sep 2004 saying that 
> boost.python functions are not generated with the same set of attributes on 
> them as built-in python functions, and the doc tools like epydoc rely on 
> those attributes.
> 
>    http://mail.python.org/pipermail/c++-sig/2004-September/008137.html
> 
> It looks like this is still an issue today. I'm just wondering if anyone has 
> come up with any workarounds for using tools like epydoc or pydoc with 
> boost.python functions, or what would be involved to fix this in 
> boost.python?

This must have been addressed since it works for me.

Ever since last summer I am dragging a local patch around with me which
automatically adds the C++ signatures to the doc strings. E.g. for a function
(to prove it works):

Help on built-in function min in scitbx.array_family.flex:

scitbx.array_family.flex.min = min(...)
    C++ signatures:
    min(scitbx::af::versa<double, scitbx::af::flex_grid<scitbx::af::small<long,

10ul> > >) -> d
    min(scitbx::af::versa<float, scitbx::af::flex_grid<scitbx::af::small<long,
1
0ul> > >) -> f
    min(scitbx::af::versa<long, scitbx::af::flex_grid<scitbx::af::small<long,
10
ul> > >) -> l
    min(scitbx::af::versa<int, scitbx::af::flex_grid<scitbx::af::small<long,
10u
l> > >) -> i
    min(scitbx::af::versa<unsigned long,
scitbx::af::flex_grid<scitbx::af::small
<long, 10ul> > >) -> m


Or for a class:

Help on class histogram in scitbx.array_family.flex:

scitbx.array_family.flex.histogram = class histogram(Boost.Python.instance)
 |  Method resolution order:
 |      histogram
 |      Boost.Python.instance
 |      __builtin__.object
 |  
 |  Methods defined here:
 |  
 |  __init__(...)
 |      C++ signatures:
 |      __init__(_object*, scitbx::histogram<double, long> other,
scitbx::af::co
nst_ref<double, scitbx::af::trivial_accessor> data) -> v
 |      __init__(_object*, scitbx::histogram<double, long> other,
scitbx::af::co
nst_ref<double, scitbx::af::trivial_accessor> data, d
relative_tolerance=0.0001)
 -> v
 |      __init__(_object*, scitbx::af::const_ref<double,
scitbx::af::trivial_acc
essor> data) -> v
 |      __init__(_object*, scitbx::af::const_ref<double,
scitbx::af::trivial_acc
essor> data, m n_slots=1000) -> v
 |  


This is output from gcc 3.4 compiled code which has some bug in the name
demangler. With other compilers the output contains full type names (e.g.
"bool" instead of just "b").

You have to update just two files in the boost tree to get the doc signatures
feature:

wget
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.hpp_2006_01_04_0620
wget
http://cci.lbl.gov/~rwgk/boost_python/doc_signatures/function.cpp_2006_01_04_0620

Copy these files to

boost/boost/python/object/function.hpp
boost/libs/python/src/object/function.cpp

The modified files are based on the current CVS. There are older files from
last summer in the same web directory (omit the file names from the URL). They
probably work with the latest boost release. In the worst case, take the diffs
from the same web directory and use the patch command to backport to your boost
version.

Sorry I never found the time to check the changes in. Unfortunately my changes
break some unit tests and it takes more time than I can affort right now to
adjust them.

Cheers,
        Ralf



		
__________________________________________ 
Yahoo! DSL ? Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 



From beyer at fli-leibniz.de  Wed Jan  4 16:28:54 2006
From: beyer at fli-leibniz.de (Andreas Beyer)
Date: Wed, 04 Jan 2006 16:28:54 +0100
Subject: [C++-sig] return reference to same python object
In-Reply-To: <E10A558B6004FF429FDD464C57E1483608B0F3@campusx3.campus.tue.nl>
References: <E10A558B6004FF429FDD464C57E1483608B0F3@campusx3.campus.tue.nl>
Message-ID: <43BBE9B6.60105@fli-leibniz.de>

Jonge, W. de (Cebra) wrote:

>Hi Andreas,
>
>Thanks for the reply, as my objects are created in C++ space I think the
>latter thread applies
>(http://mail.python.org/pipermail/c++-sig/2005-April/008805.html). 
>Did you ever got something working, and if so how? 
>
If you exactly follow David's suggestions it works. The example that I 
gave works with David's solution.

>With or without using
>the to_python_converter, this sounds as a good solution to me and I
>would also think to use a global map mapping C++ pointers to already
>existing python wrappers.
>  
>
I recommend *not* to create a map for C++ pointers. You are doubbling 
information that BP already has. You also don't gain a lot. In order to 
use the map, you will have to check if a certain smart pointer is 
already registered in the map before you return it to python. (You will 
do this in some kind of thin-wrapper function.) At the same point in 
your code you could also just call hold_python() - it does the job for you.
The problem here: you have to create a wrapper for all functions 
returning the smart pointers.

I never created a to_python_converter (don't know how to do that). 
However, you may not need it anyway.
My workaround is: call hold_python() immediately after creating an 
object. Afterwards BP 'knows' the respective smart pointer. There is no 
need to call hold_python() at any other location in your code.
The drawback: I couldn't find a way (in my code) that is not intrusive 
into the originial C++ code. What I am doing now is something like this:

A_ptr my_factory_method()
{  // this is my original factory method, which I had to modify
    A_ptr * a = create_new_A();
#ifdef BP_WRAPPING
    hold_python(a); // register new smart pointer at boost.python
#endif
    return a;
}


Of course you have to define BP_WRAPPING and hold_python() somewhere.
I am sure there are better solutions. Yet, I don't know them.

Andreas



From Mathieu.Lacage at sophia.inria.fr  Wed Jan  4 17:03:29 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 04 Jan 2006 17:03:29 +0100
Subject: [C++-sig] binding a userspace thread library
In-Reply-To: <43BBD671.6000604@sympatico.ca>
References: <1136363654.6155.64.camel@chronos>
	<1136370616.6155.73.camel@chronos>  <43BBD671.6000604@sympatico.ca>
Message-ID: <1136390609.6155.93.camel@chronos>

On Wed, 2006-01-04 at 09:06 -0500, Stefan Seefeld wrote:
> Mathieu Lacage wrote:
> > On Wed, 2006-01-04 at 09:34 +0100, Mathieu Lacage wrote:
> > 
> >>class MyThread(yans.Thread):
> >>    def run(self):
> >>        print "before sleep";
> >>        sleep_s (1.0);
> >>        print "after sleep";
> >>MyThread ("test");
> >>simulator.run ()
> >>simulator.destroy ();
> 
> [ no need for all those ';' here,  by the way ]

Yes, I am quite new to python so it is hard to resist the perl/sh
compulsion to add ; everywhere.

[snip]

> You didn't actually print the error message you get in the original
> (i.e. non-pdb) session, only the stack trace.

Yes. There is no error message printed at all: it seems the error is
printed by the interpreter's outer loop and the c++ runtime aborted
before giving the interpreter a chance to run. 

[snip]

> So: if you prepare your thread's private 'run' method to catch
> errors (by terminating the thread properly, probably), you will
> get much nicer error messages.

I see. I now terminate the c++ thread properly (that is, I catch and
ignore the exception) and I now get this:

[mlacage at chronos yans-current]$ ./bin/python/test-thread.py
before sleep
Exception exceptions.NameError: "global name 'time_s' is not defined" in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
Aborted
[mlacage at chronos yans-current]$

This error message does not look quite right: it looks like a collision
of two error messages. Am I wrong ? I suspect this might be related to
the fact that I am not forwarding properly the c++ exception from my
thread to the interpreter's thread. I tried calling a python method with
the same problem from a c++ function called from the c++ interpreter and
I got the following message instead:

Traceback (most recent call last):
  File "./bin/python/test-simulator.py", line 34, in ?
    simulator.run ()
  File "./bin/python/test-simulator.py", line 7, in notify
    print "my event class now=%f" % now_s ();
NameError: global name 'now_s' is not defined

I suspect that the c++ exception I ignore is interpreted correctly by
the boost bindings which re-generate the correct python error. Or maybe
not. I don't know. I guess I will have to see whether or not I can try
to forward exceptions from one thread to another. Or maybe try to deal
with the c++ exception by generating the correct python error myself...

thanks for your suggestions,
Mathieu
-- 



From seefeld at sympatico.ca  Wed Jan  4 17:20:18 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 04 Jan 2006 11:20:18 -0500
Subject: [C++-sig] binding a userspace thread library
In-Reply-To: <1136390609.6155.93.camel@chronos>
References: <1136363654.6155.64.camel@chronos>	<1136370616.6155.73.camel@chronos>
	<43BBD671.6000604@sympatico.ca> <1136390609.6155.93.camel@chronos>
Message-ID: <43BBF5C2.7090109@sympatico.ca>

Mathieu Lacage wrote:

>>So: if you prepare your thread's private 'run' method to catch
>>errors (by terminating the thread properly, probably), you will
>>get much nicer error messages.
> 
> 
> I see. I now terminate the c++ thread properly (that is, I catch and
> ignore the exception) and I now get this:
> 
> [mlacage at chronos yans-current]$ ./bin/python/test-thread.py
> before sleep
> Exception exceptions.NameError: "global name 'time_s' is not defined" in 'garbage collection' ignored
> Fatal Python error: unexpected exception during garbage collection
> Aborted
> [mlacage at chronos yans-current]$
> 
> This error message does not look quite right: it looks like a collision
> of two error messages. Am I wrong ?

To me it looks plausible: The worker thread writes 'before sleep' and
then stops. The error you are seeing then seems to be coming from
the cleanup at the end of your script, i.e. it appears to be an entirely
different issue.


> I suspect this might be related to
> the fact that I am not forwarding properly the c++ exception from my
> thread to the interpreter's thread. I tried calling a python method with
> the same problem from a c++ function called from the c++ interpreter and
> I got the following message instead:
> 
> Traceback (most recent call last):
>   File "./bin/python/test-simulator.py", line 34, in ?
>     simulator.run ()
>   File "./bin/python/test-simulator.py", line 7, in notify
>     print "my event class now=%f" % now_s ();
> NameError: global name 'now_s' is not defined
> 
> I suspect that the c++ exception I ignore is interpreted correctly by
> the boost bindings which re-generate the correct python error. Or maybe
> not.

I'm not sure. Are you saying that the 'now_s()' call should actually succeed ?
May be you are right, and you need to clear the error flag first before
terminating the worker thread. Try calling 'PyErr_Clear()' in your exception
handler in the worker thread. (see http://docs.python.org/api/exceptions.html)

Regards,
		Stefan


From michael.drumheller at boeing.com  Wed Jan  4 19:55:53 2006
From: michael.drumheller at boeing.com (Drumheller, Michael)
Date: Wed, 4 Jan 2006 10:55:53 -0800
Subject: [C++-sig] Pyste with MPL (well, Boost.Serialize, actually...)
Message-ID: <716621DCB4468F46BBCC1BCFBED45C120129DA86@XCH-NW-2V2.nw.nos.boeing.com>

I am having trouble running Pyste version 0.9.30 (gccxml version 0.6.0)
with Boost MPL 1.32 on Windows XP.  A complete (and trivial) example
that demonstrates the problem is included below

The problem has to do with the #ifdef's based on _MSC_VER that appear in
files such as or.hpp, and.hpp, etc.  It seems that _MSC_VER *is*
defined, but does anyone know why that should be?  After all, it is
GCCXML that is being run, not the VC7 compiler.   I found this page
which is probably address similar problems, but has no fixes that I can
discern.
<<http://mail.python.org/pipermail/c++-sig/2005-August.txt>>

Note:  This actually came up because I was trying to run Pyste on a file
that contained classes that use Boost.Serialization to serialize
themselvs, and Boost.Serialization uses MPL a lot.  I noticed that the
first signs of problems stem from the MPL headers, as in my example
below, and I am _hoping_ that once I fix this Boost.Serialization will
just work.
Has anyone else had success running Pyste on Boost.Serialize'd classes?

Thank you.

Michael Drumheller

Example:
-------------------------MplTest.pyste-------------------------
Class("MplTest",  "MplTest.h")
-------------------------MplTest.h-------------------------------
#include <boost/mpl/or.hpp>
class MplTest {};
-------------------------pyste command and output-----------------------
mpltest.deleteme=> c:/Python24/python.exe
c:/Python24/Lib/site-packages/Pyste/pyste.py
-Ic:/Boost/include/boost-1_32 MplTest.pyste 
In file included from MplTest.h:1:
c:/Boost/include/boost-1_32/boost/mpl/or.hpp:33:13: operator "defined"
requires an identifier
c:/Boost/include/boost-1_32/boost/mpl/or.hpp:33:13: ("or" is an
alternative token for "||" in C++)
c:/Boost/include/boost-1_32/boost/mpl/or.hpp:33:15: missing '(' in
expression
c:/Boost/include/boost-1_32/boost/mpl/or.hpp:44:13: operator "defined"
requires an identifier
c:/Boost/include/boost-1_32/boost/mpl/or.hpp:44:13: ("or" is an
alternative token for "||" in C++)
c:/Boost/include/boost-1_32/boost/mpl/or.hpp:44:15: missing '(' in
expression
Traceback (most recent call last):
  File "c:/Python24/Lib/site-packages/Pyste/pyste.py", line 424, in ?
    main()
  File "c:/Python24/Lib/site-packages/Pyste/pyste.py", line 418, in main
    status = Begin()
  File "c:/Python24/Lib/site-packages/Pyste/pyste.py", line 257, in
Begin
    return GenerateCode(parser, module, out, interfaces, multiple)
  File "c:/Python24/Lib/site-packages/Pyste/pyste.py", line 376, in
GenerateCode
    declarations, parsed_header = parser.Parse(header, interface, tail)
  File "c:\Python24\Lib\site-packages\Pyste\CppParser.py", line 165, in
Parse
    declarations = self.ParseWithGCCXML(header, tail)
  File "c:\Python24\Lib\site-packages\Pyste\CppParser.py", line 126, in
ParseWithGCCXML
    raise CppParserError, 'Error executing gccxml'
CppParser.CppParserError: Error executing gccxml
mpltest.deleteme=>




From dave at boost-consulting.com  Thu Jan  5 02:37:44 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 04 Jan 2006 15:37:44 -1000
Subject: [C++-sig] Pyste with MPL (well, Boost.Serialize, actually...)
References: <716621DCB4468F46BBCC1BCFBED45C120129DA86@XCH-NW-2V2.nw.nos.boeing.com>
Message-ID: <m2bqyrh2tz.fsf@coppi.local>

"Drumheller, Michael" <michael.drumheller at boeing.com> writes:

> The problem has to do with the #ifdef's based on _MSC_VER that appear in
> files such as or.hpp, and.hpp, etc.  It seems that _MSC_VER *is*
> defined, but does anyone know why that should be?  After all, it is
> GCCXML that is being run, not the VC7 compiler.   I found this page
> which is probably address similar problems, but has no fixes that I can
> discern.
> <<http://mail.python.org/pipermail/c++-sig/2005-August.txt>>

I don't think that's related.  GCC_XML seems to be running in a VC
compatibility mode.  This seems to be a GCC_XML problem; I suggest you
ask on its mailing list.

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



From dave at boost-consulting.com  Thu Jan  5 02:49:25 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 04 Jan 2006 15:49:25 -1000
Subject: [C++-sig] Cycles won't be deleted
References: <1464.192.168.0.2.1135029664.squirrel@www.glumol.com>
Message-ID: <m264ozh2ai.fsf@coppi.local>

bob at glumol.com writes:

> Hello,
>
> I'm sorry if this question has already been asked but I didn't find an
> answer on the archives.
> With the Python code :
>
> class C: pass
>
> c1 = C()
> c2 = C()
> c1.child = c2
> c2.parent = c1
> del c1
> del c2
> import gc
> gc.collect()
>
> gc.collect() will return 2.
> Now if C is not a pure Python class but a BPL one, gc.collect() will
> return 0 and the 2 objects seem to never be deleted.
> I can define 'child' and 'parent' as members of the C++ class (using a
> shared_ptr and a weak_ptr, that works) but if an other cycle is defined in
> Python, the objects won't be deleted.
>
> Could someone explain me why such a behavior ?

Because there is no way, in general, to traverse all the references to
Python objects that may be embedded in (or otherwise owned by) a given
C++ object, Boost.Python marks all wrapped C++ objects as "not
GC-able."  If we didn't do that, you would see objects disappearing
too early, which is much worse than a leak.

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



From Mathieu.Lacage at sophia.inria.fr  Thu Jan  5 10:05:21 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 05 Jan 2006 10:05:21 +0100
Subject: [C++-sig] binding a userspace thread library
In-Reply-To: <43BBF5C2.7090109@sympatico.ca>
References: <1136363654.6155.64.camel@chronos>
	<1136370616.6155.73.camel@chronos> <43BBD671.6000604@sympatico.ca>
	<1136390609.6155.93.camel@chronos>  <43BBF5C2.7090109@sympatico.ca>
Message-ID: <1136451921.6155.120.camel@chronos>

On Wed, 2006-01-04 at 11:20 -0500, Stefan Seefeld wrote:
> > [mlacage at chronos yans-current]$ ./bin/python/test-thread.py
> > before sleep
> > Exception exceptions.NameError: "global name 'time_s' is not defined" in 'garbage collection' ignored
> > Fatal Python error: unexpected exception during garbage collection
> > Aborted
> > [mlacage at chronos yans-current]$
> > 
> > This error message does not look quite right: it looks like a collision
> > of two error messages. Am I wrong ?
> 
> To me it looks plausible: The worker thread writes 'before sleep' and
> then stops. The error you are seeing then seems to be coming from
> the cleanup at the end of your script, i.e. it appears to be an entirely
> different issue.

I fail to see how the call to Simulator.destroy could generate such a
warning but you are likely to be right.

[snip]

> > Traceback (most recent call last):
> >   File "./bin/python/test-simulator.py", line 34, in ?
> >     simulator.run ()
> >   File "./bin/python/test-simulator.py", line 7, in notify
> >     print "my event class now=%f" % now_s ();
> > NameError: global name 'now_s' is not defined
> > 
> > I suspect that the c++ exception I ignore is interpreted correctly by
> > the boost bindings which re-generate the correct python error. Or maybe
> > not.
> 
> I'm not sure. Are you saying that the 'now_s()' call should actually succeed ?

no. I am merely concerned by the fact that I do not get the same warning
when using a Thread and when not using a Thread. 

I suspect that, in the case shown here, we have:
  - python interpreter calls Simulator.run which calls c++
Simulator::Run
  - c++ Simulator::run calls c++ EventWrap::notify which calls python
MyEvent.notify
  - MyEvent.notify generates python error because now_s is not defined
and returns.
  - c++ EventWrap sees python error, generates c++ exception.
  - c++ exception propagates to the outer of Simulator::run, that is the
boost binding for Simulator::run.
  - c++ boost binding eats the c++ exception, generates a python error.

In the other case I was looking at, I have:
  - python interpreter calls Simulator.run which calls c++
Simulator::Run
  - Simulator::Run calls some Event::notify which switches to another c+
+ Thread's stack (c++ Thread::run)
  - c++ ThreadWrap::run calls python Thread.run
  - python Thread.run generates python error because now_s is not
defined and returns.
  - c++ boost binding code generates c++ exception from python error.
  - c++ ThreadWrap::run sees exception, eats c++ exception, switches
back to main thread
  - c++ main thread (that is, Simulator::run) keeps on executing until
the end of the simulation.
  - at the end of the simulation, c++ Simulator::run returns to python
interpreter which keeps on executing
  - python interpreter runs Simulator.destroy (), triggers, another
errors, and displays the new error's message together with the old error
message.

So, I decided to work around this by forwarding the boost c++ exception
from my c++ thread to the c++ main thread such that the python
interpreter can generate the right error message as soon as possible. I
ended up doing this:

class ThreadWrap {
        void rethrow_exception (error_already_set &set) {
                throw set;
        }
        virtual void run (void) {
                try {
                        call_method<void>(m_self, "run");
                } catch (error_already_set &set) {
                        Simulator::insert_later (make_event (&ThreadWrap::rethrow_exception, this, set));
                }
        }
};

Which as the nice side-effect of now generating the correct error
message with a buggy script:
[mlacage at chronos yans-current]$ bin/python/test-thread.py
before sleep
Traceback (most recent call last):
  File "bin/python/test-thread.py", line 14, in ?
    simulator.run ()
  File "bin/python/test-thread.py", line 10, in run
    print "after sleep %f" % time_s ();
NameError: global name 'time_s' is not defined
[mlacage at chronos yans-current]$

Which is really uber-cool.

> May be you are right, and you need to clear the error flag first before
> terminating the worker thread. Try calling 'PyErr_Clear()' in your exception
> handler in the worker thread. (see http://docs.python.org/api/exceptions.html)

Nice. But I don't think I want to do this.

thanks for your comments,
Mathieu
-- 



From koen_van_herck at yahoo.com  Thu Jan  5 13:59:13 2006
From: koen_van_herck at yahoo.com (Koen Van Herck)
Date: Thu, 5 Jan 2006 13:59:13 +0100
Subject: [C++-sig] Docstring for operators
Message-ID: <IMEPIKNKKCDPCKIPIEIIIEAHCCAA.koen_van_herck@yahoo.com>

Hello,

Is it possible to provide a docstring for operators (in general), or in
particalar for the 'str' operator?

I currently have:

    namespace bp = boost::python;
    bp::class_<Time>("Time", "class docstring", bp::init<>("constructor
docstring"))
        .def(bp::self_ns::str(bp::self))
    ;

but have found no way to provide a "str docstring".

Regards,
Koen Van Herck.



From amohr at pixar.com  Thu Jan  5 21:03:10 2006
From: amohr at pixar.com (Alex Mohr)
Date: Thu, 05 Jan 2006 12:03:10 -0800
Subject: [C++-sig] Polymorphism with injected constructor...
Message-ID: <43BD7B7E.109@pixar.com>

This little test breaks if I use an injected constructor.  Base_wrap's 
call to get_override() fails.  The offending line is marked below.  If I 
comment it out, this test works.  See below for the output and expected 
output.

#include <boost/python.hpp>
#include <string>

using namespace boost::python;
using std::string;

struct Base {
     virtual ~Base() {}
     virtual string Func() { return "C++ Func"; }
};

struct Base_wrap : Base, wrapper<Base> {
     static Base_wrap *New() { return new Base_wrap(); }
     string default_Func() { return Base::Func(); }
     virtual string Func() {
         if (override func = get_override("Func"))
             return func();
         return default_Func();
     }
};

static void Test(Base *b) {
     printf("Func -> '%s'\n", b->Func().c_str());
}

BOOST_PYTHON_MODULE(Test) {
     def("Test", Test);
     class_<Base_wrap, boost::noncopyable>("Base")
         // *** Commenting out the following line fixes the test.
         .def("__init__", make_constructor(&Base_wrap::New))
         .def("Func", &Base::Func, &Base_wrap::default_Func)
         ;
}

#####
from Test import *
class Derived(Base):
     def Func(self):
         return 'Python Func'

Test(Base())
Test(Derived())
#####

Output is:
Func -> 'C++ Func'
Func -> 'C++ Func'

Expected is:
Func -> 'C++ Func'
Func -> 'Python Func'

Again, the test works correctly if I comment out the injected 
constructor.  Can anyone explain why this happens?

Thanks,

Alex



From seefeld at sympatico.ca  Thu Jan  5 21:16:59 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 05 Jan 2006 15:16:59 -0500
Subject: [C++-sig] Polymorphism with injected constructor...
In-Reply-To: <43BD7B7E.109@pixar.com>
References: <43BD7B7E.109@pixar.com>
Message-ID: <43BD7EBB.3080206@sympatico.ca>

Alex Mohr wrote:

> from Test import *
> class Derived(Base):
>      def Func(self):
>          return 'Python Func'

> Again, the test works correctly if I comment out the injected 
> constructor.  Can anyone explain why this happens?

Did you try adding a constructor to the Derived class
that explicitely calls Base.__init__ ?

I'm not sure I completely understand the python object model,
in particular, the relationship between classes and their
base classes as far as object layout is concerned, but
I would imagine that a function returning a new base class
instance can't really be used to initialize a base class
of a derived instance. Just a guess...

Regards,
		Stefan


From amohr at pixar.com  Thu Jan  5 22:07:53 2006
From: amohr at pixar.com (Alex Mohr)
Date: Thu, 05 Jan 2006 13:07:53 -0800
Subject: [C++-sig] Polymorphism with injected constructor...
In-Reply-To: <43BD7EBB.3080206@sympatico.ca>
References: <43BD7B7E.109@pixar.com> <43BD7EBB.3080206@sympatico.ca>
Message-ID: <43BD8AA9.7010502@pixar.com>

> Did you try adding a constructor to the Derived class
> that explicitely calls Base.__init__ ?

Actually I tried doing this:

class Derived(Base):
	def __init__(self):
		Base.__init__(self)
	def Func(self):
		return 'Python Func'

But that didn't make any difference so I left it out for brevity.

> I'm not sure I completely understand the python object model,
> in particular, the relationship between classes and their
> base classes as far as object layout is concerned, but
> I would imagine that a function returning a new base class
> instance can't really be used to initialize a base class
> of a derived instance. Just a guess...

Hmm... I guess I'm not sure what's really different about the case of an 
injected constructor versus not.  The wrapper object is getting 
constructed properly -- it's just not able to find the python override 
for Func.

Thanks,

Alex


From W.d.Jonge at cebra.tue.nl  Fri Jan  6 12:12:55 2006
From: W.d.Jonge at cebra.tue.nl (Jonge, W. de (Cebra))
Date: Fri, 6 Jan 2006 12:12:55 +0100
Subject: [C++-sig] return reference to same python object
Message-ID: <E10A558B6004FF429FDD464C57E1483608B1F0@campusx3.campus.tue.nl>

Hi,

If BP already has the required info internally all the better to use it.
I've been trying to create a working sample based on your information,
however it doesn't work. My code (this is with hold_python for every
object retrieval, I also tried calling the hold python once during
construction as you suggested, also without any success):

using namespace boost;

class A : public enable_shared_from_this<A>
{
public:
	A() : val(0) {};
	int val;
	typedef shared_ptr<A> A_ptr;
};

template <class T>
hold_python(shared_ptr<T>& x)
{
	x = python::extract<shared_ptr<T> >( python::object(x) );
}

A::A_ptr a;

A::A_ptr get_a()
{
	hold_python(a);
	return a;
}

BOOST_PYTHON_MODULE(mymod)
{
	// create single instance
	a = A::A_ptr(new A);

	python::register_ptr_to_python< A::A_ptr >();

	python::class_<A> ("A")
		.def_readwrite("val", &A::val)
	;

	python::def("get", get_a);
}

The script I'm running:

import mymod

a1 = mymod.get()
a2 = mymod.get()

a1.val = 3
a1.foo = 42

print a2.val
print a2.foo

Giving me this:

3
Traceback (most recent call last):
  File "test.py", line 10, in ?
    print a2.foo
AttributeError: 'A' object has no attribute 'foo'

Thanks,

Willem

> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]
On
> Behalf Of Andreas Beyer
> Sent: Wednesday, January 04, 2006 4:29 PM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] return reference to same python object
> 
> Jonge, W. de (Cebra) wrote:
> 
> >Hi Andreas,
> >
> >Thanks for the reply, as my objects are created in C++ space I think
the
> >latter thread applies
> >(http://mail.python.org/pipermail/c++-sig/2005-April/008805.html).
> >Did you ever got something working, and if so how?
> >
> If you exactly follow David's suggestions it works. The example that I
> gave works with David's solution.
> 
> >With or without using
> >the to_python_converter, this sounds as a good solution to me and I
> >would also think to use a global map mapping C++ pointers to already
> >existing python wrappers.
> >
> >
> I recommend *not* to create a map for C++ pointers. You are doubbling
> information that BP already has. You also don't gain a lot. In order
to
> use the map, you will have to check if a certain smart pointer is
> already registered in the map before you return it to python. (You
will
> do this in some kind of thin-wrapper function.) At the same point in
> your code you could also just call hold_python() - it does the job for
> you.
> The problem here: you have to create a wrapper for all functions
> returning the smart pointers.
> 
> I never created a to_python_converter (don't know how to do that).
> However, you may not need it anyway.
> My workaround is: call hold_python() immediately after creating an
> object. Afterwards BP 'knows' the respective smart pointer. There is
no
> need to call hold_python() at any other location in your code.
> The drawback: I couldn't find a way (in my code) that is not intrusive
> into the originial C++ code. What I am doing now is something like
this:
> 
> A_ptr my_factory_method()
> {  // this is my original factory method, which I had to modify
>     A_ptr * a = create_new_A();
> #ifdef BP_WRAPPING
>     hold_python(a); // register new smart pointer at boost.python
> #endif
>     return a;
> }
> 
> 
> Of course you have to define BP_WRAPPING and hold_python() somewhere.
> I am sure there are better solutions. Yet, I don't know them.
> 
> Andreas
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From beyer at fli-leibniz.de  Fri Jan  6 12:51:36 2006
From: beyer at fli-leibniz.de (Andreas Beyer)
Date: Fri, 06 Jan 2006 12:51:36 +0100
Subject: [C++-sig] return reference to same python object
In-Reply-To: <E10A558B6004FF429FDD464C57E1483608B1F0@campusx3.campus.tue.nl>
References: <E10A558B6004FF429FDD464C57E1483608B1F0@campusx3.campus.tue.nl>
Message-ID: <43BE59C8.4010009@fli-leibniz.de>

AFAICS you don't need enable_shared_from_this<>.
Do you use the most up-to-date CVS version of BP?

It is important that hold_python() replaces the actual 'a' and not any 
copy of it. I suspect this is the problem in your case. Although I have 
to regret, I don't see why get_a() is not using the original 'a' from 
the global name space.
Some internal BP things might play a role. Maybe David can help.

Sorry for not being of more help,
    Andreas


Jonge, W. de (Cebra) wrote:

>Hi,
>
>If BP already has the required info internally all the better to use it.
>I've been trying to create a working sample based on your information,
>however it doesn't work. My code (this is with hold_python for every
>object retrieval, I also tried calling the hold python once during
>construction as you suggested, also without any success):
>
>using namespace boost;
>
>class A : public enable_shared_from_this<A>
>{
>public:
>	A() : val(0) {};
>	int val;
>	typedef shared_ptr<A> A_ptr;
>};
>
>template <class T>
>hold_python(shared_ptr<T>& x)
>{
>	x = python::extract<shared_ptr<T> >( python::object(x) );
>}
>
>A::A_ptr a;
>
>A::A_ptr get_a()
>{
>	hold_python(a);
>	return a;
>}
>
>BOOST_PYTHON_MODULE(mymod)
>{
>	// create single instance
>	a = A::A_ptr(new A);
>
>	python::register_ptr_to_python< A::A_ptr >();
>
>	python::class_<A> ("A")
>		.def_readwrite("val", &A::val)
>	;
>
>	python::def("get", get_a);
>}
>
>The script I'm running:
>
>import mymod
>
>a1 = mymod.get()
>a2 = mymod.get()
>
>a1.val = 3
>a1.foo = 42
>
>print a2.val
>print a2.foo
>
>Giving me this:
>
>3
>Traceback (most recent call last):
>  File "test.py", line 10, in ?
>    print a2.foo
>AttributeError: 'A' object has no attribute 'foo'
>
>Thanks,
>
>Willem
>  
>




From W.d.Jonge at cebra.tue.nl  Fri Jan  6 13:26:33 2006
From: W.d.Jonge at cebra.tue.nl (Jonge, W. de (Cebra))
Date: Fri, 6 Jan 2006 13:26:33 +0100
Subject: [C++-sig] return reference to same python object
Message-ID: <E10A558B6004FF429FDD464C57E1483608B1FA@campusx3.campus.tue.nl>

I've used a recent version of boost now and it works, I was still using
1.32 of boost libraries, because the other threads about the issue were
before the 1.33 release I thought that would not be a problem.
I'll incorporate it now in the factory methods of my code as you
suggested and I'm all set.
You have been a great help, thank you.

Willem

> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]
On
> Behalf Of Andreas Beyer
> Sent: Friday, January 06, 2006 12:52 PM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] return reference to same python object
> 
> AFAICS you don't need enable_shared_from_this<>.
> Do you use the most up-to-date CVS version of BP?
> 
> It is important that hold_python() replaces the actual 'a' and not any
> copy of it. I suspect this is the problem in your case. Although I
have
> to regret, I don't see why get_a() is not using the original 'a' from
> the global name space.
> Some internal BP things might play a role. Maybe David can help.
> 
> Sorry for not being of more help,
>     Andreas
> 
> 
> Jonge, W. de (Cebra) wrote:
> 
> >Hi,
> >
> >If BP already has the required info internally all the better to use
it.
> >I've been trying to create a working sample based on your
information,
> >however it doesn't work. My code (this is with hold_python for every
> >object retrieval, I also tried calling the hold python once during
> >construction as you suggested, also without any success):
> >
> >using namespace boost;
> >
> >class A : public enable_shared_from_this<A>
> >{
> >public:
> >	A() : val(0) {};
> >	int val;
> >	typedef shared_ptr<A> A_ptr;
> >};
> >
> >template <class T>
> >hold_python(shared_ptr<T>& x)
> >{
> >	x = python::extract<shared_ptr<T> >( python::object(x) );
> >}
> >
> >A::A_ptr a;
> >
> >A::A_ptr get_a()
> >{
> >	hold_python(a);
> >	return a;
> >}
> >
> >BOOST_PYTHON_MODULE(mymod)
> >{
> >	// create single instance
> >	a = A::A_ptr(new A);
> >
> >	python::register_ptr_to_python< A::A_ptr >();
> >
> >	python::class_<A> ("A")
> >		.def_readwrite("val", &A::val)
> >	;
> >
> >	python::def("get", get_a);
> >}
> >
> >The script I'm running:
> >
> >import mymod
> >
> >a1 = mymod.get()
> >a2 = mymod.get()
> >
> >a1.val = 3
> >a1.foo = 42
> >
> >print a2.val
> >print a2.foo
> >
> >Giving me this:
> >
> >3
> >Traceback (most recent call last):
> >  File "test.py", line 10, in ?
> >    print a2.foo
> >AttributeError: 'A' object has no attribute 'foo'
> >
> >Thanks,
> >
> >Willem
> >
> >
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From jonathan.liger at wanadoo.fr  Fri Jan  6 16:35:40 2006
From: jonathan.liger at wanadoo.fr (jonathan liger)
Date: Fri, 06 Jan 2006 16:35:40 +0100
Subject: [C++-sig] Some fixes on Pyste and a few questions
Message-ID: <43BE8E4C.20903@wanadoo.fr>

Hi,

I attached to this mail a patch for Pyste 0.9.10 (in fact, the version 
which is distributed with boost 1.33.1). This patch fixes the following 
problems I encountered:
- const pointers were interpreted as pointer on const data
- "return_value_polic(ies)" are not handled properly with --no-using 
(because policies are declared in boost::python and the namespace is not 
prepended)
- Methods with default arguments are wrapped using function which are 
inside the namespace of every pyste object. They are prefixed whith the 
name of class in which the method is declared, not the one we are 
currently wrapping. Added the name of the class we are currently 
wrapping in the mangled overloaded name

As this patch surely does not do things the cleanest way, I would like 
to contact the maintener of Pyste and see what should be done. Is it 
still Bruno da Silva de Oliveira (nicodemus at globalite.com.br), as 
written in the sources of Pyste ?

I also have a few question on Pyste
- what does 'return_opaque_pointer' policies suits for ? It does not 
work (it generates invalid code) with functions returning void*, which 
is the C way to return opaque structures.
- I use Pyste in "multiple mode" and I want to be sure of the order in 
which export functions are called in the _main.cpp file. I tried using 
the "Import" directive but this one seems to be buggy:
    Exple:
        I want to have

BOOST_PYTHON_MODULE(myModule)
{
    Export_foo();
    Export_bar1();
    Export_bar2();
}

        in _main.cpp because some classes in bar1 and bar2 inherits from 
classes in foo. Importing foo.pyste at the begining of bar1 and bar2 
solves that problems but causes wrapping code in _foo.cpp to be 
generated 3 times !
Am I using this wrong or should there be another directive to manage the 
order of the Export_* functions ?

_john.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pyste.diff
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060106/3bb25945/attachment.txt>

From roman.yakovenko at gmail.com  Sun Jan  8 06:35:52 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 8 Jan 2006 07:35:52 +0200
Subject: [C++-sig] Some fixes on Pyste and a few questions
In-Reply-To: <43BE8E4C.20903@wanadoo.fr>
References: <43BE8E4C.20903@wanadoo.fr>
Message-ID: <7465b6170601072135k1568f851p4b16b09d67a13db9@mail.gmail.com>

On 1/6/06, jonathan liger <jonathan.liger at wanadoo.fr> wrote:
> Hi,
> I also have a few question on Pyste
> - what does 'return_opaque_pointer' policies suits for ? It does not
> work (it generates invalid code) with functions returning void*, which
> is the C way to return opaque structures.

1. You need patch from Niall Douglas in order to make this work. Just
search this list for
void*

2. See this FAQ http://boost.org/libs/python/doc/v2/faq.html#voidptr

> - I use Pyste in "multiple mode" and I want to be sure of the order in
> which export functions are called in the _main.cpp file. I tried using
> the "Import" directive but this one seems to be buggy:
>     Exple:
>         I want to have
>
> BOOST_PYTHON_MODULE(myModule)
> {
>     Export_foo();
>     Export_bar1();
>     Export_bar2();
> }
>
>         in _main.cpp because some classes in bar1 and bar2 inherits from
> classes in foo. Importing foo.pyste at the begining of bar1 and bar2
> solves that problems but causes wrapping code in _foo.cpp to be
> generated 3 times !
> Am I using this wrong or should there be another directive to manage the
> order of the Export_* functions ?

I think that Niall also has patch for this problem too.

Why don't you try pyplusplus? See
http://www.language-binding.net/pyplusplus/pyplusplus.html
and
http://www.language-binding.net/pyplusplus/to_pyste_comparison.html

I am almost sure you don't need to patch it at all.

> _john.
>

Roman Yakovenko


From s_sourceforge at nedprod.com  Sun Jan  8 17:12:54 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 08 Jan 2006 16:12:54 -0000
Subject: [C++-sig] Some fixes on Pyste and a few questions
In-Reply-To: <7465b6170601072135k1568f851p4b16b09d67a13db9@mail.gmail.com>
References: <43BE8E4C.20903@wanadoo.fr>
Message-ID: <43C13A06.6962.83ED50@s_sourceforge.nedprod.com>

On 8 Jan 2006 at 7:35, Roman Yakovenko wrote:

> On 1/6/06, jonathan liger <jonathan.liger at wanadoo.fr> wrote:
> > Hi,
> > I also have a few question on Pyste
> > - what does 'return_opaque_pointer' policies suits for ? It does not
> > work (it generates invalid code) with functions returning void*, which
> > is the C way to return opaque structures.
> 
> 1. You need patch from Niall Douglas in order to make this work. Just
> search this list for
> void*

Yeah that's a Boost.Python problem not a pyste problem. Find my 
patch.

> >         in _main.cpp because some classes in bar1 and bar2 inherits from
> > classes in foo. Importing foo.pyste at the begining of bar1 and bar2
> > solves that problems but causes wrapping code in _foo.cpp to be
> > generated 3 times !
> > Am I using this wrong or should there be another directive to manage the
> > order of the Export_* functions ?
> 
> I think that Niall also has patch for this problem too.

You don't use python import, you use pyste's Import().

> Why don't you try pyplusplus? See
> http://www.language-binding.net/pyplusplus/pyplusplus.html
> and
> http://www.language-binding.net/pyplusplus/to_pyste_comparison.html

If you can, use pyplusplus over pyste. I say that for ALL users of 
pyste, pyplusplus is now mature enough to be useful as well as being 
actively developed. It can also do quite a few tricks pyste cannot.

Cheers,
Niall





From pirx at cs.tu-berlin.de  Tue Jan 10 22:51:37 2006
From: pirx at cs.tu-berlin.de (Andreas)
Date: Tue, 10 Jan 2006 22:51:37 +0100
Subject: [C++-sig] weakref to shared_ptr conversion
In-Reply-To: <cscblt$tfp$1@sea.gmane.org>
References: <002e01c4fa72$d7f3a060$1d02a8c0@wxp2000>	<003301c4fa85$0c9d8260$1d02a8c0@wxp2000><csablh$o4q$1@sea.gmane.org>	<csc112$66t$1@sea.gmane.org>	<csc833$lvj$1@sea.gmane.org>
	<cscblt$tfp$1@sea.gmane.org>
Message-ID: <43C42C69.2090308@cs.tu-berlin.de>

hello,

I have a problem with implicit conversion of weakref of shared_ptr to 
shared_ptr.

I have the following code:
//c++
class A
{
   public:
     static shared_ptr<A> create() {
       return shared_ptr<A>(new A());
     };
     ~A() {}

   private:
     A() {}
};

void foo(shared_ptr<A> pA)
{
}

BOOST_PYTHON_MODULE(Test)
{
   class_<A, shared_ptr<A> >("A", no_init)
     .def("create", &A::create)
     .staticmethod("create")
   ;
   boost::python::def("foo", foo);
}

//python
import weakref
a = A.create()
weak_a = weakref.ref(a)

foo(a)  #works fine
foo(weak_a)
#error:
#    foo(weak_a)
#Boost.Python.ArgumentError: Python argument types in
#    CodeSubWars_Common.foo(weakref)
#did not match C++ signature:
#    foo(class boost::shared_ptr<class A>)


How do i get such an implicit conversion from weakref to shared_ptr 
working? Is it possible to define an implicit converter to solve this?
(I'm using boost 1.33.1, MSVC7.1 and Python 2.4.2)

Any help would be appreciated,
andreas rose



From roman.yakovenko at gmail.com  Wed Jan 11 06:47:12 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 11 Jan 2006 07:47:12 +0200
Subject: [C++-sig] weakref to shared_ptr conversion
In-Reply-To: <43C42C69.2090308@cs.tu-berlin.de>
References: <002e01c4fa72$d7f3a060$1d02a8c0@wxp2000>
	<003301c4fa85$0c9d8260$1d02a8c0@wxp2000> <csablh$o4q$1@sea.gmane.org>
	<csc112$66t$1@sea.gmane.org> <csc833$lvj$1@sea.gmane.org>
	<cscblt$tfp$1@sea.gmane.org> <43C42C69.2090308@cs.tu-berlin.de>
Message-ID: <7465b6170601102147x1a03811fx74a8542e78b4f659@mail.gmail.com>

> How do i get such an implicit conversion from weakref to shared_ptr
> working? Is it possible to define an implicit converter to solve this?
> (I'm using boost 1.33.1, MSVC7.1 and Python 2.4.2)

1. See manuals for HeldType of class
http://boost.org/libs/python/doc/v2/class.htm

2. See http://boost.org/libs/python/doc/v2/register_ptr_to_python.html

3. See http://boost.org/libs/python/doc/v2/implicit.html

4. Create simple use case and try it with one of the boost.python code
generators.
By the way, pyplusplus has small user friendly GUI, so you have to
learn almost nothing
in order to try.

I attach 4 files, unit tests of pyplusplus, that checks smart pointers
code generation.
They could be useful for understanding of the subject.

smart_pointers.cpp contains code created by pyplusplus
smart_pointers_to_be_exported.[hpp|cpp] contains code that should be
exported :-)
smart_pointers_tester.py contains tests, see run_tests function



> Any help would be appreciated,
> andreas rose

Roman Yakovenko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smart_pointers.cpp
Type: application/octet-stream
Size: 6156 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060111/26b5d3d8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smart_pointers_to_be_exported.hpp
Type: application/octet-stream
Size: 1392 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060111/26b5d3d8/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smart_pointers_to_be_exported.cpp
Type: application/octet-stream
Size: 1241 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060111/26b5d3d8/attachment-0002.obj>
-------------- next part --------------
# Copyright 2004 Roman Yakovenko.
# Distributed under the Boost Software License, Version 1.0. (See
# accompanying file LICENSE_1_0.txt or copy at
# http://www.boost.org/LICENSE_1_0.txt)

import os
import sys
import unittest
import fundamental_tester_base
from pygccxml import declarations
from pyplusplus import code_creators

class tester_t(fundamental_tester_base.fundamental_tester_base_t):
    EXTENSION_NAME = 'smart_pointers'
    
    def __init__( self, *args ):
        fundamental_tester_base.fundamental_tester_base_t.__init__( 
            self
            , tester_t.EXTENSION_NAME
            , *args )

    def customize_decls(self, decls):
        def should_stay(decl):
            if isinstance( decl, declarations.namespace_t ):
                return True
            fname = declarations.full_name( decl )
            return fname.startswith( '::smart_pointers' ) 
        return declarations.filtering.user_defined( decls, should_stay )    

    def customize_module(self, extmodule ):
        pass
   
    def run_tests( self, module):
        da = module.create_auto()
        self.failUnless( 11 == da.value )
        ds = module.create_shared()
        self.failUnless( 11 == ds.value )
        
        self.failUnless( 11 == module.ref_auto(da) )
        self.failUnless( 11 == module.ref_shared(ds) )

        self.failUnless( 11 == module.val_auto(da) )
        self.failUnless( 11 == module.val_shared(ds) )

        da = module.create_auto()

        self.failUnless( 11 == module.const_ref_auto(da) )
        self.failUnless( 11 == module.const_ref_shared(ds) )
        
        #TODO: find out why this fails
        #self.failUnless( 19 == module.ref_auto_base_value(da) )
        #self.failUnless( 19 == module.ref_shared_base_value(ds) )

        da = module.create_auto()

        self.failUnless( 19 == module.const_ref_auto_base_value(da) )
        self.failUnless( 19 == module.const_ref_shared_base_value(ds) )

        da = module.create_auto()

        self.failUnless( 19 == module.val_auto_base_value(da) )
        self.failUnless( 19 == module.val_shared_base_value(ds) )
    
def create_suite():
    suite = unittest.TestSuite()    
    suite.addTest( unittest.makeSuite(tester_t))
    return suite

def run_suite():
    unittest.TextTestRunner(verbosity=2).run( create_suite() )

if __name__ == "__main__":
    run_suite()



From michael.drumheller at boeing.com  Wed Jan 11 19:18:17 2006
From: michael.drumheller at boeing.com (Drumheller, Michael)
Date: Wed, 11 Jan 2006 10:18:17 -0800
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
Message-ID: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>

This gmane entry 
<<http://article.gmane.org/gmane.comp.python.c++/9049/match=pyplusplus+m
ature>>
says, among other things, the following

"""If you can, use pyplusplus over pyste. I say that for ALL users of
pyste, pyplusplus is now mature enough to be useful as well as being
actively developed. It can also do quite a few tricks pyste cannot."""

If this is really the case, I think the Boost documentation needs to say
so.  For example, the doc page
<<http://www.boost.org/libs/python/pyste/>> does not give any warning
that Pyste is essentially deprecated (which it apparently is, if the
above quote is true).  Further, as far as I can tell there are no clues
at <<http://www.boost.org/libs/libraries.htm#Inter-language>> indicating
that users might want to check out pyplusplus, whereas the official
Boost.Python page <<http://www.boost.org/libs/python/doc/index.html>>
explicity directs users to Pyste.

The end result is that an innocent user who is new to integrating Python
and C++ (like, um, say, me) could reasonably come away with the
impression that the most state-of-the-art approach to use is
Boost.Python+Pyste.

As a side question, does anyone use Boost.Python *without* an automatic
code generator such as Pyste or Pyplusplus?  It does not seem like a
practical thing to do--but maybe I'm missing something...?

Thank you.

Michael D.



From tkirke at gmail.com  Wed Jan 11 19:51:31 2006
From: tkirke at gmail.com (Tony Kirke)
Date: Wed, 11 Jan 2006 10:51:31 -0800
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
Message-ID: <4dcfdcab0601111051p32efe996se0bb8c93c901d6dd@mail.gmail.com>

I concur with several of your comments. However, I was unable to get
pyplusplus to work under Ubuntu 5.10 and Python 2.4. From what I remember
the documentation only states that it works with Python 2.3 and does not
mention 2.4, so I'm not sure it is as mature or actively developed or if
there was some other issue. Also the documention for Pyste is easier to
follow and I think more comprehensive.
Finally for template functions it was necessary to do something separate
from Pyste as it does not handle these types of functions.
Regards
Tony


On 1/11/06, Drumheller, Michael <michael.drumheller at boeing.com> wrote:
>
> This gmane entry
> <<http://article.gmane.org/gmane.comp.python.c++/9049/match=pyplusplus+m
> ature>>
> says, among other things, the following
>
> """If you can, use pyplusplus over pyste. I say that for ALL users of
> pyste, pyplusplus is now mature enough to be useful as well as being
> actively developed. It can also do quite a few tricks pyste cannot."""
>
> If this is really the case, I think the Boost documentation needs to say
> so.  For example, the doc page
> <<http://www.boost.org/libs/python/pyste/>> does not give any warning
> that Pyste is essentially deprecated (which it apparently is, if the
> above quote is true).  Further, as far as I can tell there are no clues
> at <<http://www.boost.org/libs/libraries.htm#Inter-language>> indicating
> that users might want to check out pyplusplus, whereas the official
> Boost.Python page <<http://www.boost.org/libs/python/doc/index.html>>
> explicity directs users to Pyste.
>
> The end result is that an innocent user who is new to integrating Python
> and C++ (like, um, say, me) could reasonably come away with the
> impression that the most state-of-the-art approach to use is
> Boost.Python+Pyste.
>
> As a side question, does anyone use Boost.Python *without* an automatic
> code generator such as Pyste or Pyplusplus?  It does not seem like a
> practical thing to do--but maybe I'm missing something...?
>
> Thank you.
>
> Michael D.
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060111/9df94e55/attachment.htm>

From seefeld at sympatico.ca  Wed Jan 11 20:57:06 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 11 Jan 2006 14:57:06 -0500
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
Message-ID: <43C56312.4070607@sympatico.ca>

Drumheller, Michael wrote:

> As a side question, does anyone use Boost.Python *without* an automatic
> code generator such as Pyste or Pyplusplus?  It does not seem like a
> practical thing to do--but maybe I'm missing something...?

I have been using boost.python for a number of projects but I never used
pyste for any of them. What's wrong with that ? What do you think *I* am
missing ?

Regards,
		Stefan


From brett at coombs.anu.edu.au  Thu Jan 12 03:39:03 2006
From: brett at coombs.anu.edu.au (Brett Calcott)
Date: Thu, 12 Jan 2006 13:39:03 +1100
Subject: [C++-sig] cvs update breaks some code (class_metadata.hpp)
Message-ID: <dq4fg9$4hf$1@sea.gmane.org>

Hi,

I have just updated from CVS. Some code of mine no longer compiles. I am 
using VC 7.1 on Window XP Prof.

Here is a short piece of code that compiles with CVS update from 1st 
August 05, but not with the latest from 12th January 06.

The problem occurs in class_metadata.hpp. A copy of the error produced 
is below the code.

I will investigate further, in the weekend. For now, if anyone has any 
clues, let me know.

Cheers,
Brett

****** CODE BEGINS


#include <boost/python/call_method.hpp>
#include <boost/python/wrapper.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/list.hpp>
#include <boost/python/tuple.hpp>
#include <boost/python/def.hpp>
#include <boost/python/module.hpp>

using namespace boost::python;

struct base {
     base() {}
     virtual int a_function(int a) { return 0; }
};

struct python_base : base, wrapper<base>
{
     python_base() : base() {}

     int a_function(int a)
     {
         if (override f = this->get_override("a_function"))
             return f(a);
         return base::a_function(a);
     }

     int default_a_function(int a) { return this->base::a_function(a); }
};

struct cpp_derived : base, wrapper<base>
{
     cpp_derived() : base() {}

     int a_function(int a)
     {
         return a * 666;
     }
};

int call_a_function(base &base, int i)
{
     return base.a_function(i);
}

BOOST_PYTHON_MODULE(simple)
{
     class_<base
         , boost::noncopyable
         >("_BaseNotUsed")
         ;

     // Base for all python classes
     class_<python_base
         , bases<base>
         , boost::noncopyable
         >("PythonBase")
         .def(init<python_base>())
         .def("a_function", &base::a_function, 
&python_base::default_a_function)
         ;

     // A C++ derived class
     class_<cpp_derived
         , bases<base>
         , boost::noncopyable
         >("SimpleEvolver")
         .def(init<cpp_derived>())
         ;

     def("call_a_function", &call_a_function);
}

******** END OF CODE

The error is a follows:

d:\boost\boost\python\object\class_metadata.hpp(57) : error C2664: 
'boost::mpl::assertion_failed' : cannot convert parameter 1 from 
'boost::mpl::failed ************boost::mpl::not_<T>::* *********** 
                  ' to 'boost::mpl::assert<false>::type'
         with
         [
 
T=boost::is_same<base,boost::python::objects::class_metadata<base,boost::noncopyable,boost::python::detail::not_specified,boost::python::detail::not_specified>::wrapped>
         ]
         A reference that is not to 'const' cannot be bound to a non-lvalue
         d:\boost\boost\mpl\for_each.hpp(73) : see reference to function 
template instantiation 'void 
boost::python::objects::register_base_of<Derived>::operator 
()<boost::detail::add_pointer_impl<T>::no_ref_type>(Base *) const' being 
compiled
         with
         [
             Derived=base,
 
T=boost::mpl::aux::resolve_bind_arg<boost::mpl::bind1<boost::mpl::quote1<boost::add_pointer,boost::mpl::void_>,boost::mpl::lambda<boost::mpl::_,boost::mpl::void_>::result_>::apply<item>::a1,item,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na>::type,
 
Base=boost::detail::add_pointer_impl<boost::mpl::aux::resolve_bind_arg<boost::mpl::bind1<boost::mpl::quote1<boost::add_pointer,boost::mpl::void_>,boost::mpl::lambda<boost::mpl::_,boost::mpl::void_>::result_>::apply<item>::a1,item,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na>::type>::no_ref_type
         ]
         d:\boost\boost\mpl\for_each.hpp(97) : see reference to function 
template instantiation 'void 
boost::mpl::aux::for_each_impl<false>::execute<first,last,TransformOp,F>(Iterator 
*,LastIterator *,TransformFunc *,F)' being compiled
         with
         [
             TransformOp=boost::add_pointer<boost::mpl::_>,
             F=boost::python::objects::register_base_of<base>,
             Iterator=first,
             LastIterator=last,
             TransformFunc=boost::add_pointer<boost::mpl::_>
         ]
         d:\boost\boost\python\object\class_metadata.hpp(98) : see 
reference to function template instantiation 'void 
boost::mpl::for_each<Bases,boost::add_pointer<T>,boost::python::objects::register_base_of<Derived>>(F,Sequence 
*,TransformOp *)' being compiled
         with
         [
             Bases=boost::python::bases<base>,
             T=boost::mpl::_,
             Derived=base,
             F=boost::python::objects::register_base_of<base>,
             Sequence=boost::python::bases<base>,
             TransformOp=boost::add_pointer<boost::mpl::_>
         ]
         d:\boost\boost\python\object\class_metadata.hpp(225) : see 
reference to function template instantiation 'void 
boost::python::objects::register_shared_ptr_from_python_and_casts<T2,boost::python::bases<Base0>>(T 
*,Bases)' being compiled
         with
         [
             T2=base,
             Base0=base,
             T=base,
             Bases=boost::python::bases<base>
         ]
         d:\boost\boost\python\object\class_metadata.hpp(213) : see 
reference to function template instantiation 'void 
boost::python::objects::class_metadata<T,X1,X2,X3>::register_aux2<T2,boost::mpl::bool_<C_>>(T2 
*,Callback)' being compiled
         with
         [
             T=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable,
             X3=boost::python::detail::not_specified,
             T2=base,
             C_=true,
             Callback=boost::mpl::bool_<true>
         ]
         d:\boost\boost\python\object\class_metadata.hpp(205) : see 
reference to function template instantiation 'void 
boost::python::objects::class_metadata<T,X1,X2,X3>::register_aux<base>(boost::python::wrapper<base> 
*)' being compiled
         with
         [
             T=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable,
             X3=boost::python::detail::not_specified
         ]
         d:\boost\boost\python\object\class_metadata.hpp(204) : while 
compiling class-template member function 'void 
boost::python::objects::class_metadata<T,X1,X2,X3>::register_(void)'
         with
         [
             T=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable,
             X3=boost::python::detail::not_specified
         ]
         d:\boost\boost\python\class.hpp(174) : see reference to class 
template instantiation 
'boost::python::objects::class_metadata<T,X1,X2,X3>' being compiled
         with
         [
             T=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable,
             X3=boost::python::detail::not_specified
         ]
         d:\boost\boost\python\class.hpp(627) : see reference to class 
template instantiation 'boost::python::class_<W,X1,X2>::id_vector' being 
compiled
         with
         [
             W=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable
         ]
         C:\Program Files\Microsoft Visual Studio .NET 
2003\Vc7\include\xmemory(156) : while compiling class-template member 
function 'boost::python::class_<W,X1,X2>::class_(const char *,const char *)'
         with
         [
             W=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable
         ]
         test.cpp(58) : see reference to class template instantiation 
'boost::python::class_<W,X1,X2>' being compiled
         with
         [
             W=python_base,
             X1=boost::python::bases<base>,
             X2=boost::noncopyable
         ]
d:\boost\boost\python\object\class_metadata.hpp(57) : fatal error C1903: 
unable to recover from previous error(s); stopping compilation









From roman.yakovenko at gmail.com  Thu Jan 12 06:28:23 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Thu, 12 Jan 2006 07:28:23 +0200
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <4dcfdcab0601111051p32efe996se0bb8c93c901d6dd@mail.gmail.com>
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
	<4dcfdcab0601111051p32efe996se0bb8c93c901d6dd@mail.gmail.com>
Message-ID: <7465b6170601112128m7c50a812l347d56c7c98fcfd8@mail.gmail.com>

On 1/11/06, Tony Kirke <tkirke at gmail.com> wrote:
> I concur with several of your comments. However, I was unable to get
> pyplusplus to work under Ubuntu 5.10 and Python 2.4. From what I remember
> the documentation only states that it works with Python 2.3 and does not
> mention 2.4, so I'm not sure it is as mature or actively developed or if
> there was some other issue. Also the documention for Pyste is easier to
> follow and I think more comprehensive.

> Finally for template functions it was necessary to do something separate
> from Pyste as it does not handle these types of functions.
> Regards
> Tony

Why don't you report a bug? pyplusplus is developed on Debian Linux. I
think if you send me your problems I can help you a lot. Also I am
testing pyplusplus on windows using Python 2.4.

About documentation - you are right. Right now I am working hard to write it.
pyplusplus has few examples:

  boost.date_time
  Qt.XML
  EasyBMP

All those are libraries, that has been wrote by other people, and
exposed to Python by me.
You can take a look on them.

Template functions: see boost.date_time example. This library has a
lot of template functions/classes. Using pyplusplus + pygccxml it is
possible to deal with them almost painless.

Roman Yakovenko


From roman.yakovenko at gmail.com  Thu Jan 12 06:33:31 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Thu, 12 Jan 2006 07:33:31 +0200
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
Message-ID: <7465b6170601112133y55259ee6ve72e4c51f23649f@mail.gmail.com>

On 1/11/06, Drumheller, Michael <michael.drumheller at boeing.com> wrote:
> This gmane entry
> <<http://article.gmane.org/gmane.comp.python.c++/9049/match=pyplusplus+m
> ature>>
> says, among other things, the following
>
> """If you can, use pyplusplus over pyste. I say that for ALL users of
> pyste, pyplusplus is now mature enough to be useful as well as being
> actively developed. It can also do quite a few tricks pyste cannot."""

As author of pyplusplus, I can tell you that Niall is right:
See this: http://www.language-binding.net/pyplusplus/to_pyste_comparison.html

> If this is really the case, I think the Boost documentation needs to say
> so.  For example, the doc page
> <<http://www.boost.org/libs/python/pyste/>> does not give any warning
> that Pyste is essentially deprecated (which it apparently is, if the
> above quote is true).  Further, as far as I can tell there are no clues
> at <<http://www.boost.org/libs/libraries.htm#Inter-language>> indicating
> that users might want to check out pyplusplus, whereas the official
> Boost.Python page <<http://www.boost.org/libs/python/doc/index.html>>
> explicity directs users to Pyste.

It would be nice to mention pyplusplus too.

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


From Mathieu.Lacage at sophia.inria.fr  Thu Jan 12 09:46:54 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 12 Jan 2006 09:46:54 +0100
Subject: [C++-sig] detecting if a function is written in python or C++
Message-ID: <1137055615.15517.35.camel@chronos>

hi,

I would like to be able to detect if the function/method I am calling
from python is implemented as python or as c++ code in a boost python
wrapper. Is this possible in a simple way ? The "inspect" python module
does not seem to contain any reference to this sort of information.

A use case for this would be the following python code where the Event
class is a c++ wrapper which calls back into the python "notify" method
and whenre CppEvent is a c++ wrapper which calls back into a c++ method.

class __MyEvent__(Event):
    def set_callback (self, function, *args):
        self.__function_ = function;
        self.__args_ = args;
    def notify (self):
        self.__function_ (*self.__args_);

def make_event(function, *args):
    #if function is python code, do this:
        ev = __MyEvent__ ();
        ev.set_callback (function, *args);
    # otherwise, do something smarter to make the c++ 
    # Event::notify method call directly in the c++ function 
    # rather than go through the __MyEvent__.notify method 
    # and then back to the c++ function.
        ev = CppEvent ();
        ev.set_callback (function, *args);
    return ev

Mathieu
-- 



From pierre.barbier at cirad.fr  Thu Jan 12 11:19:37 2006
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Thu, 12 Jan 2006 11:19:37 +0100
Subject: [C++-sig] detecting if a function is written in python or C++
In-Reply-To: <1137055615.15517.35.camel@chronos>
References: <1137055615.15517.35.camel@chronos>
Message-ID: <43C62D39.9020903@cirad.fr>

Hello,

je me rends compte que je t'ai r?pondu mais j'ai pas mis la r?ponse pour
la ML ... comme j'?tais sur le webmail de mon labo j'ai plus de trace du
mail ... tu pourrais le forwarder sur la ML s'il te plait ?

Merci,

Pierre

Mathieu Lacage a ?crit :
> hi,
> 
> I would like to be able to detect if the function/method I am calling
> from python is implemented as python or as c++ code in a boost python
> wrapper. Is this possible in a simple way ? The "inspect" python module
> does not seem to contain any reference to this sort of information.
> 
> A use case for this would be the following python code where the Event
> class is a c++ wrapper which calls back into the python "notify" method
> and whenre CppEvent is a c++ wrapper which calls back into a c++ method.
> 
> class __MyEvent__(Event):
>     def set_callback (self, function, *args):
>         self.__function_ = function;
>         self.__args_ = args;
>     def notify (self):
>         self.__function_ (*self.__args_);
> 
> def make_event(function, *args):
>     #if function is python code, do this:
>         ev = __MyEvent__ ();
>         ev.set_callback (function, *args);
>     # otherwise, do something smarter to make the c++ 
>     # Event::notify method call directly in the c++ function 
>     # rather than go through the __MyEvent__.notify method 
>     # and then back to the c++ function.
>         ev = CppEvent ();
>         ev.set_callback (function, *args);
>     return ev
> 
> Mathieu

-- 
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 pbarbier at cirad.fr  Thu Jan 12 10:39:03 2006
From: pbarbier at cirad.fr (pbarbier at cirad.fr)
Date: Thu, 12 Jan 2006 10:39:03 +0100 (CET)
Subject: [C++-sig] detecting if a function is written in python or C++
In-Reply-To: <1137055615.15517.35.camel@chronos>
References: <1137055615.15517.35.camel@chronos>
Message-ID: <1137058743.43c623b7a0fb5@webmail.cirad.fr>


Hello,

well, it is not specific to C++, but you will find that information in the
module where the function is defined. And the simplest way to get the
information is with the module "imp". So let suppose you got the function object
you want to test as the variable "fct" :

>>> imp.find_module(fct.__mofule__)[2]
('.so', 'rb', 3)

... the last number is the one one interest to you !
imp defines constant to know what it is. The constants are :
PY_SOURCE   (=1)
PY_COMPILED (=2)
C_EXTENSION (=3)

... if the value is 3 it means it's a C extension.

Hope this help !

Pierre

En r?ponse ? Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr>:

> hi,
> 
> I would like to be able to detect if the function/method I am calling
> from python is implemented as python or as c++ code in a boost python
> wrapper. Is this possible in a simple way ? The "inspect" python module
> does not seem to contain any reference to this sort of information.
> 
> A use case for this would be the following python code where the Event
> class is a c++ wrapper which calls back into the python "notify" method
> and whenre CppEvent is a c++ wrapper which calls back into a c++
> method.
> 
> class __MyEvent__(Event):
>     def set_callback (self, function, *args):
>         self.__function_ = function;
>         self.__args_ = args;
>     def notify (self):
>         self.__function_ (*self.__args_);
> 
> def make_event(function, *args):
>     #if function is python code, do this:
>         ev = __MyEvent__ ();
>         ev.set_callback (function, *args);
>     # otherwise, do something smarter to make the c++ 
>     # Event::notify method call directly in the c++ function 
>     # rather than go through the __MyEvent__.notify method 
>     # and then back to the c++ function.
>         ev = CppEvent ();
>         ev.set_callback (function, *args);
>     return ev
> 
> Mathieu
> -- 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 



From meine at kogs1.informatik.uni-hamburg.de  Thu Jan 12 13:05:12 2006
From: meine at kogs1.informatik.uni-hamburg.de (Hans Meine)
Date: Thu, 12 Jan 2006 13:05:12 +0100
Subject: [C++-sig] detecting if a function is written in python or C++
In-Reply-To: <1137055615.15517.35.camel@chronos>
References: <1137055615.15517.35.camel@chronos>
Message-ID: <200601121305.13123.meine@kogs.informatik.uni-hamburg.de>

On Thursday 12 January 2006 09:46, Mathieu Lacage wrote:
> A use case for this would be the following python code where the Event
> class is a c++ wrapper which calls back into the python "notify" method
> and whenre CppEvent is a c++ wrapper which calls back into a c++ method.
> [...]
> def make_event(function, *args):
>     #if function is python code, do this:
>         ev = __MyEvent__ ();
>         ev.set_callback (function, *args);
>     # otherwise, do something smarter to make the c++
>     # Event::notify method call directly in the c++ function
>     # rather than go through the __MyEvent__.notify method
>     # and then back to the c++ function.
>         ev = CppEvent ();
>         ev.set_callback (function, *args);
>     return ev

FWIW, I think I would have taken a different approach:

  try:
        ev = CppEvent ();
        ev.set_callback (function, *args);
  except ...:
        ev = __MyEvent__ ();
        ev.set_callback (function, *args);

AFAICT, this would also work if function is from a C extension, but does not 
fit the required interface of CppEvent.set_callback().

-- 
Ciao, /  /
     /--/
    /  / ANS


From Mathieu.Lacage at sophia.inria.fr  Thu Jan 12 15:05:45 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 12 Jan 2006 15:05:45 +0100
Subject: [C++-sig] optimizing away calls to the python runtime -- was
	[detecting if	a function is written in python or C++]
Message-ID: <1137074745.15517.102.camel@chronos>

hi,

I apologize for this second email but the more I think about what I am
trying to do, the less I see how to do it. So, here is a hopefully
detailed explanation of what I am trying to achieve.

Here are my c++ classes:
class Event {
virtual void notify (void) = 0;
};
class Simulator {
 void schedule (Event *event);
 double now_s (void); // return current time.
 void run (void);
};

sample c++ use code:
class MyEvent : public Event {
virtual void notify (void) {
	std::cout << "now=" Simulator::now_s () << std::endl;
	delete this;
}
};

Simulator->schedule (new MyEvent ());
Simulator->run (); // invokes MyEvent::notify sometime later.

This sort of code requires a lot of "forwarding code". That is, you
often have to write a bunch of Event-deriving classes whose sole purpose
in life is to forward the call to their notify method to a call to
another class' method with event-specific parameters. So, I have a small
make_event c++ template which can be used to do this sort of thing:

class MyClass {
void random_stuff (double id) {
	std::cout << "id="<<id<<"now=" Simulator::now_s () << std::endl;
}
};

MyClass *obj = new MyClass ();

Simulator->schedule (make_event (&MyClass::random_stuff, obj, 10.0));
Simulator->run ();

Okay, so, to wrap this, I wrapped my Simulator class and my EventWrap
class:
struct EventWrap : yans::Event
{
        EventWrap( PyObject* self_);
        virtual ~EventWrap();
        virtual void notify (void);
private:
        PyObject *m_self;
};
EventWrap::EventWrap (PyObject* self_)
        : m_self(self_)
{
        Py_INCREF(m_self);
}
EventWrap::~EventWrap()
{
        Py_DECREF(m_self);
}
void
EventWrap::notify (void)
{
        call_method<void>(m_self, "notify");
        delete this;
}

namespace boost { namespace python {
        template <>
        struct has_back_reference<EventWrap>
                : mpl::true_ {};
}}

void
export_event (void)
{
        class_<EventWrap, std::auto_ptr<EventWrap>, boost::noncopyable> event ("Event");
        event.def ("notify", pure_virtual(&Event::notify));
}

void
simu_insert_in_s (double delta, std::auto_ptr<EventWrap> ev)
{
        Simulator::insert_in_s (delta, ev.get ());
        ev.release ();
}

void
export_simulator (void)
{
	def ("run", Simulator::run);
        def ("insert_in_s", simu_insert_in_s);
}


which allows me to write the following python code:
class __MyEvent__(Event):
    def set_callback (self, function, *args):
        self.__function_ = function;
        self.__args_ = args;
    def notify (self):
        self.__function_ (*self.__args_);

def make_event(function, *args):
    ev = __MyEvent__ ();
    ev.set_callback (function, *args);
    return ev

def my_nothing0 ():
    print "my model now=%f" % simulator.now_s ();
simulator.insert_in_s (4.0, make_event (my_nothing1, 99));
simulator.run ()


okay, so all of this stuff works really nicely but there is a catch. I
would like to be able to write code such as:

simulator.insert_in_s (4.0, make_event (simulator.now_s));
simulator.run ()

and ensure that once simulator.run has reached the Simulator::run c++
method, no python code will be executed ever. Namely, I want call to
make_event to generate a nice C++ Event class which will not call back
into python's __MyEvent__.notify before calling simulator.now_s and
Simulator::now_s. i.e., it should call back Simulator::now_s directly.

The more I think about this, the less I see a way to do this with boost.
Have I missed something ?

Mathieu
-- 



From dave at boost-consulting.com  Fri Jan 13 00:08:16 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Jan 2006 18:08:16 -0500
Subject: [C++-sig] cvs update breaks some code (class_metadata.hpp)
References: <dq4fg9$4hf$1@sea.gmane.org>
Message-ID: <87r77dnixr.fsf@boost-consulting.com>

Brett Calcott <brett at coombs.anu.edu.au> writes:

> Hi,
>
> I have just updated from CVS. Some code of mine no longer compiles. I am 
> using VC 7.1 on Window XP Prof.
>
> Here is a short piece of code that compiles with CVS update from 1st 
> August 05, but not with the latest from 12th January 06.
>
> The problem occurs in class_metadata.hpp. A copy of the error produced 
> is below the code.
>
> I will investigate further, in the weekend. For now, if anyone has any 
> clues, let me know.

When you register a class derived from wrapper<B>, don't declare B to
be a base class (with bases<B>).  The library does that for you.


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



From dave at boost-consulting.com  Fri Jan 13 00:01:10 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Jan 2006 18:01:10 -0500
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
Message-ID: <87wth5nj9l.fsf@boost-consulting.com>

"Drumheller, Michael" <michael.drumheller at boeing.com> writes:

> This gmane entry 
> <<http://article.gmane.org/gmane.comp.python.c++/9049/match=pyplusplus+m
> ature>>
> says, among other things, the following
>
> """If you can, use pyplusplus over pyste. I say that for ALL users of
> pyste, pyplusplus is now mature enough to be useful as well as being
> actively developed. It can also do quite a few tricks pyste cannot."""
>
> If this is really the case, I think the Boost documentation needs to say
> so.  For example, the doc page
> <<http://www.boost.org/libs/python/pyste/>> does not give any warning
> that Pyste is essentially deprecated (which it apparently is, if the
> above quote is true).  

It may be deprecated by the author of that quote, but the author of
the quote has no official standing.

> Further, as far as I can tell there are no clues
> at <<http://www.boost.org/libs/libraries.htm#Inter-language>> indicating
> that users might want to check out pyplusplus, whereas the official
> Boost.Python page <<http://www.boost.org/libs/python/doc/index.html>>
> explicity directs users to Pyste.

The author of Pyplusplus has not proposed it as a replacement for
Pyste in Boost.

> The end result is that an innocent user who is new to integrating
> Python and C++ (like, um, say, me) could reasonably come away with
> the impression that the most state-of-the-art approach to use is
> Boost.Python+Pyste.
>
> As a side question, does anyone use Boost.Python *without* an
> automatic code generator such as Pyste or Pyplusplus?  

Yes, lots of people do.

> It does not seem like a practical thing to do--but maybe I'm missing
> something...?

Why do you say that?

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



From dave at boost-consulting.com  Fri Jan 13 03:51:32 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 12 Jan 2006 21:51:32 -0500
Subject: [C++-sig] optimizing away calls to the python runtime -- was
	[detecting if	a function is written in python or C++]
References: <1137074745.15517.102.camel@chronos>
Message-ID: <87irsoon63.fsf@boost-consulting.com>

Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> writes:

> hi,
>
> I apologize for this second email but the more I think about what I am
> trying to do, the less I see how to do it. So, here is a hopefully
> detailed explanation of what I am trying to achieve.
>
> Here are my c++ classes:
> class Event {
> virtual void notify (void) = 0;
> };
> class Simulator {
>  void schedule (Event *event);
>  double now_s (void); // return current time.
>  void run (void);
> };
>
> sample c++ use code:
> class MyEvent : public Event {
> virtual void notify (void) {
> 	std::cout << "now=" Simulator::now_s () << std::endl;
> 	delete this;
> }
> };
>
> Simulator->schedule (new MyEvent ());
> Simulator->run (); // invokes MyEvent::notify sometime later.
>
> This sort of code requires a lot of "forwarding code". That is, you
> often have to write a bunch of Event-deriving classes whose sole purpose
> in life is to forward the call to their notify method to a call to
> another class' method with event-specific parameters. So, I have a small
> make_event c++ template which can be used to do this sort of thing:
>
> class MyClass {
> void random_stuff (double id) {
> 	std::cout << "id="<<id<<"now=" Simulator::now_s () << std::endl;
> }
> };
>
> MyClass *obj = new MyClass ();
>
> Simulator->schedule (make_event (&MyClass::random_stuff, obj, 10.0));
> Simulator->run ();
>
> Okay, so, to wrap this, I wrapped my Simulator class and my EventWrap
> class:
> struct EventWrap : yans::Event
> {
>         EventWrap( PyObject* self_);
>         virtual ~EventWrap();
>         virtual void notify (void);
> private:
>         PyObject *m_self;
> };
> EventWrap::EventWrap (PyObject* self_)
>         : m_self(self_)
> {
>         Py_INCREF(m_self);
> }
> EventWrap::~EventWrap()
> {
>         Py_DECREF(m_self);
> }

This causes a double deletion.  Also, the Py_INCREF is somewhat evil
for other reasons.  In the Boost.Python object model, C++ objects are
owned by their Python wrappers, not vice-versa.  I think you'd be a
lot better off if you stopped trafficking in raw pointers and used
boost::shared_ptr<Event> instead.

> void
> EventWrap::notify (void)
> {
>         call_method<void>(m_self, "notify");

If this is related to your subject line, you should know that this
sort of old-style polymorphism does incur needless calls into Python.
Use derivation from boost::python::wrapper<Event> instead, with
get_override().

>         delete this;

There's that double-deletion again.

> }
>
> namespace boost { namespace python {
>         template <>
>         struct has_back_reference<EventWrap>
>                 : mpl::true_ {};
> }}
>
> void
> export_event (void)
> {
>         class_<EventWrap, std::auto_ptr<EventWrap>, boost::noncopyable> event ("Event");
>         event.def ("notify", pure_virtual(&Event::notify));
> }
>
> void
> simu_insert_in_s (double delta, std::auto_ptr<EventWrap> ev)
> {
>         Simulator::insert_in_s (delta, ev.get ());
>         ev.release ();
> }
>
> void
> export_simulator (void)
> {
> 	def ("run", Simulator::run);
>         def ("insert_in_s", simu_insert_in_s);
> }
>
>
> which allows me to write the following python code:
> class __MyEvent__(Event):

Bad idea to name your symbols that way; __XXX__ symbols are by
convention reserved to the Python language.

>     def set_callback (self, function, *args):
>         self.__function_ = function;
>         self.__args_ = args;
>     def notify (self):
>         self.__function_ (*self.__args_);
>
> def make_event(function, *args):
>     ev = __MyEvent__ ();
>     ev.set_callback (function, *args);
>     return ev
>
> def my_nothing0 ():
>     print "my model now=%f" % simulator.now_s ();
> simulator.insert_in_s (4.0, make_event (my_nothing1, 99));
> simulator.run ()
>
>
> okay, so all of this stuff works really nicely but there is a catch. I
> would like to be able to write code such as:
>
> simulator.insert_in_s (4.0, make_event (simulator.now_s));
> simulator.run ()
>
> and ensure that once simulator.run has reached the Simulator::run c++
> method, no python code will be executed ever. Namely, I want call to
> make_event to generate a nice C++ Event class which will not call back
> into python's __MyEvent__.notify before calling simulator.now_s and
> Simulator::now_s. i.e., it should call back Simulator::now_s directly.
> 
> The more I think about this, the less I see a way to do this with boost.
> Have I missed something ?

Use new-style polymorphism.

HTH,

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



From Mathieu.Lacage at sophia.inria.fr  Fri Jan 13 10:01:52 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 13 Jan 2006 10:01:52 +0100
Subject: [C++-sig] optimizing away calls to the python runtime --
	was	[detecting if	a function is written in python or C++]
In-Reply-To: <87irsoon63.fsf@boost-consulting.com>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
Message-ID: <1137142913.15517.167.camel@chronos>

On Thu, 2006-01-12 at 21:51 -0500, David Abrahams wrote:
> > Okay, so, to wrap this, I wrapped my Simulator class and my EventWrap
> > class:
> > struct EventWrap : yans::Event
> > {
> >         EventWrap( PyObject* self_);
> >         virtual ~EventWrap();
> >         virtual void notify (void);
> > private:
> >         PyObject *m_self;
> > };
> > EventWrap::EventWrap (PyObject* self_)
> >         : m_self(self_)
> > {
> >         Py_INCREF(m_self);
> > }
> > EventWrap::~EventWrap()
> > {
> >         Py_DECREF(m_self);
> > }
> 
> This causes a double deletion.  Also, the Py_INCREF is somewhat evil

I fail to see how it would cause a double deletion. It might create
leaks in certain conditions if the c++ code does not call delete at some
point but python should be forbidden from destroying this object because
I hold a refcount to it.

> for other reasons.  In the Boost.Python object model, C++ objects are
> owned by their Python wrappers, not vice-versa.  I think you'd be a

Yes, but my c++ object needs to ensure that the python object is live
when it calls back into it. If the Py_INCREF is not present, and if no
python variable holds a reference to the original python object, boom
when notify is called.

> lot better off if you stopped trafficking in raw pointers and used
> boost::shared_ptr<Event> instead.

Using shared_ptr would require my changing the c++ code to deal with
shared_ptr rather than raw pointers, am I right ?

> 
> > void
> > EventWrap::notify (void)
> > {
> >         call_method<void>(m_self, "notify");
> 
> If this is related to your subject line, you should know that this
> sort of old-style polymorphism does incur needless calls into Python.
> Use derivation from boost::python::wrapper<Event> instead, with
> get_override().

Ah. This is good to know. I used this call_method way because I already
had the private PyObject *m_self pointer because of the Py_INCREF so I
thought I could avoid duplicating PyObject * everywhere (in the wrapper
and in my code).

However, I don't think the boost::python::wrapper way of dealing with
this would completely eliminate the need to call back at least a bit
into python, am I wrong ?

> >         delete this;
> 
> There's that double-deletion again.


I do not think so. The C++ code is designed such that the Simulator::run
class does not deal with the memory management of the Event objects it
calls into. That is, it merely assumes that the lifetime of the Event
object is long enough to invoke Event::notify once and forget about it
after. It is up to the Event::notify and event constructor to deal with
the event's memory management. The c++ template make_event I use to
generate event forwarding classes does this automatically. It could be
argued that this is not very nice and I could even agree but, well.

As such, the wrapper I presented in this email does something like this:
  - python creates Event object which creates a c++ Event object
  - python passes python Event object to simulator.insert_in_s which
calls Simulator::insert_in_s which assumes ownership of the c++ Event *
passed.
  - python calls simulator.run which calls into Simulator::run
  - Simulator::run invokes c++ Event::notify which invokes back
Event.notify into python.
  - Event::notify deletes c++ object and should delete associated python
object.

I fail to see how the end-user API I want to offer could be implemented
in another way without changing the wrapped c++ code.

Changing the c++ code would require one of:
  - as suggested by you, using shared_ptr in the c++ code
  - Another solution might be to make the memory management issue
explicit at the C++ API level through some other mean than shared_ptr.
Adding a pair of ref/unref methods on the Event c++ class for example...

> > which allows me to write the following python code:
> > class __MyEvent__(Event):
> 
> Bad idea to name your symbols that way; __XXX__ symbols are by
> convention reserved to the Python language.

ok.

> 
> >     def set_callback (self, function, *args):
> >         self.__function_ = function;
> >         self.__args_ = args;
> >     def notify (self):
> >         self.__function_ (*self.__args_);
> >
> > def make_event(function, *args):
> >     ev = __MyEvent__ ();
> >     ev.set_callback (function, *args);
> >     return ev
> >
> > def my_nothing0 ():
> >     print "my model now=%f" % simulator.now_s ();
> > simulator.insert_in_s (4.0, make_event (my_nothing1, 99));
> > simulator.run ()
> >
> >
> > okay, so all of this stuff works really nicely but there is a catch. I
> > would like to be able to write code such as:
> >
> > simulator.insert_in_s (4.0, make_event (simulator.now_s));
> > simulator.run ()
> >
> > and ensure that once simulator.run has reached the Simulator::run c++
> > method, no python code will be executed ever. Namely, I want call to
> > make_event to generate a nice C++ Event class which will not call back
> > into python's __MyEvent__.notify before calling simulator.now_s and
> > Simulator::now_s. i.e., it should call back Simulator::now_s directly.
> > 
> > The more I think about this, the less I see a way to do this with boost.
> > Have I missed something ?
> 
> Use new-style polymorphism.

"new style polymorphism" is the use of get_override ? If so, you mean
that it can be made to call into c++ if python does not override the
function, right ?

Something like this ?

struct ACallback :  A, wrapper<A>
{
    char const* f()
    {
        if (override f = this->get_override("f"))
            return f();
        return A::f();
    }

    char const* default_f() { return this->A::f(); }
};

I don't think this is what I want to do. I would like to make python's
make_event function create the right underlying c++ Event class which,
rather than trying to call back into python does not bother with it and
just calls into c++ directly.

In case my description of my use-case is not very clear, here is the
real code for the c++ simulator:

http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=7912699843995beacf89cbb81ed1533c06bb2123;file=simulator/simulator.h
http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=bbc4194170ea5e790d9e296ff7037fda7954d152;file=simulator/event.h
http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=9f87c99c3c90b8cb9c60a64fdb27eb60f9807385;file=simulator/event.tcc

and the documentation for the API with sample c++ code:
http://spoutnik.inria.fr/code/yans/?cmd=file;file=doc/simulator.html;filenode=303f820404c45cc68d42d38728742b030ac50176;style=raw

the python binding code is there:
http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=a30e335d29d1c0fd68c21088474146c235e04303;file=python/event-wrap.h
http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=fc288ba73cfb6ab80e9d1728b3e2588821690400;file=python/export-event.cc
http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=231533788691a2a37d5f709ead483a5c0fd8a1c0;file=python/export-simulator.cc

and the sample python code:
http://spoutnik.inria.fr/code/yans/?cmd=file;filenode=46ff2d294159555a0178bac34169218691131864;file=python/test-simulator.py

you should be able to download and build that code if you use an x86
linux box with gcc 4.x
http://spoutnik.inria.fr/yans/releases/yans-0.3.tar.gz

It is hard for me to explain more clearly what I want to achieve because
I don't really understand enough template magic to understand how boost
python works and reformulate my problem in better terms.

thanks for your answer,
Mathieu
-- 



From ro4tub at gmail.com  Fri Jan 13 11:29:07 2006
From: ro4tub at gmail.com (Raul)
Date: Fri, 13 Jan 2006 18:29:07 +0800
Subject: [C++-sig] how to pass a c++ object to python?
Message-ID: <9a77767b0601130229l8d3b094jf97624a26f30ebfb@mail.gmail.com>

First i build a module like that:

/// game.cpp
#include <string>

class CEntity
{
private:
 std::string  m_strName;
public:
 CEntity(std::string name)
  :m_strName(name)
 {}
 std::string  Name() const
 {
  return m_strName;
 }
};


BOOST_PYTHON_MODULE(game)
{
 class_<CEntity>("CEntity", init<std::string>())
  .def("Name", &CEntity::Name);
}


/// foo.py
import game

def Foo():
 entity = game.CEntity("oscar")
 print "Hello,%s!" %entity.Name()

def FooWithArg(entity):
 name = entity.Name()
 print "Hello,%s!" %name



/// embed.cpp

CEntity entity("oscar");
/// call "FooWithArg(entity)" in the script file.

i want to ask how to pass the object 'entity' to the foo.py!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060113/fb2a575d/attachment.htm>

From dave at boost-consulting.com  Fri Jan 13 14:52:36 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 13 Jan 2006 08:52:36 -0500
Subject: [C++-sig] optimizing away calls to the python runtime --
	was	[detecting if	a function is written in python or C++]
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
Message-ID: <878xtkmdzv.fsf@boost-consulting.com>

Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> writes:

> On Thu, 2006-01-12 at 21:51 -0500, David Abrahams wrote:
>> > Okay, so, to wrap this, I wrapped my Simulator class and my EventWrap
>> > class:
>> > struct EventWrap : yans::Event
>> > {
>> >         EventWrap( PyObject* self_);
>> >         virtual ~EventWrap();
>> >         virtual void notify (void);
>> > private:
>> >         PyObject *m_self;
>> > };
>> > EventWrap::EventWrap (PyObject* self_)
>> >         : m_self(self_)
>> > {
>> >         Py_INCREF(m_self);
>> > }
>> > EventWrap::~EventWrap()
>> > {
>> >         Py_DECREF(m_self);
>> > }
>> 
>> This causes a double deletion.  Also, the Py_INCREF is somewhat evil
>
> I fail to see how it would cause a double deletion. 

~EventWrap is called because the event is being deleted.  It
decrements the refcount on the Python object that owns the very same
EventWrap object, which causes that Python object to be destroyed,
which causes it to attempt to destroy the EventWrap object it holds.

> It might create leaks in certain conditions if the c++ code does not
> call delete at some point but python should be forbidden from
> destroying this object because I hold a refcount to it.

You don't hold a refcount once you've Py_DECREF'd.

>> for other reasons.  In the Boost.Python object model, C++ objects are
>> owned by their Python wrappers, not vice-versa.  I think you'd be a
>
> Yes, but my c++ object needs to ensure that the python object is live
> when it calls back into it. If the Py_INCREF is not present, and if no
> python variable holds a reference to the original python object, boom
> when notify is called.

Use shared_ptr if you can.  Regardless, don't expect the 

>> lot better off if you stopped trafficking in raw pointers and used
>> boost::shared_ptr<Event> instead.
>
> Using shared_ptr would require my changing the c++ code to deal with
> shared_ptr rather than raw pointers, am I right ?

Yes.

>> > void
>> > EventWrap::notify (void)
>> > {
>> >         call_method<void>(m_self, "notify");
>> 
>> If this is related to your subject line, you should know that this
>> sort of old-style polymorphism does incur needless calls into Python.
>> Use derivation from boost::python::wrapper<Event> instead, with
>> get_override().
>
> Ah. This is good to know. I used this call_method way because I already
> had the private PyObject *m_self pointer because of the Py_INCREF so I
> thought I could avoid duplicating PyObject * everywhere (in the wrapper
> and in my code).
>
> However, I don't think the boost::python::wrapper way of dealing with
> this would completely eliminate the need to call back at least a bit
> into python, am I wrong ?

It depends on what you're doing, a clear picture of which I do not yet
have.  It eliminates the need to call back into Python when you call a
virtual function on a wrapped class instance and that virtual function
has *not* been overridden.

>> >         delete this;
>> 
>> There's that double-deletion again.
>
>
> I do not think so. The C++ code is designed such that the Simulator::run
> class does not deal with the memory management of the Event objects it
> calls into. That is, it merely assumes that the lifetime of the Event
> object is long enough to invoke Event::notify once and forget about it
> after. It is up to the Event::notify and event constructor to deal with
> the event's memory management. 

If the Python object is trying to deal with the event's lifetime
management simultaneously, you're going to have trouble. AFAICT
you haven't done anything to prevent the Python object from trying to
manage the lifetime of the Event.

> The c++ template make_event I use to
> generate event forwarding classes does this automatically. It could be
> argued that this is not very nice and I could even agree but, well.
>
> As such, the wrapper I presented in this email does something like this:
>   - python creates Event object which creates a c++ Event object
>   - python passes python Event object to simulator.insert_in_s which
> calls Simulator::insert_in_s which assumes ownership of the c++ Event *
> passed.

The reason shared_ptr works is that when you grab the shared_ptr, it
assumes ownership of the owning Python object and points to the C++
object.

>   - python calls simulator.run which calls into Simulator::run
>   - Simulator::run invokes c++ Event::notify which invokes back
> Event.notify into python.
>   - Event::notify deletes c++ object and should delete associated python
> object.
>
> I fail to see how the end-user API I want to offer could be implemented
> in another way without changing the wrapped c++ code.

Hold the EventWrap with an auto_ptr.  In its destructor, do
extract<auto_ptr<EventWrap>&>(self)().reset() before the
Py_DECREF(self).  Then you've at least broken the ownership cycle,
other evils notwithstanding.

> Changing the c++ code would require one of:
>   - as suggested by you, using shared_ptr in the c++ code
>   - Another solution might be to make the memory management issue
> explicit at the C++ API level through some other mean than shared_ptr.
> Adding a pair of ref/unref methods on the Event c++ class for example...
>
>> > which allows me to write the following python code:
>> > class __MyEvent__(Event):
>> 
>> Bad idea to name your symbols that way; __XXX__ symbols are by
>> convention reserved to the Python language.
>
> ok.
>
>> 
>> >     def set_callback (self, function, *args):
>> >         self.__function_ = function;
>> >         self.__args_ = args;
>> >     def notify (self):
>> >         self.__function_ (*self.__args_);
>> >
>> > def make_event(function, *args):
>> >     ev = __MyEvent__ ();
>> >     ev.set_callback (function, *args);
>> >     return ev
>> >
>> > def my_nothing0 ():
>> >     print "my model now=%f" % simulator.now_s ();
>> > simulator.insert_in_s (4.0, make_event (my_nothing1, 99));
>> > simulator.run ()
>> >
>> >
>> > okay, so all of this stuff works really nicely but there is a catch. I
>> > would like to be able to write code such as:
>> >
>> > simulator.insert_in_s (4.0, make_event (simulator.now_s));
>> > simulator.run ()
>> >
>> > and ensure that once simulator.run has reached the Simulator::run c++
>> > method, no python code will be executed ever. Namely, I want call to
>> > make_event to generate a nice C++ Event class which will not call back
>> > into python's __MyEvent__.notify before calling simulator.now_s and
>> > Simulator::now_s. i.e., it should call back Simulator::now_s directly.
>> > 
>> > The more I think about this, the less I see a way to do this with boost.
>> > Have I missed something ?
>> 
>> Use new-style polymorphism.
>
> "new style polymorphism" is the use of get_override ? If so, you mean
> that it can be made to call into c++ if python does not override the
> function, right ?

Right.

> Something like this ?
>
> struct ACallback :  A, wrapper<A>
> {
>     char const* f()
>     {
>         if (override f = this->get_override("f"))
>             return f();
>         return A::f();
>     }
>
>     char const* default_f() { return this->A::f(); }
> };
>
> I don't think this is what I want to do. I would like to make python's
> make_event function create the right underlying c++ Event class which,
> rather than trying to call back into python does not bother with it and
> just calls into c++ directly.
>
> In case my description of my use-case is not very clear, here is the
> real code for the c++ simulator:

Sorry, I don't have time right now to look into your case in that kind
of detail. :(

With Regret,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From Mathieu.Lacage at sophia.inria.fr  Fri Jan 13 15:19:02 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 13 Jan 2006 15:19:02 +0100
Subject: [C++-sig] optimizing away calls to the python runtime
	--	was	[detecting if	a function is written in python or C++]
In-Reply-To: <878xtkmdzv.fsf@boost-consulting.com>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
Message-ID: <1137161942.15517.204.camel@chronos>

On Fri, 2006-01-13 at 08:52 -0500, David Abrahams wrote:

[snip interesting answers to my questions]

> If the Python object is trying to deal with the event's lifetime
> management simultaneously, you're going to have trouble. AFAICT
> you haven't done anything to prevent the Python object from trying to
> manage the lifetime of the Event.

I thought the use of auto_ptr made python give up ownership of the
pointer and this is what my (rather limited) testing confirmed. Maybe
this is not the case which means that the double free will byte me and I
am screwed :/

This is what I did which, given some other comments below, is probably
what you suggest me to do.

void
simu_insert_in_s (double delta, std::auto_ptr<EventWrap> ev)
{
        Simulator::insert_in_s (delta, ev.get ());
        ev.release ();
}

[snip other interesting things]

> >   - python calls simulator.run which calls into Simulator::run
> >   - Simulator::run invokes c++ Event::notify which invokes back
> > Event.notify into python.
> >   - Event::notify deletes c++ object and should delete associated python
> > object.
> >
> > I fail to see how the end-user API I want to offer could be implemented
> > in another way without changing the wrapped c++ code.
> 
> Hold the EventWrap with an auto_ptr.  In its destructor, do

This, I do already. Maybe my original message was missing this.

> extract<auto_ptr<EventWrap>&>(self)().reset() before the

What I have currently is the same except for that call to reset which I
am not sure I understand. I suspect it is supposed to ask the auto_ptr
held by the wrapper to stop worrying about my object. If this is so, I
fail to see how my code could work without it because I should have had
a double free: one induced by my call to delete and the other induced by
the auto_ptr held by the python object when its last refcount is
released. Obviously, I don't have a double-free for now so... I am
probably just lucky.

I will look into this in more detail.

> Py_DECREF(self).  Then you've at least broken the ownership cycle,
> other evils notwithstanding.

understood.

[snip]

> Sorry, I don't have time right now to look into your case in that kind
> of detail. :(

Yes, I did not expect you to do my job for me but you cannot reproach me
trying to make you do it anyway :)

thanks a lot again for your thoughtful answers,
Mathieu
-- 



From dave at boost-consulting.com  Fri Jan 13 20:58:59 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 13 Jan 2006 14:58:59 -0500
Subject: [C++-sig] optimizing away calls to the python runtime
	--	was	[detecting if	a function is written in python or C++]
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
Message-ID: <87k6d3lx18.fsf@boost-consulting.com>

Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> writes:

> On Fri, 2006-01-13 at 08:52 -0500, David Abrahams wrote:
>
> [snip interesting answers to my questions]
>
>> If the Python object is trying to deal with the event's lifetime
>> management simultaneously, you're going to have trouble. AFAICT
>> you haven't done anything to prevent the Python object from trying to
>> manage the lifetime of the Event.
>
> I thought the use of auto_ptr made python give up ownership of the
> pointer and this is what my (rather limited) testing confirmed. 

You're right; I missed that, sorry.

> This is what I did which, given some other comments below, is
> probably what you suggest me to do.
>
> void
> simu_insert_in_s (double delta, std::auto_ptr<EventWrap> ev)
> {
>         Simulator::insert_in_s (delta, ev.get ());
>         ev.release ();
> }
>
> [snip other interesting things]
>
>> >   - python calls simulator.run which calls into Simulator::run
>> >   - Simulator::run invokes c++ Event::notify which invokes back
>> > Event.notify into python.
>> >   - Event::notify deletes c++ object and should delete associated python
>> > object.
>> >
>> > I fail to see how the end-user API I want to offer could be implemented
>> > in another way without changing the wrapped c++ code.
>> 
>> Hold the EventWrap with an auto_ptr.  In its destructor, do
>
> This, I do already. Maybe my original message was missing this.
>
>> extract<auto_ptr<EventWrap>&>(self)().reset() before the
>
> What I have currently is the same except for that call to reset
> which I am not sure I understand. I suspect it is supposed to ask
> the auto_ptr held by the wrapper to stop worrying about my
> object. If this is so, I fail to see how my code could work without
> it because I should have had a double free: one induced by my call
> to delete and the other induced by the auto_ptr held by the python
> object when its last refcount is released. Obviously, I don't have a
> double-free for now so... I am probably just lucky.

No, you're OK.

> I will look into this in more detail.
>
>> Py_DECREF(self).  Then you've at least broken the ownership cycle,
>> other evils notwithstanding.
>
> understood.
>
> [snip]
>
>> Sorry, I don't have time right now to look into your case in that kind
>> of detail. :(
>
> Yes, I did not expect you to do my job for me but you cannot reproach me
> trying to make you do it anyway :)
>
> thanks a lot again for your thoughtful answers,
> Mathieu
> -- 

Good luck.

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



From Rpr1969 at aol.com  Sat Jan 14 17:44:10 2006
From: Rpr1969 at aol.com (Rpr1969 at aol.com)
Date: Sat, 14 Jan 2006 11:44:10 EST
Subject: [C++-sig]  Joel de Guzman from Bacolod
Message-ID: <e8.2340a1fe.30fa845a@aol.com>

i don't know if you found this person already.  if not.  is he from 
villamonte bacolod city?
 
rommel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060114/ab4565d1/attachment.htm>

From abierbaum at gmail.com  Sat Jan 14 23:30:53 2006
From: abierbaum at gmail.com (Allen Bierbaum)
Date: Sat, 14 Jan 2006 16:30:53 -0600
Subject: [C++-sig] Pyplusplus templates and roadmap
Message-ID: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>

I am looking at using pyplusplus to replace my current usage of Pyste
on one of my projects.  In reading through the comparison between the
two (http://www.language-binding.net/pyplusplus/to_pyste_comparison.html)
it looks like pyplusplus does not support templates.  Unfortunately my
current project makes extensive use of templates so I may need to hold
off on converting it.

Taking that in account, is there a development roadmap for future
features of pyplusplus?  Will  it support templates at any point in
the near future.

Thanks,
Allen


From abierbaum at gmail.com  Sat Jan 14 23:31:51 2006
From: abierbaum at gmail.com (Allen Bierbaum)
Date: Sat, 14 Jan 2006 16:31:51 -0600
Subject: [C++-sig] Consensus on threading with Boost.Python?
Message-ID: <bea9869d0601141431l37f14adcga12b61a2acd2894c@mail.gmail.com>

I have been using Boost.Python with C++ threads for quite a while and
have been following the discussions over the past several years on this
list about how to accomplish this feat.  As it stands right now, I can
make it work but there is quite a bit of hand waving and manual coding
involved that is fairly error prone and has never really felt right to
me.  It has gotten to the point where I really need a complete solution.

So I was wondering, of the other people using Boost.Python with C++
threads, is there any sort of consensus on what is the best or more
appropriate way to do this?  Will any method ever end up being
incorporated into Boost.Python? I know David has made comments on this
list that he would like to support it, but no good solution has been
found thus far)\.

To see the discussion so far, you can start by looking at the following
threads:

http://aspn.activestate.com/ASPN/Mail/Message/2944336
http://aspn.activestate.com/ASPN/Mail/Message/2260350
http://aspn.activestate.com/ASPN/Mail/Message/2260648
http://aspn.activestate.com/ASPN/Mail/Message/1784436
http://aspn.activestate.com/ASPN/Mail/Message/1465959
http://aspn.activestate.com/ASPN/Mail/Message/1603259
http://aspn.activestate.com/ASPN/Mail/Message/1607050
http://aspn.activestate.com/ASPN/Mail/Message/1706806

There have been patches proposed by Niall Douglas and Lijun Qin, but it
seems that each of those had some limitations or constraints that made
it less then perfect for a full solution.

What is left to address?  What would it take to create a standard
threading solution that would work for most people in most cases?

-Allen


From dave at boost-consulting.com  Sun Jan 15 04:21:14 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 14 Jan 2006 22:21:14 -0500
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
	<87wth5nj9l.fsf@boost-consulting.com>
Message-ID: <877j92gor9.fsf@boost-consulting.com>

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

> "Drumheller, Michael" <michael.drumheller at boeing.com> writes:
>
>> This gmane entry 
>> <<http://article.gmane.org/gmane.comp.python.c++/9049/match=pyplusplus+m
>> ature>>
>> says, among other things, the following
>>
>> """If you can, use pyplusplus over pyste. I say that for ALL users of
>> pyste, pyplusplus is now mature enough to be useful as well as being
>> actively developed. It can also do quite a few tricks pyste cannot."""
>>
>> If this is really the case, I think the Boost documentation needs to say
>> so.  For example, the doc page
>> <<http://www.boost.org/libs/python/pyste/>> does not give any warning
>> that Pyste is essentially deprecated (which it apparently is, if the
>> above quote is true).  
>
> It may be deprecated by the author of that quote, but the author of
> the quote has no official standing.

I should clarify that I don't mean any disrespect to Niall (the author
of the quote) and I am not hostile to pyplusplus.  However, Roman (the
author of pyplusplus) has not made the sort of overtures I would
expect in order to get it to be officially endorsed by Boost(.Python).
He has been very "independent-minded," doing most of pyplusplus on his
own and rejecting the idea of working with the author of Pyste, from
whom he might have learned a few things, Pyste's weaknesses
notwithstanding.  Without more coordination with the community it
should be no surprise that the community is not linking more to
pyplusplus.  If it is indeed more capable than Pyste I would like to
be referencing it as the de-facto generator for Boost.Python wrpapers.

Is it a complete replacement for pyste?  What should a Pyste user do
in order make his code us pyplusplus instead?  IMO there ought to be a
Pyste compatibility layer.

I think
http://www.language-binding.net/pyplusplus/to_pyste_comparison.html
would be a lot better if it took a more neutral tone; it seems to bash
Pyste a lot more than necessary.  Fortunately, this page doesn't seem
to be linked from the pyplusplus main page but if Boost is going to
endorse pyplusplus, that same information *ought* to be made more
generally available.

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



From roman.yakovenko at gmail.com  Sun Jan 15 07:08:51 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 15 Jan 2006 08:08:51 +0200
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <877j92gor9.fsf@boost-consulting.com>
References: <716621DCB4468F46BBCC1BCFBED45C120129DACD@XCH-NW-2V2.nw.nos.boeing.com>
	<87wth5nj9l.fsf@boost-consulting.com>
	<877j92gor9.fsf@boost-consulting.com>
Message-ID: <7465b6170601142208n2436c9adj9abe7b25525c0c90@mail.gmail.com>

On 1/15/06, David Abrahams <dave at boost-consulting.com> wrote:
> David Abrahams <dave at boost-consulting.com> writes:
> I should clarify that I don't mean any disrespect to Niall (the author
> of the quote) and I am not hostile to pyplusplus.  However, Roman (the
> author of pyplusplus) has not made the sort of overtures I would
> expect in order to get it to be officially endorsed by Boost(.Python).

Because, pyplusplus does not have good documentation. Correct me if I wrong,
but it is a must condition, in order to be part of boost. I used boost
libraries for more
then 3 years and enjoyed from high standards. When pyplusplus will
rich the state,
I will submit it. Until then, may be you can add reference to pyplsuplus?
You do not have to make it official or state about it's usefulness. Could you?

> He has been very "independent-minded," doing most of pyplusplus on his
> own and rejecting the idea of working with the author of Pyste, from
> whom he might have learned a few things, Pyste's weaknesses
> notwithstanding.

This is partially true, all development, design and analysis I did my
self - true.
But I studied almost every post about Pyste and desired functionality from it.
Although I had few private conversations with Pyste author.

> Without more coordination with the community it
> should be no surprise that the community is not linking more to
> pyplusplus.  If it is indeed more capable than Pyste I would like to
> be referencing it as the de-facto generator for Boost.Python wrpapers.

I think that lack of good documentation, that is the reason. And yes -
it is more
capable then Pyste.

> Is it a complete replacement for pyste?

Yes and no. Yes - all functionality that exists in Pyste also exists
in pyplusplus.
( If not, I am willing to fix it ). No - because it is not drop in
replacement of Pyste.

> What should a Pyste user do in order make his code us pyplusplus instead?
> IMO there ought to be a Pyste compatibility layer.

I searched google for projects that use Pyste. The only project I
found was TnFox.
I worked very closed with Niall to help him to switch his project from
Pyste to pyplusplus.
I will do the same thing with any Pyste user.

Also I asked on this list
(http://article.gmane.org/gmane.comp.python.c++/8340/match=pyste)
how big Pyste's user base is? It seems that nobody answer this question.
For my opinion, because everybody, who used Pyste, used it for "first" time
code generation only. I did it my self for my projects.

> I think
> http://www.language-binding.net/pyplusplus/to_pyste_comparison.html
> would be a lot better if it took a more neutral tone; it seems to bash
> Pyste a lot more than necessary.

English is not my native language, neither I good in writing articles.
Also diplomatic is not my strong side. If you have concrete suggestions,
I promise to change my article. Nicodemus, the Pyste author, read that article
and said that most of it is correct. I removed wrong information from
the article.

>Fortunately, this page doesn't seem
> to be linked from the pyplusplus main page but if Boost is going to
> endorse pyplusplus, that same information *ought* to be made more
> generally available.
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

Roman Yakovenko


From roman.yakovenko at gmail.com  Sun Jan 15 07:21:52 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 15 Jan 2006 08:21:52 +0200
Subject: [C++-sig] Pyplusplus templates and roadmap
In-Reply-To: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>
References: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>
Message-ID: <7465b6170601142221g46162939n2a48b058ea18722f@mail.gmail.com>

On 1/15/06, Allen Bierbaum <abierbaum at gmail.com> wrote:
> I am looking at using pyplusplus to replace my current usage of Pyste
> on one of my projects.  In reading through the comparison between the
> two (http://www.language-binding.net/pyplusplus/to_pyste_comparison.html)
> it looks like pyplusplus does not support templates.

It does not supports templates as Pyste. This is true. But pyplusplus
provides you with
an other way. Can you take a look at boost.date_time library? This
library is "one big template". I exposed whole library to show the
power of pyplusplus. I am almost sure you
can do the same with your library too. You can find relevant files
within "examples" directory.

>Unfortunately my
> current project makes extensive use of templates so I may need to hold
> off on converting it.
> Taking that in account, is there a development roadmap for future
> features of pyplusplus?  Will  it support templates at any point in
> the near future.

Please, take a look on boost.date_time example. If you still need some
functionality,
 changes in interface or suggestions - I am here.

> Thanks,
> Allen

If you decide not to switch from Pyste I would like to hear the reasons.

Good luck.

Roman Yakovenko


From roman.yakovenko at gmail.com  Sun Jan 15 07:29:19 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 15 Jan 2006 08:29:19 +0200
Subject: [C++-sig] how to pass a c++ object to python?
In-Reply-To: <9a77767b0601130229l8d3b094jf97624a26f30ebfb@mail.gmail.com>
References: <9a77767b0601130229l8d3b094jf97624a26f30ebfb@mail.gmail.com>
Message-ID: <7465b6170601142229w10761461u32760c5dd10eb166@mail.gmail.com>

On 1/13/06, Raul <ro4tub at gmail.com> wrote:

>
>  /// embed.cpp
>
> CEntity entity("oscar");
> /// call "FooWithArg(entity)" in the script file.
>
> i want to ask how to pass the object 'entity' to the foo.py!

Read this page: http://boost.org/libs/python/doc/v2/scope.html

bp::scope().attr("entity") = entity;

Take a look at pyplusplus code generator. For example this code has
been generated for
your code, using pyplusplus GUI:

namespace bp = boost::python;

BOOST_PYTHON_MODULE(pyplusplus){
    bp::class_< CEntity >( "CEntity", bp::init< std::string >((
bp::arg("name") ))[bp::default_call_policies()] )
        .def( "Name"
                , (::std::string ( ::CEntity::* )(  ) const)(&CEntity::Name)
                , bp::default_call_policies() );

    bp::scope().attr("entity") = entity;
}


Roman Yakovenko


From s_sourceforge at nedprod.com  Sun Jan 15 12:34:33 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 15 Jan 2006 11:34:33 -0000
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <877j92gor9.fsf@boost-consulting.com>
Message-ID: <43CA3349.20009.22E1E9AD@s_sourceforge.nedprod.com>

On 14 Jan 2006 at 22:21, David Abrahams wrote:

> >> """If you can, use pyplusplus over pyste. I say that for ALL users of
> >> pyste, pyplusplus is now mature enough to be useful as well as being
> >> actively developed. It can also do quite a few tricks pyste cannot."""
> >>
> >> If this is really the case, I think the Boost documentation needs to say
> >> so.  For example, the doc page
> >> <<http://www.boost.org/libs/python/pyste/>> does not give any warning
> >> that Pyste is essentially deprecated (which it apparently is, if the
> >> above quote is true).  
> >
> > It may be deprecated by the author of that quote, but the author of
> > the quote has no official standing.
> 
> I should clarify that I don't mean any disrespect to Niall (the author
> of the quote) and I am not hostile to pyplusplus. 

I should also clarify. pyplusplus is superior to pyste, but it 
doesn't mean pyplusplus is good enough to replace pyste yet. I have 
still to generate a working binary using pyplusplus (which is because 
I have had so little free time recently rather than any fault with 
the software) and until I do have a fully working binary, I wouldn't 
recommend submitting any Boost.Python documentation patches.

TnFOX is to my knowledge the biggest and most complex user of pyste - 
perhaps even Boost.Python if the bindings library size is to be 
judged. Pyplusplus generates far more efficient code (which is also 
easier to debug) so it's entirely possible I'll get a far smaller 
binding too. It's all good, but it's not there quite yet.

> However, Roman (the
> author of pyplusplus) has not made the sort of overtures I would
> expect in order to get it to be officially endorsed by Boost(.Python).
> He has been very "independent-minded," doing most of pyplusplus on his
> own and rejecting the idea of working with the author of Pyste, from
> whom he might have learned a few things, Pyste's weaknesses
> notwithstanding.  Without more coordination with the community it
> should be no surprise that the community is not linking more to
> pyplusplus.  If it is indeed more capable than Pyste I would like to
> be referencing it as the de-facto generator for Boost.Python wrpapers.

With respect Dave, you never have used pyste yourself in anger and so 
are completely unaware of its strengths and failings. If I were you, 
I would have tested it myself extensively before allowing it into my 
CVS - it after all will be the first thing most users see of your 
library and often the *only* thing they see. Its strengths and 
weaknesses reflect strongly on BPL.

Now pyste needed rewriting - it had run into architectural limits. 
And I admit I had doubts when Roman started saying he was going to 
write a replacement - admittedly not helped by his poor English. 
However, when literally out of the blue he sent me a set of new TnFOX 
bindings about 98% complete I was quite blown away. Since then as I 
have delved into his source, I realise that he is a very competent 
coder and has got the design right from the beginning - which Bruno 
(and my respect to you nevertheless) did not. There are still some 
rough spots (like default parameters), but it's very nearly perfect 
on the generation front.

> Is it a complete replacement for pyste?  What should a Pyste user do
> in order make his code us pyplusplus instead?  IMO there ought to be a
> Pyste compatibility layer.

That would be inadvisable. The best thing is for pyste users to 
regenerate their config files from scratch as pyplusplus uses quite a 
different configuration model (nowhere near as easy, but considerably 
more powerful).

> I think
> http://www.language-binding.net/pyplusplus/to_pyste_comparison.html
> would be a lot better if it took a more neutral tone; it seems to bash
> Pyste a lot more than necessary.  Fortunately, this page doesn't seem
> to be linked from the pyplusplus main page but if Boost is going to
> endorse pyplusplus, that same information *ought* to be made more
> generally available.

No Roman is being fair on that page. He nor I mean no disrespect to 
Bruno, pyste is a good bindings generator but it has hard design 
limits in it and Roman gives a pretty good overview of those.

I should add that when Roman says it doesn't support templates, he 
doesn't mean it doesn't support template *instances* which it does 
(again, there are some rough spots here, but it's as good or better 
than pyste).

I think we're all getting ahead of ourselves. My last exam is on the 
20th January after which I have one free week. During this week, I 
have two items on the plan:

1. Write article for Economics journal
2. Finish pyplusplus bindings in TnFOX

If I finish the latter, I will submit a BPL documentation patch to 
alert users that pyplusplus exists and what it can do. Before 
pyplusplus could become part of BPL it would need extensive amounts 
of documenting, and unless someone volunteers then that won't be 
soon.

Cheers,
Niall





From s_sourceforge at nedprod.com  Sun Jan 15 12:34:33 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 15 Jan 2006 11:34:33 -0000
Subject: [C++-sig] Consensus on threading with Boost.Python?
In-Reply-To: <bea9869d0601141431l37f14adcga12b61a2acd2894c@mail.gmail.com>
Message-ID: <43CA3349.20868.22E1E95F@s_sourceforge.nedprod.com>

On 14 Jan 2006 at 16:31, Allen Bierbaum wrote:

> http://aspn.activestate.com/ASPN/Mail/Message/2944336
> http://aspn.activestate.com/ASPN/Mail/Message/2260350
> http://aspn.activestate.com/ASPN/Mail/Message/2260648
> http://aspn.activestate.com/ASPN/Mail/Message/1784436
> http://aspn.activestate.com/ASPN/Mail/Message/1465959
> http://aspn.activestate.com/ASPN/Mail/Message/1603259
> http://aspn.activestate.com/ASPN/Mail/Message/1607050
> http://aspn.activestate.com/ASPN/Mail/Message/1706806
> 
> There have been patches proposed by Niall Douglas and Lijun Qin, but it
> seems that each of those had some limitations or constraints that made
> it less then perfect for a full solution.
> 
> What is left to address?  What would it take to create a standard
> threading solution that would work for most people in most cases?

Well the TnFOX solution does have the advantage of transparent 
operation but I agree it unlocks and locks the python GIL far too 
often.

Ideally BPL should provide some method of marking up which entrances 
in and out of Python should affect the python GIL. Then you can 
annotate as desired.

The latest version of that threading patch to BPL is at 
http://svn.berlios.de/viewcvs/tnfox/trunk/Python/BoostPatches.zip?view
=log

Cheers,
Niall





From abierbaum at gmail.com  Sun Jan 15 17:28:07 2006
From: abierbaum at gmail.com (Allen Bierbaum)
Date: Sun, 15 Jan 2006 10:28:07 -0600
Subject: [C++-sig] Pyplusplus templates and roadmap
In-Reply-To: <7465b6170601142221g46162939n2a48b058ea18722f@mail.gmail.com>
References: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>
	<7465b6170601142221g46162939n2a48b058ea18722f@mail.gmail.com>
Message-ID: <bea9869d0601150828v46ddf928jf914ced795e8a861@mail.gmail.com>

On 1/15/06, Roman Yakovenko <roman.yakovenko at gmail.com> wrote:
> On 1/15/06, Allen Bierbaum <abierbaum at gmail.com> wrote:
> > I am looking at using pyplusplus to replace my current usage of Pyste
> > on one of my projects.  In reading through the comparison between the
> > two (http://www.language-binding.net/pyplusplus/to_pyste_comparison.html)
> > it looks like pyplusplus does not support templates.
>
> It does not supports templates as Pyste. This is true. But pyplusplus
> provides you with
> an other way. Can you take a look at boost.date_time library? This
> library is "one big template". I exposed whole library to show the
> power of pyplusplus. I am almost sure you
> can do the same with your library too. You can find relevant files
> within "examples" directory.

I took a look at this library, but unfortunately I can't really make
heads or tails of it because I can't find any documentation about the
basics.  I just don't understand enough about the model used by
pyplusplus to be able to understand the python code used to generate
the wrappings.

The one thing I think I really need (and I think is needed in general
before many others will port over from Pyste) is a coupld of simple
tutorial examples.  I applaud you for including detailed examples of
using pyplusplus to wrap existing libraries, but this doesn't really
explain how to use it.

What I would like to see is a simple tutorial similar to the pyste
documentation in Boost.Python.  Just step by step instructions for how
to wrap a simple class or two and an explaination of why each step
matters and how it works.  This would do more for me then providing
wrappers for any number of libraries.

I should say that after seeing the lack of documentation I did take a
stab at the classic "look at the source" method of figuring things out
but there are so few coments in the code that this didn't work out
well.  I would highly suggest that in addition to a tutorial you
provide a short design document as an introduction for developers and
then document the actual code.  My hope is that this will allow others
to extend, maintain, and build upon the current code base.

>
> >Unfortunately my
> > current project makes extensive use of templates so I may need to hold
> > off on converting it.
> > Taking that in account, is there a development roadmap for future
> > features of pyplusplus?  Will  it support templates at any point in
> > the near future.
>
> Please, take a look on boost.date_time example. If you still need some
> functionality,
>  changes in interface or suggestions - I am here.
>
> > Thanks,
> > Allen
>
> If you decide not to switch from Pyste I would like to hear the reasons.

I have hit the limits of Pyste.  I have to create quite of bit of
custom code and manual edits for most projects I wrap and that just
doesn't scal well.  I have 4-5 projects I would like to move over to
use pyplusplus as soon as possible.  The largest of these projects
makes use of about 11,000 lines of Boost.Python wrapper code generated
from a combination of Pyste and custom scripts.

The only thing that is keeping me from trying to port right now is the
lack of a tutorial that explains how to wrap a library.

Please keep up the good work.  I think your solution looks like it is
very powerful, I just wish I could figure it out. :)

-Allen

>
> Good luck.
>
> Roman Yakovenko
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>


From Paul_Kunz at slac.stanford.edu  Sun Jan 15 23:57:00 2006
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Sun, 15 Jan 2006 14:57:00 -0800
Subject: [C++-sig] problem with numarray >= 1.4
Message-ID: <200601152257.k0FMv00W001881@libra3.slac.stanford.edu>

I'm having trouble using numarray >= 1.4.1 with Boost.Python.
I create a numarry called `high' (code to follow), and I get the
following

>>> h = high[1]
>>> h.__class__
<class 'numarray.numarraycore.NumArray'>
>>> hh = h/10
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209083328 (LWP 8852)]
0x007215b0 in array_divide (m1=0xbff0b2a8, m2=0xbff0b2a8)
    at Src/_numarraymodule.c:512
(gdb) 

(gdb) p *m1
$14 = {
  ob_refcnt = 162902820, 
  ob_type = 0x923ceac, 
  data = 0x811f080 "M\t", 
  nd = 134660512, 
  dimensions = 0xbff0b2e8, 
  strides = 0x80589e3, 
  base = 0x9b5b324, 
  descr = 0x923ceac, 
  flags = 10734442, 
  _dimensions = {7476576, 12, 153341612, 162902820, 153341612, 162902820, 
 
< snip >

i.e., its looks like garbage.   However if I do

>>> h = high[1]
>>> h.__class__
<class 'numarray.numarraycore.NumArray'>
>>> h
< snip the output which looks correct
>>> hh = h/10
>>>

It just works as expected.   For numarray 1.3, both cases work fine.

Here's how I create the numarray in my c++ code


boost::python::numeric::array
PyDataSource::
columnAsNumArray( const std::string & colname ) const {
   typedef std::vector<double> vec;
   const vec & array = m_dataSource->getColumn(colname);
   numeric::array na 
     = num_util::makeNum(&const_cast<vec &>(array)[0], array.size() );

   return na;
}

Where the num_util implementation is

numeric::array makeNum(double * data, int n=0){
  object obj(handle<>(PyArray_FromDims(1, &n, PyArray_DOUBLE)));
  char *arr_data = ((PyArrayObject*) obj.ptr())->data;
  memcpy(arr_data, data, sizeof(double) * n);
  return extract<numeric::array>(obj);
}

   Any clues?


From roman.yakovenko at gmail.com  Mon Jan 16 06:21:46 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 16 Jan 2006 07:21:46 +0200
Subject: [C++-sig] Pyplusplus templates and roadmap
In-Reply-To: <bea9869d0601150828v46ddf928jf914ced795e8a861@mail.gmail.com>
References: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>
	<7465b6170601142221g46162939n2a48b058ea18722f@mail.gmail.com>
	<bea9869d0601150828v46ddf928jf914ced795e8a861@mail.gmail.com>
Message-ID: <7465b6170601152121r5a117ee8jae87577a3bfd494a@mail.gmail.com>

On 1/15/06, Allen Bierbaum <abierbaum at gmail.com> wrote:
> I took a look at this library, but unfortunately I can't really make
> heads or tails of it because I can't find any documentation about the
> basics.  I just don't understand enough about the model used by
> pyplusplus to be able to understand the python code used to generate
> the wrappings.
>
> The one thing I think I really need (and I think is needed in general
> before many others will port over from Pyste) is a coupld of simple
> tutorial examples.  I applaud you for including detailed examples of
> using pyplusplus to wrap existing libraries, but this doesn't really
> explain how to use it.

I will write some small example\tutorial and will post it in few days.

> What I would like to see is a simple tutorial similar to the pyste
> documentation in Boost.Python.  Just step by step instructions for how
> to wrap a simple class or two and an explaination of why each step
> matters and how it works.  This would do more for me then providing
> wrappers for any number of libraries.

Meanwhile you can take a look at 2 examples: EasyBMP and custom_code_creator.
Both those examples are very simple.

> I should say that after seeing the lack of documentation I did take a
> stab at the classic "look at the source" method of figuring things out
> but there are so few coments in the code that this didn't work out
> well.  I would highly suggest that in addition to a tutorial you
> provide a short design document as an introduction for developers and
> then document the actual code.  My hope is that this will allow others
> to extend, maintain, and build upon the current code base.
>
...
> I have hit the limits of Pyste.  I have to create quite of bit of
> custom code and manual edits for most projects I wrap and that just
> doesn't scal well.  I have 4-5 projects I would like to move over to
> use pyplusplus as soon as possible.  The largest of these projects
> makes use of about 11,000 lines of Boost.Python wrapper code generated
> from a combination of Pyste and custom scripts.

That is exactly the projects I target pyplusplus

> The only thing that is keeping me from trying to port right now is the
> lack of a tutorial that explains how to wrap a library.
>
> Please keep up the good work.  I think your solution looks like it is
> very powerful, I just wish I could figure it out. :)

You will, stay tuned :-)

> -Allen
>
> >
> > Good luck.
> >
> > Roman Yakovenko
> > _______________________________________________
> > 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 Mathieu.Lacage at sophia.inria.fr  Mon Jan 16 09:24:47 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Mon, 16 Jan 2006 09:24:47 +0100
Subject: [C++-sig] optimizing away calls to the python
	runtime	--	was	[detecting if	a function is written in python or C++]
In-Reply-To: <87k6d3lx18.fsf@boost-consulting.com>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
Message-ID: <1137399887.31678.25.camel@chronos>

hi,

I am sufficiently stubborn to try to figure this out myself so, I have
put together this simple example of a solution to my problem:
http://spoutnik.inria.fr/yans/releases/test-python.tar.gz

This code defines:
  1) a C++ Callback1 class
  2) a C++ Real class which will called back into by the Callback1 class
  3) a C++ store_and_invoke_callback which uses the c++ Callback1 class
to call back.

The test python code demonstrate how:
  1) you can make store_and_invoke_callback call back into python
  2) you can make store_and_invoke_callback call back into a c++ method
bound in python without requiring any call into the python runtime

I am not very happy with the solution I came up with because it
requires:
  1 - me to define two overloads of each store_callback method to be
able to call back into python. (I do have lots of store_callback-like
methods)
  2 - me to define a Real__real_method__callback for each method I want
to create an optimized shortcut for.

2 - is not such a big deal: I fail to see how I could avoid it and I am
sure I can macroize or templatize this (my template-fu being close to
nil, I welcome suggestions on how to do this :)

1 - is much more annoying so I wonder if there is anything I could do to
avoid it. What I need is a way to tell boost that any object of type
Callback1 can be converted from a PythonCallbackMethodHolder or
PythonCallbackFunctionHolder.

For conveniance, here is my .cc and .py code. If someone could outsmart
me, it would be nice :)

class PythonCallbackMethodHolder {
public:
  PythonCallbackMethodHolder (object self, object function)
    : m_self (self), m_method (function)
  {}
  object get_self (void) {
    return m_self;
  }
  object get_method (void) {
    return m_method;
  }
private:
  object m_self;
  object m_method;
};

class PythonCallbackFunctionHolder {
public:
  PythonCallbackFunctionHolder (object function)
    : m_method (function)
  {}
  object get_method (void) {
    return m_method;
  }
private:
  object m_method;
};

class Real {
public:
  void real_method (int a) {
    std::cout << "called real_method " << a << std::endl;
  }
};

class Callback1 {
public:
  virtual void operator () (int a) {};
};
struct Real__real_method__callback : public Callback1 {
  Real__real_method__callback (Real *real) {
    m_real = real;
  }
  virtual void operator () (int a) {
    m_real->real_method (a);
  }
private:
  Real *m_real;
};

static void store_and_invoke_callback (Callback1 *obj)
{
  (*obj) (10);
}

static void store_and_invoke_callback_method (PythonCallbackMethodHolder holder)
{
  struct PythonDerived : public Callback1 {
    PythonDerived (PythonCallbackMethodHolder holder)
      : m_function (holder.get_method ()), m_self (holder.get_self ())
    {}
    virtual void operator () (int a) {
      m_function (m_self, a);
    }
  private:
    object m_function;
    object m_self;
  } *derived = new PythonDerived (holder);
  store_and_invoke_callback (derived);
}
static void store_and_invoke_callback_function (PythonCallbackFunctionHolder holder)
{
  struct PythonDerived : public Callback1 {
    PythonDerived (PythonCallbackFunctionHolder holder)
      : m_function (holder.get_method ())
    {}
    virtual void operator () (int a) {
      m_function (a);
    }
  private:
    object m_function;
  } *derived = new PythonDerived (holder);
  store_and_invoke_callback (derived);
}

BOOST_PYTHON_MODULE(test)
{
  // callback mechanism
  class_<Callback1, boost::noncopyable> ("Callback1");
  def ("store_and_invoke_callback", store_and_invoke_callback);
  def ("store_and_invoke_callback", store_and_invoke_callback_function);
  def ("store_and_invoke_callback", store_and_invoke_callback_method);


  // class to call back into
  class_<Real, boost::noncopyable> real ("Real");
  real.def ("real_method", &Real::real_method);
  class_<Real, boost::noncopyable> ("Real").
    def ("real_method", &Real::real_method);

  // the generic python method holder.
  class_<PythonCallbackMethodHolder, boost::noncopyable> ("PythonCallbackMethodHolder", init<object, object> ());
  class_<PythonCallbackFunctionHolder, boost::noncopyable> ("PythonCallbackFunctionHolder", init<object> ());

  // cpp proxy to call back into c++
  class_<Real__real_method__callback,
    bases<Callback1>,
    boost::noncopyable>
    ("Real__real_method__callback", init<Real *> ());
}

def make_callback(method, *args):
    try:
        name = method.im_class.__name__ + "__" + method.__name__ + "__callback"
        command = name + '(args[0])';
        holder = eval (command);
    except:
        if inspect.ismethod (method):
            holder = PythonCallbackMethodHolder (args[0], method)
        else:
            holder = PythonCallbackFunctionHolder (method)
    return holder

class UnrealClass:
    def unreal_method (self, a):
        print ("called unreal_method %d" % (a) );

def unreal_function (a):
    print "called unreal_function %d" % (a)


# call into python unreal_method from python
unreal = UnrealClass ()
unreal.unreal_method (0);

# call into python unreal_method from c++ from python
unreal_callback = make_callback (UnrealClass.unreal_method, unreal)
store_and_invoke_callback (unreal_callback);

# call into c++ real_method from python.
real = Real ();
real.real_method (1);

# call into c++ real_method from c++ from python
real_py_callback = make_callback (Real.real_method, real);
store_and_invoke_callback (real_py_callback);

# call into python function from c++ from python
store_and_invoke_callback (make_callback (unreal_function));



Mathieu

-- 



From dave at boost-consulting.com  Mon Jan 16 14:28:34 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Jan 2006 08:28:34 -0500
Subject: [C++-sig] problem with numarray >= 1.4
References: <200601152257.k0FMv00W001881@libra3.slac.stanford.edu>
Message-ID: <87bqyce1z1.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:

> I'm having trouble using numarray >= 1.4.1 with Boost.Python.
> I create a numarry called `high' (code to follow), and I get the
> following
>
>>>> h = high[1]
>>>> h.__class__
> <class 'numarray.numarraycore.NumArray'>
>>>> hh = h/10
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1209083328 (LWP 8852)]
> 0x007215b0 in array_divide (m1=0xbff0b2a8, m2=0xbff0b2a8)
>     at Src/_numarraymodule.c:512
> (gdb) 

The Boost.Python interface to NumArray is so unsophisticated that it's
very hard to imagine the bug is in Boost.Python.  Boost.Python doesn't
know anything about numarray at the C/C++ level; it merely uses the
Python C API to load the numarray module, and thereafter it treats a
numarray object like any other boost::python::object, except that we
provide some convenience methods, e.g.:

  object array_base::argmin(long axis)
  {
      return attr("argmin")(axis);
  }

So I suggest you look into your own code and the code of the latest
NumArray release.

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



From abierbaum at gmail.com  Mon Jan 16 17:20:50 2006
From: abierbaum at gmail.com (Allen Bierbaum)
Date: Mon, 16 Jan 2006 10:20:50 -0600
Subject: [C++-sig] Pyplusplus templates and roadmap
In-Reply-To: <7465b6170601152121r5a117ee8jae87577a3bfd494a@mail.gmail.com>
References: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>
	<7465b6170601142221g46162939n2a48b058ea18722f@mail.gmail.com>
	<bea9869d0601150828v46ddf928jf914ced795e8a861@mail.gmail.com>
	<7465b6170601152121r5a117ee8jae87577a3bfd494a@mail.gmail.com>
Message-ID: <bea9869d0601160820r2e7944fbse282b25558a53c27@mail.gmail.com>

On 1/15/06, Roman Yakovenko <roman.yakovenko at gmail.com> wrote:
> On 1/15/06, Allen Bierbaum <abierbaum at gmail.com> wrote:
> > I took a look at this library, but unfortunately I can't really make
> > heads or tails of it because I can't find any documentation about the
> > basics.  I just don't understand enough about the model used by
> > pyplusplus to be able to understand the python code used to generate
> > the wrappings.
> >
> > The one thing I think I really need (and I think is needed in general
> > before many others will port over from Pyste) is a coupld of simple
> > tutorial examples.  I applaud you for including detailed examples of
> > using pyplusplus to wrap existing libraries, but this doesn't really
> > explain how to use it.
>
> I will write some small example\tutorial and will post it in few days.

That would be a great help.  I am woudl like to get going on the
conversion towards the end of this week, so if you have even the
beginnings of a tutorial ready that would be a great help.

I am definitely willing to give you feedback on the tutorial if you like.

>
> > What I would like to see is a simple tutorial similar to the pyste
> > documentation in Boost.Python.  Just step by step instructions for how
> > to wrap a simple class or two and an explaination of why each step
> > matters and how it works.  This would do more for me then providing
> > wrappers for any number of libraries.
>
> Meanwhile you can take a look at 2 examples: EasyBMP and custom_code_creator.
> Both those examples are very simple.

I took a look at both of them and I agree they are simple.  That said,
I just can't seem to figure out where to start with them.  I mean I
see the code and I know it is overriding methods and calling things
but I don't know why or how it is working.  This is why I think a
simple tutorial would help out because it would let me see the forest
through the trees so to speak.

>
> > I should say that after seeing the lack of documentation I did take a
> > stab at the classic "look at the source" method of figuring things out
> > but there are so few coments in the code that this didn't work out
> > well.  I would highly suggest that in addition to a tutorial you
> > provide a short design document as an introduction for developers and
> > then document the actual code.  My hope is that this will allow others
> > to extend, maintain, and build upon the current code base.
> >
> ...
> > I have hit the limits of Pyste.  I have to create quite of bit of
> > custom code and manual edits for most projects I wrap and that just
> > doesn't scal well.  I have 4-5 projects I would like to move over to
> > use pyplusplus as soon as possible.  The largest of these projects
> > makes use of about 11,000 lines of Boost.Python wrapper code generated
> > from a combination of Pyste and custom scripts.
>
> That is exactly the projects I target pyplusplus

I was hoping you would say that. :)

>
> > The only thing that is keeping me from trying to port right now is the
> > lack of a tutorial that explains how to wrap a library.
> >
> > Please keep up the good work.  I think your solution looks like it is
> > very powerful, I just wish I could figure it out. :)
>
> You will, stay tuned :-)

Thanks,
Allen

>
> > -Allen
> >
> > >
> > > Good luck.
> > >
> > > Roman Yakovenko
> > > _______________________________________________
> > > C++-sig mailing list
> > > C++-sig at python.org
> > > http://mail.python.org/mailman/listinfo/c++-sig
> > >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>


From rwgk at yahoo.com  Mon Jan 16 22:41:31 2006
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 16 Jan 2006 13:41:31 -0800 (PST)
Subject: [C++-sig] new docstring_options and related features
Message-ID: <20060116214131.85920.qmail@web31515.mail.mud.yahoo.com>

The most recent Boost CVS includes a new boost/python/docstring_options.hpp
header plus reference documentation with examples, available for review here:

http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/docstring_options.html

The main new feature is that C++ signatures are automatically appended to the
docstrings. This is the default behavior. The signatures or complete docstrings
may be suppressed by way of the docstring_options class. See the documentation
for details. Please let me know if something is not clear.

I've also (finally) integrated Ult Mundane's patch to work around broken gcc
name demanglers. I.e. the signatures produced by Boost.Python will now show
full type names with all recent gcc versions. Thanks Ult!

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  Mon Jan 16 23:52:59 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Jan 2006 17:52:59 -0500
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
References: <877j92gor9.fsf@boost-consulting.com>
	<43CA3349.20009.22E1E9AD@s_sourceforge.nedprod.com>
Message-ID: <873bjnaipg.fsf@boost-consulting.com>

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

> With respect Dave, you never have used pyste yourself in anger and so 
> are completely unaware of its strengths and failings. 

Not completely.

> If I were you, I would have tested it myself extensively before
> allowing it into my CVS - it after all will be the first thing most
> users see of your library and often the *only* thing they see. Its
> strengths and weaknesses reflect strongly on BPL.

True.  So it goes.

> Now pyste needed rewriting - it had run into architectural limits. 
> And I admit I had doubts when Roman started saying he was going to 
> write a replacement - admittedly not helped by his poor English. 
> However, when literally out of the blue he sent me a set of new TnFOX 
> bindings about 98% complete I was quite blown away. Since then as I 
> have delved into his source, I realise that he is a very competent 
> coder and has got the design right from the beginning - which Bruno 
> (and my respect to you nevertheless) did not. 

Having already seen one design's mistakes, it's often easier.

> There are still some rough spots (like default parameters), but it's
> very nearly perfect on the generation front.
>
>> Is it a complete replacement for pyste?  What should a Pyste user do
>> in order make his code us pyplusplus instead?  IMO there ought to be a
>> Pyste compatibility layer.
>
> That would be inadvisable. The best thing is for pyste users to 
> regenerate their config files from scratch as pyplusplus uses quite a 
> different configuration model (nowhere near as easy, but considerably 
> more powerful).

I disagree.  If you're going to use a wrapper generator, it should be
as easy as possible.  If Pyste has a reasonably terse, expressive
input syntax that matches the user's mental model (something I
encouraged Bruno to develop and that Roman could have learned from),
then pyplusplus should use it or improve on it.  To do otherwise would
be inconsistent with the design spirit and aims of Boost.Python.
There's no reason a lower-level interface couldn't be available, too,
if necessary.

>> I think
>> http://www.language-binding.net/pyplusplus/to_pyste_comparison.html
>> would be a lot better if it took a more neutral tone; it seems to bash
>> Pyste a lot more than necessary.  Fortunately, this page doesn't seem
>> to be linked from the pyplusplus main page but if Boost is going to
>> endorse pyplusplus, that same information *ought* to be made more
>> generally available.
>
> No Roman is being fair on that page. 

I never claimed it was unfair.

> He nor I mean no disrespect to Bruno, pyste is a good bindings
> generator but it has hard design limits in it and Roman gives a
> pretty good overview of those.

The tone could be more neutral, with all the facts and less gloating
(well, "gloating" is not quite the right word but I can't think of a
better one right now).

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



From Paul_Kunz at slac.stanford.edu  Tue Jan 17 00:04:15 2006
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 16 Jan 2006 15:04:15 -0800
Subject: [C++-sig] problem with numarray >= 1.4
In-Reply-To: <87bqyce1z1.fsf@boost-consulting.com> (message from David
	Abrahams on Mon, 16 Jan 2006 08:28:34 -0500)
References: <200601152257.k0FMv00W001881@libra3.slac.stanford.edu>
	<87bqyce1z1.fsf@boost-consulting.com>
Message-ID: <200601162304.k0GN4F4S003301@libra3.slac.stanford.edu>

>>>>> On Mon, 16 Jan 2006 08:28:34 -0500, David Abrahams <dave at boost-consulting.com> said:

> "Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> writes:
>> I'm having trouble using numarray >= 1.4.1 with Boost.Python.  I
>> create a numarry called `high' (code to follow), and I get the
>> following
>> 
   The problem is fixed in numarray's CVS HEAD and will be in version
1.5.1  which will be available shortly.


From dave at boost-consulting.com  Tue Jan 17 01:24:59 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 16 Jan 2006 19:24:59 -0500
Subject: [C++-sig] optimizing away calls to the python
	runtime	--	was	[detecting if	a function is written in python or C++]
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
Message-ID: <87wtgz8zvo.fsf@boost-consulting.com>

Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> writes:

> hi,
>
> I am sufficiently stubborn to try to figure this out myself so, I have
> put together this simple example of a solution to my problem:
> http://spoutnik.inria.fr/yans/releases/test-python.tar.gz
>
> This code defines:
>   1) a C++ Callback1 class
>   2) a C++ Real class which will called back into by the Callback1 class
>   3) a C++ store_and_invoke_callback which uses the c++ Callback1 class
> to call back.
>
> The test python code demonstrate how:
>   1) you can make store_and_invoke_callback call back into python
>   2) you can make store_and_invoke_callback call back into a c++ method
> bound in python without requiring any call into the python runtime

Which line of Python, in particular, demonstrates 2)?

Your example is much, much bigger than it needs to be.  Forget about
methods; just demonstrate it for regular functions.  Stop exporting
the "Real" class twice.  Stop doing needless dynamic allocation in
store_and_invoke_callback.

And stop using double underscores in C++ identifiers; that's reserved
to the compiler ;-)

If I sift out all the stuff in your code that seems extraneous, I
still can't tell what you're trying to accomplish, but maybe you just
want to use

      boost::function<void()>

inside which you can store any object invokable with zero arguments?

P.S. there's little reason to do anything special for bound methods,
since if

        >>> x.f()

is legal Python, you can always store x.f and invoke it later.

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



From brett at coombs.anu.edu.au  Tue Jan 17 03:15:02 2006
From: brett at coombs.anu.edu.au (Brett Calcott)
Date: Tue, 17 Jan 2006 13:15:02 +1100
Subject: [C++-sig] cvs update breaks some code (class_metadata.hpp)
In-Reply-To: <87r77dnixr.fsf@boost-consulting.com>
References: <dq4fg9$4hf$1@sea.gmane.org> <87r77dnixr.fsf@boost-consulting.com>
Message-ID: <dqhjv6$48n$1@sea.gmane.org>

David Abrahams wrote:
> 
> When you register a class derived from wrapper<B>, don't declare B to
> be a base class (with bases<B>).  The library does that for you.
> 
> 

Ok. It compiles now. But the derived classes don't appear to have 
inherited the base class. In my code, both PythonBase and CPPDerived 
inherit from _BaseNotUsed. One by using wrapper<> and the other by using 
bases<>.

Has something else changed that I haven't seen?

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import simple
 >>> a = simple._BaseNotUsed()
 >>> b = simple.PythonBase()
 >>> c = simple.CPPDerived()
 >>> a.normal_function()
99
 >>> b.normal_function()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'PythonBase' object has no attribute 'normal_function'
 >>> c.normal_function()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'CPPDerived' object has no attribute 'normal_function'
 >>> isinstance(b, simple._BaseNotUsed)
False
 >>> isinstance(c, simple._BaseNotUsed)
False
 >>>

The code is as follows:

#include <boost/python/call_method.hpp>
#include <boost/python/wrapper.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/list.hpp>
#include <boost/python/tuple.hpp>
#include <boost/python/def.hpp>
#include <boost/python/module.hpp>

using namespace boost::python;

struct base {
     base() {}
     int normal_function() { return 99; }
     virtual int a_function(int a) { return 0; }
};

struct python_base : base, wrapper<base>
{
     python_base() : base() {}

     int a_function(int a)
     {
         if (override f = this->get_override("a_function"))
             return f(a);
         return base::a_function(a);
     }

     int default_a_function(int a) { return this->base::a_function(a); }
};

struct cpp_derived : base, wrapper<base>
{
     cpp_derived() : base() {}

     int a_function(int a)
     {
         return a * 666;
     }
};

int call_a_function(base &base, int i)
{
     return base.a_function(i);
}

BOOST_PYTHON_MODULE(simple)
{
     class_<base
         , boost::noncopyable
         >("_BaseNotUsed")
         .def("normal_function", &base::normal_function)
         ;

     // Base for all python classes
     class_<python_base
//        , bases<base>
         , boost::noncopyable
         >("PythonBase")
         .def(init<python_base>())
         .def("a_function", &base::a_function, 
&python_base::default_a_function)
         ;

     // A C++ derived class
     class_<cpp_derived
         , bases<base>
         , boost::noncopyable
         >("CPPDerived")
         .def(init<cpp_derived>())
         ;

     def("call_a_function", &call_a_function);
}












From roman.yakovenko at gmail.com  Tue Jan 17 07:25:46 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 17 Jan 2006 08:25:46 +0200
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <873bjnaipg.fsf@boost-consulting.com>
References: <877j92gor9.fsf@boost-consulting.com>
	<43CA3349.20009.22E1E9AD@s_sourceforge.nedprod.com>
	<873bjnaipg.fsf@boost-consulting.com>
Message-ID: <7465b6170601162225w5ab880aeh976d6c3076cea253@mail.gmail.com>

On 1/17/06, David Abrahams <dave at boost-consulting.com> wrote:
> > That would be inadvisable. The best thing is for pyste users to
> > regenerate their config files from scratch as pyplusplus uses quite a
> > different configuration model (nowhere near as easy, but considerably
> > more powerful).
>
> I disagree.  If you're going to use a wrapper generator, it should be
> as easy as possible.  If Pyste has a reasonably terse, expressive
> input syntax that matches the user's mental model (something I
> encouraged Bruno to develop and that Roman could have learned from),
> then pyplusplus should use it or improve on it.
> To do otherwise would
> be inconsistent with the design spirit and aims of Boost.Python.
> There's no reason a lower-level interface couldn't be available, too,
> if necessary.

Using pyplusplus it is possible to implement Pyste interface files. But
1. I can not find open source projects, that use Pyste, except  TnFOX.
This is the main
    reason why I still did not implement Pyste interface files.

2. For small projects pyplusplus has GUI - small, simple and intuitive.

3. For big projects interface files does not help, you need low level API.

I did not find any post regardless "Boost.Python user's mental model".
It would be nice to read and learn. If you mean this: "... The
library's use of advanced metaprogramming techniques simplifies its
syntax for users, so that wrapping code takes on the look of a kind of
declarative interface definition language (IDL). ..."
In this case I can say that we deal with 2 different tasks: code
generation and actual bindings. They are so different.

I studied the use of Pyste in TnFOX project.
You need to see all tricks that TnFOX project use in order to generate
code, using
Pyste. More over Niall wrote script, that generates Pyste interface
files, that will generate
the code.

The rational behind pyplusplus is simple: every big project has
logical design ( namespaces, classes ) and physical design( location
of files on a disk ). pyplusplus
helps developers to reuse existing conventions ( logical and physical design ).
I don't say it is impossible to do this with ( not so simple )
interface files, but I do not
see any reason to go this way.

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


Roman Yakovenko


From Mathieu.Lacage at sophia.inria.fr  Tue Jan 17 09:42:29 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 17 Jan 2006 09:42:29 +0100
Subject: [C++-sig] optimizing away calls to the
	python	runtime	--	was	[detecting if	a function is written in
	python or C++]
In-Reply-To: <87wtgz8zvo.fsf@boost-consulting.com>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
Message-ID: <1137487349.31678.85.camel@chronos>

On Mon, 2006-01-16 at 19:24 -0500, David Abrahams wrote:

> Your example is much, much bigger than it needs to be.  Forget about
> methods; just demonstrate it for regular functions.  Stop exporting

done.

> the "Real" class twice.  Stop doing needless dynamic allocation in

yes, this is a remnant of some testing I did to see what would happen if
I exported a class/method twice. removed.

> store_and_invoke_callback.

right. It is not needed in this example. removed.

> 
> And stop using double underscores in C++ identifiers; that's reserved
> to the compiler ;-)

I thought it was starting and ending underscores. removed.

> 
> If I sift out all the stuff in your code that seems extraneous, I
> still can't tell what you're trying to accomplish, but maybe you just
> want to use
> 
>       boost::function<void()>
> 
> inside which you can store any object invokable with zero arguments?

My wrapped c++ code is not going to use boost::function but a similar
template-based thing which will end up generating classes such as
Callback1 in my example. The () operators of these classes will have a
non-zero number of arguments and will have return values (the current
sample code demonstrate no return value but it should be extended to
this case easily).

> P.S. there's little reason to do anything special for bound methods,
> since if
> 
>         >>> x.f()
> 
> is legal Python, you can always store x.f and invoke it later.

Yes and if you remove the python statements from the try in the
make_callback python function, this is what the code will do. 

But, it is my impression that doing so from c++ would require calling
into the python interpreter rather than access directly the c++ bound
method. I want to access directly the c++ bound method from c++ which is
the whole point of this testcase.

updated testcase (reworked as per your requests):
http://spoutnik.inria.fr/yans/releases/test-python.tar.gz

[mlacage at chronos test-python]$ time -p ./test.py --slow
real 12.68
user 12.54
sys 0.01
[mlacage at chronos test-python]$ time -p ./test.py
real 0.32
user 0.23
sys 0.00

Which shows that special-casing bound methods makes them slightly faster
which is exactly what I was after. Now, clearly, I am not too happy with
the way I achieved this.

Mathieu

PS: no attention was paid to any form of memory management here.
-- 



From roman.yakovenko at gmail.com  Tue Jan 17 10:04:54 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 17 Jan 2006 11:04:54 +0200
Subject: [C++-sig] Pyplusplus templates and roadmap
In-Reply-To: <bea9869d0601160820r2e7944fbse282b25558a53c27@mail.gmail.com>
References: <bea9869d0601141430yc4a29e8w215017c7930eeced@mail.gmail.com>
	<7465b6170601142221g46162939n2a48b058ea18722f@mail.gmail.com>
	<bea9869d0601150828v46ddf928jf914ced795e8a861@mail.gmail.com>
	<7465b6170601152121r5a117ee8jae87577a3bfd494a@mail.gmail.com>
	<bea9869d0601160820r2e7944fbse282b25558a53c27@mail.gmail.com>
Message-ID: <7465b6170601170104t25a36e8ev6dd39f32a0a61a2f@mail.gmail.com>

On 1/16/06, Allen Bierbaum <abierbaum at gmail.com> wrote:
> I am definitely willing to give you feedback on the tutorial if you like.

Thank you.

> > Meanwhile you can take a look at 2 examples: EasyBMP and custom_code_creator.
> > Both those examples are very simple.
>
> I took a look at both of them and I agree they are simple.  That said,
> I just can't seem to figure out where to start with them.  I mean I
> see the code and I know it is overriding methods and calling things
> but I don't know why or how it is working.  This is why I think a
> simple tutorial would help out because it would let me see the forest
> through the trees so to speak.

Okay, I made first step towards tutorials. I took EasyBMP example and wrote
documentation string for every function. In order to understand code
generation process
using pyplusplus you should read this
http://language-binding.net/pyplusplus/pyplusplus.html
and after this pyplusplus/examples/py_easybmp/create_easybmp.py file
( I attach new version of the file to the mail )

I still should find out, how to build simple step by step tutorial
from the information,
I provided right now. I am sure you have some idea, right?

Thanks

Roman Yakovenko
-------------- next part --------------
#! /usr/bin/python
# Copyright 2004 Roman Yakovenko.
# Distributed under the Boost Software License, Version 1.0. (See
# accompanying file LICENSE_1_0.txt or copy at
# http://www.boost.org/LICENSE_1_0.txt)

import os
from environment import settings
from pygccxml import parser
from pygccxml import declarations
from pyplusplus import code_creators
from pyplusplus import module_creator
from pyplusplus import file_writers


license = \
"""
// Copyright 2004 Roman Yakovenko.
// Distributed under the Boost Software License, Version 1.0. (See
// accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)
"""

def identify_call_policies( decl ):
    """
    pyplusplus built-in call policies resolver can not and will not guess call 
    policies for functions. Nevertheless, it is easy to setup custom call 
    policies resolver. The only requirement on custom call policy resolver is
    to be callable, that takes 1 argument - C++ "callable" declaration. It could
    be constructor, member or free function, regular or casting operators.
    
    In this example I reuse built-in call policies resolver, and if it can not
    fiind out call policies I choose call policies based on some fact.
    """    
    build_in_resolver = module_creator.build_in_resolver_t()
    policy = build_in_resolver( decl )
    if policy:
        return policy

    if isinstance( decl, declarations.member_operator_t ) \
       and decl.symbol == '()' \
       and decl.parent.name == 'BMP':
        return code_creators.return_internal_reference()
    return None

class easybmp_exporter_t:
    def __init__(self):
        self.__header_file = os.path.join( settings.easybmp_path, 'EasyBMP.h' )
    
    def read_declarations(self):
        """
        The first step in creating C++ - Python bindings is to read declarations 
        from source files. This step is done by using pygccxml. First thing that
        you should do is to setup parser ( GCC-XML ). pygccxml.parser.config_t 
        class is responsible for parser configuration. Basicaly, using config_t
        class you can setup:
            * GCC-XML binary path
            * include directories
            * working directory
            * [un]defined symbols
        See that class definition for more information.
        
        After you setup parser configuration you can read declarations from
        source files. There are 2 declaration readers:
            * pygccxml.parser.source_reader_t
            * pygccxml.parser.project_reader_t
        If you have to parse single file, then use source_reader_t, otherwise
        you'd better use project_reader_t. Please refere to pygccxml documentation
        for full explanation about those classes.
        
        In this example I read all declarations found in EasyBMP.h file and files
        that are included from it. 
        """
        config = parser.config_t( gccxml_path=settings.gccxml_path
                                  , working_directory=settings.easybmp_path )
        reader = parser.source_reader_t( config )
        return reader.read_file( self.__header_file )
    
    def filter_declarations(self, decls ):
        """
        After you read declarations, you should leave only declarations, that 
        you want to export to Python. I call this process "filtering". There are
        a lot of ways to filter out declarations:
            * by phisical location
              you can specify a list of files and directories, and all declarations
              that are not declared within those files will be removed
            * by namespace
              return declarations.find_declaration( decls
                                                    , name="geometry"
                                                    , type=declarations.namespace_t )
            * by defining some custom filter
              while defining custom filter, be careful in excluding namespaces,
              because thus you exclude all declarations defined in this namespace.s
        """
        return declarations.filtering.by_location( decls, [settings.easybmp_path] )
    
    def create_extmodule(self, decls):
        """
        3'th step. In this step pyplusplus creates "code creators" tree from 
        the set of declarations, you want to export. This step creates mapping
        between C++ declaration and instance of the pyplusplus class that will
        create code, needed to export the declaration. 
        pyplusplus.module_creator.creator_t class is responsible for this step.
        In most cases you do not need to use this class at all. Instead of
        using this class consider to use pyplusplus.module_creator.create function.
        This function takes 2 arguments: module name and a list of declarations.
        
        In my case I should use this class in order to setup custom call policies
        resolver. creator.create() returns "main" code creator -
        pyplusplus.code_creators.module_t class instance. This code creator keeps
        all other code creators.
        
        This step is the most complex in the whole process.
        """
        creator = module_creator.creator_t( decls=decls
                                            , module_name=settings.module_name
                                            , create_castinig_constructor=True
                                            , call_policies_resolver_=identify_call_policies) 
        return creator.create()
    
    def customize_extmodule( self, extmodule ):
        """
        Nobody is perfect, pyplusplus too. After you created 
        pyplusplus.code_creators.module_t class instance it's time to do all 
        customization on the yet generated code, before you actualy write the 
        code to files.
        
        First and most common customization in open source project is to setup
        license. License text will apear as is within every generated file.
        
        Second common customization is to setup include directories. This will 
        cause pyplusplus to generate code with relative include directives.
        
        You can also to setup precompiled header.
        
        Almost every code_creator has set of properties that could be changed.
        
        An other cool feature of pyplusplus is namespace aliasing. 
            bpalias = code_creators.namespace_alias_t( alias="bp"
                                                   , full_namespace_name="::boost::python")
            extmodule.adopt_creator( bpalias, extmodule.last_include_index() + 1 )
        All code that will be generated after "namespace bp = ::boost::python;"
        will use "bp" instead of "::boost::python". Nice!
        
        Last and may be the most important thing that you can do at this step
        is to create custom code creators and inject them into right place, within
        module_t code creator instance. Remember: you should be able to modify, 
        add or delete almost every piece of yet not generated code. If you are 
        not, just send me a mail.
        """
        global license
        extmodule.license = license
        #butifying include code generation
        extmodule.user_defined_directories.append( settings.easybmp_path )
        extmodule.precompiled_header = 'boost/python.hpp'
        #Adding EasyBMP.h as first include. It comes because of internal structure of EasyBMP
        extmodule.adopt_creator( code_creators.include_t( header=self.__header_file ), 2 )
        body_index = extmodule.creators.index( extmodule.body )
        bmp_call = code_creators.creator_finder.find_by_declaration_single(
            declarations.match_declaration_t( fullname='::BMP::operator()' )
            , extmodule.body )
        bmp_call.alias = 'GetRGBAPixel'
        
    def write_files( self, extmodule ):
        """
        Last step: to create file(s) with generated code. There are few options 
        here:
            * you can write all generated code to single file. In this case you 
              should specify destination file name. 
              pyplusplus.file_writers.write_file function is your friend. It takes
              2 arguments: 
                  * pyplusplus.code_creators.module_t instance 
                  * destination file name
            
            * you can write all generated code to multiple files. In this case 
              you should specify destination directory name. In this case pyplusplus
              generates files as recomended here: 
              www.boost.org/libs/python/doc/tutorial/doc/html/python/techniques.html#python.reducing_compiling_time
        If you don't like the way I do it, you can always write your own file writer.
        """
        file_writers.write_file(extmodule
                                , os.path.join(settings.generated_files_dir
                                               , settings.module_name + '.cpp') )

    def create(self):
        decls = self.read_declarations()
        self.filter_declarations(decls)
        extmodule = self.create_extmodule( decls )
        self.customize_extmodule( extmodule )
        self.write_files( extmodule )

def export():
    exporter = easybmp_exporter_t()
    exporter.create()

if __name__ == '__main__':
    export()
    print 'done'

From dave at boost-consulting.com  Tue Jan 17 17:29:19 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 17 Jan 2006 11:29:19 -0500
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
References: <877j92gor9.fsf@boost-consulting.com>
	<43CA3349.20009.22E1E9AD@s_sourceforge.nedprod.com>
	<873bjnaipg.fsf@boost-consulting.com>
	<7465b6170601162225w5ab880aeh976d6c3076cea253@mail.gmail.com>
Message-ID: <87hd827r8g.fsf@boost-consulting.com>

Roman Yakovenko <roman.yakovenko at gmail.com> writes:

> In this case I can say that we deal with 2 different tasks: code
> generation and actual bindings. They are so different.

The "code generation" is of no interest to the user.  It is merely a
step that the computer takes in helping him to achieve his goal.  The
focus should be on providing an expressive specification language
(i.e. library interface) for the user to control code generation and
binding.  I suggest you read up on domain-specific embedded languages
(DSELs).

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



From dave at boost-consulting.com  Tue Jan 17 17:41:56 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 17 Jan 2006 11:41:56 -0500
Subject: [C++-sig] optimizing away calls to the
	python	runtime	--	was	[detecting if	a function is written in
	python or C++]
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
	<1137487349.31678.85.camel@chronos>
Message-ID: <87bqya7qnf.fsf@boost-consulting.com>

Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> writes:

> My wrapped c++ code is not going to use boost::function but a similar
> template-based thing which will end up generating classes such as
> Callback1 in my example. 

Why reinvent the wheel?  boost::function will be more efficient,
better tested, etc...

> The () operators of these classes will have a
> non-zero number of arguments and will have return values (the current
> sample code demonstrate no return value but it should be extended to
> this case easily).
>
> But, it is my impression that doing so from c++ would require calling
> into the python interpreter rather than access directly the c++ bound
> method. I want to access directly the c++ bound method from c++ which is
> the whole point of this testcase.
>
> updated testcase (reworked as per your requests):
> http://spoutnik.inria.fr/yans/releases/test-python.tar.gz

No, it still contains the use of methods, which AFAICT is not needed
in order to prove your point.

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



From s_sourceforge at nedprod.com  Tue Jan 17 20:25:54 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 17 Jan 2006 19:25:54 -0000
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <873bjnaipg.fsf@boost-consulting.com>
Message-ID: <43CD44C2.897.2EDE297A@s_sourceforge.nedprod.com>

On 16 Jan 2006 at 17:52, David Abrahams wrote:

> > That would be inadvisable. The best thing is for pyste users to 
> > regenerate their config files from scratch as pyplusplus uses quite a 
> > different configuration model (nowhere near as easy, but considerably 
> > more powerful).
> 
> I disagree.  If you're going to use a wrapper generator, it should be
> as easy as possible.  If Pyste has a reasonably terse, expressive
> input syntax that matches the user's mental model (something I
> encouraged Bruno to develop and that Roman could have learned from),
> then pyplusplus should use it or improve on it.  To do otherwise would
> be inconsistent with the design spirit and aims of Boost.Python.
> There's no reason a lower-level interface couldn't be available, too,
> if necessary.

The configuration setup for pyplusplus is much more terse than pyste 
for which I wrote generator script which creates the .pyste files. I 
don't need to do that in pyplusplus. Both have the major advantage 
that the config script is written in python.

Roman's GUI should give a good enough template for simple usage, but 
you'd probably need to copy & paste from an example for more complex 
usage.

> > He nor I mean no disrespect to Bruno, pyste is a good bindings
> > generator but it has hard design limits in it and Roman gives a
> > pretty good overview of those.
> 
> The tone could be more neutral, with all the facts and less gloating
> (well, "gloating" is not quite the right word but I can't think of a
> better one right now).

I very much doubt if I could write in a non-gloating style in Spanish 
or German. You have to use the words and phrases you know and do the 
best you can. Unfortunately they often don't carry the tone you mean.

Cheers,
Niall





From duranlef at iro.umontreal.ca  Tue Jan 17 22:29:27 2006
From: duranlef at iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Duranleau?=)
Date: Tue, 17 Jan 2006 16:29:27 -0500 (EST)
Subject: [C++-sig] optimizing away calls to the python runtime -- was
 [detecting if a function is written in python or C++]
In-Reply-To: <87bqya7qnf.fsf@boost-consulting.com>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
	<1137487349.31678.85.camel@chronos>
	<87bqya7qnf.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>

On Tue, 17 Jan 2006, David Abrahams wrote:

> Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> writes:
>
>> My wrapped c++ code is not going to use boost::function but a similar
>> template-based thing which will end up generating classes such as
>> Callback1 in my example.
>
> Why reinvent the wheel?  boost::function will be more efficient,
> better tested, etc...

I have been following this discussion with great interest, since I am 
facing similar problems. I have some function templates to expose to 
Python and some of their template arguments are functions (functor or
function pointers), e.g. (dummy example):

template < typename Func >
void do_something( Func f )
{
     for ( int i = 0 ; i < 1000000 ; ++ i )
     {
         f( 10 ) ;
     }
}


The easiest way to expose it is, I think, something like this:

def( "do_something" , & do_something< object > ) ;


However, as pointed out by the timings given by Mathieu's last test, if 
the function parameter is to be called very often, it's a hit on 
performance. It could be possible to do something like the following, 
using boost::function :

typedef boost::function< void ( int ) > function_type ;

def( "do_something" , & do_something< function_type > ) ;


and then for each exposed functor, e.g.:

struct functor
{
     void operator () ( int a ) const
     {
         // ...
     }
} ;


you can use boost::python::implicitly_convertible:

class_< functor >( "Functor" )
     .def( "__call__" , & functor::operator () )
     ;

implicitly_convertible< functor , function_type >() ;


However, with this, you can't use Python callable objects anymore, unless 
we add an explicit converter to function_type for those:

function_type make_function( object o )
{
     return function_type( o ) ;
}


and then:

class_< function_type >( "Function" ) ;

def( "make_function" , & ::make_function ) ;


So in Python, you can do something like this:

// import the stuff

def func( a ) :
     # ...
     pass

do_something( Functor() )

do_something( make_function( func ) )


However, if we define a C++ function and want to pass it to do_something 
via Python, it seems like we have to either use make_function (and lose 
performance), or define a C++ wrapper functor. But in any case, the user 
has to explicitly use make_function for Python (actually, any other 
callable types not defined in your Boost.Python code) callable objects, 
and this non-uniformity between each type of call is not intuitive: a user 
must know if an object comes from Python or C++. Well, he could put 
make_function's everywhere, but he would lose the benefit. The ultimate 
goal would be to avoid any 'make_function'-like calls.

I put the complete example here (Makefile, test2.cc, test2.py):
http://www-etud.iro.umontreal.ca/~duranlef/python/

Actually, the whole point is, even using boost::function, it seems like it 
just moves the problem to someplace else, that is, how can you extract a 
C++ function/functor of unknown type (just the function signature is 
known) to store in the boost::function object, and otherwise (not a C++ 
object) just store the Python object, all that in a nice and easy way (for 
the user, at least)? Mathieu found a way, but it relies on some kind of 
hack with C++ name patterns. As a matter of fact, we could also use a hack 
with the __class__ attribute (it seems like the value for all Boost.Python 
classes is <type 'Boost.Python.class'>. But what about C++ functions? Are 
we doomed to have to deal with wrapper functors?

-- 
Fran?ois Duranleau
LIGUM, Universit? de Montr?al

"There are as many truths as there are people."
                                           - from _Neon Genesis Evangelion_

From benveal92 at hotmail.com  Wed Jan 18 02:43:45 2006
From: benveal92 at hotmail.com (Ben Veal)
Date: Wed, 18 Jan 2006 01:43:45 +0000
Subject: [C++-sig] [python] problems with tutorial in Debian
Message-ID: <BAY101-F1923E2CAE06DF8F21FB78BB31D0@phx.gbl>

I am resorting to this mailing list since I can't find the answer elsewhere.
I can't compile the tutorial 'hello.cpp' example of boost.python on Debian 
Sarge.
bjam tells me it can't find 'bootstrap.jam' which doesn't exist on my 
system.
The directory structure of the Debian boost package appears to be very 
different to the official one, and is obviously missing a few files. How can 
I fix this?
I installed all the libboost packages that were available to me on a Debian 
installation DVD I bought.
Here are the versions of the relevant packages:

libboost-* : 1.32.0-6
bjam : 3.1.10-1
gcc : 4:3.3.5-3
python : 2.3.5-2

Can anyone help me?

Also are there any other problems I ought to be aware of for creating python 
extension modules with boost.python bjam & gcc on debian?

Thankyou.




From roman.yakovenko at gmail.com  Wed Jan 18 06:32:55 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 18 Jan 2006 07:32:55 +0200
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <87hd827r8g.fsf@boost-consulting.com>
References: <877j92gor9.fsf@boost-consulting.com>
	<43CA3349.20009.22E1E9AD@s_sourceforge.nedprod.com>
	<873bjnaipg.fsf@boost-consulting.com>
	<7465b6170601162225w5ab880aeh976d6c3076cea253@mail.gmail.com>
	<87hd827r8g.fsf@boost-consulting.com>
Message-ID: <7465b6170601172132g5fde64fcu8c7e8b4fd1f7b5b4@mail.gmail.com>

On 1/17/06, David Abrahams <dave at boost-consulting.com> wrote:
> Roman Yakovenko <roman.yakovenko at gmail.com> writes:
>
> > In this case I can say that we deal with 2 different tasks: code
> > generation and actual bindings. They are so different.
>
> The "code generation" is of no interest to the user.  It is merely a
> step that the computer takes in helping him to achieve his goal.  The
> focus should be on providing an expressive specification language
> (i.e. library interface) for the user to control code generation and
> binding.  I suggest you read up on domain-specific embedded languages
> (DSELs).

Do you have good links?

> --
> 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 roman.yakovenko at gmail.com  Wed Jan 18 06:41:06 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 18 Jan 2006 07:41:06 +0200
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
In-Reply-To: <43CD44C2.897.2EDE297A@s_sourceforge.nedprod.com>
References: <873bjnaipg.fsf@boost-consulting.com>
	<43CD44C2.897.2EDE297A@s_sourceforge.nedprod.com>
Message-ID: <7465b6170601172141k2afba5ffye8cf249646b69fb@mail.gmail.com>

On 1/17/06, Niall Douglas <s_sourceforge at nedprod.com> wrote:
> On 16 Jan 2006 at 17:52, David Abrahams wrote:
>
> > > That would be inadvisable. The best thing is for pyste users to
> > > regenerate their config files from scratch as pyplusplus uses quite a
> > > different configuration model (nowhere near as easy, but considerably
> > > more powerful).
> >
> > I disagree.  If you're going to use a wrapper generator, it should be
> > as easy as possible.  If Pyste has a reasonably terse, expressive
> > input syntax that matches the user's mental model (something I
> > encouraged Bruno to develop and that Roman could have learned from),
> > then pyplusplus should use it or improve on it.  To do otherwise would
> > be inconsistent with the design spirit and aims of Boost.Python.
> > There's no reason a lower-level interface couldn't be available, too,
> > if necessary.
>
> The configuration setup for pyplusplus is much more terse than pyste
> for which I wrote generator script which creates the .pyste files. I
> don't need to do that in pyplusplus. Both have the major advantage
> that the config script is written in python.
>
> Roman's GUI should give a good enough template for simple usage, but
> you'd probably need to copy & paste from an example for more complex
> usage.

Niall you gave me idea. From GUI I can generate Python code. This
could give good
start. I mean, I will create code that configurate pyplusplus.

Thanks


Roman Yakovenko

>
> Cheers,
> Niall


From Mathieu.Lacage at sophia.inria.fr  Wed Jan 18 12:00:59 2006
From: Mathieu.Lacage at sophia.inria.fr (mathieu lacage)
Date: Wed, 18 Jan 2006 12:00:59 +0100
Subject: [C++-sig] optimizing away calls to the python runtime -- was
 [detecting if a function is written in python or C++]
In-Reply-To: <Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>
References: <1137074745.15517.102.camel@chronos>	<87irsoon63.fsf@boost-consulting.com>	<1137142913.15517.167.camel@chronos>	<878xtkmdzv.fsf@boost-consulting.com>	<1137161942.15517.204.camel@chronos>	<87k6d3lx18.fsf@boost-consulting.com>	<1137399887.31678.25.camel@chronos>	<87wtgz8zvo.fsf@boost-consulting.com>	<1137487349.31678.85.camel@chronos>	<87bqya7qnf.fsf@boost-consulting.com>
	<Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>
Message-ID: <43CE1FEB.3090109@sophia.inria.fr>

hi,

Fran?ois Duranleau wrote:

>  with C++ name patterns. As a matter of fact, we could also use a hack 
> with the __class__ attribute (it seems like the value for all 
> Boost.Python classes is <type 'Boost.Python.class'>. But what about 
> C++ functions? Are we


What would such a hack do ? Recognize which classes are exported by 
boost.python and are thus C++ bound classes ? What would you use this for ?

Mathieu


From cavok at tiscali.it  Wed Jan 18 12:06:23 2006
From: cavok at tiscali.it (Domenico Andreoli)
Date: Wed, 18 Jan 2006 12:06:23 +0100
Subject: [C++-sig] [python] problems with tutorial in Debian
In-Reply-To: <BAY101-F1923E2CAE06DF8F21FB78BB31D0@phx.gbl>
References: <BAY101-F1923E2CAE06DF8F21FB78BB31D0@phx.gbl>
Message-ID: <20060118110623.GA9842@raptus.dandreoli.com>

hi Ben,

On Wed, Jan 18, 2006 at 01:43:45AM +0000, Ben Veal wrote:
> I am resorting to this mailing list since I can't find the answer elsewhere.
> I can't compile the tutorial 'hello.cpp' example of boost.python on Debian 
> Sarge.
> bjam tells me it can't find 'bootstrap.jam' which doesn't exist on my 
> system.
> The directory structure of the Debian boost package appears to be very 
> different to the official one, and is obviously missing a few files. How can 
> I fix this?
> I installed all the libboost packages that were available to me on a Debian 
> installation DVD I bought.
> Here are the versions of the relevant packages:
> 
> libboost-* : 1.32.0-6
> bjam : 3.1.10-1
> gcc : 4:3.3.5-3
> python : 2.3.5-2
> 
> Can anyone help me?

unfortunately there is no boost-build package available for sarge. this
lets bjam package almost unusable.

you should download and extract the boost sources with the following
command:

$ apt-get source boost

then you should be able to follow the instructions of the tutorial.

cheers
domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


From duranlef at iro.umontreal.ca  Wed Jan 18 21:09:51 2006
From: duranlef at iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Duranleau?=)
Date: Wed, 18 Jan 2006 15:09:51 -0500 (EST)
Subject: [C++-sig] optimizing away calls to the python runtime -- was
 [detecting if a function is written in python or C++]
In-Reply-To: <43CE1FEB.3090109@sophia.inria.fr>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
	<1137487349.31678.85.camel@chronos>
	<87bqya7qnf.fsf@boost-consulting.com>
	<Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>
	<43CE1FEB.3090109@sophia.inria.fr>
Message-ID: <Pine.LNX.4.63.0601181223490.9529@brocoli.iro.umontreal.ca>

On Wed, 18 Jan 2006, mathieu lacage wrote:

> hi,
>
> Fran?ois Duranleau wrote:
>
>>  with C++ name patterns. As a matter of fact, we could also use a hack
>> with the __class__ attribute (it seems like the value for all
>> Boost.Python classes is <type 'Boost.Python.class'>. But what about
>> C++ functions? Are we
>
>
> What would such a hack do ? Recognize which classes are exported by
> boost.python and are thus C++ bound classes ? What would you use this for ?

It could be used like this:

def make_callback( obj ) :
     if repr( obj.__class__.__class__ ) \
        == "<type 'Boost.Python.class'>" :
         return obj
     else :
         return convert_python_object_to_boost_function( obj )

This solves some of the problems with the approach I suggested using 
boost::function (uniformity). I don't like it much more than the name 
pattern approach though, especially because if the name of the type ever 
changes, it breaks down. Also, to deal with C++ functions, we still have 
to define some wrapper functors in C++.

Actually, it is not so hard to write some helpers to make this easier 
(wrapping functions). I have updated my example with the use of 
make_callback as above and I added some helpers. Everything is still at:

http://www-etud.iro.umontreal.ca/~duranlef/python/

All that being said, coming back to the hack, in a case like your callback 
framework, I don't think it can be very useful. Your approach has the 
advantage of dealing directly with the non-wrapped function/functor, and 
the hack (__class__ attribute) is not very useful in selecting and 
instantiating the desired callback wrapper (at least, I don't see how 
either).

Now coming back to your framework, you said at some point that the process 
could be helped with templates for exporting function wrappers. Well, I 
think you could use a pattern similar to the helper I wrote in my new 
example. Here is how (not tested):

template < typename Function ,
            typename Tag >
struct function_wrapper_callback
     : Callback1
{
     static Function func ;

     void operator () ( int a )
     {
         func( a ) ;
     }
} ;

template < typename Function ,
            typename Tag >
Function function_wrapper< Function , Tag >::func = Function() ;

template < typename Tag ,
            typename Function >
void
export_function_callback( Function f ,
                           const char* name )
{
     typedef function_wrapper_callback< Function , Tab > callback_type ;

     // Ensures unicity of callback_type for f
     assert( callback_type::func == Function() ) ;

     callback_type::func = f ;

     class_< callback_type ,
             bases< Callback1 > ,
             boost::noncopyable >( name ) ;
}


And in the module section, taking your example of function 
'real_function', you could export it like this:

// declare the tag ouside of BOOST_PYTHON_MODULE(...)
struct real_function_tag ;

export_function_callback< real_function_tag >( & real_function ,
                                                "real_function_callback" );

This also should work out of the box with stateless functors.

You can do something similar with methods by adding a member 'self' in the 
wrapper (pointer to the object), a constructor with the object to bind to 
the method as an argument, and calling the method with ->. in operator(). 
Actually, I think you could even have a single wrapper for both functions 
and method using boost::function and boost::bind.

-- 
Fran?ois Duranleau
LIGUM, Universit? de Montr?al

"All wealth is created by human beings using their neurons intelligently."
                           - Robert Anton Wilson, _Prometheus Rising_, 1983

From grant at grantgoodyear.org  Wed Jan 18 22:25:07 2006
From: grant at grantgoodyear.org (Grant Goodyear)
Date: Wed, 18 Jan 2006 15:25:07 -0600
Subject: [C++-sig] dumb policy question
Message-ID: <20060118212507.GC2939@bmb24.uth.tmc.edu>

I'm currently in the process of modifying some C code so that it can
be accessed from python using boost.python.  I've attached ref.h and
libpyref.cpp (and doref.cpp as a test program for ref.h), and I'm hoping
some kind soul can tell me what I need to do to get this simple snippet
to work correctly.  Right now I get the following:

In [1]:import libpyref

In [2]:ints = [0,0,0,0]

In [3]:libpyref.ref(ints,2)
---------------------------------------------------------------------------
Boost.Python.ArgumentError                             Traceback (most
recent call last)

/home/grant/EMAN2/playground/<console> 

ArgumentError: Python argument types in
    libpyref.ref(list, int)
did not match C++ signature:
    ref(std::vector<int, std::allocator<int> > {lvalue}, int)

I'm not sure if the problem is the policy, or that I need some sort of
typeconverter because what I'm asking is beyond the magic converters
already in boost_python?

Thanks,
Grant Goodyear
-- 
Grant Goodyear		
web: http://www.grantgoodyear.org	
e-mail: grant at grantgoodyear.org	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ref.h
Type: text/x-chdr
Size: 150 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060118/03bfd459/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpyref.cpp
Type: text/x-c++src
Size: 524 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060118/03bfd459/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doref.cpp
Type: text/x-c++src
Size: 270 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060118/03bfd459/attachment-0001.cpp>

From grant at grantgoodyear.org  Thu Jan 19 00:13:36 2006
From: grant at grantgoodyear.org (Grant Goodyear)
Date: Wed, 18 Jan 2006 17:13:36 -0600
Subject: [C++-sig] dumb policy question
In-Reply-To: <20060118212507.GC2939@bmb24.uth.tmc.edu>
References: <20060118212507.GC2939@bmb24.uth.tmc.edu>
Message-ID: <20060118231336.GD2939@bmb24.uth.tmc.edu>

Okay, so I read through the FAQ again and see "How can I wrap
functions which take C++ containers as arguments", from which I 
gather that the answer is "it's really darn hard, and probably 
not worth the effort", if I understand it correctly.

Hmmm.
-Grant-
-- 
Grant Goodyear		
web: http://www.grantgoodyear.org	
e-mail: grant at grantgoodyear.org	


From dave at boost-consulting.com  Fri Jan 20 17:04:07 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 20 Jan 2006 11:04:07 -0500
Subject: [C++-sig] new docstring_options and related features
References: <20060116214131.85920.qmail@web31515.mail.mud.yahoo.com>
Message-ID: <u64oekhs8.fsf@boost-consulting.com>

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

> The most recent Boost CVS includes a new boost/python/docstring_options.hpp
> header plus reference documentation with examples, available for review here:
>
> http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/docstring_options.html
>
> The main new feature is that C++ signatures are automatically appended to the
> docstrings. This is the default behavior. The signatures or complete docstrings
> may be suppressed by way of the docstring_options class. See the documentation
> for details. Please let me know if something is not clear.
>
> I've also (finally) integrated Ult Mundane's patch to work around broken gcc
> name demanglers. I.e. the signatures produced by Boost.Python will now show
> full type names with all recent gcc versions. Thanks Ult!

Ralf, this is great stuff!

Could you please update libs/python/doc/news.html page and the "Latest
News" section on the Boost homepage?
 
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From dave at boost-consulting.com  Fri Jan 20 18:46:43 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 20 Jan 2006 12:46:43 -0500
Subject: [C++-sig] Pyste/Pyplusplus/Boost documentation problems
References: <873bjnaipg.fsf@boost-consulting.com>
	<43CD44C2.897.2EDE297A@s_sourceforge.nedprod.com>
Message-ID: <uslrihjwc.fsf@boost-consulting.com>

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

> On 16 Jan 2006 at 17:52, David Abrahams wrote:
>
>> > That would be inadvisable. The best thing is for pyste users to 
>> > regenerate their config files from scratch as pyplusplus uses quite a 
>> > different configuration model (nowhere near as easy, but considerably 
>> > more powerful).
>> 
>> I disagree.  If you're going to use a wrapper generator, it should be
>> as easy as possible.  If Pyste has a reasonably terse, expressive
>> input syntax that matches the user's mental model (something I
>> encouraged Bruno to develop and that Roman could have learned from),
>> then pyplusplus should use it or improve on it.  To do otherwise would
>> be inconsistent with the design spirit and aims of Boost.Python.
>> There's no reason a lower-level interface couldn't be available, too,
>> if necessary.
>
> The configuration setup for pyplusplus is much more terse than pyste 

Then why am I being told it isn't as easy?

>> > He nor I mean no disrespect to Bruno, pyste is a good bindings
>> > generator but it has hard design limits in it and Roman gives a
>> > pretty good overview of those.
>> 
>> The tone could be more neutral, with all the facts and less gloating
>> (well, "gloating" is not quite the right word but I can't think of a
>> better one right now).
>
> I very much doubt if I could write in a non-gloating style in Spanish 
> or German. You have to use the words and phrases you know and do the 
> best you can. Unfortunately they often don't carry the tone you mean.

I wasn't condemning anyone; I was just saying the page can be
improved.  

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



From doremix at gmail.com  Mon Jan 23 15:52:37 2006
From: doremix at gmail.com (Xavier Baele)
Date: Mon, 23 Jan 2006 15:52:37 +0100
Subject: [C++-sig] Inheritance
Message-ID: <aae0da0f0601230652i6f104911id6ed57c50413603a@mail.gmail.com>

Hello,
I try to use inheritance in Boost.Python but I probably make something wrong
because I have a strange error:

Here is the code:
"DeriveCpp" is a C++ class derived from a "Base" C++ class

    flagCpp=pymg.DeriveCPP()
    print flagCpp.getValue()     (*) --> OK
    pymg.func(flagCpp)
    print flagCpp.getValue()     (**)--> Error:
                  Boost.Python.ArgumentError: Python argument types in
DeriveCPP.getValue(DeriveCPP)
                  did not match C++ signature: getValue(class Derive
{lvalue})

while the first call (*) works, the second one (**) fails if I call the C++
pymg.func(...) function between.

Any idea what is wrong in my code?  Here is the wrapping code for the
classes and function

                        Thanks a lot,

                                  Xavier


class Base {
public:
    virtual int getValue() = 0;
};

struct BaseWrap : Base, wrapper<Base> { // Warper is used because of the
pure virtual function
    int getValue() { return this->get_override("getValue")();}
};

class Derive : public Base {
public:
    Derive() {}
    virtual int getValue() { return 1000;}
};

struct DeriveWrap : Derive, wrapper<Derive> { // Warper is used because of
the virtual function
public:
    int getValue()  {
        if (override getValue = this->get_override("getValue"))
            return getValue();
        return Derive::getValue();
    }
};

void func_base(std::auto_ptr<Base> pkBase) // auto_ptr<> used here to give
C++ ownership
{
    // ...
}

BOOST_PYTHON_MODULE(pymg)
{
    def("func", &func_base);

    class_<BaseWrap, std::auto_ptr<BaseWrap>, boost::noncopyable>("Base")
        .def("getValue", pure_virtual(&Base::getValue));

    class_<DeriveWrap, std::auto_ptr<DeriveWrap>, boost::noncopyable,
bases<Base> >("DeriveCPP")
        .def("getValue", &Derive::getValue);

    implicitly_convertible<
         std::auto_ptr<DeriveWrap>
       , std::auto_ptr<Base>
     >();
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060123/e4024133/attachment.htm>

From roman.yakovenko at gmail.com  Mon Jan 23 16:31:02 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 23 Jan 2006 17:31:02 +0200
Subject: [C++-sig] Inheritance
In-Reply-To: <aae0da0f0601230652i6f104911id6ed57c50413603a@mail.gmail.com>
References: <aae0da0f0601230652i6f104911id6ed57c50413603a@mail.gmail.com>
Message-ID: <7465b6170601230731x2dffa010xfb43064b6f8a093f@mail.gmail.com>

On 1/23/06, Xavier Baele <doremix at gmail.com> wrote:
> Hello,
>  I try to use inheritance in Boost.Python but I probably make something
> wrong because I have a strange error:
>
>  Here is the code:
>  "DeriveCpp" is a C++ class derived from a "Base" C++ class
>
>      flagCpp=pymg.DeriveCPP()
>      print flagCpp.getValue()     (*) --> OK
>      pymg.func(flagCpp)
>      print flagCpp.getValue()     (**)--> Error:
>                    Boost.Python.ArgumentError: Python argument types in
> DeriveCPP.getValue(DeriveCPP)
>                    did not match C++ signature: getValue(class Derive
> {lvalue})
>
>  while the first call (*) works, the second one (**) fails if I call the C++
> pymg.func(...) function between.
>
>  Any idea what is wrong in my code?  Here is the wrapping code for the
> classes and function
>
>                          Thanks a lot,
>
>                                    Xavier
>
>
>  class Base {
>  public:
>      virtual int getValue() = 0;
>  };
>
>  struct BaseWrap : Base, wrapper<Base> { // Warper is used because of the
> pure virtual function
>      int getValue() { return
> this->get_override("getValue")();}
>  };
>
>  class Derive : public Base {
>  public:
>      Derive() {}
>      virtual int getValue() { return 1000;}
>  };
>
>  struct DeriveWrap : Derive, wrapper<Derive> { // Warper is used because of
> the virtual function
>  public:
>      int getValue()  {
>          if (override getValue = this->get_override("getValue"))
>              return getValue();
>          return Derive::getValue();
>      }
>  };
>
>  void func_base(std::auto_ptr<Base> pkBase) // auto_ptr<> used here to give
> C++ ownership
>  {
>      // ...
>  }
>
>  BOOST_PYTHON_MODULE(pymg)
>  {
>      def("func", &func_base);
>
>      class_<BaseWrap, std::auto_ptr<BaseWrap>, boost::noncopyable>("Base")
>          .def("getValue", pure_virtual(&Base::getValue));
>
>      class_<DeriveWrap, std::auto_ptr<DeriveWrap>, boost::noncopyable,
> bases<Base> >("DeriveCPP")
>          .def("getValue", &Derive::getValue);
>
>      implicitly_convertible<
>           std::auto_ptr<DeriveWrap>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think that this should be Derive. I could be wrong. Test your use-case with
pyplusplus code generator. It has nice GUI and I am sure it can handle
your case.
Just try it. http://www.language-binding.net/pyplusplus/pyplusplus.html

>         , std::auto_ptr<Base>
>       >();
>  }
>

Roman Yakovenko


From grant at grantgoodyear.org  Mon Jan 23 19:05:06 2006
From: grant at grantgoodyear.org (Grant Goodyear)
Date: Mon, 23 Jan 2006 12:05:06 -0600
Subject: [C++-sig] easy method for converting boost::tuple to python tuple?
Message-ID: <20060123180506.GS2939@bmb24.uth.tmc.edu>

I have a c++ function that returns boost::tuple<double, float, int>.  From
python I get the following when I try to access this function::

No to_python (by-value) converter found for C++ type:
boost::tuples::tuple<double, float, int, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type>

Fair enough, I need to tell boost.python what to do.  Google provides
the following link:
http://mail.python.org/pipermail/c++-sig/2002-July/001722.html
which is a tad dated.  Is there a simple way to tell boost.python
how to perform the conversion?

Thanks,
Grant Goodyear
-- 
Grant Goodyear		
web: http://www.grantgoodyear.org	
e-mail: grant at grantgoodyear.org	


From grant at grantgoodyear.org  Mon Jan 23 20:52:20 2006
From: grant at grantgoodyear.org (Grant Goodyear)
Date: Mon, 23 Jan 2006 13:52:20 -0600
Subject: [C++-sig] Adding .staticmethod from pyste?
Message-ID: <20060123195220.GV2939@bmb24.uth.tmc.edu>

I'm adding a new method to my Util class:

    Util = Class("EMAN::Util", "util_wrapitems.h")
    exclude(Util.Crosrng_e)
    add_method(Util, "util_Crosrng_e")
    rename(Util.util_Crosrng_e, "Crosrng_e")

My only problem is that the new Util.Crosrng_e method is a static
method of Util, and I'm not sure how to convey that information to
pyste so that it inserts the appropriate .staticmethod("Crosrng_e")
line in the .cpp file that pyste generates.

Help?

Thanks,
Grant Goodyear
-- 
Grant Goodyear		
web: http://www.grantgoodyear.org	
e-mail: grant at grantgoodyear.org	


From dave at boost-consulting.com  Mon Jan 23 20:58:21 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 23 Jan 2006 14:58:21 -0500
Subject: [C++-sig] easy method for converting boost::tuple to python
	tuple?
References: <20060123180506.GS2939@bmb24.uth.tmc.edu>
Message-ID: <uvewak97m.fsf@boost-consulting.com>

Grant Goodyear <grant at grantgoodyear.org> writes:

> I have a c++ function that returns boost::tuple<double, float, int>.  From
> python I get the following when I try to access this function::
>
> No to_python (by-value) converter found for C++ type:
> boost::tuples::tuple<double, float, int, boost::tuples::null_type,
> boost::tuples::null_type, boost::tuples::null_type,
> boost::tuples::null_type, boost::tuples::null_type,
> boost::tuples::null_type, boost::tuples::null_type>
>
> Fair enough, I need to tell boost.python what to do.  Google provides
> the following link:
> http://mail.python.org/pipermail/c++-sig/2002-July/001722.html
> which is a tad dated.  Is there a simple way to tell boost.python
> how to perform the conversion?

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

should set you on the right path.

  // Untested!
  #include <boost/python/tuple.hpp>
  #include <boost/python/module.hpp>
  #include <boost/python/refcount.hpp>


  namespace python = boost::python;
  namespace tuples = boost::tuples;

  namespace my
  {
    template <class H, class T>
    python::tuple tuple_to_python(tuples::cons<H,T> const& x)
    {
        return python::make_tuple(x) + my::tuple_to_python(x.tail);
    }

    python::tuple tuple_to_python(tuples::null_type)
    {
        return python::tuple();
    }

    template <class T>
    struct tupleconverter
    {
        static PyObject* convert(T const& x)
        {
            return python::incref(my::tuple_to_python(x).ptr());
        }
    };
  }

  BOOST_PYTHON_MODULE(whatever)
  {
      to_python_converter<my_tuple_type, tupleconverter<my_tuple_type> >();
  }

Something like this really should be in the library already, though,
shouldn't it?

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



From roman.yakovenko at gmail.com  Tue Jan 24 07:56:47 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 24 Jan 2006 08:56:47 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
Message-ID: <7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>

Hi. pyplusplus project made first step towards ( better ) documentation.
I created step by step tutorials.
You can find it here: http://language-binding.net/pyplusplus/tutorials.html
Also pyplusplus GUI has wizard. It will generate pyplusplus code for you.
In order to try it you need cvs version.

What is pyplusplus?
pyplusplus is an object-oriented framework for creating a code
generator for boost.python library

All comments, suggestions or correction are welcome.

Enjoy

Roman Yakovenko


From baas at ira.uka.de  Tue Jan 24 10:22:09 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Tue, 24 Jan 2006 10:22:09 +0100
Subject: [C++-sig] Patch: Two more addressof() substitutions in
	value_holder.hpp
Message-ID: <dr4rjd$g0i$1@sea.gmane.org>

Hi,

I've just updated to Boost 1.33.1 and also extended a wrapper of mine 
and stumbled over two more occurrences of the address operator in 
value_holder.hpp that I had to substitute by the addressof() function 
(because in the SDK I'm wrapping there are private address operators, 
see the original thread over here: 
http://thread.gmane.org/gmane.comp.python.c++/8661 "Wrapping a class 
with private operator&()").

The two substitutions were in line 104 and 109 in value_holder.hpp 
(there's a patch below).

Sorry that I missed that one last time...

- Matthias -


--- value_holder.hpp.orig       2005-10-14 17:05:40.000000000 +0200
+++ value_holder.hpp    2006-01-18 12:27:38.000000000 +0100
@@ -101,12 +101,12 @@
      type_info dst_t, bool null_ptr_only)
  {
      type_info src_t = python::type_id<Value>();
-    Value* x = &m_held;
+    Value* x = boost::addressof(m_held);

      if (dst_t == src_t)
          return x;
      else if (dst_t == python::type_id<Held>())
-        return &m_held;
+        return boost::addressof(m_held);
      else
          return find_static_type(x, src_t, dst_t);
  }



From s_sourceforge at nedprod.com  Tue Jan 24 11:09:42 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 24 Jan 2006 10:09:42 -0000
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <438985AD.32440.B7578@s_sourceforge.nedprod.com>
References: <436E4390.14657.548C6F9@localhost>
Message-ID: <43D5FCE6.24282.50ED75FB@s_sourceforge.nedprod.com>

On 27 Nov 2005 at 10:08, Niall Douglas wrote:

> Attached is a slightly fixed version of the patch. When is this patch 
> going to be applied?

Any movement on getting this patch applied to CVS?

Cheers,
Niall

> 
> On 6 Nov 2005 at 17:55, Niall Douglas wrote:
> 
> > The enclosed patch adds void * support to Boost.Python by making void 
> > an opaque type. Code that uses void * "just works" with this patch 
> > with no further effort required.
> > 
> > Also enclosed is a testcase and the docs have been modified.
> > 
> > Ran full testsuite on msvc7.1 and msvc6 - everything works. I don't 
> > have GCC to hand ATM, but apart from maybe a missing typename 
> > specifier I can't see anything which would fault.
> 
> I understand from Roman that I have too many typenames in there, but 
> other than this trivial fix the patch works perfectly on GCC.
> 
> Cheers,
> Niall
> 
> 
> 
> 






From roman.yakovenko at gmail.com  Tue Jan 24 12:08:17 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 24 Jan 2006 13:08:17 +0200
Subject: [C++-sig] void* patch
Message-ID: <7465b6170601240308j1e3d2774i33e4cfb82852f965@mail.gmail.com>

Hi. What should be done in order to let Niall void* patch to be accepted?

May be there is some objection to this patch?

Thanks

Roman Yakovenko


From ndbecker2 at gmail.com  Tue Jan 24 13:28:04 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 24 Jan 2006 07:28:04 -0500
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
Message-ID: <dr56gk$jkg$1@sea.gmane.org>

Roman Yakovenko wrote:

> Hi. pyplusplus project made first step towards ( better ) documentation.
> I created step by step tutorials.
> You can find it here:
> http://language-binding.net/pyplusplus/tutorials.html Also pyplusplus GUI
> has wizard. It will generate pyplusplus code for you. In order to try it
> you need cvs version.
> 
> What is pyplusplus?
> pyplusplus is an object-oriented framework for creating a code
> generator for boost.python library
> 
> All comments, suggestions or correction are welcome.
> 
> Enjoy
> 
> Roman Yakovenko

Thank you!

1 problem so far.  I tried to follow the example but:
from environment import settings

I don't seem to have an 'environment' module:

>>> import os
>>> from environment import settings
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named environment

Where did this come from?



From roman.yakovenko at gmail.com  Tue Jan 24 14:05:31 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 24 Jan 2006 15:05:31 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <dr56gk$jkg$1@sea.gmane.org>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
	<dr56gk$jkg$1@sea.gmane.org>
Message-ID: <7465b6170601240505v72415548ob73142c9e5abcc98@mail.gmail.com>

On 1/24/06, Neal Becker <ndbecker2 at gmail.com> wrote:
> Roman Yakovenko wrote:
>
> > Hi. pyplusplus project made first step towards ( better ) documentation.
> > I created step by step tutorials.
> > You can find it here:
> > http://language-binding.net/pyplusplus/tutorials.html Also pyplusplus GUI
> > has wizard. It will generate pyplusplus code for you. In order to try it
> > you need cvs version.
> >
> > What is pyplusplus?
> > pyplusplus is an object-oriented framework for creating a code
> > generator for boost.python library
> >
> > All comments, suggestions or correction are welcome.
> >
> > Enjoy
> >
> > Roman Yakovenko
>
> Thank you!

My pleasure

> 1 problem so far.  I tried to follow the example but:
> from environment import settings
>
> I don't seem to have an 'environment' module:
>
> >>> import os
> >>> from environment import settings
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: No module named environment
>
> Where did this come from?

>From here.
http://cvs.sourceforge.net/viewcvs.py/pygccxml/source/pyplusplus/examples/tutorials/

I wrote the code and after this I created tutorials. Any way I already
fixed this issue.
Thank you.

Small advice: try GUI, it will generated pyplusplus code for your use case.

Roman Yakovenko


From baas at ira.uka.de  Tue Jan 24 16:34:23 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Tue, 24 Jan 2006 16:34:23 +0100
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
Message-ID: <dr5hd9$usp$1@sea.gmane.org>

Roman Yakovenko wrote:
> Hi. pyplusplus project made first step towards ( better ) documentation.
> I created step by step tutorials.
> [...]
> All comments, suggestions or correction are welcome.

It's good to see a more or less introductory tutorial as I couldn't 
extract enough information from the previous pages to get started with 
pyplusplus.

First, there's a typo on the page and a bug in the code:

- In step 3 of the tutorial you access the attribute 
"parser_configuration.working_directory" whereas a few lines above the 
configuration object was called "parser_config".

- In method __raise_on_wrong_settings() in 
pygccxml/parser/source_reader.py the variable environment_var_delimiter 
is only defined on Windows but not on other platforms which will raise 
an exception on those other platforms some lines later in the method 
(when the variable is used).


Now to pyplusplus itself, as a "hello world" example I found the 
required Python script rather complicated. It feels as if a lot of the 
code in those driver scripts will be identical among projects, so why 
does this have to be provided by the user and why isn't it put under the 
hood of pyplusplus instead? Personally I'd prefer the "signal-to-noise 
ratio" in the config/driver file to be as high as possible, i.e. the 
file should only contain information that really must be provided by the 
user and that pyplusplus cannot know itself. In the tutorial this would 
be the input file name and maybe the output module name (which could 
even be deduced from the input file name by default). I would say Pyste 
performs much better in this respect as its "hello world" example only 
requires a single line.
So I'd suggest to add a command line tool to pyplusplus that reads a 
config file (Python code) that can contain the required information in a 
much more concise manner. You wouldn't loose any flexibility and you 
could remove any "unnecessary" code (that would always be the same). An 
additional benefit of having a separate command line tool would be that 
there is something I can invoke and request some help from it.

Another wish of mine would be to output some descriptive information (or 
a log file) about what the program is currently doing. For example, I 
tried to wrap a class from a commercial SDK but failed (the output file 
is almost empty and I get another file __array_1.pypp.hpp that is 
neither referenced in the actual output file nor does it contain 
anything that looks as if it was related to the classes in the SDK). I 
have no idea what went wrong as there hasn't been any message at all 
(let alone an error or warning message). Here, it would be useful if the 
program would output what it saw in the input file (how many classes, 
functions, etc.) and what it is going to output, etc.

So at the end, this round went to Pyste, but I'm eagerly awaiting the 
next rounds... :)
(I'll definitely keep an eye on pyplusplus as with using Pyste I had to 
add some manual tweaks, so it's not perfect as well)

- Matthias -



From dave at boost-consulting.com  Tue Jan 24 16:51:56 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 24 Jan 2006 10:51:56 -0500
Subject: [C++-sig] Patch implementing void * support
References: <436E4390.14657.548C6F9@localhost>
	<43D5FCE6.24282.50ED75FB@s_sourceforge.nedprod.com>
Message-ID: <ulkx5fwtf.fsf@boost-consulting.com>

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

> On 27 Nov 2005 at 10:08, Niall Douglas wrote:
>
>> Attached is a slightly fixed version of the patch. When is this patch 
>> going to be applied?
>
> Any movement on getting this patch applied to CVS?

All the ones you've posted come with disclaimers or corrections, such
as:

  I understand from Roman that I have too many typenames in there, but
  other than this trivial fix the patch works perfectly on GCC.

and: 

  You don't need those lines ( at least on GCC 3.3 ):
  +
  +// Declare void as an opaque type for automatic void * usage
  +namespace boost { namespace python {

Please post a definitive patchset.

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



From s_sourceforge at nedprod.com  Tue Jan 24 21:34:38 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 24 Jan 2006 20:34:38 -0000
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <ulkx5fwtf.fsf@boost-consulting.com>
Message-ID: <43D68F5E.2122.532999A2@s_sourceforge.nedprod.com>

On 24 Jan 2006 at 10:51, David Abrahams wrote:

> All the ones you've posted come with disclaimers or corrections, such
> as:
> 
>   I understand from Roman that I have too many typenames in there, but
>   other than this trivial fix the patch works perfectly on GCC.

It was literally a case of removing some unnecessary typename 
keywords. It didn't take two seconds and at that time I didn't have 
access to Linux. I do now.

Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.

Cheers,
Niall



-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  voidptrpatch.diff
     Date:  24 Jan 2006, 20:30
     Size:  4859 bytes.
     Type:  Unknown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voidptrpatch.diff
Type: application/octet-stream
Size: 4858 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060124/93131551/attachment.obj>
-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  voidptr.py
     Date:  24 Jan 2006, 20:15
     Size:  1114 bytes.
     Type:  Unknown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voidptr.py
Type: application/octet-stream
Size: 1113 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060124/93131551/attachment-0001.obj>
-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  voidptr.cpp
     Date:  24 Jan 2006, 20:15
     Size:  892 bytes.
     Type:  Program-source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voidptr.cpp
Type: application/octet-stream
Size: 892 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060124/93131551/attachment-0002.obj>

From roman.yakovenko at gmail.com  Wed Jan 25 07:00:27 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 25 Jan 2006 08:00:27 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <dr5hd9$usp$1@sea.gmane.org>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
	<dr5hd9$usp$1@sea.gmane.org>
Message-ID: <7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>

On 1/24/06, Matthias Baas <baas at ira.uka.de> wrote:
> It's good to see a more or less introductory tutorial as I couldn't
> extract enough information from the previous pages to get started with
> pyplusplus.

What information is missing?

> First, there's a typo on the page and a bug in the code:
>
> - In step 3 of the tutorial you access the attribute
> "parser_configuration.working_directory" whereas a few lines above the
> configuration object was called "parser_config".

Thank you. Fixed. I will publish it very soon.

> - In method __raise_on_wrong_settings() in
> pygccxml/parser/source_reader.py the variable environment_var_delimiter
> is only defined on Windows but not on other platforms which will raise
> an exception on those other platforms some lines later in the method
> (when the variable is used).

Thank you, fixed.

>
> Now to pyplusplus itself, as a "hello world" example I found the
> required Python script rather complicated. It feels as if a lot of the
> code in those driver scripts will be identical among projects,

This is a wrong filling. The structure of the code will be the same - yes.
The code itself - no.

>so why
> does this have to be provided by the user and why isn't it put under the
> hood of pyplusplus instead?

What do you mean. If you mean parsing\reading C++ then the answer is simple:
pyplusplus does not care from where you read declarations. And I thing
that keeping
this separation is important.

>Personally I'd prefer the "signal-to-noise
> ratio" in the config/driver file to be as high as possible, i.e. the
> file should only contain information that really must be provided by the
> user and that pyplusplus cannot know itself. In the tutorial this would
> be the input file name and maybe the output module name (which could
> even be deduced from the input file name by default). I would say Pyste
> performs much better in this respect as its "hello world" example only
> requires a single line.

Here I don't agree with you. The complexity on start with pyplusplus is higher,
you are right. But the point is that this complexity will grow only a
little with pyplusplus.
With Pyste this is not true. I did not try to write the shorter
version, but rather to
show main and strong sides of pyplusplus. If I write a function that
will do the job and
show only this function within tutorials it will say nothing about
pyplusplus and why it
is better then Pyste.

> So I'd suggest to add a command line tool to pyplusplus that reads a
> config file (Python code) that can contain the required information in a
> much more concise manner. You wouldn't loose any flexibility and you
> could remove any "unnecessary" code (that would always be the same). An
> additional benefit of having a separate command line tool would be that
> there is something I can invoke and request some help from it.

There is such tool: GUI. If you don't need any customization use it. You raise
valid point here: pyplusplus GUI does not have persistent state and you can
not invoke it from script to run on the state. You are welcome to contribute.
I will add it to wish list.

> Another wish of mine would be to output some descriptive information (or
> a log file) about what the program is currently doing. For example, I
> tried to wrap a class from a commercial SDK but failed (the output file
> is almost empty and I get another file __array_1.pypp.hpp that is
> neither referenced in the actual output file nor does it contain
> anything that looks as if it was related to the classes in the SDK). I
> have no idea what went wrong as there hasn't been any message at all
> (let alone an error or warning message). Here, it would be useful if the
> program would output what it saw in the input file (how many classes,
> functions, etc.) and what it is going to output, etc.

First version of pyplusplus have some logging functionality. But then I dropped
it for performance reasons. I think that I will add logging again, but this time
I will write statistics only. Thanks for the tip.

> So at the end, this round went to Pyste, but I'm eagerly awaiting the
> next rounds... :)

I don't think so, but I am not objective.

> (I'll definitely keep an eye on pyplusplus as with using Pyste I had to
> add some manual tweaks, so it's not perfect as well)

If you are fine with Pyste, stay with it. I see no reason to replace
something that
doing it's job.

> - Matthias -

Thanks for review and tips.

Roman Yakovenko


From baas at ira.uka.de  Wed Jan 25 21:41:02 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Wed, 25 Jan 2006 21:41:02 +0100
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>	<dr5hd9$usp$1@sea.gmane.org>
	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>
Message-ID: <dr8no2$822$1@sea.gmane.org>

Roman Yakovenko wrote:
> On 1/24/06, Matthias Baas <baas at ira.uka.de> wrote:
>> It's good to see a more or less introductory tutorial as I couldn't
>> extract enough information from the previous pages to get started with
>> pyplusplus.
> 
> What information is missing?

Well, for example, the information from the new tutorial was missing. 
Before the tutorial it was not obvious to me how the tool actually works 
and what steps are required from the user.

>> so why
>> does this have to be provided by the user and why isn't it put under the
>> hood of pyplusplus instead?
> 
> What do you mean. If you mean parsing\reading C++ then the answer is simple:
> pyplusplus does not care from where you read declarations. And I thing
> that keeping this separation is important.

That's not really what I meant. I have absolutely no objections of your 
design to keep parsing the sources and creating the output separate 
processes. I second that design and I don't argue that you should change 
that. But why not adding some additional layer above this design that 
hides this implementation detail if not otherwise specified. I think 
most if not all users will use pygccxml to parse the sources (what other 
choice do they have?), so why not make that the default procedure?

Step 1 of the tutorial consists of 12 lines of code where there are only 
two things that I really had to specify: the name of the input header 
file and a filtering rule (whereas gccxml is on my path, so I didn't 
need to specify that in the driver file. And as long as pyplusplus 
cleans up its temporary files, I don't really care where it puts them 
(don't get me wrong, it's absolutely ok to be able to change these 
things but I shouldn't be forced to set them)). Now to pass these two 
pieces of data to pyplusplus I had to import several modules, create a 
class and call some functions. Maybe I'm wrong, but these things looked 
as if they were not from a public interface but actually from the 
internals of the program. Exposing that much stuff from inside the 
program has the disadvantage that my driver file becomes dependent on 
them. Should you ever choose to change some of these things for whatever 
reasons, these changes will break all driver scripts out there which 
would be a very bad thing. Such dependencies could be reduced if the 
public interface would be kept more slim and rather be of a descriptive 
nature as it is the case with Pyste (another example would be SCons, 
www.scons.org). Access to the internal API could also be provided but it 
should only be necessary for special cases.

>> Personally I'd prefer the "signal-to-noise
>> ratio" in the config/driver file to be as high as possible, i.e. the
>> file should only contain information that really must be provided by the
>> user and that pyplusplus cannot know itself. In the tutorial this would
>> be the input file name and maybe the output module name (which could
>> even be deduced from the input file name by default). I would say Pyste
>> performs much better in this respect as its "hello world" example only
>> requires a single line.
> 
> Here I don't agree with you. The complexity on start with pyplusplus is higher,
> you are right. But the point is that this complexity will grow only a
> little with pyplusplus.

Granted, but in my experience there have been cases where I really could 
get away with short *.pyste files and there was no need to do complex 
stuff. Currently, this would be prohibited with pyplusplus as there is 
only a relatively complex way to describe the wrappers.
Actually, you wouldn't have to change anything in your package but only 
add an additional layer on top of what is currently there so that for 
easy cases, the descriptions of the wrappers can be as concise as those 
from Pyste.

>> So at the end, this round went to Pyste, but I'm eagerly awaiting the
>> next rounds... :)
> 
> I don't think so, but I am not objective.

Of course, the above was from my point of view. :) The current state of 
the documentation and the tool just couldn't convince me yet to switch 
from Pyste to pyplusplus, which was for the previously mentioned reasons 
(well, maybe the main reason was that I couldn't get it to work with 
that SDK I'm currently wrapping). But as I said, it kept me enough 
interested to provide some feedback (hoping that this will contribute to 
the improvement of pyplusplus) and to try future versions again.
Your work is still appreciated, my criticism is not meant to bash the 
tool but rather to be an incentive to improve it.

- Matthias -



From roman.yakovenko at gmail.com  Thu Jan 26 06:49:00 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Thu, 26 Jan 2006 07:49:00 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <dr8no2$822$1@sea.gmane.org>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
	<dr5hd9$usp$1@sea.gmane.org>
	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>
	<dr8no2$822$1@sea.gmane.org>
Message-ID: <7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>

On 1/25/06, Matthias Baas <baas at ira.uka.de> wrote:
> Roman Yakovenko wrote:
> > What information is missing?
>
> Well, for example, the information from the new tutorial was missing.
> Before the tutorial it was not obvious to me how the tool actually works
> and what steps are required from the user.

If I understand you right, tutorials provides all information in order
to make decision and\or
to start with pyplusplus, right?

>
> >> so why
> >> does this have to be provided by the user and why isn't it put under the
> >> hood of pyplusplus instead?
> >
> > What do you mean. If you mean parsing\reading C++ then the answer is simple:
> > pyplusplus does not care from where you read declarations. And I thing
> > that keeping this separation is important.
>
> That's not really what I meant. I have absolutely no objections of your
> design to keep parsing the sources and creating the output separate
> processes. I second that design and I don't argue that you should change
> that. But why not adding some additional layer above this design that
> hides this implementation detail if not otherwise specified. I think
> most if not all users will use pygccxml to parse the sources (what other
> choice do they have?), so why not make that the default procedure?

There are 2 reasons:
1. Filtering. You want to apply different filters on declarations
within projects.
2. Performance reasons. With pygccxml you can save a lot of time on big projects
    by not compiling a source code with GCC-XML every time. On TnFOX project
    it saves more then 30 seconds on my computer
   ( Windows XP, Pentium 2.4, RAM 1.5G ).

> Step 1 of the tutorial consists of 12 lines of code where there are only
> two things that I really had to specify: the name of the input header
> file and a filtering rule (whereas gccxml is on my path, so I didn't
> need to specify that in the driver file.

You need at least 1 more line import pyplusplus. :-)

>And as long as pyplusplus
> cleans up its temporary files, I don't really care where it puts them
> (don't get me wrong, it's absolutely ok to be able to change these
> things but I shouldn't be forced to set them)).

You are talking about
class settings:
    gccxml_path = '/home/roman/gccxml/bin'
    working_dir = '/tmp'

right?

Well, it seems that I should rewrite this section.
working_dir - is directory of source files, may be I should give it an
other name or
to add some comments.
gccxml_path - you don't really need to specify it. pygccxml will try
to find gccxml
in your path, so basically you don't need to specify it.
May be I need to reflect this fact in tutorials?

> Now to pass these two
> pieces of data to pyplusplus I had to import several modules, create a
> class and call some functions. Maybe I'm wrong, but these things looked
> as if they were not from a public interface but actually from the
> internals of the program. Exposing that much stuff from inside the
> program has the disadvantage that my driver file becomes dependent on
> them. Should you ever choose to change some of these things for whatever
> reasons, these changes will break all driver scripts out there which
> would be a very bad thing.

Even if I hide those details and do not expose them to you. Tomorrow
you can find
some bug. Lets say that I can fix that bug only by adding new argument
to a function.
In other words I will ask for more information from you. This change
also breaks your code.
Right? So you are not really safe from dependencies.

> Such dependencies could be reduced if the
> public interface would be kept more slim and rather be of a descriptive
> nature as it is the case with Pyste (another example would be SCons,
> www.scons.org). Access to the internal API could also be provided but it
> should only be necessary for special cases.

I see your point. I think that I will add few convenience function to
mimic Pyste behaviour.

> >> Personally I'd prefer the "signal-to-noise
> >> ratio" in the config/driver file to be as high as possible, i.e. the
> >> file should only contain information that really must be provided by the
> >> user and that pyplusplus cannot know itself. In the tutorial this would
> >> be the input file name and maybe the output module name (which could
> >> even be deduced from the input file name by default). I would say Pyste
> >> performs much better in this respect as its "hello world" example only
> >> requires a single line.
> >
> > Here I don't agree with you. The complexity on start with pyplusplus is higher,
> > you are right. But the point is that this complexity will grow only a
> > little with pyplusplus.
>
> Granted, but in my experience there have been cases where I really could
> get away with short *.pyste files and there was no need to do complex
> stuff. Currently, this would be prohibited with pyplusplus as there is
> only a relatively complex way to describe the wrappers.
> Actually, you wouldn't have to change anything in your package but only
> add an additional layer on top of what is currently there so that for
> easy cases, the descriptions of the wrappers can be as concise as those
> from Pyste.

As I already told I will add few convenience function.
Do you know that you can help? Can you create an interface that you thing should
be in pyplusplus for simple use cases?

I think something like this:

def export_file( file_path, parser_config = config_t() )

def export_files( files, parser_config = config_t() )

What do you think?

> >> So at the end, this round went to Pyste, but I'm eagerly awaiting the
> >> next rounds... :)
> >
> > I don't think so, but I am not objective.
>
> Of course, the above was from my point of view. :) The current state of
> the documentation and the tool just couldn't convince me yet to switch
> from Pyste to pyplusplus, which was for the previously mentioned reasons
> (well, maybe the main reason was that I couldn't get it to work with
> that SDK I'm currently wrapping).

What were the problems? May be I can help you? Or may be you found some bug?

> But as I said, it kept me enough
> interested to provide some feedback (hoping that this will contribute to
> the improvement of pyplusplus) and to try future versions again.
> Your work is still appreciated, my criticism is not meant to bash the
> tool but rather to be an incentive to improve it.

Trust me I've got you right. pyplusplus does not have a lot of users. And such
kind of input is really very very valuable.

> - Matthias -

Thanks

Roman Yakovenko


From baas at ira.uka.de  Thu Jan 26 15:44:49 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Thu, 26 Jan 2006 15:44:49 +0100
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>	<dr5hd9$usp$1@sea.gmane.org>	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>	<dr8no2$822$1@sea.gmane.org>
	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>
Message-ID: <dran86$t5p$1@sea.gmane.org>

Roman Yakovenko wrote:
> If I understand you right, tutorials provides all information in order
> to make decision and\or
> to start with pyplusplus, right?

I wouldn't generalize like that, but tutorials can serve that purpose, 
yes. But of course, it's not the tutorial alone that will influence my 
decision.

>> that. But why not adding some additional layer above this design that
>> hides this implementation detail if not otherwise specified. I think
>> most if not all users will use pygccxml to parse the sources (what other
>> choice do they have?), so why not make that the default procedure?
> 
> There are 2 reasons:
> 1. Filtering. You want to apply different filters on declarations
> within projects.

Right, so all it requires is a way to specify such a filter, for example:

add_filter(by_location("mypath"))

or

filter_by_location("mypath")

> 2. Performance reasons. With pygccxml you can save a lot of time on big projects
>     by not compiling a source code with GCC-XML every time. On TnFOX project
>     it saves more then 30 seconds on my computer
>    ( Windows XP, Pentium 2.4, RAM 1.5G ).

Pyste also has such a feature, so there is already an example that this 
can also be done the "Pyste way".

>> Step 1 of the tutorial consists of 12 lines of code where there are only
>> two things that I really had to specify: the name of the input header
>> file and a filtering rule (whereas gccxml is on my path, so I didn't
>> need to specify that in the driver file.
> 
> You need at least 1 more line import pyplusplus. :-)

Actually, you don't! The config script can run in a prepared namespace 
that already contains everything that is needed. Again, Pyste can serve 
as an example where you also don't have to import anything to use the 
special Pyste commands and classes.

>> And as long as pyplusplus
>> cleans up its temporary files, I don't really care where it puts them
>> (don't get me wrong, it's absolutely ok to be able to change these
>> things but I shouldn't be forced to set them)).
> 
> You are talking about
> class settings:
>     gccxml_path = '/home/roman/gccxml/bin'
>     working_dir = '/tmp'
> 
> right?

Right.

> Well, it seems that I should rewrite this section.
> working_dir - is directory of source files, may be I should give it an
> other name or to add some comments.

ok, then I don't understand it, what source files are you referring to? 
(the directory remains empty after running pyplusplus)

> gccxml_path - you don't really need to specify it. pygccxml will try
> to find gccxml
> in your path, so basically you don't need to specify it.
> May be I need to reflect this fact in tutorials?

Personally, I would leave it away entirely for this introductory 
tutorial and assume anyone who has installed gccxml can invoke the tool 
without specifying the entire path (but this is a minor detail anyway. 
When I tried it out I did already leave it out and passed an empty string).

>> internals of the program. Exposing that much stuff from inside the
>> program has the disadvantage that my driver file becomes dependent on
>> them. Should you ever choose to change some of these things for whatever
>> reasons, these changes will break all driver scripts out there which
>> would be a very bad thing.
> 
> Even if I hide those details and do not expose them to you. Tomorrow
> you can find
> some bug. Lets say that I can fix that bug only by adding new argument
> to a function.
> In other words I will ask for more information from you. This change
> also breaks your code.
> Right? So you are not really safe from dependencies.

Of course not, but the likelihood of breaking code has been reduced (I 
would even argue that it has been reduced considerably).

> As I already told I will add few convenience function.
> Do you know that you can help? Can you create an interface that you thing should
> be in pyplusplus for simple use cases?
> 
> I think something like this:
> 
> def export_file( file_path, parser_config = config_t() )
> 
> def export_files( files, parser_config = config_t() )
> 
> What do you think?

This already looks better than before, but when you agree it's possible 
to simplify the interface so that it's more "Pyste-like" then why not 
using the Pyste interface as a starting point in the first place and 
only improve its weaknesses instead of inventing an entirely new interface.
Personally, I like the Pyste interface, it just needs some additions and 
improvements. In your Pyste-pyplusplus comparison you mention some 
things that cannot be done in Pyste, but it looks to me as these are no 
things that reveal severe flaws in the interface concept of Pyste but 
rather things that just haven't been added yet (but could be added 
without breaking anything else).
So far I see no reason why the simplistic interface of Pyste and the 
actual pyplusplus/pygccxml packages couldn't be combined. Actually, it 
would be great if pyplusplus had an interface that would contain the 
Pyste interface as a subset. This would be a big point for attracting 
people who were formerly using Pyste.

>> (well, maybe the main reason was that I couldn't get it to work with
>> that SDK I'm currently wrapping).
> 
> What were the problems? May be I can help you? Or may be you found some bug?

After having another look at it, I noticed the problem. It was just that 
I still had the recursive option set to False when calling 
module_creator.create() and the class that I tried to wrap resides 
inside a namespace, so I take it pyplusplus only saw the namespace but 
didn't inspect the contents of it.
Now I have an output file that contains some stuff, a lot of stuff 
indeed! Now the question is, how do I reduce this stuff? What filter do 
I have to use? Basically, for now I only want one single class that's 
inside that namespace. So how I can tell pyplusplus to only wrap that 
specific class?

Another thing I noticed, the header files included in the output file 
are specified with their *absolute* path (even standard header files). 
Is this intentional or is this a bug? I'd recommend to output the header 
names just as they were specified in the original files. Currently, this 
prevents me from taking the generated source files to another system and 
  compile them there.

- Matthias -



From dave at boost-consulting.com  Thu Jan 26 17:43:46 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 11:43:46 -0500
Subject: [C++-sig] Patch implementing void * support
References: <ulkx5fwtf.fsf@boost-consulting.com>
	<43D68F5E.2122.532999A2@s_sourceforge.nedprod.com>
Message-ID: <u8xt39by5.fsf@boost-consulting.com>

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

> On 24 Jan 2006 at 10:51, David Abrahams wrote:
>
>> All the ones you've posted come with disclaimers or corrections, such
>> as:
>> 
>>   I understand from Roman that I have too many typenames in there, but
>>   other than this trivial fix the patch works perfectly on GCC.
>
> It was literally a case of removing some unnecessary typename 
> keywords. It didn't take two seconds and at that time I didn't have 
> access to Linux. I do now.
>
> Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.

So these workarounds that are guarded by

  #ifdef BOOST_MSVC

Are known to be needed on vc7.1 as well as vc6?  What about vc8?
You ought to be using BOOST_WORKAROUND here.

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



From dave at boost-consulting.com  Thu Jan 26 18:04:44 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 12:04:44 -0500
Subject: [C++-sig] Patch implementing void * support
References: <ulkx5fwtf.fsf@boost-consulting.com>
	<43D68F5E.2122.532999A2@s_sourceforge.nedprod.com>
	<u8xt39by5.fsf@boost-consulting.com>
Message-ID: <uy8129az7.fsf@boost-consulting.com>

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

> "Niall Douglas" <s_sourceforge at nedprod.com> writes:
>
>> On 24 Jan 2006 at 10:51, David Abrahams wrote:
>>
>>> All the ones you've posted come with disclaimers or corrections, such
>>> as:
>>> 
>>>   I understand from Roman that I have too many typenames in there, but
>>>   other than this trivial fix the patch works perfectly on GCC.
>>
>> It was literally a case of removing some unnecessary typename 
>> keywords. It didn't take two seconds and at that time I didn't have 
>> access to Linux. I do now.
>>
>> Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
>
> So these workarounds that are guarded by
>
>   #ifdef BOOST_MSVC
>
> Are known to be needed on vc7.1 as well as vc6?  What about vc8?
> You ought to be using BOOST_WORKAROUND here.

This really looks careless.  As submitted the patch doesn't compile
because there's a missing

  #include <boost/type_traits/broken_compiler_spec.hpp>

in type_id.hpp

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



From s_sourceforge at nedprod.com  Thu Jan 26 18:09:58 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 26 Jan 2006 17:09:58 -0000
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <u8xt39by5.fsf@boost-consulting.com>
Message-ID: <43D90266.31788.5CBAF075@s_sourceforge.nedprod.com>

On 26 Jan 2006 at 11:43, David Abrahams wrote:

> > Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
> 
> So these workarounds that are guarded by
> 
>   #ifdef BOOST_MSVC
> 
> Are known to be needed on vc7.1 as well as vc6?  What about vc8?
> You ought to be using BOOST_WORKAROUND here.

I copied exactly the code at the end of opaque_pointer_converter.hpp. 
It uses #ifdef BOOST_MSVC, so I reused exactly the same form in 
type_id.hpp.

If opaque_pointer_converter.hpp should be different, then so should 
type_id.hpp. I don't know whether it should be different for msvc7.1 -
 whoever wrote opaque_pointer_converter.hpp is better suited to 
answer that question.

The only reason type_id.hpp needed a separate declaration is because 
GCC complained about adding template specialisations after they have 
been instanced. It's probably a good thing.

Cheers,
Niall





From dave at boost-consulting.com  Thu Jan 26 18:08:20 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 12:08:20 -0500
Subject: [C++-sig] Patch implementing void * support
References: <ulkx5fwtf.fsf@boost-consulting.com>
	<43D68F5E.2122.532999A2@s_sourceforge.nedprod.com>
	<u8xt39by5.fsf@boost-consulting.com>
	<uy8129az7.fsf@boost-consulting.com>
Message-ID: <uslra9at7.fsf@boost-consulting.com>

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

> David Abrahams <dave at boost-consulting.com> writes:
>
>> "Niall Douglas" <s_sourceforge at nedprod.com> writes:
>>
>>> On 24 Jan 2006 at 10:51, David Abrahams wrote:
>>>
>>>> All the ones you've posted come with disclaimers or corrections, such
>>>> as:
>>>> 
>>>>   I understand from Roman that I have too many typenames in there, but
>>>>   other than this trivial fix the patch works perfectly on GCC.
>>>
>>> It was literally a case of removing some unnecessary typename 
>>> keywords. It didn't take two seconds and at that time I didn't have 
>>> access to Linux. I do now.
>>>
>>> Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
>>
>> So these workarounds that are guarded by
>>
>>   #ifdef BOOST_MSVC
>>
>> Are known to be needed on vc7.1 as well as vc6?  What about vc8?
>> You ought to be using BOOST_WORKAROUND here.
>
> This really looks careless.  As submitted the patch doesn't compile
> because there's a missing
>
>   #include <boost/type_traits/broken_compiler_spec.hpp>
>
> in type_id.hpp

And even after I add that, it breaks compilation.

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



From dave at boost-consulting.com  Thu Jan 26 18:20:47 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 12:20:47 -0500
Subject: [C++-sig] Patch implementing void * support
References: <u8xt39by5.fsf@boost-consulting.com>
	<43D90266.31788.5CBAF075@s_sourceforge.nedprod.com>
Message-ID: <ubqxy9a8g.fsf@boost-consulting.com>

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

> On 26 Jan 2006 at 11:43, David Abrahams wrote:
>
>> > Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
>> 
>> So these workarounds that are guarded by
>> 
>>   #ifdef BOOST_MSVC
>> 
>> Are known to be needed on vc7.1 as well as vc6?  What about vc8?
>> You ought to be using BOOST_WORKAROUND here.
>
> I copied exactly the code at the end of opaque_pointer_converter.hpp. 
> It uses #ifdef BOOST_MSVC, so I reused exactly the same form in 
> type_id.hpp.

I didn't write that code; I probably should never have approved it in
that form.

> If opaque_pointer_converter.hpp should be different, then so should 
> type_id.hpp. 

Sure.

> I don't know whether it should be different for msvc7.1 -
>  whoever wrote opaque_pointer_converter.hpp is better suited to 
> answer that question.
>
> The only reason type_id.hpp needed a separate declaration is because
> GCC complained about adding template specialisations after they have
> been instanced. It's probably a good thing.

Hyah.

But give me a patch that works, please.

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



From s_sourceforge at nedprod.com  Thu Jan 26 20:01:00 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 26 Jan 2006 19:01:00 -0000
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <uy8129az7.fsf@boost-consulting.com>
Message-ID: <43D91C6C.19577.5D2098EE@s_sourceforge.nedprod.com>

On 26 Jan 2006 at 12:04, David Abrahams wrote:

> This really looks careless.  As submitted the patch doesn't compile
> because there's a missing
> 
>   #include <boost/type_traits/broken_compiler_spec.hpp>
> 
> in type_id.hpp

I tested the patch on windows and linux by compiling my python 
bindings. It would appear that the bindings include necessary header 
files such that everything compiles okay.

I'll get back to you hopefully tonight, otherwise in ten days or so.

Cheers,
Niall





From s_sourceforge at nedprod.com  Thu Jan 26 20:58:40 2006
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 26 Jan 2006 19:58:40 -0000
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <uslra9at7.fsf@boost-consulting.com>
Message-ID: <43D929F0.16840.5D55625C@s_sourceforge.nedprod.com>

On 26 Jan 2006 at 12:08, David Abrahams wrote:

> > This really looks careless.  As submitted the patch doesn't compile
> > because there's a missing
> >
> >   #include <boost/type_traits/broken_compiler_spec.hpp>
> >
> > in type_id.hpp
> 
> And even after I add that, it breaks compilation.

Found the reason that missing header file didn't get spotted was 
because I was using my own modified Boost.Python.

Having applied it to a clean v1.33 of Boost.Python the compile error 
shows. However after addition of that line above everything 
(libraries, test suite) links and compiles just fine on Windows. The 
test for voidptr passes. I attach a new unified diff which includes 
the testsuite and doc changes.

Can you clarify what you mean by "And even after I add that, it 
breaks compilation"? Are you using a v1.33 edition or a CVS edition? 
It's possible a CVS edition has changed something.

Cheers,
Niall



-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  voidptrpatch.diff
     Date:  26 Jan 2006, 19:56
     Size:  10128 bytes.
     Type:  Unknown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voidptrpatch.diff
Type: application/octet-stream
Size: 10128 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060126/b17af4ff/attachment.obj>

From dave at boost-consulting.com  Thu Jan 26 21:03:56 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 15:03:56 -0500
Subject: [C++-sig] Patch implementing void * support
References: <uslra9at7.fsf@boost-consulting.com>
	<43D929F0.16840.5D55625C@s_sourceforge.nedprod.com>
Message-ID: <ulkx27o43.fsf@boost-consulting.com>

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

> On 26 Jan 2006 at 12:08, David Abrahams wrote:
>
>> > This really looks careless.  As submitted the patch doesn't compile
>> > because there's a missing
>> >
>> >   #include <boost/type_traits/broken_compiler_spec.hpp>
>> >
>> > in type_id.hpp
>> 
>> And even after I add that, it breaks compilation.
>
> Found the reason that missing header file didn't get spotted was 
> because I was using my own modified Boost.Python.
>
> Having applied it to a clean v1.33 of Boost.Python the compile error 
> shows. However after addition of that line above everything 
> (libraries, test suite) links and compiles just fine on Windows. The 
> test for voidptr passes. I attach a new unified diff which includes 
> the testsuite and doc changes.
>
> Can you clarify what you mean by "And even after I add that, it 
> breaks compilation"? Are you using a v1.33 edition or a CVS edition? 
> It's possible a CVS edition has changed something.

Your patch must pass the Boost.Python test suite against the CVS in
order to be accepted.

Go to libs/python/test and do 

   bjam -sTOOLS="<whatever>" test

<whatever> might look like


       msvc vc-7_1 gcc

for example.

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



From dave at boost-consulting.com  Thu Jan 26 21:02:25 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 15:02:25 -0500
Subject: [C++-sig] Patch implementing void * support
References: <uy8129az7.fsf@boost-consulting.com>
	<43D91C6C.19577.5D2098EE@s_sourceforge.nedprod.com>
Message-ID: <ur76u7o6m.fsf@boost-consulting.com>

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

> On 26 Jan 2006 at 12:04, David Abrahams wrote:
>
>> This really looks careless.  As submitted the patch doesn't compile
>> because there's a missing
>> 
>>   #include <boost/type_traits/broken_compiler_spec.hpp>
>> 
>> in type_id.hpp
>
> I tested the patch on windows and linux by compiling my python 
> bindings. It would appear that the bindings include necessary header 
> files such that everything compiles okay.
>
> I'll get back to you hopefully tonight, otherwise in ten days or so.

A patch that works is defined as one that passes the Boost.Python test
suite.  Make sure you test your patch in that context on all platforms
you're targeting.


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



From seefeld at sympatico.ca  Thu Jan 26 21:48:37 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 26 Jan 2006 15:48:37 -0500
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <ur76u7o6m.fsf@boost-consulting.com>
References: <uy8129az7.fsf@boost-consulting.com>	<43D91C6C.19577.5D2098EE@s_sourceforge.nedprod.com>
	<ur76u7o6m.fsf@boost-consulting.com>
Message-ID: <43D935A5.8030407@sympatico.ca>

David Abrahams wrote:

> A patch that works is defined as one that passes the Boost.Python test
> suite.  Make sure you test your patch in that context on all platforms
> you're targeting.

How is that possible, in general ? Typically a single developer has access
only to a limitted number of platforms / compilers, requiring some form of
cooperation to cover all targetted platforms.

Regards,
		Stefan





From dave at boost-consulting.com  Fri Jan 27 02:15:50 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 26 Jan 2006 20:15:50 -0500
Subject: [C++-sig] Patch implementing void * support
References: <uy8129az7.fsf@boost-consulting.com>
	<43D91C6C.19577.5D2098EE@s_sourceforge.nedprod.com>
	<ur76u7o6m.fsf@boost-consulting.com> <43D935A5.8030407@sympatico.ca>
Message-ID: <uk6cm5v3t.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>> A patch that works is defined as one that passes the Boost.Python test
>> suite.  Make sure you test your patch in that context on all platforms
>> you're targeting.
>
> How is that possible, in general ? Typically a single developer has access
> only to a limitted number of platforms / compilers, requiring some form of
> cooperation to cover all targetted platforms.

A developer can't very well target a platform he has no access to, can
he?  It's up to Niall to say what he's targeting.  Of course, if the
patch is too far off of the set of compilers currently supported by
the library, it might not be accepted.

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



From seefeld at sympatico.ca  Fri Jan 27 04:34:50 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 26 Jan 2006 22:34:50 -0500
Subject: [C++-sig] Patch implementing void * support
In-Reply-To: <uk6cm5v3t.fsf@boost-consulting.com>
References: <uy8129az7.fsf@boost-consulting.com>	<43D91C6C.19577.5D2098EE@s_sourceforge.nedprod.com>	<ur76u7o6m.fsf@boost-consulting.com>
	<43D935A5.8030407@sympatico.ca>
	<uk6cm5v3t.fsf@boost-consulting.com>
Message-ID: <43D994DA.3040407@sympatico.ca>

David Abrahams wrote:
> Stefan Seefeld <seefeld at sympatico.ca> writes:
> 
> 
>>David Abrahams wrote:
>>
>>
>>>A patch that works is defined as one that passes the Boost.Python test
>>>suite.  Make sure you test your patch in that context on all platforms
>>>you're targeting.
>>
>>How is that possible, in general ? Typically a single developer has access
>>only to a limitted number of platforms / compilers, requiring some form of
>>cooperation to cover all targetted platforms.
> 
> 
> A developer can't very well target a platform he has no access to, can
> he?  It's up to Niall to say what he's targeting.  Of course, if the
> patch is too far off of the set of compilers currently supported by
> the library, it might not be accepted.

I was thinking of a patch to boost.python (say), which the author (of
the patch) only tests on a subset of platforms / compilers of the
platforms / compilers the library author(s) target.
I don't know the set of supported compilers for boost.python, but I'm
quite sure it is more than what I have access to. Yet I might be able
to submit a patch some time or another. What am I supposed to do then ?

Regards,
		Stefan


From Mathieu.Lacage at sophia.inria.fr  Fri Jan 27 08:52:07 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 27 Jan 2006 08:52:07 +0100
Subject: [C++-sig] optimizing away calls to the python runtime --
	was	[detecting if a function is written in python or C++]
In-Reply-To: <Pine.LNX.4.63.0601181223490.9529@brocoli.iro.umontreal.ca>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
	<1137487349.31678.85.camel@chronos>
	<87bqya7qnf.fsf@boost-consulting.com>
	<Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>
	<43CE1FEB.3090109@sophia.inria.fr>
	<Pine.LNX.4.63.0601181223490.9529@brocoli.iro.umontreal.ca>
Message-ID: <1138348327.28594.2.camel@chronos>

On Wed, 2006-01-18 at 15:09 -0500, Fran?ois Duranleau wrote:

> template < typename Function ,
>             typename Tag >
> struct function_wrapper_callback
>      : Callback1
> {
>      static Function func ;
> 
>      void operator () ( int a )
>      {
>          func( a ) ;
>      }
> } ;
> 
> template < typename Function ,
>             typename Tag >
> Function function_wrapper< Function , Tag >::func = Function() ;

you meant function_wrapper_callback here, I assume.

> 
> template < typename Tag ,
>             typename Function >
> void
> export_function_callback( Function f ,
>                            const char* name )
> {
>      typedef function_wrapper_callback< Function , Tab > callback_type ;
> 
>      // Ensures unicity of callback_type for f
>      assert( callback_type::func == Function() ) ;
> 
>      callback_type::func = f ;
> 
>      class_< callback_type ,
>              bases< Callback1 > ,
>              boost::noncopyable >( name ) ;
> }
> 
> 
> And in the module section, taking your example of function 
> 'real_function', you could export it like this:
> 
> // declare the tag ouside of BOOST_PYTHON_MODULE(...)
> struct real_function_tag ;
> 
> export_function_callback< real_function_tag >( & real_function ,
>                                                 "real_function_callback" );

Am I right in assuming that your "tag" is here to deal with multiple
functions having the same signature ?

Mathieu
-- 



From Mathieu.Lacage at sophia.inria.fr  Fri Jan 27 10:14:26 2006
From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 27 Jan 2006 10:14:26 +0100
Subject: [C++-sig] optimizing away calls to the python runtime --
	was	[detecting if a function is written in python or C++]
In-Reply-To: <Pine.LNX.4.63.0601181223490.9529@brocoli.iro.umontreal.ca>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
	<1137487349.31678.85.camel@chronos>
	<87bqya7qnf.fsf@boost-consulting.com>
	<Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>
	<43CE1FEB.3090109@sophia.inria.fr>
	<Pine.LNX.4.63.0601181223490.9529@brocoli.iro.umontreal.ca>
Message-ID: <1138353266.28594.7.camel@chronos>

On Wed, 2006-01-18 at 15:09 -0500, Fran?ois Duranleau wrote:

> You can do something similar with methods by adding a member 'self' in the 
> wrapper (pointer to the object), a constructor with the object to bind to 
> the method as an argument, and calling the method with ->. in operator(). 
> Actually, I think you could even have a single wrapper for both functions 
> and method using boost::function and boost::bind.


I ended up doing this:
template<typename TAG, typename R, typename T, typename T1>
struct CallbackGenerator {
        typedef R (T::*member_type) (T1);
        static std::auto_ptr<Callback<R (T1)> >
        make_callback (T *self){
                return std::auto_ptr<Callback<R (T1)> > (yans::make_callback (CallbackGenerator::m_member, self));
        }
        static member_type m_member;
};
template<typename TAG,typename R,typename T,typename T1>
R (T::* CallbackGenerator<TAG,R,T,T1>::m_member ) (T1);

template <typename TAG, typename R, typename T, typename T1>
void
export_method_as_callback (R (T::*member) (T1), char const *name)
{
        CallbackGenerator<TAG, R, T, T1>::m_member = member;
        def (name, &CallbackGenerator<TAG,R,T,T1>::make_callback);
        class_<Callback<R (T1)>, std::auto_ptr<Callback<R (T1)> >, boost::noncopyable> ("Callback", no_init);
}


with this:

        export_method_as_callback<struct foo> (&TrafficAnalyser::receive,
                                               "make_TrafficAnalyser_receive_callback");


and that:

void set_send_callback_cpp (PeriodicGenerator *self, std::auto_ptr<Callback<void (Packet *)> > *callback)
{
        self->set_send_callback (callback->get ());
        callback->release ();
}

and this results in this:
without the call to export_method_as_callback:
[mlacage at chronos yans-current]$ time -p ./bin/python/test-periodic-generator.py >/dev/null
real 12.96
user 12.81
sys 0.02

with the call:
[mlacage at chronos yans-current]$ time -p ./bin/python/test-periodic-generator.py >/dev/null
real 3.10
user 2.99
sys 0.01

which I think is very nice.

thanks again for your help,
Mathieu
-- 



From duranlef at iro.umontreal.ca  Fri Jan 27 18:24:03 2006
From: duranlef at iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Duranleau?=)
Date: Fri, 27 Jan 2006 12:24:03 -0500 (EST)
Subject: [C++-sig] optimizing away calls to the python runtime -- was
 [detecting if a function is written in python or C++]
In-Reply-To: <1138348327.28594.2.camel@chronos>
References: <1137074745.15517.102.camel@chronos>
	<87irsoon63.fsf@boost-consulting.com>
	<1137142913.15517.167.camel@chronos>
	<878xtkmdzv.fsf@boost-consulting.com>
	<1137161942.15517.204.camel@chronos>
	<87k6d3lx18.fsf@boost-consulting.com>
	<1137399887.31678.25.camel@chronos>
	<87wtgz8zvo.fsf@boost-consulting.com>
	<1137487349.31678.85.camel@chronos>
	<87bqya7qnf.fsf@boost-consulting.com>
	<Pine.LNX.4.63.0601171514420.28415@brocoli.iro.umontreal.ca>
	<43CE1FEB.3090109@sophia.inria.fr>
	<Pine.LNX.4.63.0601181223490.9529@brocoli.iro.umontreal.ca>
	<1138348327.28594.2.camel@chronos>
Message-ID: <Pine.LNX.4.63.0601271221580.31810@brocoli.iro.umontreal.ca>

On Fri, 27 Jan 2006, Mathieu Lacage wrote:

> > On Wed, 2006-01-18 at 15:09 -0500, Fran?ois Duranleau wrote:

> > template < typename Function ,
> >             typename Tag >
> > struct function_wrapper_callback
> >      : Callback1
> > {
> >      static Function func ;
> > 
> >      void operator () ( int a )
> >      {
> >          func( a ) ;
> >      }
> > } ;
> > 
> > template < typename Function ,
> >             typename Tag >
> > Function function_wrapper< Function , Tag >::func = Function() ;
>
> you meant function_wrapper_callback here, I assume.

Oops, yes, of course!

[...]
> > And in the module section, taking your example of function 
> > 'real_function', you could export it like this:
> > 
> > // declare the tag ouside of BOOST_PYTHON_MODULE(...)
> > struct real_function_tag ;
> > 
> > export_function_callback< real_function_tag >( & real_function ,
> >                                                "real_function_callback" );
> 
> Am I right in assuming that your "tag" is here to deal with multiple
> functions having the same signature ?

Right!

-- 
Fran?ois Duranleau
LIGUM, Universit? de Montr?al

"I can't do the subtraction. 16 minus 7. You borrow 10 from the tens
  column... and take away 7. And then add 6... When do you return the
  borrowed 10?"
                                                           - Jiyu Nanohanu,
            in _Jubei-Chan, The Ninja Girl, Secret of the Lovely Eye Patch_

From agorjia at yahoo.com  Sat Jan 28 04:40:13 2006
From: agorjia at yahoo.com (Gorj Gorjia)
Date: Fri, 27 Jan 2006 19:40:13 -0800 (PST)
Subject: [C++-sig] ..:: Don't loose to see ::..:: A Great address for you
	::..
Message-ID: <20060128034013.19999.qmail@web37108.mail.mud.yahoo.com>


 Free of Virus,Worm, Trojan and every infected
program.
 Hi to all. It's late for you if you loose this
chance. 
 get a free Acer TeravelMate Notebook 
 Make free Salary by Greenhors ticker bar 
 Visit this two Address for more Information 

 http://www.geocities.com/abreg5/ 
  http://www.geocities.com/softgoware/ 

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


From dave at boost-consulting.com  Sat Jan 28 05:37:40 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 27 Jan 2006 23:37:40 -0500
Subject: [C++-sig] Patch implementing void * support
References: <uy8129az7.fsf@boost-consulting.com>
	<43D91C6C.19577.5D2098EE@s_sourceforge.nedprod.com>
	<ur76u7o6m.fsf@boost-consulting.com> <43D935A5.8030407@sympatico.ca>
	<uk6cm5v3t.fsf@boost-consulting.com> <43D994DA.3040407@sympatico.ca>
Message-ID: <m2y811ge7f.fsf@coppi.local>

Stefan Seefeld <seefeld at sympatico.ca> writes:

>>>How is that possible, in general ? Typically a single developer has access
>>>only to a limitted number of platforms / compilers, requiring some form of
>>>cooperation to cover all targetted platforms.
>> 
>> 
>> A developer can't very well target a platform he has no access to, can
>> he?  It's up to Niall to say what he's targeting.  Of course, if the
>> patch is too far off of the set of compilers currently supported by
>> the library, it might not be accepted.
>
> I was thinking of a patch to boost.python (say), which the author (of
> the patch) only tests on a subset of platforms / compilers of the
> platforms / compilers the library author(s) target.
> I don't know the set of supported compilers for boost.python, but I'm
> quite sure it is more than what I have access to. Yet I might be able
> to submit a patch some time or another. What am I supposed to do then ?

Tell me what compilers and platforms you're targeting your patch at,
and test it on all those.  Re-read what I wrote.  I never said the
patch had to be tested on all platforms/compilers targeted by the
library.

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



From roman.yakovenko at gmail.com  Sun Jan 29 12:23:22 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 29 Jan 2006 13:23:22 +0200
Subject: [C++-sig] class registration order
Message-ID: <7465b6170601290323s3652e84sd5446f7424bde38a@mail.gmail.com>

Hi. It seems that I can not find answer to next question:
What is the required order of class registration?

If I understand right boost.python forces order of registration only
for classes that there is
base - derive relationship between them: base should be registered
before derived. In any other case the order is unimportant.

Am I right?

Thanks

Roman Yakovenko


From roman.yakovenko at gmail.com  Sun Jan 29 14:07:04 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 29 Jan 2006 15:07:04 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <dran86$t5p$1@sea.gmane.org>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
	<dr5hd9$usp$1@sea.gmane.org>
	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>
	<dr8no2$822$1@sea.gmane.org>
	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>
	<dran86$t5p$1@sea.gmane.org>
Message-ID: <7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>

On 1/26/06, Matthias Baas <baas at ira.uka.de> wrote:
> > There are 2 reasons:
> > 1. Filtering. You want to apply different filters on declarations
> > within projects.
>
> Right, so all it requires is a way to specify such a filter, for example:
>
> add_filter(by_location("mypath"))
>
> or
>
> filter_by_location("mypath")

What about custom filter, lets say by class name. For example Qt.Xml module
all public classes starts with QXML or QDom. Here you should to get down to
API.

> > 2. Performance reasons. With pygccxml you can save a lot of time on big projects
> >     by not compiling a source code with GCC-XML every time. On TnFOX project
> >     it saves more then 30 seconds on my computer
> >    ( Windows XP, Pentium 2.4, RAM 1.5G ).
>
> Pyste also has such a feature, so there is already an example that this
> can also be done the "Pyste way".

This is only one possible cache. pygccxml is able to cache declarations too.

> >> Step 1 of the tutorial consists of 12 lines of code where there are only
> >> two things that I really had to specify: the name of the input header
> >> file and a filtering rule (whereas gccxml is on my path, so I didn't
> >> need to specify that in the driver file.
> >
> > You need at least 1 more line import pyplusplus. :-)
>
> Actually, you don't! The config script can run in a prepared namespace
> that already contains everything that is needed. Again, Pyste can serve
> as an example where you also don't have to import anything to use the
> special Pyste commands and classes.

Lets put a side interface files. I will write article that will
explain why I do want to take
pyplusplus to "interface files".


> So far I see no reason why the simplistic interface of Pyste and the
> actual pyplusplus/pygccxml packages couldn't be combined. Actually, it
> would be great if pyplusplus had an interface that would contain the
> Pyste interface as a subset. This would be a big point for attracting
> people who were formerly using Pyste.

I will explain my point later. Also I did not find Pyste users at all.
Try to search using
Google.

> >> (well, maybe the main reason was that I couldn't get it to work with
> >> that SDK I'm currently wrapping).
> >
> > What were the problems? May be I can help you? Or may be you found some bug?
>
> After having another look at it, I noticed the problem. It was just that
> I still had the recursive option set to False when calling
> module_creator.create() and the class that I tried to wrap resides
> inside a namespace, so I take it pyplusplus only saw the namespace but
> didn't inspect the contents of it.
> Now I have an output file that contains some stuff, a lot of stuff
> indeed! Now the question is, how do I reduce this stuff? What filter do
> I have to use? Basically, for now I only want one single class that's
> inside that namespace. So how I can tell pyplusplus to only wrap that
> specific class?

take a look on http://tinyurl.com/9uhv4 or http://tinyurl.com/e44kh.
see filter_declarations method. This should help, if not please speak.

> Another thing I noticed, the header files included in the output file
> are specified with their *absolute* path (even standard header files).
> Is this intentional or is this a bug? I'd recommend to output the header
> names just as they were specified in the original files. Currently, this
> prevents me from taking the generated source files to another system and
>   compile them there.

May be there is some problem with standard header files. But pyplusplus is
flexible enough to allow you to specify additional include directories:

code_creators.module_t has 2 properties:

std_directories
user_defined_directories.

You can add your include directories to user_defined_directories list.

May be this could be done more simple, but if you are an scons user,
than you can maintan single file that will keep all environment variables,
additional include directories for example, in that file and reuse it
from pyplusplus
and scons scripts.

Give it a try an see what will happen.

> - Matthias -

Thanks for your feedbacks.

Roman Yakovenko


From dave at boost-consulting.com  Sun Jan 29 16:09:45 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 29 Jan 2006 10:09:45 -0500
Subject: [C++-sig] class registration order
References: <7465b6170601290323s3652e84sd5446f7424bde38a@mail.gmail.com>
Message-ID: <8764o3gjeu.fsf@boost-consulting.com>

Roman Yakovenko <roman.yakovenko at gmail.com> writes:

> Hi. It seems that I can not find answer to next question:
> What is the required order of class registration?
>
> If I understand right boost.python forces order of registration only
> for classes that there is
> base - derive relationship between them: base should be registered
> before derived. In any other case the order is unimportant.
>
> Am I right?

Correct.


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



From baas at ira.uka.de  Mon Jan 30 16:04:36 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Mon, 30 Jan 2006 16:04:36 +0100
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>	<dr5hd9$usp$1@sea.gmane.org>	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>	<dr8no2$822$1@sea.gmane.org>	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>	<dran86$t5p$1@sea.gmane.org>
	<7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>
Message-ID: <drl9ta$q2f$1@sea.gmane.org>

Roman Yakovenko wrote:
>> Now I have an output file that contains some stuff, a lot of stuff
>> indeed! Now the question is, how do I reduce this stuff? What filter do
>> I have to use? Basically, for now I only want one single class that's
>> inside that namespace. So how I can tell pyplusplus to only wrap that
>> specific class?
> 
> take a look on http://tinyurl.com/9uhv4 or http://tinyurl.com/e44kh.
> see filter_declarations method. This should help, if not please speak.

ok. I'm using a custom filter function now that rejects everything 
except my desired class. The test is based on decl.name (by the way, a 
reference manual where the attributes and methods of those declaration 
objects are documented would come in rather handy at this point ;)
So far so good...

>> Another thing I noticed, the header files included in the output file
>> are specified with their *absolute* path (even standard header files).
>> Is this intentional or is this a bug? I'd recommend to output the header
>> names just as they were specified in the original files. Currently, this
>> prevents me from taking the generated source files to another system and
>>   compile them there.
> 
> May be there is some problem with standard header files. But pyplusplus is
> flexible enough to allow you to specify additional include directories:
> 
> code_creators.module_t has 2 properties:
> 
> std_directories
> user_defined_directories.
> 
> You can add your include directories to user_defined_directories list.

Right, after adding the paths to 'user_defined_directories' the #include 
statements look good.
(It's a bit unfortunate that I have to pass the path information twice 
in my script (once for parser_config and once for the above attribute). 
It would be nice if the information could be reused.)

I extended my test and already added more than one class and tried the 
write_multiple_files() function. Basically, it works fine, but one 
problem still remains: The output files will only compile if I include 
some additional header files (which actually depend on the class I'm 
wrapping). So how do I tell pyplusplus to add those headers to the 
output files? (in Pyste I was using the declaration_code() function)

- Matthias -



From roman.yakovenko at gmail.com  Mon Jan 30 17:08:45 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 30 Jan 2006 18:08:45 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <drl9ta$q2f$1@sea.gmane.org>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>
	<dr5hd9$usp$1@sea.gmane.org>
	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>
	<dr8no2$822$1@sea.gmane.org>
	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>
	<dran86$t5p$1@sea.gmane.org>
	<7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>
	<drl9ta$q2f$1@sea.gmane.org>
Message-ID: <7465b6170601300808o7c99bd6cgf936f22fb40ed6b6@mail.gmail.com>

On 1/30/06, Matthias Baas <baas at ira.uka.de> wrote:
> Right, after adding the paths to 'user_defined_directories' the #include
> statements look good.
> (It's a bit unfortunate that I have to pass the path information twice
> in my script (once for parser_config and once for the above attribute).
> It would be nice if the information could be reused.)
>
> I extended my test and already added more than one class and tried the
> write_multiple_files() function. Basically, it works fine, but one
> problem still remains: The output files will only compile if I include
> some additional header files (which actually depend on the class I'm
> wrapping). So how do I tell pyplusplus to add those headers to the
> output files? (in Pyste I was using the declaration_code() function)

Every code block that is written in file, is created  by some code creator.

There are 2 relevant code creators:
   1. include_t
   2. precompiled_header_t

__init__ method takes file path/name to be included.

module_t class has method adopt_include. As argument it takes
include_t instance.
If you need to insert it in some specific position, use adopt_creator(
creator, index )
method of module_t class.

> - Matthias -
>

Roman Yakovenko


From duranlef at iro.umontreal.ca  Mon Jan 30 17:24:46 2006
From: duranlef at iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois_Duranleau?=)
Date: Mon, 30 Jan 2006 11:24:46 -0500 (EST)
Subject: [C++-sig] Convert Python tuple to boost::tuple? (was Re: easy
 method for converting boost::tuple to python tuple?)
In-Reply-To: <uvewak97m.fsf@boost-consulting.com>
References: <20060123180506.GS2939@bmb24.uth.tmc.edu>
	<uvewak97m.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.63.0601301057440.11405@frontal02.iro.umontreal.ca>

On Mon, 23 Jan 2006, David Abrahams wrote:

> http://www.boost.org/libs/python/doc/v2/to_python_converter.html
>
> should set you on the right path.
>
>  // Untested!
>  #include <boost/python/tuple.hpp>
>  #include <boost/python/module.hpp>
>  #include <boost/python/refcount.hpp>
>
>
>  namespace python = boost::python;
>  namespace tuples = boost::tuples;
>
>  namespace my
>  {
>    template <class H, class T>
>    python::tuple tuple_to_python(tuples::cons<H,T> const& x)
>    {
>        return python::make_tuple(x) + my::tuple_to_python(x.tail);
>    }
                                   ^^^

I guess it should rather be:

          return python::make_tuple(x.head) + my::tuple_to_python(x.tail);
                                    ^^^^^^

>    python::tuple tuple_to_python(tuples::null_type)
>    {
>        return python::tuple();
>    }
>
>    template <class T>
>    struct tupleconverter
>    {
>        static PyObject* convert(T const& x)
>        {
>            return python::incref(my::tuple_to_python(x).ptr());
>        }
>    };
>  }
>
>  BOOST_PYTHON_MODULE(whatever)
>  {
>      to_python_converter<my_tuple_type, tupleconverter<my_tuple_type> >();
>  }
>
> Something like this really should be in the library already, though,
> shouldn't it?

It would certainly be very helpful.

But how about doing the opposite? That is, how to easily convert a Python 
tuple to a boost::tuple automatically?

I have a couple of functions with a boost::tuple as an argument (and 
others returning a tuple), and of course, I would prefer to use python 
tuples in python. The code above helps the case of return values, but what 
about function arguments? I could do something like this (not tested as 
well):

namespace py = boost::python ;

// function to export
void func( const boost::tuple< int , int >& t )
{
     // ...
}

void wrapped_func( py::tuple t )
{
     func( boost::make_tuple( py::extract< int >( t[ 0 ] )() ,
                              py::extract< int >( t[ 1 ] )() ) ) ;
}

BOOST_PYTHON_MODULE( test )
{
     py::def( "func" , & wrapped_func ) ;
}

But it is somewhat inconvenient to write wrappers like this for every such 
function. Could we do something with boost::python::lvalue_from_pytype?

-- 
Fran?ois Duranleau
LIGUM, Universit? de Montr?al

"There, now you have a top and a bottom! But you've lost a degree of your
  freedom. Now you must stand on the ground. But now you feel easier, don't
  you? You have less to trouble your mind."
                                           - from _Neon Genesis Evangelion_

From baas at ira.uka.de  Mon Jan 30 19:24:00 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Mon, 30 Jan 2006 19:24:00 +0100
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601300808o7c99bd6cgf936f22fb40ed6b6@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>	<7465b6170601232256u682f7980h751f8864dc7b58ab@mail.gmail.com>	<dr5hd9$usp$1@sea.gmane.org>	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>	<dr8no2$822$1@sea.gmane.org>	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>	<dran86$t5p$1@sea.gmane.org>	<7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>	<drl9ta$q2f$1@sea.gmane.org>
	<7465b6170601300808o7c99bd6cgf936f22fb40ed6b6@mail.gmail.com>
Message-ID: <drllj5$g9u$1@sea.gmane.org>

Roman Yakovenko wrote:
>> I extended my test and already added more than one class and tried the
>> write_multiple_files() function. Basically, it works fine, but one
>> problem still remains: The output files will only compile if I include
>> some additional header files (which actually depend on the class I'm
>> wrapping). So how do I tell pyplusplus to add those headers to the
>> output files? (in Pyste I was using the declaration_code() function)
> 
> Every code block that is written in file, is created  by some code creator.
> 
> There are 2 relevant code creators:
>    1. include_t
>    2. precompiled_header_t
> 
> __init__ method takes file path/name to be included.
> 
> module_t class has method adopt_include. As argument it takes
> include_t instance.

ok, for every header I have a line:

extmodule.adopt_include( code_creators.include_t("myheader.h") )

The module compiles now. However, the above include files are inserted 
into every generated *.cpp file. I don't know if this will ever be a 
problem or not, but while I'm at it, how could I be more specific and 
add headers (or other code) to only some selected output files?

Anyway, I'll continue my test and move on to the more complex classes 
that needed some manual intervention using Pyste....

- Matthias -



From dave at boost-consulting.com  Tue Jan 31 04:28:06 2006
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 30 Jan 2006 22:28:06 -0500
Subject: [C++-sig] Convert Python tuple to boost::tuple? (was Re: easy
	method for converting boost::tuple to python tuple?)
References: <20060123180506.GS2939@bmb24.uth.tmc.edu>
	<uvewak97m.fsf@boost-consulting.com>
	<Pine.LNX.4.63.0601301057440.11405@frontal02.iro.umontreal.ca>
Message-ID: <87slr59iux.fsf@boost-consulting.com>

Fran?ois Duranleau <duranlef at iro.umontreal.ca> writes:

> On Mon, 23 Jan 2006, David Abrahams wrote:
>
>>    template <class H, class T>
>>    python::tuple tuple_to_python(tuples::cons<H,T> const& x)
>>    {
>>        return python::make_tuple(x) + my::tuple_to_python(x.tail);
>>    }
>                                   ^^^
>
> I guess it should rather be:
>
>          return python::make_tuple(x.head) + my::tuple_to_python(x.tail);
>                                    ^^^^^^

Yes.


>> Something like this really should be in the library already, though,
>> shouldn't it?
>
> It would certainly be very helpful.
>
> But how about doing the opposite? That is, how to easily convert a
> Python tuple to a boost::tuple automatically?
>

Yep, it's all possible.  Probably not for 1.34, though.  We have about
a week during which all new features must be finalized.  In the
meantime, I put it on the TODO list.

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



From roman.yakovenko at gmail.com  Tue Jan 31 06:32:38 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 31 Jan 2006 07:32:38 +0200
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <drllj5$g9u$1@sea.gmane.org>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>
	<dr5hd9$usp$1@sea.gmane.org>
	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>
	<dr8no2$822$1@sea.gmane.org>
	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>
	<dran86$t5p$1@sea.gmane.org>
	<7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>
	<drl9ta$q2f$1@sea.gmane.org>
	<7465b6170601300808o7c99bd6cgf936f22fb40ed6b6@mail.gmail.com>
	<drllj5$g9u$1@sea.gmane.org>
Message-ID: <7465b6170601302132o26dbdaa6x6c6e412764ac2509@mail.gmail.com>

On 1/30/06, Matthias Baas <baas at ira.uka.de> wrote:
> Roman Yakovenko wrote:
> >> I extended my test and already added more than one class and tried the
> >> write_multiple_files() function. Basically, it works fine, but one
> >> problem still remains: The output files will only compile if I include
> >> some additional header files (which actually depend on the class I'm
> >> wrapping). So how do I tell pyplusplus to add those headers to the
> >> output files? (in Pyste I was using the declaration_code() function)
> >
> > Every code block that is written in file, is created  by some code creator.
> >
> > There are 2 relevant code creators:
> >    1. include_t
> >    2. precompiled_header_t
> >
> > __init__ method takes file path/name to be included.
> >
> > module_t class has method adopt_include. As argument it takes
> > include_t instance.

I think my previous answer was not complete. pyplusplus has 2 custom
code creators:
custom_t and custom_text_t. If you need to write some text, any text,
anywhere you
can create instances of those code creators and put them in a right
place within extension
module code creators tree.

> ok, for every header I have a line:
>
> extmodule.adopt_include( code_creators.include_t("myheader.h") )
>
> The module compiles now. However, the above include files are inserted
> into every generated *.cpp file. I don't know if this will ever be a
> problem or not, but while I'm at it, how could I be more specific and
> add headers (or other code) to only some selected output files?

Right now there is no easy way to do it. I don't understand why it could be
a problem in future. I am sure I miss something.
This method works fine for boost.date_time and TnFOX.
Any way, when you need it, you need it. There is a way to do what you want.
file_writers package contains class multiple_files_t. This class is responsible
for writing\splitting extension module to multiple files. If you need
fine grained
control you can always derive from this class and implement your
custom behaviour.

Please, check whether you work with latest CVS version or not. Few
days ago TnFOX
has problem that main function was too big. This class has been improved a lot.
It better splits extension modules to files and has mush clear implementation.

> Anyway, I'll continue my test and move on to the more complex classes
> that needed some manual intervention using Pyste....

Thanks for trying. I hope you will publish your experience and may be
source code.
I could learn a lot from seeing how you use pyplusplus


> - Matthias -

Roman Yakovenko


From baas at ira.uka.de  Tue Jan 31 14:55:46 2006
From: baas at ira.uka.de (Matthias Baas)
Date: Tue, 31 Jan 2006 14:55:46 +0100
Subject: [C++-sig] pyplusplus tutorials & GUI wizard
In-Reply-To: <7465b6170601302132o26dbdaa6x6c6e412764ac2509@mail.gmail.com>
References: <7465b6170601232249u7ca7741ncf71a6973fc12c45@mail.gmail.com>	<dr5hd9$usp$1@sea.gmane.org>	<7465b6170601242200w43b57343i26f75164ef88efe9@mail.gmail.com>	<dr8no2$822$1@sea.gmane.org>	<7465b6170601252149i3c597589t15d686f027567ab8@mail.gmail.com>	<dran86$t5p$1@sea.gmane.org>	<7465b6170601290507m3c2cc0edied458d60932dfa04@mail.gmail.com>	<drl9ta$q2f$1@sea.gmane.org>	<7465b6170601300808o7c99bd6cgf936f22fb40ed6b6@mail.gmail.com>	<drllj5$g9u$1@sea.gmane.org>
	<7465b6170601302132o26dbdaa6x6c6e412764ac2509@mail.gmail.com>
Message-ID: <drnq88$d5a$1@sea.gmane.org>

Roman Yakovenko wrote:
> I think my previous answer was not complete. pyplusplus has 2 custom
> code creators:
> custom_t and custom_text_t. If you need to write some text, any text,
> anywhere you
> can create instances of those code creators and put them in a right
> place within extension module code creators tree.

ok, I'll keep that in mind and will get back to you when I actually need 
it...

>> The module compiles now. However, the above include files are inserted
>> into every generated *.cpp file. I don't know if this will ever be a
>> problem or not, but while I'm at it, how could I be more specific and
>> add headers (or other code) to only some selected output files?
> 
> Right now there is no easy way to do it. I don't understand why it could be
> a problem in future. I am sure I miss something.
> This method works fine for boost.date_time and TnFOX.

So far I'm fine with it, the question was merely "prophylactic"... ;)

> Please, check whether you work with latest CVS version or not. [...]

Yes, I have checked out the latest version from cvs...

>> Anyway, I'll continue my test and move on to the more complex classes
>> that needed some manual intervention using Pyste....

The next class I've added to the module has two methods that require a 
call policy. The methods just return a reference to its instance, so I 
want to specify the 'return_self' policy. How do I do that? (I've had a 
short glimpse at those examples you mentioned two mails ago, but didn't 
really spot a place where a policy was assigned)

Then there's another class that has a private destructor. This class 
only has static methods and is not meant to be instantiated. So for the 
wrappers I'd like to add the 'noncopyable' and 'no_init' specifiers. 
Does pyplusplus allow that?

Now I also noticed another thing that'll get more serious the more 
classes I wrap. Whenever I create the source code for the bindings 
(using the multiple_files feature) *all* files are recreated, even when 
the actual contents is the same than before. When I then compile the 
module (using distutils) *every* file is recompiled which will take 
quite some time once I've wrapped the entire SDK (which has about 300 
classes). Is there a way to tell pyplusplus to only generate a source 
file when the contents will be different from a previous run?

- Matthias -



From john at arbash-meinel.com  Tue Jan 31 17:22:37 2006
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 31 Jan 2006 10:22:37 -0600
Subject: [C++-sig] dumb policy question
In-Reply-To: <20060118231336.GD2939@bmb24.uth.tmc.edu>
References: <20060118212507.GC2939@bmb24.uth.tmc.edu>
	<20060118231336.GD2939@bmb24.uth.tmc.edu>
Message-ID: <43DF8ECD.4030002@arbash-meinel.com>

Grant Goodyear wrote:
> Okay, so I read through the FAQ again and see "How can I wrap
> functions which take C++ containers as arguments", from which I 
> gather that the answer is "it's really darn hard, and probably 
> not worth the effort", if I understand it correctly.
> 
> Hmmm.
> -Grant-

I usually export std::vector<int> into python. With something like this:

scope outer = class_<Vec, boost::noncopyable>("Vec", no_init);
class_< std::vector<signed char> >("i8")
  .def(vector_indexing_suite< std::vector<signed char> >())
;
class_< std::vector<unsigned char> >("ui8")
  .def(vector_indexing_suite< std::vector<unsigned char> >())
;

...

Then the vectors I care about are available as:

import libpyref
v = libpyref.Vec.i32()
v.append(0)
v.append(0)
v.append(0)

libpyref.ref(v, 2)

I don't know if that helps you or not, but it is how I solved the problem.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060131/13950831/attachment.pgp>