Provided by: pdl_2.4.7+dfsg-2ubuntu5_amd64 bug

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.

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 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)

       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 this 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

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', 'Examples', 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.