PDL::Doc(3pm)

📦
version 2.106 · 9 versions
, in ubuntu stonking

👑 PDL::Doc 👑

okay bestie, welcome to PDL::Doc(3pm) — your lil' user-contributed perl doc page 💖

✨ NAME ✨

PDL::Doc — it's the whole support system for PDL online documentation. that's it, that's the name, periodt 💅

✨ SYNOPSIS ✨

use PDL::Doc;
$onlinedc = PDL::Doc->new($docfile);
@match = $onlinedc->search('m/slice|clump/');

look at her go 🦋 three lines and you're already searching your docs. iconic.

🌸 DESCRIPTION 🌸

so basically it's an implementation of online docs for PDL. no cap.

Using PDL documentation

the main character use of PDL::Doc is in the "help" command (whose synonym is "?") and the "apropos" command (synonym "??") inside the perldl shell. PDL::Doc provides the infrastructure to index and access PDL's documentation through these commands. and there's also an API for direct access to the documentation database (peep below for that 👀).

the PDL doc system is built on top of Perl's pod (Plain Old Documentation), which is included inline with each module. the PDL core modules get automatically indexed when PDL is built and installed, and there's provision for indexing external modules too ✨.

so if you want your module's pod to be part of the Perl::Doc index, you should follow the documentation conventions below. no pressure but also yes pressure 💅

PDL documentation conventions

for a package like PDL that has a lot of functions, it's super desirable to have some form of online help so users can remind themselves of names, calling conventions and typical usage of the multitude of functions at their disposal. so, to make it straightforward to extract the relevant info 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're just adding functions to PDL, use FUNCTIONS and OPERATORS as appropriate. pick your fighter 🫶

individual functions or methods in these sections 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 it uses the =for directive in a special (and, like, non-conformant) 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. in the POD standard, =for is used to provide information in that paragraph. PDL uses it to signal that information is in the following paragraph. sneaky. we love a plot twist.

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... }])
  • Options — 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 info 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 for 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. iykyk 👑

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, PDL::Slices). similarly, the 'BadDoc' field provides a means of specifying info 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. do both bestie, it's giving thorough 🫶

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 very 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 🌈.

✨ METHODS ✨

Ok bestie, these are the class methods you call on a PDL::Doc object, so buckle up 🎀

💖 new

$onlinedc = PDL::Doc->new('file.pdl',[more files]);

Makes a shiny new online doc database object for you. You can hand it one file, or a whole list of them. Slay. ✨

💖 new_from_hash

$onlinedc = PDL::Doc->new_from_hash(\%hash);

Builds the object straight from a hash you already have. Heads up though: the hash must conform to the 3-level hash format. No shortcuts, no vibe-based structures. 💅

💖 addfiles

Adds another file to the online database that belongs to this object. Like adding a bestie to the group chat — more is more 🫶

💖 ensuredb

Makes sure that the database is slurped in. Yes bestie, slurped. It's giving thirsty. 😭

💖 savedb

Saves the database (aka the hash of PDL symbols) to the file that's associated with this object. Important tea: as of 2.105, you must supply the output file. Don't forget it, ok? 🙈

💖 gethash

Returns the PDL symhash (handy if you wanna do your own custom search situation). Wanna see what it's actually storing in there, in JSON format?

perl -MPDL::Doc -MJSON::PP -e \
  'print encode_json +PDL::Doc->new(PDL::Doc::find_dbs())->gethash' |
  json_pp -json_opt pretty,canonical

The symhash is a multiply nested hash ref, and it's built like this:

$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',
                 ...
            },
    },
};

So why the whole three-layer era? Because it lets the symhash (and the underlying database, its ride-or-die) handle functions that have the same name but live in different module namespaces. Two different girls can have the same name, bestie. It happens. 👑

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

Searches a PDL symhash. Iconic behaviour honestly.

$onldc->search($regex, $fields [, $sort])

So, deets: searching is by default case insensitive. Wanna change the flags? Pass the regexp in the form "m/regex/ismx" — and yeah, that "/" can be swapped out for any other non-alphanumeric character you vibe with. $fields is an array reference for all the hash fields you want matched against the regex (or just a plain string if you only wanna search one field, low maintenance queen). The 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 want your results sorted by function name, just pass a true value for $sort. ✨

And your results come back as an array of triplets, shaped like:

@results = (
 [funcname, module, {SYMHASH_ENTRY}],
 [funcname, module, {SYMHASH_ENTRY}],
 ...
);

There's an example at the end of the documentation showing how you might actually use this — go peek 👀

💖 scan

Scans a source file using the PDL podparser to extract info for online documentation. Extraction, but make it cute 🧚

💖 scantree

Scans whole directory trees for online documentation in ".pm" (module definition) and "*.pod" (general documentation) files. It does this using the File::Find module — very thorough of it. 🌸

💖 funcdocs

Extracts the complete documentation about a function from its source file, using the PDL::PodParser filter. The whole thing. No crumbs left behind. 🍓

✨ FUNCTIONS ✨

These are the standalone functions, separate from the object methods. Different energy, same excellence 💜

🌟 decodedb

$hash = decodedb($fh, $filename);

Decodes the 3-level hash out of a saved PDL::Doc database. Un-flattening the situation, fr fr.

🌟 merge_hash

merge_hash(\%pdldoc_into, \%pdldoc_from); # for 3-level hash only

Merges a 3-level PDL::Doc hash into another one. Two hashes become one. The way that they're merging... 😭

Note the comment, bestie: for 3-level hash only.

🌟 encodedb

encodedb($hash, $fh, $outdir);

That's the whole entry. Short and mysterious. It's giving main character with no backstory. 💅

🌟 scantext

$hash = scantext($module_text, $filename, $verbose);

Scans a single string (the intention here is that it's the contents of a file), and returns a hash of the functions found inside. One string in, a whole hash of functions out. Iconic. ✨

🌟 find_dbs

Finds the available doc databases so PDL::Doc objects can use them.

use PDL::Doc;
my $onlinedoc = PDL::Doc->new(PDL::Doc::find_dbs());

🌟 gen_db

use PDL::Doc;
PDL::Doc::gen_db($db_file, $blib_dir, $script_dir);

Generates a "pdldoc" database into the given location, for just the given directories. Very "only the directories I said" of it.

Added in 2.106 for the new "pdldoc" scheme of one database file per distribution in a centralised directory. It replaces "add_module". And it's used by "pdlpp_postamble" in PDL::Core::Dev. 🎀

🌟 add_module

Replaced with PDL::Core::Dev pdldoc_add in 2.106.

As of 2.106, "pdldoc" documentation is stored in one centrally-installed file per distribution. So if your distribution is pure-Perl, you need this in your Makefile.PL:

use PDL::Core::Dev;
sub MY::postamble { ::pdldoc_add() }

And if your distribution already has a "postamble" that calls "pdlpp_postamble" in PDL::Core::Dev, this will be magically done for you. Magic. No cap. 🪄

🌈 PDL::DOC EXAMPLE 🌈

Here's an example of how you might use the PDL Doc database in your own code. Real code, real vibes:

use PDL::Doc;
# Find the pdl documentation
my ($file) = PDL::Doc::find_dbs();
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,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 got a module for one of your entries? Easy: 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. We're aware bestie, we're aware. 😭

👑 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.

And that's a wrap on PDL::Doc(3pm) bestie!! 💖 This was perl v5.42.3, dated 2026-08-20, and no I will not be explaining why the date is in the future — the docs said it, so I said it. Periodt. ✨👑🦋

📦 where this page comes from