-XBT_LOG_NEW_CATEGORY: nouveau canal sous "root". Rare, donc.
-XBT_LOG_NEW_SUBCATEGORY: nouveau canal dont on précise le père.
-XBT_LOG_DEFAULT_CATEGORY: indique quel est le canal par défaut dans ce fichier
-XBT_LOG_NEW_DEFAULT_CATEGORY: Crèe un canal et l'utilise par défaut
-XBT_LOG_NEW_DEFAULT_SUBCATEGORY: devine
-XBT_LOG_EXTERNAL_CATEGORY: quand tu veux utiliser par défaut un canal créé
- dans un autre fichier.
-
-Une fois que ton canal est créé, tu l'utilise avec les macros LOG, DEBUG,
-VERB, WARN, ERROR et CRITICAL. Il faut que tu donne le nombre d'arguments
-après le nom de macro. Exemple: LOG2("My name is %s %s","Martin","Quinson")
-Si tu veux préciser explicitement le canal où écrire, ajoute un C devant le
-nom de la macro. Exemple: CCRITICAL0(module, "Cannot initialize GRAS")
-
-Toutes ces macros (enfin, ce en quoi elles se réécrivent) vérifient leurs
-arguments comme printf le fait lorsqu'on compile avec gcc.
-LOG1("name: %d","toto"); donne un warning, et donc une erreur en mode
-mainteneur.
-
-Enfin, tu peux tester si un canal est ouvert à une priorité donnée (pour
-préparer plus de débug, par exemple. Dans le parseur, je fais du pretty
-printing sur ce qu'il faut parser dans ce cas).
-XBT_LOG_ISENABLED(catName, priority) Le second argument doit être une valeur
-de e_xbt_log_priority_t (log.h). Par exemple: xbt_log_priority_verbose
-
-Voila sur comment mettre des logs dans ton code. N'hesite pas à faire pleins
-de canaux différents pour des aspects différents de ton code. En
-particulier, dans les dict, j'ai un canal pour l'ajout, le retrait, le
-netoyage du code après suppression et ainsi de suite. De cette façon, je
-peux choisir qui m'interresse.
-
-
-Pour utiliser les logs, tu déjà faire, non ? Tu colle sur la ligne de
-commande un ou plusieurs arguments de la forme
- --gras-log="<réglage> [<reglage>+]" (ou sans " si t'as pas d'espace)
-chaque réglage étant de la forme:
- <canal>.thres=<priorité>
-Les différents réglages sont lus de gauche à droite.
-"root.thres=debug root.thres=critical" ferme tout, normalement.
-
-*/
+Doing so is extremely easy, thanks to the XBT_LOG_ISENABLED(category, priority).
+
+\section log_API_subcat 2.4 Using a default category (the easy interface)
+
+If \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or
+\ref XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the
+category, then the even shorter form can be used:
+
+<code>WARN3("Values are: %s and '%d'", 5, "oops");</code>
+
+Only one default category can be created per file, though multiple
+non-defaults can be created and used.
+
+\section log_API_easy 2.5 Putting all together: the easy interface
+
+First of all, each module should register its own category into the categories
+tree using \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY.
+
+Then, logging should be done with the DEBUG<n>, VERB<n>, INFO<n>, WARN<n>,
+ERROR<n> or CRITICAL<n> macro families (such as #DEBUG10, #VERB10,
+#INFO10, #WARN10, #ERROR10 and #CRITICAL10). For each group, there is at
+least 11 different macros (like DEBUG0, DEBUG1, DEBUG2, DEBUG3, DEBUG4 and
+DEBUG5, DEBUG6, DEBUG7, DEBUG8, DEBUG9, DEBUG10), only differing in the number of arguments passed along the format.
+This is because we want SimGrid itself to keep compilable on ancient
+compiler not supporting variable number of arguments to macros. But we
+should provide a macro simpler to use for the users not interested in SP3
+machines (FIXME).
+
+Under GCC, these macro check there arguments the same way than printf does. So,
+if you compile with -Wall, the folliwing code will issue a warning:
+<code>DEBUG2("Found %s (id %f)", some_string, a_double)</code>
+
+If you want to specify the category to log onto (for example because you
+have more than one category per file, add a C before the name of the log
+producing macro (ie, use #CDEBUG10, #CVERB10, #CINFO10, #CWARN10, #CERROR10 and
+#CCRITICAL10 and friends), and pass the category name as first argument.
+
+The TRACE priority is not used the same way than the other. You should use
+the #XBT_IN, XBT_IN<n> (up to #XBT_IN5), #XBT_OUT and #XBT_HERE macros
+instead.
+
+\section log_API_example 2.6 Example of use
+
+Here is a more complete example:
+
+\verbatim
+#include "xbt/log.h"
+
+/ * create a category and a default subcategory * /
+XBT_LOG_NEW_CATEGORY(VSS);
+XBT_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS);
+
+int main() {
+ / * Now set the parent's priority. (the string would typcially be a runtime option) * /
+ xbt_log_control_set("SA.thresh:3");
+
+ / * This request is enabled, because WARNING >= INFO. * /
+ CWARN2(VSS, "Low fuel level.");
+
+ / * This request is disabled, because DEBUG < INFO. * /
+ CDEBUG2(VSS, "Starting search for nearest gas station.");
+
+ / * The default category SA inherits its priority from VSS. Thus,
+ the following request is enabled because INFO >= INFO. * /
+ INFO1("Located nearest gas station.");
+
+ / * This request is disabled, because DEBUG < INFO. * /
+ DEBUG1("Exiting gas station search");
+}
+\endverbatim
+
+Another example can be found in the relevant part of the GRAS tutorial:
+\ref GRAS_tut_tour_logs.
+
+\section log_user 3. User interface
+
+\section log_use_conf 3.1 Configuration
+
+Although rarely done, it is possible to configure the logs during
+program initialization by invoking the xbt_log_control_set() method
+manually. A more conventionnal way is to use the --log command line
+argument. xbt_init() (called by MSG_init(), gras_init() and friends)
+checks and deals properly with such arguments.
+
+The following command line arguments exist, but are deprecated and
+may disapear in the future: --xbt-log, --gras-log, --msg-log and
+--surf-log.
+
+\subsection log_use_conf_thres 3.1.1 Thresold configuration
+
+The most common setting is to control which logging event will get
+displayed by setting a threshold to each category through the
+<tt>thres</tt> keyword.
+
+For example, \verbatim --log=root.thres:debug\endverbatim will make
+SimGrid <b>extremely</b> verbose while \verbatim
+--log=root.thres:critical\endverbatim should shut it almost
+completely off.
+
+\subsection log_use_conf_multi 3.1.2 Passing several settings
+
+You can provide several of those arguments to change the setting of several
+categories, they will be applied from left to right. So,
+\verbatim --log="root.thres:debug root.thres:critical"\endverbatim should
+disable almost any logging.
+
+Note that the quotes on above line are mandatory because there is a space in
+the argument, so we are protecting ourselves from the shell, not from SimGrid.
+We could also reach the same effect with this:
+\verbatim --log=root.thres:debug --log=root.thres:critical\endverbatim
+
+\subsection log_use_conf_fmt 3.1.3 Format configuration
+
+As with SimGrid 3.3, it is possible to control the format of log
+messages. This is done through the <tt>fmt</tt> keyword. For example,
+\verbatim --log=root.fmt:%m\endverbatim reduces the output to the
+user-message only, removing any decoration such as the date, or the
+process ID, everything.
+
+Here are the existing format directives:
+
+ - %%: the % char
+ - %%n: platform-dependant line separator (LOG4J compliant)
+ - %%e: plain old space (SimGrid extension)
+
+ - %%m: user-provided message
+
+ - %%c: Category name (LOG4J compliant)
+ - %%p: Priority name (LOG4J compliant)
+
+ - %%h: Hostname (SimGrid extension)
+ - %%P: Process name (SimGrid extension)
+ - %%t: Thread "name" (LOG4J compliant -- actually the address of the thread in memory)
+ - %%i: Process PID (SimGrid extension -- this is a 'i' as in 'i'dea)
+
+ - %%F: file name where the log event was raised (LOG4J compliant)
+ - %%l: location where the log event was raised (LOG4J compliant, like '%%F:%%L' -- this is a l as in 'l'etter)
+ - %%L: line number where the log event was raised (LOG4J compliant)
+ - %%M: function name (LOG4J compliant -- called method name here of course).
+ Defined only when using gcc because there is no __FUNCTION__ elsewhere.
+
+ - %%b: full backtrace (Called %%throwable in LOG4J).
+ Defined only when using the GNU libc because backtrace() is not defined
+ elsewhere.
+ - %%B: short backtrace (only the first line of the %%b).
+ Called %%throwable{short} in LOG4J; defined where %%b is.
+
+ - %%d: date (UNIX-like epoch)
+ - %%r: application age (time elapsed since the beginning of the application)
+
+
+If you want to mimick the simple layout with the format one, you would use this
+format: '[%%h:%%i:(%%I) %%r] %%l: [%%c/%%p] %%m%%n'. This is not completely correct
+because the simple layout do not display the message location for messages at
+priority INFO (thus, the fmt is '[%%h:%%i:(%%I) %%r] %%l: [%%c/%%p] %%m%%n' in this
+case). Moreover, if there is no process name (ie, messages comming from the
+library itself, or test programs doing strange things) do not display the
+process identity (thus, fmt is '[%%r] %%l: [%%c/%%p] %%m%%n' in that case, and '[%%r]
+[%%c/%%p] %%m%%n' if they are at priority INFO).
+
+For now, there is only one format modifyier: the precision field. You
+can for example specify %.4r to get the application age with 4
+numbers after the radix. Another limitation is that you cannot set
+specific layouts to the several priorities.
+
+\subsection log_use_conf_add 3.1.4 Category additivity
+
+The <tt>add</tt> keyword allows to specify the additivity of a
+category (see \ref log_in_app). This is rarely useful since you
+cannot specify an alternative appender. Anyway, '0', '1', 'no',
+'yes', 'on' and 'off' are all valid values, with 'yes' as default.
+
+\section log_use_misc 3.2 Misc and Caveats
+
+ - Do not use any of the macros that start with '_'.
+ - Log4J has a 'rolling file appender' which you can select with a run-time
+ option and specify the max file size. This would be a nice default for
+ non-kernel applications.
+ - Careful, category names are global variables.
+
+\section log_internals 4. Internal considerations
+
+This module is a mess of macro black magic, and when it goes wrong,
+SimGrid studently loose its ability to explain its problems. When
+messing around this module, I often find useful to define
+XBT_LOG_MAYDAY (which turns it back to good old printf) for the time
+of finding what's going wrong. But things are quite verbose when
+everything is enabled...
+
+\section log_in_perf 4.1 Performance
+
+Except for the first invocation of a given category, a disabled logging request
+requires an a single comparison of a static variable to a constant.
+
+There is also compile time constant, \ref XBT_LOG_STATIC_THRESHOLD, which
+causes all logging requests with a lower priority to be optimized to 0 cost
+by the compiler. By setting it to gras_log_priority_infinite, all logging
+requests are statically disabled and cost nothing. Released executables
+<i>might</i> be compiled with (note that it will prevent users to debug their problems)
+\verbatim-DXBT_LOG_STATIC_THRESHOLD=gras_log_priority_infinite\endverbatim
+
+Compiling with the \verbatim-DNLOG\endverbatim option disables all logging
+requests at compilation time while the \verbatim-DNDEBUG\endverbatim disables
+the requests of priority below INFO.
+
+\todo Logging performance *may* be improved further by improving the message
+propagation from appender to appender in the category tree.
+
+\section log_in_app 4.2 Appenders
+
+Each category has an optional appender. An appender is a pointer to a
+structure which starts with a pointer to a doAppend() function. DoAppend()
+prints a message to a log.
+
+When a category is passed a message by one of the logging macros, the
+category performs the following actions:
+
+ - if the category has an appender, the message is passed to the
+ appender's doAppend() function,
+ - if additivity is true for the category (which is the case by
+ default, and can be controlled by xbt_log_additivity_set()), the
+ message is passed to the category's parent.
+
+By default, only the root category have an appender, and any other category has
+its additivity set to true. This causes all messages to be logged by the root
+category's appender.
+
+The default appender function currently prints to stderr, and no other one
+exist, even if more would be needed, like the one able to send the logs to a
+remote dedicated server, or other ones offering different output formats.
+This is on our TODO list for quite a while now, but your help would be
+welcome here, too.
+
+
+*//*'*/
+
+\f
+xbt_log_appender_t xbt_log_default_appender = NULL; /* set in log_init */
+xbt_log_layout_t xbt_log_default_layout = NULL; /* set in log_init */
+int _log_usable = 0;