NAME¶
PDL::Doc - support for PDL online documentation
SYNOPSIS¶
use PDL::Doc;
$onlinedc = new PDL::Doc ($docfile);
@match = $onlinedc->search('m/slice|clump/');
DESCRIPTION¶
An implementation of online docs for PDL.
Using PDL documentation¶
PDL::Doc's main use is in the "help" (synonym "?") and
"apropos" (synonym "??") commands in the perldl shell.
PDL:Doc provides the infrastrucure to index and access PDL's documentation
through these commands. There is also an API for direct access to the
documentation database (see below).
The PDL doc system is built on Perl's pod (Plain Old Documentation), included
inline with each module. The PDL core modules are automatically indexed when
PDL is built and installed, and there is provision for indexing external
modules as well.
To include your module's pod into the Perl::Doc index, you should follow the
documentation conventions below.
PDL documentation conventions¶
For a package like PDL that has
a lot of functions it is very desirable
to have some form of online help to make it easy for the user to remind
himself of names, calling conventions and typical usage of the multitude of
functions at his disposal. To make it straightforward to extract the relevant
information from the POD documentation in source files that make up the PDL
distribution certain conventions have been adopted in formatting this
documentation.
The first convention says that all documentation for PDL functions appears in
the POD section introduced by one of the following:
=head1 FUNCTIONS
=head1 OPERATORS
=head1 METHODS
=head1 CONSTRUCTORS
If you're documenting an object-oriented interface to a class that your module
defines, you should use METHODS and CONSTRUCTORS as appropriate. If you are
simply adding functions to PDL, use FUNCTIONS and OPERATORS as appropriate.
Individual functions or methods in these section are introduced by
=head2 funcname
where signature is the argumentlist for a PP defined function as explained in
PDL::PP. Generally, PDL documentation is in valid POD format (see perlpod) but
uses the "=for" directive in a special way. The "=for"
directive is used to flag to the PDL Pod parser that information is following
that will be used to generate online help.
The PDL Pod parser recognises the following "=for" directives:
- Ref
- indicates that the one line reference for this function follows, e.g.,
=for ref
Returns a piddle of lags to parent.
- Sig
- the signature for the current function follows, e.g.,
=for sig
Signature: (a(n), [o]b(), [t]tmp(n))
- Usage
- an indication of the possible calling conventions for the current
function, e.g.,
=for usage
wpic($pdl,$filename[,{ options... }])
- Opt
- lists options for the current function, e.g.,
=for options
CONVERTER => 'ppmtogif', # explicitly specify pbm converter
FLAGS => '-interlaced -transparent 0', # flags for converter
IFORM => 'PGM', # explicitly specify intermediate format
XTRAFLAGS => '-imagename iris', # additional flags to defaultflags
FORMAT => 'PCX', # explicitly specify output image format
COLOR => 'bw', # specify color conversion
LUT => $lut, # use color table information
- Example
- gives examples of typical usage for the current function:
=for example
wpic $pdl, $file;
$im->wpic('web.gif',{LUT => $lut});
for (@images) {
$_->wpic($name[0],{CONVERTER => 'ppmtogif'})
}
- Bad
- provides information on how the function handles bad values (if
$PDL:Config{WITH_BADVAL} is set to 1). The documentation under this
directive should indicate if this function accepts piddles with bad values
and under what circumstances this function might return piddles with bad
values.
The PDL podparser is implemented as a simple state machine. Any of the above
"=for" statements switches the podparser into a state where the
following paragraph is accepted as information for the respective field
("Ref", "Usage", "Opt", "Example" or
"Bad"). Only the text up to the end of the current paragraph is
accepted, for example:
=for example
($x,$y) = $a->func(1,3); # this is part of the accepted info
$x = func($a,0,1); # this as well
$x = func($a,$b); # but this isn't
To make the resulting pod documentation also easily digestible for the existing
pod filters (pod2man, pod2text, pod2html, etc) the actual textblock of
information must be separated from the "=for" directive by at least
one blank line. Otherwise, the textblock will be lost in the translation
process when the "normal" podformatters are used. The general idea
behind this format is that it should be easy to extract the information for
online documentation, automatic generation of a reference card, etc but at the
same time the documentation should be translated by the standard podformatters
without loss of contents (and without requiring any changes in the existing
POD format).
The preceding explanations should be further explained by the following example
(extracted from PDL/IO/Misc/misc.pd):
=head2 rcols()
=for ref
Read ASCII whitespaced cols from file into piddles efficiently.
If no columns are specified all are assumed
Will optionally only process lines matching a pattern.
Can take file name or *HANDLE.
=for usage
Usage: ($x,$y,...) = rcols(*HANDLE|"filename", ["/pattern/",$col1, $col2,] ...)
e.g.,
=for example
($x,$y) = rcols 'file1'
($x,$y,$z) = rcols 'file2', "/foo/",3,4
$x = PDL->rcols 'file1';
Note: currently quotes are required on the pattern.
which is translated by, e.g, the standard "pod2text" converter into:
rcols()
Read ASCII whitespaced cols from file into piddles efficiently.
If no columns are specified all are assumed Will optionally only
process lines matching a pattern. Can take file name or *HANDLE.
Usage: ($x,$y,...) = rcols(*HANDLE|"filename", ["/pattern/",$col1, $col2,] ...)
e.g.,
($x,$y) = rcols 'file1'
($x,$y,$z) = rcols 'file2', "/foo/",3,4
$x = PDL->rcols 'file1';
Note: currently quotes are required on the pattern.
It should be clear from the preceding example that readable output can be
obtained from this format using the standard converters and the reader will
hopefully get a feeling how he can easily intersperse the special
"=for" directives with the normal POD documentation.
Which directives should be contained in the documentation¶
The module documentation should start with the
=head1 NAME
PDL::Modulename -- do something with piddles
section (as anyway required by "pod2man") since the PDL podparser
extracts the name of the module this function belongs to from that section.
Each function that is
not only for internal use by the module should be
documented, introduced with the "=head2" directive in the
"=head1 FUNCTIONS" section. The only field that every function
documented along these lines should have is the
Ref field preceding a
one line description of its intended functionality (suitable for inclusion in
a concise reference card). PP defined functions (see PDL::PP) should have a
Sig field stating their signature. To facilitate maintainance of this
documentation for such functions the 'Doc' field has been introduced into the
definition of "pp_def" (see again PDL::PP) which will take care that
name and signature of the so defined function are documented in this way (for
examples of this usage see, for example, the PDL::Slices module, especially
slices.pd and the resulting
Slices.pm). Similarly, the 'BadDoc'
field provides a means of specifying information on how the routine handles
the presence of bad values: this will be autpmatically created if
"BadDoc" is not supplied, or set to "undef".
Furthermore, the documentation for each function should contain at least one of
the
Usage or
Examples fields. Depending on the calling
conventions for the function under consideration presence of both fields may
be warranted.
If a function has options that should be given as a hash reference in the form
{Option => Value, ...}
then the possible options (and aproppriate values) should be explained in the
textblock following the "=for Opt" directive (see example above and,
e.g., PDL::IO::Pic).
It is well possible that some of these conventions appear to be clumsy at times
and the author is keen to hear of any suggestions for better alternatives.
INSTANCE METHODS¶
new¶
$onlinedc = new PDL::Doc ('file.pdl',[more files]);
addfiles¶
add another file to the online database associated with this object.
outfile¶
set the name of the output file for this online db
ensuredb¶
Make sure that the database is slurped in
savedb¶
save the database (i.e., the hash of PDL symbols) to the file associated with
this object.
gethash¶
Return the PDL symhash (e.g. for custom search operations)
The symhash is a multiply nested hash with the following structure:
$symhash = {
function_name => {
Module => 'module::name',
Sig => 'signature string',
Bad => 'bad documentation string',
...
},
function_name => {
Module => 'module::name',
Sig => 'signature string',
Bad => 'bad documentation string',
...
},
};
The possible keys for each function include:
Module - module name
Sig - signature
Crossref - the function name for the documentation, if it has multiple
names (ex: the documentation for zeros is under zeroes)
Names - a comma-separated string of the all the function's names
Example - example text (optional)
Ref - one-line reference string
Opt - options
Usage - short usage explanation
Bad - explanation of behavior when it encounters bad values
search¶
Search a PDL symhash
$onldc->search($regex, $fields [, $sort])
Searching is by default case insensitive. Other flags can be given by specifying
the regexp in the form "m/regex/ismx" where "/" can be
replaced with any other non-alphanumeric character. $fields is an array
reference for all hash fields (or simply a string if you only want to search
one field) that should be matched against the regex. Valid fields are
Name, # name of the function
Module, # module the function belongs to
Ref, # the one-line reference description
Example, # the example for this function
Opt, # options
File, # the path to the source file these docs have been extracted from
If you wish to have your results sorted by function name, pass a true value for
$sort.
The results will be returned as an array of pairs in the form
@results = (
[funcname, {SYMHASH_ENTRY}],
[funcname, {SYMHASH_ENTRY}],
...
);
See the example at the end of the documentation to see how you might use this.
scan¶
Scan a source file using the PDL podparser to extract information for online
documentation
scantree¶
Scan whole directory trees for online documentation in ".pm" (module
definition) and "*.pod" (general documentation) files (using the
File::Find module).
funcdocs¶
extract the complete documentation about a function from its
source file using the PDL::Pod::Parser filter.
FUNCTIONS¶
add_module¶
use PDL::Doc; PDL::Doc::add_module("my::module");
The "add_module" function allows you to add POD from a particular Perl
module that you've installed somewhere in @INC. It searches for the active PDL
document database and the module's .pod and .pm files, and scans and indexes
the module into the database.
"add_module" is meant to be added to your module's Makefile as part of
the installation script.
PDL::DOC EXAMPLE¶
Here's an example of how you might use the PDL Doc database in your own code.
use PDL::Doc;
# Find the pdl documentation
my ($dir,$file,$pdldoc);
DIRECTORY: for $dir (@INC) {
$file = $dir."/PDL/pdldoc.db";
if (-f $file) {
print "Found docs database $file\n";
$pdldoc = new PDL::Doc ($file);
last DIRECTORY;
}
}
die ("Unable to find docs database!\n") unless $pdldoc;
# Print the reference line for zeroes:
print $pdldoc->gethash->{zeroes}->{Ref};
# See which examples use zeroes
$pdldoc->search('zeroes', 'Example', 1);
# All the functions that use zeroes in their example:
my @entries = $pdldoc->search('zeroes', 'Example', 1);
print "Functions that use 'zeroes' in their examples include:\n";
foreach my $entry (@entries) {
# Unpack the entry
my ($func_name, $sym_hash) = @$entry;
print "$func_name\n";
}
print "\n";
# Let's look at the function 'mpdl'
@entries = $pdldoc->search('mpdl', 'Name');
# I know there's only one:
my $entry = $entries[0];
my ($func_name, $sym_hash) = @$entry;
print "mpdl info:\n";
foreach my $key (keys %$sym_hash) {
# Unpack the entry
print "---$key---\n$sym_hash->{$key}\n";
}
Finding Modules¶
How can you tell if you've gotten a module for one of your entries? The Ref
entry will begin with 'Module:' if it's a module. In code:
# Prints:
# Module: fundamental PDL functionality
my $sym_hash = $pdldoc->gethash;
print $pdldoc->gethash->{'PDL::Core'}->{Ref}, "\n"
BUGS¶
Quite a few shortcomings which will hopefully be fixed following discussions on
the pdl-porters mailing list.
AUTHOR¶
Copyright 1997 Christian Soeller <c.soeller@auckland.ac.nz> and Karl
Glazebrook <kgb@aaoepp.aao.gov.au>
Further contributions copyright 2010 David Mertens
<dcmertens.perl@gmail.com>
All rights reserved. There is no warranty. You are allowed to redistribute this
software / documentation under certain conditions. For details, see the file
COPYING in the PDL distribution. If this file is separated from the PDL
distribution, the copyright notice should be included in the file.