pygccxml-development Mailing List for C++ Python language bindings (Page 58)
Brought to you by:
mbaas,
roman_yakovenko
You can subscribe to this list here.
2006 |
Jan
|
Feb
(6) |
Mar
(160) |
Apr
(96) |
May
(152) |
Jun
(72) |
Jul
(99) |
Aug
(189) |
Sep
(161) |
Oct
(110) |
Nov
(9) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(13) |
Feb
(48) |
Mar
(35) |
Apr
(7) |
May
(37) |
Jun
(8) |
Jul
(15) |
Aug
(8) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(38) |
2008 |
Jan
(11) |
Feb
(29) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(64) |
Jul
(49) |
Aug
(51) |
Sep
(18) |
Oct
(22) |
Nov
(9) |
Dec
(9) |
2009 |
Jan
(28) |
Feb
(15) |
Mar
(2) |
Apr
(11) |
May
(6) |
Jun
(2) |
Jul
(3) |
Aug
(34) |
Sep
(5) |
Oct
(7) |
Nov
(13) |
Dec
(14) |
2010 |
Jan
(39) |
Feb
(3) |
Mar
(3) |
Apr
(14) |
May
(11) |
Jun
(8) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
From: Roman Y. <rom...@gm...> - 2006-05-29 18:13:18
|
On 5/29/06, Lakin Wecker <lak...@gm...> wrote: > Yeah, something like that will work, but it would be better if py++ > would export these variables automatically. Are you planning on > fixing this? (If so, then the rest of this letter is not necessary.) > > I looked at the code causing the problem, and it's all code similar to: > > class Foo{ > union { > struct { > float r,g,b,a; > }; > float val[4]; > }; > }; > > So (if my understanding is correct), the union is unnamed, but the > union's members can be access through Foo::r, Foo::g, Foo::b, Foo::a, > and Foo::val. > > It would be awesome if py++ exported these appropriately. I will add this feature, but not in a week or two. I could be wrong, but there are 4 or 5 places, where ogre uses such constructs. mb =3D module_builder_t(...) ogre =3D mb.namespace( 'ogre' ) print len( ogre.classes( '' ) ) / 2 for unnamed_cls in ogre.classes( '' ): named_parent =3D unnamed.parent if not named_parent.name: named_parent =3D named_parent.parent for mvar in named_paret.member_variables(): named_parent.add_code( 'add_property( "%(mvar)s", &Ogre::Vector3::%(mvar)s)" % dict( mvar=3Dmvar.name ) ) ) May be the previous code needs to be fixed, but I think you've got the idea= . I work on preparing source code to release. This means: source code is open for bug fixes + documentation. I have to do it, otherwise my project will never have documentation :-(. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Lakin W. <lak...@gm...> - 2006-05-29 17:35:10
|
Gah! I really need to remember to reply-all .... Sorry roman, and the list. Lakin ---------- Forwarded message ---------- From: Lakin Wecker <lak...@gm...> Date: May 29, 2006 11:34 AM Subject: Re: [pygccxml-development] More questions on the Ogre Binding To: Roman Yakovenko <rom...@gm...> On 5/28/06, Roman Yakovenko <rom...@gm...> wrote: > On 5/29/06, Lakin Wecker <lak...@gm...> wrote: > For the time being, those variables will not be exported to Python. Solut= ion: > > mb =3D module_builder_t(...) > Vector3 =3D mb.class_( "Vector3" ) > Vector3.add_code( 'add_property( "x", &Ogre::Vector3::x)' ) Yeah, something like that will work, but it would be better if py++ would export these variables automatically. Are you planning on fixing this? (If so, then the rest of this letter is not necessary.) I looked at the code causing the problem, and it's all code similar to: class Foo{ union { struct { float r,g,b,a; }; float val[4]; }; }; So (if my understanding is correct), the union is unnamed, but the union's members can be access through Foo::r, Foo::g, Foo::b, Foo::a, and Foo::val. It would be awesome if py++ exported these appropriately. Lakin |
From: Roman Y. <rom...@gm...> - 2006-05-29 05:49:41
|
On 5/29/06, Lakin Wecker <lak...@gm...> wrote: > In working some more on the bindings for Ogre, I tried to compile the > following class: > http://lakin.weckers.net/ogre/cpp/Frustum.pypp.cpp > > The Frustum class that Ogre defines has a member variable: > > VertexData mVertexData; > > But VertexData defines a protected Copy constructor. Now, Ogre > compiles and works fine, because the Frustum class itself doesn't > define a copy constructor, and no code uses the copy constructor, (So > it's not generated by the compiler, iirc). > > However, in the generated wrapper, the Copy Constructor is used, and > then g++ generates the appropriate error: > > g++ `pkg-config --cflags OGRE` -I/usr/include/python2.4 > -DBOOST_PYTHON_MAX_ARITY=3D16 -fPIC -Icpp -c -o cpp/Frustum.pypp.os > cpp/Frustum.pypp.cpp > /home/lakin/.local/include/OGRE/OgreFrustum.h: In copy constructor > 'Ogre::Frustum::Frustum(const Ogre::Frustum&)': > /home/lakin/.local/include/OGRE/OgreVertexIndexData.h:43: error: > 'Ogre::VertexData::VertexData(const Ogre::VertexData&)' is private > /home/lakin/.local/include/OGRE/OgreFrustum.h:62: error: within this cont= ext > cpp/Frustum.pypp.cpp: In constructor > 'Frustum_wrapper::Frustum_wrapper(const Ogre::Frustum&)': > cpp/Frustum.pypp.cpp:13: warning: synthesized method > 'Ogre::Frustum::Frustum(const Ogre::Frustum&)' first required here > scons: *** [cpp/Frustum.pypp.os] Error 1 > scons: building terminated because of errors. > > I'm going to file a bug with the Ogre guys, as I'm fairly certain that > they would want to define a copy constructor that works. :) I am almost sure, they will put it to be private, without any implementatio= n. > OGRE's api and general usage pattern will avoid copy constructors, using = and > passing around pointers. However, that leads to a question: Is this > also a bug in pyplusplus? Any time, the generated code could not be compiled it is a bug in py++ :-). Fixed, committed. The bug was in is_noncopyable function in type_traits.py module. I did not take into account member variables of the class. Now this function will return True is: one of the base classes is noncopyable contains const member variable to fundamental type, class or enum contains member variable of noncopyable class I understand, that this is not a complete list of all cases, I will add treatment to new use cases, when we will have them. Also, I updated unit test it is possible I missed some use case. Quick work around is mb =3D module_builder_t( ... ) Frustum =3D mb.class_( 'Frustum' ) Frustum.noncopyable =3D True But you still need the latest Subversion :-(. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-29 05:02:33
|
On 5/29/06, Lakin Wecker <lak...@gm...> wrote: > Hi list, > > This question is probably more for Roman, than the list directly, but > I'm sending it to the list for archival purposes. > > First off, I'm using revision 178. And I've uploaded the scripts > I'm using to: > http://lakin.weckers.net/ogre/ > > generate_code.py doesn't show any errors, but trying to compile the > resulting code results in an error of: > > for both Vector3.pypp.cpp, and Quaternion.pypp.cpp for the line which > looks similar to: > > .def_readonly( "", &Ogre::Vector3 ) Fixed, committed. The problem was unnamed member variable within Vector3 cl= ass. For the time being, those variables will not be exported to Python. Solutio= n: mb =3D module_builder_t(...) Vector3 =3D mb.class_( "Vector3" ) Vector3.add_code( 'add_property( "x", &Ogre::Vector3::x)' ) Or something like this. I did not test the code. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Lakin W. <lak...@gm...> - 2006-05-29 04:39:37
|
In working some more on the bindings for Ogre, I tried to compile the following class: http://lakin.weckers.net/ogre/cpp/Frustum.pypp.cpp The Frustum class that Ogre defines has a member variable: VertexData mVertexData; But VertexData defines a protected Copy constructor. Now, Ogre compiles and works fine, because the Frustum class itself doesn't define a copy constructor, and no code uses the copy constructor, (So it's not generated by the compiler, iirc). However, in the generated wrapper, the Copy Constructor is used, and then g++ generates the appropriate error: g++ `pkg-config --cflags OGRE` -I/usr/include/python2.4 -DBOOST_PYTHON_MAX_ARITY=16 -fPIC -Icpp -c -o cpp/Frustum.pypp.os cpp/Frustum.pypp.cpp /home/lakin/.local/include/OGRE/OgreFrustum.h: In copy constructor 'Ogre::Frustum::Frustum(const Ogre::Frustum&)': /home/lakin/.local/include/OGRE/OgreVertexIndexData.h:43: error: 'Ogre::VertexData::VertexData(const Ogre::VertexData&)' is private /home/lakin/.local/include/OGRE/OgreFrustum.h:62: error: within this context cpp/Frustum.pypp.cpp: In constructor 'Frustum_wrapper::Frustum_wrapper(const Ogre::Frustum&)': cpp/Frustum.pypp.cpp:13: warning: synthesized method 'Ogre::Frustum::Frustum(const Ogre::Frustum&)' first required here scons: *** [cpp/Frustum.pypp.os] Error 1 scons: building terminated because of errors. I'm going to file a bug with the Ogre guys, as I'm fairly certain that they would want to define a copy constructor that works. :) OGRE's api and general usage pattern will avoid copy constructors, using and passing around pointers. However, that leads to a question: Is this also a bug in pyplusplus? Lakin |
From: Lakin W. <lak...@gm...> - 2006-05-29 02:49:10
|
Hi list, This question is probably more for Roman, than the list directly, but I'm sending it to the list for archival purposes. First off, I'm using revision 178. And I've uploaded the scripts I'm using to: http://lakin.weckers.net/ogre/ generate_code.py doesn't show any errors, but trying to compile the resulting code results in an error of: for both Vector3.pypp.cpp, and Quaternion.pypp.cpp for the line which looks similar to: .def_readonly( "", &Ogre::Vector3 ) Commenting this out allows the build to continue, but Matrix4.pypp.cpp errors with: g++ `pkg-config --cflags OGRE` -I/usr/include/python2.4 -fPIC -Icpp -c -o cpp/Matrix4.pypp.os cpp/Matrix4.pypp.cpp cpp/Matrix4.pypp.cpp: In function 'void register_Matrix4_class()': cpp/Matrix4.pypp.cpp:12: error: wrong number of template arguments (16, should be 15) /usr/include/boost/python/init.hpp:58: error: provided for 'template<class T0, class T1, class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10, class T11, class T12, class T13, class T14> class boost::python::init' scons: *** [cpp/Matrix4.pypp.os] Error 1 Boost comes with a default limit of 15 for the arity of the init stuff, and this should be fixed by using a -DBOOST_PYTHON_MAX_ARITY=16 , but this results in the error given in : http://lakin.weckers.net/ogre/Scons.log Which, for the life of me, I can't solve. Lakin |
From: Lakin W. <lak...@gm...> - 2006-05-28 18:01:50
|
Right. I never realized that boost would return error messages in such a way, but it makes sense. I will work on this. Lakin On 5/28/06, Roman Yakovenko <rom...@gm...> wrote: > On 5/28/06, Lakin Wecker <lak...@gm...> wrote: > > I've tried using the boost date_time bindings as an example of how to > > build the library once the cpp files are generated. So I copied the > > sconscript and hacked it to compile the files. There are some things > > that need to be fixed in my script, such as the python path is > > hardcoded, and the cpp path is hardcoded, but I was just hoping to > > hack together something that works, and then clean it up > > > > The following links show you the sconscript I used, and the log is > > generated from running: > > scons -f sconscript >& Scons.log > > > > http://lakin.weckers.net/ogre/sconscript > > http://lakin.weckers.net/ogre/Scons.log > > > > any thoughts on where I can investigate this? > > Yes, you can read it :-). > > cpp/Overlay2DElementsIterator.pypp.cpp:26: instantiated from here > /usr/include/boost/python/detail/invoke.hpp:88: error: no match for > call to '(const > boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<Ogre::OverlayContainer*>) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (Ogre::OverlayContainer*)' > > You did not set call policies :-(. > > from pyplusplus import utils > > mb = module_builder_t( ... ) > > utils.missing_call_policies.print_ ( mb.code_creator ) > utils.missing_call_policies.exclude( mb.code_creator ) > > Basically next code will print all function, that are missing call policies > and then will remove them. May be it will work, may be not > ( hint pure virtual functions ). > > > Lakin > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > |
From: Roman Y. <rom...@gm...> - 2006-05-28 17:46:37
|
On 5/28/06, Lakin Wecker <lak...@gm...> wrote: > I've tried using the boost date_time bindings as an example of how to > build the library once the cpp files are generated. So I copied the > sconscript and hacked it to compile the files. There are some things > that need to be fixed in my script, such as the python path is > hardcoded, and the cpp path is hardcoded, but I was just hoping to > hack together something that works, and then clean it up > > The following links show you the sconscript I used, and the log is > generated from running: > scons -f sconscript >& Scons.log > > http://lakin.weckers.net/ogre/sconscript > http://lakin.weckers.net/ogre/Scons.log > > any thoughts on where I can investigate this? Yes, you can read it :-). cpp/Overlay2DElementsIterator.pypp.cpp:26: instantiated from here /usr/include/boost/python/detail/invoke.hpp:88: error: no match for call to '(const boost::python::detail::specify_a_return_value_policy_to_wrap_functions_retu= rning<Ogre::OverlayContainer*>) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (Ogre::OverlayContainer*)' You did not set call policies :-(. from pyplusplus import utils mb =3D module_builder_t( ... ) utils.missing_call_policies.print_ ( mb.code_creator ) utils.missing_call_policies.exclude( mb.code_creator ) Basically next code will print all function, that are missing call policies and then will remove them. May be it will work, may be not ( hint pure virtual functions ). > Lakin --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Lakin W. <lak...@gm...> - 2006-05-28 17:33:26
|
I've tried using the boost date_time bindings as an example of how to build the library once the cpp files are generated. So I copied the sconscript and hacked it to compile the files. There are some things that need to be fixed in my script, such as the python path is hardcoded, and the cpp path is hardcoded, but I was just hoping to hack together something that works, and then clean it up The following links show you the sconscript I used, and the log is generated from running: scons -f sconscript >& Scons.log http://lakin.weckers.net/ogre/sconscript http://lakin.weckers.net/ogre/Scons.log any thoughts on where I can investigate this? Lakin |
From: Roman Y. <rom...@gm...> - 2006-05-28 05:26:25
|
On 5/28/06, Lakin Wecker <lak...@gm...> wrote: > I updated to revision 168, and this time I actually installed it after > updating. :) :-) > Currently, I'm getting ready to really start working on the bindings. > I need to have a look at the Ogre classes and decide what needs to be > exported, and what doesn't. May I give you small advice? I saw on PyOgre page few examples, how to use PyOgre. Just peak up one of them( the smallest ) and make it work. If it works for you - fine, peak another example. If not :-( - you know where to find me. > > Thanks again for your help, and see you tomorrow. My pleasure. > Lakin > > http://lakin.weckers.net/ogre/OgrePython.py > http://lakin.weckers.net/ogre/pyplusplus.log.bz2 --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Lakin W. <lak...@gm...> - 2006-05-28 05:06:28
|
*Resending to the list* .. (sorry for all the direct mails, roman. It's late and I'm tired) I updated to revision 168, and this time I actually installed it after updating. :) I also added your tip for excluding the absolute paths. You were right, the files were not properly uploaded, although I am not sure what went wrong. This time I've uploaded them and checked that they worked. The links are at the bottom of the letter, but there are no problems, so I provide them only for a reference. Currently, I'm getting ready to really start working on the bindings. I need to have a look at the Ogre classes and decide what needs to be exported, and what doesn't. Additionally, I should look at the call policies as you have mentioned. Thanks again for your help, and see you tomorrow. Lakin http://lakin.weckers.net/ogre/OgrePython.py http://lakin.weckers.net/ogre/pyplusplus.log.bz2 On 5/27/06, Roman Yakovenko <rom...@gm...> wrote: > On 5/27/06, Lakin Wecker <lak...@gm...> wrote: > > I've update from svn, and done some of your optimizations that you > > mentioned, but I still get the error. > > > > I've reuploaded the log and the python file. > I could be wrong, but it seems to me, that you did not updated the file. > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications i= n > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmdlnk&kid=107521&bid$8729&dat=121642 > _______________________________________________ > pygccxml-development mailing list > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > |
From: Roman Y. <rom...@gm...> - 2006-05-27 20:29:52
|
On 5/27/06, Lakin Wecker <lak...@gm...> wrote: > I've update from svn, and done some of your optimizations that you > mentioned, but I still get the error. > > I've reuploaded the log and the python file. I could be wrong, but it seems to me, that you did not updated the file. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Lakin W. <lak...@gm...> - 2006-05-27 20:13:08
|
forwarding to the list as well. ---------- Forwarded message ---------- From: Lakin Wecker <lak...@gm...> Date: May 27, 2006 1:08 PM Subject: Re: My log To: Roman Yakovenko <rom...@gm...> I've update from svn, and done some of your optimizations that you mentioned, but I still get the error. I've reuploaded the log and the python file. Lakin On 5/27/06, Roman Yakovenko <rom...@gm...> wrote: > Okay. The error you reported has been fixed. pyplusplus did not take into > account that member variable can hold pointer to function. This has been fixed. > File that contains the fix is attached. Please put it into > pyplusplus/decl_wrappers > directory. ( It is also committed to repository ) > > Also I want to give you few tips: > > 1. Speed could be improved: > from pygccxml import parser > > ogre_header \ > = parser.create_cached_source_fc( r" path to/Ogre.h", "path > to/ogre.xml" ) ] > > mb = module_builder_t( [ogre_header], .... ) > > It will create xml file in location you specify and will reuse it > every time. Thus you > will save time by not invoking gccxml every time. > > IT IS UP TO YOU to remove the xml file if you change source files. You can > remove the XML file from ogre build scripts. > > You can read more about this function in pygccxml_dev/docs/design.rest file. > > 2. Cool feature: > > mb.calldefs( access_type_matcher_t( 'protected' ) ).exclude() > mb.calldefs( access_type_matcher_t( 'protected' ) ).exclude() > > is equal to: > > mb.calldefs( ~access_type_matcher_t( 'public' ) ).exclude() > > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > > > |
From: Roman Y. <rom...@gm...> - 2006-05-27 20:12:37
|
Another issue, that you will have is absolute paths in generated code. There are 2 ways to solve it: mb =3D module_builder_t( ... ) mb.build_code_creator( ... ) #This will replace all include headers, except boost.python related mb.code_creator.replace_included_headers( ['Ogre.h'] ) #Or another approach: mb.code_creator.user_defined_directories( 'my dir' ) In this case py++ will generate code and will calculate include headers relatively to 'my dir' directory --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-27 19:23:04
|
On 5/27/06, Lakin Wecker <lak...@gm...> wrote: > I've update from svn, and done some of your optimizations that you > mentioned, but I still get the error. The log file has been cut: tail pyplusplus.log Alias: address Ignore: True Signature: [u'::Ogre::EdgeListBuilder::Geometry *', [u'::Ogre::EdgeListBuilder::Geometry &']] Call policies: None Use keywords: True Use signature: True Use default arguments: True member_function_t: 'address' location: [/usr/include/c++/4.0.3/ext/new_allocator.h]:78 artificial: 'Fals~ What is the error you are talking about. It works fine on my computer. uname -a Linux umka 2.6.15-22-386 #1 PREEMPT Sun May 7 15:49:09 UTC 2006 i686 GNU/Li= nux And I am using Ogre 1.2 > I've reuploaded the log and the python file. > > Lakin --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-27 18:48:43
|
Okay. The error you reported has been fixed. pyplusplus did not take into account that member variable can hold pointer to function. This has been fi= xed. File that contains the fix is attached. Please put it into pyplusplus/decl_wrappers directory. ( It is also committed to repository ) Also I want to give you few tips: 1. Speed could be improved: from pygccxml import parser ogre_header \ =3D parser.create_cached_source_fc( r" path to/Ogre.h", "path to/ogre.xml" ) ] mb =3D module_builder_t( [ogre_header], .... ) It will create xml file in location you specify and will reuse it every time. Thus you will save time by not invoking gccxml every time. IT IS UP TO YOU to remove the xml file if you change source files. You c= an remove the XML file from ogre build scripts. You can read more about this function in pygccxml_dev/docs/design.rest f= ile. 2. Cool feature: mb.calldefs( access_type_matcher_t( 'protected' ) ).exclude() mb.calldefs( access_type_matcher_t( 'protected' ) ).exclude() is equal to: mb.calldefs( ~access_type_matcher_t( 'public' ) ).exclude() --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Lakin W. <lak...@gm...> - 2006-05-27 18:12:11
|
I don't mind switching to a public mailing list at all. It will be benificial to have all of this recorded somewhere. On 5/27/06, Roman Yakovenko <rom...@gm...> wrote: > On 5/27/06, Lakin Wecker <lak...@gm...> wrote: > > Here is the script that I'm currently using and the results: > > http://lakin.weckers.net/ogre/OgrePython.py > > http://lakin.weckers.net/ogre/pyplusplus.log > > > > Maybe this is one of the issues you were talking about. > > > > To start this project, these are the rules that I have come up with: > > 1) protected and private members aren't necessary. (I think this is a safe > > general rule to start out with, there may be some exceptions in the future, > > but none that I can think of currently). > > 2) Ogre will name methods starting with a '_' when they need them to be > > public (For internal use), but don't think that they should be part of the > > API. > > 3) There are a number of abstract base classes , Like GPUProgram, which are > > needed for the C++ api, but may not be necessary in the python API. (I'm > > not yet sure of this.) > > Excuse me, but I think I don't understand something. I talked about > next issues: > 1. Ogre SharedPtr class. We will have to create manual wrapper for this class. > I could be wrong, but it should be very similar to code from boost.python > library that works with boost.shared_ptr class > > 2. include bitset header - resolved > > 3. unnamed classes - this one I should solve this evening. > What are the issues you are talking about. Sorry. I was not clear. There is an exception raised (see the bottom of my log). Because I'm not yet familiar enough with py++, I thought that this exception might be caused by one of the issues that you had mentioned, (maybe #2?). And, because you were planning on fixing #2 tonight, I thought I would not waste my time trying to solve this problem until after it is fixed. > I took a look on your script. You are doing good. Your script is missing call > policies: > > http://boost.org/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies > > For example Ogre defines "clone" member function, that returns raw pointer to > new object. > > mb.member_functions( 'clone' ).call_policies \ > = module_builder.call_policies.return_value_policy( > module_builder.call_policies.manage_new_object ) You're right, this is something that needs to be taken care of, although, I had not yet realized it. I will work on this for my next version. > Another issue, I found in your script: you write all generated code into > single file. I am almost sure, that most of compilers will not handle this. > You can use another API provided by module_builder_t class: > > mb.split_module( directory name ) I knew this was an issue and was going to investigate it, but you've answered my question already. Thanks. > All generated code will be split to multiple files, using classic C++ strategy: > 1 class == source + header files. > > You may have some issues using this API - template instantiations. > In python "vector<int>" is illegal name, so py++ replace is with something > ugly: "vector_less_int_more" or something like this. The name could be too > long, so file system will not let py++ to create file with such name. > You should give > an alias to the class: > > mb.class_( 'vector<int>' ).alias = "VectorOfInt" Ok, I will check into this. Thanks for your help. > Any way I am online and ready for hard work :-). Ok, sounds good. Me too. Lakin > P.S. > If you don't mind, I would like to switch to public mailing list. I am > almost sure, that > the issues you have, other people will have too. I would like to share > my answer. > Here is a page where you can subscribe to py++ mailing list( low traffic): > > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > > Thanks. > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > |
From: Roman Y. <rom...@gm...> - 2006-05-27 18:00:21
|
On 5/27/06, Lakin Wecker <lak...@gm...> wrote: > Sorry. I was not clear. There is an exception raised (see the bottom > of my log). Because I'm not yet familiar enough with py++, I thought > that this exception might be caused by one of the issues that you had > mentioned, (maybe #2?). And, because you were planning on fixing #2 > tonight, I thought I would not waste my time trying to solve this > problem until after it is fixed. Good. I start to fix it, right after I answer this mail :-). In most cases, just report the bug, with the way to reproduce it. > I will work on this for my next version. This is okay. I will try to guide you. You can take a look on some "big" scripts: pyplusplus_dev/exampples/boost_dev/dev/, date_time and random are good. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-24 20:20:37
|
Hi Neal. I suppose you read my posts on boost.python mailing list. If not you suggest you to read them. Any way, I implemented the missing functionality. In your case struct A {}; struct B { A& a; }; py++ will create next code: #include "boost/python.hpp" #include "1.h" namespace bp =3D boost::python; struct B_wrapper : B, bp::wrapper< B > { static ::A & get_a( B& inst ) { return inst.a; } static void set_a( B& inst, ::A & new_value ){ inst.a =3D new_value; } }; BOOST_PYTHON_MODULE(pyplusplus){ if( true ){ typedef bp::class_< B_wrapper, boost::noncopyable > B_exposer_t; B_exposer_t B_exposer =3D B_exposer_t( "B", bp::no_init ); bp::scope B_scope( B_exposer ); B_exposer.def( "get_a" , (::A & (*)( ::B ))(&B_wrapper::get_a) , bp::return_value_policy< bp::copy_non_const_reference, bp::default_call_policies >() ); B_exposer.def( "set_a" , (void (*)( ::B,::A & ))(&B_wrapper::set_a) , bp::default_call_policies() ); } bp::class_< A >( "A" ); } You can change call policies for every function using getter_call_policies and setter_call_policies of variable_t class. It would be nice if you can try new functionality and report problems and/o= r suggestions. I did some testing, but not a full one. Thanks --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-23 20:34:01
|
On 5/23/06, Allen Bierbaum <al...@vr...> wrote: > > Sorry, looks like this was just an old cache file. :( > > I wish there was a way to automatically know that when the pyplusplus > code changes the old cache files need re-built. I discuss a little this subject with Matthias. I know how to solve this pro= blem. I wish, I have more time. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-23 20:04:11
|
On 5/23/06, Allen Bierbaum <al...@vr...> wrote: > Thanks for the quick turn around. :) My pleasure. > I can verify that this now works with my test case. I will try it later > today on the full library. Good luck > Roman: Is there any way you can add a test for this one to the test > suite to guard against any regressions in this behavior in the future? :-), What do you think I am doing right now? I work on adding unit test. More over, almost for every reported bug I create unit test. I am big fun of agile software development. > Thanks, > Allen --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Allen B. <al...@vr...> - 2006-05-23 19:58:12
|
Thanks for the quick turn around. :) I can verify that this now works with my test case. I will try it later today on the full library. Roman: Is there any way you can add a test for this one to the test suite to guard against any regressions in this behavior in the future? Thanks, Allen Roman Yakovenko wrote: > Allen, there is no work around for this bug, so I work on it right now. > I believe you will have an answer pretty soon. > > On 5/23/06, Allen Bierbaum <al...@vr...> wrote: > >> I should also have mentioned that as of yet I have not found a work >> around for this bug. >> >> I tried to work around it by "finalizing" the Son class, but I can't >> find a reliable way to finalize a class with pyplusplus. Until then I >> think I am at an impass. :( >> >> -Allen >> >> >> Allen Bierbaum wrote: >> >> > I think I have found a bug in the handling of virtual methods with >> > pyplusplus. >> > >> > I have attached a set of test classes and the generated bindings. >> > >> > The problem seems to be that when you have 3 classes derived from each >> > other as: >> > >> > class Grandpa >> > class Father : public Grandpa >> > class Son : public Father >> > >> > And Grandpa declares a pure virtual method that is defined in Father >> > but just used in Son, the wrapper for Son still thinks it is a pure >> > virtual and doesn't know to generate code with the default >> > implementation in Father. (See the attached code, it really makes >> > more sense with an example) >> > >> > -Allen >> > >> >------------------------------------------------------------------------ >> >> > >> >// This file has been generated by pyplusplus. >> > >> >#include "boost/python.hpp" >> > >> >#include "/home/allenb/temp/pypp_test/Classes.h" >> > >> >namespace bp = boost::python; >> > >> >struct Grandpa_wrapper : test_ns::Grandpa, bp::wrapper< >> test_ns::Grandpa > { >> > >> > Grandpa_wrapper() >> > : test_ns::Grandpa() >> > , bp::wrapper< test_ns::Grandpa >() >> > {} >> > >> > virtual int gp_pure( int i ){ >> > bp::override func_gp_pure = this->get_override( "gp_pure" ); >> > return func_gp_pure( i ); >> > } >> > >> >}; >> > >> >struct Father_wrapper : test_ns::Father, bp::wrapper< >> test_ns::Father > { >> > >> > Father_wrapper(test_ns::Father const & arg ) >> > : test_ns::Father( arg ) >> > , bp::wrapper< test_ns::Father >() >> > {} >> > >> > Father_wrapper() >> > : test_ns::Father() >> > , bp::wrapper< test_ns::Father >() >> > {} >> > >> > virtual int gp_pure( int i ) { >> > if( bp::override func_gp_pure = this->get_override( >> "gp_pure" ) ) >> > return func_gp_pure( i ); >> > else >> > return test_ns::Father::gp_pure( i ); >> > } >> > >> > >> > virtual int default_gp_pure( int i ) { >> > return test_ns::Father::gp_pure( i ); >> > } >> > >> >}; >> > >> >struct Son_wrapper : test_ns::Son, bp::wrapper< test_ns::Son > { >> > >> > Son_wrapper(test_ns::Son const & arg ) >> > : test_ns::Son( arg ) >> > , bp::wrapper< test_ns::Son >() >> > {} >> > >> > Son_wrapper() >> > : test_ns::Son() >> > , bp::wrapper< test_ns::Son >() >> > {} >> > >> > virtual int gp_pure( int i ){ >> > bp::override func_gp_pure = this->get_override( "gp_pure" ); >> > return func_gp_pure( i ); >> > } >> > >> >}; >> > >> >BOOST_PYTHON_MODULE(_test){ >> > bp::class_< Grandpa_wrapper, boost::noncopyable >( "Grandpa" ) >> > .def("gp_pure" >> > , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) >> > , ( bp::arg("i") ) >> > , bp::default_call_policies() ); >> > >> > bp::class_< Father_wrapper, bp::bases< test_ns::Grandpa > >( >> "Father" ) >> > .def("gp_pure" >> > , &::test_ns::Father::gp_pure >> > , &Father_wrapper::default_gp_pure >> > , ( bp::arg("i") ) >> > , bp::default_call_policies() ); >> > >> > bp::class_< Son_wrapper, bp::bases< test_ns::Father > >( "Son" ) >> > .def("gp_pure" >> > , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) >> > , ( bp::arg("i") ) >> > , bp::default_call_policies() ); >> >} >> > >> > >> >------------------------------------------------------------------------ >> >> > >> > >> >namespace test_ns >> >{ >> >class Grandpa >> >{ >> >public: >> > virtual int gp_pure(int i) = 0; >> >}; >> > >> >class Father : public Grandpa >> >{ >> >public: >> > virtual int gp_pure(int i); >> >}; >> > >> >class Son : public Father >> >{ >> >public: >> >}; >> > >> >} // namespace test_ns >> > >> > >> >> >> >> ------------------------------------------------------- >> All the advantages of Linux Managed Hosting--Without the Cost and Risk! >> Fully trained technicians. The highest number of Red Hat >> certifications in >> the hosting industry. Fanatical Support. Click to learn more >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >> _______________________________________________ >> pygccxml-development mailing list >> pyg...@li... >> https://lists.sourceforge.net/lists/listinfo/pygccxml-development >> > > |
From: Roman Y. <rom...@gm...> - 2006-05-23 19:51:11
|
> > Allen Bierbaum wrote: > > > > > > > > >namespace test_ns > > >{ > > >class Grandpa > > >{ > > >public: > > > virtual int gp_pure(int i) =3D 0; > > >}; > > > > > >class Father : public Grandpa > > >{ > > >public: > > > virtual int gp_pure(int i); > > >}; > > > > > >class Son : public Father > > >{ > > >public: > > >}; > > > > > >} // namespace test_ns You need to check out module_creator/creator.py file: Here is the code generated after I fixed the bug: #include "boost/python.hpp" #include "Classes.h" namespace bp =3D boost::python; struct Grandpa_wrapper : test_ns::Grandpa, bp::wrapper< test_ns::Grandpa > = { Grandpa_wrapper() : test_ns::Grandpa() , bp::wrapper< test_ns::Grandpa >() {} virtual int gp_pure( int i ){ bp::override func_gp_pure =3D this->get_override( "gp_pure" ); return func_gp_pure( i ); } }; struct Father_wrapper : test_ns::Father, bp::wrapper< test_ns::Father > { Father_wrapper(test_ns::Father const & arg ) : test_ns::Father( arg ) , bp::wrapper< test_ns::Father >() {} Father_wrapper() : test_ns::Father() , bp::wrapper< test_ns::Father >() {} virtual int gp_pure( int i ) { if( bp::override func_gp_pure =3D this->get_override( "gp_pure" ) ) return func_gp_pure( i ); else return test_ns::Father::gp_pure( i ); } virtual int default_gp_pure( int i ) { return test_ns::Father::gp_pure( i ); } }; BOOST_PYTHON_MODULE(pyplusplus){ bp::class_< Grandpa_wrapper, boost::noncopyable >( "Grandpa" ) .def("gp_pure" , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) , ( bp::arg("i") ) , bp::default_call_policies() ); bp::class_< Father_wrapper, bp::bases< test_ns::Grandpa > >( "Father" ) .def("gp_pure" , &::test_ns::Father::gp_pure , &Father_wrapper::default_gp_pure , ( bp::arg("i") ) , bp::default_call_policies() ); bp::class_< test_ns::Son, bp::bases< test_ns::Father > >( "Son" ); } Enjoy. --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-05-23 19:40:39
|
Allen, there is no work around for this bug, so I work on it right now. I believe you will have an answer pretty soon. On 5/23/06, Allen Bierbaum <al...@vr...> wrote: > I should also have mentioned that as of yet I have not found a work > around for this bug. > > I tried to work around it by "finalizing" the Son class, but I can't > find a reliable way to finalize a class with pyplusplus. Until then I > think I am at an impass. :( > > -Allen > > > Allen Bierbaum wrote: > > > I think I have found a bug in the handling of virtual methods with > > pyplusplus. > > > > I have attached a set of test classes and the generated bindings. > > > > The problem seems to be that when you have 3 classes derived from each > > other as: > > > > class Grandpa > > class Father : public Grandpa > > class Son : public Father > > > > And Grandpa declares a pure virtual method that is defined in Father > > but just used in Son, the wrapper for Son still thinks it is a pure > > virtual and doesn't know to generate code with the default > > implementation in Father. (See the attached code, it really makes > > more sense with an example) > > > > -Allen > > > >------------------------------------------------------------------------ > > > >// This file has been generated by pyplusplus. > > > >#include "boost/python.hpp" > > > >#include "/home/allenb/temp/pypp_test/Classes.h" > > > >namespace bp =3D boost::python; > > > >struct Grandpa_wrapper : test_ns::Grandpa, bp::wrapper< test_ns::Grandpa= > { > > > > Grandpa_wrapper() > > : test_ns::Grandpa() > > , bp::wrapper< test_ns::Grandpa >() > > {} > > > > virtual int gp_pure( int i ){ > > bp::override func_gp_pure =3D this->get_override( "gp_pure" ); > > return func_gp_pure( i ); > > } > > > >}; > > > >struct Father_wrapper : test_ns::Father, bp::wrapper< test_ns::Father > = { > > > > Father_wrapper(test_ns::Father const & arg ) > > : test_ns::Father( arg ) > > , bp::wrapper< test_ns::Father >() > > {} > > > > Father_wrapper() > > : test_ns::Father() > > , bp::wrapper< test_ns::Father >() > > {} > > > > virtual int gp_pure( int i ) { > > if( bp::override func_gp_pure =3D this->get_override( "gp_pure" = ) ) > > return func_gp_pure( i ); > > else > > return test_ns::Father::gp_pure( i ); > > } > > > > > > virtual int default_gp_pure( int i ) { > > return test_ns::Father::gp_pure( i ); > > } > > > >}; > > > >struct Son_wrapper : test_ns::Son, bp::wrapper< test_ns::Son > { > > > > Son_wrapper(test_ns::Son const & arg ) > > : test_ns::Son( arg ) > > , bp::wrapper< test_ns::Son >() > > {} > > > > Son_wrapper() > > : test_ns::Son() > > , bp::wrapper< test_ns::Son >() > > {} > > > > virtual int gp_pure( int i ){ > > bp::override func_gp_pure =3D this->get_override( "gp_pure" ); > > return func_gp_pure( i ); > > } > > > >}; > > > >BOOST_PYTHON_MODULE(_test){ > > bp::class_< Grandpa_wrapper, boost::noncopyable >( "Grandpa" ) > > .def("gp_pure" > > , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) > > , ( bp::arg("i") ) > > , bp::default_call_policies() ); > > > > bp::class_< Father_wrapper, bp::bases< test_ns::Grandpa > >( "Father= " ) > > .def("gp_pure" > > , &::test_ns::Father::gp_pure > > , &Father_wrapper::default_gp_pure > > , ( bp::arg("i") ) > > , bp::default_call_policies() ); > > > > bp::class_< Son_wrapper, bp::bases< test_ns::Father > >( "Son" ) > > .def("gp_pure" > > , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) > > , ( bp::arg("i") ) > > , bp::default_call_policies() ); > >} > > > > > >------------------------------------------------------------------------ > > > > > >namespace test_ns > >{ > >class Grandpa > >{ > >public: > > virtual int gp_pure(int i) =3D 0; > >}; > > > >class Father : public Grandpa > >{ > >public: > > virtual int gp_pure(int i); > >}; > > > >class Son : public Father > >{ > >public: > >}; > > > >} // namespace test_ns > > > > > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications i= n > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat= =3D121642 > _______________________________________________ > pygccxml-development mailing list > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Allen B. <al...@vr...> - 2006-05-23 19:30:09
|
I should also have mentioned that as of yet I have not found a work around for this bug. I tried to work around it by "finalizing" the Son class, but I can't find a reliable way to finalize a class with pyplusplus. Until then I think I am at an impass. :( -Allen Allen Bierbaum wrote: > I think I have found a bug in the handling of virtual methods with > pyplusplus. > > I have attached a set of test classes and the generated bindings. > > The problem seems to be that when you have 3 classes derived from each > other as: > > class Grandpa > class Father : public Grandpa > class Son : public Father > > And Grandpa declares a pure virtual method that is defined in Father > but just used in Son, the wrapper for Son still thinks it is a pure > virtual and doesn't know to generate code with the default > implementation in Father. (See the attached code, it really makes > more sense with an example) > > -Allen > >------------------------------------------------------------------------ > >// This file has been generated by pyplusplus. > >#include "boost/python.hpp" > >#include "/home/allenb/temp/pypp_test/Classes.h" > >namespace bp = boost::python; > >struct Grandpa_wrapper : test_ns::Grandpa, bp::wrapper< test_ns::Grandpa > { > > Grandpa_wrapper() > : test_ns::Grandpa() > , bp::wrapper< test_ns::Grandpa >() > {} > > virtual int gp_pure( int i ){ > bp::override func_gp_pure = this->get_override( "gp_pure" ); > return func_gp_pure( i ); > } > >}; > >struct Father_wrapper : test_ns::Father, bp::wrapper< test_ns::Father > { > > Father_wrapper(test_ns::Father const & arg ) > : test_ns::Father( arg ) > , bp::wrapper< test_ns::Father >() > {} > > Father_wrapper() > : test_ns::Father() > , bp::wrapper< test_ns::Father >() > {} > > virtual int gp_pure( int i ) { > if( bp::override func_gp_pure = this->get_override( "gp_pure" ) ) > return func_gp_pure( i ); > else > return test_ns::Father::gp_pure( i ); > } > > > virtual int default_gp_pure( int i ) { > return test_ns::Father::gp_pure( i ); > } > >}; > >struct Son_wrapper : test_ns::Son, bp::wrapper< test_ns::Son > { > > Son_wrapper(test_ns::Son const & arg ) > : test_ns::Son( arg ) > , bp::wrapper< test_ns::Son >() > {} > > Son_wrapper() > : test_ns::Son() > , bp::wrapper< test_ns::Son >() > {} > > virtual int gp_pure( int i ){ > bp::override func_gp_pure = this->get_override( "gp_pure" ); > return func_gp_pure( i ); > } > >}; > >BOOST_PYTHON_MODULE(_test){ > bp::class_< Grandpa_wrapper, boost::noncopyable >( "Grandpa" ) > .def("gp_pure" > , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) > , ( bp::arg("i") ) > , bp::default_call_policies() ); > > bp::class_< Father_wrapper, bp::bases< test_ns::Grandpa > >( "Father" ) > .def("gp_pure" > , &::test_ns::Father::gp_pure > , &Father_wrapper::default_gp_pure > , ( bp::arg("i") ) > , bp::default_call_policies() ); > > bp::class_< Son_wrapper, bp::bases< test_ns::Father > >( "Son" ) > .def("gp_pure" > , bp::pure_virtual( &::test_ns::Grandpa::gp_pure ) > , ( bp::arg("i") ) > , bp::default_call_policies() ); >} > > >------------------------------------------------------------------------ > > >namespace test_ns >{ >class Grandpa >{ >public: > virtual int gp_pure(int i) = 0; >}; > >class Father : public Grandpa >{ >public: > virtual int gp_pure(int i); >}; > >class Son : public Father >{ >public: >}; > >} // namespace test_ns > > |