Re: [pygccxml-development] improving user experience

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

Roman Yakovenko wrote:
> On 7/23/06, Matthias Baas <ba...@ir...> wrote:
>> Personally, I'm against splitting lines. Actually, I'd even prefer to
>> have the entire warning message in one single line so that I see the
>> entire message when I 'grep' for a particular declaration.
>> This would also make it easier to write scripts that further process a
>> log file (e.g. a filter that transforms the single-line log into an
>> easier to read log or even a set of html pages).
> 
> Yes, but in this case line is toooooo long. Personally, I can not read it.
> I have an idea, but I will need your help( =time ). All messages written 
> by py++
> will be written in single line. py++ will create custom formatter,
> that will divide
> message to few lines and will use it by default. You will be able to
> use the formatter
> provided by logging package.It could be nice, if you can find time and
> implement it.

Sounds good! I've already played around with this a bit and did some 
tests. I have some questions though:

readme() returns a list of strings. What exactly are these strings? Is 
each string a separate info/warning message or is the concatenation of 
the strings one single warning message? In what way is the first string 
special? There is the following code in creator_t._prepare_decls() which 
I don't quite understand:

     ...
     if not decl.exportable:
         reason = readme[0]
         if reason in DO_NOT_REPORT_MSGS:
             continue
         readme = readme[1:]
         msg = [ 'Declaration "%s" could not be exported.' % decl ]
         msg.append( reason.replace( os.linesep, os.linesep + '\t' ) )
         self.decl_logger.warn( os.linesep.join( msg ) )

     for msg in readme:
         self.decl_logger.warn( 'Declaration "%s": %s' % ( decl, msg ) )
     ...

Why is the first string in readme treated differently than the other 
strings?
By the way, are there other places where warnings are written to the 
logger? (it appears to me that this is the only location)

I've already modified the above so that the log message is one single 
line. The line consists of two fields containing the declaration string 
and the actual message separated by a colon:

<decl>;<msg>

Additionally I wrote a custom formatter that makes the message more 
readable again by splitting the declaration string and message up again 
and using the textwrap module to prevent long lines. Example:

WARNING: MTime & MTime::operator--() [member_operator]
   ->
   "operator--" is not supported.  See Boost.Python documentation:
   http://www.boost.org/libs/python/doc/v2/operators.html#introduction.

WARNING: MTime & MTime::operator--(int arg0) [member_operator]
   ->
   "operator--" is not supported.  See Boost.Python documentation:
   http://www.boost.org/libs/python/doc/v2/operators.html#introduction.

Or an example of a method that spans several lines:

WARNING: static MCallbackId MUiMessage::addCameraChangedCallback(MString 
const
   & panelName, void (*)( ::MString &,::MObject &,void * ) * func, void *
   clientData=0, MStatus * ReturnStatus=0) [member_function]
   ->
   boost.python can not expose function, which takes as argument/returns
   pointer to function. See
   http://www.boost.org/libs/python/doc/v2/faq.html#funcptr for more
   information.


To make it apparent where a new warning message begins, the actual text 
is indented by 2 blanks. The '->' line should make the beginning of the 
actual message easier to spot (which otherwise can get difficult with 
long declarations).

What is the proper place for the new formatter? Currently, I would put 
it into the _logging_ module and use it as formatter for the default 
stream logger which goes to stdout.
For my additional custom file logger I would simply use a standard 
formatter which leaves everything in one line to make it more 
'grep'-friendly. So I guess everyone's happy then! :)

Roman, does this sound good to you and can I commit that stuff or do you 
have any objections/suggestions, etc?

- Matthias -