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

[Roman Yakovenko]

On 1/24/06, Matthias Baas <baas at ira.uka.de> wrote:
> It's good to see a more or less introductory tutorial as I couldn't
> extract enough information from the previous pages to get started with
> pyplusplus.

What information is missing?

> First, there's a typo on the page and a bug in the code:
>
> - In step 3 of the tutorial you access the attribute
> "parser_configuration.working_directory" whereas a few lines above the
> configuration object was called "parser_config".

Thank you. Fixed. I will publish it very soon.

> - In method __raise_on_wrong_settings() in
> pygccxml/parser/source_reader.py the variable environment_var_delimiter
> is only defined on Windows but not on other platforms which will raise
> an exception on those other platforms some lines later in the method
> (when the variable is used).

Thank you, fixed.

>
> Now to pyplusplus itself, as a "hello world" example I found the
> required Python script rather complicated. It feels as if a lot of the
> code in those driver scripts will be identical among projects,

This is a wrong filling. The structure of the code will be the same - yes.
The code itself - no.

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

>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.
With Pyste this is not true. I did not try to write the shorter
version, but rather to
show main and strong sides of pyplusplus. If I write a function that
will do the job and
show only this function within tutorials it will say nothing about
pyplusplus and why it
is better then Pyste.

> So I'd suggest to add a command line tool to pyplusplus that reads a
> config file (Python code) that can contain the required information in a
> much more concise manner. You wouldn't loose any flexibility and you
> could remove any "unnecessary" code (that would always be the same). An
> additional benefit of having a separate command line tool would be that
> there is something I can invoke and request some help from it.

There is such tool: GUI. If you don't need any customization use it. You raise
valid point here: pyplusplus GUI does not have persistent state and you can
not invoke it from script to run on the state. You are welcome to contribute.
I will add it to wish list.

> Another wish of mine would be to output some descriptive information (or
> a log file) about what the program is currently doing. For example, I
> tried to wrap a class from a commercial SDK but failed (the output file
> is almost empty and I get another file __array_1.pypp.hpp that is
> neither referenced in the actual output file nor does it contain
> anything that looks as if it was related to the classes in the SDK). I
> have no idea what went wrong as there hasn't been any message at all
> (let alone an error or warning message). Here, it would be useful if the
> program would output what it saw in the input file (how many classes,
> functions, etc.) and what it is going to output, etc.

First version of pyplusplus have some logging functionality. But then I dropped
it for performance reasons. I think that I will add logging again, but this time
I will write statistics only. Thanks for the tip.

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

> (I'll definitely keep an eye on pyplusplus as with using Pyste I had to
> add some manual tweaks, so it's not perfect as well)

If you are fine with Pyste, stay with it. I see no reason to replace
something that
doing it's job.

> - Matthias -

Thanks for review and tips.

Roman Yakovenko