Re: [pygccxml-development] Indexing suite exception

[Matthias B. <ba...@ir...>]

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

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

- Matthias -