view release on metacpan or search on metacpan
lib/App/Build.pm view on Meta::CPAN
my $localdir = File::Spec->catdir( $blib, $type );
next unless -e $localdir;
if (my $dest = $self->install_destination($type)) {
# thins alters the behavious of Module::Build, and
# looks into the implementation
if ( $self->install_path($type)
&& !File::Spec->file_name_is_absolute($dest)) {
$dest = File::Spec->catdir( $self->_prefix, $dest );
}
$map{$localdir} = $dest;
view release on metacpan or search on metacpan
lib/App/BundleDeps.pm view on Meta::CPAN
my $self = shift;
$self->{deps} = shift if @_;
return $self->{deps};
}
# given a META.yml file (if no arguments, looks for a META.yml in the current
# directory), does the proper dep bundling
sub bundle_from_meta {
my ($self, $file) = @_;
$file ||= 'META.yml';
view release on metacpan or search on metacpan
lib/App/CELL/Guide.pm view on Meta::CPAN
meta parameter's value any number of times, and L<App::CELL> will not care.
Initial C<meta> param settings are placed in a file entitled
C<$str_MetaConfig.pm> (where C<$str> is a string free of underscore
characters) in the sitedir. For example, if the application name is FooApp, its
initial C<meta> parameter settings could be contained in a file called
C<FooApp_MetaConfig.pm>. At initialization time, L<App::CELL> looks in
the sitedir for files matching this description, and attempts to load them.
(See L</How configuration files are named>.)
=head4 Core parameters
lib/App/CELL/Guide.pm view on Meta::CPAN
is loaded and OK is returned. If a C<sitedir> argument is present but
invalid, an ERR status results. If no C<sitedir> argument was given, CELL
continues to the next step.
=item C<enviro> parameter --
if no C<sitedir> parameter is given, C<< $CELL->load >> looks for a
parameter called C<enviro> which it interprets as the name of an
environment variable containing the sitedir path. If the C<enviro>
argument points to a valid sitedir, it is loaded and OK is returned. If an
C<enviro> argument is present but invalid, an ERR status results. If there
is no C<enviro> argument at all, CELL continues to the next step.
lib/App/CELL/Guide.pm view on Meta::CPAN
regular expression for message files is:
^.+_Message(_[^_]+){0,1}.conf$
In less-precise human terms, this means that the initialization routine
looks for filenames consisting of at least three, but possibly four,
components:
=over
=item 1. the application name (this can be anything)
lib/App/CELL/Guide.pm view on Meta::CPAN
C<.conf> -- this is stored in the C<language> attribute of the message
object.)
No sanity checks are conducted on the language tag. Whatever string
the regular expression produces becomes the language tag for all
messages in that file. If no language tag is found, CELL first looks for a
config parameter called C<CELL_DEFAULT_LANGUAGE> and, failing that, the
hard-coded fallback value is C<en>.
I'll repeat that, since it's important: CELL assumes that the message
file names contain the relevant language tag. If the message
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
lib/App/CPAN/Mini/Visit.pm view on Meta::CPAN
if ( $config{local} ) {
$opt->merge_defaults( { minicpan => $config{local} } );
}
}
# confirm minicpan directory that looks like minicpan
return _exit_no_minicpan() if !$opt->get_minicpan;
return _exit_bad_minicpan( $opt->get_minicpan ) if !-d $opt->get_minicpan;
my $id_dir = dir( $opt->get_minicpan, qw/authors id/ );
return _exit_bad_minicpan( $opt->get_minicpan ) if !-d $id_dir;
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
bin/cpanidx_httpserver view on Meta::CPAN
$ cpanidx_httpserver --config cpanidx.ini
=head1 CONFIGURATION
Configuration is stored in an L<Config::Tiny> style initialisation file. By default
it looks for a C<cpanidx.ini> in the current working directory. This can be amended
by using the C<--config> command line switch.
If no previous configuration is found, the script will default to using L<DBD::SQLite>
based database C<cpanidx.db> in the current working directory.
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
lib/App/CPANtoRPM.pm view on Meta::CPAN
}
return %files;
}
# This looks at the filelist determines which are pod files, which are
# .pm files, which are test files, etc.
#
sub _categorize_files {
my($self,$op,$dir,%files) = @_;
view release on metacpan or search on metacpan
lib/App/CamelPKI/CADB.pm view on Meta::CPAN
ok($Synopsis::cursor->isa("App::CamelPKI::CADB::Cursor"));
is($Synopsis::cert->serialize(), $certificate->serialize());
is($Synopsis::infos{foo}->[0], "bar");
is_deeply([sort @{$Synopsis::infos{baz}}], [qw(bloggs quux)]);
like($Synopsis::revocation_time, qr/^\d{4}\d{2}\d{2}\d{2}\d{2}\d{2}Z$/,
"revocation time looks ok");
is($Synopsis::revocation_reason, "keyCompromise");
is($Synopsis::compromise_time, "20070313104800Z");
};
=end internals
view release on metacpan or search on metacpan
lib/App/CatalystStarter/Bloated.pm view on Meta::CPAN
If given a --dsn, runs create model and provides default names
for schema and model classes.
=item *
If using a dbi:Pg dsn, looks in your ~/.pgpass to find usernames
and passwords and even intelligently completes your dsn if you are
missing hostname and or port.
=item *
view release on metacpan or search on metacpan
lib/App/Changelog2x.pm view on Meta::CPAN
One special value is recognized: C<unix>. If C<date_format> is called with
this value as a format string, a pre-defined format is used that emulates the
UNIX C<date> command as closely as possible (but see L</CAVEATS> for notes
on B<DateTime> limitations with regards to timezone names and the special
patterns recognized in date format strings to try and work around this). A
string formatted this way looks like this:
Mon Aug 10 09:21:46 -0700 2009
=item xslt_path [DIRS]
view release on metacpan or search on metacpan
devel/brown72-import.pl view on Meta::CPAN
my $tdate = App::Chart::ymd_to_tdate_floor (1980,1,1);
open my $in, '<', $filename or die;
while (defined (my $line = <$in>)) {
$line =~ s/,//;
Scalar::Util::looks_like_number($line) or next;
push @data, { symbol => $symbol,
date => App::Chart::tdate_to_iso($tdate),
close => $line,
};
$tdate++;
devel/brown72-import.pl view on Meta::CPAN
$tdate++;
open my $in, '<', $filename or die;
while (defined (my $line = <$in>)) {
$line =~ s/,//;
Scalar::Util::looks_like_number($line) or next;
$line -= $mean;
$total += $line;
push @data, { symbol => $symbol,
date => App::Chart::tdate_to_iso($tdate),
close => $total,
view release on metacpan or search on metacpan
# Update a member of an archive of if a newer file exists
ar -ruv libMy.a 1.o
# Alternate syntax to link to an archive library
-lABC # looks for libABC.so, then for libABC.a
-l:libABC.a # Looks for libABC.a (more explicit, but simplier)
#############################################################
## C,CPP - String
In the face of ambiguity, do what I mean.
There's more than one way to do it.
Although that might not be obvious unless you're a Monk.
At your discretion is better than not at all.
Although your discretion should be used judiciously.
Just because the code looks clean doesn't mean it is good.
Just because the code looks messy doesn't mean it is bad.
Reuse via CPAN is one honking great idea -- let's do more of that
# Zen of Perl
According to Larry Wall, there are three great virtues of a programmer; Laziness, Impatience and Hubris
- Laziness:
+ my ($Orig,$Self,%Param) = @_;
+ $Orig->($Self,%Param);
+ return 1;
+ };
# The basic Moose type hierarchy looks like this (perl,OOP):
Any
Item
Bool
Maybe[`a]
Undef
#############################################################
## Perl Modules - Scalar::Util
#############################################################
# perl looks_like_number example.
perl -MScalar::Util=looks_like_number -E 'printf("%s: %s\n", $_, looks_like_number($_)) for qw/ 1 cat bat 1.5 1e10 4.5 fat /'
1: 1
cat:
bat:
1.5: 1
1e10: 1
view release on metacpan or search on metacpan
lib/Chronicle/Plugin/PostBuild.pm view on Meta::CPAN
The C<on_generate> method is automatically invoked to generate output
pages. This particular plugin method is invoked I<after> any
C<on_initiate> methods which might be present.
This method merely looks for defined post-build commands, and if any
are encountered they are executed via C<system>.
=cut
sub on_generate
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
lib/App/CmdDispatch.pm view on Meta::CPAN
=back
=head2 run( $cmd, @args )
This method looks up the supplied command and executes it.
=head2 command_hint( $cmd )
This method prints a short hint listing all commands and aliases or just the
hint for the supplied command.
view release on metacpan or search on metacpan
lib/App/Cmdline.pm view on Meta::CPAN
$self->composed_of (
'App::Cmdline::Options::Basic',
);
}
The last example looks a bit inconvenient. And you do not need to do
it that way - because the C<composed_of> method accepts also any
arrayrefs, ignoring them and just passing them to its return
value. That's why you really can call this method only once and not to
be bothered with the hashref at the end. Here is an example how you
can combine class names (predefined sets) with your own option
view release on metacpan or search on metacpan
lib/App/Session/Cookie.pm view on Meta::CPAN
Sample Usage:
$ref->_init($args);
The _init() method looks at the cookies in the request
and restores the session state information from the cookies
named "app_sessiondata" (and "app_sessiondata[2..n]").
When the values of these cookies are concatenated, they
form a Base64-encoded, gzipped, frozen multi-level hash of
view release on metacpan or search on metacpan
my $pid = <PID>;
close( PID );
return undef unless defined $pid;
chomp( $pid );
return undef unless $pid;
die "$pid looks like a funny pid!\n"
unless $pid =~ /^(\d+)$/
;
return $self->{PID} = $1;
}
view release on metacpan or search on metacpan
lib/App/Critique/Command/tutorial.pm view on Meta::CPAN
=head2 Collect
Next you want to ask F<critique> to find all the files you want to
process. This will basically just traverse the directory tree and
find all the available perl files, and looks like this:
> critique collect -v --root lib/ExampleCompany/
You can also provide different criteria to help create the file list
that you want. You can do this in a few ways, here are some examples.
view release on metacpan or search on metacpan
lib/App/DBBrowser/Auxil.pm view on Meta::CPAN
use warnings;
use strict;
use 5.016;
use Encode qw( decode );
use Scalar::Util qw( looks_like_number );
#use Storable qw(); # required
use DBI::Const::GetInfoType;
use JSON::MaybeXS qw( decode_json );
lib/App/DBBrowser/Auxil.pm view on Meta::CPAN
}
sub quote_if_not_numeric {
my ( $sf, $value ) = @_;
if ( looks_like_number $value ) {
return $value;
}
else {
return $sf->{d}{dbh}->quote( $value );
}
view release on metacpan or search on metacpan
The C<flat> output format is meant to support typical unixish command
line uses. It is not a strong serialization format but works well for
simple values nested max 2 levels.
Output looks like this:
=head3 Plain values
Affe
Tiger
view release on metacpan or search on metacpan
inc/Module/Install.pm view on Meta::CPAN
if ( my $code = $sym->{$pwd} ) {
# Delegate back to parent dirs
goto &$code unless $cwd eq $pwd;
}
unless ($$sym =~ s/([^:]+)$//) {
# XXX: it looks like we can't retrieve the missing function
# via $$sym (usually $main::AUTOLOAD) in this case.
# I'm still wondering if we should slurp Makefile.PL to
# get some context or not ...
my ($package, $file, $line) = caller;
die <<"EOT";
view release on metacpan or search on metacpan
string like "SIGINT".
=item status
will print out diagnostics on what the status of the daemon is. Typically,
the output looks like this:
Pid file: ./tt.pid
Pid in file: 15562
Running: yes
Name match: 1
This indicates that the pidfile says that the daemon has PID 15562 and
that a process with this PID is actually running at this moment. Also,
a name grep on the process name in the process table results in 1 match,
according to the output above.
Note that the name match is unreliable, as it just looks for a command line
that looks approximately like the script itself. So if the script is
C<test.pl>, it will match lines like "perl -w test.pl" or
"perl test.pl start", but unfortunately also lines like
"vi test.pl".
If the process is no longer running, the status output might look like
view release on metacpan or search on metacpan
lib/App/Dapper.pm view on Meta::CPAN
_source/
index.md
_output/
index.html
To see what your website looks like, run the C<dapper serve> command which
will spin up a development webserver and serve the static files located in
the output directory (default: C<_output>) at L<http://localhost:8000>.
Now, let's walk through each file:
view release on metacpan or search on metacpan
lib/App/Dest.pm view on Meta::CPAN
Given our database example, we'd likely want each of the action sub-files to be
pure SQL. In that case, we'll need to write some wrapper program that C<dest>
will run that will then consume and run the SQL files as appropriate.
C<dest> looks for wrapper files up the chain from the location of the action
file. Specifically, it'll assume a file is a wrapper if the filename is
"dest.wrap". If such a file is found, then that file is called, and the name of
the action sub-file is passed as its only argument.
As an example, let's say I created an action set that looked like this