On 5/21/07, Johannes Gajdosik <johannes.gajdosik@gmx.at> wrote:
My opinion about console is this:

1) never use wcout, wcerr, wprintf or similar, just cout and cerr.
I really mean it, this has to do with MS windows. Also Fabien has made a
"style guideline" in the wiki which says the same. An output cleanup must
remove widechar output from the console.

Yes.

2) The console output is meant for the developers, not for the users. So
it must be possible to easily locate the piece of code which produces a console output line.
This can be done by explicitely printing classname::methodname (which I like to do by
myself), by the FILE and LINE macros, and propably in other ways.

It is also for the users in case of crash, they can produce better bug reports. I agree we should include the classname::methodname.

3) distinguishing between cout and cerr is in my opinion no good idea, it would be better
to use cout only. Otherwise the logging lines get mixed up, the users have to send two files
instead of one, and similar. Historically the distinction between stdout and stderr was that
programs like ls, grep, sed, awk,... produced the program output on stdout, and stderr for
error reporting. This is done also now by the mjpegtools: Video data on stdout, messages
on stderr. This is very convieniant for piping stdout into stdin of another program.
But stellarium produces its main output not on stdout, but in a window.

I like to have the disctinction because the 2 have different colors on my console, so it helps to read quiclky the logs.

4) prefixing each log line with keyword like WARNING, ERROR, INFO,... does not hurt,
but also does not help much (at least me).

I find it quite useful, if the program crashes and display before a "ERROR blabla" the users try to understand what happened and provide better a bug reports.

5) I got a question about disabling file output in the windows version: I think in windows
files like "stdout.txt" and "stderr.txt" are produced. One user wants to put the stellarium
program and data on an USB stick, so that he can use it on computers of friends and similar.
But the flash ram on the usb stick cannot be written infinitely often, and therefore no output
files should be created if not necessary.

Yeah it's quite annoying in windows  but we have no control on it, it is SDL which pipes the two outputs to these files. When we switch to QT we can change this.

Fabien

Johannes


On 2007.05.21 17:48:50 CEST, Rob Spearman wrote:
>
> It would be easier to manage if we had some common debug methods to
> print the different types of messages.  Then it's easy to manage what
> messages go where and when.
>
> In other languages it is possible to print out the calling class/method,
> I assume this is possible in C++ somehow.
>
> Rob
>
> On Mon, 2007-05-21 at 16:35 +0100, Matthew Gates wrote:
> > In my adventures so far, I think I've probably made quite an ugly mess of
> > the console output.
> >
> > I would like to discuss some guidelines for tidying up this output.  Here
> > are my idea about it, I'd like to hear what you think.  There is a very
> > brief mention in the coding standards, but no details.
> >
> > I think we have four types of output which we might want to send to the
> > console:
> >
> > * Errors - something which is going to cause Stellarium to crash, or some
> > important operation to not function correctly.  Probably this can be
> > further divided into fatal errors and recoverable errors.  Essentially
> > stuff the user probably needs to know about.
> >
> > * Warnings - stuff which doesn't cause a crash and shouldn't significantly
> > affect usage.  Stuff like missing or corrupt nebula textures (which can be
> > simply not loaded), mal-formed records in data files which will be dropped,
> > etc.
> >
> > * Informative - for example, "loaded x star records from stars0.cat".
> > Things the user night car about, but should not be expected to know or
> > react to.
> >
> > * Debugging - output of internal state which might be useful to  figure out
> > a problem.  This is probably a sub-set of Informative - the more obscure
> > information relating to internal state.
> >
> >
> > I think Informative output should go to stdout, all others to stderr.
> >
> > I think Debugging output should not be done by default - only with some
> > command line option, e.g. -d / --debug.  We may also want the option to
> > compile without it at all to save some CPU cycles.
> >
> > Fatal errors should have some GUI-based mechanism for informing the user of
> > a crash.
> >
> > For all types except "Informative", we should print the function name, or
> > source file and line in the message, as well as what type of message it is,
> > e.g.
> >
> > ERROR StelApp::StelApp(): Failed to do something important, quitting
> > WARNING LandscapeMgr::getNameToDirMap: no landscape.ini in dir "."
> > DEBUG StelApp::StelApp(): conf file = /home/matthew/.stellarium/config.ini
> >
> > Tell me if I am being too anal about this - I can get fanatical about
> > debugging output formatting  :)  And of course, this is not a priority for
> > the next release, but a long term goal.
> >
> >
> > Matthew
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Stellarium-pubdevel mailing list
> > Stellarium-pubdevel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
> --
>   Digitalis Education Solutions, Inc.  tel 360.616.8915
>   P.O. Box 2976                        fax 360.616.8917
>   Bremerton, WA 98310                  http://digitaliseducation.com
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Stellarium-pubdevel mailing list
> Stellarium-pubdevel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Stellarium-pubdevel mailing list
Stellarium-pubdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel