- \ref GRAS_tut_tour_logs_config
- \ref GRAS_tut_tour_logs_config_prio
- \ref GRAS_tut_tour_logs_config_layout
-
+
<hr>
\section GRAS_tut_tour_logs_intro Introduction
the user a fine control at run time of what gets displayed and what don't.
For that, <i>log event</i> are produced into <i>log channels</i> at a given
<i>log priority</i>. Then, you can select the minimal priority an event
-should have on a given channel to get displayed.
+should have on a given channel to get displayed.
Then, to keep things managable even when the number of channels increase,
the channels form a tree and properties get inherited from parent channel to
their respective subchannels too). Finally, channels are not just open or
closed, but filter messages below a given priority (as we said). The
priorities are defined by type #e_xbt_log_priority_t.
-
+
That is all you really need to know about the logs before diving into
practice. If you want more information on that topic, refer to the \ref
XBT_log section, which contains much more information than this page.
\until XBT_LOG
Then, we change any call to fprintf to one of the logging macros. There is a
-plenty of them, called <priority><nb args>, such as #DEBUG10,
-which produces a debuging log event onto the default category. You have to
-declare the name of arguments as part of the macro name for compatibility
-with old compilers not accepting variable number of arguments. Here is a
-partial list of the existing macros: #DEBUG10, #VERB10, #INFO10, #WARN10,
-#ERROR10 and #CRITICAL10. For each priority, this is the biggest macro (and
-the others are not documented for sake of clarity in the relevant document).
-Ie, VERB20 does not exist, but VERB0 does exist. I may add more if someone
-wants more, but that should be enough for most purposes.
+plenty of them, called <priority><nb args>, such as #XBT_DEBUG,
+which produces a debuging log event onto the default category. Here is a
+list of the existing macros: #XBT_DEBUG, #XBT_VERB, #XBT_INFO, #XBT_WARN,
+#XBT_ERROR and #XBT_CRITICAL.
Note also that there is no need to add a '\\n' at the end of your format
line, it gets automatically added.
\section GRAS_tut_tour_logs_recap Recapping everything together
Once we changed any fprintf of our code to some of these macros, the program
-may read:
+may read:
\include 06-logs.c
And the output now looks better:
\section GRAS_tut_tour_logs_config The user side: configuring logs at run time
-\section GRAS_tut_tour_logs_config_prio Choosing what gets displayed
+\subsection GRAS_tut_tour_logs_config_prio Choosing what gets displayed
Once we changed our program to use proper logging, it is naturally possible
to choose at run time what we want to see. For example, if we want more
\include 06-logs.output.verbose
On the contrary, if we want to reduce the amount of logging, we may want to
-do pass <tt>--log=test.thres:error</tt>:
+do pass <tt>--log=test.thres:error</tt>:
-\section GRAS_tut_tour_logs_config_layout Choosing how things get displayed
+\subsection GRAS_tut_tour_logs_config_layout Choosing how things get displayed
As with SimGrid 3.3, it is also possible to change how each and every
message get displayed from the command line without even recompiling
