Bolt 1.3
+Bolt 1.4
hunk ./doc/bolt.html 42
-Released under the LGPL v3August 14, 2012 |
+Released under the LGPL v3October 26, 2012
hunk ./doc/bolt.html 65
-3.6 Output
-3.7 Event dispatch
+3.6 Mode
+3.7 Output
+3.8 Event dispatch
hunk ./doc/bolt.html 69
-Chapter 4 Using Bolt
+Chapter 4 Using Bolt
hunk ./doc/bolt.html 71
-4.1 Linking with the library
-4.2 Adding log statements
+4.1 Linking with the library
+4.2 Adding log statements
hunk ./doc/bolt.html 74
-4.2.1 Explicit logging
-4.2.2 Implicit logging
+4.2.1 Explicit logging
+4.2.2 Implicit logging
hunk ./doc/bolt.html 77
-4.3 Configuring log
+4.3 Configuring log
hunk ./doc/bolt.html 79
-4.3.1 Predefined filters
-4.3.2 Predefined layouts
-4.3.3 Predefined outputs
+4.3.1 Predefined filters
+4.3.2 Predefined layouts
+4.3.3 Predefined outputs
hunk ./doc/bolt.html 84
-Chapter 5 Reviewing generated log
-Chapter 6 Daikon support
+Chapter 5 Reviewing generated log
+Chapter 6 Daikon support
hunk ./doc/bolt.html 87
-6.1 Overview
-6.2 Configuration
-6.3 Instrumentation
-6.4 Review
+6.1 Overview
+6.2 Configuration
+6.3 Instrumentation
+6.4 Review
hunk ./doc/bolt.html 92
-Chapter 7 Pajé support
+Chapter 7 Pajé support
hunk ./doc/bolt.html 94
-7.1 Overview
-7.2 Configuration
-7.3 Instrumentation
-7.4 Review
+7.1 Overview
+7.2 Configuration
+7.3 Instrumentation
+
+7.4 Review
hunk ./doc/bolt.html 109
-Chapter 8 Complete example
-Chapter 9 Customizing Bolt
+Chapter 8 Complete example
+Chapter 9 Customizing Bolt
hunk ./doc/bolt.html 112
-9.1 Defining a custom filter
-9.2 Defining a custom layout
-9.3 Defining a custom output
-9.4 Using custom elements
+9.1 Defining a custom filter
+9.2 Defining a custom layout
+9.3 Defining a custom output
+9.4 Compiling custom elements
+9.5 Using custom elements
hunk ./doc/bolt.html 151
-The configuration of Argot is done by executing ./configure. One can specify elements if they are not correctly inferred by the configure script; the following switches are available:
+The configuration of Bolt is done by executing ./configure. One can specify elements if they are not correctly inferred by the configure script; the following switches are available:
hunk ./doc/bolt.html 197
-A filter is basically a predicate over events, allowing to determine whether an event should be recorded by a condition on any element of the events.Each logger has an associated filter, ensuring that only the events satisfying the filter will be recorded.
+A filter is basically a predicate over events, allowing to determine whether an event should be recorded by a condition on any element of the events. Each logger has an associated filter, ensuring that only the events satisfying the filter will be recorded.
hunk ./doc/bolt.html 199
-Each logger has an associated layout that is responsible for the conversion of events into bare string that can then be easily manipulated.
-3.6 Output
-Each logger has an associated output that defines where event are actually recorded. An output is thus responsible for the storage of events, once they have been converted into string by a layout. the most simple output is the file, and in this case, safety commands that two loggers should not have the same destination.
-3.7 Event dispatch
+Each logger has an associated layout that is responsible for the conversion of events into bare strings that can then be easily manipulated.
+
+Each logger has an associated mode that is reponsible for sending data to the output. A mode allows to buffer data, in order to mitigate performances issues related to logging.
+3.7 Output
+Each logger has an associated output that defines where event are actually recorded. An output is thus responsible for the storage of events, once they have been converted into strings by a layout. The most simple output is the file, and in this case, safety commands that two loggers should not have the same destination.
+3.8 Event dispatch
hunk ./doc/bolt.html 215
-
-4.1 Linking with the library
+
+4.1 Linking with the library
hunk ./doc/bolt.html 224
- 4.2 Adding log statements
+ 4.2 Adding log statements
hunk ./doc/bolt.html 228
- 4.2.1 Explicit logging
+ 4.2.1 Explicit logging
hunk ./doc/bolt.html 248
- 4.2.2 Implicit logging
+ 4.2.2 Implicit logging
hunk ./doc/bolt.html 283
- 4.3 Configuring log
+ 4.3 Configuring log
hunk ./doc/bolt.html 292
+ a Mode.t parameter giving the mode of the logger;
hunk ./doc/bolt.html 318
-| property_value ::= ident | integer | string |
+| property_value ::= expr | integer | float | string |
+| expr ::= ident | ident && ident | ident || ident |
hunk ./doc/bolt.html 324
-In both format, each section defines a logger whose name is the section name. The following properties are used to customize the logger:
+In both formats, each section defines a logger whose name is the section name. The following properties are used to customize the logger:
hunk ./doc/bolt.html 329
+mode defines the mode of the logger;
hunk ./doc/bolt.html 335
-The level can have one of the following values: TRACE, DEBUG, INFO, WARN, ERROR, FATAL. The possible values for the other properties are discussed in the following sections.Code sample 4.3 and ?? exemplify typical configuration files, respectively in old and new format. It defines three loggers (with names “”, “Pack.Main”, and “Pack.Aux”). When executed, the application will produce three files “bymodule.result”, “bymodule1.result”, and “bymodule2.result”: the first file will contain the log information for the whole application while the other ones will contain respectively the log information associated with the “Pack.Main” and “Pack.Aux” loggers.
+The level can have one of the following values: TRACE, DEBUG, INFO, WARN, ERROR, FATAL. The possible values for the other properties are discussed in the following sections.
+
+The mode can have one of the following values:
+ -
+direct, meaning that data is sent to output as soon at it is available;
+
- memory, meaning that data is buffered and sent to output only at program termination;
+
- retained, meaning that data is buffered and periodically sent to output.
+
+When retained mode is used, the retention parameter defines when data is actually sent to output. The string value can have one of the following form:
+ -
+an integer followed by the letter ’e’ (e. g. "10e") means that events are delivered when n events have been accumulated;
+
- an integer followed by the letter ’b’ (e. g. "10b") means that events are delivered when a string representation of n bytes has been accumulated;
+
- an integer followed by the letter ’s’ (e. g. "10s") means that events are delivered every n seconds.
+
+
+Code sample 4.3 and 4.4 exemplify typical configuration files, respectively in old and new format. They define three loggers (with names “”, “Pack.Main”, and “Pack.Aux”). When executed, the application will produce three files “bymodule.result”, “bymodule1.result”, and “bymodule2.result”: the first file will contain the log information for the whole application while the other ones will contain respectively the log information associated with the “Pack.Main” and “Pack.Aux” loggers.
hunk ./doc/bolt.html 358
+mode=direct
hunk ./doc/bolt.html 366
+mode=direct
hunk ./doc/bolt.html 374
+mode=direct
hunk ./doc/bolt.html 379
- | Code sample 4.4: Example of configuration file (new format). |
+| Code sample 4.4: Example of configuration file (new format). |
hunk ./doc/bolt.html 386
+ mode = direct;
hunk ./doc/bolt.html 395
+ mode = direct;
hunk ./doc/bolt.html 404
+ mode = direct;
hunk ./doc/bolt.html 409
-4.3.1 Predefined filters
+ 4.3.1 Predefined filters
hunk ./doc/bolt.html 443
- 4.3.2 Predefined layouts
+ 4.3.2 Predefined layouts
hunk ./doc/bolt.html 446
-simple with format: LEVEL - MESSAGE;
+minimal with format: MESSAGE;
+ simple with format: LEVEL - MESSAGE;
hunk ./doc/bolt.html 450
-daikon_decls, and daikon_trace that respectively follow Daikon2 declaration (i.e. program points, and associated variable types) and trace format (i.e. actual variable values for the various program points visits) – see chapter 6 for more information;;
+daikon_decls, and daikon_trace that respectively follow Daikon2 declaration (i.e. program points, and associated variable types) and trace format (i.e. actual variable values for the various program points visits) – see chapter 6 for more information;
hunk ./doc/bolt.html 486
-properties property list of event (formatted as ["[k1: v1; ...; kn: vn]"]);
+properties property list of event (formatted as "[k1: v1; ...; kn: vn]");
hunk ./doc/bolt.html 490
-4.3.3 Predefined outputs
-There are three predefined outputs, namely void, growlnotify3, and file. The void output discards all data. The file output writes data to a bare file, the name property (or the string value when using Bolt.Logger.register) defines the path of the file to be used4, and the rotate property (or the float option value when using Bolt.Logger.register) gives the rates in seconds at which files will be rotated. It is also possible to use the signal property (set to one one the following values: SIGHUP, SIGUSR1, SIGUSR2) in order to request rotation upon signal reception.
+ 4.3.3 Predefined outputs
+There are five predefined outputs, namely void, growlnotify3, bell, say, and file.
+
+The void output discards all data.
+
+The growlnotify output sends the data to the Growl application through the growlnotify command-line utility.
+
+The bell output discards all data, and simply prints a “bell” character on the standard output.
+
+The say output uses the MacOS X command-line utility say to invoke the text-to-speech engine in order to actually vocalize the data.
+ The file output writes data to a bare file, the name property (or the string value when using Bolt.Logger.register) defines the path of the file to be used4, and the rotate property (or the float option value when using Bolt.Logger.register) gives the rate in seconds at which files will be rotated. It is also possible to use the signal property (set to one one the following values: SIGHUP, SIGUSR1, SIGUSR2) in order to request rotation upon signal reception.
hunk ./doc/bolt.html 511
-1
|