Acme-Sort-Sleep
view release on metacpan or search on metacpan
lib/Acme/Sort/Sleep.pod view on Meta::CPAN
Acme::Sort::Sleep - IO::Async timer based sorting algorithm
=head1 SYNOPSIS
use Acme::Sort::Sleep qw( sleepsort );
my @sorted = sleepsort( qw( 3 1 3.37 0 ) );
=head1 DISCUSSION
L<https://www.reddit.com/r/programming/comments/2qeg28/4chan_sleep_sort/>
If it's dumb but it works, it's not dumb.
Except this. This works, but it's still dumb. :D
-- Asmor
Except this won't always work.
=head1 AUTHOR
local/lib/perl5/IO/Async/Stream.pm view on Meta::CPAN
my ( $buffref, $eof ) = @_;
while( $$buffref =~ s/^(.*\n)// ) {
print "Received a line: $1";
}
return 0;
}
Because a reference to the buffer itself is passed, it is simple to use a
C<s///> regular expression on the scalar it points at, to both check if data
is ready (i.e. a whole line), and to remove it from the buffer. If no data is
available then C<0> is returned, to indicate it should not be tried again. If
a line was successfully extracted, then C<1> is returned, to indicate it
should try again in case more lines exist in the buffer.
=head2 Reading binary data
This C<on_read> method accepts incoming records in 16-byte chunks, printing
each one.
local/lib/perl5/Module/Build.pm view on Meta::CPAN
If you run the C<Build> script without any arguments, it runs the
C<build> action, which in turn runs the C<code> and C<docs> actions.
This is analogous to the C<MakeMaker> I<make all> target.
=item clean
[version 0.01]
This action will clean up any files that the build process may have
created, including the C<blib/> directory (but not including the
C<_build/> directory and the C<Build> script itself).
=item code
[version 0.20]
This action builds your code base.
By default it just creates a C<blib/> directory and copies any C<.pm>
and C<.pod> files from your C<lib/> directory into the C<blib/>
directory. It also compiles any C<.xs> files from C<lib/> and places
them in C<blib/>. Of course, you need a working C compiler (probably
the same one that built perl itself) for the compilation to work
properly.
The C<code> action also runs any C<.PL> files in your F<lib/>
directory. Typically these create other files, named the same but
without the C<.PL> ending. For example, a file F<lib/Foo/Bar.pm.PL>
could create the file F<lib/Foo/Bar.pm>. The C<.PL> files are
processed first, so any C<.pm> files (or other kinds that we deal
with) will get copied correctly.
=item config_data
[version 0.26]
local/lib/perl5/Module/Build.pm view on Meta::CPAN
C<perl Build.PL>, followed by the 'build' and 'test' actions in that directory.
Use PERL_MB_OPT or F<.modulebuildrc> to set options that should be applied
during subprocesses
=item docs
[version 0.20]
This will generate documentation (e.g. Unix man pages and HTML
documents) for any installable items under B<blib/> that
contain POD. If there are no C<bindoc> or C<libdoc> installation
targets defined (as will be the case on systems that don't support
Unix manpages) no action is taken for manpages. If there are no
C<binhtml> or C<libhtml> installation targets defined no action is
taken for HTML documents.
=item fakeinstall
[version 0.02]
local/lib/perl5/Module/Build.pm view on Meta::CPAN
With an optional argument specifying an action name (e.g. C<Build help
test>), the 'help' action will show you any POD documentation it can
find for that action.
=item html
[version 0.26]
This will generate HTML documentation for any binary or library files
under B<blib/> that contain POD. The HTML documentation will only be
installed if the install paths can be determined from values in
C<Config.pm>. You can also supply or override install paths on the
command line by specifying C<install_path> values for the C<binhtml>
and/or C<libhtml> installation targets.
With an optional C<html_links> argument set to a false value, you can
skip the search for other documentation to link to, because that can
waste a lot of time if there aren't any links to generate anyway:
./Build html --html_links 0
=item install
[version 0.01]
This action will use C<ExtUtils::Install> to install the files from
C<blib/> into the system. See L<"INSTALL PATHS">
for details about how Module::Build determines where to install
things, and how to influence this process.
If you want the installation process to look around in C<@INC> for
other versions of the stuff you're installing and try to delete it,
you can use the C<uninst> parameter, which tells C<ExtUtils::Install> to
do so:
./Build install uninst=1
local/lib/perl5/Module/Build.pm view on Meta::CPAN
This is an action intended for use by module authors, not people
installing modules. It will generate a boilerplate MANIFEST.SKIP file
if one does not already exist.
=item manpages
[version 0.28]
This will generate man pages for any binary or library files under
B<blib/> that contain POD. The man pages will only be installed if the
install paths can be determined from values in C<Config.pm>. You can
also supply or override install paths by specifying there values on
the command line with the C<bindoc> and C<libdoc> installation
targets.
=item pardist
[version 0.2806]
Generates a PAR binary distribution for use with L<PAR> or L<PAR::Dist>.
local/lib/perl5/Module/Build.pm view on Meta::CPAN
This action is just like the C<clean> action, but also removes the
C<_build> directory and the C<Build> script. If you run the
C<realclean> action, you are essentially starting over, so you will
have to re-create the C<Build> script again.
=item retest
[version 0.2806]
This is just like the C<test> action, but doesn't actually build the
distribution first, and doesn't add F<blib/> to the load path, and
therefore will test against a I<previously> installed version of the
distribution. This can be used to verify that a certain installed
distribution still works, or to see whether newer versions of a
distribution still pass the old regression tests, and so on.
=item skipcheck
[version 0.05]
Reports which files are skipped due to the entries in the
F<MANIFEST.SKIP> file (See L<manifest> for details)
=item test
[version 0.01]
This will use C<Test::Harness> or C<TAP::Harness> to run any regression
tests and report their results. Tests can be defined in the standard
places: a file called C<test.pl> in the top-level directory, or several
files ending with C<.t> in a C<t/> directory.
If you want tests to be 'verbose', i.e. show details of test execution
rather than just summary information, pass the argument C<verbose=1>.
If you want to run tests under the perl debugger, pass the argument
C<debugger=1>.
If you want to have Module::Build find test files with different file
name extensions, pass the C<test_file_exts> argument with an array
of extensions, such as C<[qw( .t .s .z )]>.
local/lib/perl5/Module/Build.pm view on Meta::CPAN
=head1 SEE ALSO
perl(1), L<Module::Build::Cookbook>, L<Module::Build::Authoring>,
L<Module::Build::API>, L<ExtUtils::MakeMaker>
F<META.yml> Specification:
L<CPAN::Meta::Spec>
L<http://www.dsmit.com/cons/>
L<http://search.cpan.org/dist/PerlBuildSystem/>
=cut
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
=item mozilla
The distribution is licensed under the Mozilla Public
License. (L<http://opensource.org/licenses/mozilla1.0.php> or
L<http://opensource.org/licenses/mozilla1.1.php>)
=item open_source
The distribution is licensed under some other Open Source
Initiative-approved license listed at
L<http://www.opensource.org/licenses/>.
=item perl
The distribution may be copied and redistributed under the same terms
as Perl itself (this is by far the most common licensing option for
modules on CPAN). This is a dual license, in which the user may
choose between either the GPL or the Artistic license.
=item restrictive
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
my $output_file = shift;
open my $fh, ">", $output_file or die "Can't open $output_file: $!";
print $fh <<'END';
#!/usr/bin/perl
print "Hello, world!\n";
END
PL files are not installed by default, so its safe to put them in
F<lib/> and F<bin/>.
=item pm_files
[version 0.19]
An optional parameter specifying the set of C<.pm> files in this
distribution, specified as a hash reference whose keys are the files'
locations in the distributions, and whose values are their logical
locations based on their package name, i.e. where they would be found
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
distribution, you could specify your layout in your C<Build.PL> like
this:
my $build = Module::Build->new
(
module_name => 'Foo::Bar',
...
pm_files => { 'Bar.pm' => 'lib/Foo/Bar.pm' },
);
Note that the values should include C<lib/>, because this is where
they would be found in a "normal" Module::Build-style distribution.
Note also that the path specifications are I<always> given in
Unix-like format, not in the style of the local system.
=item pod_files
[version 0.19]
Just like C<pm_files>, but used for specifying the set of C<.pod>
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
An optional parameter specifying a set of files that should be used as
C<Test::Harness>-style regression tests to be run during the C<test>
action. May be given as an array reference of the files, or as a hash
reference whose keys are the files (and whose values will currently be
ignored). If the argument is given as a single string (not in an
array reference), that string will be treated as a C<glob()> pattern
specifying the files to use.
The default is to look for a F<test.pl> script in the top-level
directory of the distribution, and any files matching the glob pattern
C<*.t> in the F<t/> subdirectory. If the C<recursive_test_files>
property is true, then the C<t/> directory will be scanned recursively
for C<*.t> files.
=item use_tap_harness
[version 0.2808_03]
An optional parameter indicating whether or not to use TAP::Harness for
testing rather than Test::Harness. Defaults to false. If set to true, you must
therefore be sure to add TAP::Harness as a requirement for your module in
L</build_requires>. Implicitly set to a true value if C<tap_harness_args> is
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
stored in the args hash for that option key. When called with two arguments,
the second argument is assigned to the args hash under the key passed as the
first argument.
=item autosplit_file($from, $to)
[version 0.28]
Invokes the L<AutoSplit> module on the C<$from> file, sending the
output to the C<lib/auto> directory inside C<$to>. C<$to> is
typically the C<blib/> directory.
=item base_dir()
[version 0.14]
Returns a string containing the root-level directory of this build,
i.e. where the C<Build.PL> script and the C<lib> directory can be
found. This is usually the same as the current working directory,
because the C<Build> script will C<chdir()> into this directory as
soon as it begins execution.
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
executable bit set, then the destination file will be made executable.
=item create_build_script()
[version 0.05]
Creates an executable script called C<Build> in the current directory
that will be used to execute further user actions. This script is
roughly analogous (in function, not in form) to the Makefile created
by C<ExtUtils::MakeMaker>. This method also creates some temporary
data in a directory called C<_build/>. Both of these will be removed
when the C<realclean> action is performed.
Among the files created in C<_build/> is a F<_build/prereqs> file
containing the set of prerequisites for this distribution, as a hash
of hashes. This file may be C<eval()>-ed to obtain the authoritative
set of prerequisites, which might be different from the contents of
F<META.yml> (because F<Build.PL> might have set them dynamically).
But fancy developers take heed: do not put any fancy custom runtime
code in the F<_build/prereqs> file, leave it as a static declaration
containing only strings and numbers. Similarly, do not alter the
structure of the internal C<< $self->{properties}{requires} >> (etc.)
data members, because that's where this data comes from.
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
The supplied C<$path> should be an absolute path to install elements
of C<$type>. The return value is C<$path>.
Assigning the value C<undef> to an element causes it to be removed.
=item install_types()
[version 0.28]
Returns a list of installable types that this build knows about.
These types each correspond to the name of a directory in F<blib/>,
and the list usually includes items such as C<lib>, C<arch>, C<bin>,
C<script>, C<libdoc>, C<bindoc>, and if HTML documentation is to be
built, C<libhtml> and C<binhtml>. Other user-defined types may also
exist.
=item invoked_action()
[version 0.28]
This is the name of the original action invoked by the user. This
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
Returns a hash reference indicating the C<requires> prerequisites that
were passed to the C<new()> method.
=item rscan_dir($dir, $pattern)
[version 0.28]
Uses C<File::Find> to traverse the directory C<$dir>, returning a
reference to an array of entries matching C<$pattern>. C<$pattern>
may either be a regular expression (using C<qr//> or just a plain
string), or a reference to a subroutine that will return true for
wanted entries. If C<$pattern> is not given, all entries will be
returned.
Examples:
# All the *.pm files in lib/
$m->rscan_dir('lib', qr/\.pm$/)
# All the files in blib/ that aren't *.html files
local/lib/perl5/Module/Build/Authoring.pod view on Meta::CPAN
=head1 SEE ALSO
perl(1), L<Module::Build>(3), L<Module::Build::API>(3),
L<Module::Build::Cookbook>(3), L<ExtUtils::MakeMaker>(3), L<YAML>(3)
F<META.yml> Specification:
L<CPAN::Meta::Spec>
L<http://www.dsmit.com/cons/>
L<http://search.cpan.org/dist/PerlBuildSystem/>
=cut
local/lib/perl5/Module/Build/Bundling.pod view on Meta::CPAN
In order to install a distribution using Module::Build, users must
have Module::Build available on their systems. There are two ways
to do this. The first way is to include Module::Build in the
C<configure_requires> metadata field. This field is supported by
recent versions L<CPAN> and L<CPANPLUS> and is a standard feature
in the Perl core as of Perl 5.10.1. Module::Build now adds itself
to C<configure_requires> by default.
The second way supports older Perls that have not upgraded CPAN or
CPANPLUS and involves bundling an entire copy of Module::Build
into the distribution's C<inc/> directory. This is the same approach
used by L<Module::Install>, a modern wrapper around ExtUtils::MakeMaker
for Makefile.PL based distributions.
The "trick" to making this work for Module::Build is making sure the
highest version Module::Build is used, whether this is in C<inc/> or
already installed on the user's system. This ensures that all necessary
features are available as well as any new bug fixes. This is done using
the experimental L<inc::latest> module, available on CPAN.
A "normal" Build.PL looks like this (with only the minimum required
fields):
use Module::Build;
Module::Build->new(
local/lib/perl5/Module/Build/Bundling.pod view on Meta::CPAN
Module::Build->new(
module_name => 'Foo::Bar',
license => 'perl',
)->create_build_script;
For I<authors>, when "Build dist" is run, Module::Build will be
automatically bundled into C<inc> according to the rules for
L<inc::latest>.
For I<users>, inc::latest will load the latest Module::Build, whether
installed or bundled in C<inc/>.
=head1 BUNDLING OTHER CONFIGURATION DEPENDENCIES
The same approach works for other configuration dependencies -- modules
that I<must> be available for Build.PL to run. All other dependencies can
be specified as usual in the Build.PL and CPAN or CPANPLUS will install
them after Build.PL finishes.
For example, to bundle the L<Devel::AssertOS::Unix> module (which ensures a
"Unix-like" operating system), one could do this:
local/lib/perl5/Module/Build/Bundling.pod view on Meta::CPAN
Module::Build->new(
module_name => 'Foo::Bar',
license => 'perl',
)->create_build_script;
The C<inc::latest> module creates bundled directories based on the packlist
file of an installed distribution. Even though C<inc::latest> takes module
name arguments, it is better to think of it as bundling and making
available entire I<distributions>. When a module is loaded through
C<inc::latest>, it looks in all bundled distributions in C<inc/> for a
newer module than can be found in the existing C<@INC> array.
Thus, the module-name provided should usually be the "top-level" module
name of a distribution, though this is not strictly required. For example,
L<Module::Build> has a number of heuristics to map module names to
packlists, allowing users to do things like this:
use inc::latest 'Devel::AssertOS::Unix';
even though Devel::AssertOS::Unix is contained within the Devel-CheckOS
local/lib/perl5/Module/Build/Cookbook.pm view on Meta::CPAN
use Module::Build;
my $build = Module::Build->new
(
module_name => 'Foo::Bar',
...other stuff here...
);
$build->add_build_element('dat');
$build->create_build_script;
This will find all F<.dat> files in the F<lib/> directory, copy them
to the F<blib/lib/> directory during the C<build> action, and install
them during the C<install> action.
If your extra files aren't located in the C<lib/> directory in your
distribution, you can explicitly say where they are, just as you'd do
with F<.pm> or F<.pod> files:
use Module::Build;
my $build = new Module::Build
(
module_name => 'Foo::Bar',
dat_files => {'some/dir/Bar.dat' => 'lib/Foo/Bar.dat'},
...other stuff here...
);
local/lib/perl5/Module/Build/Cookbook.pm view on Meta::CPAN
}
EOF
my $build = $class->new
(
module_name => 'Foo::Bar',
...other stuff here...
);
$build->add_build_element('dat');
$build->create_build_script;
If your extra files don't go in F<lib/> but in some other place, see
L<"Adding new elements to the install process"> for how to actually
get them installed.
Please note that these examples use some capabilities of Module::Build
that first appeared in version 0.26. Before that it could
still be done, but the simple cases took a bit more work.
=head2 Adding new elements to the install process
By default, Module::Build creates seven subdirectories of the F<blib>
directory during the build process: F<lib>, F<arch>, F<bin>,
F<script>, F<bindoc>, F<libdoc>, and F<html> (some of these may be
missing or empty if there's nothing to go in them). Anything copied
to these directories during the build will eventually be installed
during the C<install> action (see L<Module::Build/"INSTALL PATHS">.
If you need to create a new custom type of installable element, e.g. C<conf>,
then you need to tell Module::Build where things in F<blib/conf/>
should be installed. To do this, use the C<install_path> parameter to
the C<new()> method:
my $build = Module::Build->new
(
...other stuff here...
install_path => { conf => $installation_path }
);
Or you can call the C<install_path()> method later:
$build->install_path(conf => $installation_path);
The user may also specify the path on the command line:
perl Build.PL --install_path conf=/foo/path/etc
The important part, though, is that I<somehow> the install path needs
to be set, or else nothing in the F<blib/conf/> directory will get
installed, and a runtime error during the C<install> action will
result.
See also L<"Adding new file types to the build process"> for how to
create the stuff in F<blib/conf/> in the first place.
=head1 EXAMPLES ON CPAN
Several distributions on CPAN are making good use of various features
of Module::Build. They can serve as real-world examples for others.
=head2 SVN-Notify-Mirror
L<http://search.cpan.org/~jpeacock/SVN-Notify-Mirror/>
John Peacock, author of the C<SVN-Notify-Mirror> distribution, says:
=over 4
=item 1. Using C<auto_features>, I check to see whether two optional
modules are available - SVN::Notify::Config and Net::SSH;
=item 2. If the S::N::Config module is loaded, I automatically
generate test files for it during Build (using the C<PL_files>
local/lib/perl5/Module/Build/PPMMaker.pm view on Meta::CPAN
# This is a nasty hack because it fails if there is no >= op
if ($op eq '>=') {
$min_version = $version;
last;
}
}
# PPM4 spec requires a '::' for top level modules
$modname .= '::' unless $modname =~ /::/;
$ppd .= qq! <REQUIRE NAME="$modname" VERSION="$min_version" />\n!;
}
}
# We only include these tags if this module involves XS, on the
# assumption that pure Perl modules will work on any OS.
if (keys %{$build->find_xs_files}) {
my $perl_version = $self->_ppd_version($build->perl_version);
$ppd .= sprintf(<<'EOF', $self->_varchname($build->config) );
<ARCHITECTURE NAME="%s" />
EOF
}
foreach my $codebase (@codebase) {
$self->_simple_xml_escape($codebase);
$ppd .= sprintf(<<'EOF', $codebase);
<CODEBASE HREF="%s" />
EOF
}
$ppd .= <<'EOF';
</IMPLEMENTATION>
</SOFTPKG>
EOF
my $ppd_file = "$dist{name}.ppd";
open(my $fh, '>', $ppd_file)
local/lib/perl5/Module/Build/PPMMaker.pm view on Meta::CPAN
On the command line, builds a .ppd file:
./Build ppd
=head1 DESCRIPTION
This package contains the code that builds F<.ppd> "Perl Package
Description" files, in support of ActiveState's "Perl Package
Manager". Details are here:
L<http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/>
=head1 AUTHOR
Dave Rolsky <autarch@urth.org>, Ken Williams <kwilliams@cpan.org>
=head1 COPYRIGHT
Copyright (c) 2001-2006 Ken Williams. All rights reserved.
local/lib/perl5/Module/Build/Platform/cygwin.pm view on Meta::CPAN
$VERSION = eval $VERSION;
use Module::Build::Platform::Unix;
our @ISA = qw(Module::Build::Platform::Unix);
sub manpage_separator {
'.'
}
# Copied from ExtUtils::MM_Cygwin::maybe_command()
# If our path begins with F</cygdrive/> then we use the Windows version
# to determine if it may be a command. Otherwise we use the tests
# from C<ExtUtils::MM_Unix>.
sub _maybe_command {
my ($self, $file) = @_;
if ($file =~ m{^/cygdrive/}i) {
require Module::Build::Platform::Windows;
return Module::Build::Platform::Windows->_maybe_command($file);
}
local/lib/perl5/Test/Exception.pm view on Meta::CPAN
Tests to see that a specific exception is thrown. throws_ok() has two forms:
throws_ok BLOCK REGEX, TEST_DESCRIPTION
throws_ok BLOCK CLASS, TEST_DESCRIPTION
In the first form the test passes if the stringified exception matches the give regular expression. For example:
throws_ok { read_file( 'unreadable' ) } qr/No file/, 'no file';
If your perl does not support C<qr//> you can also pass a regex-like string, for example:
throws_ok { read_file( 'unreadable' ) } '/No file/', 'no file';
The second form of throws_ok() test passes if the exception is of the same class as the one supplied, or a subclass of that class. For example:
throws_ok { $foo->bar } "Error::Simple", 'simple error';
Will only pass if the C<bar> method throws an Error::Simple exception, or a subclass of an Error::Simple exception.
You can get the same effect by passing an instance of the exception you want to look for. The following is equivalent to the previous example:
local/lib/perl5/Test/Exception.pm view on Meta::CPAN
=head1 BUGS
There are some edge cases in Perl's exception handling where Test::Exception will miss exceptions
thrown in DESTROY blocks. See the RT bug L<http://rt.cpan.org/Ticket/Display.html?id=24678> for
details, along with the t/edge-cases.t in the distribution test suite. These will be addressed in
a future Test::Exception release.
If you find any more bugs please let me know by e-mail, or report the problem with
L<http://rt.cpan.org/>.
=head1 COMMUNITY
=over 4
=item perl-qa
If you are interested in testing using Perl I recommend you visit L<http://qa.perl.org/> and join the excellent perl-qa mailing list. See L<http://lists.perl.org/showlist.cgi?name=perl-qa> for details on how to subscribe.
=item perlmonks
You can find users of Test::Exception, including the module author, on L<http://www.perlmonks.org/>. Feel free to ask questions on Test::Exception there.
=item CPAN::Forum
The CPAN Forum is a web forum for discussing Perl's CPAN modules. The Test::Exception forum can be found at L<http://www.cpanforum.com/dist/Test-Exception>.
=item AnnoCPAN
AnnoCPAN is a web site that allows community annotations of Perl module documentation. The Test::Exception annotations can be found at L<http://annocpan.org/~ADIE/Test-Exception/>.
=back
=head1 TO DO
If you think this module should do something that it doesn't (or does something that it shouldn't) please let me know.
You can see my current to do list at L<http://adrianh.tadalist.com/lists/public/15421>, with an RSS feed of changes at L<http://adrianh.tadalist.com/lists/feed_public/15421>.
( run in 1.081 second using v1.01-cache-2.11-cpan-e1769b4cff6 )