.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.42) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "Datum 3pm" .TH Datum 3pm "2022-06-30" "perl v5.34.0" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" Carp::Datum \- Debugging And Tracing Ultimate Module .SH "SYNOPSIS" .IX Header "SYNOPSIS" .Vb 2 \& # In modules \& use Carp::Datum; \& \& # Programming by contract \& sub routine { \& DFEATURE my $f_, "optional message"; # $f_ is a lexical lvalue here \& my ($a, $b) = @_; \& DREQUIRE $a > $b, "a > b"; \& $a += 1; $b += 1; \& DASSERT $a > $b, "ordering a > b preserved"; \& my $result = $b \- $a; \& DENSURE $result < 0; \& return DVAL $result; \& } \& \& # Tracing \& DTRACE "this is a debug message"; \& DTRACE TRC_NOTICE, "note: a = ", $a, " is positive"; \& DTRACE {\-level => TRC_NOTICE, \-marker => "!!"}, "note with marker"; \& \& # Returning \& return DVAL $scalar; # single value \& return DARY @list; # list of values \& \& # In application\*(Aqs main \& use Carp::Datum qw(:all on); # turns Datum "on" or "off" \& \& DLOAD_CONFIG(\-file => "debug.cf", \-config => "config string"); .Ve .SH "DESCRIPTION" .IX Header "DESCRIPTION" The \f(CW\*(C`Carp::Datum\*(C'\fR module brings powerful debugging and tracing features to development code: automatic flow tracing, returned value tracing, assertions, and debugging traces. Its various functions may be customized dynamically (i.e. at run time) via a configuration language allowing selective activation on a routine, file, or object type basis. See Carp::Datum::Cfg for configuration defails. .PP \&\f(CW\*(C`Carp::Datum\*(C'\fR traces are implemented on top of \f(CW\*(C`Log::Agent\*(C'\fR and go to its debugging channel. This lets the application have full control of the final destination of the debugging information (logfile, syslog, etc...). .PP \&\f(CW\*(C`Carp::Datum\*(C'\fR can be globally turned on or off by the application. It is off by default, which means no control flow tracing (routine entry and exit), and no returned value tracing. However, assertions are still fully monitored, and the \f(CW\*(C`DTRACE\*(C'\fR calls are redirected to \f(CW\*(C`Log::Agent\*(C'\fR. .PP The C version of \f(CW\*(C`Carp::Datum\*(C'\fR is implemented with macros, which may be redefined to nothing to remove all assertions in the released code. The Perl version cannot be handled that way, but comes with a \f(CW\*(C`Carp::Datum::Strip\*(C'\fR module that will \fBlexically\fR remove all the assertions, leaving only \f(CW\*(C`DTRACE\*(C'\fR calls. Modules using \f(CW\*(C`Carp::Datum\*(C'\fR can make use of \f(CW\*(C`Carp::Datum::MakeMaker\*(C'\fR in their Makefile.PL to request stripping at build time. See Carp::Datum::MakeMaker for instructions. .PP Here is a small example showing what traces look like, and what happens by default on assertion failure. Since \f(CW\*(C`Log::Agent\*(C'\fR is not being customized, the debugging channel is \s-1STDERR.\s0 In real life, one would probably customize Log::Agent with a file driver, and redirect the debug channel to a file separate from both \s-1STDOUT\s0 and \s-1STDERR.\s0 .PP First, the script, with line number: .PP .Vb 10 \& 1 #!/usr/bin/perl \& 2 \& 3 use Carp::Datum qw(:all on); \& 4 \& 5 DFEATURE my $f_; \& 6 \& 7 show_inv(2, 0.5, 0); \& 8 \& 9 sub show_inv { \& 10 DFEATURE my $f_; \& 11 foreach (@_) { \& 12 print "Inverse of $_ is ", inv($_), "\en"; \& 13 } \& 14 return DVOID; \& 15 } \& 16 \& 17 sub inv { \& 18 DFEATURE my $f_; \& 19 my ($x) = @_; \& 20 DREQUIRE $x != 0, "x=$x not null"; \& 21 return DVAL 1 / $x; \& 22 } \& 23 .Ve .PP What goes to \s-1STDOUT:\s0 .PP .Vb 3 \& Inverse of 2 is 0.5 \& Inverse of 0.5 is 2 \& FATAL: PANIC: pre\-condition FAILED: x=0 not null ($x != 0) [./demo:20] .Ve .PP The debugging output on \s-1STDERR:\s0 .PP .Vb 10 \& +\-> global [./demo:5] \& | +\-> main::show_inv(2, 0.5, 0) from global at ./demo:7 [./demo:10] \& | | +\-> main::inv(2) from main::show_inv() at ./demo:12 [./demo:18] \& | | | Returning: (0.5) [./demo:21] \& | | +\-< main::inv(2) from main::show_inv() at ./demo:12 \& | | +\-> main::inv(0.5) from main::show_inv() at ./demo:12 [./demo:18] \& | | | Returning: (2) [./demo:21] \& | | +\-< main::inv(0.5) from main::show_inv() at ./demo:12 \& | | +\-> main::inv(0) from main::show_inv() at ./demo:12 [./demo:18] \& !! | | | pre\-condition FAILED: x=0 not null ($x != 0) [./demo:20] \& !! | | | main::inv(0) called at ./demo line 12 \& !! | | | main::show_inv(2, 0.5, 0) called at ./demo line 7 \& ** | | | FATAL: PANIC: pre\-condition FAILED: x=0 not null ($x != 0) [./demo:20] \& | | +\-< main::inv(0) from main::show_inv() at ./demo:12 \& | +\-< main::show_inv(2, 0.5, 0) from global at ./demo:7 \& +\-< global .Ve .PP The last three lines were manually re-ordered for this manpage: because of the pre-condition failure, Perl enters its global object destruction routine, and the destruction order of the lexicals is not right. The \f(CW$f_\fR in \fBshow_inv()\fR is destroyed before the one in \fBinv()\fR, resulting in the inversion. To better please the eye, it has been fixed. And the \s-1PANIC\s0 is emitted when the pre-condition failure is detected, but it would have messed up the trace example. .PP Note that the stack dump is prefixed with the \*(L"!!\*(R" token, and the fatal error is tagged with \*(L"**\*(R". This is a visual aid only, to quickly locate troubles in logfiles by catching the eye. .PP Routine entry and exit are tagged, returned values and parameters are shown, and the immediate caller of each routine is also traced. The final tags \f(CW\*(C`from global at ./demo:7 [./demo:10]\*(C'\fR refer to the file name (here the script used was called \*(L"demo\*(R") and the line number where the call to the \f(CW\*(C`Carp::Datum\*(C'\fR routine is made: here the \&\f(CW\*(C`DFEATURE\*(C'\fR at line 10. It also indicates the caller origin: here, the call is made at line 7 of file \f(CW\*(C`demo\*(C'\fR. .PP The special name \*(L"global\*(R" (without trailing () marker) is used to indicate that the caller is the main script, i.e. there is no calling routine. .PP Returned values in \fBinv()\fR are traced as \*(L"(0.5)\*(R" and \*(L"(2)\*(R", and not as \*(L"0.5\*(R" and \*(L"2\*(R" as one would expect, because the routine was called in non-scalar context (within a print statement). .SH "PROGRAMMING BY CONTRACT" .IX Header "PROGRAMMING BY CONTRACT" .SS "Introduction" .IX Subsection "Introduction" The Programming by Contract paradigm was introduced by Bertrand Meyer in his \fIObject Oriented Software Construction\fR book, and later implemented natively in the Eiffel language. It is very simple, yet extremely powerful. .PP Each feature (routine) of a program is viewed externally as a supplier for some service. For instance, the \fBsqrt()\fR routine computes the square root of any positive number. The computation could be verified, but \&\fBsqrt()\fR probably provides an efficient algorithm for that, and it has already been written and validated. .PP However, \fBsqrt()\fR is only defined for positive numbers. Giving a negative number to it is not correct. The old way (i.e. in the old days before Programming by Contract was formalized), people implemented that restriction by testing the argument \fIx\fR of \fBsqrt()\fR, and doing so in the routine itself to factorize code. Then, on error, \fBsqrt()\fR would return \-1 for instance (which cannot be a valid square root for a real number), and the desired quantity otherwise. The caller had then to check the returned value to determine whether an error had occurred. Here it is easy, but in languages where no out-of-band value such as Perl's \f(CW\*(C`undef\*(C'\fR are implemented, it can be quite difficult to both report an error and return a result. .PP With Programming by Contract, the logic is reversed, and the code is greatly simplified: .IP "\(bu" 4 It is up to the caller to always supply a positive value to \fBsqrt()\fR, i.e. to check the value first. .IP "\(bu" 4 In return, \fBsqrt()\fR promises to always return the square root of its argument. .PP What are the benefits of such a gentlemen's agreement? The code of the \fBsqrt()\fR routine is much simpler (meaning fewer bugs) because it does not have to bother with handling the case of negative arguments, since the caller promised to never call with such invalid values. And the code of the caller is at worst as complex as before (one test to check that the argument is positive, against a check for an error code) and at best less complex: if it is known that the value is positive, it doesn't even have to be checked, for instance if it is the result of an \fBabs()\fR call. .PP But if \fBsqrt()\fR is called with a negative argument, and there's no explicit test in \fBsqrt()\fR to trap the case, what happens if \fBsqrt()\fR is given a negative value, despite a promise never to do so? Well, it's a bug, and it's a bug in the caller, not in the \fBsqrt()\fR routine. .PP To find those bugs, one usually monitors the assertions (pre\- and post-conditions, plus any other assertion in the code, which is both a post-condition for the code above and a pre-condition for the code below, at the same time) during testing. When the product is released, assertions are no longer checked. .SS "Formalism" .IX Subsection "Formalism" Each routine is equipped with a set of pre-conditions and post-conditions. A routine \fIr\fR is therefore defined as: .PP .Vb 4 \& r(x) \& pre\-condition \& body \& post\-condition .Ve .PP The pre\- and post-conditions are expressions involving the parameters of r(), here only \fIx\fR, and, for the post-condition, the returned value of r() as well. Conditions satisfying this property are made visible to the clients, and become the routine's \fIcontract\fR, which can be written as: .IP "\(bu" 4 You, the caller, promise to always call me with my pre-condition satisfied. Failure to do so will be a bug in your code. .IP "\(bu" 4 I promise you, the caller, that my implementation will then perform correctly and that my post-condition will be satisfied. Failure to do so will be a bug in my code. .PP In object-oriented programming, pre\- and post-conditions can also use internal attributes of the object, but then become debugging checks that everything happens correctly (in the proper state, the proper order, etc...) and cannot be part of the contract (for external users of the class) since clients cannot check that the pre-condition is true, because it will not have access to the internal attributes. .PP Furthermore, in object-oriented programming, a redefined feature must \fIweaken\fR the pre-condition of its parent feature and \fIstrengthen\fR its post-condition. It can also keep them as-is. To fully understand why, it's best to read Meyer. Intuitively, it's easy to understand why the pre-condition cannot be strengthened, nor why the post-condition cannot be weakened: because of dynamic binding, a caller of r() only has the static type of the object, not its dynamic type. Therefore, it cannot know in advance which of the routines will be called amongst the inheritance tree. .SS "Common Pitfalls" .IX Subsection "Common Pitfalls" .IP "\(bu" 4 Do not write both a pre-condition and a test with the same expression. .IP "\(bu" 4 Never write a pre-condition when trying to validate user input! .IP "\(bu" 4 Never write a test on an argument when failure means an error, use a pre-condition. .Sp If a pre-condition is so important that it needs to always be monitored, even within the released product, then \f(CW\*(C`Carp::Datum\*(C'\fR provides \f(CW\*(C`VERIFY\*(C'\fR, a pre-condition that will always be checked (i.e. never stripped by \f(CW\*(C`Carp::Datum::Strip\*(C'\fR). It can be used to protect the external interface of a module against abuse. .SS "Implementation" .IX Subsection "Implementation" With Carp::Datum, pre-conditions can be given using \f(CW\*(C`DREQUIRE\*(C'\fR or \f(CW\*(C`VERIFY\*(C'\fR. Assertions are written with \f(CW\*(C`DASSERT\*(C'\fR and post-conditions given by \f(CW\*(C`DENSURE\*(C'\fR. .PP Although all assertions could be expressed with only \f(CW\*(C`DASSERT\*(C'\fR, stating whether it's a pre-condition with \f(CW\*(C`DREQUIRE\*(C'\fR also has a commentary value for the reader. Moreover, one day, there might be an automatic tool to extract the pre\- and post-conditions of all the routines for documentation purposes, and if all assertions are called \f(CW\*(C`DASSERT\*(C'\fR, the tool will have a hard time figuring out which is what. .PP Moreover, remember that a pre-condition failure \fIalways\fR means a bug in the caller, whilst other assertion failures means a bug near the place of failure. If only for that, it's worth making the distinction. .SH "INTERFACE" .IX Header "INTERFACE" .SS "Control Flow" .IX Subsection "Control Flow" .ie n .IP "\s-1DFEATURE\s0 my $f_, \fIoptional comment\fR" 4 .el .IP "\s-1DFEATURE\s0 my \f(CW$f_\fR, \fIoptional comment\fR" 4 .IX Item "DFEATURE my $f_, optional comment" This statement marks the very top of any routine. Do not omit the \f(CW\*(C`my\*(C'\fR which is very important to ensure that what is going to be stored in the lexically scoped \f(CW$f_\fR variable will be destroyed when the routine ends. Any name can be used for that lexical, but \f(CW$f_\fR is recommended because it is both unlikely to conflict with any real variable and short. .Sp The \fIoptional comment\fR part will be printed in the logs at routine entry time, and can be used to flag object constructors, for instance, for easier grep'ing in the logs afterwards. .IP "return \s-1DVOID\s0" 4 .IX Item "return DVOID" This can be used in place of an ordinary \f(CW\*(C`return\*(C'\fR from a routine. It allows tracing of the return statement. .IP "return \s-1DVAL\s0 \fIscalar\fR" 4 .IX Item "return DVAL scalar" Use this form when returning something in scalar context. Do not put any parentheses around \fIscalar\fR, or it will be incorrectly stripped by \f(CW\*(C`Carp::Datum::Strip\*(C'\fR. Examples: .Sp .Vb 3 \& return DVAL 5; # OK \& return DVAL ($a == 1) ? 2 : 4; # WRONG (has parenthesis) \& return DVAL (1, 2, 4); # WRONG (and will return 4) \& \& my $x = ($a == 1) ? 2 : 4; \& return DVAL $x; # OK \& \& return DVAL &foo(); # Will be traced as array context .Ve .Sp Using \s-1DVAL\s0 allows tracing of the returned value. .IP "return \s-1DARY\s0 (\fIlist\fR)" 4 .IX Item "return DARY (list)" Use this form when returning something in list context. Using \s-1DARY\s0 allows tracing of the returned values. .Sp .Vb 1 \& return DARY @x; .Ve .Sp If a routine returns something different depending on its calling context, then write: .Sp .Vb 2 \& return DARY @x if wantarray; \& return DVAL $x; .Ve .Sp Be very careful with that, otherwise the program will behave differently when the \f(CW\*(C`DARY\*(C'\fR and \f(CW\*(C`DVAL\*(C'\fR tokens are stripped by \f(CW\*(C`Carp::Datum::Strip\*(C'\fR, thereby raising subtle bugs. .SS "Programming by Contract" .IX Subsection "Programming by Contract" .ie n .IP """DREQUIRE"" \fIexpr\fR, \fItag\fR" 4 .el .IP "\f(CWDREQUIRE\fR \fIexpr\fR, \fItag\fR" 4 .IX Item "DREQUIRE expr, tag" Specify a pre-condition \fIexpr\fR, along with a \fItag\fR that will be printed whenever the pre-condition fails, i.e. when \fIexpr\fR evaluates to false. The \fItag\fR string may be used to dump faulty values, for instance: .Sp .Vb 1 \& DREQUIRE $x > 0, "x = $x positive"; .Ve .Sp The \fItag\fR is optional and may be left off. .ie n .IP """VERIFY"" \fIexpr\fR, \fItag\fR" 4 .el .IP "\f(CWVERIFY\fR \fIexpr\fR, \fItag\fR" 4 .IX Item "VERIFY expr, tag" This is really the same as \f(CW\*(C`DREQUIRE\*(C'\fR, except that it will not be stripped by \f(CW\*(C`Carp::Datum::Strip\*(C'\fR and that it will always be monitored and cause a fatal error, whatever dynamic configuration is setup. .ie n .IP """DENSURE"" \fIexpr\fR, \fItag\fR" 4 .el .IP "\f(CWDENSURE\fR \fIexpr\fR, \fItag\fR" 4 .IX Item "DENSURE expr, tag" Specify a post-condition \fIexpr\fR, along with an optional \fItag\fR that will be printed whenever the post-condition fails, i.e. when \fIexpr\fR evaluates to false. .ie n .IP """DASSERT"" \fIexpr\fR, \fItag\fR" 4 .el .IP "\f(CWDASSERT\fR \fIexpr\fR, \fItag\fR" 4 .IX Item "DASSERT expr, tag" Specify an assertion \fIexpr\fR, and an optional \fItag\fR printed when \fIexpr\fR evaluates to false. .SS "Tracing" .IX Subsection "Tracing" Tracing is ensured by the \f(CW\*(C`DTRACE\*(C'\fR routine, which is never stripped. When \&\f(CW\*(C`Carp::Datum\*(C'\fR is off, traces are redirected to \f(CW\*(C`Log::Agent\*(C'\fR (then channel depends on the level of the trace). .PP The following forms can be used, from the simpler to the more complex: .PP .Vb 3 \& DTRACE "the variable x+1 is ", $x + 1, " and y is $y"; \& DTRACE TRC_WARNING, "a warning message"; \& DTRACE { \-level => TRC_CRITICAL, \-marker => "##" }, "very critical"; .Ve .PP The first call emits a trace at the \f(CW\*(C`TRC_DEBUG\*(C'\fR level, by default. The second call emits a warning at the \f(CW\*(C`TRC_WARNING\*(C'\fR level, and the last call emits a \f(CW\*(C`TRC_CRITICAL\*(C'\fR message prefixed with a marker. .PP Markers are 2\-char strings emitted in the very first columns of the debugging output, and can be used to put emphasis on specifice messages. Internally, \f(CW\*(C`Carp::Datum\*(C'\fR and \f(CW\*(C`Log::Agent\*(C'\fR use the following markers: .PP .Vb 3 \& !! assertion failure and stack trace \& ** critical errors, fatal if not trapped by eval {} \& >> a message emitted via a Log::Agent routine, not DTRACE .Ve .PP The table below lists the available \f(CW\*(C`TRC_\*(C'\fR levels defined by \f(CW\*(C`Carp::Datum\*(C'\fR, and how they remap to \f(CW\*(C`Log::Agent\*(C'\fR routines when \f(CW\*(C`Carp::Datum\*(C'\fR is off: .PP .Vb 10 \& Carp::Datum Log::Agent \& \-\-\-\-\-\-\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\- \& TRC_EMERGENCY logdie \& TRC_ALERT logerr \& TRC_CRITICAL logerr \& TRC_ERROR logerr \& TRC_WARNING logwarn \& TRC_NOTICE logsay \& TRC_INFO logtrc "info" \& TRC_DEBUG logtrc "debug" .Ve .PP If an application does not configure \f(CW\*(C`Log::Agent\*(C'\fR specifically, all the calls map nicely to perl's native routines (die, warn and print). .SS "Convenience Routines" .IX Subsection "Convenience Routines" .ie n .IP """equiv"" \fIexpr1\fR, \fIexpr2\fR" 4 .el .IP "\f(CWequiv\fR \fIexpr1\fR, \fIexpr2\fR" 4 .IX Item "equiv expr1, expr2" Returns true when both \fIexpr1\fR and \fIexpr2\fR have the same truth value, whether they are both true or both false. .ie n .IP """implies"" \fIexpr1\fR, \fIexpr2\fR" 4 .el .IP "\f(CWimplies\fR \fIexpr1\fR, \fIexpr2\fR" 4 .IX Item "implies expr1, expr2" Returns the truth value of \fIexpr1\fR implies \fIexpr2\fR, which is the same as: .Sp .Vb 1 \& !expr1 || expr2 .Ve .Sp It is always true except when \fIexpr1\fR is true and \fIexpr2\fR is false. .Sp Warning: this is function, not a macro. That is to say, both arguments are evaluated, and there is no short-circuit when \fIexpr1\fR is false. .SH "DEBUG CONFIGURATION" .IX Header "DEBUG CONFIGURATION" .SS "Global Switch on/off" .IX Subsection "Global Switch on/off" The \f(CW\*(C`Carp::Datum\*(C'\fR module can be turned on/off. This indication must be included when the module is imported in the main program as followed: .PP .Vb 3 \& # In application\*(Aqs main \& use Carp::Datum qw(:all on); # to turn on \& use Carp::Datum qw(:all off); # to turn off .Ve .PP When \f(CW\*(C`Carp::Datum\*(C'\fR is turned off, most of the specific functions (\s-1DFEATURE, ...\s0) continue to be invoked during the program execution but they return immediately. In details, all the tracing functions are disconnected, the contracts (\s-1DASSERT, DREQUIRE, DENSURE\s0) continue to be verified: assertion failure will stop the program. .PP That leads to a tiny perfomance loss when running production release. But, the delivered code keeps the possibility to be easily debugged. If the performance would be problematic in a production release, there is a stripper program available that can extract all the \&\f(CW\*(C`Carp::Datum\*(C'\fR calls from a source file. (see Carp::Datum::Strip). .PP To turn on/off debugging according to an environment variable, the module can be imported like the following: .PP .Vb 2 \& # In application\*(Aqs main \& use Carp::Datum (":all", $ENV{DATUM}); \& \& # as a preamble to the program execution \& # in your favorite shell (here /bin/ksh) \& export DATUM=on # to turn on \& export DATUM=off # to turn off .Ve .SS "Dynamic Configuration" .IX Subsection "Dynamic Configuration" The dynamic configuration is loaded when the \f(CW\*(C`DLOAD_CONFIG\*(C'\fR function is invoked in the main program. The function signature passes either a filename or directly a string (or both). .PP .Vb 10 \& DLOAD_CONFIG(\-file => "./debug.cf") # filename \& \- or \- \& DLOAD_CONFIG(\-config => <. .SH "SEE ALSO" .IX Header "SEE ALSO" \&\fBCarp::Datum::Cfg\fR\|(3), \fBCarp::Datum::MakeMaker\fR\|(3), \fBCarp::Datum::Strip\fR\|(3), \&\fBLog::Agent\fR\|(3).