pygccxml-development

Re: [pygccxml-development] Problems with long filename

[Birgir S. <Bir...@ro...>]

Hei, I cannot get any of those to work, as it seems to me
that they are based on the fact that I have declared the
classes.

I added this
holder =3D mb.class_( 'std::vector < std::string >')
holder.rename( 'StringVector' )

and got this error

pygccxml.declarations.matcher.declaration_not_found_t: Unable to find=
 declaration.  matcher: [(decl type=3D=3Dclass_t) and (name=3D=
=3Dstd::vector < std::string >)

In my case it is the return type (stl container) that
is beeing auto converted to a class_ by Py++

Is there any other way?

Birgir


-----Original Message-----
From: Roman Yakovenko [mailto:rom...@gm...]
Sent: Fri 3/9/2007 10:20 AM
To: Birgir Sigurjonsson
Cc: pyg...@li...
Subject: Re: [pygccxml-development] Problems with long filename
=0D
On 3/9/07, Birgir Sigurjonsson <Bir...@ro...> wrote:
> Hei , I am using Py++ to expose the following.
>
>  class AbstractLoader : private boost::noncopyable {
>  public:
>
>    AbstractLoader();
>    virtual ~AbstractLoader();
>
>    std::vector < std::string > extensions() const;
>
>  private:
>    virtual std::vector < std::string > extensions_impl() const =3D 0;
>  };
>
>  I want to use the module_builder_t.split_module
>  but I am getting the following error message.
>
>  IOError: [Errno 36] File name too long:=
 u'splitted/vector_less_std_scope_basic_string_less_char_comma__std_scope_c=
har_traits_less_char_grate__comma__std_scope_allocator_less_char_grate___gr=
ate__comma_std_scope_allocator_less_std_scope_basic_string_less_char_comma_=
_std_scope_char_traits_less_char_grate__comma__std_scope_allocator_less_cha=
r_grate___grate___grate___grate_.pypp.hpp'
>
>  How can I tell Py++ not to autogenerate so long names?

Take a look on this "how to":
http://language-binding.net/pyplusplus/documentation/how_to.html#py-generat=
ed-file-name-is-too-long
After it you I think you would like to read this:
http://language-binding.net/pyplusplus/documentation/hints.html

Does it help?

--=0D
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/





DISCLAIMER:
This message contains information that may be privileged or confidential=
 and is the property of the Roxar Group. It is intended only for the person=
 to whom it is addressed. If you are not the intended recipient, you are=
 not authorised to read, print, retain, copy, disseminate, distribute, or=
 use this message or any part thereof. If you receive this message in=
 error, please notify the sender immediately and delete all copies of this=
 message.=0D

Re: [pygccxml-development] Problems with long filename

[Roman Y. <rom...@gm...>]

On 3/9/07, Birgir Sigurjonsson <Bir...@ro...> wrote:
> Hei , I am using Py++ to expose the following.
>
>  class AbstractLoader : private boost::noncopyable {
>  public:
>
>    AbstractLoader();
>    virtual ~AbstractLoader();
>
>    std::vector < std::string > extensions() const;
>
>  private:
>    virtual std::vector < std::string > extensions_impl() const = 0;
>  };
>
>  I want to use the module_builder_t.split_module
>  but I am getting the following error message.
>
>  IOError: [Errno 36] File name too long: u'splitted/vector_less_std_scope_basic_string_less_char_comma__std_scope_char_traits_less_char_grate__comma__std_scope_allocator_less_char_grate___grate__comma_std_scope_allocator_less_std_scope_basic_string_less_char_comma__std_scope_char_traits_less_char_grate__comma__std_scope_allocator_less_char_grate___grate___grate___grate_.pypp.hpp'
>
>  How can I tell Py++ not to autogenerate so long names?

Take a look on this "how to":
http://language-binding.net/pyplusplus/documentation/how_to.html#py-generated-file-name-is-too-long
After it you I think you would like to read this:
http://language-binding.net/pyplusplus/documentation/hints.html

Does it help?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Problems with long filename

[Birgir S. <Bir...@ro...>]

Hei , I am using Py++ to expose the following.

class AbstractLoader : private boost::noncopyable {
public:
 =0D
  AbstractLoader();
  virtual ~AbstractLoader();

  std::vector < std::string > extensions() const;
 =0D
private:
  virtual std::vector < std::string > extensions_impl() const =3D 0;
};

I want to use the module_builder_t.split_module
but I am getting the following error message.

IOError: [Errno 36] File name too long:=
 u'splitted/vector_less_std_scope_basic_string_less_char_comma__std_scope_c=
har_traits_less_char_grate__comma__std_scope_allocator_less_char_grate___gr=
ate__comma_std_scope_allocator_less_std_scope_basic_string_less_char_comma_=
_std_scope_char_traits_less_char_grate__comma__std_scope_allocator_less_cha=
r_grate___grate___grate___grate_.pypp.hpp'

How can I tell Py++ not to autogenerate so long names?

Best regards,
Birgir Sigurjonsson.


DISCLAIMER:
This message contains information that may be privileged or confidential=
 and is the property of the Roxar Group. It is intended only for the person=
 to whom it is addressed. If you are not the intended recipient, you are=
 not authorised to read, print, retain, copy, disseminate, distribute, or=
 use this message or any part thereof. If you receive this message in=
 error, please notify the sender immediately and delete all copies of this=
 message.=0D

Re: [pygccxml-development] errors with global

[Roman Y. <rom...@gm...>]

On 3/5/07, Neal Becker <ndb...@gm...> wrote:
> This code has lots of problems:
>
> test.h:
> -----------------------------------
> #include <boost/shared_ptr.hpp>
>
> struct A {
>   virtual void doit () = 0;
> };
>
> struct B : public A {
>   virtual void doit ();
> };
>
>
> struct C {
>   C (boost::shared_ptr<A> _a) :
>     a (_a) {}
>
>   void doit() { a->doit(); }
>
>   boost::shared_ptr<A> a;
> };
>
> B the_b;
>
> INFO gccxml
> cmd: /usr/bin/gccxml  -I"/home/nbecker/tmp" -I"/home/nbecker/tmp"   "/home/nbecker/tmp/test.h" -fxml="/tmp/tmpoHXDYR.xml"
>
> WARNING: boost::shared_ptr<A> [class]
> > warning W1040: The declaration is unexposed, but there are other
> > declarations, which refer to it. This could cause "no to_python
> > converter found" run time error. Declarations:
> > C::C(boost::shared_ptr<A> _a) [constructor]  C::a [variable]
>
> INFO: file "test.cpp" - updated( 0.000000 seconds )
> g++ -o test.os -c -fPIC -I/usr/local/src/boost.hg -I/usr/include/python2.4
> test.cpp
> test.cpp: In function 'void init_module_test()':
> test.cpp:88: error: expected `)' before '.' token
> test.cpp:92: error: '_GLOBAL__I__home_nbecker_tmp_test' was not declared in
> this scope
> test.cpp:92: error: '::_GLOBAL__I__home_nbecker_tmp_test' has not been
> declared
> scons: *** [test.os] Error 1
>

fixed, thank you for reporting this.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] errors with global

[Neal B. <ndb...@gm...>]

This code has lots of problems:

test.h:
-----------------------------------
#include <boost/shared_ptr.hpp>

struct A {
  virtual void doit () = 0;
};

struct B : public A {
  virtual void doit ();
};


struct C {
  C (boost::shared_ptr<A> _a) :
    a (_a) {}

  void doit() { a->doit(); }

  boost::shared_ptr<A> a;
};

B the_b;

INFO gccxml 
cmd: /usr/bin/gccxml  -I"/home/nbecker/tmp" -I"/home/nbecker/tmp"   "/home/nbecker/tmp/test.h" -fxml="/tmp/tmpoHXDYR.xml"

WARNING: boost::shared_ptr<A> [class]
> warning W1040: The declaration is unexposed, but there are other
> declarations, which refer to it. This could cause "no to_python
> converter found" run time error. Declarations:
> C::C(boost::shared_ptr<A> _a) [constructor]  C::a [variable]

INFO: file "test.cpp" - updated( 0.000000 seconds )
g++ -o test.os -c -fPIC -I/usr/local/src/boost.hg -I/usr/include/python2.4 
test.cpp
test.cpp: In function 'void init_module_test()':
test.cpp:88: error: expected `)' before '.' token
test.cpp:92: error: '_GLOBAL__I__home_nbecker_tmp_test' was not declared in 
this scope
test.cpp:92: error: '::_GLOBAL__I__home_nbecker_tmp_test' has not been 
declared
scons: *** [test.os] Error 1

Re: [pygccxml-development] boost python indexing suite (Was: Parameter passing, ownership semantics)

[Roman Y. <rom...@gm...>]

On 2/26/07, Gustavo Carneiro <gjc...@gm...> wrote:
>   The attached patch fixes the boost python indexing suite compilation error on 64-bit systems and Python 2.5.
>
>   In a related subject, what do you see as a future for this indexing suite?  Will it make it into upstream soon?  The way things stand right now it is very difficult to deploy software based on the latest Py++ mainly because of the boost indexing suite, which is very difficult to compile.  I sincerely hope this gets resolved soon.  Either boost incorporates these changes, or a separate library is created; as it is right now is way too hard for the average person trying to compile the average program.

Thank you for the patch. I will commit the change this evening.

Basically I am waiting for boost 1.34 to go out. After this I will try
to convince David Abrahams, the author of Boost.Python, to add new
indexing suite to on-going version.

In any case I am going to create stand-alone distribution of:
gccxml, pygccxml, boost.python ( with only needed parts of the boost )
and Py++.

I am aware of madness, the people have to come through, before they
start to enjoy.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] boost python indexing suite (Was: Parameter passing, ownership semantics)

[Gustavo C. <gjc...@gm...>]

On 2/22/07, Gustavo Carneiro <gjc...@gm...> wrote:
>
> On 2/22/07, Roman Yakovenko <rom...@gm...> wrote:
>
> Also I added new functionality, which allows you to implement the patch:
> > http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?view=markup
> >
> > http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?view=markup
> >
> >
> > I attached the generated code.
>
>
>   Unfortunately I can't test it on my work PC (amd64 ubuntu) because it is
> LP64 and the "indexing" boost extensions provided in Py++ do not compile
> here.   I attach the log.
>

  The attached patch fixes the boost python indexing suite compilation error
on 64-bit systems and Python 2.5.

  In a related subject, what do you see as a future for this indexing
suite?  Will it make it into upstream soon?  The way things stand right now
it is very difficult to deploy software based on the latest Py++ mainly
because of the boost indexing suite, which is very difficult to compile.  I
sincerely hope this gets resolved soon.  Either boost incorporates these
changes, or a separate library is created; as it is right now is way too
hard for the average person trying to compile the average program.

  Regard,

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] default arguments bug?

[Roman Y. <rom...@gm...>]

On 2/25/07, Tony Kirke <tk...@gm...> wrote:
> A slight modification of the 1st example on:
> http://www.language-binding.net/pyplusplus/documentation/functions/default_args.html
> doesn't seem to work.
> Copying the class header file (non.h - attached) and placing it one
> directory up generates an empty module definition.  Run mygen.py and
> look at 2 generated files.
> Is this intended?

Please read "Caveats" paragraph in next document:
http://www.language-binding.net/pyplusplus/documentation/best_practices.html

It seems that you have exactly same issue. Does it help?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] default arguments bug?

[Tony K. <tk...@gm...>]

A slight modification of the 1st example on:
http://www.language-binding.net/pyplusplus/documentation/functions/default_args.html
doesn't seem to work.
Copying the class header file (non.h - attached) and placing it one
directory up generates an empty module definition.  Run mygen.py and
look at 2 generated files.
Is this intended?

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/24/07, Roman Yakovenko <rom...@gm...> wrote:
>
> On 2/24/07, Gustavo Carneiro <gjc...@gm...> wrote:
> > On 2/24/07, Gustavo Carneiro <gjc...@gm...> wrote:
> > >
> > > On 2/22/07, Roman Yakovenko < rom...@gm...> wrote:
> > >
> > >
> > >
> > > > Also I added new functionality, which allows you to implement the
> patch:
> > > >
> >
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?view=markup
> > > >
> >
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?view=markup
> > >
> > >
> > >   Thanks, it works perfectly! :-)
> >
> >   Bah, I spoke a little too soon :P
> >
> >   It seems that  when  the virtual method is protected, as shown in the
> > patch below, the " method.add_override_precall_code()" part
> > stops having any effect on the generated virtual method code, and so the
> > INCREF is not inserted, making the memory problem come back.  And it so
> > happens that the code I am trying to wrap hits precisely this bug...
> what a
> > bad luck :(
> >
> >
> > --- simulator.hpp       2007-02-19 12:55:53.000000000 +0000
> >  +++ simulator-new.hpp   2007-02-24 18:29:12.000000000 +0000
> > @@ -7,6 +7,10 @@ namespace ns3 {
> >   class EventImpl
> >  {
> >   public:
> > +    void Invoke(void) {
> >  +        Notify();
> > +    }
> >  +protected:
> >      virtual void Notify() = 0;
> >   };
> >
> >  @@ -18,7 +22,7 @@ public:
> >      };
> >
> >      static void Run() {
> >  -        Simulator::event->Notify();
> > +        Simulator::event->Invoke();
> >           delete Simulator::event;
> >          Simulator::event = 0;
> >      };
>
> My fault and it is fixed now in SVN.


  It _really_ works now, thanks! :-)

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Parameter passing, ownership semantics

[Roman Y. <rom...@gm...>]

On 2/24/07, Gustavo Carneiro <gjc...@gm...> wrote:
> On 2/24/07, Gustavo Carneiro <gjc...@gm...> wrote:
> >
> > On 2/22/07, Roman Yakovenko < rom...@gm...> wrote:
> >
> >
> >
> > > Also I added new functionality, which allows you to implement the patch:
> > >
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?view=markup
> > >
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?view=markup
> >
> >
> >   Thanks, it works perfectly! :-)
>
>   Bah, I spoke a little too soon :P
>
>   It seems that  when  the virtual method is protected, as shown in the
> patch below, the " method.add_override_precall_code()" part
> stops having any effect on the generated virtual method code, and so the
> INCREF is not inserted, making the memory problem come back.  And it so
> happens that the code I am trying to wrap hits precisely this bug... what a
> bad luck :(
>
>
> --- simulator.hpp       2007-02-19 12:55:53.000000000 +0000
>  +++ simulator-new.hpp   2007-02-24 18:29:12.000000000 +0000
> @@ -7,6 +7,10 @@ namespace ns3 {
>   class EventImpl
>  {
>   public:
> +    void Invoke(void) {
>  +        Notify();
> +    }
>  +protected:
>      virtual void Notify() = 0;
>   };
>
>  @@ -18,7 +22,7 @@ public:
>      };
>
>      static void Run() {
>  -        Simulator::event->Notify();
> +        Simulator::event->Invoke();
>           delete Simulator::event;
>          Simulator::event = 0;
>      };

My fault and it is fixed now in SVN.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/24/07, Gustavo Carneiro <gjc...@gm...> wrote:
>
> On 2/22/07, Roman Yakovenko <rom...@gm...> wrote:
>
> Also I added new functionality, which allows you to implement the patch:
> > http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?view=markup
> >
> > http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?view=markup
> >
>
>
>   Thanks, it works perfectly! :-)
>

  Bah, I spoke a little too soon :P

  It seems that  when  the virtual method is protected, as shown in the
patch below, the "method.add_override_precall_code()" part stops having any
effect on the generated virtual method code, and so the INCREF is not
inserted, making the memory problem come back.  And it so happens that the
code I am trying to wrap hits precisely this bug... what a bad luck :(


--- simulator.hpp       2007-02-19 12:55:53.000000000 +0000
+++ simulator-new.hpp   2007-02-24 18:29:12.000000000 +0000
@@ -7,6 +7,10 @@ namespace ns3 {
 class EventImpl
 {
 public:
+    void Invoke(void) {
+        Notify();
+    }
+protected:
     virtual void Notify() = 0;
 };

@@ -18,7 +22,7 @@ public:
     };

     static void Run() {
-        Simulator::event->Notify();
+        Simulator::event->Invoke();
         delete Simulator::event;
         Simulator::event = 0;
     };

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/22/07, Roman Yakovenko <rom...@gm...> wrote:
>
> On 2/22/07, Gustavo Carneiro <gjc...@gm...> wrote:
> >   That wiki entry didn't apply anymore probably due to changing
> > boost::python interfaces, but it provided very useful clues.  I managed
> to
> > get it working 100% correctly using another hack.  Here's the diff of
> the
> > manual changes I made to the wrapper:
> >
> > --- ns3.cpp     2007-02-21 23:46:44.000000000 +0000
> > +++ ns3-working.cpp      2007-02-21 23:44:34.000000000 +0000
> > @@ -9,19 +9,32 @@
> >   namespace bp = boost::python;
> >
> >   struct EventImpl_wrapper : ns3::EventImpl, bp::wrapper< ns3::EventImpl
> > {
> > +    ~EventImpl_wrapper() {
> >  +        if (this->pyobj) {
> > +            Py_DECREF(this->pyobj);
> > +            this->pyobj = 0;
> >  +        }
> > +
> >  +    }
> >
> >      EventImpl_wrapper()
> >      : ns3::EventImpl()
> >  -      , bp::wrapper< ns3::EventImpl >(){
> > -        // null constructor
> >  +      , bp::wrapper< ns3::EventImpl > (), pyobj(0) {
> >
> >      }
> >
> >      virtual void Notify(  ){
> >  +        if (!this->pyobj) {
> > +            this->pyobj =
> > bp::detail::wrapper_base_::get_owner(*this);
> >  +            Py_INCREF(this->pyobj);
> > +        }
> >           bp::override func_Notify = this->get_override( "Notify" );
> >           func_Notify(  );
> >      }
> >
> > +protected:
> >  +    PyObject *pyobj;
> > +
> >   };
> >
> >  static void Schedule_b8544467c482930a621aca2e7ac87dca(
> > std::auto_ptr< ::ns3::EventImpl > event ){
> >
>
> Hi Gustavo. I tested the code you post and it doesn't work for me :-(.
> I also doesn't understand how it works for you. You should increment
> reference
> on the object before you pass it "Schedule" member function, otherwise
> you get same "Segmentation fault". Am I missing something?
> I can avoid it by commenting the destructor code.


  You are right.  In my case it worked due to a bug in my code.  I forgot to
make ~EventImpl() virtual, and so ~EventImpl_wrapper() was never called! :P

  I hate C++ :(

Also I added new functionality, which allows you to implement the patch:
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?view=markup
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?view=markup


  Thanks, it works perfectly! :-)

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Parameter passing, ownership semantics

[Roman Y. <rom...@gm...>]

On 2/22/07, Gustavo Carneiro <gjc...@gm...> wrote:
>   That wiki entry didn't apply anymore probably due to changing
> boost::python interfaces, but it provided very useful clues.  I managed to
> get it working 100% correctly using another hack.  Here's the diff of the
> manual changes I made to the wrapper:
>
> --- ns3.cpp     2007-02-21 23:46:44.000000000 +0000
> +++ ns3-working.cpp      2007-02-21 23:44:34.000000000 +0000
> @@ -9,19 +9,32 @@
>   namespace bp = boost::python;
>
>   struct EventImpl_wrapper : ns3::EventImpl, bp::wrapper< ns3::EventImpl > {
> +    ~EventImpl_wrapper() {
>  +        if (this->pyobj) {
> +            Py_DECREF(this->pyobj);
> +            this->pyobj = 0;
>  +        }
> +
>  +    }
>
>      EventImpl_wrapper()
>      : ns3::EventImpl()
>  -      , bp::wrapper< ns3::EventImpl >(){
> -        // null constructor
>  +      , bp::wrapper< ns3::EventImpl > (), pyobj(0) {
>
>      }
>
>      virtual void Notify(  ){
>  +        if (!this->pyobj) {
> +            this->pyobj =
> bp::detail::wrapper_base_::get_owner(*this);
>  +            Py_INCREF(this->pyobj);
> +        }
>           bp::override func_Notify = this->get_override( "Notify" );
>           func_Notify(  );
>      }
>
> +protected:
>  +    PyObject *pyobj;
> +
>   };
>
>  static void Schedule_b8544467c482930a621aca2e7ac87dca(
> std::auto_ptr< ::ns3::EventImpl > event ){
>

Hi Gustavo. I tested the code you post and it doesn't work for me :-(.
I also doesn't understand how it works for you. You should increment reference
on the object before you pass it "Schedule" member function, otherwise
you get same "Segmentation fault". Am I missing something?
I can avoid it by commenting the destructor code.

Also I added new functionality, which allows you to implement the patch:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?view=markup
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?view=markup

I attached the generated code.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/20/07, Gustavo Carneiro <gjc...@gm...> wrote:
>
> On 2/19/07, Roman Yakovenko <rom...@gm...> wrote:
> >
> > Hi. Unfortunately I reproduced the error and was not able to  fix it
> > :-(((((.
> > There is something I don't understand  and I think  this is
> > Boost.Python bug.
> >
> > I do made some progress.
> >
> > 1. When you derive Python class from a C++ one you have to define
> > __init__
> >     method, otherwise your code will not work:
> >
> > class MyEvent(EventImpl):
> >     def __init__( self ):
> >         EventImpl.__init__( self )
> >
> >     def Notify(self):
> >         print "Notify!"
> >
> > 2. I did small research for you. Read this post:
> >    http://aspn.activestate.com/ASPN/Mail/Message/cpp-sig/1331901
> >    and take a look on Boost.Python unit tests:
> >    http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.cpp?view=markup
> >
> >    http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.py?view=markup
> >
> >
> > What I found is:
> > The ownership is really transfered. You can check this using simple
> > technique:
> >         Add new function to EventImpl:
> >           virtual std::string class_name() const { return "EventImpl"; }
> >         Add free function:
> >            std::string get_class_name( const std::auto_ptr<EventImpl>& e
> > ){
> >                if( e.get() ){
> >                    return e->class_name();
> >                }
> >                else{
> >                   return "no object";
> >                }
> >            }
> >         You will get the answer "no object", after "Schedule" call.
> > So, may be you don't have to delete the Python object.
> >
> > I will submit the bug to the Boost.Python mailing list, hope somebody
> > will be able to help.
>
>
> I found this wiki with a possible solution for the problem:
>
> http://wiki.python.org/moin/boost.python/HowTo#head-927c9493ac51c81b3f2484e486d85567ff316c8a
>
>

  Good news.

  That wiki entry didn't apply anymore probably due to changing
boost::python interfaces, but it provided very useful clues.  I managed to
get it working 100% correctly using another hack.  Here's the diff of the
manual changes I made to the wrapper:

--- ns3.cpp     2007-02-21 23:46:44.000000000 +0000
+++ ns3-working.cpp     2007-02-21 23:44:34.000000000 +0000
@@ -9,19 +9,32 @@
 namespace bp = boost::python;

 struct EventImpl_wrapper : ns3::EventImpl, bp::wrapper< ns3::EventImpl > {
+    ~EventImpl_wrapper() {
+        if (this->pyobj) {
+            Py_DECREF(this->pyobj);
+            this->pyobj = 0;
+        }
+
+    }

     EventImpl_wrapper()
     : ns3::EventImpl()
-      , bp::wrapper< ns3::EventImpl >(){
-        // null constructor
+      , bp::wrapper< ns3::EventImpl > (), pyobj(0) {

     }

     virtual void Notify(  ){
+        if (!this->pyobj) {
+            this->pyobj = bp::detail::wrapper_base_::get_owner(*this);
+            Py_INCREF(this->pyobj);
+        }
         bp::override func_Notify = this->get_override( "Notify" );
         func_Notify(  );
     }

+protected:
+    PyObject *pyobj;
+
 };

 static void Schedule_b8544467c482930a621aca2e7ac87dca( std::auto_ptr<
::ns3::EventImpl > event ){

  Now my question, especially to any boost_python maintainers out there, can
you please do something about this?  I shouldn't have to make these kinds of
hacks to get it working; any chance this INCREF/DECREF of the PyObject can
make it upstream to the standard boost distribution?

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Warning output about members and member names

[Roman Y. <rom...@gm...>]

Hi Allen, I added additional information to the warnings.

Enjoy.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] return_range - new call policy

[Roman Y. <rom...@gm...>]

Hi all. I am not sure whether you see my post on Boost.Python mailing list, so
will repost it here.

I created new and cool call policy: return_range.

Class return_range is a model of CallPolicies, which can be used to
wrap C++ functions that return a pointer to some array. The new call
policy constructs object, which provides a regular Python sequence
interface.

For more information refer to documentation:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#return-range

Enjoy.
-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/19/07, Roman Yakovenko <rom...@gm...> wrote:
>
> Hi. Unfortunately I reproduced the error and was not able to  fix it
> :-(((((.
> There is something I don't understand  and I think  this is  Boost.Pythonbug.
>
> I do made some progress.
>
> 1. When you derive Python class from a C++ one you have to define __init__
>
>     method, otherwise your code will not work:
>
> class MyEvent(EventImpl):
>     def __init__( self ):
>         EventImpl.__init__( self )
>
>     def Notify(self):
>         print "Notify!"
>
> 2. I did small research for you. Read this post:
>    http://aspn.activestate.com/ASPN/Mail/Message/cpp-sig/1331901
>    and take a look on Boost.Python unit tests:
>
> http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.cpp?view=markup
>
> http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.py?view=markup
>
> What I found is:
> The ownership is really transfered. You can check this using simple
> technique:
>         Add new function to EventImpl:
>           virtual std::string class_name() const { return "EventImpl"; }
>         Add free function:
>            std::string get_class_name( const std::auto_ptr<EventImpl>& e
> ){
>                if( e.get() ){
>                    return e->class_name();
>                }
>                else{
>                   return "no object";
>                }
>            }
>         You will get the answer "no object", after "Schedule" call.
> So, may be you don't have to delete the Python object.
>
> I will submit the bug to the Boost.Python mailing list, hope somebody will
> be able to help.


I found this wiki with a possible solution for the problem:

http://wiki.python.org/moin/boost.python/HowTo#head-927c9493ac51c81b3f2484e486d85567ff316c8a

Unfortunately the provided code, after adaptions to my case, didn't even
compile :-(

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/20/07, Roman Yakovenko <rom...@gm...> wrote:
>
> On 2/20/07, Gustavo Carneiro <gjc...@gm...> wrote:
> >
> > On 2/19/07, Roman Yakovenko <rom...@gm... > wrote:
> > >
> > > Hi. Unfortunately I reproduced the error and was not able to  fix it
> > > :-(((((.
> >
> >
> >   Hey, thanks a lot anyway; it is now a problem in boost, but you solved
> > the Py++ part of the problem with commendable speed.
> >
> > There is something I don't understand  and I think  this is
> > > Boost.Python bug.
> > >
> > > I do made some progress.
> > >
> > > 1. When you derive Python class from a C++ one you have to define
> > > __init__
> > >     method, otherwise your code will not work:
> >
> >
> >   Since when does a subclass have to define __init__ in order to get the
> > parent class __init__ called?  What you say goes against all my python
> > knowledge...
> >
>
> During __init__ method of parent class reference to relevant Python object
> is
> saved and associated with the C++ class.
>

  But if I don't define __init__ in a subclass, the parent class __init__ is
automatically used instead, as demonstrated by this example:

class Foo(object):
    def __init__(self):
        print "Foo.__init__"

class Bar(Foo):
    pass

bar = Bar()

  I think the problem you want to express is when Bar defines __init__ but
doesn't chain to the parent class __init__.

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Parameter passing, ownership semantics

[Roman Y. <rom...@gm...>]

On 2/20/07, Gustavo Carneiro <gjc...@gm...> wrote:
>
> On 2/19/07, Roman Yakovenko <rom...@gm...> wrote:
> >
> > Hi. Unfortunately I reproduced the error and was not able to  fix it
> > :-(((((.
>
>
>   Hey, thanks a lot anyway; it is now a problem in boost, but you solved
> the Py++ part of the problem with commendable speed.
>
> There is something I don't understand  and I think  this is  Boost.Pythonbug.
> >
> > I do made some progress.
> >
> > 1. When you derive Python class from a C++ one you have to define
> > __init__
> >     method, otherwise your code will not work:
>
>
>   Since when does a subclass have to define __init__ in order to get the
> parent class __init__ called?  What you say goes against all my python
> knowledge...
>

During __init__ method of parent class reference to relevant Python object
is
saved and associated with the C++ class.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/19/07, Roman Yakovenko <rom...@gm...> wrote:
>
> Hi. Unfortunately I reproduced the error and was not able to  fix it
> :-(((((.


  Hey, thanks a lot anyway; it is now a problem in boost, but you solved the
Py++ part of the problem with commendable speed.

There is something I don't understand  and I think  this is  Boost.Pythonbug.
>
> I do made some progress.
>
> 1. When you derive Python class from a C++ one you have to define __init__
>
>     method, otherwise your code will not work:


  Since when does a subclass have to define __init__ in order to get the
parent class __init__ called?  What you say goes against all my python
knowledge...

class MyEvent(EventImpl):
>     def __init__( self ):
>         EventImpl.__init__( self )
>
>     def Notify(self):
>         print "Notify!"
>
> 2. I did small research for you. Read this post:
>    http://aspn.activestate.com/ASPN/Mail/Message/cpp-sig/1331901
>    and take a look on Boost.Python unit tests:
>
> http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.cpp?view=markup
>
> http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.py?view=markup
>
> What I found is:
> The ownership is really transfered. You can check this using simple
> technique:



        Add new function to EventImpl:
>           virtual std::string class_name() const { return "EventImpl"; }
>         Add free function:
>            std::string get_class_name( const std::auto_ptr<EventImpl>& e
> ){
>                if( e.get() ){
>                    return e->class_name();
>                }
>                else{
>                   return "no object";
>                }
>            }
>         You will get the answer "no object", after "Schedule" call.
> So, may be you don't have to delete the Python object.


  I can't help it;  I can't prevent the programmer  from deleting the object
prematurely; it's out of my control.

I will submit the bug to the Boost.Python mailing list, hope somebody will
> be able to help.


   Thanks, I will subscribe to that list too.

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."

Re: [pygccxml-development] Parameter passing, ownership semantics

[Roman Y. <rom...@gm...>]

Hi. Unfortunately I reproduced the error and was not able to  fix it
:-(((((.
There is something I don't understand  and I think  this is  Boost.Pythonbug.

I do made some progress.

1. When you derive Python class from a C++ one you have to define __init__
    method, otherwise your code will not work:

class MyEvent(EventImpl):
    def __init__( self ):
        EventImpl.__init__( self )

    def Notify(self):
        print "Notify!"

2. I did small research for you. Read this post:
   http://aspn.activestate.com/ASPN/Mail/Message/cpp-sig/1331901
   and take a look on Boost.Python unit tests:

http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.cpp?view=markup

http://boost.cvs.sourceforge.net/boost/boost/libs/python/test/auto_ptr.py?view=markup

What I found is:
The ownership is really transfered. You can check this using simple
technique:
        Add new function to EventImpl:
          virtual std::string class_name() const { return "EventImpl"; }
        Add free function:
           std::string get_class_name( const std::auto_ptr<EventImpl>& e ){
               if( e.get() ){
                   return e->class_name();
               }
               else{
                  return "no object";
               }
           }
        You will get the answer "no object", after "Schedule" call.
So, may be you don't have to delete the Python object.

I will submit the bug to the Boost.Python mailing list, hope somebody will
be able to help.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Any recent commits that may affect performance

[Roman Y. <rom...@gm...>]

On 2/19/07, Allen Bierbaum <al...@vr...> wrote:
>
> > I thought about it and I don't know. May be you are doing something
> wrong.
>
> That is always possible although nothing has really changed in the
> script in the time since it used to run fast.
>
> > Python-Ogre project is not a smallest one, but it takes only 5 minutes(
> without
> > cache and files ) to generate code. During code generation they also
> parse
> > Ogre source tree to extract documentation. Can you show your script?
>
> The generation script is here:
>
> https://realityforge.vrsource.org/trac/pyopensg/browser/trunk/src/gen_bindings.py
>
> I have added some additional timing analysis that shows the vast
> majority (>90%)of the time being spent in two places.
>
> 1) line 587, the call to the module builder initialization where all the
> code is parsed
> 2) line 1040, the call to build_code_creator where all the code creators
> are built up and everything is setup to run the code generation.
>
> Neither of these is a surprise since this is where py++ does all of it's
> work.
>
> I am still collecting more information that should be able to help track
> down why the full_name and get_name methods are being called so many
> millions of times.  (calling full_name 50 million times for a single run
> just seems excessive.)  I am using stack monitoring technique I used
> when I helped out with the performance last time.  I have added code to
> a local version of py++ that is not only counting the number of times
> full_name is called but also keeps a dictionary that contains a list of
> every call path (stack) into the code and how many times full_name has
> been called along each path.  This should be able to show us if there
> are some code paths that end up making the majority of the calls and
> could be optimized.
>
> Collecting this information can take a long time though.  I have already
> had the instrumented code running for about 20 hours and I expect it
> will run for another 24 hours before it is complete.  Once the run is
> done I will post the resulting information so everyone can take a look
> and present any ideas they have for helping out performance.
>
> -Allen
>
>
Grate. We make Py++ faster. Thank you for all your work.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Any recent commits that may affect performance

[Allen B. <al...@vr...>]

> I thought about it and I don't know. May be you are doing something wrong.

That is always possible although nothing has really changed in the 
script in the time since it used to run fast.

> Python-Ogre project is not a smallest one, but it takes only 5 minutes( without
> cache and files ) to generate code. During code generation they also parse
> Ogre source tree to extract documentation. Can you show your script?

The generation script is here: 
https://realityforge.vrsource.org/trac/pyopensg/browser/trunk/src/gen_bindings.py

I have added some additional timing analysis that shows the vast 
majority (>90%)of the time being spent in two places.

1) line 587, the call to the module builder initialization where all the 
code is parsed
2) line 1040, the call to build_code_creator where all the code creators 
are built up and everything is setup to run the code generation.

Neither of these is a surprise since this is where py++ does all of it's 
work.

I am still collecting more information that should be able to help track 
down why the full_name and get_name methods are being called so many 
millions of times.  (calling full_name 50 million times for a single run 
just seems excessive.)  I am using stack monitoring technique I used 
when I helped out with the performance last time.  I have added code to 
a local version of py++ that is not only counting the number of times 
full_name is called but also keeps a dictionary that contains a list of 
every call path (stack) into the code and how many times full_name has 
been called along each path.  This should be able to show us if there 
are some code paths that end up making the majority of the calls and 
could be optimized.

Collecting this information can take a long time though.  I have already 
had the instrumented code running for about 20 hours and I expect it 
will run for another 24 hours before it is complete.  Once the run is 
done I will post the resulting information so everyone can take a look 
and present any ideas they have for helping out performance.

-Allen

Re: [pygccxml-development] Parameter passing, ownership semantics

[Gustavo C. <gjc...@gm...>]

On 2/19/07, Roman Yakovenko <rom...@gm...> wrote:
>
> On 2/19/07, Gustavo Carneiro <gjc...@gm...> wrote:
> >   Even with the name mangling problem, something was not right:
> >
> > gjc@nazgul:python$  python test-schedule.py
> > Traceback (most recent call last):
> >   File "test-schedule.py ", line 11, in <module>
> >     Simulator.Schedule_fbf096d706be19b392c1e3fbcd3bf544(t1,
> > ev)
> > Boost.Python.ArgumentError: Python argument types in
> >
> > Simulator.Schedule_fbf096d706be19b392c1e3fbcd3bf544(Time,
> > MyEvent)
> > did not match C++ signature:
> >     Schedule_fbf096d706be19b392c1e3fbcd3bf544(ns3::Time
> > time, std::auto_ptr<ns3::EventImpl> event)
> >
> >   Then I saw something I missed in the unit test, and added this code:
> >
> >     EventImpl = mb.class_('EventImpl')
> >     EventImpl.held_type = 'std::auto_ptr< %s >' % EventImpl.decl_string
> >
> >   (EventImpl is the type of the argument that is subject to the
> ownership
> > transfer)
> >
> >   But with the above changes the code doesn't compile (errors
> below).  The
> > generated source contains:
> >
> >     bp::class_< EventImpl_wrapper, std::auto_ptr< ::ns3::EventImpl >,
> > boost::noncopyable >( "EventImpl" )
> >         .def( bp::init< >() )
> >
> >   The error comes from the ".def( bp::init< >() )" line.  Manually
> removing
> > the "std::auto_ptr< ::ns3::EventImpl >" part from the first line solves
> the
> > compilation error.
> >
> >    Any hints?
>
> Yes:
> 1. change "std::auto_ptr< ::ns3::EventImpl >" to
>     "std::auto_ptr< EventImpl_wrapper >" and add next line to your code:
>
> ei = mb.class _( 'EventImpl' )
> ei.add_registration_code(
>     "boost::python::implicitly_convertible< std::auto_ptr<
> EventImpl_wrapper >, std::auto_ptr< ::ns3::EventImpl > >();"
>    , False )
>
> This should help.


  Thanks, Roman!  I helped.


2. If not, please create small standalone test case, which reproduce the
> problem.
>     I will take a look on it.


  Unfortunately after all this effort I am still experiencing similar memory
errors as before.  I don't understand why because, as far as I can tell,
Py++ generated the boost code according to the boost FAQ advice.  In this
code, if I uncomment the 'del ev' line I get a memory error and segfault:

from ns3 import *

class MyEvent(EventImpl):

    def Notify(self):
        print "Notify!"

ev = MyEvent()
Simulator.Schedule(Seconds(1), ev) # takes ownership of ev
#del ev
Simulator.Run() # calls ev.Notify and then destroys it; memory error here


  Here's what valgrind reports:

==9790== Invalid read of size 4
==9790==    at 0x4B6E960: (within
/usr/lib/libboost_python-gcc-mt-1_33_1.so.1.33.1)
==9790==    by 0x8097F18: (within /usr/bin/python2.5)
==9790==    by 0x8062CED: (within /usr/bin/python2.5)
==9790==    by 0x4ABE032: boost::python::api::object_base::~object_base()
(object_core.hpp:436)
==9790==    by 0x4ABE080: boost::python::api::object::~object()
(object_core.hpp:294)
==9790==    by 0x4ABE176: boost::python::override::~override() (override.hpp
:88)
==9790==    by 0x4ADFC4F: EventImpl_wrapper::Notify() (ns3.cpp:32)
==9790==    by 0x4AF9CF5: ns3::EventImpl::Invoke() (event-impl.cc:39)
==9790==    by 0x4B005DE: ns3::SimulatorPrivate::ProcessOneEvent() (
simulator.cc:138)
==9790==    by 0x4B0061E: ns3::SimulatorPrivate::Run() (simulator.cc:168)
==9790==  Address 0x497D838 is 0 bytes inside a block of size 12 free'd
==9790==    at 0x4020F9A: free (vg_replace_malloc.c:233)
==9790==    by 0x4B6E766:
boost::python::instance_holder::deallocate(_object*, void*) (in
/usr/lib/libboost_python-gcc-mt-1_33_1.so.1.33.1)
==9790==    by 0x4B6E97F: (within
/usr/lib/libboost_python-gcc-mt-1_33_1.so.1.33.1)
==9790==    by 0x8097F18: (within /usr/bin/python2.5)
==9790==    by 0x8086418: PyDict_DelItem (in /usr/bin/python2.5)
==9790==    by 0x8061656: PyObject_DelItem (in /usr/bin/python2.5)
==9790==    by 0x80C27F9: PyEval_EvalFrameEx (in /usr/bin/python2.5)
==9790==    by 0x80C60F4: PyEval_EvalCodeEx (in /usr/bin/python2.5)
==9790==    by 0x80C6166: PyEval_EvalCode (in /usr/bin/python2.5)
==9790==    by 0x80E590B: PyRun_FileExFlags (in /usr/bin/python2.5)


  I think I'll try to make a small example to reproduce this...

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."