From s_sourceforge at nedprod.com  Wed Jun  1 16:32:06 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 01 Jun 2005 15:32:06 +0100
Subject: [C++-sig] Pyste's AllFromHeader()
Message-ID: <429DD4F6.22635.894F478@localhost>

How's that function looking now in pyste? It is fully working yet? I 
was strongly thinking of finishing off TnFOX's python bindings and 
for that we'll need AllFromHeader() working, or at least 98% working.

Cheers,
Niall





From nicodemus at esss.com.br  Wed Jun  1 17:08:49 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Wed, 01 Jun 2005 12:08:49 -0300
Subject: [C++-sig] Pyste's AllFromHeader()
In-Reply-To: <429DD4F6.22635.894F478@localhost>
References: <429DD4F6.22635.894F478@localhost>
Message-ID: <429DCF81.2090408@esss.com.br>

Hi Niall,

It does work in most cases, but it has some problems regarding finding 
the correct relationship between classes and subclasses
when AllFromHeader is used. The fix for this is complicated, because of 
the --multiple support and the ability of spreading the bindings over 
several source files, so I have no plans to fix this in the near future, 
sorry. :(


Regards,
Bruno.


Niall Douglas wrote:

>How's that function looking now in pyste? It is fully working yet? I 
>was strongly thinking of finishing off TnFOX's python bindings and 
>for that we'll need AllFromHeader() working, or at least 98% working.
>
>Cheers,
>Niall
>
>
>
>_______________________________________________
>C++-sig mailing list
>C++-sig at python.org
>http://mail.python.org/mailman/listinfo/c++-sig
>
>  
>


From skottmckay at gmail.com  Thu Jun  2 03:04:17 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Wed, 1 Jun 2005 19:04:17 -0600
Subject: [C++-sig] custom smart pointer, vector_indexing_suite typeerror
Message-ID: <51d01787050601180429bc001e@mail.gmail.com>

Is the following possible or am I doing something wrongly?

I have a custom smart pointer, and an abstract base class that is
wrapped specifying smart_ptr<X> as the HeldType, as I want to treat
the object as if it's automatically wrapped with a smart_ptr.

I then have a std::vector<smart_ptr<X>> exposed using the
vector_indexing_suite with proxying turned off.

Basically something along these lines...

struct X_Wrapper: X
{
    X_Wrapper(PyObject* py_self_):
        X(), py_self(py_self_) {}

    X& run() {
        return call_method< X& >(py_self, "run");
    }
}

class_< X, X_Wrapper, boost::noncopyable, smart_ptr< X > >("X", init<>())
    .def("run", pure_virtual(&X::run), return_self<>()) 
;
 
class_< std::vector< smart_ptr<X> > > ( "vector_X" )
        .def( vector_indexing_suite< std::vector< smart_ptr<X> >, true >() )
;
 
Then in the python code I want to implement the X interface and add
the python object that does so to the vector.

class testX( X ):

    def run( self ):

        print "run"
        return self


tester = testX()
vector = vector_X()
vector.append( tester )

Doing so leads to a type error in the append (from the base_append of
the vector_indexing_suite). The object type is a 'testX', which I
thought would be held as a smart_ptr<X> under the covers and hence
would be convertible, but I guess that isn't the case.

As the vector takes a non-const I thought it was necessary to use the
HeldType rather than register_ptr_to_python.

Is there a way to make this work? I'm not sure I have everything setup
correctly though, so perhaps I'm missing a piece.

Thanks for any help.

Scott


From skottmckay at gmail.com  Thu Jun  2 04:28:34 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Wed, 1 Jun 2005 20:28:34 -0600
Subject: [C++-sig] custom smart pointer, vector_indexing_suite typeerror
In-Reply-To: <51d01787050601180429bc001e@mail.gmail.com>
References: <51d01787050601180429bc001e@mail.gmail.com>
Message-ID: <51d017870506011928538aecc3@mail.gmail.com>

After some experimentation/review I think this

> class_< X, X_Wrapper, boost::noncopyable, smart_ptr< X > >("X", init<>())
>     .def("run", pure_virtual(&X::run), return_self<>())
> ;

should be

class_<X,boost::noncopyable,smart_ptr<X_wrapper> >("X", init<>())
...

However doing so still results in a TypeError.

Now if I make it a vector of boost::shared_ptr<X>'s, I can append a
testX to it, so I'm thinking it may be due to the 'smart' pointer
class not being able to handle the conversion between X_Wrapper and X.

Could that be the case?

Thanks

S


From aashish at iastate.edu  Thu Jun  2 07:13:00 2005
From: aashish at iastate.edu (aashish at iastate.edu)
Date: Thu, 2 Jun 2005 00:13:00 -0500 (CDT)
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
 2.3and boost-1.31.0
Message-ID: <2978.68.108.219.106.1117689180.squirrel@mail.eng.iastate.edu>


Hi,

I am using one of the library which uses Boost. When I was trying to compile
boost on my linux (fedora core 3) machine I was getting warnings about
POSIX_C_SOURCE redefinition.

I found this post

http://lists.boost.org/MailArchives/boost/msg61875.php

and I believe that I need to check  out cvs version but not exactly sure
which branch I have to check out (for verison 1.31.0). I have to use boost
1.31.0 to make this library work (an older version).

My system is:

Fedora core 3
python 2.3.5
boost 1.31.0

Thanks for your help.

~Regards,
Ashish

-----------------------------------------------
Aashish Chaudhary
Technical Programmer, PRISM
Email: ashish_cy at yahoo.com
Ph: (480) 275-0755
-----------------------------------------------


From dave at boost-consulting.com  Thu Jun  2 18:10:17 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 02 Jun 2005 12:10:17 -0400
Subject: [C++-sig] custom smart pointer, vector_indexing_suite typeerror
References: <51d01787050601180429bc001e@mail.gmail.com>
Message-ID: <uhdggspsm.fsf@boost-consulting.com>

Scott McKay <skottmckay at gmail.com> writes:

> Is the following possible or am I doing something wrongly?
>
> I have a custom smart pointer, and an abstract base class that is
> wrapped specifying smart_ptr<X> as the HeldType, as I want to treat
> the object as if it's automatically wrapped with a smart_ptr.
>
> I then have a std::vector<smart_ptr<X>> exposed using the
> vector_indexing_suite with proxying turned off.
>
> Basically something along these lines...
>
> struct X_Wrapper: X
> {
>     X_Wrapper(PyObject* py_self_):
>         X(), py_self(py_self_) {}
>
>     X& run() {
>         return call_method< X& >(py_self, "run");
>     }
> }

You should use the new-style polymorphism support
(http://www.boost.org/libs/python/doc/v2/wrapper.html) although this
probably has nothing to do with your problem.

> class_< X, X_Wrapper, boost::noncopyable, smart_ptr< X > >("X", init<>())
>     .def("run", pure_virtual(&X::run), return_self<>()) 
> ;
>  
> class_< std::vector< smart_ptr<X> > > ( "vector_X" )
>         .def( vector_indexing_suite< std::vector< smart_ptr<X> >, true >() )
> ;
>  
> Then in the python code I want to implement the X interface and add
> the python object that does so to the vector.
>
> class testX( X ):
>
>     def run( self ):
>
>         print "run"
>         return self
>
>
> tester = testX()
> vector = vector_X()
> vector.append( tester )
>
> Doing so leads to a type error in the append (from the base_append of
> the vector_indexing_suite). The object type is a 'testX', which I
> thought would be held as a smart_ptr<X> under the covers and hence
> would be convertible, but I guess that isn't the case.

The problem is that you're missing an __init__ function in testX.
Calling the __init__ function of the base class inside it
(i.e. X.__init__(self)) is what causes the held smart_ptr<X> to be
created.

> As the vector takes a non-const I thought it was necessary to use the
> HeldType rather than register_ptr_to_python.

I'm not sure they're related.

> Is there a way to make this work? I'm not sure I have everything setup
> correctly though, so perhaps I'm missing a piece.

I think the __init__ function will do it for you.

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



From nico_ml at mgdesign.org  Thu Jun  2 18:24:09 2005
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Thu, 2 Jun 2005 18:24:09 +0200
Subject: [C++-sig] exporting __stdcall methods
References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com><422DCDCD.8090803@paniq.org>
	<42334D12.2020608@paniq.org><005101c52759$ee9cc030$37ce4e51@MIKESPC01>
	<42337D6E.2010505@paniq.org><ud5u41l6n.fsf@boost-consulting.com><024f01c52a4b$5caa5df0$0dc66b51@fuji>
	<uwts672h4.fsf@boost-consulting.com>
Message-ID: <110901c5678f$814a1f70$de00a8c0@nico>

Hi !

as I have some time ahead, I upgraded my codebase to latest boost snapshot. 
I was quite surprised to see that, by default, BPL still can't export 
__stdcall & __fastcall functions, or, at least, I could not find anything 
that allows that !...

I thought that it may be useful to send my patch to deal with these calling 
conventions...

I improved somewhat the patch I used before to handle the situation a little 
bit like type_traits lib does, by adding two defines that should sit in BPL 
config.hpp : BOOST_PYTHON_ENABLE_STDCALL and BOOST_PYTHON_ENABLE_FASTCALL.

I did not go on tweaking or adding a specific test, as I first wanted to 
have some feedback about the usefulness of such a patch and about the 
quality of the one I'm proposing.

Any thoughts ?
Regards,

Nicolas.

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: "John Maddock" <john at johnmaddock.co.uk>
Cc: "pysig" <c++-sig at python.org>
Sent: Thursday, March 17, 2005 4:48 PM
Subject: [C++-sig] Re: exporting __stdcall methods


> "John Maddock" <john at johnmaddock.co.uk> writes:
>
>>> Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp
>>> which are outside the Boost.Python library would need to be enhanced
>>> to deal with __stdcall, etc.
>>
>> Should now be fixed in cvs: provided the changes don't break anything 
>> else
>> of course!
>
> Fantastic!  Thanks, John!
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stdcall_and_fastcall_patch.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050602/c1c93245/attachment.txt>

From dave at boost-consulting.com  Thu Jun  2 18:12:29 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 02 Jun 2005 12:12:29 -0400
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
	2.3and boost-1.31.0
References: <2978.68.108.219.106.1117689180.squirrel@mail.eng.iastate.edu>
Message-ID: <ubr6ospoy.fsf@boost-consulting.com>

aashish at iastate.edu writes:

> Hi,
>
> I am using one of the library which uses Boost. When I was trying to compile
> boost on my linux (fedora core 3) machine I was getting warnings about
> POSIX_C_SOURCE redefinition.
>
> I found this post
>
> http://lists.boost.org/MailArchives/boost/msg61875.php
>
> and I believe that I need to check  out cvs version but not exactly sure
> which branch I have to check out (for verison 1.31.0). 

If you want version 1.31.0, get Revision_1_31_0.

I don't know what relevance that has to your problem, though.

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



From skottmckay at gmail.com  Thu Jun  2 18:37:22 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Thu, 2 Jun 2005 10:37:22 -0600
Subject: [C++-sig] custom smart pointer, vector_indexing_suite typeerror
In-Reply-To: <uhdggspsm.fsf@boost-consulting.com>
References: <51d01787050601180429bc001e@mail.gmail.com>
	<uhdggspsm.fsf@boost-consulting.com>
Message-ID: <51d0178705060209375bc52494@mail.gmail.com>

> You should use the new-style polymorphism support
> (http://www.boost.org/libs/python/doc/v2/wrapper.html) although this
> probably has nothing to do with your problem.

I'll check it out. Thanks
 
> The problem is that you're missing an __init__ function in testX.
> Calling the __init__ function of the base class inside it
> (i.e. X.__init__(self)) is what causes the held smart_ptr<X> to be
> created.

Ahh. Didn't realize the __init__ was required to trigger that. I did
have it 'working' without the init after I added an
implicitly_convertible< < smart_ptr<X_Wrapper>, smart_ptr<X> >(). It
would append but I hadn't verified that all the reference counting was
working as expected.

I will add the __init__ as well.

Many thanks for your help.

Scott


From aashish at iastate.edu  Thu Jun  2 19:16:00 2005
From: aashish at iastate.edu (aashish at iastate.edu)
Date: Thu, 2 Jun 2005 12:16:00 -0500 (CDT)
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
 2.3and boost-1.31.0
Message-ID: <57302.149.169.227.180.1117732560.squirrel@mail.eng.iastate.edu>

Thanks Dave.

Here is what I am getting on my console when I am trying to compile Boost.

On googling I found that I am getting this warning because, of the
importance of include order for Python header files.

Should I ignore these warnings? or what I can do to get rid of these
warnings ?

Also due to unfamiliarity with CVS , I have to ask this rather stupid
question. When you say Revision_1_31_0 does it mean it is a tag or branch
in CVS ? I believe in Boost RC_n_n_n stands for release version and there
is a separate tag Version_n_n_n.

Thanks in advance.

~Ashish



/usr/local/include/python2.3/pyconfig.h:856:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from /usr/include/limits.h:26,
                 from
/usr/lib/gcc/i386-redhat-linux/3.4.3/include/limits.h:122,
                 from
/usr/lib/gcc/i386-redhat-linux/3.4.3/include/syslimits.h:7,
                 from
/usr/lib/gcc/i386-redhat-linux/3.4.3/include/limits.h:11,
                 from
/home/software/vrjuggler/cvs_version/VRJ_2_0_ALPHA_4_BRANCH/juggler_deps/source/boost/boost/python/detail/wrap_python.hpp:27,
                 from
/home/software/vrjuggler/cvs_version/VRJ_2_0_ALPHA_4_BRANCH/juggler_deps/source/boost/boost/python/detail/prefix.hpp:13,
                 from
/home/software/vrjuggler/cvs_version/VRJ_2_0_ALPHA_4_BRANCH/juggler_deps/source/boost/boost/python/type_id.hpp:9,
                 from
/home/software/vrjuggler/cvs_version/VRJ_2_0_ALPHA_4_BRANCH/juggler_deps/source/boost/boost/python/converter/registry.hpp:8,
                 from
/home/software/vrjuggler/cvs_version/VRJ_2_0_ALPHA_4_BRANCH/juggler_deps/source/boost/libs/python/build/../src/converter/registry.cpp:6:
/usr/include/features.h:150:1: warning: this is the location of the
previous definition



From dave at boost-consulting.com  Thu Jun  2 19:49:59 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 02 Jun 2005 13:49:59 -0400
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
	2.3and boost-1.31.0
References: <57302.149.169.227.180.1117732560.squirrel@mail.eng.iastate.edu>
Message-ID: <uzmu8odh4.fsf@boost-consulting.com>

aashish at iastate.edu writes:

> Thanks Dave.
>
> Here is what I am getting on my console when I am trying to compile Boost.
>
> On googling I found that I am getting this warning because, of the
> importance of include order for Python header files.

Right.

> Should I ignore these warnings? 

Probably not.  This is a question for the Python developers really.

> or what I can do to get rid of these warnings ?

Boost 1.32.0 shouldn't give you the warnings.  
As for 1.31.0, the only thing I can suggest is that you steal
boost/python/detail/prefix.hpp, boost/python/detail/wrap_python.hpp,
and boost/python/detail/config.hpp from 1.32.0, and make sure you
start all of your source files with

#include <boost/python/detail/prefix.hpp>

> Also due to unfamiliarity with CVS , I have to ask this rather stupid
> question. When you say Revision_1_31_0 does it mean it is a tag or branch
> in CVS ? 

Branches are a special kind of tag; they're identified the same way.

> I believe in Boost RC_n_n_n stands for release version 

No, it stands for release candidate.

> and there is a separate tag Version_n_n_n.

That's the tag for the actual release.

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



From beyer at imb-jena.de  Thu Jun  2 20:11:34 2005
From: beyer at imb-jena.de (Andreas Beyer)
Date: Thu, 02 Jun 2005 11:11:34 -0700
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with
 python	2.3and boost-1.31.0
In-Reply-To: <uzmu8odh4.fsf@boost-consulting.com>
References: <57302.149.169.227.180.1117732560.squirrel@mail.eng.iastate.edu>
	<uzmu8odh4.fsf@boost-consulting.com>
Message-ID: <429F4BD6.2060209@imb-jena.de>

David Abrahams wrote:

>aashish at iastate.edu writes:
>
>  
>
>>Thanks Dave.
>>
>>Here is what I am getting on my console when I am trying to compile Boost.
>>
>>On googling I found that I am getting this warning because, of the
>>importance of include order for Python header files.
>>    
>>
>
>Right.
>
>  
>
>>Should I ignore these warnings? 
>>    
>>
>
>Probably not.  This is a question for the Python developers really.
>
>  
>
>>or what I can do to get rid of these warnings ?
>>    
>>
>
>Boost 1.32.0 shouldn't give you the warnings.  
>As for 1.31.0, the only thing I can suggest is that you steal
>boost/python/detail/prefix.hpp, boost/python/detail/wrap_python.hpp,
>and boost/python/detail/config.hpp from 1.32.0, and make sure you
>start all of your source files with
>
>#include <boost/python/detail/prefix.hpp>
>  
>
Here is another suggested work-around. It involves changing pyconfig.h:
http://mail.python.org/pipermail/c++-sig/2005-April/008776.html
Maybe it is easier to apply.
Are you sure you can't switch to Boost 1.32?

Andreas



From aashishvr2004 at yahoo.com  Thu Jun  2 20:22:20 2005
From: aashishvr2004 at yahoo.com (Ashish Chaudhary)
Date: Thu, 2 Jun 2005 11:22:20 -0700 (PDT)
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
	2.3and boost-1.31.0
In-Reply-To: <429F4BD6.2060209@imb-jena.de>
Message-ID: <20050602182220.20844.qmail@web30511.mail.mud.yahoo.com>

Thanks again Dave and Andreas. 

I am giving 1.32.0 a try and yes I didn't get those
warnings with this version. So now I am going to try
compiling other library (VRJuVRJugglersion 2.0 alpha4
)
with new boost version.

If it does not work I will try Dave's or your
suggestion.  

Also I think I created two threads on the same
subject. I am sorry about that as something went wrong
with my email. 

~Regards,
AshiAshish


--- Andreas Beyer <beyebeyer-imbajena deote:

> David AbraAbrahamste:
> 
> >aashaashishtiastate edutes:
> >
> >  
> >
> >>Thanks Dave.
> >>
> >>Here is what I am getting on my console when I am
> trying to compile Boost.
> >>
> >>On googgooglingound that I am getting this warning
> because, of the
> >>importance of include order for Python header
> files.
> >>    
> >>
> >
> >Right.
> >
> >  
> >
> >>Should I ignore these warnings? 
> >>    
> >>
> >
> >Probably not.  This is a question for the Python
> developers really.
> >
> >  
> >
> >>or what I can do to get rid of these warnings ?
> >>    
> >>
> >
> >Boost 1.32.0 shouldn't give you the warnings.  
> >As for 1.31.0, the only thing I can suggest is that
> you steal
> >boost/python/detail/prefix.hpp,hpp
boost/python/detail/wrap_python.hpp,hpp >and
boost/python/detail/confconfig hppm 1.32.0, and
> make sure you
> >start all of your source files with
> >
> >#include <boost/python/detail/prefix.hpp>hpp >  
> >
> Here is another suggested work-around. It involves
> changing pycopyconfig
>
httphttpail.python.org/pipepipermail-sig/sig5-April/008776.htmlhtmlMaybe
it is easier to apply.
> Are you sure you can't switch to Boost 1.32?
> 
> Andreas
> 
> _______________________________________________
> C++-sig sigling list
> C++-sig at sighon.org
> httphttpail.python.org/mailman/listlistinfo-sig
sig


		
__________________________________ 
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/


From nyamatongwe at gmail.com  Thu Jun  2 23:46:30 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Fri, 3 Jun 2005 07:46:30 +1000
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
	2.3and boost-1.31.0
In-Reply-To: <20050602182220.20844.qmail@web30511.mail.mud.yahoo.com>
References: <429F4BD6.2060209@imb-jena.de>
	<20050602182220.20844.qmail@web30511.mail.mud.yahoo.com>
Message-ID: <50862ebd050602144659db82c0@mail.gmail.com>

   These warnings went away for me when I moved 
#include <boost/python.hpp>
   to the top of each file rather than starting with system includes.

   Neil


From dave at boost-consulting.com  Fri Jun  3 13:56:59 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Jun 2005 07:56:59 -0400
Subject: [C++-sig] _POSIX_C_SOURCE redefinition warning with python
	2.3and boost-1.31.0
References: <429F4BD6.2060209@imb-jena.de>
	<20050602182220.20844.qmail@web30511.mail.mud.yahoo.com>
	<50862ebd050602144659db82c0@mail.gmail.com>
Message-ID: <u4qcflkl0.fsf@boost-consulting.com>

Neil Hodgson <nyamatongwe at gmail.com> writes:

>    These warnings went away for me when I moved 
> #include <boost/python.hpp>
>    to the top of each file rather than starting with system includes.

You always have to start with a Boost.Python #include if you are using
Boost.Python (because Python itself imposes that rule and we have to
wrap the Python.h header).  I assumed the OP was doing that already.

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



From apprentice_99 at hotmail.com  Sun Jun  5 10:59:19 2005
From: apprentice_99 at hotmail.com (Studious Apprentice)
Date: Sun, 05 Jun 2005 08:59:19 +0000
Subject: [C++-sig] Raw member and constructor functions
Message-ID: <BAY101-F170A351D712A9C29E386C093F80@phx.gbl>

Hello !

I would like to use raw member functions and a raw constructor. However I 
can only manage to have raw functions to work.

The following code works :

#include <boost/python.hpp>
#include <boost/python/raw_function.hpp>
using namespace boost::python;

tuple raw(tuple args, dict kw)
{
	return make_tuple(args, kw);
}

BOOST_PYTHON_MODULE(PythonTest)
{
	def("raw", raw_function(raw));
}

However this code does not compile with MSVC7.1 and results in "error C2064: 
term does not evaluate to a function taking 2 arguments" :

#include <boost/python.hpp>
#include <boost/python/raw_function.hpp>
using namespace boost::python;

class X {
public:
	object memberraw(tuple args, dict kw)
	{
		return object();
	}
};

BOOST_PYTHON_MODULE(PythonTest)
{
	class_<X>("X")
		.def("memberraw", raw_function(&X::memberraw))
		;
}

Anyone would have an idea of how to get this working ?

Thanks in advance,

Marc




From dave at boost-consulting.com  Mon Jun  6 04:30:52 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Jun 2005 22:30:52 -0400
Subject: [C++-sig] Raw member and constructor functions
References: <BAY101-F170A351D712A9C29E386C093F80@phx.gbl>
Message-ID: <upsv06wtf.fsf@boost-consulting.com>

"Studious Apprentice" <apprentice_99 at hotmail.com> writes:

> Hello !
>
> I would like to use raw member functions and a raw constructor. However I 
> can only manage to have raw functions to work.
>
> The following code works :
>
> #include <boost/python.hpp>
> #include <boost/python/raw_function.hpp>
> using namespace boost::python;
>
> tuple raw(tuple args, dict kw)
> {
> 	return make_tuple(args, kw);
> }
>
> BOOST_PYTHON_MODULE(PythonTest)
> {
> 	def("raw", raw_function(raw));
> }
>
> However this code does not compile with MSVC7.1 and results in "error C2064: 
> term does not evaluate to a function taking 2 arguments" :
>
> #include <boost/python.hpp>
> #include <boost/python/raw_function.hpp>
> using namespace boost::python;
>
> class X {
> public:
> 	object memberraw(tuple args, dict kw)
> 	{
> 		return object();
> 	}
> };
>
> BOOST_PYTHON_MODULE(PythonTest)
> {
> 	class_<X>("X")
> 		.def("memberraw", raw_function(&X::memberraw))
> 		;
> }

As http://www.boost.org/libs/python/doc/v2/raw_function.html says, 

   f(tuple(), dict())

must be well-formed where f is the argument to raw_function.  That's
clearly not the case here.  This might work:

tuple raw(tuple raw, dict kw)
{
    extract<X&>(raw[0])().memberraw(raw.slice(1), kw);
}

BOOST_PYTHON_MODULE(PythonTest)
{
	class_<X>("X")
		.def("memberraw", raw_function(raw))
		;
}


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



From apprentice_99 at hotmail.com  Mon Jun  6 10:32:40 2005
From: apprentice_99 at hotmail.com (Studious Apprentice)
Date: Mon, 06 Jun 2005 08:32:40 +0000
Subject: [C++-sig] Raw member and constructor functions
Message-ID: <BAY101-F24BE2CB1613697EA7B189F93FB0@phx.gbl>

Thanks a lot for this fast answer ! This looks like the way to go. The 
following code does compile but the result under python is unexpected :

#include <boost/python.hpp>
#include <boost/python/raw_function.hpp>
using namespace boost::python;

namespace {
	class X {
	public:
		object memberraw(const tuple& args, const dict& kw)
		{
			return make_tuple(args, kw);
		}
	};

	object memberrawfwd(tuple raw, dict kw)
	{
		tuple arg = extract<tuple&>(raw.slice(1, _))();
		return extract<X&>(raw[0])().
			memberraw(arg, kw);
	}

};

BOOST_PYTHON_MODULE(PythonTest)
{
	class_<X>("X")
		.def("memberraw", raw_function(memberrawfwd))
		;
}

However the following results when run with Python :
>>>a = X()
>>>a.memberraw()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: No registered converter was able to extract a C++ reference to 
type c
lass boost::python::tuple from this Python object of type tuple
>>>

Any further help ? Thanks in advance,

Marc

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On 
Behalf Of David Abrahams
Sent: lundi 6 juin 2005 04:31
To: c++-sig at python.org
Subject: Re: [C++-sig] Raw member and constructor functions

"Studious Apprentice" <apprentice_99 at hotmail.com> writes:

>Hello !
>
>I would like to use raw member functions and a raw constructor. However I 
>can only manage to have raw functions to work.
>
>The following code works :
>
>#include <boost/python.hpp>
>#include <boost/python/raw_function.hpp>
>using namespace boost::python;
>
>tuple raw(tuple args, dict kw)
>{
>	return make_tuple(args, kw);
>}
>
>BOOST_PYTHON_MODULE(PythonTest)
>{
>	def("raw", raw_function(raw));
>}
>
>However this code does not compile with MSVC7.1 and results in "error 
>C2064: term does not evaluate to a function taking 2 arguments" :
>
>#include <boost/python.hpp>
>#include <boost/python/raw_function.hpp>
>using namespace boost::python;
>
>class X {
>public:
>	object memberraw(tuple args, dict kw)
>	{
>		return object();
>	}
>};
>
>BOOST_PYTHON_MODULE(PythonTest)
>{
>	class_<X>("X")
>		.def("memberraw", raw_function(&X::memberraw))
>		;
>}

As http://www.boost.org/libs/python/doc/v2/raw_function.html says,

   f(tuple(), dict())

must be well-formed where f is the argument to raw_function.  That's
clearly not the case here.  This might work:

tuple raw(tuple raw, dict kw)
{
    extract<X&>(raw[0])().memberraw(raw.slice(1), kw);
}

BOOST_PYTHON_MODULE(PythonTest)
{
	class_<X>("X")
		.def("memberraw", raw_function(raw))
		;
}


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

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




From dave at boost-consulting.com  Mon Jun  6 12:56:04 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Jun 2005 06:56:04 -0400
Subject: [C++-sig] Raw member and constructor functions
References: <BAY101-F24BE2CB1613697EA7B189F93FB0@phx.gbl>
Message-ID: <upsuziwjf.fsf@boost-consulting.com>

"Studious Apprentice" <apprentice_99 at hotmail.com> writes:

> Thanks a lot for this fast answer ! This looks like the way to go. The 
> following code does compile but the result under python is unexpected :
>
> #include <boost/python.hpp>
> #include <boost/python/raw_function.hpp>
> using namespace boost::python;
>
> namespace {
> 	class X {
> 	public:
> 		object memberraw(const tuple& args, const dict& kw)
> 		{
> 			return make_tuple(args, kw);
> 		}
> 	};
>
> 	object memberrawfwd(tuple raw, dict kw)
> 	{
> 		tuple arg = extract<tuple&>(raw.slice(1, _))();

Why didn't you just do it the way I told you to?  Did that fail somehow?
This should be

     tuple arg( raw.slice(1,_) );

> 		return extract<X&>(raw[0])().
> 			memberraw(arg, kw);
> 	}
>
> };
>
> BOOST_PYTHON_MODULE(PythonTest)
> {
> 	class_<X>("X")
> 		.def("memberraw", raw_function(memberrawfwd))
> 		;
> }

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



From apprentice_99 at hotmail.com  Mon Jun  6 14:33:08 2005
From: apprentice_99 at hotmail.com (Studious Apprentice)
Date: Mon, 06 Jun 2005 12:33:08 +0000
Subject: [C++-sig] Raw member and constructor functions
Message-ID: <BAY101-F3273A443DCA6BDCF89FF4393FB0@phx.gbl>

Thanks again! It now works ;-) Sorry for my mistake, I modified the code 
because I got an conversion error at compilation from tuple to object, but 
the error was in the member function not in the forwarding function, so I 
added the extract which was indeed stupid ;-) Thanks again !

Marc

"Studious Apprentice" <apprentice_99 at hotmail.com> writes:

>Thanks a lot for this fast answer ! This looks like the way to go. The 
>following code does compile but the result under python is unexpected :
>
>#include <boost/python.hpp>
>#include <boost/python/raw_function.hpp> using namespace boost::python;
>
>namespace {
>	class X {
>	public:
>		object memberraw(const tuple& args, const dict& kw)
>		{
>			return make_tuple(args, kw);
>		}
>	};
>
>	object memberrawfwd(tuple raw, dict kw)
>	{
>		tuple arg = extract<tuple&>(raw.slice(1, _))();

Why didn't you just do it the way I told you to?  Did that fail somehow?
This should be

     tuple arg( raw.slice(1,_) );

>		return extract<X&>(raw[0])().
>			memberraw(arg, kw);
>	}
>
>};
>
>BOOST_PYTHON_MODULE(PythonTest)
>{
>	class_<X>("X")
>		.def("memberraw", raw_function(memberrawfwd))
>		;
>}

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

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




From dave at boost-consulting.com  Mon Jun  6 23:04:13 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Jun 2005 17:04:13 -0400
Subject: [C++-sig] Raw member and constructor functions
References: <BAY101-F3273A443DCA6BDCF89FF4393FB0@phx.gbl>
Message-ID: <ubr6jw62a.fsf@boost-consulting.com>

"Studious Apprentice" <apprentice_99 at hotmail.com> writes:

> Thanks again! It now works ;-) 

Excellent!

> Sorry for my mistake, I modified the code 
> because I got an conversion error at compilation from tuple to object, but 
> the error was in the member function not in the forwarding function, 

Probably because object's ctor is explicit.  Try using direct
initialization (parens) instead of implicit conversion or copy
initialization (assignment syntax).


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



From dan.eloff at gmail.com  Tue Jun  7 01:44:55 2005
From: dan.eloff at gmail.com (Dan Eloff)
Date: Mon, 6 Jun 2005 16:44:55 -0700
Subject: [C++-sig] Boost Python - class_<T> As object
Message-ID: <4817b6fc050606164463c1601d@mail.gmail.com>

Hi all, I've not posted to this discussion list before, but I have
been subscribed and following it loosely for a year now.

I was looking through the boost python docs and found something interesting:

class_<T> as objects

Due to the dynamic nature of Boost.Python objects, any class_<T> may
also be one of these types! The following code snippet wraps the class
(type) object.

We can use this to create wrapped instances. Example:

object vec345 = (
    class_<Vec2>("Vec2", init<double, double>())
        .def_readonly("length", &Point::length)
        .def_readonly("angle", &Point::angle)
    )(3.0, 4.0);

assert(vec345.attr("length") == 5.0);

This is nice, but I'm wondering about the inline class_<> declaration.
Specifically I don't want to copy and paste the entire class_<> stuff
everytime I want to create a python object of a exported c++ class and
use it in c++. This violates the rule of duplication as a bad thing.
How could I avoid this? Looking at it as I write, I think it may be
possible to save the entire thing as a C++ variable and then use it
elsewhere.

class_<Vec2> g_Vec2 = class_<Vec2>("Vec2", init<double, double>())
        .def_readonly("length", &Point::length)
        .def_readonly("angle", &Point::angle);

And then I use it like so ?:

object vec345 = g_Vec2(3.0,4.0);
object vec_other = g_Vec2(7.0,7.0);

And use it inside the module declaration as well:

BOOST_PYTHON_MODULE(mymodule)
(
g_Vec2;
...
)

I may be totally off here, but hopefully I've given a clear picture of
what I'm trying to do. I just want to put everything in one place if I
can.

Thanks for reading!
-Dan


From seefeld at sympatico.ca  Tue Jun  7 01:52:20 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 06 Jun 2005 19:52:20 -0400
Subject: [C++-sig] Boost Python - class_<T> As object
In-Reply-To: <4817b6fc050606164463c1601d@mail.gmail.com>
References: <4817b6fc050606164463c1601d@mail.gmail.com>
Message-ID: <42A4E1B4.8010104@sympatico.ca>

Dan Eloff wrote:

> This is nice, but I'm wondering about the inline class_<> declaration.
> Specifically I don't want to copy and paste the entire class_<> stuff
> everytime I want to create a python object of a exported c++ class and
> use it in c++. This violates the rule of duplication as a bad thing.
> How could I avoid this? Looking at it as I write, I think it may be
> possible to save the entire thing as a C++ variable and then use it
> elsewhere.
> 
> class_<Vec2> g_Vec2 = class_<Vec2>("Vec2", init<double, double>())
>         .def_readonly("length", &Point::length)
>         .def_readonly("angle", &Point::angle);
> 
> And then I use it like so ?:
> 
> object vec345 = g_Vec2(3.0,4.0);
> object vec_other = g_Vec2(7.0,7.0);
> 
> And use it inside the module declaration as well:
> 
> BOOST_PYTHON_MODULE(mymodule)
> (
> g_Vec2;
> ...
> )
> 
> I may be totally off here, but hopefully I've given a clear picture of
> what I'm trying to do. I just want to put everything in one place if I
> can.

I think you got it right. 'g_Vec2' represents a (python) type, and
'g_Vec2(...)' invokes __call__ on it, which is a constructor call in this
case, i.e. a factory that returns an instance of type 'g_Vec2'.

Regards,
		Stefan


From dave at boost-consulting.com  Tue Jun  7 04:14:54 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Jun 2005 22:14:54 -0400
Subject: [C++-sig] Boost Python - class_<T> As object
References: <4817b6fc050606164463c1601d@mail.gmail.com>
Message-ID: <uwtp6syjl.fsf@boost-consulting.com>

Dan Eloff <dan.eloff at gmail.com> writes:

> Hi all, I've not posted to this discussion list before, but I have
> been subscribed and following it loosely for a year now.
>
> I was looking through the boost python docs and found something interesting:
>
> class_<T> as objects
>
> Due to the dynamic nature of Boost.Python objects, any class_<T> may
> also be one of these types! The following code snippet wraps the class
> (type) object.
>
> We can use this to create wrapped instances. Example:
>
> object vec345 = (
>     class_<Vec2>("Vec2", init<double, double>())
>         .def_readonly("length", &Point::length)
>         .def_readonly("angle", &Point::angle)
>     )(3.0, 4.0);
>
> assert(vec345.attr("length") == 5.0);
>
> This is nice, but I'm wondering about the inline class_<> declaration.
> Specifically I don't want to copy and paste the entire class_<> stuff
> everytime I want to create a python object of a exported c++ class and
> use it in c++. This violates the rule of duplication as a bad thing.
> How could I avoid this? Looking at it as I write, I think it may be
> possible to save the entire thing as a C++ variable and then use it
> elsewhere.
>
> class_<Vec2> g_Vec2 = class_<Vec2>("Vec2", init<double, double>())
>         .def_readonly("length", &Point::length)
>         .def_readonly("angle", &Point::angle);

Well, I'm not sure that class_<T> has a copy ctor.  But as you've
been saying, why repeat yourself?

object g_Vec2 = 
   class_<Vec2>("Vec2", init<double, double>())
      .def_readonly("length", &Point::length)
      .def_readonly("angle", &Point::angle)
      ;

object vec345 = g_Vec2(3.0,4.0);
object vec_other = g_Vec2(7.0,7.0);

If the tutorial doesn't make it crystal clear that you can do that, it
should.

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



From apprentice_99 at hotmail.com  Tue Jun  7 17:43:03 2005
From: apprentice_99 at hotmail.com (Studious Apprentice)
Date: Tue, 07 Jun 2005 15:43:03 +0000
Subject: [C++-sig] And now for a raw constructor
Message-ID: <BAY101-F2112D876BBA8B68879D01093FA0@phx.gbl>

Thanks again Dave for the help provided ! I would like to know if there is a 
way to do the same for a constructor. I planned to use a .def("__init__", 
rawfunction(constructorfwd)) but this wont work for I do not have a 
constructed object to start with ;-) and on the top of that the object needs 
to be constructed at a specific place.

Browsing through the Boost Python code, it looks like I could use the 
detail::make_keyword_range_constructor<Signature,NArgs> function or even use 
the objects::make_holder<Arity> however I do know which parameters I should 
provide...

Thanks in advance,

Marc




From skottmckay at gmail.com  Tue Jun  7 18:33:04 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Tue, 7 Jun 2005 10:33:04 -0600
Subject: [C++-sig] pyste #include format
Message-ID: <51d01787050607093312978ffa@mail.gmail.com>

Could this line in pyste.py

    context['Include'] = lambda header: infos.CodeInfo('#include
<%s>\n' % header, 'include')

possibly be changed to something like this instead to honour the
existing syntax but also allow you to explicitly specify the include
format?

       context['Include'] = infos.Include

with the following addition to infos.py

def Include( header ):

    header = header.strip()

    if ( header[0] == '"' or header[0] == '<' ) :
        CodeInfo('#include %s\n' % header, 'include')
    else:
        CodeInfo('#include <%s>\n' % header, 'include')

Cheers

Scott


From s_sourceforge at nedprod.com  Tue Jun  7 18:52:28 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 07 Jun 2005 17:52:28 +0100
Subject: [C++-sig] Custodian & ward
Message-ID: <42A5DEDC.611.1BAEEAF@localhost>

Hi,

If there is:

struct FXWindow
{
  FXWindow(FXWindow *parent=0);
};

... and each FXWindow instance maintains a list of its children, and 
deletes its children when it gets deleted, then how do I apply 
custodian & ward to ensure that when the parent instance is deleted, 
python knows not to delete the children?

Something like:

class_< FXWindow >("FXWindow", init< 
FXWindow*>()[with_custodian_and_ward_postcall<1,2>()])

BTW the docs on the reference page for with_custodian_and_ward are 
confusing - the text suggests that the first arg determines the life 
of the second, whereas the code for return_internal_reference() is 
pretty clear that the second arg determines the life of the first. I 
am assuming that the latter is the correct orientation?

Cheers,
Niall





From s_sourceforge at nedprod.com  Tue Jun  7 18:58:56 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 07 Jun 2005 17:58:56 +0100
Subject: [C++-sig] Custodian & ward
Message-ID: <42A5E060.10783.1C0DA7E@localhost>

Hi,

If there is:

struct FXWindow
{
  FXWindow(FXWindow *parent=0);
};

... and each FXWindow instance maintains a list of its children, and 
deletes its children when it gets deleted, then how do I apply 
custodian & ward to ensure that when the parent instance is deleted, 
python knows not to delete the children?

Something like:

class_< FXWindow >("FXWindow", init< 
FXWindow*>()[with_custodian_and_ward_postcall<1,2>()])

BTW the docs on the reference page for with_custodian_and_ward are 
confusing - the text suggests that the first arg determines the life 
of the second, whereas the code for return_internal_reference() is 
pretty clear that the second arg determines the life of the first. I 
am assuming that the latter is the correct orientation?

Cheers,
Niall






From s_sourceforge at nedprod.com  Tue Jun  7 19:01:32 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 07 Jun 2005 18:01:32 +0100
Subject: [C++-sig] Improved pyste
Message-ID: <42A5E0FC.812.1C33D07@localhost>

(The file is at http://www.nedprod.com/Pyste.zip as it seems you 
can't post attachments here)

Enclosed is a further improved version of pyste over the one I sent 
some months ago. This is from the pyste in v1.32. Here are the 
changes:

* Overloads were being declared multiply per code unit if they 
applied to each class, now they are output only once

* friend functions of classes which overload weren't being 
distinguished between by casting (fixed by brute force casting all 
functions)

* Outputs things missing a policy to a file for more easier browsing

* Fixed a bug where it was missing "artificial" copy constructors ie;
ones generated by the compiler

* Got AllFromHeader() to maintain a list of things it exported so the
pyste file can know what policies to apply. This is very much a hack 
and would conflict with anything in the header file called "exporter"

* Fixed AllFromHeader() breaking application of bases<> to class 
definitions

* Added new SplitOutput() directive which can split output into 
multiple files, thus avoiding MSVC's "internal structure overflow" 
error. Note that the implementation of this is pretty hacky

This is in addition to the previous enhancements:

* Support for void* by casting to void_* and treating it as an opaque
pointer. This is a major new feature for wrapping most code.

* Prevents the problem of throw() specifiers confusing Boost.Python 
by casting them off

* Passing of gccxml errors out so you can see what's confusing 
GCC/GCCXML (handy when you develop primarily with MSVC)

* Protected virtual methods are no longer wrapped as there were 
access problems. I've had similar problems with protected 
inheritance.

Cheers,
Niall





From nicodemus at esss.com.br  Tue Jun  7 19:26:15 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Tue, 07 Jun 2005 14:26:15 -0300
Subject: [C++-sig] Improved pyste
In-Reply-To: <42A5E0FC.812.1C33D07@localhost>
References: <42A5E0FC.812.1C33D07@localhost>
Message-ID: <42A5D8B7.9010301@esss.com.br>

Hi Niall,

Niall Douglas wrote:

><snip improvements>
>  
>

Thanks a lot. Some of the improvements have already been applied to the 
HEAD from your previous patch. I will take a look at the new changes in 
the next few days and apply it.

Regards,
Bruno.


From cppsig-eric at sneakemail.com  Tue Jun  7 22:50:24 2005
From: cppsig-eric at sneakemail.com (Eric)
Date: Tue, 7 Jun 2005 13:50:24 -0700
Subject: [C++-sig] Improved pyste
In-Reply-To: <42A5E0FC.812.1C33D07@localhost>
Message-ID: <28794-74921@sneakemail.com>


Wow, can't wait to try this out. I had a question:

> * Added new SplitOutput() directive which can split output into 
> multiple files, thus avoiding MSVC's "internal structure overflow" 
> error. Note that the implementation of this is pretty hacky

Can you say a bit more about how this works? 



> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]On
> Behalf Of Niall Douglas s_sourceforge-at-nedprod.com |cppsig|
> Sent: Tuesday, June 07, 2005 10:02 AM
> To: ......................
> Subject: [C++-sig] Improved pyste
> 
> 
> (The file is at http://www.nedprod.com/Pyste.zip as it seems you 
> can't post attachments here)
> 
> Enclosed is a further improved version of pyste over the one I sent 
> some months ago. This is from the pyste in v1.32. Here are the 
> changes:
> 
> * Overloads were being declared multiply per code unit if they 
> applied to each class, now they are output only once
> 
> * friend functions of classes which overload weren't being 
> distinguished between by casting (fixed by brute force casting all 
> functions)
> 
> * Outputs things missing a policy to a file for more easier browsing
> 
> * Fixed a bug where it was missing "artificial" copy constructors ie;
> ones generated by the compiler
> 
> * Got AllFromHeader() to maintain a list of things it exported so the
> pyste file can know what policies to apply. This is very much a hack 
> and would conflict with anything in the header file called "exporter"
> 
> * Fixed AllFromHeader() breaking application of bases<> to class 
> definitions
> 
> * Added new SplitOutput() directive which can split output into 
> multiple files, thus avoiding MSVC's "internal structure overflow" 
> error. Note that the implementation of this is pretty hacky
> 
> This is in addition to the previous enhancements:
> 
> * Support for void* by casting to void_* and treating it as an opaque
> pointer. This is a major new feature for wrapping most code.
> 
> * Prevents the problem of throw() specifiers confusing Boost.Python 
> by casting them off
> 
> * Passing of gccxml errors out so you can see what's confusing 
> GCC/GCCXML (handy when you develop primarily with MSVC)
> 
> * Protected virtual methods are no longer wrapped as there were 
> access problems. I've had similar problems with protected 
> inheritance.
> 
> Cheers,
> Niall
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 


From rwgk at yahoo.com  Tue Jun  7 23:18:52 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 7 Jun 2005 14:18:52 -0700 (PDT)
Subject: [C++-sig] Improved pyste
In-Reply-To: <28794-74921@sneakemail.com>
Message-ID: <20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>

--- Eric <cppsig-eric at sneakemail.com> wrote:
> Wow, can't wait to try this out. I had a question:
> 
> > * Added new SplitOutput() directive which can split output into 
> > multiple files, thus avoiding MSVC's "internal structure overflow" 
> > error. Note that the implementation of this is pretty hacky
> 
> Can you say a bit more about how this works? 

FWIW: I've never seen the dreaded "internal structure overflow" error with
Visual C++ 7.1. Since the compiler is available free of charge I wonder why
anybody is still "investing" time working around the numerous problems in VC6
and VC 7.0:

http://msdn.microsoft.com/visualc/vctoolkit2003/

Cheers,
        Ralf


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


From s_sourceforge at nedprod.com  Wed Jun  8 00:43:33 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 07 Jun 2005 23:43:33 +0100
Subject: [C++-sig] Improved pyste
In-Reply-To: <20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
References: <28794-74921@sneakemail.com>
Message-ID: <42A63125.6154.2FC5ABE@localhost>

On 7 Jun 2005 at 14:18, Ralf W. Grosse-Kunstleve wrote:

> > > * Added new SplitOutput() directive which can split output into
> > > multiple files, thus avoiding MSVC's "internal structure overflow"
> > > error. Note that the implementation of this is pretty hacky
> > 
> > Can you say a bit more about how this works?

Yeah it's very easy. For example:

class A
{
  virtual void foo();
};

class B
{
  virtual void foo();
}

in file TestFile.h with TestFile.pyste containing SplitOutput("A") 
causes generation of _TestFile.cpp and _TestFile1.cpp.

_TestFile.cpp contain everything not split ie; class B. 
_TestFile1.cpp contains just the class_<"A"> and the A_Wrapper class. 
All headers, PCH etc. are the same for both files.

This good when any one of your classes alone isn't complex enough to 
kill MSVC, but doesn't help you if any single class is. However it's 
not much of an additional step to get pyste to pass the class_<> 
instance to the subsiduary c++ file so that more defs can be applied 
to it.

I could have had pyste do this automatically, but the problem is that 
complexity has little to do with simple line counts - a short class 
definition can trip the compiler as much as a much longer one. Hence 
I went with the new directive so the user can specify manually.

You can specify SplitOutput() many times, with each class going into 
its own .cpp file. I had to do this with FXMDIButton.h as each class 
alone was too big to coexist with any other, and it defined like six 
MDI buttons.

I should warn you that the pyste I supplied outputs TnFOX-only code 
as I had to patch BPL to unlock the interpreter around entering C++, 
though it's trivial to return to the default pyste output.

> FWIW: I've never seen the dreaded "internal structure overflow" error
> with Visual C++ 7.1. Since the compiler is available free of charge I
> wonder why anybody is still "investing" time working around the
> numerous problems in VC6 and VC 7.0:

Oh no, it's MSVC7.1 is the problem. Some *nine* files of 238 total 
output by pyste cause fatal internal structure overflows but then I 
can see why, the output is about 50-80Kb long with multiple 
polymorphic classes with multiple inheritance all kicking along. To 
give you some idea, the whole of the TnFOX python bindings is around 
110,000 lines of code which is nearly that of the TnFOX core library 
itself. The DLL output was around 16Mb release build and takes about 
six hours to link and comdat optimise.

As you might imagine, binding TnFOX to Python has pushed BPL itself, 
pyste and the compilers & linkers to their limit. It was after all 
the cause of me patching GCC with the visibility patch.

I'd imagine MSVC8 is better, but I haven't tried it. GCC is just 
fine.

Cheers,
Niall





From roman.yakovenko at gmail.com  Wed Jun  8 08:02:39 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 8 Jun 2005 09:02:39 +0300
Subject: [C++-sig] Improved pyste
In-Reply-To: <42A63125.6154.2FC5ABE@localhost>
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
Message-ID: <7465b61705060723025e2d4dff@mail.gmail.com>

Hi.

Sorry for bad English!

A few month ago I started to write boost python code generator from
zero. It's name is pycplusplus ( py++ ). Right now I am missing 3
futures: class wrappers, call policies( will be implemented pretty
soon ) and documentation. I attach small example of using my library.

Small introduction: py++ is based on an other library I developed: pygccxml. 

About pygccxml:
This library parsers GCC-XML generated file. It use only build in
libraries. XML parsing done using SAX api. This gave huge speed
improvement. Also pygccxml can read whole project: you can give him a
list of files and it will tell you all declarations found within
files. It can do it by parsing file by file and after this joining
declarations. Or by creating temporal file that includes all files.
That's not all. I am almost sure that you use boost::type_traites
library. Well pygccxml has similar capabilities. It's implements
almost all type_traites functionality. This functionality will be used
in implementing call policies in py++. Although pygccxml has good
documentation and more then 60 unittests. pygccxml uses boost license.
If you interested here is url: http://pygccxml.sourceforge.net/. 

About py++:
py++ is library I am developing right now. It is heavily based on
pygccxml. py++ introduces next terminology:

code creators - classes that implements code creation logic. 
file writers - classes that implements logic that will dump created
code to different files.
module creator - class (factory) that implements logic what should be
exported and the
                         order of to be export elements. For example
in this factory implemented \
                         topological sort algorithm in order to find
out c++ class exporting order.

This gave me power, flexible and expendable design. User can introduce
his own code creators. To implement his own file writer. That's not
all. I found that there are 2 - 3 projects similar to boost.python
library: langbinding, lua bind and tcl bind that use almost same
syntax's to expose C++ classes to target language. I think it should
be easy to add code generation functionality for those projects. An
other difference between py++ and pyste is the way you use it. py++ is
python package: you call function and it does the job. Well an other
way that py++ could be extended is generating python code. Consider
next situation:

namespace top{
namepsace x1{...}
namepsace x2{...}
}

In my opinion the resulting could should be package top that has to
modules or sub packages x1 and x2. py++ has all data in order to
implement this.

Any way: I think I introduced new and powerful alternative to pyste.
Right now it has more bugs than futures, less power than pyste. But
don't worry I am going to fix the situation..

What I am asking is please take a look to py++ and say what do you
think about it.
py++ is sharing same cvs as pygccxml. Here is the link with
instructions to check out the code.
http://sourceforge.net/cvs/?group_id=118209

Development of both projects done in simultaneously on windows and Linux.

Thanks for attention.

Roman
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: example.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050608/3b6cfb9c/attachment.txt>

From dave at boost-consulting.com  Wed Jun  8 15:21:46 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Jun 2005 09:21:46 -0400
Subject: [C++-sig] Improved pyste
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
Message-ID: <uzmu1htlh.fsf@boost-consulting.com>

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

> Any way: I think I introduced new and powerful alternative to pyste.
> Right now it has more bugs than futures, less power than pyste. But
> don't worry I am going to fix the situation..

What is the point?  Why not pour your energy into Pyste?  Or work with
Nicodemus to integrate the two efforts?

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



From nico_ml at mgdesign.org  Wed Jun  8 15:55:22 2005
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Wed, 8 Jun 2005 15:55:22 +0200
Subject: [C++-sig] std::wstring argument troubles ?
Message-ID: <028d01c56c31$bd50beb0$de00a8c0@nico>

Hi,

I updated my boost libraries last week (via CVS on the 06/02) and I'm now 
experiencing problems when calling functions with wstring arguments, which 
worked seamlessly with my previous boost libs, using python 2.4.

I may be missing something obvious, did anything change concerning wstring 
support (I was previously using a CVS snapshot around v1.31 of boost)

for instance, I have a class BrushTextMenu::Entry defined roughly as follows 
::

class BrushTextMenu : public ...
{
public:
struct Entry
{
Entry() {};
explicit Entry(std::wstring const& _text) : text(_text) {};
std::wstring text;
};

which is wrapped as follows ::

python::class_<BrushTextMenu, bases<Brush>, 
Brush_Holder<BrushTextMenu>::type, boost::noncopyable> 
class_BrushTextMenu("BrushTextMenu", no_init);
{
    python::scope class_scope = class_BrushTextMenu;
    python::class_<BrushTextMenu::Entry>("Entry")
        .def( init<std::wstring const&>() )
        ;
}

now, whenever I call the Entry constructor, I get error messages concerning 
signature mismatch ::

b = BrushTextMenu.Entry(u"r")

==>
Traceback (most recent call last):
  File "<string>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    Entry.__init__(Entry, unicode)
did not match C++ signature:
    __init__(struct _object *, class std::basic_string<unsigned short,struct 
std::char_traits<unsigned short>,class std::allocator<unsigned short> >)
    __init__(struct _object *)

or

b = BrushTextMenu.Entry("r")

==>
Traceback (most recent call last):
  File "<string>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    Entry.__init__(Entry, str)
did not match C++ signature:
    __init__(struct _object *, class std::basic_string<unsigned short,struct 
std::char_traits<unsigned short>,class std::allocator<unsigned short> >)
    __init__(struct _object *)

Thanks in advance,

Nicolas. 



From nico_ml at mgdesign.org  Wed Jun  8 16:39:21 2005
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Wed, 8 Jun 2005 16:39:21 +0200
Subject: [C++-sig] std::wstring argument troubles ?
References: <028d01c56c31$bd50beb0$de00a8c0@nico>
Message-ID: <02bc01c56c37$dc145bd0$de00a8c0@nico>

Hm, obsiouvly I missed something obvious ... :}

For the records, the problem was that I compiled boost.python lib with BJam 
(which I did not do before) with vc-7_1 toolset, and BJam activates the VC 
'treat wchar_t as Build-in Type' (/Zc:wchar_t) whereas my extension modules 
were not using this option. Hence, the registered builtin type converter was 
refering to std::wstring as std::basic_string<wchar_t, ...> and my module to 
std::basic_string<unsigned short, ...>

So one have to make sure that the boost.python lib and his modules are 
consistent in wchar_t compilation...

Sorry for the time lost,
Regards,

Nicolas. 



From dave at boost-consulting.com  Wed Jun  8 18:25:06 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Jun 2005 12:25:06 -0400
Subject: [C++-sig] Improved pyste
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
	<uzmu1htlh.fsf@boost-consulting.com>
Message-ID: <uacm06ckd.fsf@boost-consulting.com>

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

> Roman Yakovenko <roman.yakovenko at gmail.com> writes:
>
>> Any way: I think I introduced new and powerful alternative to pyste.
>> Right now it has more bugs than futures, less power than pyste. But
>> don't worry I am going to fix the situation..
>
> What is the point?  Why not pour your energy into Pyste?  Or work with
> Nicodemus to integrate the two efforts?

Sorry, I don't mean to be discouraging.  It's always great when a new
project supporting Boost.Python appears.  But I still prefer 
cooperation to competition when possible.  Can you explain what your
system offers, or will offer, that Pyste cannot?

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



From jake at zarloc.com  Thu Jun  9 02:26:32 2005
From: jake at zarloc.com (Jake Skinner)
Date: Thu, 09 Jun 2005 09:56:32 +0930
Subject: [C++-sig] trouble linking with wxWidgets
In-Reply-To: <uacm06ckd.fsf@boost-consulting.com>
References: <28794-74921@sneakemail.com>	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>	<42A63125.6154.2FC5ABE@localhost>	<7465b61705060723025e2d4dff@mail.gmail.com>	<uzmu1htlh.fsf@boost-consulting.com>
	<uacm06ckd.fsf@boost-consulting.com>
Message-ID: <42A78CB8.10804@zarloc.com>

Hello,

I am trying to do an extension. I'm using python 2.4, wxWidgets 2.6,
boost 1.32 and vc.net. I can't seem to get to get wxWidgets to link (I
have built it as one big dll). I am building it in the
libs/python/example directory

this is my jamfile
---------------------------
project-root ;
import python ;

extension pyROSS
: pyROSS.cpp
: <include>c:/wxDockit/include
  <include>c:/wxWidgets-src-2.6.0.0/include
  <include>c:/data/RossClient
  <include>c:/wxWidgets-src-2.6.0.0/lib/vc_dll/mswd
  <dll>boost_python_debug
  <dll>wxmswd26d_vc
  <library-path>c:/boost_1_32_0/libs/python/build/bin-stage
  <library-path>c:/wxWidgets-src-2.6.0.0/lib/vc_dll
  <find-library>boost_python_debug
  <find-library>wxmsw26d
  <template>@boost/libs/python/build/extension
  ;
-------------------------------------
below i have included the link error:


pyROSS.obj : error LNK2019: unresolved external symbol "class
Application & __cdecl wxGetApp(void)" (?wxGetApp@@YAAAVApplicat
ion@@XZ) referenced in function "public: __thiscall `anonymous
namespace'::pyROSS::pyROSS(void)" (??0pyROSS@?A0xba7fa9fe@@QAE
@XZ)
bin\example\pyROSS.pyd\vc-7_1\debug\threading-multi\pyROSS.pyd : fatal
error LNK1120: 1 unresolved externals

    CALL "C:\Program Files\Microsoft Visual Studio .NET
2003\VC7\bin\VCVARS32.BAT" >nul
    "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\link" 
/nologo /INCREMENTAL:NO  /DEBUG /DLL /subsystem:consol
e  
/out:"bin\example\pyROSS.pyd\vc-7_1\debug\threading-multi\pyROSS.pyd" 
/IMPLIB:"bin\example\pyROSS.pyd\vc-7_1\debug\threa
ding-multi\pyROSS.lib" 
/LIBPATH:"c:\boost_1_32_0\libs\python\build\bin-stage"
/LIBPATH:"c:\wxWidgets-src-2.6.0.0\lib\vc_dll"
/LIBPATH:"c:\Python-2.4.1\libs" /LIBPATH:"c:\Python-2.4.1\PCbuild"  
"boost_python_debug.lib" "wxmsw26d.lib" "python24.lib"
@"bin\example\pyROSS.pyd\vc-7_1\debug\threading-multi\pyROSS.CMD"


I build it with 'bjam.exe -sTOOLS=vc-7_1 -a'

It looks like it is linking to the wxmsw26d.lib, I think the problem is
my lack of experience with bjam.

jake
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pyROSS.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050609/3149f6ba/attachment.txt>

From roman.yakovenko at gmail.com  Thu Jun  9 07:53:02 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Thu, 9 Jun 2005 08:53:02 +0300
Subject: [C++-sig] Improved pyste
In-Reply-To: <uacm06ckd.fsf@boost-consulting.com>
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
	<uzmu1htlh.fsf@boost-consulting.com>
	<uacm06ckd.fsf@boost-consulting.com>
Message-ID: <7465b61705060822531d375f23@mail.gmail.com>

On 6/8/05, David Abrahams <dave at boost-consulting.com> wrote:
> David Abrahams <dave at boost-consulting.com> writes:
> ...Can you explain what your system offers, or will offer, that Pyste cannot?

Yes. 

1. One of the main differences from user point of view is the way he use it.

Pyste - is program that takes as input configurations files and works on them
py++ - is python package that expose a few classes that makes the job.

2. Extendability:  If I need a custom way to export something it could
not be easily done with pyste. Example: there are a lot of projects
that use java-doc like comments within source. Using py++ it is simple
to create new class that derives from one of build in classes and
implement logic of injection of documentation into python wrapper. An
other example is - programmer can define call policies within special
comment near function declaration and then to read it during code
creation process

3. Flexibility: May be I wrong but there is no easy way in Pyste to
exclude functions
that takes as argument some specific type. For example: I have classes
that has functions that deals with XML using xercesc library. I want
to exclude all those functions.

4. py++ could be extended to generate python code. Consider next situation:

namespace top{
namepsace x1{...}
namepsace x2{...}
}

In my opinion the resulting could should be package top that has to
modules or sub packages x1 and x2. py++ has all data in order to
implement this.

I think there is no easy way to do it in Pyste. Am I wrong?

5. There is full separation between next things: 
    1. what should be exported and in what order
    2. how it should be exported
    3. where and how to write code in files

6. As I mentioned in my previous post: there are a few projects that
use similar way to expose C++ to different languages. One of them is
yours: langbinding. I think it will be pretty easy to support code
generation for this library too. ( This statement still should be
checked by reality )

Before starting to write code for py++, I checked what could be
improved in current Pyste. The first obvious thing was parsing GCC-XML
generated file. I created new python package called pygccxml. After
this, I checked how pygccxml could be integrated with Pyste. It was
too difficult. So I dropped this idea. Also I do had small coversation
with Nicodemus. And in one mail he told me that is going to be next
version of Pyste. It was 6 months ago. Nothing happen till now. So I
decided to write next version of Pyste.

That's all. I hope in 2 or 4 month I will have first version, that
could be released.

Roman.


From dave at boost-consulting.com  Thu Jun  9 17:14:20 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 09 Jun 2005 11:14:20 -0400
Subject: [C++-sig] Improved pyste
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
	<uzmu1htlh.fsf@boost-consulting.com>
	<uacm06ckd.fsf@boost-consulting.com>
	<7465b61705060822531d375f23@mail.gmail.com>
Message-ID: <uy89jtveb.fsf@boost-consulting.com>

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

> On 6/8/05, David Abrahams <dave at boost-consulting.com> wrote:
>> David Abrahams <dave at boost-consulting.com> writes:
>> ...Can you explain what your system offers, or will offer, that Pyste cannot?
>
> Yes. 
>
> 1. One of the main differences from user point of view is the way he use it.
>
> Pyste - is program that takes as input configurations files and works on them
> py++ - is python package that expose a few classes that makes the job.

IIUC Pyste "configuration files" are just Python modules that use a
package that "exposes a few classes that makes the job."

> 2. Extendability:  If I need a custom way to export something it could
> not be easily done with pyste. Example: there are a lot of projects
> that use java-doc like comments within source. Using py++ it is simple
> to create new class that derives from one of build in classes and
> implement logic of injection of documentation into python wrapper. An
> other example is - programmer can define call policies within special
> comment near function declaration and then to read it during code
> creation process

Okay, that's interesting.

> 3. Flexibility: May be I wrong but there is no easy way in Pyste to
> exclude functions
> that takes as argument some specific type. For example: I have classes
> that has functions that deals with XML using xercesc library. I want
> to exclude all those functions.
>
> 4. py++ could be extended to generate python code. Consider next situation:
>
> namespace top{
> namepsace x1{...}
> namepsace x2{...}
> }
>
> In my opinion the resulting could should be package top that has to
> modules or sub packages x1 and x2. py++ has all data in order to
> implement this.
>
> I think there is no easy way to do it in Pyste. Am I wrong?

I don't know, but these are the sort of questions I would have
discussed with Pyste's author before beginning such a project.

> 5. There is full separation between next things: 
>     1. what should be exported and in what order
>     2. how it should be exported
>     3. where and how to write code in files

I'm not sure I want 1&2 "fully separated." When I say that something
should be exported, why wouldn't I want to say how it is exported at
the same time?

> 6. As I mentioned in my previous post: there are a few projects that
> use similar way to expose C++ to different languages. One of them is
> yours: langbinding. I think it will be pretty easy to support code
> generation for this library too. ( This statement still should be
> checked by reality )
>
> Before starting to write code for py++, I checked what could be
> improved in current Pyste. The first obvious thing was parsing GCC-XML
> generated file. I created new python package called pygccxml. After
> this, I checked how pygccxml could be integrated with Pyste. It was
> too difficult. So I dropped this idea. Also I do had small coversation
> with Nicodemus. And in one mail he told me that is going to be next
> version of Pyste. It was 6 months ago. Nothing happen till now. So I
> decided to write next version of Pyste.
>
> That's all. I hope in 2 or 4 month I will have first version, that
> could be released.

Well, it certainly sounds interesting.  I still think you will get a
better project if you collaborate more.  Rather than waiting for
Nicodemus to come up with something and then when he doesn't, deciding
you're going to write the next version of his project, you could be
consulting with him as you go along.  A person who has gone down the
road once usually has a great deal of valuable insight into how to
traverse it better.

Good luck, regardless!

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



From chilavert123 at gmx.net  Fri Jun 10 10:11:00 2005
From: chilavert123 at gmx.net (Thomas Kolb)
Date: Fri, 10 Jun 2005 10:11:00 +0200
Subject: [C++-sig] Function needs ownership of python object that is derived
 from a C++ class
Message-ID: <d8bhmi$1uk$1@sea.gmane.org>

Hi all,

I have a C++ class Base that is declared as follows:
	struct Base
	{
		virtual int f() = 0;
	};
and a free function call_f that needs ownership of the parameter:
	void Moses::call_f(Base* b)
	{
		std::cout << " b->f() = " << b->f() << std::endl;
		delete (b);
	}
On pyhton side I derive from Base like that:

class Derived(Base):
	def f(self):
		return 42


of course the following leads to a segmentation fault:
	d = Derived()
	call_f(d)

First thing I tried was to do this auto_ptr stuff as described in FAQ 
("How can I wrap a function which needs to take ownership of a raw 
pointer"), but this doesn't work because of:
      Boost.Python.ArgumentError: Python argument types in
      call_f(Derived)
           did not match C++ signature:
      call_f(std::auto_ptr<Moses::Base>)

then I tried to wrap call_f as follows below:
	call_f_Wrapper(PyObject* p)
	{
              handle<> hP(p);
              Moses::Base* bP = extract<Moses::Base*>(object(hP));
	     call_f(bP);
         }
but this leads to segmentation faults too.

Last thing I did was the stuff described in PythonInfo Wiki in section 
"ownership of C++ object extended in Python", but that also doesn't work 
and so, I guess I need your help.

Best Regards,
    Franz



From s_sourceforge at nedprod.com  Fri Jun 10 15:57:15 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Jun 2005 14:57:15 +0100
Subject: [C++-sig] BPL and Py_Clear()
Message-ID: <42A9AA4B.10179.5BB929B@localhost>

How well does BPL handle Py_Clear() being called on a wrapped object 
instance when there are still plenty of referants around? What 
happens if something tries to access the wrapped object instance 
after it has been cleared? Does it get None, or does it crash?

Cheers,
Niall





From s_sourceforge at nedprod.com  Fri Jun 10 16:27:05 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Jun 2005 15:27:05 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <42A9AA4B.10179.5BB929B@localhost>
Message-ID: <42A9B149.14416.5D6E3B6@localhost>

On 10 Jun 2005 at 14:57, Niall Douglas wrote:

> How well does BPL handle Py_Clear() being called on a wrapped object
> instance when there are still plenty of referants around? What happens
> if something tries to access the wrapped object instance after it has
> been cleared? Does it get None, or does it crash?

Actually ignore this question. However, I have another:

How do you absolutely ensure a BPL wrapped object ceases to exist? In 
other words, if python code has ten references to a BPL wrapped 
object and I want that object to die immediately, therefore I would 
have to ensure either (a) the BPL wrapped object becomes a zombie or 
(b) each and every reference to that object is set to None.

The latter sounds more appealing. I'm assuming I'd have to walk some 
table in Python?

Cheers,
Niall





From seefeld at sympatico.ca  Fri Jun 10 16:46:00 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 10 Jun 2005 10:46:00 -0400
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <42A9B149.14416.5D6E3B6@localhost>
References: <42A9B149.14416.5D6E3B6@localhost>
Message-ID: <42A9A7A8.9030602@sympatico.ca>

Niall Douglas wrote:

> How do you absolutely ensure a BPL wrapped object ceases to exist? In 
> other words, if python code has ten references to a BPL wrapped 
> object and I want that object to die immediately, therefore I would 
> have to ensure either (a) the BPL wrapped object becomes a zombie or 
> (b) each and every reference to that object is set to None.
> 
> The latter sounds more appealing. I'm assuming I'd have to walk some 
> table in Python?

That sounds quite unpythonic ! If I hold a reference to a python object,
I don't expect that to die in the middle of a program. Actually, I have
been debugging some code recently where I do some cleanup in a __del__
function of a global object, but the way python cleans up modules made
those calls fail, since system modules I tried to use were already set
to None. Fortunately that only happened at the end of a program, so
the issue was relatively easy to work around. (Yet I'm not sure whether
that can be considered a python bug.)

Regards,
		Stefan



From s_sourceforge at nedprod.com  Fri Jun 10 17:41:48 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Jun 2005 16:41:48 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <42A9A7A8.9030602@sympatico.ca>
References: <42A9B149.14416.5D6E3B6@localhost>
Message-ID: <42A9C2CC.22250.61B4B8D@localhost>

On 10 Jun 2005 at 10:46, Stefan Seefeld wrote:

> > How do you absolutely ensure a BPL wrapped object ceases to exist?
> > In other words, if python code has ten references to a BPL wrapped
> > object and I want that object to die immediately, therefore I would
> > have to ensure either (a) the BPL wrapped object becomes a zombie or
> > (b) each and every reference to that object is set to None.
> > 
> > The latter sounds more appealing. I'm assuming I'd have to walk some
> > table in Python?
> 
> That sounds quite unpythonic ! If I hold a reference to a python
> object, I don't expect that to die in the middle of a program.

Well true, but the library I am wrapping has parents eating their 
young and if you don't tell python that the children are now invalid, 
python segfaults.

> Actually, I have been debugging some code recently where I do some
> cleanup in a __del__ function of a global object, but the way python
> cleans up modules made those calls fail, since system modules I tried
> to use were already set to None. Fortunately that only happened at the
> end of a program, so the issue was relatively easy to work around.
> (Yet I'm not sure whether that can be considered a python bug.)

Yeah there's a lack of order of destruction much like C++ static 
inits. It's unfortunate.

Cheers,
Niall





From dave at boost-consulting.com  Fri Jun 10 19:05:52 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Jun 2005 13:05:52 -0400
Subject: [C++-sig] Function needs ownership of python object that is
	derived from a C++ class
References: <d8bhmi$1uk$1@sea.gmane.org>
Message-ID: <u64wmm9an.fsf@boost-consulting.com>

Thomas Kolb <chilavert123 at gmx.net> writes:

> Hi all,
>
> I have a C++ class Base that is declared as follows:
> 	struct Base
> 	{
> 		virtual int f() = 0;
> 	};
> and a free function call_f that needs ownership of the parameter:
> 	void Moses::call_f(Base* b)
> 	{
> 		std::cout << " b->f() = " << b->f() << std::endl;
> 		delete (b);
> 	}

It should take auto_ptr<Base> as an argument, if possible.

> On pyhton side I derive from Base like that:
>
> class Derived(Base):
> 	def f(self):
> 		return 42
>
>
> of course the following leads to a segmentation fault:
> 	d = Derived()
> 	call_f(d)
>
> First thing I tried was to do this auto_ptr stuff as described in FAQ 
> ("How can I wrap a function which needs to take ownership of a raw 
> pointer"), but this doesn't work because of:
>       Boost.Python.ArgumentError: Python argument types in
>       call_f(Derived)
>            did not match C++ signature:
>       call_f(std::auto_ptr<Moses::Base>)

Did you miss this part?  


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

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

In your case, 

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


> then I tried to wrap call_f as follows below:
> 	call_f_Wrapper(PyObject* p)
> 	{
>               handle<> hP(p);
>               Moses::Base* bP = extract<Moses::Base*>(object(hP));
> 	     call_f(bP);
>          }
> but this leads to segmentation faults too.

I would expect so.

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



From dave at boost-consulting.com  Fri Jun 10 19:08:02 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Jun 2005 13:08:02 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <42A9AA4B.10179.5BB929B@localhost>
	<42A9B149.14416.5D6E3B6@localhost>
Message-ID: <uzmtykuml.fsf@boost-consulting.com>

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

> On 10 Jun 2005 at 14:57, Niall Douglas wrote:
>
>> How well does BPL handle Py_Clear() being called on a wrapped object
>> instance when there are still plenty of referants around? What happens
>> if something tries to access the wrapped object instance after it has
>> been cleared? Does it get None, or does it crash?
>
> Actually ignore this question. However, I have another:
>
> How do you absolutely ensure a BPL wrapped object ceases to exist? In 
> other words, if python code has ten references to a BPL wrapped 
> object and I want that object to die immediately, therefore I would 
> have to ensure either (a) the BPL wrapped object becomes a zombie or 
> (b) each and every reference to that object is set to None.
>
> The latter sounds more appealing. I'm assuming I'd have to walk some 
> table in Python?

There is no known mechanism for the latter.

The former is easy: make sure the object is held by auto_ptr<T>, and pass
the object to a function accepting an auto_ptr<T>.

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



From js.nospam at wolke7.net  Fri Jun 10 22:00:42 2005
From: js.nospam at wolke7.net (=?ISO-8859-1?Q?=22Jarno_Sepp=E4nen=22?=)
Date: Fri, 10 Jun 2005 22:00:42 +0200 (MEST)
Subject: [C++-sig] Custodian & ward
Message-ID: <12370.1118433642@www40.gmx.net>

Hi,

Niall asked:
> ... and each FXWindow instance maintains a list of its children, and
> deletes its children when it gets deleted, then how do I apply 
> custodian & ward to ensure that when the parent instance is deleted, 
> python knows not to delete the children?

I've experienced the same problems when writing wrappers for LLVM.  My
conclusion is that BPL doesn't obey with_custodian_and_ward and/or
return_value_policy in case of constructors.  This is what I think should
work, but eventually this crashes in a double delete:

struct P;
struct C {
    explicit C(P& parent); // transfers ownership of this to parent
};
BOOST_PYTHON_MODULE(init_policy) {
    class_<C, boost::noncopyable>
        ("C", init<P&>()
         [with_custodian_and_ward<2, 1,
              return_value_policy<reference_existing_object> >()]);
}

I've attached a compiling example of the crash, and how to work around by
using a factory function.

BR, Jarno

-- 
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: init_policy.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050610/a9da5e5d/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_init_policy.py
Type: text/x-python
Size: 607 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050610/a9da5e5d/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 499 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050610/a9da5e5d/attachment-0001.py>

From hopper at omnifarious.org  Fri Jun 10 23:26:09 2005
From: hopper at omnifarious.org (Eric Hopper)
Date: Fri, 10 Jun 2005 14:26:09 -0700
Subject: [C++-sig] Python string -> const char * + size_t
Message-ID: <20050610212609.GA5773@omnifarious.org>

I'm trying to connect a hash function written in C++ to Python.  This
function will be processing a ton of data.  In Python, it's quite
natural to store random data in a string.  It's my impression that when
boost::python converts that string to a ::std::string it makes a copy of
it.  For this application, that will add a significant amount of CPU to
the time for processing the data, and that's important.

I would like instead to pass in pointers that point into the internal
data structure that Python is storing the string in.  The hash function
is only going to read it and munge it a bit, so as long as the data
remains around for the duration of the call, it's not a problem.

I want to somehow pass a Python string to an interface something like:

class Something {
 public:
   void hash_data(const char *data, size_t datalen);
};

What is the easiest and cleanest way to make this happen using
boost::python?

I'm willing to write a wrapper that has a slightly different (and
possibly boost::python specific) interface as long as the wrapper sucks
up very little CPU time.

I do want to manipulate Something objects in other ways in the Python
interpreter.

Thanks,
-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper at omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050610/85eb8562/attachment.pgp>

From dave at boost-consulting.com  Sat Jun 11 07:49:48 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 11 Jun 2005 01:49:48 -0400
Subject: [C++-sig] Custodian & ward
References: <12370.1118433642@www40.gmx.net>
Message-ID: <ubr6dh283.fsf@boost-consulting.com>

"Jarno Sepp?nen" <js.nospam at wolke7.net> writes:

> Hi,
>
> Niall asked:
>> ... and each FXWindow instance maintains a list of its children, and
>> deletes its children when it gets deleted, then how do I apply 
>> custodian & ward to ensure that when the parent instance is deleted, 
>> python knows not to delete the children?
>
> I've experienced the same problems when writing wrappers for LLVM.  My
> conclusion is that BPL doesn't obey with_custodian_and_ward and/or
> return_value_policy in case of constructors.  

What effect do you expect the return_value_policy to have?
The ctor is returning a brand new object every time.

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



From dave at boost-consulting.com  Sat Jun 11 07:53:54 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 11 Jun 2005 01:53:54 -0400
Subject: [C++-sig] Python string -> const char * + size_t
References: <20050610212609.GA5773@omnifarious.org>
Message-ID: <u64wlh219.fsf@boost-consulting.com>

Eric Hopper <hopper at omnifarious.org> writes:

> I'm trying to connect a hash function written in C++ to Python.  This
> function will be processing a ton of data.  In Python, it's quite
> natural to store random data in a string.  It's my impression that when
> boost::python converts that string to a ::std::string it makes a copy of
> it.  

Of course Python and C++ can't share that representation.

> For this application, that will add a significant amount of CPU to
> the time for processing the data, and that's important.

So convert to a char const* instead.

> I would like instead to pass in pointers that point into the internal
> data structure that Python is storing the string in.  

That's what converting to char const* will do.

> The hash function
> is only going to read it and munge it a bit, so as long as the data
> remains around for the duration of the call, it's not a problem.
>
> I want to somehow pass a Python string to an interface something like:
>
> class Something {
>  public:
>    void hash_data(const char *data, size_t datalen);
> };
>
> What is the easiest and cleanest way to make this happen using
> boost::python?

Well, if you need the length it's a little harder.  Make a thin
wrapper function that accepts a boost::python::str object x, then use 

        x.ptr()

to get the PyObject* and use the Python/C API to get the pointer and length.

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



From js.nospam at wolke7.net  Sat Jun 11 08:47:54 2005
From: js.nospam at wolke7.net (=?ISO-8859-1?Q?=22Jarno_Sepp=E4nen=22?=)
Date: Sat, 11 Jun 2005 08:47:54 +0200 (MEST)
Subject: [C++-sig] Custodian & ward
References: <ubr6dh283.fsf@boost-consulting.com>
Message-ID: <12704.1118472474@www18.gmx.net>

Hi,

David writes:

> "Jarno Sepp?nen" <js.nospam at wolke7.net> writes:
> 
> > Niall asked:
> >> ... and each FXWindow instance maintains a list of its children, and
> >> deletes its children when it gets deleted, then how do I apply 
> >> custodian & ward to ensure that when the parent instance is deleted, 
> >> python knows not to delete the children?
> >
> > I've experienced the same problems when writing wrappers for LLVM.  My
> > conclusion is that BPL doesn't obey with_custodian_and_ward and/or
> > return_value_policy in case of constructors.  
> 
> What effect do you expect the return_value_policy to have?
> The ctor is returning a brand new object every time.

My purpose in using return_value_policy<reference_existing_object> for the
constructor is to make BPL not delete the newly constructed object, because
that will cause a double delete.

The LLVM library (and Niall's FXWindow library IIUC) semantics are that the
child object constructor transfers the ownership of itself to the parent,
and the child object must _not_ be deleted, because the parent owns it.  At
the same time the semantics guarantee that the child object is not deleted
before the parent is, i.e., use for with_custodian_and_ward, no?

Cheers, Jarno

-- 
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++


From s_sourceforge at nedprod.com  Sat Jun 11 16:03:26 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Jun 2005 15:03:26 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <uzmtykuml.fsf@boost-consulting.com>
Message-ID: <42AAFD3E.18784.AE78E9C@localhost>

On 10 Jun 2005 at 13:08, David Abrahams wrote:

> > How do you absolutely ensure a BPL wrapped object ceases to exist?
> > In other words, if python code has ten references to a BPL wrapped
> > object and I want that object to die immediately, therefore I would
> > have to ensure either (a) the BPL wrapped object becomes a zombie or
> > (b) each and every reference to that object is set to None.
> >
> > The latter sounds more appealing. I'm assuming I'd have to walk some
> > table in Python?
> 
> There is no known mechanism for the latter.
> 
> The former is easy: make sure the object is held by auto_ptr<T>, and
> pass the object to a function accepting an auto_ptr<T>.

The latter could probably be made to work if given enough time, but 
it would require a substantial amount of alterations to pyste to 
achieve it - and even then, I still can see issues which may arise.

Hence I must go the quick & dirty route. I was thinking of throwing a 
dummy exception, reading the traceback & stack frame info and 
recursing up through the globals() in each deleting any references to 
my object. This would surely do it for the current interpreter at 
least?

Cheers,
Niall





From s_sourceforge at nedprod.com  Sat Jun 11 16:03:25 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Jun 2005 15:03:25 +0100
Subject: [C++-sig] Custodian & ward
In-Reply-To: <12704.1118472474@www18.gmx.net>
Message-ID: <42AAFD3D.14160.AE78CE6@localhost>

On 11 Jun 2005 at 8:47, Jarno Sepp?nen wrote:

> The LLVM library (and Niall's FXWindow library IIUC) semantics are
> that the child object constructor transfers the ownership of itself to
> the parent, and the child object must _not_ be deleted, because the
> parent owns it.  At the same time the semantics guarantee that the
> child object is not deleted before the parent is, i.e., use for
> with_custodian_and_ward, no?

I did get custodian & ward to prevent *python* deleting either the 
parent before the child or the child before the parent, but that's 
not what I want to do. I *fully* want python to be able to delete 
either at any time with immediate effect so it became clear that 
custodian & ward is of no use to me.

What I do have a problem with is the C++ library deleting stuff 
without telling python. There isn't much I can do to stop that, but I 
can tell python somehow to permanently forget about those instances.

Cheers,
Niall





From faheem at email.unc.edu  Sun Jun 12 03:04:40 2005
From: faheem at email.unc.edu (Faheem Mitha)
Date: Sun, 12 Jun 2005 01:04:40 +0000 (UTC)
Subject: [C++-sig] wrapping a Singleton class
Message-ID: <slrndan2pr.614.faheem@Chrestomanci.home.earth>

Hi,

Consider the following Singleton class, which seems to have problems
being wrapped by Boost.Python.

********************************************************
class lustate
{
public:
  static lustate& instance(const vector<double>& lower, 
			   const vector<double>& upper)
  {
    static lustate lu(lower, upper);
    return lu;
  };
  vector<double> l;
  vector<double> u;
private:
  lustate(const vector<double>& _l, const vector<double>& _u): 
    l(_l), u(_u) {};
};
****************************************************************

I tried

BOOST_PYTHON_MODULE(mg)
{
  boost::python::class_<lustate>("lustate", boost::python::no_init)
  // boost::python::class_<lustate>("lustate")
    .staticmethod("instance")
    ;
}

This compiles without error, but on importing I get

*******************************************************************************
In [1]:import mg
---------------------------------------------------------------------------
exceptions.KeyError                          Traceback (most recent call last)

/home/faheem/co/paper/mg/c++/<console>

KeyError: 'instance'
********************************************************************************

I think that static member functions still require the corresponding
class to be instantiated in Python, since it is invoked like a regular
bound method, though the values obtained are of course the same for
every instantiation. This understanding is based on Googling + the
example files staticmethod.cpp & staticmethod.py.

In other words, it doesn't have the equivalent of 

lustate::instance

at the Python level. Since the constructor is private, it cannot
instantiate the class. Hence, it is stuck.

Is this an accurate description of the situation? I'm not sure what
the error means, though.

                                                              Faheem.




From dave at boost-consulting.com  Sun Jun 12 18:05:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 12 Jun 2005 12:05:45 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <uzmtykuml.fsf@boost-consulting.com>
	<42AAFD3E.18784.AE78E9C@localhost>
Message-ID: <uwtozd0h2.fsf@boost-consulting.com>

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

> On 10 Jun 2005 at 13:08, David Abrahams wrote:
>
>> > How do you absolutely ensure a BPL wrapped object ceases to exist?
>> > In other words, if python code has ten references to a BPL wrapped
>> > object and I want that object to die immediately, therefore I would
>> > have to ensure either (a) the BPL wrapped object becomes a zombie or
>> > (b) each and every reference to that object is set to None.
>> >
>> > The latter sounds more appealing. I'm assuming I'd have to walk some
>> > table in Python?
>> 
>> There is no known mechanism for the latter.
>> 
>> The former is easy: make sure the object is held by auto_ptr<T>, and
>> pass the object to a function accepting an auto_ptr<T>.
>
> The latter could probably be made to work if given enough time, but 
> it would require a substantial amount of alterations to pyste to 
> achieve it - and even then, I still can see issues which may arise.
>
> Hence I must go the quick & dirty route. I was thinking of throwing a 
> dummy exception, reading the traceback & stack frame info and 
> recursing up through the globals() in each deleting any references to 
> my object. This would surely do it for the current interpreter at 
> least?

No, there may be references hiding in other pythong objects and, for
that matter, in extension modules.

I don't see what advantage you gain from it either.  A variable or
attribute in Python has to be bound to *something*, be it None or a
zombie (which will act almost like None) or whatever.  You'll reclaim
a small amount of memory, but that's about it.

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



From dave at boost-consulting.com  Sun Jun 12 18:08:07 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 12 Jun 2005 12:08:07 -0400
Subject: [C++-sig] wrapping a Singleton class
References: <slrndan2pr.614.faheem@Chrestomanci.home.earth>
Message-ID: <uoeabd0d4.fsf@boost-consulting.com>

Faheem Mitha <faheem at email.unc.edu> writes:

> ********************************************************
> class lustate
> {
> public:
>   static lustate& instance(const vector<double>& lower, 
> 			   const vector<double>& upper)
>   {
>     static lustate lu(lower, upper);
>     return lu;
>   };
>   vector<double> l;
>   vector<double> u;
> private:
>   lustate(const vector<double>& _l, const vector<double>& _u): 
>     l(_l), u(_u) {};
> };
> ****************************************************************
>
> I tried
>
> BOOST_PYTHON_MODULE(mg)
> {
>   boost::python::class_<lustate>("lustate", boost::python::no_init)
>   // boost::python::class_<lustate>("lustate")

You're missing
      .def("instance", &lustate::instance)
right here.
>     .staticmethod("instance")
>     ;
> }

HTH,

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



From s_sourceforge at nedprod.com  Sun Jun 12 19:19:00 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 12 Jun 2005 18:19:00 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <uwtozd0h2.fsf@boost-consulting.com>
Message-ID: <42AC7C94.24450.10C0FCA6@localhost>

On 12 Jun 2005 at 12:05, David Abrahams wrote:

> >> The former is easy: make sure the object is held by auto_ptr<T>,
> >> and pass the object to a function accepting an auto_ptr<T>.
> >
> > The latter could probably be made to work if given enough time, but
> > it would require a substantial amount of alterations to pyste to
> > achieve it - and even then, I still can see issues which may arise.
> >
> > Hence I must go the quick & dirty route. I was thinking of throwing
> > a dummy exception, reading the traceback & stack frame info and
> > recursing up through the globals() in each deleting any references
> > to my object. This would surely do it for the current interpreter at
> > least?
> 
> No, there may be references hiding in other pythong objects and, for
> that matter, in extension modules.
> 
> I don't see what advantage you gain from it either.  A variable or
> attribute in Python has to be bound to *something*, be it None or a
> zombie (which will act almost like None) or whatever.  You'll reclaim
> a small amount of memory, but that's about it.

As it turned out, pyste already supported auto_ptr. And it also seems 
that BPL treats auto_ptr quite sensibly, so it "just works". Wish I 
had known as it would have saved me a day's work :(

My current problem is when running through virtual function wrappers 
in that call_method<> tries converting an unsigned int * to an 
unsigned int which I don't want. I tried putting ptr() round it like 
this:

    void setData(FX::FXColor* p0, FX::FXuint p1) {
        call_method< void >(py_self, "setData", ptr(p0), p1);
    }

(here FXColor is a typedef for unsigned int)

... but BPL won't take pointers to integral types in ptr(), and thus 
I can't see how to pass the pointer as-is.

Why doesn't BPL's ptr() accept pointers to integral types?

Cheers,
Niall





From ult at mundane.org  Sun Jun 12 19:49:52 2005
From: ult at mundane.org (Ult Mundane)
Date: Sun, 12 Jun 2005 13:49:52 -0400
Subject: [C++-sig] Pyste for class with private destructor
In-Reply-To: <42AC7C94.24450.10C0FCA6@localhost>
References: <42AC7C94.24450.10C0FCA6@localhost>
Message-ID: <42AC75C0.5070006@mundane.org>

Hi there,

I'm just learning to use Boost.Python and Pyste, so I thank you for your 
patience. I just upgraded Pyste to the current CVS sources (from Boost 
1.32).

In 1.32, Pyste would not export a copy constructor if the class didn't 
declare one, even though the compiler would create an "artificial" copy 
constructor. Using the current CVS version, Pyste will export the copy 
constructor. This solves the problem I was having with a simple class 
that I wanted to be able to copy in Python.

However, it uncovered a new issue for me. In the case that the class's 
constructors or destructor are private, exporting the class causes an 
error in value_holder.hpp when compiling the generated cpp file.

My intention is to create a class that is instantiated on the c++ side, 
and referenced (but never copied or destroyed) on the Python side. 
Perhaps I'm using the wrong approach. Should I be using a shared_ptr, or 
wrapping the class?

Thanks,

Ult


From dave at boost-consulting.com  Sun Jun 12 21:25:21 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 12 Jun 2005 15:25:21 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <uwtozd0h2.fsf@boost-consulting.com>
	<42AC7C94.24450.10C0FCA6@localhost>
Message-ID: <ubr6bbcny.fsf@boost-consulting.com>

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

> On 12 Jun 2005 at 12:05, David Abrahams wrote:
>
>> >> The former is easy: make sure the object is held by auto_ptr<T>,
>> >> and pass the object to a function accepting an auto_ptr<T>.
>> >
>> > The latter could probably be made to work if given enough time, but
>> > it would require a substantial amount of alterations to pyste to
>> > achieve it - and even then, I still can see issues which may arise.
>> >
>> > Hence I must go the quick & dirty route. I was thinking of throwing
>> > a dummy exception, reading the traceback & stack frame info and
>> > recursing up through the globals() in each deleting any references
>> > to my object. This would surely do it for the current interpreter at
>> > least?
>> 
>> No, there may be references hiding in other pythong objects and, for
>> that matter, in extension modules.
>> 
>> I don't see what advantage you gain from it either.  A variable or
>> attribute in Python has to be bound to *something*, be it None or a
>> zombie (which will act almost like None) or whatever.  You'll reclaim
>> a small amount of memory, but that's about it.
>
> As it turned out, pyste already supported auto_ptr. And it also seems 
> that BPL treats auto_ptr quite sensibly, so it "just works". Wish I 
> had known as it would have saved me a day's work :(

You could have taken my word for it :)

> My current problem is when running through virtual function wrappers 
> in that call_method<> tries converting an unsigned int * to an 
> unsigned int which I don't want. I tried putting ptr() round it like 
> this:
>
>     void setData(FX::FXColor* p0, FX::FXuint p1) {
>         call_method< void >(py_self, "setData", ptr(p0), p1);
>     }
>
> (here FXColor is a typedef for unsigned int)
>
> ... but BPL won't take pointers to integral types in ptr(), and thus
> I can't see how to pass the pointer as-is.
>
>
> Why doesn't BPL's ptr() accept pointers to integral types?

Think about how you would implement such a thing.  What would a
an overriden virtual function written in Python see?

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



From dave at boost-consulting.com  Sun Jun 12 21:27:29 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 12 Jun 2005 15:27:29 -0400
Subject: [C++-sig] Pyste for class with private destructor
References: <42AC7C94.24450.10C0FCA6@localhost> <42AC75C0.5070006@mundane.org>
Message-ID: <u64wjbcke.fsf@boost-consulting.com>

Ult Mundane <ult at mundane.org> writes:

> Hi there,
>
> I'm just learning to use Boost.Python and Pyste, so I thank you for your 
> patience. I just upgraded Pyste to the current CVS sources (from Boost 
> 1.32).
>
> In 1.32, Pyste would not export a copy constructor if the class didn't 
> declare one, even though the compiler would create an "artificial" copy 
> constructor. Using the current CVS version, Pyste will export the copy 
> constructor. This solves the problem I was having with a simple class 
> that I wanted to be able to copy in Python.
>
> However, it uncovered a new issue for me. In the case that the class's 
> constructors or destructor are private, exporting the class causes an 
> error in value_holder.hpp when compiling the generated cpp file.
>
> My intention is to create a class that is instantiated on the c++ side, 
> and referenced (but never copied or destroyed) on the Python side. 
> Perhaps I'm using the wrong approach. Should I be using a shared_ptr, or 
> wrapping the class?

Did you read the thread entitled "wrapping a Singleton class" from
today?  Does following that example help?

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



From s_sourceforge at nedprod.com  Mon Jun 13 02:40:38 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 13 Jun 2005 01:40:38 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <ubr6bbcny.fsf@boost-consulting.com>
Message-ID: <42ACE416.9292.12554DB7@localhost>

On 12 Jun 2005 at 15:25, David Abrahams wrote:

> > As it turned out, pyste already supported auto_ptr. And it also
> > seems that BPL treats auto_ptr quite sensibly, so it "just works".
> > Wish I had known as it would have saved me a day's work :(
> 
> You could have taken my word for it :)

Unfortunately Dave what's easy to you is not so easy for the rest of 
us mere mortals. You have previously told me to do things which I am 
sure are very easy for you, but took me days of head scratching. 
Hence you see my hesitation!

> > My current problem is when running through virtual function wrappers
> > in that call_method<> tries converting an unsigned int * to an
> > unsigned int which I don't want. I tried putting ptr() round it like
> > this:
> >
> >     void setData(FX::FXColor* p0, FX::FXuint p1) {
> >         call_method< void >(py_self, "setData", ptr(p0), p1);
> >     }
> >
> > (here FXColor is a typedef for unsigned int)
> >
> > ... but BPL won't take pointers to integral types in ptr(), and thus
> > I can't see how to pass the pointer as-is.
> >
> >
> > Why doesn't BPL's ptr() accept pointers to integral types?
> 
> Think about how you would implement such a thing.  What would a
> an overriden virtual function written in Python see?

A single item of whatever type eg; long * would mean the python code 
sees a python integer.

Sure, it's not very useful to the python code itself. However, the 
python code could go call some C which produces an iterable list from 
the pointer which saves having to pack and unpack such a list through 
each and every virtual function invocation.

Cheers,
Niall





From dave at boost-consulting.com  Mon Jun 13 14:40:54 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Jun 2005 08:40:54 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <ubr6bbcny.fsf@boost-consulting.com>
	<42ACE416.9292.12554DB7@localhost>
Message-ID: <u1x768m5l.fsf@boost-consulting.com>

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

> On 12 Jun 2005 at 15:25, David Abrahams wrote:
>
>> > As it turned out, pyste already supported auto_ptr. And it also
>> > seems that BPL treats auto_ptr quite sensibly, so it "just works".
>> > Wish I had known as it would have saved me a day's work :(
>> 
>> You could have taken my word for it :)
>
> Unfortunately Dave what's easy to you is not so easy for the rest of 
> us mere mortals. You have previously told me to do things which I am 
> sure are very easy for you, but took me days of head scratching. 
> Hence you see my hesitation!
>
>> > My current problem is when running through virtual function wrappers
>> > in that call_method<> tries converting an unsigned int * to an
>> > unsigned int which I don't want. I tried putting ptr() round it like
>> > this:
>> >
>> >     void setData(FX::FXColor* p0, FX::FXuint p1) {
>> >         call_method< void >(py_self, "setData", ptr(p0), p1);
>> >     }
>> >
>> > (here FXColor is a typedef for unsigned int)
>> >
>> > ... but BPL won't take pointers to integral types in ptr(), and thus
>> > I can't see how to pass the pointer as-is.
>> >
>> >
>> > Why doesn't BPL's ptr() accept pointers to integral types?
>> 
>> Think about how you would implement such a thing.  What would a
>> an overriden virtual function written in Python see?
>
> A single item of whatever type eg; long * would mean the python code 
> sees a python integer.

I'm confused now.  If you pass an int* without wrapping it in ptr()
that's exactly what happens, right?

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



From ult at mundane.org  Mon Jun 13 15:53:52 2005
From: ult at mundane.org (Ult Mundane)
Date: Mon, 13 Jun 2005 09:53:52 -0400
Subject: [C++-sig] Pyste for class with private destructor
In-Reply-To: <u64wjbcke.fsf@boost-consulting.com>
References: <42AC7C94.24450.10C0FCA6@localhost> <42AC75C0.5070006@mundane.org>
	<u64wjbcke.fsf@boost-consulting.com>
Message-ID: <42AD8FF0.9030204@mundane.org>

I think I understand what's going on a bit better now. The source of the 
problem seems to be that Pyste uses the value_holder template as long as 
there are any public constructors (including "artificial" ones created 
by the compiler), regardless of whether there is a public destructor. I 
guess what should happen is that if the destructor is private, Pyste 
should declare the class with no_init, because it will never compile.

It isn't a big deal for a simple class, because (as in the example 
below) you can just declare all the artificial constructors as private. 
But if the class contains data members which can't be constructed, an 
empty copy constructor won't compile.

What do Pyste users do for situations like this where Pyste is getting 
in the way? Just use Boost.Python directly for that class? Insert code 
using module_code()? Patch Pyste?

Thanks,

Ult


Here's some code to make it more concrete:

# --- Ah.hpp ---

#ifndef AH_HPP
#define AH_HPP

#include <string>
#include <vector>

class Hum
{
   public:
     std::string mantra;

   private:
     Hum();
     /* If I add this line, it works fine; Pyste says no_init and
      * value_holder doesn't complain. But if I have a data member
      * which can't be copied, I'm out of luck.
      */
//    Hum(Hum const & rhs) {};
     Hum(char const * mantra);
     ~Hum();

     friend class Ah;
};

class Ah
{
   public:
     Ah();
     ~Ah();

     void  addHum(char const * mantra);

     std::vector<Hum *> humlist;
};

#endif

# --- Ah.pyste ---

Ah = Class("Ah", "Ah.hpp")
Hum = Class("Hum", "Ah.hpp")
set_policy(Ah.addHum, return_internal_reference())

Include("vector")
module_code('''
   class_<std::vector<Hum *> >("vector_HumRef")
       .def("__iter__", iterator<std::vector<Hum *>,
           return_internal_reference<> >())
       ;
''')

# --- _Ah.cpp (produced from Ah.pyste) ---

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

// Includes 
====================================================================
#include <Ah.hpp>
#include <vector>

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

// Module 
======================================================================
void Export_pystebox_src_pyste_Ah()
{
     class_< Ah >("Ah", init<  >())
         .def(init< const Ah& >())
         .def_readwrite("humlist", &Ah::humlist)
         .def("addHum", &Ah::addHum, return_internal_reference< 1 >())
     ;

     class_< Hum >("Hum", init< const Hum& >())
         .def_readwrite("mantra", &Hum::mantra)
     ;


   class_<std::vector<Hum *> >("vector_HumRef")
       .def("__iter__", iterator<std::vector<Hum *>,
           return_internal_reference<> >())
       ;
}

# --- Errors compiling _Ah.cpp ---
pystebox/src/pyste/Ah.hpp: In constructor
 
`boost::python::objects::value_holder<Value>::value_holder(PyObject*, A0)
    [with A0 = boost::python::objects::reference_to_value<const Hum&>, 
Value =
    Hum]':
libs/boost-1.32.0/include/boost/python/object/make_holder.hpp:83: 
instantiated from `static void 
boost::python::objects::make_holder<1>::apply<Holder, 
ArgList>::execute(PyObject*, 
boost::mpl::deref<boost::mpl::begin<ArgList>::type>::type) [with Holder 
= boost::python::objects::value_holder<Hum>, ArgList = 
boost::mpl::vector1<const Hum&>]'

# [... a few pages of "instantiated from" lines like that one ...]

linux-i686-pystebox/pystebox/pystebox/_Ah.cpp:22:   instantiated from here
pystebox/src/pyste/Ah.hpp:22: `Hum::~Hum()' is private
libs/boost-1.32.0/include/boost/python/object/value_holder.hpp:133: 
within this
    context



David Abrahams wrote:
> Ult Mundane <ult at mundane.org> writes:
> 
> 
>>Hi there,
>>
>>I'm just learning to use Boost.Python and Pyste, so I thank you for your 
>>patience. I just upgraded Pyste to the current CVS sources (from Boost 
>>1.32).
>>
>>In 1.32, Pyste would not export a copy constructor if the class didn't 
>>declare one, even though the compiler would create an "artificial" copy 
>>constructor. Using the current CVS version, Pyste will export the copy 
>>constructor. This solves the problem I was having with a simple class 
>>that I wanted to be able to copy in Python.
>>
>>However, it uncovered a new issue for me. In the case that the class's 
>>constructors or destructor are private, exporting the class causes an 
>>error in value_holder.hpp when compiling the generated cpp file.
>>
>>My intention is to create a class that is instantiated on the c++ side, 
>>and referenced (but never copied or destroyed) on the Python side. 
>>Perhaps I'm using the wrong approach. Should I be using a shared_ptr, or 
>>wrapping the class?
> 
> 
> Did you read the thread entitled "wrapping a Singleton class" from
> today?  Does following that example help?
> 


From nicodemus at esss.com.br  Mon Jun 13 23:27:10 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 13 Jun 2005 19:27:10 -0200
Subject: [C++-sig] Improved pyste
In-Reply-To: <7465b61705060822531d375f23@mail.gmail.com>
References: <28794-74921@sneakemail.com>	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>	<42A63125.6154.2FC5ABE@localhost>	<7465b61705060723025e2d4dff@mail.gmail.com>	<uzmu1htlh.fsf@boost-consulting.com>	<uacm06ckd.fsf@boost-consulting.com>
	<7465b61705060822531d375f23@mail.gmail.com>
Message-ID: <42ADFA2E.70805@esss.com.br>

Hi Roman,

(sorry about the late reply, I've been busy)

Roman Yakovenko wrote:

>On 6/8/05, David Abrahams <dave at boost-consulting.com> wrote:
>
>> <>David Abrahams <dave at boost-consulting.com> writes:
>> ...Can you explain what your system offers, or will offer, that Pyste 
>> cannot?
>>
>> 2. Extendability: If I need a custom way to export something it could
>> not be easily done with pyste. Example: there are a lot of projects
>> that use java-doc like comments within source. Using py++ it is simple
>> to create new class that derives from one of build in classes and
>> implement logic of injection of documentation into python wrapper. An
>> other example is - programmer can define call policies within special
>> comment near function declaration and then to read it during code
>> creation process
>

Yes, that is a weakness of Pyste. It wasn't designed to be extensible by 
the user.

>> <>3. Flexibility: May be I wrong but there is no easy way in Pyste to
>> exclude functions
>> that takes as argument some specific type. For example: I have classes
>> that has functions that deals with XML using xercesc library. I want
>> to exclude all those functions.
>

Yes, not right now. One of the planned implementation is to make the 
objects returned by the various Class, Function, etc, be the actual 
*declaration* objects. This way you could easily do that kind of 
manipulation.

>> <>4. py++ could be extended to generate python code. Consider next 
>> situation:
>>
>> namespace top{
>> namepsace x1{...}
>> namepsace x2{...}
>> }
>>
>> In my opinion the resulting could should be package top that has to
>> modules or sub packages x1 and x2. py++ has all data in order to
>> implement this.
>>
>> I think there is no easy way to do it in Pyste. Am I wrong?
>

No, you're right. One would have to do it by hand after the code was 
generated.

>> <>5. There is full separation between next things:
>> 1. what should be exported and in what order
>> 2. how it should be exported
>> 3. where and how to write code in files
>>
>> 6. As I mentioned in my previous post: there are a few projects that
>> use similar way to expose C++ to different languages. One of them is
>> yours: langbinding. I think it will be pretty easy to support code
>> generation for this library too. ( This statement still should be
>> checked by reality )
>

Cool!

>> <>
>> Before starting to write code for py++, I checked what could be
>> improved in current Pyste. The first obvious thing was parsing GCC-XML
>> generated file. I created new python package called pygccxml. After
>> this, I checked how pygccxml could be integrated with Pyste. It was
>> too difficult. So I dropped this idea. Also I do had small coversation
>> with Nicodemus. And in one mail he told me that is going to be next
>> version of Pyste. It was 6 months ago. Nothing happen till now. So I
>> decided to write next version of Pyste.
>

Yes, I plan to eventually drop my code regarding parsing GCCXML in favor 
of pygccxml, but really have not found the time to do it yet.

>> <>That's all. I hope in 2 or 4 month I will have first version, that
>> could be released.
>

Cool. But I think the community would benefit better if we joined our 
efforts somehow. Perhaps we could merge the strengths of both tools into 
one project?

Regards,
Nicodemus.


From nicodemus at esss.com.br  Mon Jun 13 23:37:20 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 13 Jun 2005 19:37:20 -0200
Subject: [C++-sig] Pyste for class with private destructor
In-Reply-To: <42AD8FF0.9030204@mundane.org>
References: <42AC7C94.24450.10C0FCA6@localhost>
	<42AC75C0.5070006@mundane.org>	<u64wjbcke.fsf@boost-consulting.com>
	<42AD8FF0.9030204@mundane.org>
Message-ID: <42ADFC90.3040506@esss.com.br>

Hi Ult,

Ult Mundane wrote:

>What do Pyste users do for situations like this where Pyste is getting 
>in the way? Just use Boost.Python directly for that class? Insert code 
>using module_code()? Patch Pyste?
>  
>

Normally people patch Pyste and send it to me, so I can integrate it in 
CVS. I suggest you try that ;)

Regards,
Nicodemus.


From seefeld at sympatico.ca  Tue Jun 14 02:12:45 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 13 Jun 2005 20:12:45 -0400
Subject: [C++-sig] Improved pyste
In-Reply-To: <7465b61705060822531d375f23@mail.gmail.com>
References: <28794-74921@sneakemail.com>	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>	<42A63125.6154.2FC5ABE@localhost>	<7465b61705060723025e2d4dff@mail.gmail.com>	<uzmu1htlh.fsf@boost-consulting.com>	<uacm06ckd.fsf@boost-consulting.com>
	<7465b61705060822531d375f23@mail.gmail.com>
Message-ID: <42AE20FD.9090204@sympatico.ca>

Roman Yakovenko wrote:

> 6. As I mentioned in my previous post: there are a few projects that
> use similar way to expose C++ to different languages. One of them is
> yours: langbinding. I think it will be pretty easy to support code
> generation for this library too. ( This statement still should be
> checked by reality )

By the way, did you have a look into synopsis (http://synopsis.fresco.org) ?
It contains a C++ parser and its goal is to provide a code introspection
framework particularly useful to write source-to-source translators with.
I think, as a first step it would be an interesting project to replace
gccxml by synopsis as a parser backend in pyste, and then gradually
make pyste extensible much the same way synopsis already is extensible,
i.e. allow user modules to override specific code generation rules.

What do you think ?

Regards,
		Stefan


From s_sourceforge at nedprod.com  Mon Jun 13 18:30:49 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 13 Jun 2005 17:30:49 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <u1x768m5l.fsf@boost-consulting.com>
Message-ID: <42ADC2C9.1397.1588052@localhost>

On 13 Jun 2005 at 8:40, David Abrahams wrote:

> >> > Why doesn't BPL's ptr() accept pointers to integral types?
> >> 
> >> Think about how you would implement such a thing.  What would a an
> >> overriden virtual function written in Python see?
> >
> > A single item of whatever type eg; long * would mean the python code
> > sees a python integer.
> 
> I'm confused now.  If you pass an int* without wrapping it in ptr()
> that's exactly what happens, right?

I don't know about int, but unsigned int * yields a runtime error of 
no to-python converter for unsigned int.

Cheers,
Niall





From roman.yakovenko at gmail.com  Tue Jun 14 06:41:19 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 14 Jun 2005 07:41:19 +0300
Subject: [C++-sig] Improved pyste
In-Reply-To: <42ADFA2E.70805@esss.com.br>
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
	<uzmu1htlh.fsf@boost-consulting.com>
	<uacm06ckd.fsf@boost-consulting.com>
	<7465b61705060822531d375f23@mail.gmail.com>
	<42ADFA2E.70805@esss.com.br>
Message-ID: <7465b6170506132141702004da@mail.gmail.com>

On 6/14/05, Nicodemus <nicodemus at esss.com.br> wrote:
> Hi Roman,
> 
> (sorry about the late reply, I've been busy)
> 
> Roman Yakovenko wrote:
> 
> >On 6/8/05, David Abrahams <dave at boost-consulting.com> wrote:
> >
> >> <>David Abrahams <dave at boost-consulting.com> writes:
> >> ...Can you explain what your system offers, or will offer, that Pyste
> >> cannot?
> >>
> >> 2. Extendability: If I need a custom way to export something it could
> >> not be easily done with pyste. Example: there are a lot of projects
> >> that use java-doc like comments within source. Using py++ it is simple
> >> to create new class that derives from one of build in classes and
> >> implement logic of injection of documentation into python wrapper. An
> >> other example is - programmer can define call policies within special
> >> comment near function declaration and then to read it during code
> >> creation process
> >
> 
> Yes, that is a weakness of Pyste. It wasn't designed to be extensible by
> the user.

For me it was serious weekness in one project within a company I work.
 
> >> <>3. Flexibility: May be I wrong but there is no easy way in Pyste to
> >> exclude functions
> >> that takes as argument some specific type. For example: I have classes
> >> that has functions that deals with XML using xercesc library. I want
> >> to exclude all those functions.
> >
> 
> Yes, not right now. One of the planned implementation is to make the
> objects returned by the various Class, Function, etc, be the actual
> *declaration* objects. This way you could easily do that kind of
> manipulation.

Already done in py++

> >> <>4. py++ could be extended to generate python code. Consider next
> >> situation:
> >>
> >> namespace top{
> >> namepsace x1{...}
> >> namepsace x2{...}
> >> }
> >>
> >> In my opinion the resulting could should be package top that has to
> >> modules or sub packages x1 and x2. py++ has all data in order to
> >> implement this.
> >>
> >> I think there is no easy way to do it in Pyste. Am I wrong?
> >
> 
> No, you're right. One would have to do it by hand after the code was
> generated.
> 
> >> <>5. There is full separation between next things:
> >> 1. what should be exported and in what order
> >> 2. how it should be exported
> >> 3. where and how to write code in files
> >>
> >> 6. As I mentioned in my previous post: there are a few projects that
> >> use similar way to expose C++ to different languages. One of them is
> >> yours: langbinding. I think it will be pretty easy to support code
> >> generation for this library too. ( This statement still should be
> >> checked by reality )
> >
> 
> Cool!
Do you know what is cool? GUI - I think it is possible to write GUI
editor for py++.

> >> <>
> >> Before starting to write code for py++, I checked what could be
> >> improved in current Pyste. The first obvious thing was parsing GCC-XML
> >> generated file. I created new python package called pygccxml. After
> >> this, I checked how pygccxml could be integrated with Pyste. It was
> >> too difficult. So I dropped this idea. Also I do had small coversation
> >> with Nicodemus. And in one mail he told me that is going to be next
> >> version of Pyste. It was 6 months ago. Nothing happen till now. So I
> >> decided to write next version of Pyste.
> >
> 
> Yes, I plan to eventually drop my code regarding parsing GCCXML in favor
> of pygccxml, but really have not found the time to do it yet.

You don't have
 
> >> <>That's all. I hope in 2 or 4 month I will have first version, that
> >> could be released.
> >
> 
> Cool. But I think the community would benefit better if we joined our
> efforts somehow. Perhaps we could merge the strengths of both tools into
> one project?

The main reason for the first letter I wrote was to involve you and
others into building next version of code generration tool around
boost python library. So I am going to write a lot of documentation
about py++. I will post the message when it will be ready. This will
give us ability to compare both projects and to have the best parts of
them. If I was not clear then the answer to your question is yes. We
could merge our efforts and tools.

> Regards,
> Nicodemus.
> 

Roman


From roman.yakovenko at gmail.com  Tue Jun 14 06:52:01 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 14 Jun 2005 07:52:01 +0300
Subject: [C++-sig] Improved pyste
In-Reply-To: <42AE20FD.9090204@sympatico.ca>
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
	<uzmu1htlh.fsf@boost-consulting.com>
	<uacm06ckd.fsf@boost-consulting.com>
	<7465b61705060822531d375f23@mail.gmail.com>
	<42AE20FD.9090204@sympatico.ca>
Message-ID: <7465b617050613215266da6a41@mail.gmail.com>

On 6/14/05, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Roman Yakovenko wrote:
> 
> > 6. As I mentioned in my previous post: there are a few projects that
> > use similar way to expose C++ to different languages. One of them is
> > yours: langbinding. I think it will be pretty easy to support code
> > generation for this library too. ( This statement still should be
> > checked by reality )
> 
> By the way, did you have a look into synopsis (http://synopsis.fresco.org) ?
> It contains a C++ parser and its goal is to provide a code introspection
> framework particularly useful to write source-to-source translators with.
> I think, as a first step it would be an interesting project to replace
> gccxml by synopsis as a parser backend in pyste, and then gradually
> make pyste extensible much the same way synopsis already is extensible,
> i.e. allow user modules to override specific code generation rules.
> 
> What do you think ?

I am aware about this poject. If I understand right, one of the
reasons Pyste has success is it's ability to read C++ code with 100%
exectness. I don't know whether synopsis is able to do the same.
pygccxml backend could be changed. This is pretty easy. I tried to
extend it using VisualStudio Intellicense API. An other backend is
could be based on *bsc ( browse source code ) files.

> Regards,
>                 Stefan
> 

Roman


From pierre.barbier at cirad.fr  Tue Jun 14 10:57:22 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Tue, 14 Jun 2005 10:57:22 +0200
Subject: [C++-sig] Any work for cyclic garbage collection support ?
Message-ID: <42AE9BF2.9010306@cirad.fr>

Hello,

I had the problem some years ago and did not succeed in using the cyclic
garbage collector of Python with BPL objects. Now, I read a little more
about it and I wonder if it is possible to add such support without many
changes in BPL !

The fact is, the allocation is different, you have to initialise the
structure of the class in the right way and you have to define some
"traversal" function being able to enumerate all the objects potentially
involve in some cycles. Is there any chance of this being supported ? Or
at least, is there a way to add the needed functions "by hands" ?

Hope I was clear enough,

Pierre

-- 
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 seefeld at sympatico.ca  Tue Jun 14 14:38:06 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Jun 2005 08:38:06 -0400
Subject: [C++-sig] Improved pyste
In-Reply-To: <7465b617050613215266da6a41@mail.gmail.com>
References: <28794-74921@sneakemail.com>	
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>	
	<42A63125.6154.2FC5ABE@localhost>	
	<7465b61705060723025e2d4dff@mail.gmail.com>	
	<uzmu1htlh.fsf@boost-consulting.com>	
	<uacm06ckd.fsf@boost-consulting.com>	
	<7465b61705060822531d375f23@mail.gmail.com>	
	<42AE20FD.9090204@sympatico.ca>
	<7465b617050613215266da6a41@mail.gmail.com>
Message-ID: <42AECFAE.9020701@sympatico.ca>

Roman Yakovenko wrote:

> I am aware about this poject. If I understand right, one of the
> reasons Pyste has success is it's ability to read C++ code with 100%
> exectness. I don't know whether synopsis is able to do the same.

Probably not. But it would be worth to define in more precise terms
what '100% exactness' means. Correct parsing ? Correct type analysis ?

As far as I understand, for source-to-source translation you need a
correct parse tree, but you don't need all aspects of type analysis.
Am I wrong ?

(Synopsis is a work in progress, and I hope to get synopsis closer
to '100% exactness' over time, but I'm sure for many practical purposes
it's already 'exact enough'.)

My argument was only partly about switching the parser backend. Another
aspect is the extensibility of the design of the 'processor pipeline'
I use, which I think might offer a solution for pyste, too, if people
want to plug in their own code generation rules.


Regards,
		Stefan


From dave at boost-consulting.com  Tue Jun 14 15:00:41 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Jun 2005 09:00:41 -0400
Subject: [C++-sig] Improved pyste
References: <28794-74921@sneakemail.com>
	<20050607211852.66574.qmail@web31501.mail.mud.yahoo.com>
	<42A63125.6154.2FC5ABE@localhost>
	<7465b61705060723025e2d4dff@mail.gmail.com>
	<uzmu1htlh.fsf@boost-consulting.com>
	<uacm06ckd.fsf@boost-consulting.com>
	<7465b61705060822531d375f23@mail.gmail.com>
	<42AE20FD.9090204@sympatico.ca>
Message-ID: <uacltytxi.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Roman Yakovenko wrote:
>
>> 6. As I mentioned in my previous post: there are a few projects that
>> use similar way to expose C++ to different languages. One of them is
>> yours: langbinding. I think it will be pretty easy to support code
>> generation for this library too. ( This statement still should be
>> checked by reality )
>
> By the way, did you have a look into synopsis (http://synopsis.fresco.org) ?
> It contains a C++ parser and its goal is to provide a code introspection
> framework particularly useful to write source-to-source translators with.
> I think, as a first step it would be an interesting project to replace
> gccxml by synopsis as a parser backend in pyste, and then gradually
> make pyste extensible much the same way synopsis already is extensible,
> i.e. allow user modules to override specific code generation rules.
>
> What do you think ?

I think that would be a great project.

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



From dave at boost-consulting.com  Tue Jun 14 15:01:19 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Jun 2005 09:01:19 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <u1x768m5l.fsf@boost-consulting.com>
	<42ADC2C9.1397.1588052@localhost>
Message-ID: <u4qc1ytwg.fsf@boost-consulting.com>

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

> On 13 Jun 2005 at 8:40, David Abrahams wrote:
>
>> >> > Why doesn't BPL's ptr() accept pointers to integral types?
>> >> 
>> >> Think about how you would implement such a thing.  What would a an
>> >> overriden virtual function written in Python see?
>> >
>> > A single item of whatever type eg; long * would mean the python code
>> > sees a python integer.
>> 
>> I'm confused now.  If you pass an int* without wrapping it in ptr()
>> that's exactly what happens, right?
>
> I don't know about int, but unsigned int * yields a runtime error of 
> no to-python converter for unsigned int.

Oh, drat.  But then, why not just dereference the pointer and pass
that?

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



From jorgensen at getcollc.com  Tue Jun 14 15:42:02 2005
From: jorgensen at getcollc.com (Jens B. Jorgensen)
Date: Tue, 14 Jun 2005 08:42:02 -0500
Subject: [C++-sig] examples compile but give exception (win32; intel 8.1;
	dinkumware 3.08)
Message-ID: <DB19BFB5D30D1E41A719B7709E4D90EE370B3D@MAILSERV1.getco.com>

I have a problem that hopefully someone can give me some insight to. I recently got Boost 1.32.0 to compile for my environment. I'm using the Intel c++ compiler 8.1 and the dinkumware std library v3.08. Getting everything to compile ultimately required my own custom intel-win32-sxl-tools.jam which I based on the intel-win32-tools.jam. The main options I added to get that working are:

CFLAGS += -I\"<path to dinkumware stdlib>" ;
CFLAGS += /D_GLOBAL_USING=1 /DBOOST_DATE_TIME_NO_LOCALE /D_HAS_EXCEPTIONS=1 /DBOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT -DBOOST_NO_EXCEPTION_STD_NAMESPACE /DBOOST_NO_STD_ALLOCATOR -DBOOST_NO_STD_USE_FACET -DBOOST_HAS_TWO_ARG_USE_FACET ;

e.g. if I use bjam "-sTOOLS=intel-win32-sxl" -n I see:

    CALL "c:\Program Files\Intel\CPP\Compiler80\Ia32\bin\ICLVARS.BAT" > nul
    "c:\Program Files\Intel\CPP\Compiler80\Ia32\bin\icl"  /Zm800 -nologo /EHsc -c  -DBOOST_PYTHON_DYNAMIC_LIB  /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\VendorAPIs\SXL\include" /D_GLOBAL_USING=1 /DBOOST_DATE_TIME_NO_LOCALE /D_HAS_EXCEPTIONS=1 /DBOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT -DBOOST_NO_EXCEPTION_STD_NAMESPACE /DBOOST_NO_STD_ALLOCATOR -DBOOST_NO_STD_USE_FACET -DBOOST_HAS_TWO_ARG_USE_FACET  /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Zc:forScope /Qansi_alias /Qvc6 -DBOOST_NO_INTRINSIC_WCHAR_T /EHa  -I"bin\example"  -I"C:\Program Files\Microsoft Visual
 Studio\VC98\include"  -I"c:\boost_1_32_0" -I"c:\Python24\include"   -Fo"bin\example\getting_started2.pyd\intel-win32-sxl\debug\threading-multi\getting_started2.obj"  -Tp"c:\boost_1_32_0\libs\python\example\getting_started2.cpp"

I arrived at my custom .jam through time patiently spent looking at compiler error messages and the source. With the above everything builds! Huzzah. We're using the Intel compiler in an msvc6 "environment" at the moment so I've got /Qvc6. 

So, then I proceeded to the hello example that defines a module with a "greet" function. Works fine. Then I tried to get a little fancier and create an object. This builds but I get a runtime error. So, ultimately I try using bjam to build the example code included. Everything builds fine but when I try to using the resulting python module I get some interesting things:

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import getting_started2
>>> h = getting_started2.hello()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    hello.__init__(hello)
did not match C++ signature:
    __init__(struct _object *, class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)

Any ideas? I've been pondering the lists but I'm stumped. It's clear that someout it isn't able to map the class but I have no idea why. The above module was compiled from the source included in the distribution, I made no changes to the source.

Thanks for any help or pointers,

Jens B. Jorgensen
Getco, LLC




From jorgensen at getcollc.com  Tue Jun 14 15:58:48 2005
From: jorgensen at getcollc.com (Jens B. Jorgensen)
Date: Tue, 14 Jun 2005 08:58:48 -0500
Subject: [C++-sig] examples compile but give exception (win32; intel 8.1;
	dinkumware 3.08)
Message-ID: <DB19BFB5D30D1E41A719B7709E4D90EE370B3E@MAILSERV1.getco.com>

Sorry, the below makes me look like an idiot (I'm not asserting I'm not, but what you see below is actually not what I intended). Clearly the hello constructor in getting_started2 requires an argument. I first saw the error below in a different piece of code (one I wrote) and I quickly tried the example to verify that I was getting the same thing. In any case, writing proper Python I get: 

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import getting_started2
>>> h = getting_started2.hello('hello, world')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    hello.__init__(hello, str)
did not match C++ signature:
    __init__(struct _object *, class std::basic_string<char,struct std::char_tra
its<char>,class std::allocator<char> >)
>>>

Or running the test_getting_started2.py I get:

**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 2, in test_getting_started2
Failed example:
    hi = hello('California')
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[1]>", line 1, in ?
        hi = hello('California')
    ArgumentError: Python argument types in
        hello.__init__(hello, str)
    did not match C++ signature:
        __init__(struct _object *, class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)
**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 3, in test_getting_started2
Failed example:
    hi.greet()
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[2]>", line 1, in ?
        hi.greet()
    NameError: name 'hi' is not defined
**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 5, in test_getting_started2
Failed example:
    invite(hi)
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[3]>", line 1, in ?
        invite(hi)
    NameError: name 'hi' is not defined
**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 7, in test_getting_started2
Failed example:
    hi.invite()
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[4]>", line 1, in ?
        hi.invite()
    NameError: name 'hi' is not defined
**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 14, in test_getting_started2
Failed example:
    hi2 = wordy('Florida')
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[6]>", line 1, in ?
        hi2 = wordy('Florida')
    ArgumentError: Python argument types in
        hello.__init__(wordy, str)
    did not match C++ signature:
        __init__(struct _object *, class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)
**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 15, in test_getting_started2
Failed example:
    hi2.greet()
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[7]>", line 1, in ?
        hi2.greet()
    NameError: name 'hi2' is not defined
**********************************************************************
File "c:\boost_1_32_0\libs\python\example\test_getting_started2.py", line 17, in test_getting_started2
Failed example:
    invite(hi2)
Exception raised:
    Traceback (most recent call last):
      File "C:\Python24\Lib\doctest.py", line 1243, in __run
        compileflags, 1) in test.globs
      File "<doctest test_getting_started2[8]>", line 1, in ?
        invite(hi2)
    NameError: name 'hi2' is not defined
**********************************************************************
1 items had failures:
   7 of   9 in test_getting_started2
***Test Failed*** 7 failures.


> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]On
> Behalf Of Jens B. Jorgensen
> Sent: Tuesday, June 14, 2005 8:42 AM
> To: c++-sig at python.org
> Subject: [C++-sig] examples compile but give exception (win32; intel
> 8.1;dinkumware 3.08)
> 
> 
> I have a problem that hopefully someone can give me some 
> insight to. I recently got Boost 1.32.0 to compile for my 
> environment. I'm using the Intel c++ compiler 8.1 and the 
> dinkumware std library v3.08. Getting everything to compile 
> ultimately required my own custom intel-win32-sxl-tools.jam 
> which I based on the intel-win32-tools.jam. The main options 
> I added to get that working are:
> 
> CFLAGS += -I\"<path to dinkumware stdlib>" ;
> CFLAGS += /D_GLOBAL_USING=1 /DBOOST_DATE_TIME_NO_LOCALE 
> /D_HAS_EXCEPTIONS=1 
> /DBOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT 
> -DBOOST_NO_EXCEPTION_STD_NAMESPACE /DBOOST_NO_STD_ALLOCATOR 
> -DBOOST_NO_STD_USE_FACET -DBOOST_HAS_TWO_ARG_USE_FACET ;
> 
> e.g. if I use bjam "-sTOOLS=intel-win32-sxl" -n I see:
> 
>     CALL "c:\Program 
> Files\Intel\CPP\Compiler80\Ia32\bin\ICLVARS.BAT" > nul
>     "c:\Program Files\Intel\CPP\Compiler80\Ia32\bin\icl"  
> /Zm800 -nologo /EHsc -c  -DBOOST_PYTHON_DYNAMIC_LIB  /Z7 /Od 
> /Ob0 /EHsc /GR /MDd -I"C:\VendorAPIs\SXL\include" 
> /D_GLOBAL_USING=1 /DBOOST_DATE_TIME_NO_LOCALE 
> /D_HAS_EXCEPTIONS=1 
> /DBOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT 
> -DBOOST_NO_EXCEPTION_STD_NAMESPACE /DBOOST_NO_STD_ALLOCATOR 
> -DBOOST_NO_STD_USE_FACET -DBOOST_HAS_TWO_ARG_USE_FACET  /Qwn5 
> /Qwd985 -Qoption,c,--arg_dep_lookup /Zc:forScope /Qansi_alias 
> /Qvc6 -DBOOST_NO_INTRINSIC_WCHAR_T /EHa  -I"bin\example"  
> -I"C:\Program Files\Microsoft Visual
>  Studio\VC98\include"  -I"c:\boost_1_32_0" 
> -I"c:\Python24\include"   
> -Fo"bin\example\getting_started2.pyd\intel-win32-sxl\debug\thr
> eading-multi\getting_started2.obj"  
> -Tp"c:\boost_1_32_0\libs\python\example\getting_started2.cpp"
> 
> I arrived at my custom .jam through time patiently spent 
> looking at compiler error messages and the source. With the 
> above everything builds! Huzzah. We're using the Intel 
> compiler in an msvc6 "environment" at the moment so I've got /Qvc6. 
> 
> So, then I proceeded to the hello example that defines a 
> module with a "greet" function. Works fine. Then I tried to 
> get a little fancier and create an object. This builds but I 
> get a runtime error. So, ultimately I try using bjam to build 
> the example code included. Everything builds fine but when I 
> try to using the resulting python module I get some 
> interesting things:
> 
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit 
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import getting_started2
> >>> h = getting_started2.hello()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> Boost.Python.ArgumentError: Python argument types in
>     hello.__init__(hello)
> did not match C++ signature:
>     __init__(struct _object *, class 
> std::basic_string<char,struct std::char_traits<char>,class 
> std::allocator<char> >)
> 
> Any ideas? I've been pondering the lists but I'm stumped. 
> It's clear that someout it isn't able to map the class but I 
> have no idea why. The above module was compiled from the 
> source included in the distribution, I made no changes to the source.
> 
> Thanks for any help or pointers,
> 
> Jens B. Jorgensen
> Getco, LLC
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 


From dave at boost-consulting.com  Tue Jun 14 19:49:46 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Jun 2005 13:49:46 -0400
Subject: [C++-sig] Any work for cyclic garbage collection support ?
References: <42AE9BF2.9010306@cirad.fr>
Message-ID: <uzmtsu8ud.fsf@boost-consulting.com>

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

> Hello,
>
> I had the problem some years ago and did not succeed in using the cyclic
> garbage collector of Python with BPL objects. Now, I read a little more
> about it and I wonder if it is possible to add such support without many
> changes in BPL !
>
> The fact is, the allocation is different, you have to initialise the
> structure of the class in the right way and you have to define some
> "traversal" function being able to enumerate all the objects potentially
> involve in some cycles. Is there any chance of this being supported
> ? 

I guess, if you can figure out how to do it in a way that's reasonably
safe.  The problem, IIRC, is that if you mark something for GC you
need to be able to enumerate all the PyObject*s embedded in it. So if
someone makes a C++ class containing a boost::python::object and
doesn't tell us about it, the GC system will break.  Seemed a little
too dangerous to be worthwhile.

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



From dave at boost-consulting.com  Tue Jun 14 19:59:17 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Jun 2005 13:59:17 -0400
Subject: [C++-sig] examples compile but give exception (win32; intel 8.1;
	dinkumware 3.08)
References: <DB19BFB5D30D1E41A719B7709E4D90EE370B3E@MAILSERV1.getco.com>
Message-ID: <ur7f4u8ei.fsf@boost-consulting.com>

"Jens B. Jorgensen" <jorgensen at getcollc.com> writes:

> Sorry, the below makes me look like an idiot (I'm not asserting I'm not, but what you see below is actually not what I intended). Clearly the hello constructor in getting_started2 requires an argument. I first saw the error below in a different piece of code (one I wrote) and I quickly tried the example to verify that I was getting the same thing. In any case, writing proper Python I get: 
>
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import getting_started2
>>>> h = getting_started2.hello('hello, world')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> Boost.Python.ArgumentError: Python argument types in
>     hello.__init__(hello, str)
> did not match C++ signature:
>     __init__(struct _object *, class std::basic_string<char,struct std::char_tra
> its<char>,class std::allocator<char> >)
>>>>

Looks like a problem with RTTI.  Did you perhaps have it turned off in
your extension module?

Incidentally, I think you went about making the toolset the hard way.
Seems like using a rather big hammer to be manually injecting the
compiler flags; you might easily be countermanding something that the
build system is doing on purpose in order to make Boost.Python work on
intel-windows.

I would take intel-win32-stlport-tools.jam as my model if I were you.

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



From chilavert123 at gmx.net  Wed Jun 15 12:32:23 2005
From: chilavert123 at gmx.net (Thomas Kolb)
Date: Wed, 15 Jun 2005 12:32:23 +0200
Subject: [C++-sig] Wrapping boost::multi_array
Message-ID: <d8ovq4$dh5$1@sea.gmane.org>

Hi all,

I have lots of classes in my library that deal heavily with 
boost::multi_array, so I'm trying to wrap this class for some special 
dimensions and data types.

My source code is:

namespace  {

	typedef boost::multi_array<double, 1> DoubleVector;	

	DoubleVector* cTorWrapper(unsigned int size)
	{
		return new DoubleVector(boost::extents[size]);
	}
	
	double& operatorWrapper(DoubleVector& vec, DoubleVector::size_type id)
	{
		return vec[0];
	}

}// namespace


// Module 
======================================================================
void Export_Multi_Array()
{
     class_< DoubleVector, std::auto_ptr<DoubleVector> >("DoubleVector")
     	.def("__init__", make_constructor(cTorWrapper))
	.def("get",&operatorWrapper, return_internal_reference< 1 >())
     ;
}

this leads to the following compiler error:

/usr/local/include/boost-1_31/boost/python/object/make_instance.hpp: 
In static
    member function `static PyObject*
    boost::python::objects::make_instance_impl<T, Holder,
    Derived>::execute(Arg&) [with Arg = double*, T = double, Holder =
    boost::python::objects::pointer_holder<double*, double>, Derived =
    boost::python::objects::make_ptr_instance<double,
    boost::python::objects::pointer_holder<double*, double> >]':
/usr/local/include/boost-1_31/boost/python/to_python_indirect.hpp:64: 
   instantiated from `static PyObject* 
boost::python::detail::make_reference_holder::execute(T*) [with T = 
double]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:19: 
   instantiated from `typename Generator::result_type 
boost::python::detail::unwind_type_cv(U*, 
boost::python::detail::cv_tag<false, false>, Generator*) [with 
Generator = boost::python::detail::make_reference_holder, U = double]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:48: 
   instantiated from `typename Generator::result_type 
boost::python::detail::unwind_ptr_type(U*, Generator*) [with Generator 
= boost::python::detail::make_reference_holder, U = double]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:58: 
   instantiated from `static typename Generator::result_type 
boost::python::detail::unwind_helper<is_ptr>::execute(U, Generator*) 
[with Generator = boost::python::detail::make_reference_holder, U = 
double*, bool is_ptr = true]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:77: 
   instantiated from `typename Generator::result_type 
boost::python::detail::unwind_type(const U&, Generator*) [with 
Generator = boost::python::detail::make_reference_holder, U = double*]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:26: 
   instantiated from `typename Generator::result_type 
boost::python::detail::unwind_type_cv(const U*, 
boost::python::detail::cv_tag<true, false>, Generator*) [with 
Generator = boost::python::detail::make_reference_holder, U = double]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:48: 
   instantiated from `typename Generator::result_type 
boost::python::detail::unwind_ptr_type(U*, Generator*) [with Generator 
= boost::python::detail::make_reference_holder, U = const double]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:69: 
   instantiated from `static typename Generator::result_type 
boost::python::detail::unwind_helper<false>::execute(U&, Generator*) 
[with Generator = boost::python::detail::make_reference_holder, U = 
const double]'
/usr/local/include/boost-1_31/boost/python/detail/unwind_type.hpp:77: 
   instantiated from `typename Generator::result_type 
boost::python::detail::unwind_type(const U&, Generator*) [with 
Generator = boost::python::detail::make_reference_holder, U = double]'
/usr/local/include/boost-1_31/boost/python/to_python_indirect.hpp:105: 
   instantiated from `PyObject* boost::python::to_python_indirect<T, 
MakeHolder>::operator()(T) const [with T = double&, MakeHolder = 
boost::python::detail::make_reference_holder]'
/usr/local/include/boost-1_31/boost/python/detail/invoke.hpp:76: 
instantiated from `PyObject* 
boost::python::detail::invoke(boost::python::detail::invoke_tag_<false, 
false>, const RC&, F&, AC0&, AC1&) [with RC = 
boost::python::to_python_indirect<double&, 
boost::python::detail::make_reference_holder>, F = 
double&(*)(<unnamed>::DoubleVector*, long unsigned int), AC0 = 
boost::python::arg_from_python<<unnamed>::DoubleVector*>, AC1 = 
boost::python::arg_from_python<long unsigned int>]'
/usr/local/include/boost-1_31/boost/python/detail/caller.hpp:199: 
instantiated from `PyObject* 
boost::python::detail::caller_arity<2>::impl<F, Policies, 
Sig>::operator()(PyObject*, PyObject*) [with F = 
double&(*)(<unnamed>::DoubleVector*, long unsigned int), Policies = 
boost::python::return_internal_reference<1, 
boost::python::default_call_policies>, Sig = 
boost::mpl::vector3<double&, <unnamed>::DoubleVector*, long unsigned 
int>]'
/usr/local/include/boost-1_31/boost/python/object/py_function.hpp:39: 
   instantiated from `PyObject* 
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, 
PyObject*) [with Caller = 
boost::python::detail::caller<double&(*)(<unnamed>::DoubleVector*, 
long unsigned int), boost::python::return_internal_reference<1, 
boost::python::default_call_policies>, boost::mpl::vector3<double&, 
<unnamed>::DoubleVector*, long unsigned int> >]'
/usr/local/include/boost-1_31/boost/python/make_constructor.hpp:40: 
instantiated from here
/usr/local/include/boost-1_31/boost/python/object/make_instance.hpp:25: 
error: invalid
    application of `sizeof' to an incomplete type

returning the result of operator[] by values compiles great, but 
that's not what I want.

Anybody has an idea what's wrong?

Best Regards



From s_sourceforge at nedprod.com  Wed Jun 15 12:49:11 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Jun 2005 11:49:11 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <u4qc1ytwg.fsf@boost-consulting.com>
Message-ID: <42B015B7.20783.1ECEB@localhost>

On 14 Jun 2005 at 9:01, David Abrahams wrote:

> >> >> > Why doesn't BPL's ptr() accept pointers to integral types?
> >> >> 
> >> >> Think about how you would implement such a thing.  What would a
> >> >> an overriden virtual function written in Python see?
> >> >
> >> > A single item of whatever type eg; long * would mean the python
> >> > code sees a python integer.
> >> 
> >> I'm confused now.  If you pass an int* without wrapping it in ptr()
> >> that's exactly what happens, right?
> >
> > I don't know about int, but unsigned int * yields a runtime error of
> > no to-python converter for unsigned int.
> 
> Oh, drat.  But then, why not just dereference the pointer and pass
> that?

Because I want to pass the pointer, not what it points to. I suppose 
I could have pyste cast it to void_.

Cheers,
Niall





From jorgensen at getcollc.com  Wed Jun 15 14:00:01 2005
From: jorgensen at getcollc.com (Jens B. Jorgensen)
Date: Wed, 15 Jun 2005 07:00:01 -0500
Subject: [C++-sig] examples compile but give exception (win32; intel 8.1;
	dinkumware 3.08)
Message-ID: <DB19BFB5D30D1E41A719B7709E4D90EE370B44@MAILSERV1.getco.com>

> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]On
> Behalf Of David Abrahams
> Sent: Tuesday, June 14, 2005 12:59 PM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] examples compile but give exception 
> (win32; intel
> 8.1;dinkumware 3.08)
> 
> 
> "Jens B. Jorgensen" <jorgensen at getcollc.com> writes:
> 
> > Sorry, the below makes me look like an idiot (I'm not 
> asserting I'm not, but what you see below is actually not 
> what I intended). Clearly the hello constructor in 
> getting_started2 requires an argument. I first saw the error 
> below in a different piece of code (one I wrote) and I 
> quickly tried the example to verify that I was getting the 
> same thing. In any case, writing proper Python I get: 
> >
> > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 
> bit (Intel)] on win32
> > Type "help", "copyright", "credits" or "license" for more 
> information.
> >>>> import getting_started2
> >>>> h = getting_started2.hello('hello, world')
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > Boost.Python.ArgumentError: Python argument types in
> >     hello.__init__(hello, str)
> > did not match C++ signature:
> >     __init__(struct _object *, class 
> std::basic_string<char,struct std::char_tra
> > its<char>,class std::allocator<char> >)
> >>>>
> 
> Looks like a problem with RTTI.  Did you perhaps have it turned off in
> your extension module?

Nope, definitely left that on. I guess I'll have to debug into the code. Any pointers on the best place to start looking for that? It's a little confusing since everything is declarative. Is the error triggered by an exception? A cast that fails? How does it work?

> Incidentally, I think you went about making the toolset the hard way.
> Seems like using a rather big hammer to be manually injecting the
> compiler flags; you might easily be countermanding something that the
> build system is doing on purpose in order to make Boost.Python work on
> intel-windows.
> 
> I would take intel-win32-stlport-tools.jam as my model if I were you.

That's pretty much what I did, although I started with intel-win32-tools.jam. Rest assured I didn't generate it from scratch. The main thing I started from was that I needed to link to the Dinkumware stdlib and then dealt with all the stuff that broke. 

One thing that I haven't quite figured out yet: I see postings here and there referring to tests that can be built and run but I haven't yet figured out how to get them built. Is there actually any documentation around that indicates how this is to be done? 

Thanks again for any suggestions or pointers. 


From dave at boost-consulting.com  Wed Jun 15 17:47:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Jun 2005 11:47:45 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <u4qc1ytwg.fsf@boost-consulting.com>
	<42B015B7.20783.1ECEB@localhost>
Message-ID: <uk6kvtye6.fsf@boost-consulting.com>

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

> On 14 Jun 2005 at 9:01, David Abrahams wrote:
>
>> >> >> > Why doesn't BPL's ptr() accept pointers to integral types?
>> >> >> 
>> >> >> Think about how you would implement such a thing.  What would a
>> >> >> an overriden virtual function written in Python see?
>> >> >
>> >> > A single item of whatever type eg; long * would mean the python
>> >> > code sees a python integer.
>> >> 
>> >> I'm confused now.  If you pass an int* without wrapping it in ptr()
>> >> that's exactly what happens, right?
>> >
>> > I don't know about int, but unsigned int * yields a runtime error of
>> > no to-python converter for unsigned int.
>> 
>> Oh, drat.  But then, why not just dereference the pointer and pass
>> that?
>
> Because I want to pass the pointer, not what it points to. 

I don't get it.  If you expect the Python code to just see a Python
int, what's the advantage in passing a pointer?  You are aware that
Python ints are immutable, I presume!

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



From dave at boost-consulting.com  Wed Jun 15 17:56:02 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Jun 2005 11:56:02 -0400
Subject: [C++-sig] examples compile but give exception (win32; intel 8.1;
	dinkumware 3.08)
References: <DB19BFB5D30D1E41A719B7709E4D90EE370B44@MAILSERV1.getco.com>
Message-ID: <uekb3ty0d.fsf@boost-consulting.com>

"Jens B. Jorgensen" <jorgensen at getcollc.com> writes:

>>  Looks like a problem with RTTI.  Did you perhaps have it turned off
>> in your extension module?
>
> Nope, definitely left that on. I guess I'll have to debug into the
> code. Any pointers on the best place to start looking for that? It's a
> little confusing since everything is declarative. Is the error
> triggered by an exception? A cast that fails? How does it work?

Well, it's triggered by a failure to find a matching __init__
overload.  The code that searches the overload set is in
function::call in libs/python/src/object/function.cpp.  The matching
of a particular overload is done in this code:

  // Call the function.  Pass keywords in case it's a
  // function accepting any number of keywords
  PyObject* result = inner_args ? f->m_fn(inner_args.get(), keywords) : 0;

There's quite a lot of detail that goes into that.

I would also recompile the Boost.Python library with
BOOST_PYTHON_TRACE_REGISTRY #defined, e.g.

   bjam "-sBUILD=<define>BOOST_PYTHON_TRACE_REGISTRY" ... 

The output you get when you try to run your extension module could be
illuminating.

>> Incidentally, I think you went about making the toolset the hard
>> way.  Seems like using a rather big hammer to be manually injecting
>> the compiler flags; you might easily be countermanding something
>> that the build system is doing on purpose in order to make
>> Boost.Python work on intel-windows.
>> 
>> I would take intel-win32-stlport-tools.jam as my model if I were
>> you.
>
> That's pretty much what I did, although I started with
> intel-win32-tools.jam. Rest assured I didn't generate it from
> scratch. The main thing I started from was that I needed to link to
> the Dinkumware stdlib and then dealt with all the stuff that broke.
>
> One thing that I haven't quite figured out yet: I see postings here
> and there referring to tests that can be built and run but I haven't
> yet figured out how to get them built. Is there actually any
> documentation around that indicates how this is to be done?

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

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



From s_sourceforge at nedprod.com  Wed Jun 15 23:00:59 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 15 Jun 2005 22:00:59 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <uk6kvtye6.fsf@boost-consulting.com>
Message-ID: <42B0A51B.14646.2320ADF@localhost>

On 15 Jun 2005 at 11:47, David Abrahams wrote:

> >> >> I'm confused now.  If you pass an int* without wrapping it in
> >> >> ptr() that's exactly what happens, right?
> >> >
> >> > I don't know about int, but unsigned int * yields a runtime error
> >> > of no to-python converter for unsigned int.
> >> 
> >> Oh, drat.  But then, why not just dereference the pointer and pass
> >> that?
> >
> > Because I want to pass the pointer, not what it points to. 
> 
> I don't get it.  If you expect the Python code to just see a Python
> int, what's the advantage in passing a pointer?  You are aware that
> Python ints are immutable, I presume!

Because if my C++ is going through a BPL wrapped virtual function and 
is passing it an array of unsigned int, if python doesn't overload it 
then it goes C++=>Python=>C++ and no extra action is required.

If you convert the array to/from a python list as you go through 
python, then that involves a to-list and from-list conversion for no 
good reason plus it destroys the original pointer value which can 
destroy semantics of the function.

If you could just specify ptr(unsigned int * parameter), it could run 
through the python part with very little overhead. Python if it looks 
sees just an int (though really underneath it's a BPL object which 
just looks like an int), but an overload in python could specifically 
call a function to do the list conversion if required.

I'm simply saying that there are some kinds of virtual function which 
can't be wrapped easily in BPL ie; those functions which expect a 
specific pointer rather then a pointer. BPL doesn't handle void * at 
all well when it seems naturally an obvious automatic opaque pointer. 
I guess I just don't see why this is the case.

Cheers,
Niall





From seefeld at sympatico.ca  Wed Jun 15 23:15:49 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 15 Jun 2005 17:15:49 -0400
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <42B0A51B.14646.2320ADF@localhost>
References: <42B0A51B.14646.2320ADF@localhost>
Message-ID: <42B09A85.9020302@sympatico.ca>

Niall Douglas wrote:

> I'm simply saying that there are some kinds of virtual function which 
> can't be wrapped easily in BPL ie; those functions which expect a 
> specific pointer rather then a pointer. BPL doesn't handle void * at 
> all well when it seems naturally an obvious automatic opaque pointer. 
> I guess I just don't see why this is the case.

Python is strongly typed, and there is no such thing as 'anything'
in python. If you want a special datatype, you should define it
(together with some wrapper functions to prevent the compiler from
having to second-guess).

Regards,
		Stefan


From dave at boost-consulting.com  Wed Jun 15 23:41:23 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Jun 2005 17:41:23 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <uk6kvtye6.fsf@boost-consulting.com>
	<42B0A51B.14646.2320ADF@localhost>
Message-ID: <u1x73nvr0.fsf@boost-consulting.com>

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

> On 15 Jun 2005 at 11:47, David Abrahams wrote:
>
>> >> >> I'm confused now.  If you pass an int* without wrapping it in
>> >> >> ptr() that's exactly what happens, right?
>> >> >
>> >> > I don't know about int, but unsigned int * yields a runtime error
>> >> > of no to-python converter for unsigned int.
>> >> 
>> >> Oh, drat.  But then, why not just dereference the pointer and pass
>> >> that?
>> >
>> > Because I want to pass the pointer, not what it points to. 
>> 
>> I don't get it.  If you expect the Python code to just see a Python
>> int, what's the advantage in passing a pointer?  You are aware that
>> Python ints are immutable, I presume!
>
> Because if my C++ is going through a BPL wrapped virtual function and 
> is passing it an array of unsigned int, if python doesn't overload it 
> then it goes C++=>Python=>C++ and no extra action is required.

Not if you use the new-style polymorphism support.

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



From antony.trupe at gmail.com  Thu Jun 16 01:27:30 2005
From: antony.trupe at gmail.com (Antony Trupe)
Date: Wed, 15 Jun 2005 19:27:30 -0400
Subject: [C++-sig] Creating an instance of a Python class
Message-ID: <c70524220506151627da2ca86@mail.gmail.com>

I need to instantiate a class defined in python code in c/c++ code, and call 
its methods. Any advice or directions to advice would be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050615/7df4beaf/attachment.htm>

From chilavert123 at gmx.net  Thu Jun 16 09:49:14 2005
From: chilavert123 at gmx.net (Thomas Kolb)
Date: Thu, 16 Jun 2005 09:49:14 +0200
Subject: [C++-sig] Wrapping boost::multi_array
In-Reply-To: <d8ovq4$dh5$1@sea.gmane.org>
References: <d8ovq4$dh5$1@sea.gmane.org>
Message-ID: <d8rajv$aqi$1@sea.gmane.org>

Thomas Kolb schrieb:

> namespace  {
> 
> 	typedef boost::multi_array<double, 1> DoubleVector;	
> 
> 	DoubleVector* cTorWrapper(unsigned int size)
> 	{
> 		return new DoubleVector(boost::extents[size]);
> 	}
> 	
> 	double& operatorWrapper(DoubleVector& vec, DoubleVector::size_type id)
> 	{
> 		return vec[0];
> 	}
> 

it seems it's not possible to return references (or pointers) to 
builtin types (like double, int,...) here. Am I right?



From dave at boost-consulting.com  Thu Jun 16 12:40:26 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Jun 2005 06:40:26 -0400
Subject: [C++-sig] Wrapping boost::multi_array
References: <d8ovq4$dh5$1@sea.gmane.org> <d8rajv$aqi$1@sea.gmane.org>
Message-ID: <uhdfyinz9.fsf@boost-consulting.com>

Thomas Kolb <chilavert123 at gmx.net> writes:

> Thomas Kolb schrieb:
>
>> namespace  {
>> 
>> 	typedef boost::multi_array<double, 1> DoubleVector;	
>> 
>> 	DoubleVector* cTorWrapper(unsigned int size)
>> 	{
>> 		return new DoubleVector(boost::extents[size]);
>> 	}
>> 	
>> 	double& operatorWrapper(DoubleVector& vec, DoubleVector::size_type id)
>> 	{
>> 		return vec[0];
>> 	}
>> 
>
> it seems it's not possible to return references (or pointers) to 
> builtin types (like double, int,...) here. Am I right?

That's correct.  Python floats and ints are immutable, so there's no
type that corresponds to a reference-to-double in Python.

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



From skottmckay at gmail.com  Thu Jun 16 18:43:24 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Thu, 16 Jun 2005 10:43:24 -0600
Subject: [C++-sig] pyste cache
Message-ID: <51d0178705061609434ed019ed@mail.gmail.com>

I've noticed that the pyste cache doesn't detect changes like a
declared method in a header having a default implementation added
there, resulting in the changes being ignored.

Would it be useful to update it to maybe checksum the file as well (or
perhaps just use a checksum for caching purposes rather than the
gccxml output)?

Thanks

S


From dave at boost-consulting.com  Thu Jun 16 19:02:32 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Jun 2005 13:02:32 -0400
Subject: [C++-sig] Boost.Python
In-Reply-To: <716621DCB4468F46BBCC1BCFBED45C12557FB1@XCH-NW-2V2.nw.nos.boeing.com>
	(Michael Drumheller's message of "Thu, 16 Jun 2005 09:28:30 -0700")
References: <716621DCB4468F46BBCC1BCFBED45C12557FB1@XCH-NW-2V2.nw.nos.boeing.com>
Message-ID: <uwtoub5g7.fsf@boost-consulting.com>


Followups to the C++-sig, please.

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

> David:
>
>   > a really great facility, and I am excited to try it out. 
>   
>   Thanks; that's always gratifying to hear!
>   
> You're welcome!
>
>   > I have a question though:  In the Tutorial->Embedding section,
>   > http://www.boost.org/libs/python/doc/tutorial/doc/html/python/embedding.html
>   > it says "Currently, Boost.Python does not directly support everything
>   > you'll need when embedding."  However, in other sections, such as the Ref Man page
>   > http://www.boost.org/libs/python/doc/v2/call_method.html, it seems to suggest
>   > that there is very powerful support for calling Python functions/methods etc.
>   > from C++.  
>   >
>   > Are these documents just out of sync, or am I misunderstanding
>   > something?
>   
>   I guess the latter.  Despite that powerful support you mention, there
>   are still gaps in Boost.Python's wrapping of the Python/C API as you
>   can see from the example.
>
> OK, thank you.  I think this is rather a serious doc bug.  

The smallest mistakes can look serious if they lead you down the wrong
path.

> I very nearly dismissed Boost.Python summarily as useless (to me)
> upon reading the Tutorial section.  (This is because my initial
> interest is in calling Python from C++, not building C++
> extensions.)  If you don't mind me going into a little detail, I'd
> like to explain how the documentation appeared to me, in particular
> the browsing sequence that it "led me through":
>
> I started browsing the Boost.Python doc pages, and found at this
> link pretty quickly:
> http://www.boost.org/libs/python/doc/tutorial/doc/html/python/embedding.html.
> (I found it because I first went to
> http://www.boost.org/libs/python/doc/, and there I saw the tutorial
> link
> http://www.boost.org/libs/python/doc/tutorial/doc/html/index.html.
> A tutorial is *always* the first thing I look for, so I went there.)
> I saw the "Embedding" item in the contents.  Clicking there, I saw
> right at the top of the first page the statement "...sometimes you
> may need to do the reverse: call Python code from the C++-side."  So
> I thought "A-ha, this is what I was looking for.  I am definitely in
> the right place."
>
> But when I read the rest of that page, all I saw stuff for eval'ing
> a string or file.  So I thought, "Hmmm, this stuff has not gone very
> far beyond what Python has been able to do forever."

If you can make some _specific_ suggestions about how to reformulate
that page, they'd be greatly appreciated.  I mean, "add this text
here, delete that text, stick a link here to whatever."

> I can't recall how I found the other link
> http://www.boost.org/libs/python/doc/v2/call_method.html, but it
> definitely took more time and resourcefulness on my part than it
> should have.

That might be good, because you shouldn't use it ;-).  The object
interface described at
http://www.boost.org/libs/python/doc/tutorial/doc/html/python/object.html
is much cleaner and generally more effective.

> I think Boost (and maybe Boost Consulting!) might be losing a
> potential user/customer now and then because of this--that is,
> because of the failure of the "Embedding" section to point to all
> the cool "callable" stuff.  

Well, yeah, I agree we could do better.  That said, if a person is
going to dive into the middle of the documentation, they're going to
miss some things.  You can only point to so many cool things from any
page before the whole doc becomes terribly redundant.

> To view it in the worst possible light, it is rather a glaring
> inadequacy, and such inadequacies, as you know, tend to cause doubts
> in people's minds as to the professional quality of a piece of
> software, and, speaking for myself, it tends to make one wonder
> whethere anyone is using, maintaining, or even paying attention to
> it.  (In fact, given that Boost has been around for a while, I find
> it kind of puzzling that I should be the first person to notice this
> particular problem.)

It's getting plenty of use and -- at the moment -- not as much
maintenance attention as I'd like.  Boost.Python is at its healthiest
when someone is funding development, but I do try to stay on top of
the critical things all the time.

> Another suggestion, while I'm at it, is this: I think the
> Boost.Python html docs *definitely* need to be supplemented with
> either/or/both (a) a one-page html version, (b) a pdf version.  The
> reason is to provide easy searchability.  If the Boost.Python docs
> were searchable, I might have found what I was looking for faster.

I can easily put a "search Boost.Python docs" box on the library's
front page without changing the format.  That's a good idea.  In the
meantime, try typing your search terms into Google, followed by

  site:http://www.boost.org/libs/python/doc

> All that being said, I'd like to say again that I am fascinated and impressed
> by the capabilities described therein and I'm looking forward to trying it out!

Thanks a lot!

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


From seefeld at sympatico.ca  Thu Jun 16 19:17:17 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 16 Jun 2005 13:17:17 -0400
Subject: [C++-sig] Boost.Python
In-Reply-To: <uwtoub5g7.fsf@boost-consulting.com>
References: <716621DCB4468F46BBCC1BCFBED45C12557FB1@XCH-NW-2V2.nw.nos.boeing.com>
	<uwtoub5g7.fsf@boost-consulting.com>
Message-ID: <42B1B41D.9090601@sympatico.ca>

David Abrahams wrote:

>>But when I read the rest of that page, all I saw stuff for eval'ing
>>a string or file.  So I thought, "Hmmm, this stuff has not gone very
>>far beyond what Python has been able to do forever."
> 
> 
> If you can make some _specific_ suggestions about how to reformulate
> that page, they'd be greatly appreciated.  I mean, "add this text
> here, delete that text, stick a link here to whatever."

David, what is boost.python holding back from offering functions
such as

object run_string(std::string const &text, object &scope);

and

object run_file(std::string const &filename, object &scope);

which are tiny wrappers around PyRun_String and PyRun_File ?

Is there any particular magic that would have to be added to make
that work ?

I remember we had this discussion years ago, but I don't remember
any particular outcome. If it's just a matter of someone having to
submit a patch I could write one. Am I missing any important issue ?

Thanks,
		Stefan


From dave at boost-consulting.com  Thu Jun 16 19:54:38 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Jun 2005 13:54:38 -0400
Subject: [C++-sig] Boost.Python
In-Reply-To: <uwtoub5g7.fsf@boost-consulting.com> (David Abrahams's message of
	"Thu, 16 Jun 2005 13:02:32 -0400")
References: <716621DCB4468F46BBCC1BCFBED45C12557FB1@XCH-NW-2V2.nw.nos.boeing.com>
	<uwtoub5g7.fsf@boost-consulting.com>
Message-ID: <uoea6b31d.fsf@boost-consulting.com>

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

> I can easily put a "search Boost.Python docs" box on the library's
> front page without changing the format.  That's a good idea.  In the
> meantime, try typing your search terms into Google, followed by
>
>   site:http://www.boost.org/libs/python/doc

This is done now.

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


From dave at boost-consulting.com  Thu Jun 16 20:17:50 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Jun 2005 14:17:50 -0400
Subject: [C++-sig] Boost.Python
References: <716621DCB4468F46BBCC1BCFBED45C12557FB1@XCH-NW-2V2.nw.nos.boeing.com>
	<uwtoub5g7.fsf@boost-consulting.com> <42B1B41D.9090601@sympatico.ca>
Message-ID: <uy89a9ne9.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>>>But when I read the rest of that page, all I saw stuff for eval'ing
>>>a string or file.  So I thought, "Hmmm, this stuff has not gone very
>>>far beyond what Python has been able to do forever."
>> 
>> 
>> If you can make some _specific_ suggestions about how to reformulate
>> that page, they'd be greatly appreciated.  I mean, "add this text
>> here, delete that text, stick a link here to whatever."
>
> David, what is boost.python holding back from offering functions
> such as
>
> object run_string(std::string const &text, object &scope);
>
> and
>
> object run_file(std::string const &filename, object &scope);
>
> which are tiny wrappers around PyRun_String and PyRun_File ?

Someone just has to implement them.

> Is there any particular magic that would have to be added to make
> that work ?

I don't see why there would be.

> I remember we had this discussion years ago, but I don't remember
> any particular outcome. If it's just a matter of someone having to
> submit a patch I could write one. Am I missing any important issue ?

Well, any patch has to include docs and tests.  If you're willing to
do all the legwork, I'll happily integrate it.

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



From s_sourceforge at nedprod.com  Thu Jun 16 21:52:05 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 16 Jun 2005 20:52:05 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <u1x73nvr0.fsf@boost-consulting.com>
Message-ID: <42B1E675.27655.17F944@localhost>

On 15 Jun 2005 at 17:41, David Abrahams wrote:

> > Because if my C++ is going through a BPL wrapped virtual function
> > and is passing it an array of unsigned int, if python doesn't
> > overload it then it goes C++=>Python=>C++ and no extra action is
> > required.
> 
> Not if you use the new-style polymorphism support.

Is there a special doc page or wiki entry describing this? It has 
been added when I wasn't paying attention to this mailing list.

Cheers,
Niall





From s_sourceforge at nedprod.com  Thu Jun 16 21:52:05 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 16 Jun 2005 20:52:05 +0100
Subject: [C++-sig] BPL and Py_Clear()
In-Reply-To: <42B09A85.9020302@sympatico.ca>
References: <42B0A51B.14646.2320ADF@localhost>
Message-ID: <42B1E675.19229.17F992@localhost>

On 15 Jun 2005 at 17:15, Stefan Seefeld wrote:

> > I'm simply saying that there are some kinds of virtual function
> > which can't be wrapped easily in BPL ie; those functions which
> > expect a specific pointer rather then a pointer. BPL doesn't handle
> > void * at all well when it seems naturally an obvious automatic
> > opaque pointer. I guess I just don't see why this is the case.
> 
> Python is strongly typed, and there is no such thing as 'anything' in
> python. If you want a special datatype, you should define it (together
> with some wrapper functions to prevent the compiler from having to
> second-guess).

No but python can understand opaque types. This is enough in many 
cases where python gets a void * and must pass that void * to some 
C++.

Cheers,
Niall





From atulkshirsagar at yahoo.com  Fri Jun 17 00:25:35 2005
From: atulkshirsagar at yahoo.com (Atul Kshirsagar)
Date: Thu, 16 Jun 2005 15:25:35 -0700 (PDT)
Subject: [C++-sig] solaris: import module error
Message-ID: <20050616222535.29473.qmail@web30715.mail.mud.yahoo.com>

Hello,
I am embedding python in C++ using SWIG. 
* The appication runs as a server. 
* Mutiple clients send requests which execute some
python scripts with import statements. 
* Each request is handled in a separate thread which
has its own interepreter for script execution.
* Requests are succesfully completed fine for some
time and then I see some "ImportErrors" for example
"ImportError: No module named string" 

Apart from these python replated errors I see some
"too many files open" errors in my other server code. 

Other than solaris things work fine on other unix
platforms and windos too. One additional thing I do
for solaris is 
"import DLFCN; sys.setdlopenflags(DLFCN.RTLD_NOW |
DLFCN.RTLD_PARENT);"

One of my question is, is importing some module create
a file handle ?

Any help on this is appreciated.

Thanks,
Atul Kshirsagar

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


From nicodemus at esss.com.br  Fri Jun 17 00:42:31 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Thu, 16 Jun 2005 20:42:31 -0200
Subject: [C++-sig] pyste cache
In-Reply-To: <51d0178705061609434ed019ed@mail.gmail.com>
References: <51d0178705061609434ed019ed@mail.gmail.com>
Message-ID: <42B20057.5020301@esss.com.br>

Scott McKay wrote:

>I've noticed that the pyste cache doesn't detect changes like a
>declared method in a header having a default implementation added
>there, resulting in the changes being ignored.
>  
>

No it doesn't. The cache wasn't meant to be bullet-proof; it was 
implemented only as a way to speed up the process of generating 
wrappers. The cache is really just the pickled representation of the xml 
given by gccxml. Reading this pickled file is much faster than calling 
gccxml and parsing its output, which can help you if you're doing a lot 
of changes and tests in the pyste files but the source code isn't changing.

>Would it be useful to update it to maybe checksum the file as well (or
>perhaps just use a checksum for caching purposes rather than the
>gccxml output)?
>  
>

It could, but I would rather not; I think this is a job for a complete 
dependency and build system, like SCons' rules. But if someone provides 
a clean patch and tests, I would happily integrate it. :)

Best Regards,
Nicodemus.


From skottmckay at gmail.com  Fri Jun 17 01:57:39 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Thu, 16 Jun 2005 17:57:39 -0600
Subject: [C++-sig] pyste cache
In-Reply-To: <42B20057.5020301@esss.com.br>
References: <51d0178705061609434ed019ed@mail.gmail.com>
	<42B20057.5020301@esss.com.br>
Message-ID: <51d017870506161657f31e996@mail.gmail.com>

I'll look into making it an option. I have a makefile setup which
detects that the header has changed and calls pyste, but as that
doesn't output a changed .cpp file it thinks there's nothing more to
do.

Maybe something simple like leaving the current test in place, and
adding an additional check that if the header was modified more
recently than the cache file simply touch the output .cpp file.

S

On 6/16/05, Nicodemus <nicodemus at esss.com.br> wrote:
> Scott McKay wrote:
> 
> >I've noticed that the pyste cache doesn't detect changes like a
> >declared method in a header having a default implementation added
> >there, resulting in the changes being ignored.
> >
> >
> 
> No it doesn't. The cache wasn't meant to be bullet-proof; it was
> implemented only as a way to speed up the process of generating
> wrappers. The cache is really just the pickled representation of the xml
> given by gccxml. Reading this pickled file is much faster than calling
> gccxml and parsing its output, which can help you if you're doing a lot
> of changes and tests in the pyste files but the source code isn't changing.
> 
> >Would it be useful to update it to maybe checksum the file as well (or
> >perhaps just use a checksum for caching purposes rather than the
> >gccxml output)?
> >
> >
> 
> It could, but I would rather not; I think this is a job for a complete
> dependency and build system, like SCons' rules. But if someone provides
> a clean patch and tests, I would happily integrate it. :)
> 
> Best Regards,
> Nicodemus.
>


From dave at boost-consulting.com  Fri Jun 17 04:57:27 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Jun 2005 22:57:27 -0400
Subject: [C++-sig] BPL and Py_Clear()
References: <u1x73nvr0.fsf@boost-consulting.com>
	<42B1E675.27655.17F944@localhost>
Message-ID: <uaclp8zc8.fsf@boost-consulting.com>

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

> On 15 Jun 2005 at 17:41, David Abrahams wrote:
>
>> > Because if my C++ is going through a BPL wrapped virtual function
>> > and is passing it an array of unsigned int, if python doesn't
>> > overload it then it goes C++=>Python=>C++ and no extra action is
>> > required.
>> 
>> Not if you use the new-style polymorphism support.
>
> Is there a special doc page or wiki entry describing this? It has 
> been added when I wasn't paying attention to this mailing list.

http://tinyurl.com/8gynk#python.class_virtual_functions
(http://www.boost.org/libs/python/doc/tutorial/doc/html/python/exposing.html#python.class_virtual_functions)

http://tinyurl.com/aknmp
(http://www.boost.org/libs/python/doc/v2/wrapper.html)

This is the recommended approach; it performs better and has fewer
problems in almost every way than the old one.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From cimca at canberra.edu.au  Sat Jun 18 06:00:09 2005
From: cimca at canberra.edu.au (cimca)
Date: Sat, 18 Jun 2005 14:00:09 +1000
Subject: [C++-sig] CFP: IEEE inco-operated International Conference on
	Computational Intelligence for Modelling, Control and Automation
Message-ID: <088D96D6E422174EAABF7B27D94F3EE702AD16E8@hera.ucstaff.win.canberra.edu.au>

 
                           CALL FOR PAPERS

International Conference on Computational Intelligence for Modelling,
                    Control and Automation
              28 - 30 November 2005 Vienna, Austria
                         http://www.ise.canberra.edu.au/conferences/cimca05/

In co-operation with:
IEEE Computational Intelligence Society
Conference Proceedings will be published as books by IEEE (The Institute of Electrical and Electronic Engineering)



Sponsored by:
European Society for Fuzzy Logic and Technology - EUFLAT
International Association for Fuzzy Set in Management and Economy - SIGEF 
Japan Society for Fuzzy Theory and Intelligent Informatics - SOFT
Taiwan Fuzzy Systems Association - TFSA
World Wide Web Business Intelligence - W3BI
Hungarian Fuzzy Association - HFA 
University of Canberra

                             Jointly with
International Conference on Intelligent Agents, Web Technologies
                         and Internet Commerce
             http://www.ise.canberra.edu.au/conferences/iawtic05/                          

Honorary Chair:
Lotfi A. Zadeh, University of California, USA
Stephen Grossberg, Boston University, USA


The international conference on computational intelligence for modelling, control and automation will be held in Vienna, 
Austria on 28 to 30 November 2005. The conference provides a medium for the exchange of ideas between theoreticians and 
practitioners to address the important issues in computational intelligence, modelling, control and automation. 
The conference will consist of both plenary sessions and contributory sessions, focusing on theory, implementation 
and applications of computational intelligence techniques to modelling, control and automation. For contributory 
sessions, papers (4 pages or more) are being solicited. Several well-known keynote speakers will address the
 conference. 

Conference Proceedings will be published as books by IEEE (The Institute of Electrical and Electronic Engineering) in USA 
and will be index world wide. All papers will be peer reviewed by at least two reviewers. 
Topics of the conference include, but are not limited to, the following areas:

Modern and Advanced Control Strategies:
Neural Networks Control,
Fuzzy Logic Control,
Genetic Algorithms and Evolutionary Control,
Model-Predictive Control,
Adaptive and Optimal Control,
Intelligent Control Systems,
Robotics and Automation,
Fault Diagnosis,
Intelligent agents,
Industrial Automations

Hybrid Systems:
Fuzzy Evolutionary Systems,
Fuzzy Expert Systems,
Fuzzy Neural Systems,
Neural Genetic Systems,
Neural-Fuzzy-Genetic Systems,
Hybrid Systems for Optimisation

Data Analysis, Prediction and Model Identification:
Signal Processing,
Prediction and Time Series Analysis,
System Identification,
Data Fusion and Mining,
Knowledge Discovery,
Intelligent Information Systems,
Image Processing, and Image Understanding,
Parallel Computing applications in Identification & Control,
Pattern Recognition,
Clustering and Classification

Decision Making and Information Retrieval:
Case-Based Reasoning,
Decision Analysis,
Intelligent Databases & Information Retrieval,
Dynamic Systems Modelling,
Decision Support Systems,
Multi-criteria Decision Making,
Qualitative and Approximate-Reasoning

Paper Submission
Papers will be selected based on their originality, significance, correctness, and clarity of presentation. Papers (4 pages or more) should be submitted to the following e-mail or the following address: 
CIMCA'2005 Secretariat
School of Information Sciences and Engineering
University of Canberra, Canberra, 2616, ACT, Australia
E-mail: cimca at canberra.edu.au

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

Important Dates
31 August 2005 Submission of draft papers
30 September 2005 Notification of acceptance
21 October 2005 Deadline for camera-ready copies of accepted papers
28-30 November 2005 Conference sessions

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

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

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

Organising Committee Chair:
Masoud Mohammadian, University of
Canberra, Australia

International Program Committee:
H. Adeli, The Ohio State University, USA
W. Pedrycz, University of Manitoba, Canada
A. Agah, The University of Kansas, USA
T. Fukuda, Nagoya University, Japan
J. Bezdek, University of West Florida, USA
R. C. Eberhart, Purdue University, USA
F. Herrera, University of Granada, Spain
T. Furuhashi, Nagoya University, Japan
A. Agah, The University of Kansas, US
E. Andr?, Universit?t Augsburg, Germany
A. Kandel, University of South Florida, USA
J. P. Bigus, IBM T. J. Watson Research Center, USA
J. Liu, Hong Kong Baptist University, Hong Kong
A. Namatame, National Defense Academy, Japan
K. Sycara, Carnegie Mellon University, USA
B. Kosko, University of Southern California, USA
T. Baeck, Informatic Centrum Dortmund, Germany
K. Hirota, Tokyo Institute of Technology, Japan
E. Oja, Helsinki University of Technology, Finland
H. R. Berenji, NASA Ames Research Center, USA
H. Liljenstrom, Royal Institute of Technology, Sweden
A. Bulsari, AB Nonlinear Solutions OY, Finland
J. Fernandez de Ca?ete, University of Malaga, Spain
W. Duch, Nicholas Copernicus University, Poland
E. Tulunay, Middle East Technical University, Turkey
C. Kuroda, Tokyo Institute of Technology, Japan
T. Yamakawa, Kyushu Institute of Technology, Japan
J. Liu, Hong Kong Baptist University, Hong Kong
A. Namatame, National Defense Academy, Japan
A. Aamodt, Norwegian University of Science & Technology, Norway

International Liaison:
Canada and USA Liaison:
Robert John, De Montfort University, UK
Nasser Jazdi, Institut f?r Automatisierungs- und
Softwaretechnik, Germany

Europe Liaison:
Dr. Eng. Djamel Khadraoui, Centre de Recherche Public, Luxembourg 
Frank Zimmer, SES ASTRA, Luxembourg

Asia Liaison:
Renzo Gobbin, University of Canberra, Australia
R. Amin Sarker, ADFA, Australia

Local Arrangements and
Public Relation:
Zohreh Pahlavani, AVIP, Austria
C Meier, Australia

Publicity:
C. Meier, Australia
Zohreh Pahlavani, AVIP, Austria

Publication:
Masoud Mohammadian, Australia

In cooperation with:
University of Canberra, (Masoud Mohammadian)
Universidad Carlos III de Madrid, (Jos?-Luis Fern?ndez-Villaca?as Mart?n)
University of Guelph, (Simon X. Yang)





From skottmckay at gmail.com  Mon Jun 20 23:30:23 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Mon, 20 Jun 2005 15:30:23 -0600
Subject: [C++-sig] pyste cache
In-Reply-To: <51d017870506161657f31e996@mail.gmail.com>
References: <51d0178705061609434ed019ed@mail.gmail.com>
	<42B20057.5020301@esss.com.br>
	<51d017870506161657f31e996@mail.gmail.com>
Message-ID: <51d017870506201430460bb2f7@mail.gmail.com>

After looking into this a little more I'm not sure what the best
approach is. Gnu make can be made to work by making the .o file
dependent on the .pyste, .hh and .cpp files (previously I had the .cpp
dependent on the .hh and .pyste, and the .o dependent on just the
.cpp). I don't know whether it's preferable to require that in the
makefile world, or whether it's better to always write a .cpp file
even if the cache entry was used.

If the current setup is preferred then maybe the documentation could
have a note added to it about settings the .o dependecies correctly.

Thoughts?

S 

On 6/16/05, Scott McKay <skottmckay at gmail.com> wrote:
> I'll look into making it an option. I have a makefile setup which
> detects that the header has changed and calls pyste, but as that
> doesn't output a changed .cpp file it thinks there's nothing more to
> do.
> 
> Maybe something simple like leaving the current test in place, and
> adding an additional check that if the header was modified more
> recently than the cache file simply touch the output .cpp file.
> 
> S
> 
> On 6/16/05, Nicodemus <nicodemus at esss.com.br> wrote:
> > Scott McKay wrote:
> >
> > >I've noticed that the pyste cache doesn't detect changes like a
> > >declared method in a header having a default implementation added
> > >there, resulting in the changes being ignored.
> > >
> > >
> >
> > No it doesn't. The cache wasn't meant to be bullet-proof; it was
> > implemented only as a way to speed up the process of generating
> > wrappers. The cache is really just the pickled representation of the xml
> > given by gccxml. Reading this pickled file is much faster than calling
> > gccxml and parsing its output, which can help you if you're doing a lot
> > of changes and tests in the pyste files but the source code isn't changing.
> >
> > >Would it be useful to update it to maybe checksum the file as well (or
> > >perhaps just use a checksum for caching purposes rather than the
> > >gccxml output)?
> > >
> > >
> >
> > It could, but I would rather not; I think this is a job for a complete
> > dependency and build system, like SCons' rules. But if someone provides
> > a clean patch and tests, I would happily integrate it. :)
> >
> > Best Regards,
> > Nicodemus.
> >
>


From s_sourceforge at nedprod.com  Tue Jun 21 01:45:33 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 21 Jun 2005 00:45:33 +0100
Subject: [C++-sig] wrapper class (was: Re:  BPL and Py_Clear())
In-Reply-To: <uaclp8zc8.fsf@boost-consulting.com>
Message-ID: <42B7632D.853.31559CA@localhost>

On 16 Jun 2005 at 22:57, David Abrahams wrote:

> >> > Because if my C++ is going through a BPL wrapped virtual function
> >> > and is passing it an array of unsigned int, if python doesn't
> >> > overload it then it goes C++=>Python=>C++ and no extra action is
> >> > required.
> >> 
> >> Not if you use the new-style polymorphism support.
> >
> > Is there a special doc page or wiki entry describing this? It has
> > been added when I wasn't paying attention to this mailing list.
> 
> http://tinyurl.com/8gynk#python.class_virtual_functions
> (http://www.boost.org/libs/python/doc/tutorial/doc/html/python/exposin
> g.html#python.class_virtual_functions)
> 
> http://tinyurl.com/aknmp
> (http://www.boost.org/libs/python/doc/v2/wrapper.html)
> 
> This is the recommended approach; it performs better and has fewer
> problems in almost every way than the old one. -- Dave Abrahams Boost
> Consulting www.boost-consulting.com

None of those docs told me why the new way was any better than the 
old way. I did however find this message:

http://mail.python.org/pipermail/c++-sig/2004-July/007826.html

Now plus or minus a few items, this is what I was looking for. It's 
rather a shame this isn't in the docs, but it's far more of a shame 
that pyste generates old code here as like I'm sure many people, I 
used pyste to teach me how to write in BPL.

I'd imagine pyste could be patched easily enough. I've added it to my 
todo list for the v0.86 release of TnFOX. As before, I'll submit the 
new version here.

Cheers,
Niall





From dave at boost-consulting.com  Tue Jun 21 04:16:46 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 20 Jun 2005 22:16:46 -0400
Subject: [C++-sig] [docs][pyste] wrapper class
References: <uaclp8zc8.fsf@boost-consulting.com>
	<42B7632D.853.31559CA@localhost>
Message-ID: <uis08e9o1.fsf_-_@boost-consulting.com>

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

> On 16 Jun 2005 at 22:57, David Abrahams wrote:
>
>> >> > Because if my C++ is going through a BPL wrapped virtual function
>> >> > and is passing it an array of unsigned int, if python doesn't
>> >> > overload it then it goes C++=>Python=>C++ and no extra action is
>> >> > required.
>> >> 
>> >> Not if you use the new-style polymorphism support.
>> >
>> > Is there a special doc page or wiki entry describing this? It has
>> > been added when I wasn't paying attention to this mailing list.
>> 
>> http://tinyurl.com/8gynk#python.class_virtual_functions
>> (http://www.boost.org/libs/python/doc/tutorial/doc/html/python/exposin
>> g.html#python.class_virtual_functions)
>> 
>> http://tinyurl.com/aknmp
>> (http://www.boost.org/libs/python/doc/v2/wrapper.html)
>> 
>> This is the recommended approach; it performs better and has fewer
>> problems in almost every way than the old one. -- Dave Abrahams Boost
>> Consulting www.boost-consulting.com
>
> None of those docs told me why the new way was any better than the 
> old way. 

That might be useful, OTOH most people reading the docs are new users;
there's no point in confusing them by discussing an "old way" of doing
things.  I think putting the a priority on recommending the best way
now was the right choice.

> I did however find this message:
>
> http://mail.python.org/pipermail/c++-sig/2004-July/007826.html
>
> Now plus or minus a few items, this is what I was looking for. It's 
> rather a shame this isn't in the docs

Well, I just went through the docs looking for a good place to put the
information about the differences between the old way and the new way,
but couldn't find one.  Any suggestions?  Can you suggest a place
where you would have actually looked for it?

> but it's far more of a shame that pyste generates old code here as
> like I'm sure many people, I used pyste to teach me how to write in
> BPL.

I tried to encourage it, as you can see.

> I'd imagine pyste could be patched easily enough. I've added it to
> my todo list for the v0.86 release of TnFOX. As before, I'll submit
> the new version here.

That'd be great, thanks.

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



From hopper at omnifarious.org  Tue Jun 21 04:58:29 2005
From: hopper at omnifarious.org (Eric Hopper)
Date: Mon, 20 Jun 2005 19:58:29 -0700
Subject: [C++-sig]  Re: Python string -> const char * + size_t
In-Reply-To: <u64wlh219.fsf@boost-consulting.com>
Message-ID: <20050621025829.GM25606@omnifarious.org>

Dave Abrahams wrote:
> Eric Hopper wrote:
>> The hash function is only going to read it and munge it a bit, so as
>> long as the data remains around for the duration of the call, it's
>> not a problem.
>>
>> I want to somehow pass a Python string to an interface something like:
>>
>> class Something {
>>  public:
>>    void hash_data(const char *data, size_t datalen);
>> };
>>
>> What is the easiest and cleanest way to make this happen using
>> boost::python?
> 
> Well, if you need the length it's a little harder.  Make a thin
> wrapper function that accepts a boost::python::str object x, then use
> 
>         x.ptr()
> 
> to get the PyObject* and use the Python/C API to get the pointer and
> length.

That worked like a charm.  I thought that might be the answer, but I was
a bit worried that ::boost::python::str made a copy.  I'm glad to learn
that it doesn't.  :-)

Thanks,
-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper at omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050620/e3299448/attachment.pgp>

From s_sourceforge at nedprod.com  Tue Jun 21 11:26:38 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 21 Jun 2005 10:26:38 +0100
Subject: [C++-sig] [docs][pyste] wrapper class
In-Reply-To: <uis08e9o1.fsf_-_@boost-consulting.com>
Message-ID: <42B7EB5E.29429.237A17@localhost>

On 20 Jun 2005 at 22:16, David Abrahams wrote:

> > None of those docs told me why the new way was any better than the
> > old way. 
> 
> That might be useful, OTOH most people reading the docs are new users;
> there's no point in confusing them by discussing an "old way" of doing
> things.  I think putting the a priority on recommending the best way
> now was the right choice.

And this is the fundamental problem with the BPL docs - it's good at 
the very high level (the tutorial) and it's good at the very low 
level (the reference manual), but there's a huge chasm in between 
filled only by the testsuite. And unfortunately, that's where a lot 
of people want to be. But well, you've heard me on this ad nauseum 
and I'm not prepared to write extensive amounts of additional docs 
for you, so I'll just shut up.

> > I did however find this message:
> >
> > http://mail.python.org/pipermail/c++-sig/2004-July/007826.html
> >
> > Now plus or minus a few items, this is what I was looking for. It's
> > rather a shame this isn't in the docs
> 
> Well, I just went through the docs looking for a good place to put the
> information about the differences between the old way and the new way,
> but couldn't find one.  Any suggestions?  Can you suggest a place
> where you would have actually looked for it?

I'd have stuck it in the tutorial where the Class Virtual Functions 
is. I would have said something like:

"There are two ways of wrapping polymorphic functions: (i) the new 
way and (ii) the old way. The pros & cons of each are <table of 
both>".

If you don't want to confuse people, you could simply mention that 
there was an old way based on call_method and the interested reader 
should go search old Boost docs or c++-sig. You should still mention 
why the new way is better. BTW, I agree wholeheartedly that the new 
way is better in every way I can see.

BTW, in this new way, if I still want the PyObject *self do I 
extract<> it in the constructor because I can't see where wrapper<> 
lets you have access to it? I ask only because my base object class 
has two special virtual functions just for python which allow 
internal code to distinguish between C++ and python wrapped object 
instances - most importantly, to gain its python side representation 
which isn't as easy with the new polymorphism support.

Another question: Does get_override() enter the python library at any 
stage? Would it be safe to call with the python GIL unlocked?

> > I'd imagine pyste could be patched easily enough. I've added it to
> > my todo list for the v0.86 release of TnFOX. As before, I'll submit
> > the new version here.
> 
> That'd be great, thanks.

It's no problem, though pyste's design makes extending it in more 
useful ways tricky. There are too many hidden dependencies and the 
IDLE debugger has an annoying knack of not seeing any changes you 
make after the first test run :(

Cheers,
Niall





From dave at boost-consulting.com  Tue Jun 21 12:51:48 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 21 Jun 2005 06:51:48 -0400
Subject: [C++-sig] [docs][pyste] wrapper class
References: <uis08e9o1.fsf_-_@boost-consulting.com>
	<42B7EB5E.29429.237A17@localhost>
Message-ID: <u7jgodltn.fsf@boost-consulting.com>

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

> And this is the fundamental problem with the BPL docs - it's good at
> the very high level (the tutorial) and it's good at the very low
> level (the reference manual), but there's a huge chasm in between
> filled only by the testsuite. And unfortunately, that's where a lot
> of people want to be.  But well, you've heard me on this ad nauseum
> and I'm not prepared to write extensive amounts of additional docs
> for you, so I'll just shut up.

Oh, I'd love to fill the gap, but I don't know what, specifically, to
do about it.

>> > I did however find this message:
>> >
>> > http://mail.python.org/pipermail/c++-sig/2004-July/007826.html
>> >
>> > Now plus or minus a few items, this is what I was looking for. It's
>> > rather a shame this isn't in the docs
>> 
>> Well, I just went through the docs looking for a good place to put the
>> information about the differences between the old way and the new way,
>> but couldn't find one.  Any suggestions?  Can you suggest a place
>> where you would have actually looked for it?
>
> I'd have stuck it in the tutorial where the Class Virtual Functions 
> is. I would have said something like:
>
> "There are two ways of wrapping polymorphic functions: (i) the new 
> way and (ii) the old way. The pros & cons of each are <table of 
> both>".

There are no pros to the old way; that's why I don't want it in the
tutorial: it's a poor investment in the future (assuming there will be
more Boost.Python users than there have been some day).  Also, it
seems to me that the only people that's going to help are those who
aren't reading the tutorial.  If you had been reading the tutorial, I
presume you would have noticed that something was different.

I could put this in the FAQ, but then it's not exactly "frequently
asked."  Maybe in the question on dangling references, although it
might be a little out of place there.

> If you don't want to confuse people, you could simply mention that 
> there was an old way based on call_method and the interested reader 
> should go search old Boost docs or c++-sig. You should still mention 
> why the new way is better. BTW, I agree wholeheartedly that the new 
> way is better in every way I can see.
>
> BTW, in this new way, if I still want the PyObject *self do I 
> extract<> it in the constructor because I can't see where wrapper<> 
> lets you have access to it? 

I wouldn't do it in the constructor unless you really want to store
another copy of it, but yeah, extract<> seems like a possibility.

> I ask only because my base object class has two special virtual
> functions just for python which allow internal code to distinguish
> between C++ and python wrapped object instances - most importantly,
> to gain its python side representation which isn't as easy with the
> new polymorphism support.

If that functionality is important, maybe we need to expose the
get_owner function to users.

> Another question: Does get_override() enter the python library at any 
> stage? 

Sure.

> Would it be safe to call with the python GIL unlocked?

I don't think so.

>> > I'd imagine pyste could be patched easily enough. I've added it to
>> > my todo list for the v0.86 release of TnFOX. As before, I'll submit
>> > the new version here.
>> 
>> That'd be great, thanks.
>
> It's no problem, though pyste's design makes extending it in more 
> useful ways tricky. There are too many hidden dependencies and the 
> IDLE debugger has an annoying knack of not seeing any changes you 
> make after the first test run :(

Yeah, you have to restart it.  I think there are better tools out
there that will start a fresh Python for each testing run, but not
sure.

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



From sheig222 at gmail.com  Wed Jun 22 09:33:36 2005
From: sheig222 at gmail.com (Ira)
Date: Wed, 22 Jun 2005 10:33:36 +0300
Subject: [C++-sig] boost::python & precomp headers problem
Message-ID: <d9b3ug$mej$1@sea.gmane.org>

Hi,

I'm new to boost so don't assume I've tried *anything* to solve this (though
I assure you I have).

First off, I'm Using VC6.

When trying to '#include <boost/python.hpp>' in cpp files it works fine.
When trying that include in the precompiled headers, I get the following

d:\visual studio projects\boost_1_32_0\boost\ref.hpp(50) : fatal error
C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 1786)
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more
information

Any way around this?

If this is the wrong group for this post, please let me know.

Thanks,
Ira





From dave at boost-consulting.com  Wed Jun 22 14:53:10 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 22 Jun 2005 08:53:10 -0400
Subject: [C++-sig] boost::python & precomp headers problem
References: <d9b3ug$mej$1@sea.gmane.org>
Message-ID: <uslzaa6yx.fsf@boost-consulting.com>

"Ira" <sheig222 at gmail.com> writes:

> Hi,
>
> I'm new to boost so don't assume I've tried *anything* to solve this (though
> I assure you I have).
>
> First off, I'm Using VC6.
>
> When trying to '#include <boost/python.hpp>' in cpp files it works fine.
> When trying that include in the precompiled headers, I get the following
>
> d:\visual studio projects\boost_1_32_0\boost\ref.hpp(50) : fatal error
> C1001: INTERNAL COMPILER ERROR
>         (compiler file 'msc1.cpp', line 1786)
>          Please choose the Technical Support command on the Visual C++
>          Help menu, or open the Technical Support help file for more
> information
>
> Any way around this?

I can't promise it will help, but the first thing I would try is to
stop using boost/python.hpp and instead #include only the individual
Boost.Python headers you need.

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



From sram at qualcomm.com  Thu Jun 23 03:23:12 2005
From: sram at qualcomm.com (Ram, Siddharth)
Date: Wed, 22 Jun 2005 18:23:12 -0700
Subject: [C++-sig] Question about Boost.Python and unsigneds
Message-ID: <EC9142D53269D6428CC3BC573E1B584602C940C4@NAEX01.na.qualcomm.com>

I have the following in my Boost Module:

#include <boost/python.hpp>
using namespace boost::python;
#include "RLPTypesPkg.h"
BOOST_PYTHON_MODULE (RLPTypesPkg)
 {
        def("RLPDEFS_CONFIG_INITIAL",RLPDEFS_CONFIG_INITIAL);
[...]


Where RLPDEFS_CONFIG_INITIAL is defined to be an unsigned int. 

When I build this, I get the following error. I was under the impression
(from the tutorial) that unsigneds are mapped to Python longs ?

Any help would be appreciated

-Siddharth

/usr/include/boost/python/make_function.hpp: In function
`boost::python::api::object boost::python::make_function(F) [with F =
unsigned int]':
/usr/include/boost/python/def.hpp:82:   instantiated from
`boost::python::api::object boost::python::detail::make_function1(T,
...) [with T = unsigned int]'
/usr/include/boost/python/def.hpp:91:   instantiated from `void
boost::python::def(const char*, Fn) [with Fn = unsigned int]'
test/boost_rlp/boost_RLPTypesPkg.cpp:6:   instantiated from here
/usr/include/boost/python/make_function.hpp:103: error: no matching
function for call to `get_signature(unsigned int&)'


From grobinson at goombah.com  Thu Jun 23 04:45:38 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Thu, 23 Jun 2005 02:45:38 +0000 (UTC)
Subject: [C++-sig] boost on OS X
Message-ID: <loom.20050623T042213-247@post.gmane.org>

Hi,

I'm a beginner with respect to boost. And I'm not too experienced with
Unix either, so my questions are newbie ones.

I'm trying to get it to install on OS X 10.3.9. After reading various
discussions on installing boost on OS X that I could find online, I
tried this:


bjam "-sPYTHON_ROOT=/System/Library/Frameworks/Python.framework"
"-sPYTHON_VERSION=2.3" "-sTOOLS=darwin" "-sRUN_ALL_TESTS=1" "test"

I got the response:

    ...found 2 targets...

And no other response. I expected to find output results in /usr/local,
but found nothing there.

Any help would be most appreciated!

Thanks,
Gary

-- 

Gary Robinson
Emergent Music, LLC
grobinson at goombah.com
Company: http://www.goombah.com
Blog:    http://www.garyrobinson.net



From mrovner at propel.com  Thu Jun 23 06:55:53 2005
From: mrovner at propel.com (Mike Rovner)
Date: Wed, 22 Jun 2005 21:55:53 -0700
Subject: [C++-sig] boost::python & precomp headers problem
In-Reply-To: <d9b3ug$mej$1@sea.gmane.org>
References: <d9b3ug$mej$1@sea.gmane.org>
Message-ID: <42BA40D9.40001@propel.com>

I tried VC6 myself and after 2 month struggling switched to VC7.1
Even with it I had to split some of my classes.
Take a look at vc.dsp/.proj to make sure you use switches which increase 
compiler internal limits.

Ira wrote:
> Hi,
> 
> I'm new to boost so don't assume I've tried *anything* to solve this (though
> I assure you I have).
> 
> First off, I'm Using VC6.
> 
> When trying to '#include <boost/python.hpp>' in cpp files it works fine.
> When trying that include in the precompiled headers, I get the following
> 
> d:\visual studio projects\boost_1_32_0\boost\ref.hpp(50) : fatal error
> C1001: INTERNAL COMPILER ERROR
>         (compiler file 'msc1.cpp', line 1786)
>          Please choose the Technical Support command on the Visual C++
>          Help menu, or open the Technical Support help file for more
> information
> 
> Any way around this?
> 
> If this is the wrong group for this post, please let me know.
> 
> Thanks,
> Ira




From dave at boost-consulting.com  Thu Jun 23 08:12:50 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 23 Jun 2005 02:12:50 -0400
Subject: [C++-sig] Question about Boost.Python and unsigneds
References: <EC9142D53269D6428CC3BC573E1B584602C940C4@NAEX01.na.qualcomm.com>
Message-ID: <uy89138kd.fsf@boost-consulting.com>

"Ram, Siddharth" <sram at qualcomm.com> writes:

> I have the following in my Boost Module:
>
> #include <boost/python.hpp>
> using namespace boost::python;
> #include "RLPTypesPkg.h"
> BOOST_PYTHON_MODULE (RLPTypesPkg)
>  {
>         def("RLPDEFS_CONFIG_INITIAL",RLPDEFS_CONFIG_INITIAL);
> [...]
>

That can't work.  

http://www.boost.org/libs/python/doc/v2/def.html#def-spec makes it
pretty clear what def requires of its 2nd argument, and an unsigned
int doesn't satisfy any of those requirements.

You might check out how the module attributes "yes" and "no" are
created in http://www.boost.org/libs/python/doc/v2/scope.html#examples

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



From dave at boost-consulting.com  Thu Jun 23 08:14:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 23 Jun 2005 02:14:57 -0400
Subject: [C++-sig] boost on OS X
References: <loom.20050623T042213-247@post.gmane.org>
Message-ID: <uslz938gu.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> Hi,
>
> I'm a beginner with respect to boost. And I'm not too experienced with
> Unix either, so my questions are newbie ones.
>
> I'm trying to get it to install on OS X 10.3.9. After reading various
> discussions on installing boost on OS X that I could find online, I
> tried this:
>
>
> bjam "-sPYTHON_ROOT=/System/Library/Frameworks/Python.framework"
> "-sPYTHON_VERSION=2.3" "-sTOOLS=darwin" "-sRUN_ALL_TESTS=1" "test"

>From which directory?

> I got the response:
>
>     ...found 2 targets...
>
> And no other response. I expected to find output results in /usr/local,
> but found nothing there.

Why did you build the "test" target?

That's not how you get results to go into /usr/local.  If you want to
"install" Boost somewhere, just follow the instructions at
http://www.boost.org/more/getting_started.html


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



From grobinson at goombah.com  Thu Jun 23 18:39:06 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Thu, 23 Jun 2005 16:39:06 +0000 (UTC)
Subject: [C++-sig] boost on OS X
References: <loom.20050623T042213-247@post.gmane.org>
	<uslz938gu.fsf@boost-consulting.com>
Message-ID: <loom.20050623T182635-306@post.gmane.org>

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

>> > That's not how you get results to go into /usr/local.  If you want to >
"install" Boost somewhere, just follow the instructions at >
http://www.boost.org/more/getting_started.html


OK, thanks... somehow I missed the obvious. Still having problems though.

I tried:

bjam "-sPYTHON_ROOT=/System/Library/Frameworks/Python.framework/Versions/2.3"
"-sPYTHON_VERSION=2.3" "-sTOOLS=darwin" install


(since without specifying the python info, it assumed I had a Python 2.2
installation; OS X 10.3 comes with Python 2.3 pre-installed).

It got stuck on

darwin-C++-action
bin/boost/libs/serialization/build/libboost_serialization.a/darwin/release/
xml_grammar.o

That is, it ate memory until it got a couple of gigs of VM and then died with
the message:

    virtual memory exhausted: Cannot allocate memory

It then continued and got stuck again on

darwin-C++-action
bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/release/
xml_wgrammar.o

at that point since it was thrashing my machine so badly it was almost unusable
and maintained that state for 20 or 30 minutes, I killed it.

Any thoughts?

Thanks,
Gary



From grafik.list at redshift-software.com  Thu Jun 23 19:23:59 2005
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Thu, 23 Jun 2005 12:23:59 -0500
Subject: [C++-sig] boost on OS X
In-Reply-To: <loom.20050623T182635-306@post.gmane.org>
References: <loom.20050623T042213-247@post.gmane.org>	<uslz938gu.fsf@boost-consulting.com>
	<loom.20050623T182635-306@post.gmane.org>
Message-ID: <42BAF02F.4070800@redshift-software.com>

Gary Robinson wrote:
> It got stuck on
> 
> darwin-C++-action
> bin/boost/libs/serialization/build/libboost_serialization.a/darwin/release/
> xml_grammar.o

Known problem, and is fixed for next release, see:

http://article.gmane.org/gmane.comp.lib.boost.user/8983
Re: Compile on OSX hangs  huge memory usage  xml grammar.o


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


From rwgk at yahoo.com  Thu Jun 23 19:51:17 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 23 Jun 2005 10:51:17 -0700 (PDT)
Subject: [C++-sig] ANN: Boost.Python bindings for OpenGL
Message-ID: <20050623175117.47840.qmail@web31503.mail.mud.yahoo.com>

The GL Toolbox (gltbx) provides Python bindings for OpenGL GL_*
and GLU_* defines, and gl*() and glu*() functions. The
original C interfaces are preserved as much as possible. Except
for the functions that may appear between calls of glBegin()
and glEnd(), OpenGL errors are converted to Python exceptions.
All functions support Python keyword arguments.

For more information visit: http://cci.lbl.gov/gltbx/


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


From grobinson at goombah.com  Thu Jun 23 20:25:54 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Thu, 23 Jun 2005 18:25:54 +0000 (UTC)
Subject: [C++-sig] boost on OS X
References: <loom.20050623T042213-247@post.gmane.org>	<uslz938gu.fsf@boost-consulting.com>
	<loom.20050623T182635-306@post.gmane.org>
	<42BAF02F.4070800@redshift-software.com>
Message-ID: <loom.20050623T202443-770@post.gmane.org>

Rene Rivera <grafik.list <at> redshift-software.com> writes:

> Known problem, and is fixed for next release, see:
> 
> http://article.gmane.org/gmane.comp.lib.boost.user/8983
> Re: Compile on OSX hangs  huge memory usage  xml grammar.o
> 

thanks for that tip -- that solved it. But I still have problems.

I got the following error messages

...failed darwin-Link-DyLib-action
bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/shared-
linkable-true/libboost_prg_exec_monitor-d-1_32.dylib...

...failed darwin-Link-DyLib-action
bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/release/shared-
linkable-true/libboost_prg_exec_monitor-1_32.dylib...

...failed darwin-Link-DyLib-action
bin/boost/libs/test/build/libboost_test_exec_monitor.dylib/darwin/debug/shared-
linkable-true/libboost_test_exec_monitor-d-1_32.dylib...

...failed darwin-Link-DyLib-action
bin/boost/libs/test/build/libboost_test_exec_monitor.dylib/darwin/release/shared
-linkable-true/libboost_test_exec_monitor-1_32.dylib...

...failed darwin-Link-DyLib-action
bin/boost/libs/test/build/libboost_unit_test_framework.dylib/darwin/debug/shared
-linkable-true/libboost_unit_test_framework-d-1_32.dylib...

...failed darwin-Link-DyLib-action
bin/boost/libs/test/build/libboost_unit_test_framework.dylib/darwin/release/
shared-linkable-true/libboost_unit_test_framework-1_32.dylib...


...failed updating 6 targets... ...skipped 6 targets... ...updated 3388
targets...


Are those failures something I need to worry about? If so can anything be done
about them?

The only piece of boost I expect to be using in the near future is boost.python,
but I'm trying to get the whole thing installed.

Thanks!
Gary





From sram at qualcomm.com  Thu Jun 23 20:46:25 2005
From: sram at qualcomm.com (Ram, Siddharth)
Date: Thu, 23 Jun 2005 11:46:25 -0700
Subject: [C++-sig] Passing messages from C++ to python
Message-ID: <EC9142D53269D6428CC3BC573E1B584602C940C8@NAEX01.na.qualcomm.com>

I  have a bunch of C++ code that has sucessfully been exported to
python. I have a question about how I could use boost to send messages
from C++ to Python. The setup is somewhat complex, please bear with me

Here is my setup:

1 or more C++ (p)threads are executing

I have started the python interpreter in another pthread

I import the .so created via boost into the interpreter (which is
attached to /dev/tty)

So now, I can call methods in the C++ threads from the python
interpreter. All commands exported to  commands result in messages being
posted on a queue. It gets picked up by the C++ thread and consumed.


Now, I would like to be able to do this from the C++ thread to Python.
Imagine that some timer expires in the C++ thread and it wants to send a
message to a listener in python. I have created another pthread which
gets signaled via a condition variable, recieves the message, and does a
PyRun_SimpleString (after grabbing the global interpreter lock and all
that good stuff). 

My question is this: How do I pass parameters from C++ to Python receive
thread ? They use the same types which I have exported to python via
Boost, but Py_BuildValue does not have a way of saying '..take this C++
object and create this corresponding PyObject which you already know
about'. The only way I can think of doing this is by writing a
conversion function, which I am trying to avoid. And I should not really
need to do this, since Python already knows the type. Can Boost help
with this?

Thanks for any help. BTW, If it is not obvious, I am a newcomer to
Boost.Python. It really rocks. Thanks to David and others for an awesome
tool.


From dave at boost-consulting.com  Thu Jun 23 20:56:07 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 23 Jun 2005 14:56:07 -0400
Subject: [C++-sig] ANN: Boost.Python bindings for OpenGL
References: <20050623175117.47840.qmail@web31503.mail.mud.yahoo.com>
Message-ID: <ud5qcucl4.fsf@boost-consulting.com>

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

> The GL Toolbox (gltbx) provides Python bindings for OpenGL GL_*
> and GLU_* defines, and gl*() and glu*() functions. The
> original C interfaces are preserved as much as possible. Except
> for the functions that may appear between calls of glBegin()
> and glEnd(), OpenGL errors are converted to Python exceptions.
> All functions support Python keyword arguments.
>
> For more information visit: http://cci.lbl.gov/gltbx/

Cool!  You should announce to comp.lang.python as well!

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



From petrucio at hoplon.com  Thu Jun 23 21:00:41 2005
From: petrucio at hoplon.com (Petrucio)
Date: Thu, 23 Jun 2005 16:00:41 -0300
Subject: [C++-sig] Passing messages from C++ to python
In-Reply-To: <EC9142D53269D6428CC3BC573E1B584602C940C8@NAEX01.na.qualcom m.com>
References: <EC9142D53269D6428CC3BC573E1B584602C940C8@NAEX01.na.qualcomm.com>
Message-ID: <6.0.2.0.1.20050623155306.01c24ec0@mail.hoplon.com>

I did not took the time to fully read your question and setup, so forgive 
me if my answer is not what you need.

But to pass parameters or call code from C++ to Python, the easiest way to 
do this is to implement a polymorphic function in C++ to receive these, and 
reimplement that in Python. Something like this:

class CppReceiver {
    public:
       virtual void receiveParameters(SomeClass parm1, ...) {}
}

Export this class and reimplement that in Python, doing whatever you want 
in it:

def class PythonReceiver:
    def receiveParameters(parm1, ...):
         ...

Now all you have to do is create an instance of that extended python class 
and pass it to the c++ code that will do the calling. When any C++ code 
calls the receiveParameters of your python create instance, the python code 
you implemented will be called.

Petrucio

At 15:46 23/6/2005, you wrote:
>I  have a bunch of C++ code that has sucessfully been exported to
>python. I have a question about how I could use boost to send messages
>from C++ to Python. The setup is somewhat complex, please bear with me
>
>Here is my setup:
>
>1 or more C++ (p)threads are executing
>
>I have started the python interpreter in another pthread
>
>I import the .so created via boost into the interpreter (which is
>attached to /dev/tty)
>
>So now, I can call methods in the C++ threads from the python
>interpreter. All commands exported to  commands result in messages being
>posted on a queue. It gets picked up by the C++ thread and consumed.
>
>
>Now, I would like to be able to do this from the C++ thread to Python.
>Imagine that some timer expires in the C++ thread and it wants to send a
>message to a listener in python. I have created another pthread which
>gets signaled via a condition variable, recieves the message, and does a
>PyRun_SimpleString (after grabbing the global interpreter lock and all
>that good stuff).
>
>My question is this: How do I pass parameters from C++ to Python receive
>thread ? They use the same types which I have exported to python via
>Boost, but Py_BuildValue does not have a way of saying '..take this C++
>object and create this corresponding PyObject which you already know
>about'. The only way I can think of doing this is by writing a
>conversion function, which I am trying to avoid. And I should not really
>need to do this, since Python already knows the type. Can Boost help
>with this?
>
>Thanks for any help. BTW, If it is not obvious, I am a newcomer to
>Boost.Python. It really rocks. Thanks to David and others for an awesome
>tool.
>_______________________________________________
>C++-sig mailing list
>C++-sig at python.org
>http://mail.python.org/mailman/listinfo/c++-sig



From seefeld at sympatico.ca  Thu Jun 23 21:01:26 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 23 Jun 2005 15:01:26 -0400
Subject: [C++-sig] Passing messages from C++ to python
In-Reply-To: <EC9142D53269D6428CC3BC573E1B584602C940C8@NAEX01.na.qualcomm.com>
References: <EC9142D53269D6428CC3BC573E1B584602C940C8@NAEX01.na.qualcomm.com>
Message-ID: <42BB0706.4030601@sympatico.ca>

Ram, Siddharth wrote:

> My question is this: How do I pass parameters from C++ to Python receive
> thread ? They use the same types which I have exported to python via
> Boost, but Py_BuildValue does not have a way of saying '..take this C++
> object and create this corresponding PyObject which you already know
> about'. The only way I can think of doing this is by writing a
> conversion function, which I am trying to avoid. And I should not really
> need to do this, since Python already knows the type. Can Boost help
> with this?

I'm not sure this is really boost-related. I would use the same design
as with a pure C++ application, i.e. let the application code bind
callbacks to the consumer threads (or the tasks) so they can get
called during or after task processing.

Here this means that you provide python callbacks that derive from a
C++ callback base class, such that registering them in python results
in their C++ base object being registered with the C++ harness internally.

The conversion between python and C++ of these callback types is then
done automatically by boost.python.

HTH,
		Stefan


From grobinson at goombah.com  Thu Jun 23 21:45:58 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Thu, 23 Jun 2005 19:45:58 +0000 (UTC)
Subject: [C++-sig] boost on OS X
References: <loom.20050623T042213-247@post.gmane.org>	<uslz938gu.fsf@boost-consulting.com>
	<loom.20050623T182635-306@post.gmane.org>
	<42BAF02F.4070800@redshift-software.com>
Message-ID: <loom.20050623T214541-814@post.gmane.org>


Despite the errors reported earlier, I decided to go ahead and try the tutorial
for boost.python.

In libs/python/example/tutoral, I did:


bjam   "-sPYTHON_ROOT=/System/Library/Frameworks/Python.framework/Versions/2.3"
"-sPYTHON_VERSION=2.3" "-sTOOLS=darwin" ...found 1715 targets... ...updating 5
targets... MkDir1
../../../../bin/boost/libs/python/example/tutorial/hello.so/darwin MkDir1
../../../../bin/boost/libs/python/example/tutorial/hello.so/darwin/debug MkDir1
../../../../bin/boost/libs/python/example/tutorial/hello.so/darwin/debug/shared-
linkable-true darwin-C++-action
../../../../bin/boost/libs/python/example/tutorial/hello.so/darwin/debug/shared-
linkable-true/hello.o darwin-Link-action
../../../../bin/boost/libs/python/example/tutorial/hello.so/darwin/debug/shared-
linkable-true/hello.so Chmod1
../../../../bin/boost/libs/python/example/tutorial/hello.so/darwin/debug/shared-
linkable-true/hello.so ...updated 5 targets...

It looked like it worked.

The tutoral says that it was supposed to have made libboost_python.so and
hello.so.

It did in fact make hello.so, but I could find no trace of libboost_python.so on
my hard drive. When I tried to import hello.so, I got:

ImportError: Failure linking new module:
../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/debug/shared-
linkable-true/libboost_python.dylib: dyld: python can't open library:
../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/debug/shared-
linkable-true/libboost_python.dylib  (No such file or directory, errno = 2)


This confused me a bit because I thought it was going to want libboost_python.so
rather than libboost_python.dylib, and also because libboost_python.dylib
actually is in a directory with the specified path ending:

ls -l
~/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.dylib/darwin/
debug/shared-linkable-true/libboost_python.dylib -rwxr-xr-x  1 root  staff 
5253136 23 Jun 11:55
/Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.
dylib/darwin/debug/shared-linkable-true/libboost_python.dylib


So now I'm pretty mystified.

Any help would be most appreciated.

Thanks, Gary




From grobinson at goombah.com  Thu Jun 23 22:45:31 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Thu, 23 Jun 2005 20:45:31 +0000 (UTC)
Subject: [C++-sig] boost on OS X
References: <loom.20050623T042213-247@post.gmane.org>	<uslz938gu.fsf@boost-consulting.com>
	<loom.20050623T182635-306@post.gmane.org>
	<42BAF02F.4070800@redshift-software.com>
	<loom.20050623T214541-814@post.gmane.org>
Message-ID: <loom.20050623T224110-551@post.gmane.org>

In case it's helpful, I ran otool -L hello.so

and got:



/System/Library/Frameworks/Python.framework/Versions/2.3/Python
(compatibility version 2.3.0, current version 2.3.0)

../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/debug/shared-
linkable-true/ libboost_python.dylib (compatibility version 0.0.0, current
version 0.0.0) 

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.1.3)


All three files are in the locations specified, as long as ../../.. represents
the top level boost folder (the folder extracted from the original boost
download). I ran the tutorial example from its original location nested in that
folder.

Gary



From beyer at imb-jena.de  Fri Jun 24 03:29:42 2005
From: beyer at imb-jena.de (Andreas Beyer)
Date: Thu, 23 Jun 2005 18:29:42 -0700
Subject: [C++-sig] wrapping a to_python_converter
Message-ID: <42BB6206.4070305@imb-jena.de>

Assume I have a class A and a shared pointer to it A_ptr. BP converts 
A_ptr correctly to python after regestring the pointer:
BOOST_PYTHON_MODULE(ptr_test) {
   ...
   python::register_ptr_to_python< A::A_ptr >();
   ...
}

Now, I want to call a function f() each time a pointer of type A_ptr is 
returned to python. The function f() does not modify A, nor does it 
change the way A's should be converted to python. In fact, f() only 
registers the pointer (see below).
I guess I would somehow have to wrap the existing converter. Is that the 
correct idea?
But "where" is this converter? (Thus, how/where does the 
register_ptr_to_python template create and register the actual 
converter?) Does anybody have an example of such wrapped 
to_python_converter?
The questions may sound a bit stupid, but I never have done anything 
low-level with BP. Specifically I never wrote a to_python_converter.

In the concrete example I want to call this function before returning A_ptr:

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

Here python::object(x) will call the to_python_converter. Thus, if 
hold_python() would be called from within a to_python_converter I would 
have to avoid recursion, right? I guess hold_python() must explicitely 
call the standard to_python_converter. How do I do that?

Thanks!!
    Andreas



From grobinson at goombah.com  Fri Jun 24 18:23:55 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Fri, 24 Jun 2005 16:23:55 +0000 (UTC)
Subject: [C++-sig] OS X boost.python tutorial question
Message-ID: <loom.20050624T182145-894@post.gmane.org>



Some of this is a repeat of an early question, but I really need an answer if
one is available to be had. We want to use boost.py in our product, Goombah
(http://www.python.com). We have it working on Windows, and have C code working
in the product that uses boost.python on Windows. But we need it to work on OS X
too if we're going to use it, since Goombah is a cross-platform product.

I have built boost.python successfully (at least it gives no "failure" or
"skipped" messages). I did it by going to the root boost directory and entering:

bjam "-sPYTHON_ROOT=/System/Library/Frameworks/Python.framework/Versions/2.3"
"-sPYTHON_VERSION=2.3" "-sTOOLS=darwin" "-sBUILD=debug release"

I then went to the ../examples/tutorial folder and ran bjam with the same
arguments, and that  too seemed to complete successfully.

hello.so was created and was in the directory
/Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/example/tutorial/hello
.so/darwin/release/shared-linkable-true/hello.so

However the tutorial text explicitly states that libboost_python.so will be
created too. No such file was created.  I don't know whether the it's the
documentation that's in error or whether something didn't work right in the
build. Can someone tell me which is the case?

When I enter interactive python and try to import the hello module, I get:

 import hello Traceback (most recent call last): File "<stdin>", line 1, in ?
ImportError: Failure linking new module:
../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/release/shared
-linkable-true/libboost_python.dylib: dyld: python can't open library:
../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/release/shared
-linkable-true/libboost_python.dylib  (No such file or directory, errno = 2)


libboost_python.dylib was created, and is in the stated location (if ../../..
means ~/Desktop/boost_1_32_0/ on my machine). So I don't know why it's giving me
an error:

ls -l
~/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.dylib/darwin/
release/shared-linkable-true/libboost_python.dylib -rwxr-xr-x  1 root  staff 
1102392 24 Jun 09:53
/Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.
dylib/darwin/release/shared-linkable-true/libboost_python.dylib
Gary-Robinsons-Computer:~/Desktop/boost_1_32_0/bin/boost/libs/python/example/
tutorial/hello.so/darwin/release/shared-linkable-true garyrob$


If anyone can help me get the tutorial working I'd really appreciate it.

Gary



From patrick.hartling at gmail.com  Fri Jun 24 21:50:31 2005
From: patrick.hartling at gmail.com (Patrick Hartling)
Date: Fri, 24 Jun 2005 14:50:31 -0500
Subject: [C++-sig] OS X boost.python tutorial question
In-Reply-To: <loom.20050624T182145-894@post.gmane.org>
References: <loom.20050624T182145-894@post.gmane.org>
Message-ID: <944f7d8e05062412504046e8fe@mail.gmail.com>

On 6/24/05, Gary Robinson <grobinson at goombah.com> wrote:
> 
> 
> Some of this is a repeat of an early question, but I really need an answer if
> one is available to be had. We want to use boost.py in our product, Goombah
> (http://www.python.com). We have it working on Windows, and have C code working
> in the product that uses boost.python on Windows. But we need it to work on OS X
> too if we're going to use it, since Goombah is a cross-platform product.
> 
> I have built boost.python successfully (at least it gives no "failure" or
> "skipped" messages). I did it by going to the root boost directory and entering:
> 
> bjam "-sPYTHON_ROOT=/System/Library/Frameworks/Python.framework/Versions/2.3"
> "-sPYTHON_VERSION=2.3" "-sTOOLS=darwin" "-sBUILD=debug release"
> 
> I then went to the ../examples/tutorial folder and ran bjam with the same
> arguments, and that  too seemed to complete successfully.
> 
> hello.so was created and was in the directory
> /Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/example/tutorial/hello
> .so/darwin/release/shared-linkable-true/hello.so
> 
> However the tutorial text explicitly states that libboost_python.so will be
> created too. No such file was created.  I don't know whether the it's the
> documentation that's in error or whether something didn't work right in the
> build. Can someone tell me which is the case?
> 
> When I enter interactive python and try to import the hello module, I get:
> 
>  import hello Traceback (most recent call last): File "<stdin>", line 1, in ?
> ImportError: Failure linking new module:
> ../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/release/shared
> -linkable-true/libboost_python.dylib: dyld: python can't open library:
> ../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/release/shared
> -linkable-true/libboost_python.dylib  (No such file or directory, errno = 2)
> 
> 
> libboost_python.dylib was created, and is in the stated location (if ../../..
> means ~/Desktop/boost_1_32_0/ on my machine). So I don't know why it's giving me
> an error:
> 
> ls -l
> ~/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.dylib/darwin/
> release/shared-linkable-true/libboost_python.dylib -rwxr-xr-x  1 root  staff
> 1102392 24 Jun 09:53
> /Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.
> dylib/darwin/release/shared-linkable-true/libboost_python.dylib
> Gary-Robinsons-Computer:~/Desktop/boost_1_32_0/bin/boost/libs/python/example/
> tutorial/hello.so/darwin/release/shared-linkable-true garyrob$
> 
> 
> If anyone can help me get the tutorial working I'd really appreciate it.

Do you have the directory
/Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.dylib/darwin/release/shared-linkable-true
in your $DYLD_LIBRARY_PATH environment variable?

 -Patrick


-- 
Patrick L. Hartling
http://www.137.org/patrick/


From dave at boost-consulting.com  Sat Jun 25 17:22:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 25 Jun 2005 11:22:45 -0400
Subject: [C++-sig] OS X boost.python tutorial question
References: <loom.20050624T182145-894@post.gmane.org>
Message-ID: <ur7eqcvga.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> Some of this is a repeat of an early question, but I really need an answer if
> one is available to be had. We want to use boost.py in our product, Goombah
> (http://www.python.com). 

Gary, are you sure you meant to insert that URL?

  http://goombah.emergentmusic.com/

seems like a more likely choice.

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



From grobinson at goombah.com  Sat Jun 25 22:40:53 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Sat, 25 Jun 2005 16:40:53 -0400
Subject: [C++-sig] OS X boost.python tutorial question
In-Reply-To: <200506251740.j5PHe2B19584@transpose.com>
References: <200506251740.j5PHe2B19584@transpose.com>
Message-ID: <20050625164053.645092.ae5834ba@goombah.com>

>>  Some of this is a repeat of an early question, but I really need an
>>  answer if one is available to be had. We want to use boost.py in our
>>  product, Goombah (http://www.python.com). ...

Er... I meant http://www.goombah.com... www.python.com is a "notorious 
porn site," Tim Peters informs me... guess my fingers weren't paying 
much attention to my brain...

Gary


From grobinson at goombah.com  Sat Jun 25 23:28:46 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Sat, 25 Jun 2005 17:28:46 -0400
Subject: [C++-sig] OS X boost.python tutorial question
Message-ID: <20050625172846.371782.c084a7d5@goombah.com>

> 
> Do you have the directory
> 
/Users/garyrob/Desktop/boost_1_32_0/bin/boost/libs/python/build/libboost_python.dylib/darwin/release/shared-linkable-true
> in your $DYLD_LIBRARY_PATH environment variable?

No, I didn't  -- and in fact I never heard of DYLD_LIBRARY_PATH before. 
I am truly a newbie. A complete newbie to boost, but 99.5% a newbie to 
unix development as well. Thanks for the tip!

But the thing that made it counterintuitive to me that to think that it 
might be a matter of the path is the fact that when I tried to 

    import hello

it told me it couldn't load the libboost_python.dylib file, and the 
error message named the exact location where it really was. If it knows 
exactly where it is, why does it need an environment variable with the 
path? I guess DYLD_LIBRARY_PATH must "bless" the directories it lists 
to make their contents OK for use as dynamic libraries? Dunno. I found 
some docs on it on Apple's site and will read about it.

The remaining mystery is that the tutorial docs say that 
libboost_python.so should have been produced, but in fact 
libboost_python.pylib was produced. 
(http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html). 
I'm not sure if the docs are wrong or if I'm missing something.


Gary

-- 

Gary Robinson
CEO
Transpose, LLC
grobinson at transpose.com
207-942-3463
Company: http://transpose.com
Blog:    http://www.garyrobinson.net


From dave at boost-consulting.com  Sun Jun 26 02:36:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 25 Jun 2005 20:36:57 -0400
Subject: [C++-sig] OS X boost.python tutorial question
References: <20050625172846.371782.c084a7d5@goombah.com>
Message-ID: <uaclear86.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> The remaining mystery is that the tutorial docs say that 
> libboost_python.so should have been produced, but in fact 
> libboost_python.pylib was produced. 
> (http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html). 
> I'm not sure if the docs are wrong or if I'm missing something.

The docs were written for every other *nix system on the planet ;-)
Apple decided to make up their own extension for dynamic libraries, so
it doesn't quite fit.

Joel, maybe you could add a note to the page in question for OS X?

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



From grobinson at goombah.com  Sun Jun 26 14:53:08 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Sun, 26 Jun 2005 08:53:08 -0400
Subject: [C++-sig] OS X boost.python tutorial question
Message-ID: <20050626085308.521448.eb57207c@goombah.com>


>> The remaining mystery is that the tutorial docs say that 
>> libboost_python.so should have been produced, but in fact 
>> libboost_python.pylib was produced. 
>> 
> (http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html). 
>> I'm not sure if the docs are wrong or if I'm missing something.
> 
> The docs were written for every other *nix system on the planet ;-)
> Apple decided to make up their own extension for dynamic libraries, so
> it doesn't quite fit.

Er.... obviously I meant libboost_python.dylib, not .pylib.

I read through the Apple docs on finding dynamically-linked libraries 
and I  now understand why it couldn't find the dylib originally and why 
it could when I set DYLD_LIBRARY_PATH. BUT I don't understand why it 
originally tried to find it at a relative path that was not where the 
file was. Is that due to an incompatibility between OS X and other 
Unixes, or is there an error in the tutorial code, or was there no way 
to make it work "out of the box" when hello.so is loaded, or is there 
something else I'm missing?

Gary


From grobinson at goombah.com  Sun Jun 26 15:01:34 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Sun, 26 Jun 2005 09:01:34 -0400
Subject: [C++-sig] Boost tutorial Jamfile discrepancy
Message-ID: <20050626090134.994194.5b1d3680@goombah.com>

http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html 
says that the Jamfile for hello.cpp is

    subproject libs/python/example/tutorial ;

    SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
    include python.jam ;

    extension hello                     # Declare a Python extension 
called hello
    :   hello.cpp                       # source
        <dll>../../build/boost_python   # dependencies
        ;


However the actual contents are:

    #   Hello World Example from the tutorial
    #   [Joel de Guzman 10/9/2002]
    
    #   Specify our location in the boost project hierarchy
    subproject libs/python/example/tutorial ;
    
    #   Include definitions needed for Python modules
    import python ;
    
    extension hello                     # Declare a Python extension 
called hello
    :   hello.cpp                       # source
        <dll>../../build/boost_python   # dependencies
        ;

They are quite different -- which is correct?

Gary


From grafik.list at redshift-software.com  Sun Jun 26 16:31:56 2005
From: grafik.list at redshift-software.com (Rene Rivera)
Date: Sun, 26 Jun 2005 09:31:56 -0500
Subject: [C++-sig] Boost tutorial Jamfile discrepancy
In-Reply-To: <20050626090134.994194.5b1d3680@goombah.com>
References: <20050626090134.994194.5b1d3680@goombah.com>
Message-ID: <42BEBC5C.2010902@redshift-software.com>

Gary Robinson wrote:
> http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html 
> says that the Jamfile for hello.cpp is
> 
>     subproject libs/python/example/tutorial ;
> 
>     SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
>     include python.jam ;
> 
>     extension hello                     # Declare a Python extension 
> called hello
>     :   hello.cpp                       # source
>         <dll>../../build/boost_python   # dependencies
>         ;
> 
> 
> However the actual contents are:
> 
>     #   Hello World Example from the tutorial
>     #   [Joel de Guzman 10/9/2002]
>     
>     #   Specify our location in the boost project hierarchy
>     subproject libs/python/example/tutorial ;
>     
>     #   Include definitions needed for Python modules
>     import python ;
>     
>     extension hello                     # Declare a Python extension 
> called hello
>     :   hello.cpp                       # source
>         <dll>../../build/boost_python   # dependencies
>         ;
> 
> They are quite different -- which is correct?

They don't look that different to me ;-) And they are both "correct".

* The "extension" declaration is the same.
* The "subproject" declaration is the same.
* The "import" vs. "SEARCH"+"include" is historical. The 
"SEARCH"+"include" was a recurring pattern so we introduced the "import" 
shortcut for it. And improved it along the way.


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


From dave at boost-consulting.com  Sun Jun 26 19:53:26 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 26 Jun 2005 13:53:26 -0400
Subject: [C++-sig] Boost tutorial Jamfile discrepancy
References: <20050626090134.994194.5b1d3680@goombah.com>
Message-ID: <ull4x80o9.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html 
> says that the Jamfile for hello.cpp is
>
>     subproject libs/python/example/tutorial ;
>
>     SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
>     include python.jam ;
>
>     extension hello                     # Declare a Python extension 
> called hello
>     :   hello.cpp                       # source
>         <dll>../../build/boost_python   # dependencies
>         ;
>
>
> However the actual contents are:
>
>     #   Hello World Example from the tutorial
>     #   [Joel de Guzman 10/9/2002]
>
>     #   Specify our location in the boost project hierarchy

Comments, irrelevant to the tutorial.

>     subproject libs/python/example/tutorial ;

Identical
>     #   Include definitions needed for Python modules
>     import python ;

An equivalent but more modern version of the incantation about
involving SEARCH and include.  

>     extension hello                     # Declare a Python extension 
> called hello
>     :   hello.cpp                       # source
>         <dll>../../build/boost_python   # dependencies
>         ;

Identical.

So, they're both correct; the 2nd one is more correct than the 1st
one.  However, the one in the CVS tutorial is even more correct (and
it matches the CVS Jamfile):

  http://www.boost-consulting.com/boost/libs/python/doc/tutorial/doc/html/python/hello.html

However, what's missing from this tutorial is the setting up of a
boost-build.jam file that points at the Boost build system.  You can
put one anywhere in your directory hierarchy at or above the location
of the Jamrules file.  It should contain:

  boost-build path-to-your-booost-installation/tools/build/v1 ;

where path-to-your-booost-installation is the (absolute or relative)
path to the top-level directory of Boost containing a subdirectory
called "tools/".

[Joel, would you be able to add this info to the tutorial before the
 release?  The phraseology I've used here would work nicely.
]


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



From grobinson at goombah.com  Mon Jun 27 00:48:45 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Sun, 26 Jun 2005 18:48:45 -0400
Subject: [C++-sig] double vs float in Py_BuildValue
Message-ID: <20050626184845.293925.1d5c500c@goombah.com>

I'm having a problem I think is fairly bizarre using Py_BuildValue 
(note, this code isn't presently using boost.python, it's the straight 
Python-C interface).

Here's an example c module:

> #include <Python.h>
> static float         gfSumChiSquare = 0.0; 
>     
>         
> static PyObject *    
> getSumChiSquare(PyObject *self, PyObject *args){
>     return Py_BuildValue("f", gfSumChiSquare);
>     }
>     
> static PyMethodDef SimMethods[] = {
>     {"getSumChiSquare", getSumChiSquare, METH_NOARGS, "Return 
> fSumChiSquare"},
>     {NULL, NULL, 0, NULL}        /* Sentinel */
> };
> 
> PyMODINIT_FUNC
> inittestfloat(void)
> {
>     (void) Py_InitModule("testfloat", SimMethods);
> }
> 
> 

If the float, gfSumChiSquare, is defined as a float, as above, it works 
fine.


But  if I turn it into a double:

    static double         gfSumChiSquare = 0.0; 
 ...
    static PyObject *    
    getSumChiSquare(PyObject *self, PyObject *args){
        return Py_BuildValue("d", gfSumChiSquare);
        }
 ...


I get a bus error when I call it from Python.


I'm extremely rusty in C, not having used it in about 7 years, so maybe 
that's what's responsible. But I would appreciate some insight here!

As always, in appreciation the help I find in this sig,
Gary


From dave at boost-consulting.com  Mon Jun 27 01:31:24 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 26 Jun 2005 19:31:24 -0400
Subject: [C++-sig] double vs float in Py_BuildValue
References: <20050626184845.293925.1d5c500c@goombah.com>
Message-ID: <u1x6o8zlf.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> If the float, gfSumChiSquare, is defined as a float, as above, it works 
> fine.
>
>
> But  if I turn it into a double:
>
>     static double         gfSumChiSquare = 0.0; 
>  ...
>     static PyObject *    
>     getSumChiSquare(PyObject *self, PyObject *args){
>         return Py_BuildValue("d", gfSumChiSquare);
>         }
>  ...
>
>
> I get a bus error when I call it from Python.
>
>
> I'm extremely rusty in C, not having used it in about 7 years, so maybe 
> that's what's responsible. But I would appreciate some insight here!

What I remember (without looking it up) is that floats and doubles are
both passed as doubles in C.  So the format character for a double
should also be "f."  I'm guessing "d" indicates an int or something.


Oh, well, according to http://docs.python.org/api/arg-parsing.html:

"d" (float) [double]
    Convert a C double to a Python floating point number.

"f" (float) [float]
    Same as "d".

So I don't know what to tell ya.  I'm guessing you have a bug
elsewhere in your code.  Throw a debugger at it? Purify?

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



From djowel at gmail.com  Mon Jun 27 01:38:06 2005
From: djowel at gmail.com (Joel de Guzman)
Date: Mon, 27 Jun 2005 07:38:06 +0800
Subject: [C++-sig] Boost tutorial Jamfile discrepancy
In-Reply-To: <ull4x80o9.fsf@boost-consulting.com>
References: <20050626090134.994194.5b1d3680@goombah.com>
	<ull4x80o9.fsf@boost-consulting.com>
Message-ID: <42BF3C5E.8010102@boost-consulting.com>

David Abrahams wrote:

> [Joel, would you be able to add this info to the tutorial before the
>  release?  The phraseology I've used here would work nicely.
> ]

Ok. Sure, I'll give it a shot.

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


From jan.heiser at raubtierbaendiger.de  Mon Jun 27 11:15:32 2005
From: jan.heiser at raubtierbaendiger.de (Jan Heiser)
Date: Mon, 27 Jun 2005 11:15:32 +0200
Subject: [C++-sig] Embedding: Creating a Python object with BPL
Message-ID: <d9ofmh$knl$1@sea.gmane.org>

Hi,

I need to create a Python object (that is completely defined in a python
module) from C++. I can import the module, find the class object and (in
other routines) can access the data and methods of objects. I can even use
the class object to check the validity of objects (using
PyObject_IsInstance). However, I did not find a way to create a new object
based on this class object.

Is there a way with BPL to call the class' constructor somehow? Failing
that, how can one do that using the Python C-API? I can only find
constructors for basic types in there.

There is Py_ObjectNew() but that does take a PyTypeObject* which I don't
have (can I get it from the class object?). Furthermore, I don't see a way
to specify constructor arguments in the call.

Jan.
-- 
<jan.heiser at raubtierbaendiger.de>



From seefeld at sympatico.ca  Mon Jun 27 11:46:11 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 27 Jun 2005 05:46:11 -0400
Subject: [C++-sig] Embedding: Creating a Python object with BPL
In-Reply-To: <d9ofmh$knl$1@sea.gmane.org>
References: <d9ofmh$knl$1@sea.gmane.org>
Message-ID: <42BFCAE3.9000109@sympatico.ca>

Jan Heiser wrote:
> Hi,
> 
> I need to create a Python object (that is completely defined in a python
> module) from C++. I can import the module, find the class object and (in
> other routines) can access the data and methods of objects. I can even use
> the class object to check the validity of objects (using
> PyObject_IsInstance). However, I did not find a way to create a new object
> based on this class object.
> 
> Is there a way with BPL to call the class' constructor somehow? Failing

Just call it !

boost::python::object cls = ...
boost::python::object instance = cls();

> that, how can one do that using the Python C-API? I can only find
> constructors for basic types in there.

Regards,
		Stefan



From jan.heiser at raubtierbaendiger.de  Mon Jun 27 14:23:59 2005
From: jan.heiser at raubtierbaendiger.de (Jan Heiser)
Date: Mon, 27 Jun 2005 14:23:59 +0200
Subject: [C++-sig] Embedding: Creating a Python object with BPL
References: <d9ofmh$knl$1@sea.gmane.org> <42BFCAE3.9000109@sympatico.ca>
Message-ID: <d9oqnq$khi$1@sea.gmane.org>

Stefan Seefeld wrote:

> Jan Heiser wrote:
>> Is there a way with BPL to call the class' constructor somehow? Failing
> 
> Just call it !
> 
> boost::python::object cls = ...
> boost::python::object instance = cls();

Thanks a lot, sometimes the answer is too simple to find ;-) !

Jan.
-- 
<jan.heiser at raubtierbaendiger.de>



From grobinson at goombah.com  Mon Jun 27 15:27:15 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Mon, 27 Jun 2005 09:27:15 -0400
Subject: [C++-sig] double vs float in Py_BuildValue
In-Reply-To: <u1x6o8zlf.fsf@boost-consulting.com>
References: <20050626184845.293925.1d5c500c@goombah.com>
	<u1x6o8zlf.fsf@boost-consulting.com>
Message-ID: <20050627092715.993427.f8238a35@goombah.com>


I played around with it some more. Although initially I got a bus error 
with doubles and not with floats, it eventually appeared that the 
function was simply being unreliable.

Another change seemed to make it reliable. Originally registering 
getSumChiSquare() with METH_NOARGS in PyMethodDef, and did not call 
PyArg_ParseTuple.

That is I had:

#include <Python.h>
static  double         gfSumChiSquare = 123.0; 
            
static PyObject *    
getSumChiSquare(PyObject *self, PyObject *args){
    return Py_BuildValue("d", gfSumChiSquare);
    }
    
static PyMethodDef SimMethods[] = {
    {"getSumChiSquare", getSumChiSquare, METH_NOARGS, "Return 
fSumChiSquare"},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};

PyMODINIT_FUNC
inittestfloat(void)
{
    (void) Py_InitModule("testfloat", SimMethods);
}

That caused a bus error 100% of the time when I simply imported the 
module into Python and called getSumChiSquare().

Now I use METH_VARARGS, and parse the non-existent args with 
PyArg_ParseTuple:

#include <Python.h>
static  double         gfSumChiSquare = 123.0; 
            
static PyObject *    
getSumChiSquare(PyObject *self, PyObject *args){
    if (!PyArg_ParseTuple(args, "", NULL))
        return NULL;    
    return Py_BuildValue("d", gfSumChiSquare);
    }
    
static PyMethodDef SimMethods[] = {
    {"getSumChiSquare", getSumChiSquare, METH_VARARGS, "Return 
fSumChiSquare"},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};

PyMODINIT_FUNC
inittestfloat(void)
{
    (void) Py_InitModule("testfloat", SimMethods);
}


This approach seems to work reliably -- at least variations I've tried 
haven't caused a bus error. But I haven't been able to discern an 
explanation from the docs as to why this would be better. The docs say 
that both METH_VARARGS and METH_NOARGS expect a PyCFunction. So if I am 
calling the function with no arguments, why can't I use METH_NOARGS and 
skip the call to PyArg_ParseTuple?

Of course it may be that it's only due to random chance that this 
change "seems" to fix the problem so far.

Gary

-- 

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

On Sun, 26 Jun 2005 19:31:24 -0400, David Abrahams wrote:
> Gary Robinson <grobinson at goombah.com> writes:
> 
>>  If the float, gfSumChiSquare, is defined as a float, as above, it works 
>>  fine.
>> 
>> 
>>  But  if I turn it into a double:
>> 
>>      static double         gfSumChiSquare = 0.0; 
>>   ...
>>      static PyObject *    
>>      getSumChiSquare(PyObject *self, PyObject *args){
>>          return Py_BuildValue("d", gfSumChiSquare);
>>          }
>>   ...
>> 
>> 
>>  I get a bus error when I call it from Python.
>> 
>> 
>>  I'm extremely rusty in C, not having used it in about 7 years, so maybe 
>>  that's what's responsible. But I would appreciate some insight here!
> 
> What I remember (without looking it up) is that floats and doubles are
> both passed as doubles in C.  So the format character for a double
> should also be "f."  I'm guessing "d" indicates an int or something.
> 
> 
> Oh, well, according to http://docs.python.org/api/arg-parsing.html:
> 
> "d" (float) [double]
>     Convert a C double to a Python floating point number.
> 
> "f" (float) [float]
>     Same as "d".
> 
> So I don't know what to tell ya.  I'm guessing you have a bug
> elsewhere in your code.  Throw a debugger at it? Purify?


From markus.schoepflin at comsoft.de  Mon Jun 27 16:30:20 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Mon, 27 Jun 2005 16:30:20 +0200
Subject: [C++-sig] Wrapping classical C API for python access
Message-ID: <d9p24n$d7u$1@sea.gmane.org>

I'm currently in the process of evaluating how feasible it would be to use 
boost.python to expose a classical C API to python.

By classical C API I mean that most arguments are passed around as pointers 
(both in and out), and nearly every function has an int return value for 
the error code.

How do I deal with functions using pointers as out parameters? Given, for 
example, the function "int test(char const *s, int *p)" where p is an out 
parameter, I can easily wrap it with BP using test("foo", foo).

But when trying to call this function from python, I keep getting the 
following error:

 >>> a = int(0)
 >>> print test("foo", a)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
     pyubss.test(str, int)
did not match C++ signature:
     test(char*, int*)

So how do I specify that p is an out parameter? How do I have to call the 
function in Python? Is it possible?

TIA, Markus



From dave at boost-consulting.com  Mon Jun 27 17:09:56 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 27 Jun 2005 11:09:56 -0400
Subject: [C++-sig] double vs float in Py_BuildValue
References: <20050626184845.293925.1d5c500c@goombah.com>
	<u1x6o8zlf.fsf@boost-consulting.com>
	<20050627092715.993427.f8238a35@goombah.com>
Message-ID: <u4qbj4z0b.fsf@boost-consulting.com>

Gary Robinson <grobinson at goombah.com> writes:

> This approach seems to work reliably -- at least variations I've tried 
> haven't caused a bus error. But I haven't been able to discern an 
> explanation from the docs as to why this would be better. The docs say 
> that both METH_VARARGS and METH_NOARGS expect a PyCFunction. So if I am 
> calling the function with no arguments, why can't I use METH_NOARGS and 
> skip the call to PyArg_ParseTuple?
>
> Of course it may be that it's only due to random chance that this 
> change "seems" to fix the problem so far.

This seems like a Python problem (or a usage error on your part, like
linking with the wrong Python library) that should be reported to the
Python-dev mailing list.  Or at least, you should ask on
comp.lang.python.

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



From grobinson at goombah.com  Mon Jun 27 17:20:39 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Mon, 27 Jun 2005 11:20:39 -0400
Subject: [C++-sig] double vs float in Py_BuildValue
In-Reply-To: <u4qbj4z0b.fsf@boost-consulting.com>
References: <20050626184845.293925.1d5c500c@goombah.com>
	<u1x6o8zlf.fsf@boost-consulting.com>
	<20050627092715.993427.f8238a35@goombah.com>
	<u4qbj4z0b.fsf@boost-consulting.com>
Message-ID: <20050627112039.026945.1df8ecc3@goombah.com>

> This seems like a Python problem (or a usage error on your part, like
> linking with the wrong Python library) that should be reported to the
> Python-dev mailing list.  Or at least, you should ask on
> comp.lang.python.

OK,  I'll take this one over there. Thanks.

Gary

-- 

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

O


From dave at boost-consulting.com  Mon Jun 27 17:19:50 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 27 Jun 2005 11:19:50 -0400
Subject: [C++-sig] Wrapping classical C API for python access
References: <d9p24n$d7u$1@sea.gmane.org>
Message-ID: <uy88v3jzd.fsf@boost-consulting.com>

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

> I'm currently in the process of evaluating how feasible it would be to use 
> boost.python to expose a classical C API to python.
>
> By classical C API I mean that most arguments are passed around as pointers 
> (both in and out), and nearly every function has an int return value for 
> the error code.
>
> How do I deal with functions using pointers as out parameters? Given, for 
> example, the function "int test(char const *s, int *p)" where p is an out 
> parameter, I can easily wrap it with BP using test("foo", foo).
>
> But when trying to call this function from python, I keep getting the 
> following error:
>
>  >>> a = int(0)
>  >>> print test("foo", a)
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> Boost.Python.ArgumentError: Python argument types in
>      pyubss.test(str, int)
> did not match C++ signature:
>      test(char*, int*)
>
> So how do I specify that p is an out parameter? How do I have to call the 
> function in Python? Is it possible?

Decide what interface you'd like to see in Python; that's your first
step.

  http://article.gmane.org/gmane.comp.python.c++/964

might give you an idea.

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



From ult at mundane.org  Mon Jun 27 18:05:12 2005
From: ult at mundane.org (Ult Mundane)
Date: Mon, 27 Jun 2005 12:05:12 -0400
Subject: [C++-sig] str operator
Message-ID: <42C023B8.3050805@mundane.org>

Hi there,

I'm having trouble getting the str operator to compile. Any help would be 
greatly appreciated! I'm building on linux with gcc.

Here's my example code:

--- foo.cpp --

#include <iostream>

#include <boost/python.hpp>

using namespace boost::python;
using namespace std;

class Foo
{
   public:
     int val;
};

ostream & operator<<(ostream & output, Foo const & f)
{
   return output << f.val;
};

BOOST_PYTHON_MODULE(foo)
{
   class_<Foo>("Foo", init<>())
       .def(str(self))
       ;
}

--- end foo.cpp ---

And here's my compile error:

g++ -fPIC -Iboopy/src/foo -Ilibs/boost-1.32.0/src/python/src 
-Ilibs/boost-1.32.0/include -Ilibs/python-2.2/include 
-Ilibs/python-2.2/include/linux-i686 -c -o linux-i686-boopy/boopy/src/foo/foo.os 
boopy/src/foo/foo.cpp
libs/boost-1.32.0/include/boost/python/def_visitor.hpp: In static member
    function `static void boost::python::def_visitor_access::visit(const V&,
    classT&) [with V = boost::python::def_visitor<boost::python::api::object>,
    classT = boost::python::class_<Foo, boost::python::detail::not_specified,
    boost::python::detail::not_specified,
    boost::python::detail::not_specified>]':
libs/boost-1.32.0/include/boost/python/def_visitor.hpp:67:   instantiated from 
`void boost::python::def_visitor<DerivedVisitor>::visit(classT&) const [with 
classT = boost::python::class_<Foo, boost::python::detail::not_specified, 
boost::python::detail::not_specified, boost::python::detail::not_specified>, 
DerivedVisitor = boost::python::api::object]'
libs/boost-1.32.0/include/boost/python/class.hpp:225:   instantiated from 
`boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, 
X3>::def(const boost::python::def_visitor<Derived>&) [with Derived = 
boost::python::api::object, W = Foo, X1 = boost::python::detail::not_specified, 
X2 = boost::python::detail::not_specified, X3 = 
boost::python::detail::not_specified]'
boopy/src/foo/foo.cpp:22:   instantiated from here
libs/boost-1.32.0/include/boost/python/def_visitor.hpp:31: no matching function
    for call to `boost::python::api::object::visit(boost::python::class_<Foo,
    boost::python::detail::not_specified, boost::python::detail::not_specified,
    boost::python::detail::not_specified>&) const'




From petrucio at hoplon.com  Mon Jun 27 18:54:00 2005
From: petrucio at hoplon.com (Petrucio)
Date: Mon, 27 Jun 2005 13:54:00 -0300
Subject: [C++-sig] Wrapping classical C API for python access
In-Reply-To: <uy88v3jzd.fsf@boost-consulting.com>
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
Message-ID: <6.0.2.0.1.20050627134823.01b2c850@mail.hoplon.com>

 From my experience on trying to export a similar API, SWIG has been a more
feasible solution to do this job.

It has pre made typemaps that help you do just that:
http://www.swig.org/Doc1.3/Arguments.html

At 12:19 27/6/2005, you wrote:
>Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:
>
> > I'm currently in the process of evaluating how feasible it would be to use
> > boost.python to expose a classical C API to python.
> >
> > By classical C API I mean that most arguments are passed around as 
> pointers
> > (both in and out), and nearly every function has an int return value for
> > the error code.
> >
> > How do I deal with functions using pointers as out parameters? Given, for
> > example, the function "int test(char const *s, int *p)" where p is an out
> > parameter, I can easily wrap it with BP using test("foo", foo).
> >
> > But when trying to call this function from python, I keep getting the
> > following error:
> >
> >  >>> a = int(0)
> >  >>> print test("foo", a)
> > Traceback (most recent call last):
> >    File "<stdin>", line 1, in ?
> > Boost.Python.ArgumentError: Python argument types in
> >      pyubss.test(str, int)
> > did not match C++ signature:
> >      test(char*, int*)
> >
> > So how do I specify that p is an out parameter? How do I have to call the
> > function in Python? Is it possible?
>
>Decide what interface you'd like to see in Python; that's your first
>step.
>
>   http://article.gmane.org/gmane.comp.python.c++/964
>
>might give you an idea.
>
>--
>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 mrovner at propel.com  Mon Jun 27 21:52:25 2005
From: mrovner at propel.com (Mike Rovner)
Date: Mon, 27 Jun 2005 12:52:25 -0700
Subject: [C++-sig] Wrapping classical C API for python access
In-Reply-To: <6.0.2.0.1.20050627134823.01b2c850@mail.hoplon.com>
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
	<6.0.2.0.1.20050627134823.01b2c850@mail.hoplon.com>
Message-ID: <d9pldd$a56$1@sea.gmane.org>

I'd consider pyrex.

Petrucio wrote:
>  From my experience on trying to export a similar API, SWIG has been a more
> feasible solution to do this job.
> 
> It has pre made typemaps that help you do just that:
> http://www.swig.org/Doc1.3/Arguments.html
> 
> At 12:19 27/6/2005, you wrote:
> 
>>Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:
>>
>>
>>>I'm currently in the process of evaluating how feasible it would be to use
>>>boost.python to expose a classical C API to python.
>>>
>>>By classical C API I mean that most arguments are passed around as 
>>
>>pointers
>>
>>>(both in and out), and nearly every function has an int return value for
>>>the error code.
>>>
>>>How do I deal with functions using pointers as out parameters? Given, for
>>>example, the function "int test(char const *s, int *p)" where p is an out
>>>parameter, I can easily wrap it with BP using test("foo", foo).
>>>
>>>But when trying to call this function from python, I keep getting the
>>>following error:
>>>
>>> >>> a = int(0)
>>> >>> print test("foo", a)
>>>Traceback (most recent call last):
>>>   File "<stdin>", line 1, in ?
>>>Boost.Python.ArgumentError: Python argument types in
>>>     pyubss.test(str, int)
>>>did not match C++ signature:
>>>     test(char*, int*)
>>>
>>>So how do I specify that p is an out parameter? How do I have to call the
>>>function in Python? Is it possible?
>>
>>Decide what interface you'd like to see in Python; that's your first
>>step.
>>
>>  http://article.gmane.org/gmane.comp.python.c++/964
>>
>>might give you an idea.
>>
>>--
>>Dave Abrahams
>>Boost Consulting
>>www.boost-consulting.com
>>
>>_______________________________________________
>>C++-sig mailing list
>>C++-sig at python.org
>>http://mail.python.org/mailman/listinfo/c++-si
> 
> g



From dave at boost-consulting.com  Mon Jun 27 22:07:08 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 27 Jun 2005 16:07:08 -0400
Subject: [C++-sig] str operator
References: <42C023B8.3050805@mundane.org>
Message-ID: <uslz3zhqr.fsf@boost-consulting.com>

Ult Mundane <ult at mundane.org> writes:

> Hi there,
>
> I'm having trouble getting the str operator to compile. Any help would be 
> greatly appreciated! I'm building on linux with gcc.

Which version?

Try replacing uses of "str" with "self_ns::str."  It's possible your
GCC is having trouble with argument-dependent lookup.

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



From markus.schoepflin at comsoft.de  Tue Jun 28 09:57:26 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 28 Jun 2005 09:57:26 +0200
Subject: [C++-sig] Wrapping classical C API for python access
In-Reply-To: <uy88v3jzd.fsf@boost-consulting.com>
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
Message-ID: <d9qvfq$c3r$1@sea.gmane.org>

David Abrahams wrote:

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

>>I'm currently in the process of evaluating how feasible it would be to use 
>>boost.python to expose a classical C API to python.
>>

> Decide what interface you'd like to see in Python; that's your first
> step.
> 
>   http://article.gmane.org/gmane.comp.python.c++/964
> 
> might give you an idea.

I did some reading and I think the typemap facility offered by SWIG would 
be just what I need. (Thanks for the pointer, Petrucio)

In short words, it allows me to convert "void foo(int a, int *b)" into a 
python function foo(int a) returning int b.

Is there some built-in support in BP for this? If not, how would I go about 
doing this? Do I have to write a wrapper function for each C function? And 
lastly, would "int bar(int a, int *b)" be convertible to "(ret, b) = bar(1)"?

TIA, Markus



From markus.schoepflin at comsoft.de  Tue Jun 28 10:00:52 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 28 Jun 2005 10:00:52 +0200
Subject: [C++-sig] Wrapping classical C API for python access
In-Reply-To: <6.0.2.0.1.20050627134823.01b2c850@mail.hoplon.com>
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
	<6.0.2.0.1.20050627134823.01b2c850@mail.hoplon.com>
Message-ID: <d9qvm8$d2c$1@sea.gmane.org>

Petrucio wrote:

>  From my experience on trying to export a similar API, SWIG has been a more
> feasible solution to do this job.
> 
> It has pre made typemaps that help you do just that:
> http://www.swig.org/Doc1.3/Arguments.html

Thanks for the pointer. This looks very promising and probably will be the 
way to go when BP doesn't work out.

Markus



From dave at boost-consulting.com  Tue Jun 28 13:19:30 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Jun 2005 07:19:30 -0400
Subject: [C++-sig] Wrapping classical C API for python access
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
	<d9qvfq$c3r$1@sea.gmane.org>
Message-ID: <uoe9qu3st.fsf@boost-consulting.com>

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

> David Abrahams wrote:
>
>> Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:
>
>>>I'm currently in the process of evaluating how feasible it would be to use 
>>>boost.python to expose a classical C API to python.
>>>
>
>> Decide what interface you'd like to see in Python; that's your first
>> step.
>> 
>>   http://article.gmane.org/gmane.comp.python.c++/964
>> 
>> might give you an idea.
>
> I did some reading and I think the typemap facility offered by SWIG would 
> be just what I need. (Thanks for the pointer, Petrucio)
>
> In short words, it allows me to convert "void foo(int a, int *b)" into a 
> python function foo(int a) returning int b.
>
> Is there some built-in support in BP for this? 

Nope.

> If not, how would I go about doing this? Do I have to write a
> wrapper function for each C function?

If you have a particular signature over and over again, you can do it
with a template:

  template <void (&f)(int, int*)>
  int thin_wrapper(int x)
  {
     int result;
     f(x,&result);
     return result;
  }

Then you can wrap

  thin_wrapper<foo>

> And lastly, would "int bar(int a, int *b)" be convertible to "(ret,
> b) = bar(1)"?
>

Sorry, I don't understand.  A C++ type convertible to a Python
statement?

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



From markus.schoepflin at comsoft.de  Tue Jun 28 13:52:59 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 28 Jun 2005 13:52:59 +0200
Subject: [C++-sig] Wrapping classical C API for python access
In-Reply-To: <uoe9qu3st.fsf@boost-consulting.com>
References: <d9p24n$d7u$1@sea.gmane.org>
	<uy88v3jzd.fsf@boost-consulting.com><d9qvfq$c3r$1@sea.gmane.org>
	<uoe9qu3st.fsf@boost-consulting.com>
Message-ID: <42C13A1B.1080100@comsoft.de>

David Abrahams wrote:

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

> If you have a particular signature over and over again, you can do it
> with a template:
> 
>   template <void (&f)(int, int*)>
>   int thin_wrapper(int x)
>   {
>      int result;
>      f(x,&result);
>      return result;
>   }
> 
> Then you can wrap
> 
>   thin_wrapper<foo>

I see. Thanks for getting me started.

>>And lastly, would "int bar(int a, int *b)" be convertible to "(ret,
>>b) = bar(1)"?

> Sorry, I don't understand.  A C++ type convertible to a Python
> statement?

Errm, no. What I meant is that the C++ function "int bar(int a, int *b)" 
where the return value of bar and the output parameter b could be turned 
into a tuple on the Python side, which would make the function callable 
like "(ret, b) = bar(1)".

But as I'll have to write wrappers anyway, I'll have to do the conversion 
manually I think. Is there by any chance some built-in support for using 
boost.tuple together with boost.python, which would me enable to just write

boost::tuple<int, int> bar_wrapper(int a)
{
   int b;
   int ret = bar(a, &b);
   return boost::make_tuple(ret, b);
}

and later on

def("bar", bar_wrapper);

Thanks for your help, Dave!

Markus


From ericjardim at gmail.com  Tue Jun 28 15:53:59 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Tue, 28 Jun 2005 10:53:59 -0300
Subject: [C++-sig] str operator
In-Reply-To: <42C023B8.3050805@mundane.org>
References: <42C023B8.3050805@mundane.org>
Message-ID: <432ec6c505062806535151142c@mail.gmail.com>

On 6/27/05, Ult Mundane <ult at mundane.org> wrote:
> 
> .def(str(self))
> 

Sorry to ask but, what do you mean by defining "str(self)"?

The code does not work here, but worked with the namespace "self_ns::". 

The compiler is:
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-34)

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050628/4aae009c/attachment.htm>

From dave at boost-consulting.com  Tue Jun 28 16:20:12 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Jun 2005 10:20:12 -0400
Subject: [C++-sig] Wrapping classical C API for python access
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
	<d9qvfq$c3r$1@sea.gmane.org> <uoe9qu3st.fsf@boost-consulting.com>
	<42C13A1B.1080100@comsoft.de>
Message-ID: <uhdfir2ar.fsf@boost-consulting.com>

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

> David Abrahams wrote:
>
>> Markus Sch?pflin <markus.schoepflin at comsoft.de> writes:
>
>> If you have a particular signature over and over again, you can do it
>> with a template:
>> 
>>   template <void (&f)(int, int*)>
>>   int thin_wrapper(int x)
>>   {
>>      int result;
>>      f(x,&result);
>>      return result;
>>   }
>> 
>> Then you can wrap
>> 
>>   thin_wrapper<foo>
>
> I see. Thanks for getting me started.
>
>>>And lastly, would "int bar(int a, int *b)" be convertible to "(ret,
>>>b) = bar(1)"?
>
>> Sorry, I don't understand.  A C++ type convertible to a Python
>> statement?
>
> Errm, no. What I meant is that the C++ function "int bar(int a, int *b)" 
> where the return value of bar and the output parameter b could be turned 
> into a tuple on the Python side, which would make the function callable 
> like "(ret, b) = bar(1)".

Sorry, I understand the concept, but not the question.  "I meant that
the C++ function ..., which would make the function callable..." just
doesn't parse.

> But as I'll have to write wrappers anyway, I'll have to do the conversion 
> manually I think. Is there by any chance some built-in support for using 
> boost.tuple together with boost.python, which would me enable to just write
>
> boost::tuple<int, int> bar_wrapper(int a)
> {
>    int b;
>    int ret = bar(a, &b);
>    return boost::make_tuple(ret, b);
> }

Why not just use boost::python::tuple?

template <int(&f)(int a, int*b)>
boost::python::tuple thin1(int x)
{
    int z;
    int r = f(x,&z);
    return make_tuple(r,z);
};

> and later on
>
> def("bar", bar_wrapper);

  def("bar", thin1<bar>)

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



From markus.schoepflin at comsoft.de  Tue Jun 28 16:39:37 2005
From: markus.schoepflin at comsoft.de (=?ISO-8859-1?Q?Markus_Sch=F6pflin?=)
Date: Tue, 28 Jun 2005 16:39:37 +0200
Subject: [C++-sig] Wrapping classical C API for python access
In-Reply-To: <uhdfir2ar.fsf@boost-consulting.com>
References: <d9p24n$d7u$1@sea.gmane.org>
	<uy88v3jzd.fsf@boost-consulting.com>	<d9qvfq$c3r$1@sea.gmane.org>
	<uoe9qu3st.fsf@boost-consulting.com>	<42C13A1B.1080100@comsoft.de>
	<uhdfir2ar.fsf@boost-consulting.com>
Message-ID: <d9rn1q$m5u$1@sea.gmane.org>

David Abrahams wrote:

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

>>Errm, no. What I meant is that the C++ function "int bar(int a, int *b)" 
>>where the return value of bar and the output parameter b could be turned 
>>into a tuple on the Python side, which would make the function callable 
>>like "(ret, b) = bar(1)".

> Sorry, I understand the concept, but not the question.  "I meant that
> the C++ function ..., which would make the function callable..." just
> doesn't parse.

Sigh, sometimes I wish I was a native speaker. :-( But you already have 
answered my question, even if you don't know it. :-)


>>boost::tuple<int, int> bar_wrapper(int a)
>>{
>>   int b;
>>   int ret = bar(a, &b);
>>   return boost::make_tuple(ret, b);
>>}

> Why not just use boost::python::tuple?
> 
> template <int(&f)(int a, int*b)>
> boost::python::tuple thin1(int x)
> {
>     int z;
>     int r = f(x,&z);
>     return make_tuple(r,z);
> };

Ummm, no real excuse for this one. Because I didn't know it and I'm just 
getting to know my way around boost.python is probably the best answer I 
can give.

But is there a special reason for boost.python to have it's own version of 
tuple? Because it's too complicated to make boost.tuple play nice with 
boost.python? Or are those two tuple implementations totally unrelated?

Markus



From dave at boost-consulting.com  Tue Jun 28 17:04:56 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 28 Jun 2005 11:04:56 -0400
Subject: [C++-sig] Wrapping classical C API for python access
References: <d9p24n$d7u$1@sea.gmane.org> <uy88v3jzd.fsf@boost-consulting.com>
	<d9qvfq$c3r$1@sea.gmane.org> <uoe9qu3st.fsf@boost-consulting.com>
	<42C13A1B.1080100@comsoft.de> <uhdfir2ar.fsf@boost-consulting.com>
	<d9rn1q$m5u$1@sea.gmane.org>
Message-ID: <u7jger087.fsf@boost-consulting.com>

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

>
> But is there a special reason for boost.python to have it's own version of 
> tuple? 

Yes, the same reason it has list and str: they are wrappers for the
correspondingly named built-in Python types.

> Because it's too complicated to make boost.tuple play nice with 
> boost.python? Or are those two tuple implementations totally unrelated?

Yep, unrelated.

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



From ntuck at ssoc-inc.com  Wed Jun 29 01:08:10 2005
From: ntuck at ssoc-inc.com (Nathan Tuck)
Date: Tue, 28 Jun 2005 17:08:10 -0600
Subject: [C++-sig] basic embedded boost.python build question
Message-ID: <1120000090.5131.442.camel@linux.site>

I have a somewhat basic build question for embedded python, but I have
not been able to google the answer.

First of all, I am using Linux.

I want to build an application with an embedded (dynamically linked)
python interpreter and a module of statically linked (into the
application executable) boost.python routines.  I would prefer not to
compile separate .so's for the modules or include my own custom version
of the interpreter.

Is it possible to make this work?  The best solution I have come up with
so far has three pieces: 1) an executable 2) the boost module .so and 3)
another .so implementing the functions that are called both by the boost
module and the executable.  Surely there is a way I can get this down to
one file (just the executable) which dynamically links to the main
python libs?

Thanks,

Nathan




From simon at arrowtheory.com  Wed Jun 29 10:46:06 2005
From: simon at arrowtheory.com (Simon Burton)
Date: Wed, 29 Jun 2005 09:46:06 +0100
Subject: [C++-sig] str operator
In-Reply-To: <42C023B8.3050805@mundane.org>
References: <42C023B8.3050805@mundane.org>
Message-ID: <20050629094606.29ce85dd.simon@arrowtheory.com>

On Mon, 27 Jun 2005 12:05:12 -0400
Ult Mundane <ult at mundane.org> wrote:

> 
> Hi there,
> 
> I'm having trouble getting the str operator to compile. Any help would be 
> greatly appreciated! I'm building on linux with gcc.

I had similar problems with str too:
http://mail.python.org/pipermail/c++-sig/2005-February/thread.html#8584

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 


From dirgesh.patel at hp.com  Thu Jun 30 01:24:38 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Wed, 29 Jun 2005 16:24:38 -0700
Subject: [C++-sig] Linking files in JAMFILE with boost
Message-ID: <d9va5r$eel$1@sea.gmane.org>

I am using BOOST in Linux with C++ and have sucessfully created my .cpp
file.

but now i want to take that cpp file and link it with a ".la" file that has
been created
from other sources. is there a way in the JamFile i can tell the "bjam"
compiler to
LINK the .cpp file with the .la file when done.

please advice

thanks much







From dirgesh.patel at hp.com  Thu Jun 30 01:17:37 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Wed, 29 Jun 2005 16:17:37 -0700
Subject: [C++-sig] Linking to ".la" file in Linux with JAMFILE
Message-ID: <d9v9om$dki$1@sea.gmane.org>

I am using BOOST in Linux with C++ and have sucessfully created my .cpp
file.

but now i want to take that cpp file and link it with a ".la" file that has
been created
from other sources. is there a way in the JamFile i can tell the "bjam"
compiler to
LINK the .cpp file with the .la file when done.

please advice

thanks much





From dave at boost-consulting.com  Thu Jun 30 14:01:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 30 Jun 2005 08:01:45 -0400
Subject: [C++-sig] basic embedded boost.python build question
References: <1120000090.5131.442.camel@linux.site>
Message-ID: <ull4skq8m.fsf@boost-consulting.com>

Nathan Tuck <ntuck at ssoc-inc.com> writes:

> I have a somewhat basic build question for embedded python, but I have
> not been able to google the answer.
>
> First of all, I am using Linux.
>
> I want to build an application with an embedded (dynamically linked)
> python interpreter and a module of statically linked (into the
> application executable) boost.python routines.  I would prefer not to
> compile separate .so's for the modules or include my own custom version
> of the interpreter.
>
> Is it possible to make this work?  The best solution I have come up with
> so far has three pieces: 1) an executable 2) the boost module .so 

I assume you mean the Boost.Python shared library here.

> and 3)
> another .so implementing the functions that are called both by the boost
> module and the executable.  Surely there is a way I can get this down to
> one file (just the executable) which dynamically links to the main
> python libs?

There's a Boost.Python static library that you can use instead of the
Boost.Python shared library.  The "functions that are called both by
the boost module and the executable" can just be linked statically
into your application.  In fact, the "embedding" target in
libs/python/test/Jamfile shows how to build exactly that
configuration.

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



From dave at boost-consulting.com  Thu Jun 30 14:03:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 30 Jun 2005 08:03:57 -0400
Subject: [C++-sig] Linking files in JAMFILE with boost
References: <d9va5r$eel$1@sea.gmane.org>
Message-ID: <ufyv0kq4y.fsf@boost-consulting.com>

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

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

What is a .la file?  I'd know the answer if you asked about a file
with extension .a, .o, or .so, but I've never heard of a .la file.

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



From jorgensen at getcollc.com  Thu Jun 30 14:33:08 2005
From: jorgensen at getcollc.com (Jens B. Jorgensen)
Date: Thu, 30 Jun 2005 07:33:08 -0500
Subject: [C++-sig] Linking files in JAMFILE with boost
Message-ID: <DB19BFB5D30D1E41A719B7709E4D90EE370B86@MAILSERV1.getco.com>

An .la file is a meta-file produced by libtool. It contains information
about the real library and meta-information detailing the specifics of
linking to it.  

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Thursday, June 30, 2005 7:04 AM
To: c++-sig at python.org
Subject: Re: [C++-sig] Linking files in JAMFILE with boost

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

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

What is a .la file?  I'd know the answer if you asked about a file with
extension .a, .o, or .so, but I've never heard of a .la file.

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

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


From dave at boost-consulting.com  Thu Jun 30 15:46:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 30 Jun 2005 09:46:45 -0400
Subject: [C++-sig] Linking files in JAMFILE with boost
References: <DB19BFB5D30D1E41A719B7709E4D90EE370B86@MAILSERV1.getco.com>
Message-ID: <uk6kchs8q.fsf@boost-consulting.com>

"Jens B. Jorgensen" <jorgensen at getcollc.com> writes:

> An .la file is a meta-file produced by libtool. It contains information
> about the real library and meta-information detailing the specifics of
> linking to it.  

And what would you do from the command-line in order to link to an .la
file "manually?"

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



From jorgensen at getcollc.com  Thu Jun 30 15:55:00 2005
From: jorgensen at getcollc.com (Jens B. Jorgensen)
Date: Thu, 30 Jun 2005 08:55:00 -0500
Subject: [C++-sig] Linking files in JAMFILE with boost
Message-ID: <DB19BFB5D30D1E41A719B7709E4D90EE370B88@MAILSERV1.getco.com>

The canonical method for this is to invoke 'libtool'. You can check out
an example here:

http://www.gnu.org/software/libtool/manual.html#Linking-executables

I'm by no means any kind of expert or even really a novice with libtool.
I've mucked about in open source projects that were set up to build with
it and that's about it.  

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Thursday, June 30, 2005 8:47 AM
To: c++-sig at python.org
Subject: Re: [C++-sig] Linking files in JAMFILE with boost

"Jens B. Jorgensen" <jorgensen at getcollc.com> writes:

> An .la file is a meta-file produced by libtool. It contains 
> information about the real library and meta-information detailing the 
> specifics of linking to it.

And what would you do from the command-line in order to link to an .la
file "manually?"

--
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 dirgesh.patel at hp.com  Thu Jun 30 16:27:46 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Thu, 30 Jun 2005 07:27:46 -0700
Subject: [C++-sig] linking with a ".a" file with boost.python
Message-ID: <da0v31$ceo$1@sea.gmane.org>

i also have a choice of linking with a ".a" file or a ".so" file...how can i
link with those kinds of file in my Jamfile?

please advice





From dirgesh.patel at hp.com  Thu Jun 30 16:42:19 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Thu, 30 Jun 2005 07:42:19 -0700
Subject: [C++-sig] using libtool with boost.python
Message-ID: <da0vua$fbn$1@sea.gmane.org>

if i want to use libtool to compile and link all of my files in the JAMFILE
with boost.python...how can i do so, here is what my Jamfile looks like
currently.

extension MaskUtil
:  # sources
   MaskUtil.cpp

  # requirements and dependencies for Boost.Python extensions
  <template>@boost/libs/python/build/extension
  ;

# Declare a test for the extension module
boost-python-runtest test2
    : # extension modules to use
    <pyd>MaskUtil ;





From foo.Clark at gmail.com  Thu Jun 30 17:05:41 2005
From: foo.Clark at gmail.com (Clark)
Date: Thu, 30 Jun 2005 23:05:41 +0800
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <uwtpvgroy.fsf@boost-consulting.com>
References: <20050514013221.29299.qmail@web31501.mail.mud.yahoo.com>
	<20050516014714.GA28985@dell.cad>
	<uwtpvgroy.fsf@boost-consulting.com>
Message-ID: <20050630150541.GA12758@BigDell>

It takes much time of me to solve this problem.

The answer is: 
A class member named "this" is added to every python class wrapped by
SWIG. The "this" is a "PySwigObject", which has a member points to 
the C++ 'this' pointer. For example
A C++ class exposed by SWIG:
    class Foo
    {  
    public:
        virtual void foo()
        {
            printf("Foo bar!\n");
        }
    } 
A C++ function exposed by Boost.Python:
    void bar(PyObject *obj)
    { 
        PySwigObject *psObj = (PySwigObject *)obj;
        Foo *f = psObj->ptr;
        f->foo();
    } 
A Python script:
    >>>a = Foo()
    >>>bar(a.this)
    Foo bar!
    >>>

Here is another simple but complete example to illustrate the approach.

There are four files: foo.h, foo.cpp, foo.i, bar.cpp.
foo.h      is a C++ header file that declares a C++ class Foo, 
           which has a method "foo()".
foo.cpp    is a C++ source file that defines the method "Foo::foo()" 
foo.i      is a SWIG interface definition file that exposes 
           C++ class "Foo" to Python.
bar.cpp    is a C++ source file that makes use of Boost.Python 
           to expose a function "foobar".
foobar.py  is python script which will output "Foo bar!"

After building two python extension modules foo and bar 
by SWIG and Boost.Python, respectively, running the script foobar.py 
will give the output "Foo bar!"

================== foo.h ================
class Foo 
{
public:
   virtual void foo() const;
};
-----------------------------------------

================ foo.cpp ================
#include "foo.h"
#include <stdio.h>

void Foo::foo() const
{
    printf("Foo bar!\n");
}
-----------------------------------------

================= foo.i =================
%module foo 
%{
#include "foo.h"
%}

class Foo 
{
public:
    void foo() const;
};
-----------------------------------------

================ bar.cpp ================
#include <boost/python.hpp>    
using namespace boost::python; 
#include "foo.h"

typedef struct {
    PyObject_HEAD
    void *ptr;
    const char *desc;
} PySwigObject;

void foobar(object obj)       
{
    // convert obj to Foo *
    Foo *f = (Foo *)(((PySwigObject *)obj.ptr())->ptr);
    f->foo();
}

BOOST_PYTHON_MODULE(bar)     
{
    def("foobar", &foobar);      
}
-----------------------------------------

=============== foobar.py ===============
import foo, bar
a = foo.Foo()
bar.foobar(a.this)
-----------------------------------------




On Thu, May 19, 2005 at 11:29:17AM -0400, David Abrahams wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.python.c++ as well.
> 
> Clark <foo.Clark at gmail.com> writes:
> 
> > We know that cross-module type info share is easy with latest Swig or
> > Boost.Python.
> > But how to make it possible to do with Swig and Boost.Python together?
> >
> > For example, we have two c++ extension A and B, which are exposed
> > with Swig and Boost.Python, respectively. They are as follows:
> >
> > ==============Module A wrapped with Swig ===============
> >    class Base
> > {
> > public:
> >         Base();
> >             ...
> > };
> > --------------------------------------------------------
> >
> > ========== Module B wrapped with Boost.Python ==========
> > void foo(Base *);
> >
> > class Derive: public Base
> > {
> >         ...
> > };
> > --------------------------------------------------------
> >
> > I wish to use module A and B in Python like this:
> >
> > ============= Module A and B used in Python ============
> >>>>import A
> >>>>import B
> >>>>obj = A.Base()
> >>>>B.foo(obj)
> >>>>obj = B.Derive()
> >>>>B.foo(obj)
> > --------------------------------------------------------
> >
> > Could anybody give me a solution or some hints? I've working for
> > this for long.
> 
> Well, you can use the raw converter stuff, which is documented in
> http://www.boost.org/libs/python/doc/v2/reference.html#type_conversion.
> You might also see the test code that exercises these facilities in
> libs/python/test/m1.cpp, libs/python/test/m2.cpp, and
> libs/python/test/newtest.py.  
> 
> If SWIG is generating a Python extension type object BaseType, and an
> extension instance type BaseObject corresponding to Base, you could
> use lvalue_from_pytype, something like:
> 
>   lvalue_from_pytype<extract_member<
>         BaseObject, Base, &BaseObject::value>,&BaseType>();
> 
> Otherwise, you'll have to touch some ugly, undocumented details of
> Boost.Python.  Let me know if you need that, and I'll try to help.
> 
> HTH,
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com


From sram at qualcomm.com  Thu Jun 30 22:04:19 2005
From: sram at qualcomm.com (Siddharth Ram)
Date: Thu, 30 Jun 2005 13:04:19 -0700
Subject: [C++-sig] help with boost error
Message-ID: <42C45043.6010509@qualcomm.com>

I get the following error(s) when building  ACE header files (public 
domain software)

Here's the error: I am trying to understand the reason for the static 
assertion failure. removing either/boost of the class_ from the input 
file still results in the error. If I remove both class_ the error goes away

/usr/include/boost/python/with_custodian_and_ward.hpp: In static member 
function `static PyObject* 
boost::python::with_custodian_and_ward_postcall<custodian, ward, 
BasePolicy_>::postcall(const ArgumentPackage&, PyObject*) [with 
ArgumentPackage = PyObject*, unsigned int custodian = 0u, unsigned int 
ward = 1u, BasePolicy_ = boost::python::default_call_policies]':
/usr/include/boost/python/detail/caller.hpp:201:   instantiated from 
`PyObject* boost::python::detail::caller_arity<2u>::impl<F, Policies, 
Sig>::operator()(PyObject*, PyObject*) [with F = 
ACE_Data_Block*(<unnamed>::ACE_Data_Block_Wrapper::*)(long unsigned int) 
const, Policies = boost::python::return_internal_reference<1u, 
boost::python::default_call_policies>, Sig = 
boost::mpl::vector3<ACE_Data_Block*, <unnamed>::ACE_Data_Block_Wrapper&, 
long unsigned int>]'
/usr/include/boost/python/object/py_function.hpp:38:   instantiated from 
`PyObject* 
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, 
PyObject*) [with Caller = boost::python::detail
::caller<ACE_Data_Block*(<unnamed>::ACE_Data_Block_Wrapper::*)(long 
unsigned int) const, boost::python::return_internal_reference<1u, 
boost::python::default_call_policies>, 
boost::mpl::vector3<ACE_Data_Block*, <unnamed>::ACE_Data_Block_Wrapper&, 
long unsigned int> >]'
test/protocol/ranc/RLP/python/boost/ace.cpp:103:   instantiated from here
/usr/include/boost/python/with_custodian_and_ward.hpp:87: warning: 
comparison of unsigned expression < 0 is always false
/usr/include/boost/python/object/make_instance.hpp: In static member 
function `static PyObject* boost::python::objects::make_instance_impl<T, 
Holder, Derived>::execute(Arg&) [with Arg = char*, T = char, Holder = 
boost::python::objects::pointer_holder<char*, char>, Derived = 
boost::python::objects::make_ptr_instance<char, 
boost::python::objects::pointer_holder<char*, char> >]':
/usr/include/boost/python/to_python_indirect.hpp:96:   instantiated from 
`static PyObject* 
boost::python::detail::make_reference_holder::execute(T*) [with T = char]'
/usr/include/boost/python/to_python_indirect.hpp:60:   instantiated from 
`PyObject* boost::python::to_python_indirect<T, 
MakeHolder>::execute(const U&, mpl_::false_) const [with U = char, T = 
char*, MakeHolder = boost::python::detail::make_reference_holder]'
/usr/include/boost/python/to_python_indirect.hpp:48:   instantiated from 
`PyObject* boost::python::to_python_indirect<T, MakeHolder>::execute(U*, 
mpl_::true_) const [with U = char, T = char*, MakeHolder = 
boost::python::detail::make_reference_holder]'
/usr/include/boost/python/to_python_indirect.hpp:37:   instantiated from 
`PyObject* boost::python::to_python_indirect<T, 
MakeHolder>::operator()(const U&) const [with U = char*, T = char*, 
MakeHolder = boost::python::detail::make_reference_holder]'
/usr/include/boost/python/detail/invoke.hpp:88:   instantiated from 
`PyObject* 
boost::python::detail::invoke(boost::python::detail::invoke_tag_< 
false,  true>, const RC&, F&, TC&) [with RC = 
boost::python::to_python_indirect<char*, 
boost::python::detail::make_reference_holder>, F = 
char*(ACE_Data_Block::*)() const, TC = 
boost::python::arg_from_python<ACE_Data_Block&>]'
/usr/include/boost/python/detail/caller.hpp:199:   instantiated from 
`PyObject* boost::python::detail::caller_arity<1u>::impl<F, Policies, 
Sig>::operator()(PyObject*, PyObject*) [with F = 
char*(ACE_Data_Block::*)() const, Policies = 
boost::python::return_internal_reference<1u, 
boost::python::default_call_policies>, Sig = boost::mpl::vector2<char*, 
ACE_Data_Block&>]'
/usr/include/boost/python/object/py_function.hpp:38:   instantiated from 
`PyObject* 
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, 
PyObject*) [with Caller = 
boost::python::detail::caller<char*(ACE_Data_Block::*)() const, 
boost::python::return_internal_reference<1u, 
boost::python::default_call_policies>, boost::mpl::vector2<char*, 
ACE_Data_Block&> >]'
test/protocol/ranc/RLP/python/boost/ace.cpp:103:   instantiated from here
/usr/include/boost/python/object/make_instance.hpp:24: error: incomplete 
type `boost::STATIC_ASSERTION_FAILURE< false>' used in nested name specifier
/usr/include/boost/python/object/make_instance.hpp:24: error: size of 
array has non-integral type `<type error>'

The input file is attached. thanks for your help


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ace.cpp
Type: text/x-c++src
Size: 18735 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050630/9a64f9f2/attachment.cpp>

From rwgk at yahoo.com  Thu Jun 30 23:17:02 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 30 Jun 2005 14:17:02 -0700 (PDT)
Subject: [C++-sig] In a C++ extension,
	how to use a C++ class exported in another extension
In-Reply-To: <20050630150541.GA12758@BigDell>
Message-ID: <20050630211702.2749.qmail@web31505.mail.mud.yahoo.com>

Thanks for posting this. It is very interesting!

David, how difficult would it be to provide something like

  boost::python::arg_from_swig_object<Foo>();

so that we could wrap functions taking SWIG-wrapped arguments directly?
I guess there is no easy way to construct SWIG-wrapped return values without a
lot of support from SWIG, but automatically extracting the pointer to turn it
into a T*, T&, const T*, const T& argument seems like something that may not be
too hard... true?

Looking some more, isn't this almost it?

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

But we want to do it without having the equivalent of noddy_NoddyType, just
knowing that ((PySwigObject*)obj.ptr())->ptr gives us the T*.

Cheers,
        Ralf

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

> It takes much time of me to solve this problem.
> 
> The answer is: 
> A class member named "this" is added to every python class wrapped by
> SWIG. The "this" is a "PySwigObject", which has a member points to 
> the C++ 'this' pointer.


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail