Re: Re: prints to std::cout in qgis

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re: prints to std::cout in qgis

Marco Hugentobler-2
Hi qgissers,

I will have time to do the implementation of the logger class tomorrow. My suggestion is a header as below. QgsLogger would query the environment variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and print out messages or not.
The question is how the output should be controled by QGIS_DEBUG. One possibility would be to have QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for fatal and critical, QGIS_DEBUG=3 for fatal, critical, warning, etc. If QGIS_DEBUG_FILE is set, only messages from that file will be printed. Else, messages from all files will be printed. What do you think?

class QgsLogger
{
public:
 static debug(QString msg, const char* file = 0, const char* function = 0);
 static debug(QString var, int val, const char* file = 0, const char* function = 0);
 static debug(QString var, double val, const char* file = 0, const char* function = 0); //goes to qDebug

 static warning(QString msg); //goes to qWarning

 static critical(QString msg); //goes to qCritical

 static fatal(QString msg); //goes to qFatal
}

Marco

>On 3/22/06, Tim Sutton <[hidden email]> wrote:
>> One other idea I could throw into the pot is to have a logger class. We
>> could then set it up to write to console, to file or even in the future
>> to some part of the gui. The latter could help when we have non
>> technical users and windows users who experience problems - we can just
>> ask us to send output from the logger window or whathaveyou. Log
>> requests could be static methods or we could use qt signals and slots
>> and connect the logger to objects being logged when they are
>> instantiated. Example invocation mechanisms:
>>
>> emit logMessage("foo",QgsLogger::Critical);
>> emit logMessage("foo",QgsLogger::Informational);
>>
>> or
>>
>> QgsLogger::logMessage("foo",QgsLogger::Critical);
>> QgsLogger::logMessage("foo",QgsLogger::Informational);
>
>I prefer the second over emit. But it is too long, I would make it shorter:
>
>QgsLog::critical("foo");
>QgsLog::info("foo");
>QgsLog::debug(1,"foo"); // 1 is level controled by env. var.
>
>It is also often useful to print variable name - value pairs and
>QString::number() is too long, so I would suggest also
>
>QgsLog::debug(int l, QString var, int val);
>QgsLog::debug(int l, QString var, double val);
>
>Radim
>
>> Just another thought anyway...
>>
>> Regards
>>
>> Tim
>_______________________________________________
>Qgis-developer mailing list
>[hidden email]
>http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>
>
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: prints to std::cout in qgis

Mateusz Loskot
[hidden email] wrote:
> Hi qgissers,
>
> I will have time to do the implementation of the logger class
> tomorrow. My suggestion is a header as below. QgsLogger would query
> the environment variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and
> print out messages or not.

Yes.

> The question is how the output should be
> controled by QGIS_DEBUG. One possibility would be to have
> QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for fatal and critical,
> QGIS_DEBUG=3 for fatal, critical, warning, etc. If QGIS_DEBUG_FILE is
> set, only messages from that file will be printed. Else, messages
> from all files will be printed. What do you think?

I think this is a good idea.

Here is a bit modified version of QgsLogger with simeple use case.
Simply, I'd suggest to use template member what will make it possible to
pass e.g. objects of class types that have ostream operator defined.

#include <QtGlobal>
#include <QString>

#include <sstream>

class QgsLogger
{
public:

static void debug(QString msg, const char* file = 0, const char*
function = 0)
{
   qDebug("File: %s\nFunction: %s\nMessage: %s",
         file, function, msg.toLocal8Bit().data());
}

template <typename T>
static void debug(QString var, T val, const char* file = 0, const char*
function = 0)
{
   std::ostringstream os;
   os << var.toLocal8Bit().data() << " = " << val;

   qDebug("File: %s\nFunction: %s\nMessage: %s",
         file, function, os.str().c_str());
}


// REST OF FUCTIONS

};

Simple use case:



#include "qgslogger.h"

void foo(int x)
{
   QgsLogger::debug("x", x, __FILE__, __FUNCTION__);
}

int main()
{
   QgsLogger::debug("Error occured", __FILE__, __FUNCTION__);

   foo(19);

   return 0;
}

Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Re: prints to std::cout in qgis

Tim Sutton
In reply to this post by Marco Hugentobler-2
Hi Marco

I think it would be interesting to combine the logger functions with
the unit tests I am planning. So for example a unit test may achieve a
result but produce critical errors / warnings (Im assuming if its
fatal, the unit test would fail). With this in mind it would be
interesting to propoage __FILE__ and __LINE__ into the logs. I was
also wondering if a simple xml format (or delimited text for xml
haters) could be produced by the logger e.g.

xml:

<Message file="qgisapp.cpp" line="1232" severity="critical">
  QGIS has detected a wobble in the earths orbit
</Message>

or:

File               Line    Severity  Message
qgisapp.cpp   1232   Critical    QGIS has detected a wobble in the earths orbit
etc.

My idea is that we could then record stats across the test suite. e.g.
I run the test suite and  the stats tell give me  a global report:

File | Total Fatal  | Uniqe Fatal | Total Critical | Unique Critical
| Total Warning | Unique Warning
---------------------------------------------------------------------------------------------------------------------------------------
qgisapp   10              6                    5                    
4                10                   10
---------------------------------------------------------------------------------------------------------------------------------------
all files     100            88                 66                  
22                 99                  22
---------------------------------------------------------------------------------------------------------------------------------------


This would be very useful way of measuring the growth or reduction of
problems encountered.


Regards

Tim


On 4/3/06, [hidden email] <[hidden email]> wrote:

> Hi qgissers,
>
> I will have time to do the implementation of the logger class tomorrow. My suggestion is a header as below. QgsLogger would query the environment variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and print out messages or not.
> The question is how the output should be controled by QGIS_DEBUG. One possibility would be to have QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for fatal and critical, QGIS_DEBUG=3 for fatal, critical, warning, etc. If QGIS_DEBUG_FILE is set, only messages from that file will be printed. Else, messages from all files will be printed. What do you think?
>
> class QgsLogger
> {
> public:
>  static debug(QString msg, const char* file = 0, const char* function = 0);
>  static debug(QString var, int val, const char* file = 0, const char* function = 0);
>  static debug(QString var, double val, const char* file = 0, const char* function = 0); //goes to qDebug
>
>  static warning(QString msg); //goes to qWarning
>
>  static critical(QString msg); //goes to qCritical
>
>  static fatal(QString msg); //goes to qFatal
> }
>
> Marco
>
> >On 3/22/06, Tim Sutton <[hidden email]> wrote:
> >> One other idea I could throw into the pot is to have a logger class. We
> >> could then set it up to write to console, to file or even in the future
> >> to some part of the gui. The latter could help when we have non
> >> technical users and windows users who experience problems - we can just
> >> ask us to send output from the logger window or whathaveyou. Log
> >> requests could be static methods or we could use qt signals and slots
> >> and connect the logger to objects being logged when they are
> >> instantiated. Example invocation mechanisms:
> >>
> >> emit logMessage("foo",QgsLogger::Critical);
> >> emit logMessage("foo",QgsLogger::Informational);
> >>
> >> or
> >>
> >> QgsLogger::logMessage("foo",QgsLogger::Critical);
> >> QgsLogger::logMessage("foo",QgsLogger::Informational);
> >
> >I prefer the second over emit. But it is too long, I would make it shorter:
> >
> >QgsLog::critical("foo");
> >QgsLog::info("foo");
> >QgsLog::debug(1,"foo"); // 1 is level controled by env. var.
> >
> >It is also often useful to print variable name - value pairs and
> >QString::number() is too long, so I would suggest also
> >
> >QgsLog::debug(int l, QString var, int val);
> >QgsLog::debug(int l, QString var, double val);
> >
> >Radim
> >
> >> Just another thought anyway...
> >>
> >> Regards
> >>
> >> Tim
> >_______________________________________________
> >Qgis-developer mailing list
> >[hidden email]
> >http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
> >
> >
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>


--
Tim Sutton

Visit http://qgis.org for a great Open Source GIS
Skype: timlinux
MSN: [hidden email]
Yahoo: [hidden email]
Jabber: timlinux
Irc: timlinux on #qgis at freenode.net
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: prints to std::cout in qgis

Tim Sutton
In reply to this post by Mateusz Loskot
Hi

Adding __FUNCTION__ to my reports would also be useful

Tim



On 4/3/06, Mateusz Łoskot <[hidden email]> wrote:

> [hidden email] wrote:
> > Hi qgissers,
> >
> > I will have time to do the implementation of the logger class
> > tomorrow. My suggestion is a header as below. QgsLogger would query
> > the environment variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and
> > print out messages or not.
>
> Yes.
>
> > The question is how the output should be
> > controled by QGIS_DEBUG. One possibility would be to have
> > QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for fatal and critical,
> > QGIS_DEBUG=3 for fatal, critical, warning, etc. If QGIS_DEBUG_FILE is
> > set, only messages from that file will be printed. Else, messages
> > from all files will be printed. What do you think?
>
> I think this is a good idea.
>
> Here is a bit modified version of QgsLogger with simeple use case.
> Simply, I'd suggest to use template member what will make it possible to
> pass e.g. objects of class types that have ostream operator defined.
>
> #include <QtGlobal>
> #include <QString>
>
> #include <sstream>
>
> class QgsLogger
> {
> public:
>
> static void debug(QString msg, const char* file = 0, const char*
> function = 0)
> {
>    qDebug("File: %s\nFunction: %s\nMessage: %s",
>          file, function, msg.toLocal8Bit().data());
> }
>
> template <typename T>
> static void debug(QString var, T val, const char* file = 0, const char*
> function = 0)
> {
>    std::ostringstream os;
>    os << var.toLocal8Bit().data() << " = " << val;
>
>    qDebug("File: %s\nFunction: %s\nMessage: %s",
>          file, function, os.str().c_str());
> }
>
>
> // REST OF FUCTIONS
>
> };
>
> Simple use case:
>
>
>
> #include "qgslogger.h"
>
> void foo(int x)
> {
>    QgsLogger::debug("x", x, __FILE__, __FUNCTION__);
> }
>
> int main()
> {
>    QgsLogger::debug("Error occured", __FILE__, __FUNCTION__);
>
>    foo(19);
>
>    return 0;
> }
>
> Cheers
> --
> Mateusz Łoskot
> http://mateusz.loskot.net
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>

--
Tim Sutton

Visit http://qgis.org for a great Open Source GIS
Skype: timlinux
MSN: [hidden email]
Yahoo: [hidden email]
Jabber: timlinux
Irc: timlinux on #qgis at freenode.net

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: prints to std::cout in qgis

Mateusz Loskot
In reply to this post by Tim Sutton
Tim Sutton wrote:

> Hi Marco
>
> I think it would be interesting to combine the logger functions with
>  the unit tests I am planning. So for example a unit test may achieve
>  a result but produce critical errors / warnings (Im assuming if its
>  fatal, the unit test would fail). With this in mind it would be
> interesting to propoage __FILE__ and __LINE__ into the logs. I was
> also wondering if a simple xml format (or delimited text for xml
> haters) could be produced by the logger e.g.
>
> xml:
>
> <Message file="qgisapp.cpp" line="1232" severity="critical"> QGIS has
>  detected a wobble in the earths orbit </Message>
>
> or:
>
> File               Line    Severity  Message qgisapp.cpp   1232
> Critical    QGIS has detected a wobble in the earths orbit etc.

It could be nice to have possibility to create 1-3 test reporter for
different output.
This is how Unit Tests work in GEOS.
Test reporter is very very simple code, that just grabs output from
Unit Test runner. Reporter catches callbacks/signals from test runner.

Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: prints to std::cout in qgis

Hugentobler  Marco
In reply to this post by Tim Sutton
Hi Tim,

Right, __LINE__ and __FUNCTION__ are also important.
XML log file would be a good extension.


Regards,
Marco


Am Montag 03 April 2006 17:22 schrieb Tim Sutton:

> Hi Marco
>
> I think it would be interesting to combine the logger functions with
> the unit tests I am planning. So for example a unit test may achieve a
> result but produce critical errors / warnings (Im assuming if its
> fatal, the unit test would fail). With this in mind it would be
> interesting to propoage __FILE__ and __LINE__ into the logs. I was
> also wondering if a simple xml format (or delimited text for xml
> haters) could be produced by the logger e.g.
>
> xml:
>
> <Message file="qgisapp.cpp" line="1232" severity="critical">
>   QGIS has detected a wobble in the earths orbit
> </Message>
>
> or:
>
> File               Line    Severity  Message
> qgisapp.cpp   1232   Critical    QGIS has detected a wobble in the earths
> orbit etc.
>
> My idea is that we could then record stats across the test suite. e.g.
> I run the test suite and  the stats tell give me  a global report:
>
> File | Total Fatal  | Uniqe Fatal | Total Critical | Unique Critical
>
> | Total Warning | Unique Warning
>
> ---------------------------------------------------------------------------
>------------------------------------------------------------ qgisapp   10  
>           6                    5
> 4                10                   10
> ---------------------------------------------------------------------------
>------------------------------------------------------------ all files    
> 100            88                 66
> 22                 99                  22
> ---------------------------------------------------------------------------
>------------------------------------------------------------
>
>
> This would be very useful way of measuring the growth or reduction of
> problems encountered.
>
>
> Regards
>
> Tim
>
> On 4/3/06, [hidden email] <[hidden email]> wrote:
> > Hi qgissers,
> >
> > I will have time to do the implementation of the logger class tomorrow.
> > My suggestion is a header as below. QgsLogger would query the environment
> > variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and print out messages
> > or not. The question is how the output should be controled by QGIS_DEBUG.
> > One possibility would be to have QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for
> > fatal and critical, QGIS_DEBUG=3 for fatal, critical, warning, etc. If
> > QGIS_DEBUG_FILE is set, only messages from that file will be printed.
> > Else, messages from all files will be printed. What do you think?
> >
> > class QgsLogger
> > {
> > public:
> >  static debug(QString msg, const char* file = 0, const char* function =
> > 0); static debug(QString var, int val, const char* file = 0, const char*
> > function = 0); static debug(QString var, double val, const char* file =
> > 0, const char* function = 0); //goes to qDebug
> >
> >  static warning(QString msg); //goes to qWarning
> >
> >  static critical(QString msg); //goes to qCritical
> >
> >  static fatal(QString msg); //goes to qFatal
> > }
> >
> > Marco
> >
> > >On 3/22/06, Tim Sutton <[hidden email]> wrote:
> > >> One other idea I could throw into the pot is to have a logger class.
> > >> We could then set it up to write to console, to file or even in the
> > >> future to some part of the gui. The latter could help when we have non
> > >> technical users and windows users who experience problems - we can
> > >> just ask us to send output from the logger window or whathaveyou. Log
> > >> requests could be static methods or we could use qt signals and slots
> > >> and connect the logger to objects being logged when they are
> > >> instantiated. Example invocation mechanisms:
> > >>
> > >> emit logMessage("foo",QgsLogger::Critical);
> > >> emit logMessage("foo",QgsLogger::Informational);
> > >>
> > >> or
> > >>
> > >> QgsLogger::logMessage("foo",QgsLogger::Critical);
> > >> QgsLogger::logMessage("foo",QgsLogger::Informational);
> > >
> > >I prefer the second over emit. But it is too long, I would make it
> > > shorter:
> > >
> > >QgsLog::critical("foo");
> > >QgsLog::info("foo");
> > >QgsLog::debug(1,"foo"); // 1 is level controled by env. var.
> > >
> > >It is also often useful to print variable name - value pairs and
> > >QString::number() is too long, so I would suggest also
> > >
> > >QgsLog::debug(int l, QString var, int val);
> > >QgsLog::debug(int l, QString var, double val);
> > >
> > >Radim
> > >
> > >> Just another thought anyway...
> > >>
> > >> Regards
> > >>
> > >> Tim
> > >
> > >_______________________________________________
> > >Qgis-developer mailing list
> > >[hidden email]
> > >http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > [hidden email]
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>
> --
> Tim Sutton
>
> Visit http://qgis.org for a great Open Source GIS
> Skype: timlinux
> MSN: [hidden email]
> Yahoo: [hidden email]
> Jabber: timlinux
> Irc: timlinux on #qgis at freenode.net
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Re: prints to std::cout in qgis

Radim Blazek-2
In reply to this post by Marco Hugentobler-2
On 4/3/06, [hidden email] <[hidden email]> wrote:

> Hi qgissers,
>
> I will have time to do the implementation of the logger class tomorrow. My suggestion is a header as below. QgsLogger would query the environment variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and print out messages or not.
> The question is how the output should be controled by QGIS_DEBUG. One possibility would be to have QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for fatal and critical, QGIS_DEBUG=3 for fatal, critical, warning, etc. If QGIS_DEBUG_FILE is set, only messages from that file will be printed. Else, messages from all files will be printed. What do you think?
>
> class QgsLogger
> {
> public:
>  static debug(QString msg, const char* file = 0, const char* function = 0);
>  static debug(QString var, int val, const char* file = 0, const char* function = 0);
>  static debug(QString var, double val, const char* file = 0, const char* function = 0); //goes to qDebug
>
>  static warning(QString msg); //goes to qWarning
>
>  static critical(QString msg); //goes to qCritical
>
>  static fatal(QString msg); //goes to qFatal
> }

I thought that  QGIS_DEBUG would only control debug messages
(not warning/critical/fatal) and the level could be optionaly defined in
overloaded methods (default level 1):
   static debug(int level, QString msg)
It is important for example to have a possibility to avoid debug from loops
through data, for example:

   debug("raster draw"); // level 1
   for each row {
        debug (2, "raster row"); //level 2
        for each col {
            debug (3, "pixel value"); //level 3
        }
   }

i.e. normaly on level 1 it will only print "raster draw", if there
are problems with rendering user can set higher level.

Could we also have a macro calling debug automaticaly with
__FILE__, __FUNCTION__, __LINE__
if available?

Radim

> Marco
>
> >On 3/22/06, Tim Sutton <[hidden email]> wrote:
> >> One other idea I could throw into the pot is to have a logger class. We
> >> could then set it up to write to console, to file or even in the future
> >> to some part of the gui. The latter could help when we have non
> >> technical users and windows users who experience problems - we can just
> >> ask us to send output from the logger window or whathaveyou. Log
> >> requests could be static methods or we could use qt signals and slots
> >> and connect the logger to objects being logged when they are
> >> instantiated. Example invocation mechanisms:
> >>
> >> emit logMessage("foo",QgsLogger::Critical);
> >> emit logMessage("foo",QgsLogger::Informational);
> >>
> >> or
> >>
> >> QgsLogger::logMessage("foo",QgsLogger::Critical);
> >> QgsLogger::logMessage("foo",QgsLogger::Informational);
> >
> >I prefer the second over emit. But it is too long, I would make it shorter:
> >
> >QgsLog::critical("foo");
> >QgsLog::info("foo");
> >QgsLog::debug(1,"foo"); // 1 is level controled by env. var.
> >
> >It is also often useful to print variable name - value pairs and
> >QString::number() is too long, so I would suggest also
> >
> >QgsLog::debug(int l, QString var, int val);
> >QgsLog::debug(int l, QString var, double val);
> >
> >Radim
> >
> >> Just another thought anyway...
> >>
> >> Regards
> >>
> >> Tim
> >_______________________________________________
> >Qgis-developer mailing list
> >[hidden email]
> >http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
> >
> >
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: prints to std::cout in qgis

Hugentobler  Marco

Hi Radim,

I see, so levels for debug messages and warning, critical, fatal turned on.

> I thought that  QGIS_DEBUG would only control debug messages
> (not warning/critical/fatal) and the level could be optionaly defined in
> overloaded methods (default level 1):
>    static debug(int level, QString msg)
> It is important for example to have a possibility to avoid debug from loops
> through data, for example:
>
>    debug("raster draw"); // level 1
>    for each row {
>         debug (2, "raster row"); //level 2
>         for each col {
>             debug (3, "pixel value"); //level 3
>         }
>    }
>
> i.e. normaly on level 1 it will only print "raster draw", if there
> are problems with rendering user can set higher level.
>
> Could we also have a macro calling debug automaticaly with
> __FILE__, __FUNCTION__, __LINE__
> if available?
>
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer