Data::Show(3pm)

📦

version 0.004002 · 4 versions

0.004002 · ubuntu resolute, ubuntu stonking (latest)
0.002004 · ubuntu jammy
0.002004 · debian bookworm, ubuntu noble
0.004001 · debian trixie

💖 Data::Show 💖

okay bestie, so this is the Data::Show(3pm) page and I need you to sit with me for a sec because this module is genuinely iconic. it dumps data structures and tells you where they came from. name, point-of-origin, the whole ✨receipts✨. periodt.

🌸 VERSION 🌸

This document describes Data::Show version 0.004002

✨ 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 🦋

so basically this module is a lil cozy wrapper around a whole bunch of data-dumping modules. it's giving "I don't want to pick a favourite dumper, I want them all to get along" energy and honestly? slay.

When you call show(), it data-dumps its arguments — and it prefaces that dump with a context string that reports the arguments and the file and line that show() was called from. like, it snitches on your own code for your own good. no cap. 💅

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

and if you have Term::ANSIColor installed, bestie, you get an even cleaner dump — the context, the source code, and the dumped values all distinguished in distinct, accessible, and configurable colours. it's giving rainbow but make it ✨functional✨ 🌈

👑 INTERFACE 👑

use Data::Show;

Loading the module with no 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" below, iykyk.)

The show() subroutine is the only subroutine this module provides. It is always exported. one icon, no entourage. 💅

show() can be called with any number of arguments and it data-dumps them all, with a suitable header showing the arguments and the file and line from which show() was called.

and the best part?? show() returns its own argument(s), which means you can drop it right in the middle of a larger expression to peek at an intermediate value. (see "Inlined dumps".) not me inserting debug statements that don't break anything, we love a non-destructive queen 😭🫶

🎀 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. it can't be loaded), then a fallback is used instead — see "Fallbacks".

See "Plugins" for the details of how to specify any of the standard plugins, and how to create and name your own plugins. very DIY, very craft-core 🧚

🌈 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".

okay so it's not just a backup, it's the first domino in the whole backup chain. keep that in mind bestie.

💜 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 like... show() is an extremely generic name. it could easily already be used in some other way in the code you're debugging. it's giving "you named your dog 'Dog'". 🙈

So the module can export show() under another name — just load it with the 'as' option and pass 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're asked to dump data. The default maximum is 78 columns, but with this option that maximum can be reset to any desired positive integer value.

heads up bestie: 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. so the grid ones are the well-behaved ones. 😌

💀 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. So 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');

fr fr, warnings => 0 does NOT do what you think it does. the vibes are false but the warnings are true. 💀

🔥 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 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 the output has any styling at all). 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. it's giving "I'll dress up if I can find the outfit". 💅

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. go off, customise your whole aesthetic 🌈

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 that any other ambient source code gets output in (and which is typically de-emphasized 💤) as part of the context info. Default: 'cyan, blue' 💙
filestyle — the style that filenames get output in as part of the context info. Default: 'blue, red' 🔥
linestyle — the style that line numbers get output in as part of the context info. Default: 'blue, red' 🔥
gridstyle — the style that the gridlines are drawn in. Default: 'blue, red' 🎀

✨ Lexically disabling show() ✨

Okay so during a debugging sesh it's lowkey so useful to be able to turn OFF the data-dumping behaviour of the show() subroutine, without having to comment out or delete every single call to it scattered all over your source code. Bestie, we've all been there 😭

So 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 that lexical scope. Meaning: if you think you're gonna need to keep debugging later on, you can set up a whole series of show() calls and then just "turn them off" without actually having to rip them out right away. Iconic. 💅

Of course, those calls still put a slight overhead on your code, so you should still actually remove the calls to show() from your source once you're confident you've genuinely finished debugging it. No cap. 🫶

🧚 Plugins 🧚

Because most dumper modules have totally distinct and incompatible interfaces, Data::Show uses object-oriented wrapper classes to convert each dumper module into a compatible API. And honestly? That's also what makes it easy to integrate other modules you might wanna use as dumpers for Data::Show. Main character design decision, fr fr. ✨

Wrapper classes get automatically generated for these 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 so Data::Show can make use of other dumper modules. Go off 👑

Every wrapper class has to 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). Important detail bestie, don't skip it 🎀

The stringify() method expects a single argument: a data value or reference that is to be stringified. It's 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 a 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 a plugin has to provide is format(). It gets 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";
}

Quick note, bestie: if you're generally happy with the output formatting that Data::Show gives you by default, it's not necessary to write your own format() method when you're making a new plugin — you can just choose to 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 the 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). Slay. 💖

🌸 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. Obsessed with the flexibility honestly. 😌

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 🦋

On top of letting the user explicitly specify a fallback option, the module keeps an internal hierarchy of dumpers it can fall back on if the requested dumper (or the default dumper) isn't 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 can't be loaded, the module will follow the arrows downwards through that 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's not available, then the module will try Data::Pretty, then Data::Dump, then Data::Dumper, then Dumpvalue, accepting the first fallback it can load. And fun fact bestie — both Data::Dumper and Dumpvalue are core modules, so they should always be available in any standard Perl installation. So like... you're never truly stranded 💀🫶

💖 `"Unknown named arguments: <ARGNAMES>"` 💖

So you loaded the module and passed in a named argument whose name is not one of these besties: "as", "to", "with", "fallback", "warnings", "termwidth", "grid", "style", "showstyle", "datastyle", "codestyle", "filestyle", "linestyle", or "gridstyle".

Did you misspell one of those? 🫶 Like, spelling is hard, we get it, but the module is literally keeping receipts.

🦋 `"No value specified for named argument <ARGNAME>"` 🦋

You loaded the module and passed a named option ('with', 'to', 'warnings', etc.) but — bestie — 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, then specify the "undef" explicitly, like:

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';

Slay, okay, so watch out for that one. 😭

✨ `"Unknown configuration options: <CONFIGNAMES>"` ✨

You specified a configuration option in a .datashow file with a name that's not any of: "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 literally does not make sense to specify 'base' in your .datashow configuration file, bestie. 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 there is pointless (and probably indicates a misunderstanding of the 'base' option). 💀

Just remove the configuration option from your .datashow file. Done and dusted. ✨

🌸 `"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. Periodt. 👑

⭐ `"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. Like, check permissions, bestie. 🙈

🍓 `"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. Two whole vibe checks. 💅

💙 `"<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. Quiet quitting, but for dependencies. 😌

🌈 `"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. The plot thickens, bestie. 🫶

🦋 `"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. Iconic. 👑

🌸 `"<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. You're basically the main character now. 🏆

✨ 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. ✨ (We love a clean slate.)

🔥 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 🌈

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 💀

okay bestie, deep breath, this is the part nobody reads but everybody needs. legally speaking, this software is free, and free means no promises. 💅

Because this software is licensed free of charge, there is no warranty for the software, to the extent that applicable law allows. And unless somebody said otherwise in writing, the copyright holders and/or other parties hand you the software "AS IS", with no warranty of any kind — not expressed, not implied, not even a little. That includes (but is not limited to) the implied warranties of merchantability and fitness for a particular purpose. 🙈

And the vibe check on risk? the entire risk as to the quality and performance of the software is with YOU. If the software turns out to be defective, you assume the cost of all necessary servicing, repair, or correction. not us. you. 😭

Now the second paragraph, which is the legal equivalent of "not me, not ever":

In no event — unless applicable law requires it or you agreed to it in writing — will any copyright holder, or any other party who may modify and/or redistribute the software as permitted by the licence above, be liable to you for damages. And we mean any of them: general, special, incidental, or consequential damages arising out of the use or inability to use the software. That includes (but is not limited to) loss of data, data being rendered inaccurate, losses sustained by you or by third parties, or a failure of the software to operate with any other software — even if that holder or other party has been advised of the possibility of such damages. 💀

fr fr, this is the boring part but it's the binding part. read it once, screenshot it, move on. 🫶

and that's the whole page, bestie!! you made it to the end of Data::Show(3pm) and honestly? iconic. 👑

this little writeup came from perl v5.40.1 and was last touched on 2025-08-16, and it lives under the name Data::Show(3pm). go forth and show your data. ✨🎀🦋

📦 where this page comes from

ubuntu resolute: libdata-show-perl 0.004002-1 · Artistic-1.0-Perl OR GPL-1.0-or-later
ubuntu stonking: libdata-show-perl 0.004002-1 · Artistic-1.0-Perl OR GPL-1.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-14: a language model's rewrite of the original, under its terms