Provided by: libdata-show-perl_0.004001-1_all 
NAME
Data::Show - Dump data structures with name and point-of-origin information
VERSION
This document describes Data::Show version 0.004001
SYNOPSIS
use Data::Show;
show %foo;
show @bar;
show (
@bar,
$baz,
);
show $baz;
show $ref;
show @bar[do{1..2;}];
show 2*3;
show 'a+b';
show 100 * sqrt length $baz;
show $foo{q[;{{{]};
DESCRIPTION
This module provides a simple wrapper around various data-dumping modules.
A call to show() data-dumps its arguments, prefaced by a context string that reports the arguments and
the file and line from which show() was called.
For example, the code in the SYNOPSIS might produce something like the following:
### try_SYNOPSIS.pl
### 16: show %foo;
>>>
>>> ( f => 1, o => 2 )
### 17: show @bar;
>>>
>>> qw( 3 . 1 4 1 5 )
### 18: show (
### 19: @bar,
### 20: $baz,
### 21: );
>>>
>>> (3, ".", 1, 4, 1, 5, "baz value")
### 22: show $baz;
>>>
>>> "baz value"
### 23: show $ref;
>>>
>>> {
>>> a => [1, 2, 3],
>>> h => { x => 1, y => 2, z => 3 },
>>> s => \"scalar",
>>> }
### 24: show @bar[do{1..2;}];
>>>
>>> qw( . 1 )
### 25: show 2*3;
>>>
>>> 6
### 26: show 'a+b';
>>>
>>> "a+b"
### 27: show 100 * sqrt length $baz;
>>>
>>> 300
### 28: show $foo{q[;{{{]};
>>>
>>> undef
If you have Term::ANSIColor installed, you get an even cleaner dump with the context, source code, and
dumped values distinguished in distinct, accessible, and configurable colours.
INTERFACE
use Data::Show;
Loading the module without arguments exports a single show() subroutine that dumps its argument(s) to
"STDERR", using either the "Data::Pretty" module, or else "Data::Dump", or else "Data::Dumper", or else
"Dumpvalue" (whichever is first available, in that order - see "Fallbacks").
The show() subroutine is the only subroutine provided by the module. It is always exported.
show() can be called with any number of arguments and data-dumps them all with a suitable header
indicating the arguments, and the file and line from which show() was called.
show() returns its own argument(s), which allows you to place it in the middle of a larger expression to
check an intermediate value (see "Inlined dumps").
Changing the module used to dump data
use Data::Show with => 'MODULE::NAME';
If you pass a 'with' argument when loading the module, it exports the single show() subroutine that dumps
its argument(s) to "STDERR" using the specified dumper plugin. For example:
use Data::Show with => 'Data::Printer';
use Data::Show with => 'Data::Dmp';
use Data::Show with => 'Legacy';
use Data::Show with => 'My::Own::Dumper';
If the requested module is not available (i.e. can't be loaded), then a fallback (see "Fallbacks") is
used instead.
See "Plugins" for details of how to specify any of the standard plugins, and how to create and name your
own plugins.
Specifying a fallback dumper
use Data::Show fallback => 'MODULE::NAME';
You can specify a fallback plugin to be used if the requested (or default) dumper plugin cannot be
loaded. This fallback will be used any time the requested plugin cannot be located, or fails to load, or
does not supply the necessary dumping methods. The specified fallback represents the starting point for
the standard fallback process. See "Fallbacks".
Changing the destination to which data is dumped
use Data::Show to => TARGET_SPECIFIER;
Loading the module with a 'to' argument exports the single show() subroutine that dumps its argument(s)
to the specified target (rather than to "STDERR"). The specified target can be a filename, an already-
opened filehandle, or a variable reference. For example:
use Data::Show to => \*STDOUT;
use Data::Show to => \$capture_variable;
use Data::Show to => 'some_file_name';
Exporting show() under another name...
use Data::Show as => 'explicate';
The module always exports a single show() subroutine, but show() is an extremely generic name, which
could easily already be used in some other way in the code you are debugging.
So the module can export show() under another name, by loading it with the 'as' option, passing the
desired alternative name as a string.
Specifying the output width
use Data::Show termwidth => 78;
Loading the module with a 'termwidth' argument sets the maximum width value that will be passed to
plugins when they are asked to dump data. The default maximum is 78 columns, but using this option that
maximum can be reset to any desired positive integer value.
Note that plugins are always free to disregard the maximum terminal width they are passed, and will often
do so in the interest of showing the dumped data fully. However, the built-in plugins that support grid
output will always constrain their output grids to the requested terminal width.
Silencing warnings
The module produces a number of compile-time warnings , most of which can be silenced, by loading it with
the 'warnings' option, as follows:
use Data::Show warnings => 'off';
Note that if the option is specified with any value except 'off', then warnings will remain enabled.
Specifically, passing a false value for 'warnings' does not turn off warnings. If you need to control
warnings via a boolean value (say in the variable $ENV{WARNINGS}), use something like:
use Data::Show warnings => ($ENV{WARNINGS} ? 'on' : 'off');
Requesting grid output
use Data::Show grid => 'on'; # Or any other true value except 'off'
Normally, the context and data information produced as the output of the show() subroutine are
distinguished by prefixes or by colour/styling. However, you can also request that the context and data
are placed in a grid, to more clearly distinguish the module's output from the program's regular output.
When requested, the grid is generated automatically, using either ASCII punctuation characters:
_______________________________
|20: show ( |
|21: \@bar, |
|22: $baz, |
|23: ); |
|-------------------------------|
| ( ['b', 'a', 'r'], 'baz' ) |
|_______________________________|
...or (if the the module can determine that the terminal supports UTF8 output), using Unicode box-drawing
elements:
┏━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃19│ show ( ┃
┃20│ \@bar, ┃
┃21│ $baz, ┃
┃22│ ); ┃
┠──┴────────────────────────────┨
┃ ( ['b', 'a', 'r'], 'baz' ) ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
The choice to use Unicode is made by examining the $ENV{LC_ALL}, $ENV{LC_TYPE}, and $ENV{LANG}
environment variables. If any of them are set to a value that includes the strings 'utf-8' or 'UTF-8',
then the terminal is assumed to be Unicode capable.
You can also explicitly turn grid output off (if, for example, it was turned on by default in your
.datashow file):
use Data::Show grid => 'off';
Specifying the output style
The module allows you to configure every aspect of the styling of its output (including whether or not it
the output has any styling). Normally, the module determines automatically whether colour output is
appropriate or possible, by checking for the availability of the Term::ANSIColor module. If that module
can be loaded, it is used to style the output; if not, the output is unstyled.
However, you can explicitly disable output styling (regardless of the availability of Term::ANSIColor) by
passing the appropriate 'style' option when the module is loaded:
use Data::Show style => 'off';
You can also turn off styling of just the data dump (leaving the context information styled) with:
use Data::Show style => 'context';
If you wish to explicitly request the default automatic styling (for example, to override an option
specified in the .datashow file), you can do so with:
use Data::Show style => 'auto';
In addition to controlling whether styling is used at all, you can also specify exactly what styling is
used for each component of the output, using the various '...style' options. Each option takes a string
value containing either two Term::ANSIColor style specifications, separated by a comma (the first of
which is used for terminals with dark backgrounds, and the second of which is used for terminals with
light backgrounds):
use Data::Show
# COMPONENT FOR DARK BG FOR LIGHT BG
# ========= =========== ============
datastyle => 'bold white , bold black',
showstyle => 'bold cyan , bold blue',
codestyle => 'cyan , blue',
filestyle => 'blue , red',
linestyle => 'blue , red',
gridstyle => 'blue , red';
Alternatively any of these options can be specified with a single string containing only one
Term::ANSIColor style specification (which is then used for both light- and dark-background terminals):
use Data::Show
# COMPONENT FOR ALL BGS
# ========= ===========
datastyle => 'bold red',
showstyle => 'bold green',
codestyle => 'green',
filestyle => 'cyan',
linestyle => 'cyan',
gridstyle => 'blue';
You can specify as many or as few of these options as you wish, and mix any number of single- and
light/dark values in a single call.
The effect of each option is as follows:
"datastyle"
The style in which the dumped data is output (default: 'bold white, bold black')
"showstyle"
The style in which the show statement itself is output (and highlighted) as part of the context
information (default: 'bold bright_cyan, bold bright_blue')
"codestyle"
The style in which any other ambient source code is output (and typically de-emphasized) as part of
the context information (default: 'cyan, blue')
"filestyle"
The style in which filenames are output as part of the context information (default: 'blue, red')
"linestyle"
The style in which line numbers are output as part of the context information (default: 'blue, red')
"gridstyle"
The style in which gridlines are drawn (default: 'blue, red')
Lexically disabling show()
During a debugging session it can be useful to turn off the data dumping behaviour of the show()
subroutine, without having to comment out, or remove, every call to it throughout the source code.
If you load the module with "no" instead of "use":
no Data::Show;
...then the dumping behaviour of show() is disabled within the rest of the lexical scope. So, if you
anticipate needing to continue debugging at a later stage, you can set up a series of calls to show() and
then "turn them off" without actually having to remove them immediately.
Of course, those calls still impose a slight overhead on your code so you should still actually remove
the calls to show() from your source, once you are confident that you have genuinely finished debugging
it.
Plugins
Because most dumper modules have distinct and incompatible interfaces, the Data::Show module uses object-
oriented wrapper classes to convert each dumper module into a compatible API. This also makes it easy to
integrate other modules you may wish to use as dumpers for Data::Show.
Wrapper classes are automatically generated for the following core or CPAN dumper modules:
Data::Dmp
Data::Dump
Data::Dump::Compact
Data::Dumper
Data::Dumper::Color
Data::Dumper::Concise
Data::Dumper::Table
Data::Pretty
Data::Printer
Data::TreeDumper
Dumpvalue
YAML
YAML::PP
YAML::Tiny
YAML::Tiny::Color
But you can also write your own plugin wrapper classes to allow Data::Show to make use of other dumper
modules.
Each wrapper class must be declared with a name beginning "Data::Show::Plugin::", where the convention is
that the rest of the wrapper's name is the name of the dumper module it's wrapping. For example:
Data::Show::Plugin::Data::Dumper
Data::Show::Plugin::Data::Dump
Data::Show::Plugin::YAML
Data::Show::Plugin::My::Own::Dumper
Each such wrapper class must provide two methods: stringify() and format(). Both methods should expect
to be called on the class itself (i.e. as common methods), rather than on an actual object (i.e. not as
instance methods).
The stringify() method expects a single argument: a data value or reference that is to be stringified.
The stringify() method is expected to return a single string representing that data in some way.
For example:
# Create a plugin to allow Data::Show to dump using the Data::Dumper module...
package Data::Show::Plugin::Data::Dumper;
sub stringify ($class, $data) {
use Data::Dumper 'Dumper';
return Dumper($data) =~ s{ ; (\s*) \z }{$1}xr;
}
When creating plugin you can, of course, use the new Perl OO syntax instead:
class Data::Show::Plugin::Data::Printer;
method stringify ($data) {
use Data::Printer;
return np($data, colored=>1) . "\n";
}
The second method that a plugin must provide is format(). It is passed nine arguments:
$file # The name of the file from which show() was called
$line # The line at which show() was called
$pre_source # Any source code on that line before the call to show()
$source, # The source code of the call to show()
$post_source # Any source code on the same line after the call to show()
$data # The already-stringified data to be shown
$style # A hash containing the various style configuration values
$termwidth # The maximum terminal width nominated by the user
The format() method is expected to use this information to return a single formatted string (possibly
including terminal escape codes) that will then be output as the result of the call to show().
For example:
class Data::Show::Plugin::Legacy;
method format ($class, $file, $line, $pre, $source, $post, $data, $style, $termwidth) {
# Extract description of arglist from source...
$source =~ s{\\A show \b \\s*}{}x;
$source =~ s{\\s+}{ }gx;
$source =~ s{\\A \\( (.*) \\) \\Z}{$1}x;
# Trim filename and format context info and description...
$file =~ s{.*[/\\\\]}{}xms;
my $context = "[ '$file', line $line ]";
# Insert title into header...
my $header = '=' x $termwidth;
substr($header, $TITLE_POS, length($source)+6) = "( $source )";
substr($header, -(length($context)+$TITLE_POS), length($context)) = $context;
# Indent data...
$data =~ s{^}{ }gxms;
# Assemble and send off...
return "$header\\n\\n$data\\n\\n";
}
Note that, if you are generally happy with the output formatting that Data::Show provides by default, it
is not necessary to write your own format() method when creating a new plugin; you can choose to simply
inherit the default one:
class Data::Show::Plugin::My::Own::Dumper;
use Data::Show 'base'; # Inherit format() from Data::Show::Plugin
method stringify ($data) {
use My::Own::Dumper;
return My::Own::Dumper->new->dump($data);
}
...or, if you want legacy Data::Show formatting for your new plugin:
class Data::Show::Plugin::My::Own::Dumper::Legacy;
use Data::Show base => 'Data::Show::Plugin::Legacy'; # Inherit legacy format()
method stringify ($data) {
use My::Own::Dumper;
return My::Own::Dumper->new->dump($data);
}
When the Data::Show module is loaded with the single argument 'base':
use Data::Show 'base';
...it causes the current class to inherit the root plugin base class, "Data::Show::Plugin".
Alternatively, when Data::Show is loaded with a named "base" argument pair:
use Data::Show base => 'Data::Show::Plugin::Whatever';
...it causes the current class to inherit the specified base class (loading or autogenerating that base
class, if necessary).
Modifying existing plugins
The object-oriented nature of the plugin mechanism also makes it easy to modify the dumping or formatting
behaviour of an existing plugin.
For example, if you wanted to change the default behaviour of the builtin plugin for Data::Printer, so
that it no longer shows tainting or colours, and so that it indents by eight columns instead of four,
then you could create a derived plugin class and override its stringify() method:
class Data::Show::Plugin::Data::Printer::Custom;
# Inherit from the existing standard plugin...
use Data::Show base => 'Data::Show::Plugin::Data::Printer';
# Change the stringification behaviour...
method stringify ($data) {
use Data::Printer;
return np($data, show_tainted=>0, colored=>0, indent=>8, ) . "\n";
}
# and thereafter...
use Data::Show with => 'Data::Printer::Custom';
Fallbacks
In addition to allowing the user to explicitly specify a fallback option , the module maintains an
internal hierarchy of dumpers it can fall back on if the requested dumper (or the default dumper) is not
able to be loaded:
Data::Dmp Legacy
\______ ______/
\/
Data::Dumper::Color Data::Pretty Data::Dump::Compact
\________________________ __________________________/
\/
Data::Dumper::Concise Data::Dump YAML YAML::PP YAML::Tiny::Color
\______________ ______________/ \____________ _________________/
\/ \/
Data::Printer Data::Dumper Data::Dumper::Table YAML::Tiny Data::TreeDumper
\____________________________________ ____________________________________/
\/
Dumpvalue
The idea is that when a specific dumper module is requested (or defaulted to) but cannot be loaded, the
module will follow the arrows downwards through the preceding diagram, trying each alternative dumper
module on that path through the tree.
So, for example, if the user requests Data::Dmp as their dumper, but it is not available, then the module
will try Data::Pretty, then Data::Dump, then Data::Dumper, then Dumpvalue, accepting the first fallback
it can load. Note that both Data::Dumper and Dumpvalue are core modules, so they should always be
available in any standard Perl installation.
DIAGNOSTICS
"Unknown named arguments: <ARGNAMES>"
You loaded the module and passed a named argument with a name other than "as", "to", "with",
"fallback", "warnings", "termwidth", "grid", "style", "showstyle", "datastyle", "codestyle",
"filestyle", "linestyle", or "gridstyle".
Did you misspell one of those?
"No value specified for named argument <ARGNAME>"
You loaded the module and passed a named option ('with', 'to', 'warnings', etc.) but you didn't
provide a value for that name. For example:
use Data::Show 'warnings';
If you really intended to specify that named argument with an undefined value, specify the "undef"
explicitly:
use Data::Show 'warnings' => undef;
Although, because passing "undef" actually leaves the warnings on, in this particular example the
user probably meant:
use Data::Show 'warnings' => 'off';
"Unknown configuration options: <CONFIGNAMES>"
You specified a configuration option in a .datashow file with a name other than: "as", "to", "with",
"fallback", "warnings", "termwidth", "grid", "style", "showstyle", "datastyle", "codestyle",
"filestyle", "linestyle", or "gridstyle".
Did you misspell one of those?
"Can't specify 'base' as a configuration option in <CONFIGFILE>"
It doesn't make sense to specify 'base' in your .datashow configuration file. A 'base' specification
causes the current class to inherit a plugin class. But there's no current class in a configuration
file, so specifying a 'base' value is pointless there (and probably indicate a misunderstanding of
the 'base' option).
Just remove the configuration option from your .datashow file.
"If 'base' is specified, it must be the only argument"
The 'base' named argument causes the current class to inherit a specified plugin class. It does not
export or configure show(), so any other arguments are pointless (and probably indicate a
misunderstanding of the 'base' option).
Remove any other named arguments from the "use Data::Show" call.
"Could not open named 'to' argument for output"
You specified a filename as an alternative output target, via a named 'to' argument, but the
specified file could not be opened for output. For example:
use Data::Show to => "";
Check whether the filename is legal on your filesystem, and also whether the target directory, and
any existing version of the file, are both writeable.
"Named 'to' argument is not a writeable target"
You specified a filehandle as an alternative output target, but the filehandle was not writeable.
Check whether the filehandle you passed is actually open, and then whether it is open for output.
"<PLUGIN> requires <MODULE>, which could not be loaded"
You requested a built-in plugin, but that plugin requires a module that could not be loaded.
Either install the required support module, or load Data::Show with:
use Data::Show warnings => 'off';
...to silence this warning and quietly use a fallback module instead.
"Could not load <PLUGIN>"
You requested a non-built-in plugin, but that plugin could not be loaded.
Check that the name of the requested plugin is correctly spelled, and that the plugin is actually
installed somewhere in the current @INC path.
If you can't install the module, you can silence this warning and default to a fallback dumper with:
use Data::Show warnings => 'off';
"Requested plugin class does not provide the following essential methods"
You specified a non-builtin plugin, which was found and loaded, but which did not provide both of the
two required methods for dumping information: stringify() and format().
See "Plugins" for an explanation of why these two methods are required, and how they work.
To ignore this warning and proceed to a fallback dumper module instead:
use Data::Show warnings => 'off';
"Used <FALLBACK> in place of <PLUGIN>"
You requested a plugin that could not be loaded, so the best available fallback was used instead.
You would have also received one or more of the three preceding diagnostics. Consult their entries
for suggestions on silencing this warning.
"Call to show() may not be not transparent"
The call to show() has been inserted into a scalar context, but was passed two or more arguments to
dump. This can change the behaviour of the surrounding code. For example, consider the following
statements:
my @list = (
abs $x,
exp $y,
sqrt $z,
);
sub foo ($angle) {
return cos $angle,
sin $angle;
}
If we add interstitial show() calls, as follows:
my @list = (
abs show $x,
exp show $y,
sqrt show $z,
);
sub foo ($angle) {
return cos show $angle,
sin show $angle;
}
...then the addition of the show() calls actually changes the final contents of @list, and also
changes the return value of foo() in scalar contexts.
This issue (and warning) never occurs in list or void contexts, and can generally be avoided in
scalar contexts, by explicitly parenthesizing each call to show(), as follows:
my @list = (
abs show($x),
exp show($y),
sqrt show($z),
);
sub foo ($angle) {
return cos show($angle),
sin show($angle);
}
Note that this approach also ensures that the various intermediate calls to show() occur in a more
predictable sequence.
"<MODULE> cannot show a <TYPE> reference"
The stringification module used by your selected plugin was unable to stringify the particular data
passed to show().
This may be due to a bug or limitation in the stringification module itself, or it may be because the
target output format does not support rendering certain Perl datatypes. For example, "YAML::Tiny"
deliberately supports only a subset of the full YAML output format and cannot represent references to
scalars or "qr" regexes. So "Data::Show::Plugin::YAML::Tiny" cannot stringify those two data types.
To be shown the particular data, choose another "Data::Show" plugin instead. For example, try
"Data::Show::Plugin::YAML" instead of "Data::Show::Plugin::YAML::Tiny".
"Internal error: <DESCRIPTION>"
Congratulations! You found a bug in this module. Please consider reporting it to the maintainer, who
will be extremely grateful to you.
CONFIGURATION AND ENVIRONMENT
You can change the default values for the 'with', 'to', 'warnings', and all other options to a "use
Data::Show;" by specifying either a local or a global configuration file.
If a "use Data::Show" call does not specify an explicit 'with' or 'to', the module looks first for a
.datashow file in the current directory, and then for a .datashow file in the home directory.
The contents of each of these configuration files must be a series of key":"value pairs (in the typical
INI format). The keys can be any valid named argument that can be passed to a "use Data::Show" import,
except 'base'. As in many other INI config files, you can use "=" instead of ":" if you prefer, and any
line that starts with a "#" is ignored as a comment.
So, for example, you could change the global default plugin (for example, from "Data::Pretty" to
"Data::Printer"), and change the default output destination (from STDERR to the file datashow.log in the
current directory), and change the default styling of output (to something slightly more subtle because
you have an ANSI-256 colour terminal), by creating a ~/.datashow file containing the following lines:
# Change default dumper...
with: Data::Printer
# Change default output target...
to: ./datashow.log
# Change the styling...
showstyle: bold italic ansi75
codestyle: italic ansi246
filestyle: bold italic ansi27
linestyle: bold italic ansi27
gridstyle: ansi27
datastyle: bold white
See the file sample.datashow in the module's distribution for a full example of a potential .datashow
configuration file, in which all the configuration values happen to be the default values for those
options (i.e. installing sample.datashow as your .datashow should have no effect on the module, if you're
loading it without named arguments).
DEPENDENCIES
This module only works under Perl 5.10 and later.
The module requires the PPR module.
It will also require any non-core module that is itself required by a plugin you select.
However, the requested non-core module is not actually required; if it cannot be loaded, the plugin
request will be ignored and a fallback will be used instead.
INCOMPATIBILITIES
None reported.
BUGS AND LIMITATIONS
The module uses a complex PPR-based regex to parse out the call context from the source. Hence it is
subject to the usual limitations of this approach (namely, that it may very occasionally get the argument
list wrong).
Also, because the module uses the PPR module, it will not work under Perl v5.20 (due to bugs in the regex
engine under that version of Perl).
No other bugs have been reported.
Please report any bugs or feature requests to "bug-data-show@rt.cpan.org", or through the web interface
at <http://rt.cpan.org>.
AUTHOR
Damian Conway "<DCONWAY@CPAN.org>"
LICENCE AND COPYRIGHT
Copyright (c) 2010-2024, Damian Conway "<DCONWAY@CPAN.org>". All rights reserved. This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See perlartistic.
DISCLAIMER OF WARRANTY
BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE
SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY
OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE, BE LIABLE
TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF
THE USE OR INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE
WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.