Re: [pygccxml-development] pyplusplus status

[Matthias B. <ba...@ir...>]

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/

>>> - 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).

>> 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!

>>> - 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).

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.

>>> - 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.

>>> - 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)

>>> - This is a small nitpick, but unless you are making a lot of money from
>>> Google AdSense, could you remove the Google ads in the table of contents
>>> on the website.  They are just annoying and make the documentation
>>> harder to read.
>>
>> I am not, the AdSence is there to return the money I pay for running 
>> web site.
>> I hate the idea to ask for donations. User experience is importer.
>> I will do something about it.
> 
> That would be very helpful. I do not care about the ads on the left bar 
> or even if you added ones at the other sides of the pages.  But putting 
> ads in the middle of the table of contents or text body is a little 
> annoying.

I also think the web page is a bit difficult to read because of the ads. 
  Roman, I don't know how much control you have about the layout of the 
site and the ads, but would it also be possible to separate them from 
the actual content somehow? Like for example, using a different 
background color, adding separating lines or something like this. 
Currently, the distinction between content and ad is not obvious at 
first glance.


- Matthias -