[C++-sig] pyplusplus tutorials & GUI wizard

[Roman Yakovenko]

On 1/25/06, Matthias Baas <baas at ira.uka.de> wrote:
> Roman Yakovenko wrote:
> > What information is missing?
>
> Well, for example, the information from the new tutorial was missing.
> Before the tutorial it was not obvious to me how the tool actually works
> and what steps are required from the user.

If I understand you right, tutorials provides all information in order
to make decision and\or
to start with pyplusplus, right?

>
> >> so why
> >> does this have to be provided by the user and why isn't it put under the
> >> hood of pyplusplus instead?
> >
> > What do you mean. If you mean parsing\reading C++ then the answer is simple:
> > pyplusplus does not care from where you read declarations. And I thing
> > that keeping this separation is important.
>
> That's not really what I meant. I have absolutely no objections of your
> design to keep parsing the sources and creating the output separate
> processes. I second that design and I don't argue that you should change
> that. But why not adding some additional layer above this design that
> hides this implementation detail if not otherwise specified. I think
> most if not all users will use pygccxml to parse the sources (what other
> choice do they have?), so why not make that the default procedure?

There are 2 reasons:
1. Filtering. You want to apply different filters on declarations
within projects.
2. Performance reasons. With pygccxml you can save a lot of time on big projects
    by not compiling a source code with GCC-XML every time. On TnFOX project
    it saves more then 30 seconds on my computer
   ( Windows XP, Pentium 2.4, RAM 1.5G ).

> Step 1 of the tutorial consists of 12 lines of code where there are only
> two things that I really had to specify: the name of the input header
> file and a filtering rule (whereas gccxml is on my path, so I didn't
> need to specify that in the driver file.

You need at least 1 more line import pyplusplus. :-)

>And as long as pyplusplus
> cleans up its temporary files, I don't really care where it puts them
> (don't get me wrong, it's absolutely ok to be able to change these
> things but I shouldn't be forced to set them)).

You are talking about
class settings:
    gccxml_path = '/home/roman/gccxml/bin'
    working_dir = '/tmp'

right?

Well, it seems that I should rewrite this section.
working_dir - is directory of source files, may be I should give it an
other name or
to add some comments.
gccxml_path - you don't really need to specify it. pygccxml will try
to find gccxml
in your path, so basically you don't need to specify it.
May be I need to reflect this fact in tutorials?

> Now to pass these two
> pieces of data to pyplusplus I had to import several modules, create a
> class and call some functions. Maybe I'm wrong, but these things looked
> as if they were not from a public interface but actually from the
> internals of the program. Exposing that much stuff from inside the
> program has the disadvantage that my driver file becomes dependent on
> them. Should you ever choose to change some of these things for whatever
> reasons, these changes will break all driver scripts out there which
> would be a very bad thing.

Even if I hide those details and do not expose them to you. Tomorrow
you can find
some bug. Lets say that I can fix that bug only by adding new argument
to a function.
In other words I will ask for more information from you. This change
also breaks your code.
Right? So you are not really safe from dependencies.

> Such dependencies could be reduced if the
> public interface would be kept more slim and rather be of a descriptive
> nature as it is the case with Pyste (another example would be SCons,
> www.scons.org). Access to the internal API could also be provided but it
> should only be necessary for special cases.

I see your point. I think that I will add few convenience function to
mimic Pyste behaviour.

> >> Personally I'd prefer the "signal-to-noise
> >> ratio" in the config/driver file to be as high as possible, i.e. the
> >> file should only contain information that really must be provided by the
> >> user and that pyplusplus cannot know itself. In the tutorial this would
> >> be the input file name and maybe the output module name (which could
> >> even be deduced from the input file name by default). I would say Pyste
> >> performs much better in this respect as its "hello world" example only
> >> requires a single line.
> >
> > Here I don't agree with you. The complexity on start with pyplusplus is higher,
> > you are right. But the point is that this complexity will grow only a
> > little with pyplusplus.
>
> Granted, but in my experience there have been cases where I really could
> get away with short *.pyste files and there was no need to do complex
> stuff. Currently, this would be prohibited with pyplusplus as there is
> only a relatively complex way to describe the wrappers.
> Actually, you wouldn't have to change anything in your package but only
> add an additional layer on top of what is currently there so that for
> easy cases, the descriptions of the wrappers can be as concise as those
> from Pyste.

As I already told I will add few convenience function.
Do you know that you can help? Can you create an interface that you thing should
be in pyplusplus for simple use cases?

I think something like this:

def export_file( file_path, parser_config = config_t() )

def export_files( files, parser_config = config_t() )

What do you think?

> >> So at the end, this round went to Pyste, but I'm eagerly awaiting the
> >> next rounds... :)
> >
> > I don't think so, but I am not objective.
>
> Of course, the above was from my point of view. :) The current state of
> the documentation and the tool just couldn't convince me yet to switch
> from Pyste to pyplusplus, which was for the previously mentioned reasons
> (well, maybe the main reason was that I couldn't get it to work with
> that SDK I'm currently wrapping).

What were the problems? May be I can help you? Or may be you found some bug?

> But as I said, it kept me enough
> interested to provide some feedback (hoping that this will contribute to
> the improvement of pyplusplus) and to try future versions again.
> Your work is still appreciated, my criticism is not meant to bash the
> tool but rather to be an incentive to improve it.

Trust me I've got you right. pyplusplus does not have a lot of users. And such
kind of input is really very very valuable.

> - Matthias -

Thanks

Roman Yakovenko