Re: [pygccxml-development] Indexing suite exception

[Lakin W. <lak...@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)
>
> >> But as pyplusplus already knows that a particular member won't compile,
> >> shouldn't it then refuse to write it to the output file (as it was the
> >> case before)? Or even abort or something so that the user definitely
> >> knows that some action is required on his side?
> >
> > Now when you have bad experience( and I am sorry for that ) you can
> > give an advice.
> > In my opinion pyplusplus did the job, but of  course I could be wrong.
>
> Well, in general I'd say that knowingly producing code that won't
> compile is bad practice. In this particular case I can live with it as
> it is because 1) there actually is a warning message (even though it
> might pass unnoticed) and 2) once you know what the problem is it is
> easy to either ignore those methods or modify Boost.Python accordingly.
> For now, I just ignored them which was only one additional line in my
> script.
> In my opinion, what should actually be "fixed" here is the way important
> information is passed to the user. I think it's not so much of a problem
> that pyplusplus generated invalid code

I know that I'm just arguing semantics, but I disagree.  The code
_does_ compile and is therefore _not_ invalid.  It just requires you
to pass an extra switch the compiler, in this case:
-DBOOST_PYTHON_MAX_ARITY=19 or somesuch.


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

I don't mind the current behavior as it would be easy for the user to
hook into the logging module and write out messages above a certain
importance to a separate log file.

However, having a some sort of summary printed at the end of all the
interesting things that a User may have to take care of would be nice.


> >> In the code the maximum number (10) is hard-coded, shouldn't that be at
> >> least be user-settable
> >
> > Yes, I fixed and committed.
> >
> >> (or, if possible, automatically determined).
> >
> > It does not worth that, too much work ( make files, auto
> > configuration, scons, bjam, prj .... )
>
> Yes, I agree. If it's not inside an official header file then it's not
> worth trying to get hold of the config files and parse them.

What about generating:
#define BOOST_MAX_ARITY 19
at the top of file which contains those methods that are too long.
I'm not sure about this particular option, but maybe it is possible to
set this option on a per file basis.


Lakin