Re: [pygccxml-development] Indexing suite exception

[Roman Y. <rom...@gm...>]

On 6/21/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > I am aware of the this problem ( lot of output ), so next code will
> > write only important things:
> >
> > import logging
> > from pyplusplus import module_builder
> > module_builder.set_logger_level( logging.INFO )
>
> I have that already in my script, but I still get a line for each
> individual file that is written. Maybe these messages should be debug
> messages instead of info messages (I think a summary of the time it took
> to write the files and maybe how many files were actually updated would
> be enough in the standard case).
> (But apart from that there is still a lot of output from my own script
> that would drown the message anyway)

Do you want/have time to make pyplusplus messages really useful? Can you
fix current situation?

> In my opinion, what should actually be "fixed" here is the way important
> information is passed to the user.

I agree with you. The amount of information, that is written by
pyplusplus is so big,
that users just ignore it. This is the opposite of what I want.

> I think it's not so much of a problem
> that pyplusplus generated invalid code but it's more serious that I
> missed the warnings about that (if I had seen them I wouldn't have tried
> compiling the code in the first place).

Would it be helpful, if pyplusplus will dump the information to the
generated source
files, too? So when you see compilation error you also can read an explanation.

> The problem is that a command line tool basically only has one single
> channel (stdout) to communicate with the user (having stderr as well is
> only a slight improvement as they both refer to the same "channel" by
> default, namely the console window). My suggestion would be to write the
> really important messages (like the max arity thing) into a separate log
> file in addition to writing to stdout (or actually it should be stderr).

What is your definition/guide line of "really important"? Also I agree with you.

> In my opinion this should already be the default behavior. So a user can
> check any time after the tool has run if there have been important
> issues. Before quitting, pyplusplus could even check if anything has
> been written into that log file and print a final message that there
> have been critical errors and the user should refer to that log file.

Writing log to file is quite an improvement. On top of the file we can
write small
guide: search for word  WARNING or ERROR. Or something like this.

>
> >> What if the user actually did increase BOOST_PYTHON_MAX_ARITY?
> >
> > Then he will update decl_wrappers.calldef_t.BOOST_PYTHON_MAX_ARITY to the
> > actual number and will get rid of warning :-)
>
> Aha, there we are... :)
> (though I'd recommend to add functionality to the high level API to
> read/write this value so that the details of where the attribute is
> actually stored in pyplusplus are encapsulated)

:-) I will add new property to module_builder_t. That is what you meant, right?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/