view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

        - No functional changes.

        - [build] Rebuild to fix POD section ordering.


0.07    2015-12-18  Released-By: PERLANCAR

	- No functional changes.

	- [build] Re-build with updated Perinci::To::POD (0.72) which fixes
          rendering of examples in modules' POD.


0.06    2015-12-17  Released-By: PERLANCAR

	- No functional changes.

	- [build] Re-build with updated Perinci::To::POD (0.70) which fixes
          rendering of modules' POD with regard to result_naked=1/args_as !=
          'hash'.


0.05    2015-12-17  Released-By: PERLANCAR

	- No functional changes.

        - [build] Rebuild with updated Pod::Weaver::Plugin::Rinci (0.50),
          Perinci::Sub::ConvertArgs::Argv (0.07), and
          Perinci::Sub::To::CLIDocData (0.24) which produces nicer/correct
          command-line in examples.


0.04    2015-11-28  Released-By: PERLANCAR

	- Switch to Perinci::CmdLine::Inline for faster startup, allow
	  multiple arguments.

script/_chinese-zodiac-of  view on Meta::CPAN

#adjust with your personal style.
#
#B<Per-package settings.> Each importer package can use its own format/layout,
#output. For example, a module that is migrated from Log::Any uses Log::Any-style
#logging, while another uses native Log::ger style, and yet some other uses block
#formatting like Log::Contextual. This eases code migration and teamwork. Each
#module author can preserve her own logging style, if wanted, and all the modules
#still use the same framework.
#
#B<Dynamic.> Outputs and levels can be changed anytime during run-time and logger
#routines will be updated automatically. This is useful in situation like a
#long-running server application: you can turn on tracing logs temporarily to
#debug problems, then turn them off again, without restarting your server.
#
#B<Interoperability.> There are modules to interop with Log::Any, either consume
#Log::Any logs (see L<Log::Any::Adapter::LogGer>) or produce logs to be consumed
#by Log::Any (see L<Log::ger::Output::LogAny>).
#
#B<Many output modules and plugins.> See C<Log::ger::Output::*>,
#C<Log::ger::Format::*>, C<Log::ger::Layout::*>, C<Log::ger::Plugin::*>. Writing
#an output module in Log::ger is easier than writing a Log::Any::Adapter::*.

script/_zodiac-of  view on Meta::CPAN

#adjust with your personal style.
#
#B<Per-package settings.> Each importer package can use its own format/layout,
#output. For example, a module that is migrated from Log::Any uses Log::Any-style
#logging, while another uses native Log::ger style, and yet some other uses block
#formatting like Log::Contextual. This eases code migration and teamwork. Each
#module author can preserve her own logging style, if wanted, and all the modules
#still use the same framework.
#
#B<Dynamic.> Outputs and levels can be changed anytime during run-time and logger
#routines will be updated automatically. This is useful in situation like a
#long-running server application: you can turn on tracing logs temporarily to
#debug problems, then turn them off again, without restarting your server.
#
#B<Interoperability.> There are modules to interop with Log::Any, either consume
#Log::Any logs (see L<Log::Any::Adapter::LogGer>) or produce logs to be consumed
#by Log::Any (see L<Log::ger::Output::LogAny>).
#
#B<Many output modules and plugins.> See C<Log::ger::Output::*>,
#C<Log::ger::Format::*>, C<Log::ger::Layout::*>, C<Log::ger::Plugin::*>. Writing
#an output module in Log::ger is easier than writing a Log::Any::Adapter::*.