Algorithm-Dependency
view release on metacpan or search on metacpan
Revision history for Perl extension Algorithm-Dependency
1.112 2020-04-28 03:15:25Z
- restore prerequisite version declarations from version 1.110
- update documentation to add clarity for how ordered processing works
(PR#1) (thanks, Mark Murawski!)
1.111 2018-12-22 01:42:08Z
- distribution tooling updates
1.110 2009-04-14
- Upgrading to Module::Install 0.83
1.109 2009-04-09
- Upgrading to Module::Install 0.82
% make install
On Windows platforms, you should use `dmake` or `nmake`, instead of `make`.
If your perl is system-managed, you can create a local::lib in your home
directory to install modules to. For details, see the local::lib documentation:
https://metacpan.org/pod/local::lib
The prerequisites of this distribution will also have to be installed manually. The
prerequisites are listed in one of the files: `MYMETA.yml` or `MYMETA.json` generated
by running the manual build process described above.
## Configure Prerequisites
This distribution requires other modules to be installed before this
distribution's installer can be run. They can be found under the
"configure_requires" key of META.yml or the
"{prereqs}{configure}{requires}" key of META.json.
## Other Prerequisites
lib/Algorithm/Dependency.pm view on Meta::CPAN
#pod core => [ ],
#pod a => [ 'core' ],
#pod b => [ 'a' ]
#pod this => [ ],
#pod that => [ ],
#pod };
#pod my $deps_source = Algorithm::Dependency::Source::HoA->new( $deps );
#pod
#pod my $dep = Algorithm::Dependency::Ordered->new(
#pod source => $deps_source,
#pod selected => [ 'this', 'that' ], # Items we have processed elsewhere or have already satisfied
#pod )
#pod or die 'Failed to set up dependency algorithm';
#pod
#pod my $also = $dep->schedule_all();
#pod # Returns: ['core', 'a', 'b'] -- ie: installation-order. Whereas using base
#pod # Algorithm::Dependency would return sorted ['a', 'b', 'core']
#pod
#pod my $also = $dep->schedule( 'b' );
#pod # Returns: ['core', 'a', 'b'] -- installation order, including ourselves
#pod
lib/Algorithm/Dependency.pm view on Meta::CPAN
#pod If multiple item names are provided, the same applies. The list returned
#pod will not contain duplicates.
#pod
#pod The method returns a reference to an array of item names on success, a
#pod reference to an empty array if no other items are needed, or C<undef>
#pod on error.
#pod
#pod NOTE: The result of C<depends> is ordered by an internal C<sort>
#pod irrespective of the ordering provided by the dependency handler. Use
#pod L<Algorithm::Dependency::Ordered> and C<schedule> to use the most
#pod common ordering (process sequence)
#pod
#pod =cut
sub depends {
my $self = shift;
my @stack = @_ or return undef;
my @depends = ();
my %checked = ();
# Process the stack
lib/Algorithm/Dependency.pm view on Meta::CPAN
}
#pod =pod
#pod
#pod =head2 schedule $name1, ..., $nameN
#pod
#pod Given a list of one or more item names, the C<depends> method will
#pod return, as a reference to an array, the ordered list of items you
#pod should act upon in whichever order this particular dependency handler
#pod uses - see L<Algorithm::Dependency::Ordered> for one that implements
#pod the most common ordering (process sequence).
#pod
#pod This would be the original names provided, plus those added to satisfy
#pod dependencies, in the preferred order of action. For the normal algorithm,
#pod where order it not important, this is alphabetical order. This makes it
#pod easier for someone watching a program operate on the items to determine
#pod how far you are through the task and makes any logs easier to read.
#pod
#pod If any of the names you provided in the arguments is already selected, it
#pod will not be included in the list.
#pod
lib/Algorithm/Dependency.pm view on Meta::CPAN
core => [ ],
a => [ 'core' ],
b => [ 'a' ]
this => [ ],
that => [ ],
};
my $deps_source = Algorithm::Dependency::Source::HoA->new( $deps );
my $dep = Algorithm::Dependency::Ordered->new(
source => $deps_source,
selected => [ 'this', 'that' ], # Items we have processed elsewhere or have already satisfied
)
or die 'Failed to set up dependency algorithm';
my $also = $dep->schedule_all();
# Returns: ['core', 'a', 'b'] -- ie: installation-order. Whereas using base
# Algorithm::Dependency would return sorted ['a', 'b', 'core']
my $also = $dep->schedule( 'b' );
# Returns: ['core', 'a', 'b'] -- installation order, including ourselves
lib/Algorithm/Dependency.pm view on Meta::CPAN
If multiple item names are provided, the same applies. The list returned
will not contain duplicates.
The method returns a reference to an array of item names on success, a
reference to an empty array if no other items are needed, or C<undef>
on error.
NOTE: The result of C<depends> is ordered by an internal C<sort>
irrespective of the ordering provided by the dependency handler. Use
L<Algorithm::Dependency::Ordered> and C<schedule> to use the most
common ordering (process sequence)
=head2 schedule $name1, ..., $nameN
Given a list of one or more item names, the C<depends> method will
return, as a reference to an array, the ordered list of items you
should act upon in whichever order this particular dependency handler
uses - see L<Algorithm::Dependency::Ordered> for one that implements
the most common ordering (process sequence).
This would be the original names provided, plus those added to satisfy
dependencies, in the preferred order of action. For the normal algorithm,
where order it not important, this is alphabetical order. This makes it
easier for someone watching a program operate on the items to determine
how far you are through the task and makes any logs easier to read.
If any of the names you provided in the arguments is already selected, it
will not be included in the list.
lib/Algorithm/Dependency/Ordered.pm view on Meta::CPAN
my @queue = $rv ? @$rv : return undef;
# Get a working copy of the selected index
my %selected = %{ $self->{selected} };
# If at any time we check every item in the stack without finding
# a suitable candidate for addition to the schedule, we have found
# a circular reference error. We need to create a marker to track this.
my $error_marker = '';
# Begin the processing loop
my @schedule = ();
while ( my $id = shift @queue ) {
# Have we checked every item in the stack?
return undef if $id eq $error_marker;
# Are there any un-met dependencies
my $Item = $self->{source}->item($id) or return undef;
my @missing = grep { ! $selected{$_} } $Item->depends;
# Remove orphans if we are ignoring them
lib/Algorithm/Dependency/Source.pm view on Meta::CPAN
If there are any missing dependencies, returns a reference to an array of
their ids. If there are no missing dependencies, returns 0. Returns
C<undef> on error.
=head1 EXTENDING
C<Algorithm::Dependency::Source> itself is a fairly thin module, and it
is intended that you will probably need to extend it to be able to
extract item data from whatever location you have stored them.
This is usually a fairly simple two step process.
=over 4
=item Overload the C<new> method.
Assuming your subclass takes some form or argument on creation, you will
need to overload the C<new> method to accept the arguments, validate them,
and store them in the source object.
=item Define the method C<_load_item_list>.
t/08_weight.t view on Meta::CPAN
}
is_deeply( $algorithm->weight_all, $basic, 'Got weight for all' );
delete $basic->{B};
delete $basic->{D};
is_deeply( $algorithm->weight_hash(qw{A C E F}), $basic, 'basic: Got weight for selected' );
# Larger scale processing
$file = File::Spec->catfile( $TESTDATA, 'complex.txt' );
$Source = Algorithm::Dependency::Source::File->new( $file );
isa_ok( $Source, 'Algorithm::Dependency::Source::File' );
isa_ok( $Source, 'Algorithm::Dependency::Source' );
@items = $Source->items;
is( scalar(@items), 20, "Source ->items returns a list" );
is( scalar($Source->items), 20, "Source ->items returns a list" );
$algorithm = Algorithm::Dependency::Weight->new( source => $Source );
isa_ok( $algorithm, 'Algorithm::Dependency::Weight' );
isa_ok( $algorithm->source, 'Algorithm::Dependency::Source' );
( run in 0.306 second using v1.01-cache-2.11-cpan-8d75d55dd25 )