Re: [pygccxml-development] pyplusplus status
Brought to you by:
mbaas,
roman_yakovenko
From: Allen B. <al...@vr...> - 2006-07-18 16:10:40
|
Matthias Baas wrote: >Allen Bierbaum wrote: > > >>>>- 90% of users should never have to delve beyond the "easy API" (never >>>>need to know about creators). The current API is close to this, but >>>>there are still some times when IMHO users have to suddenly delve very >>>>deep into the internal code. >>>> >>>> >>>[...] >>> >>> >>The big ones I find missing are: >> >> * Do not require the user to know anything outside of the high-level >> API to accomplish most tasks. >> * Provide access to all the power of pypluplus and pygccxml *if* the >> user wants it >> >>[...] >> >>Am I the only one that feels this way when using the API? >> >> > >No, I also think that most of the time it should be enough to stick to >the high-level API. >I would say this is more or less the case with my Maya bindings, but >then, I'm still using the "experimental" API instead of Roman's version. >I've just committed the current version of the API into the "contrib" >directory (subdirectory "pypp_api"). >My main script to generate the bindings can be found here (pypp_setup.py): >http://svn.sourceforge.net/viewcvs.cgi/cgkit/maya/trunk/maya_wrapper/ > > I did not know you were still keeping these up-to-date. I have to admit it has been a long time since I looked at this interface but it does seem a little more high-level or at least more self contained. Q: If I remember correctly, when I first wrote these I had to modify the code creators to change they code they output. Is this still necessary or is everything captured in the api itself? Maybe the better way to say this is how do you handle decorating and creating for features that are not supported by Roman's API? > > >>>>- template support: I would like to see an API that allows users to more >>>>easily wrap templates. I have had to manually create some code that >>>>does this but I am sure something better could be done. You can see >>>>what I have done at: >>>>https://realityforge.vrsource.org/viewvc/pyopensg/trunk/src/gen_bindings.py?view=markup >>>> >>>>Look for the TemplateBuilder helper class. >>>> >>>> >>>My main objection to this is that users will not use it. Think about >>>it. You can create/generate/generate on fly header file/string and to >>>include it to the list of header files >>>passed to module_builder_t.__init__. You don't have to learn new API. >>> >>> >>And my main reason for saying this is needed is that doing it manually >>is too hard for most users. It is *much* easier to do this with Pyste. >>You just say Template("class") and then instantiate templates. Very >>straight forward in Pyste's domain specific lanaguage. Unfortunately I >>think the domain specific language of pyplusplus is still python and >>this is not good IMHO. >> >> > >I agree with Allen. If you can use a Template() function then you don't >have to know *how* the template class is actually wrapped. Whereas if >you have to create C++ source code yourself you have to know what code >to create, where to put that code, how the code is added to the sources, >etc. > >By the way, the pypp_api stuff still contains the Template() >functionality that Allen has originally written (though I haven't tested >it myself yet as the Maya SDK doesn't contain any templates). > > I took a quick look at it. It looks like I implemented it quite a bit like the Template helper I am using now, but it was more integrated. One of the big reasons is that in the experimental API, the construction of the builder is separated from the parsing. So you could create a builder, call the Template() method on it and then when parsing times comes around the builder could take care of all the autocreation needed behind the scenes for the templates. It wasn't perfect, but it did make it pretty transparent to the users. > > >>>mb = module_builder_t( ... >>> , compilation_mode=pygccxml.parser.COMPILATION_MODE.ALL_AT_ONCE >>> , ... ) >>> >>> >>Does this behave *exactly* the same way. Does it only create one entry >>in the cache? >> >> > >I don't think so. We were talking about that already in a previous >thread quite a while ago. If I remember correctly the ALL_AT_ONCE mode >doesn't use the cache at all, that's why I also create my own header >file for the Maya bindings and do not use ALL_AT_ONCE. > > > >>Would it be useful to make the tutorial and howto a "live" document so >>everyone can contribute, add questions, make changes? If so, what about >>using a wiki so everyone can contribute and fix up the descrptions. >> >> > >Sounds like a good idea to me! > > Anyone else agree or disagree? > > >>>>- Wrap method: Add API for just wrapping an existing method with a new >>>>defined method. (right now this can be cone but you have to exclude the >>>>current method and then call add_code with a 'def'. It is just too >>>>complex for a new user and makes the wrapper gen script look >>>>complicated.) >>>> >>>> >>>http://www.language-binding.net/pyplusplus/peps/call_wrapper_policies.html >>> >>> >>>When I implement this PEP, it will be pretty easy to do what you want. >>>Until then I don't want to introduce something, that I will not >>>support later. >>> >>> >>I don't see how this pep fixes the problem, but then again I don't fully >>understand what the pep will do. I will just trust you that this will >>help out. >> >> > >I think you two are talking about somewhat different things here. >If I understand Allen correctly he wants to replace a method with his >own code instead of wrapping the original method. The original method >might even never get called in the wrapper code but the wrapper code >will still provide the same functionality. I also did that for methods >that deal with stuff like function pointers that need some manual >intervention anyway (even though in most cases I did actually call the >original method). > > Exactly. >The "call wrapper policies" (in my version they are still called arg >policies) are rather meant to attach additional code to a wrapper method >that surrounds the original method invocation. This surrounding code is >mainly used to transform input arguments or return values between Python >and C++ (which cannot be done by Boost.Python automatically in those >cases). One example is the often mentioned "void getSize(int& width, >int& height)" method which cannot be wrapped directly because of the >references. > > > Yes, I need these too. >>>>- Add ability to add user code to namespace or global *without* having >>>>to use code creators directly >>>> >>>> >>>I want to solve this problem, to this release. Can you write what you >>>want/need/expect >>>here? In other words I need use cases and how you see they should be >>>solved. >>> >>> >>I will have to think about this and get back to you. >> >> > >I take it your basically talking about the addStartText(), >addBodyTailText() methods that you implemented in the experimental >version, right? They are still available in pypp_api and I'm also using >them myself. > > Yes, that is what I am thinking about. I am actually just trying to port some code that used the experimental pypp_api and I could not find a way to do this. > > >>>>- Cache parsing and preparing query optimizer. If the input has not >>>>changed (the headers are the same) why do I have to wait for all the >>>>processing of the declarations and query optimization each time. Can't >>>>we cache all of that? >>>> >>>> >>>Yes, but you can guess what the priority of this. Also I think that >>>solution for this >>>problem will be completely in the user code. >>> >>> > >Wouldn't that rather be located in the high level API where the queries >are made? (if it's in the user code it would have to be duplicated with >every new project) > > I agree. This should be handled by the module builder so users don't need to know the implementation details. As I think about it right now, we are really just caching some of the module builder data structures so this seems like exactly something that should be encapsulated in the module builder. Experimental API, pypp_api... I did not realize that there were still two active high-level APIs being developed. As a user this concerns me a little because it means that there are probably good ideas in both that are not being cross-mixed to get the best API possible. (some of the topics above point out those cases). Also, after thinking about it more I believe that many of the limits and issues I am having were addressed at least in some form by the experimental API. The way pypp_api was designed was to provide a very simple and easy to use API that could accomplish what most users would want with a minimal understanding of pyplusplus. One way to make Roman's API more complete and simple would be to re-examine the pypp_api and make sure that Roman's API can do all the things that pypp_api can do with the same level of simplicitly. Comments? -Allen |