Smart comments provide an easy way to insert debugging and tracking code
into a program. They can report the value of a variable, track the progress
of a loop, and verify that particular assertions are true.

Best of all, when you're finished debugging, you don't have to remove them.
Simply commenting out the 'use Smart::Comments' line turns them back into
regular comments. Leaving smart comments in your code is smart because if
you needed them once, you'll almost certainly need them again later.

sorry, no description found

sorry, no description found

String::Formatter is a tool for building sprintf-like formatting routines.
It supports named or positional formatting, custom conversions, fixed
string interpolation, and simple width-matching out of the box. It is easy
to alter its behavior to write new kinds of format string expanders. For
most cases, it should be easy to build all sorts of formatters out of the
options built into String::Formatter.

Normally, String::Formatter will be used to import a sprintf-like routine
referred to as "'stringf'", but which can be given any name you like. This
routine acts like sprintf in that it takes a string and some inputs and
returns a new string:

my $output = stringf "Some %a format %s for you to %u.\n", { ... };

This routine is actually a wrapper around a String::Formatter object
created by importing stringf. In the following code, the entire hashref
after "stringf" is passed to String::Formatter's constructor (the 'new'
method), save for the '-as' key and any other keys that start with a dash.

use String::Formatter
stringf => {
-as => 'fmt_time',
codes => { ... },
format_hunker => ...,
input_processor => ...,
},
stringf => {
-as => 'fmt_date',
codes => { ... },
string_replacer => ...,
hunk_formatter => ...,
},
;

As you can see, this will generate two stringf routines, with different
behaviors, which are installed with different names. Since the behavior of
these routines is based on the 'format' method of a String::Formatter
object, the rest of the documentation will describe the way the object
behaves.

There's also a 'named_stringf' export, which behaves just like the
'stringf' export, but defaults to the 'named_replace' and
'require_named_input' arguments. There's a 'method_stringf' export, which
defaults 'method_replace' and 'require_single_input'. Finally, a
'indexed_stringf', which defaults to 'indexed_replaced' and
'require_arrayref_input'. For more on these, keep reading, and check out
the cookbook.

the String::Formatter::Cookbook manpage provides a number of recipes for
ways to put String::Formatter to use.

a module for when strings are too long to be displayed in...

The synopsis section, above, looks almost indistinguishable from any other
use of Sub::Exporter, apart from the use of 'method_installer'. It is
nearly indistinguishable in behavior, too. The only change is that
subroutines exported from Method::Builder into named slots in
Vehicle::Autobot will be wrapped in a subroutine called
'Vehicle::Autobot::transform'. This will insert a named frame into stack
traces to aid in debugging.

More importantly (for the author, anyway), they will not be removed by
namespace::autoclean. This makes the following code work:

package MyLibrary;

use Math::Trig qw(tan); # uses Exporter.pm
use String::Truncate qw(trunc); # uses Sub::Exporter's defaults

use Sub::Exporter::ForMethods qw(method_installer);
use Mixin::Linewise { installer => method_installer }, qw(read_file);

use namespace::autoclean;

...

1;

After MyLibrary is compiled, 'namespace::autoclean' will remove 'tan' and
'trunc' as foreign contaminants, but will leave 'read_file' in place. It
will also remove 'method_installer', an added win.

This module enables you to export shared globs with Sub::Exporter
collectors

This class provides a set of assertion methods useful for writing tests.
The API is based on JUnit4 and the Test::Unit::Lite manpage and the methods
die on failure.

These assertion methods might be not useful for common the Test::Builder
manpage-based (the Test::Simple manpage, the Test::More manpage, etc.) test
units.

The assertion methods can be used in class which is derived from
'Test::Assert' or used as standard Perl functions after importing them into
user's namespace.

'Test::Assert' can also wrap standard the Test::Simple manpage, the
Test::More manpage or other the Test::Builder manpage-based tests.

The assertions can be also used for run-time checking.

This module checks that you _Changes_ file has an entry for the current
version of the *Module* being tested.

The version information for the distribution being tested is taken out of
the Build data, or if that is not found, out of the Makefile.

It then attempts to open, in order, a file with the name _Changes_ or
_CHANGES_.

The _Changes_ file is then parsed for version numbers. If one and only one
of the version numbers matches the test passes. Otherwise the test fails.

A message with the current version is printed if the test passes, otherwise
dialog messages are printed to help explain the failure.

The _examples_ directory contains examples of the different formats of
_Changes_ files that are recognized.

'Test::Command' intends to bridge the gap between the well tested functions
and objects you choose and their usage in your programs. By examining the
exit status, terminating signal, STDOUT and STDERR of your program you can
determine if it is behaving as expected.

This includes testing the various combinations and permutations of options
and arguments as well as the interactions between the various functions and
objects that make up your program.

The various test functions below can accept either a command string or an
array reference for the first argument. If the command is expressed as a
string it is passed to 'system' as is. If the command is expressed as an
array reference it is dereferenced and passed to 'system' as a list. See
''perldoc -f system'' for how these may differ.

The final argument for the test functions, '$name', is optional. By default
the '$name' is a concatenation of the test function name, the command
string and the expected value. This construction is generally sufficient
for identifying a failing test, but you may always specify your own '$name'
if desired.

Any of the test functions can be used as instance methods on a
'Test::Command' object. This is done by dropping the initial '$cmd'
argument and instead using arrow notation.

All of the following 'exit_is_num' calls are equivalent.

exit_is_num('true', 0);
exit_is_num('true', 0, 'exit_is_num: true, 0');
exit_is_num(['true'], 0);
exit_is_num(['true'], 0, 'exit_is_num: true, 0');

my $cmd = Test::Command->new( cmd => 'true' );

exit_is_num($cmd, 0);
exit_is_num($cmd, 0, 'exit_is_num: true, 0');
$cmd->exit_is_num(0);
$cmd->exit_is_num(0, 'exit_is_num: true, 0');

$cmd = Test::Command->new( cmd => ['true'] );

exit_is_num($cmd, 0);
exit_is_num($cmd, 0, 'exit_is_num: true, 0');
$cmd->exit_is_num(0);
$cmd->exit_is_num(0, 'exit_is_num: true, 0');