D5693: First attempt to port remaining dbo* statements to qCDebug().

[Johan Ouwerkerk]

On Wed, May 3, 2017 at 10:03 PM, Luigi Toscano <luigi.toscano at tiscali.it> wrote:
> Ian Wadham ha scritto:
>>
>> Re the current issue, it might be unwise to replace all occurrences of
>> "dboN" with calls to qCDebug(), unless the "KSudokuLog" parameter
>> exactly reproduces the behaviour of debug levels and macros defined
>> in file "generator/debug.h".  If log messages appear as "all or none",
>> you will either be flooded with (possibly millions of) messages from
>> the KSudoku solver or receive no messages at all.  Neither of those
>> alternatives would be any use if a bug appeared in the main solver ---
>> and the "debugging on" alternative would be a serious drag on resources,
>> because that solver is invoked multiple times when generating a puzzle.
>>
>> Also, if Johan goes ahead, lines like the following would need attention:
>>     if (dbgLevel >= 2) {
>>         this->print (boardValues);
>>     }
>>
>> It might be easiest just to redefine the "debug.h" file in terms of qCDebug().

This is somewhat difficult.
With the structured logging approach, messages should be filtered out
at runtime instead of compile time based on user-configurable
settings.
Hardcoded 'debug levels' run counter to that idea.

>
>> Similar remarks apply in games where I used the "debug.h" approach to
>> debug details of animation frames (Kubrick? KGoldrunner?).
>
> I disagree that using different systems for logging at the same time
> (printf/fprintf/qDebug) only adds more complexity. On the other side, it is
> possible to select different levels by defining different logging categories,
> and this is something that we should consider for the logs of the solver. I
> rechecked also the logging messages ported from kDebug/qDebug/dbe (sometimes
> the same log was sent through qDebug and dbe) and I think that other levels
> are not required there, but that's open for discussion.
>
> --
> Luigi

To avoid flooding the log, multiple logging categories are certainly a
good idea.
We could use a KSudokuDebugLog like category with a default filter
that lets no messages through.
Then we could log to that category at info (qCInfo()), warning
(qCWarning()) and debug (qCDebug()) levels depending on the log
message.

Perhaps it is best to move this discussion to Phabricator:
https://phabricator.kde.org/D5693 & https://phabricator.kde.org/T5980
That way we keep the discussion and ongoing revisions to the code in
the same place.

Regards,

-Johan Ouwerkerk