PDL::Doc(3)

NAME
PDL::Doc - support for PDL online documentation

SYNOPSIS
  use PDL::Doc;
  $onlinedc = PDL::Doc->new($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 users to remind themselves of names, calling conventions and typical usage of the multitude of functions at their 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 an ndarray 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. The documentation under this directive should indicate if this function accepts ndarrays with bad values and under what circumstances this function might return ndarrays 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) = $z->func(1,3);  # this is part of the accepted info
         $x = func($z,0,1);        # this as well

         $x = func($c,$d);         # 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 ndarrays 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 ndarrays 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 they 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 ndarrays

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 maintenance 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 automatically 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 = PDL::Doc->new('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). To see what it has stored in it in JSON format:

  perl -MPDL::Doc -MJSON::PP -e \
    'print encode_json +PDL::Doc->new(PDL::Doc::_find_inc([qw(PDL pdldoc.db)]))->gethash' |
    json_pp -json_opt pretty,canonical

The symhash is a multiply nested hash ref with the following structure:

 $symhash = {
     function_name => {
             module::name => {
                  Module => 'module::name',
                  Sig    => 'signature string',
                  Bad    => 'bad documentation string',
                  ...
                  },
             },
     function_name => {
             module::name => {
                  Module => 'module::name',
                  Sig    => 'signature string',
                  Bad    => 'bad documentation string',
                  ...
                  },
             },
 }

The three-layer structure is designed to allow the symhash (and the underlying database) to handle functions that have the same name but reside in different module namespaces.

The possible keys for each function/module entry 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 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 triplets in the form

 @results = (
  [funcname, module, {SYMHASH_ENTRY}],
  [funcname, module, {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::PodParser filter.

FUNCTIONS

  add_module
 use PDL::Doc;
 PDL::Doc::add_module("PDL::Stats"); # add PDL::Stats, PDL::Stats::GLM, ...

The "add_module" function allows you to add POD from a particular Perl module (and as of PDL 2.083, in fact all modules starting with that as a prefix) 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(s) into the database.

"add_module" is meant to be added to your module's Makefile as part of the installation script. This is done automatically by "pdlpp_postamble" in PDL::Core::Dev, but if the top level of your distribution is Perl modules (like PDL::LinearAlgebra), then add a "postamble" manually in the Makefile.PL:

  use PDL::Core::Dev;
  sub MY::postamble {
    my $oneliner = PDL::Core::Dev::_oneliner(qq{exit if \$ENV{DESTDIR}; use PDL::Doc; eval { PDL::Doc::add_module(shift); }});
    qq|\ninstall :: pure_install\n\t$oneliner \$(NAME)\n|;
  }

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 ($file) = _find_inc([qw(PDL pdldoc.db)], 0);
 die "Unable to find docs database!\n" unless defined $file;
 print "Found docs database $file\n";
 my $pdldoc = PDL::Doc->new($file);
 # Print the reference line for zeroes:
 print map{$_->{Ref}} values %{$pdldoc->gethash->{zeroes}};
 # Or, if you remember that zeroes is in PDL::Core:
 print $pdldoc->gethash->{zeroes}->{PDL::Core}->{Ref};

 # Get info for all the functions whose examples use zeroes
 my @entries = $pdldoc->search('zeroes','Example',1);

 # All the functions that use zeroes in their example:
 print "Functions that use 'zeroes' in their examples include:\n";
 foreach my $entry (@entries) {
     # Unpack the entry
     my ($func_name, $module, $sym_hash) = @$entry;
     print "$func_name\n";
 }
 print "\n";

 #Or, more concisely:
 print map "$_->[0]\n", @entries;

 # 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, undef, $sym_hash) = @$entry;
 print "mpdl info:\n";
 foreach my $key (sort 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 and vectorization/broadcasting
 print $pdldoc->gethash->{'PDL::Core'}->{'PDL::Core'}->{Ref}, "\n"

BUGS
Quite a few shortcomings which will hopefully be fixed following discussions on the pdl-devel 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>

Documentation database restructuring 2019 Derek Lamb

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.