Doc(3) User Contributed Perl Documentation Doc(3)NAMEPDL::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.
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
=head1 FUNCTIONS
Individual functions in this 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 podparser is derived from the PDL::Pod::Parser class that had
to be patched in a few places, partly to fix minor bugs, partly to
enhance functionality for perusal by PDL::Doc. Since the PDL::Doc
module is still experimental the patched Pod-Parser distribution is
included with the current PDL-Doc distribution. Note that PDL::Doc will
not work correctly with the released Pod-Parser distribution.
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 intention is to have
this information automatically created for pp-compiled functions,
although it can be over-ridden.
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)
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 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 this docs have been extracted from
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.
FUNCTIONSBUGS
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> 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.
perl v5.10.0 2003-09-16 Doc(3)
