Re: [pygccxml-development] pyplusplus status

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

Roman Yakovenko wrote:

> On 7/18/06, Allen Bierbaum <al...@vr...> wrote:
>
>> What this comment really comes down to is that I don't think the current
>> API fullfills the goals set out at:
>> https://realityforge.vrsource.org/view/PyOpenSG/PyppApiDiscussion
>>
>> 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.
>
>
> This will never happen :-(. py++ knows to export only limited subset 
> of C++.

I think the keywords here are "most tasks".   I think we are already 
close to being able to do most tasks with the higher-level API. I just 
don't think the high-level API allows people to do everything as easily 
as they could with Pyste or the experimental API that Matthias is using.

>
>> Please don't take offense to this Roman, but you understand the APIs of
>> pygccxml and pyplusplus so well and in so much detail that I think your
>> take on what is an "easy API" may be much more in depth then what I
>> would consider an "easy API".
>> ...
>> But having the simple API is still important
>> for allowing new users to pick it up and use the tool.
>
>
> With the power comes complexity. Also I would like to see your
> definition to "simple"
> and "power" API. My definition is next:
>
> simple - API defined by decl_wrappers package and module_builder
> package. Basically,
> this is get\set properties + "query" api.

I would also say the simple API would require limited to no use of 
pygccxml directly.  This may be one of the areas that gets me the most 
because I don't always know where to look in pygccxml to do what I want.

If the query api was more completely documented in a tutorial form (so 
newbies don't have to delve deeply into the reference docs), then I 
think we would be on much better footing here.

>
> power - modifying directly code creators tree. This is really the
> "dark" area of the project,
> but I have an idea how to simplify it and of course I will write a
> documentation that will
> explain it.

I would also add using anything in pygccxml that requires understanding 
of how pygccxml is implemented and using any of pygccxml that is not 
documented in a tutorial.  Basically, if the user has to read the code 
to understand or find what they need to do, then that is not part of the 
simple interface.

>
>> Am I the only one that feels this way when using the API?
>
>
> I definitely would like to get the answer to this question with
> suggestions from other users.
>
>> You just say Template("class") and then instantiate templates.  Very
>> straight forward in Pyste's domain specific lanaguage.
>
>
> Please contribute your code with small example and documentation( and 
> license )
> to py++ :-). I already added new directory for this in "contrib" one.

I think my code as it stands is too complex.  I will try to revisit it 
once I get back to using it (probably late this week or early next week).

>
>> > 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?
>
>
> Almost. pygccxml will create temporal file. I never checked how it
> will behave with a
> cache. Can you check this, and if the behaviour is not as you expect,
> I will try to fix it.
>
>> I would recommend just treating it like you would a .decls() call.  ie.
>> if the users looks up declarations of differing types and then calls a
>> method on those decls that only makes sense for one type, then python
>> will display an error about the type problems.
>
>
> I prefer to continue to discuss this problem within the original thread.

Ok.

>
>> 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.
>
>
> I think, this will be useful, but not now. There is only few peoples
> who contribute
> to the project.
>
> I started to work on FAQs:
> http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/docs/faqs/faqs.rest?view=markup 
>
>
> If you have something specifiec in mind, or want to add documentation
> here and there,
> please do it.
>
>> 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.
>
>
> This is pretty simple: this paper deals with method transformations.
> For example:
>     void get_size( int& h, int&w )
> You will be able to define the transformation of get_size to
>    boost::python::tuple get_size()
>
> The function wrapper, you are talking about, it is just an "user
> defined" transformation.

What I want is not only transformations, but defining completely new 
functions to replace existing functions.

>
>> def processClass(cls):
>>    if cls.count("method"):
>>       # do something
>>
>> I have run into a few cases where something like this could be pretty
>> useful and keep the script more understandable.
>
>
> I will see what I can do.
>
Thanks,
Allen