Re: [Rosegarden-devel] Consensus on debug printing Re: [rosegarden:code] [r13770] - tedfelix: Comments and debug output

[Tom B. (Tehom) <te...@pa...>]

> On 08/07/2014 11:13 AM, Tom Breton (Tehom) wrote:
>> Ted, I noticed you changed the debug printing to go to std::cerr.
>
>    Yeah, I couldn't think of anything better.
>
>> Is there some way we can handle what you need thru the RG_DEBUG idiom?
>> Or
>> perhaps some way to have the best of both?
>
>    I like to have two things:
>
>    1. Debug output that is present while I'm debugging, but always
> committed turned off so it doesn't get in anyone else's way.  For this,
> I went with RG_DEBUG and RG_NO_DEBUG_PRINT to turn it off when I commit.

Yes, that's important and that's the clean way to do it.

>   I saw in other places #ifdef being used, but that's pretty cumbersome.

Yes, it is very cumbersome.

>    2. Debug output for error situations to help users troubleshoot.
> This would always be enabled, for a debug build anyway.  For this, I
> went with std::cerr since RG_NO_DEBUG_PRINT would have no effect on it.

OK, to help myself understand and/or be clear, let me list the levels of
debug/error output there would be as I understand them:

 * Pop-up messages.  Intended for in-the-users-face issues.  Always on.

 * What you're proposing: Debug output for error situations to help users
troubleshoot, should they choose to.  Turned on in the debug build.

 * What RG_DEBUG is doing now: Very detailed error messages intended for
maintainers.  On short-term during intense development, per developer.

>   (Neither would a release build for that matter.  So, it's a bit
> extreme.)  It would be nice to have an RG_ERROR that acts like RG_DEBUG,
> but isn't affected by RG_NO_DEBUG_PRINT.  I didn't notice anything like
> that in Debug.h.  (Qt has qDebug() and qWarning() which I think roughly
> correspond to what I would use.)

Right and right.

I suspect with cerr or another ostream, you would run into the annoyance
that most operator<< overloads are defined for QT and are thus unavailable
to ostreams.  (Though an important one for Event is just for ostream)

RG_ERROR seems promising.  It looks easy enough to write.  We'd want to
ensure that future developments understood which to use when.

Since these aren't fatal conditions, RG_WARNING might be a more
appropriate name.  An alias like RG_NOTIFY might be wanted for level-2
messages that aren't warnings, such as "RG Translations loaded
successfully." or successfully loading the user's config file.

That's what makes sense to me.

>    But this is just the way I work.  I wouldn't impose this on anyone
> else.  Though I will admit that the deluge of RG_DEBUG output during a
> run does make it more difficult for me to get my work done.  I would
> love to have a "Please don't commit live RG_DEBUG statements" rule.  But
> I've mentioned it in the past, and the idea met with some resistance.

I have no problem with such a rule.  I have not always followed it 100% in
the past; no excuses.  I have no problem with following it in the future,
but I'd like to hear from others.

The deluge of output is a longstanding thing.  Nobody loves it AFAICT.  I
*suspect* that nobody would object if most of it went away.

It might make sense to keep a few major messages like major phases of
initialization.  If I understand what you proposed, those would be
appropriate for the level-2 output.

Anybody else want to voice an opinion?

	Tom Breton (Tehom)