1Doc(3) User Contributed Perl Documentation Doc(3)
2
6 PDL::Doc - support for PDL online documentation
7
9 use PDL::Doc;
10 $onlinedc = new PDL::Doc ($docfile);
11 @match = $onlinedc->search('m/slice⎪clump/');
12
14 An implementation of online docs for PDL.
15
17 For a package like PDL that has a lot of functions it is very desirable
18 to have some form of online help to make it easy for the user to remind
19 himself of names, calling conventions and typical usage of the multi‐
20 tude of functions at his disposal. To make it straightforward to
21 extract the relevant information from the POD documentation in source
22 files that make up the PDL distribution certain conventions have been
23 adopted in formatting this documentation.
24 The first convention says that all documentation for PDL functions
26 appears in the POD section introduced by
27 =head1 FUNCTIONS
29 Individual functions in this section are introduced by
31 =head2 funcname
33 where signature is the argumentlist for a PP defined function as
35 explained in PDL::PP. Generally, PDL documentation is in valid POD for‐
36 mat (see "perlpod") but uses the "=for" directive in a special way. The
37 "=for" directive is used to flag to the PDL Pod parser that information
38 is following that will be used to generate online help.
39 The PDL podparser is derived from the PDL::Pod::Parser class that had
41 to be patched in a few places, partly to fix minor bugs, partly to
42 enhance functionality for perusal by PDL::Doc. Since the PDL::Doc mod‐
43 ule is still experimental the patched Pod-Parser distribution is
44 included with the current PDL-Doc distribution. Note that PDL::Doc will
45 not work correctly with the released Pod-Parser distribution.
46 The PDL Pod parser recognises the following "=for" directives:
48 Ref indicates that the one line reference for this function follows,
50 e.g.,
51 =for ref
53 Returns a piddle of lags to parent.
55 Sig the signature for the current function follows, e.g.,
57 =for sig
59 Signature: (a(n), [o]b(), [t]tmp(n))
61 Usage
63 an indication of the possible calling conventions for the current
64 function, e.g.,
65 =for usage
67 wpic($pdl,$filename[,{ options... }])
69 Opt lists options for the current function, e.g.,
71 =for options
73 CONVERTER => 'ppmtogif', # explicitly specify pbm converter
75 FLAGS => '-interlaced -transparent 0', # flags for converter
76 IFORM => 'PGM', # explicitly specify intermediate format
77 XTRAFLAGS => '-imagename iris', # additional flags to defaultflags
78 FORMAT => 'PCX', # explicitly specify output image format
79 COLOR => 'bw', # specify color conversion
80 LUT => $lut, # use color table information
81 Example
83 gives examples of typical usage for the current function:
84 =for example
86 wpic $pdl, $file;
88 $im->wpic('web.gif',{LUT => $lut});
89 for (@images) {
90 $_->wpic($name[0],{CONVERTER => 'ppmtogif'})
91 }
92 Bad provides information on how the function handles bad values (if
94 $PDL:Config{WITH_BADVAL} is set to 1). The intention is to have
95 this information automatically created for pp-compiled functions,
96 although it can be over-ridden.
97 The PDL podparser is implemented as a simple state machine. Any of the
99 above "=for" statements switches the podparser into a state where the
100 following paragraph is accepted as information for the respective field
101 ("Ref", "Usage", "Opt", "Example" or "Bad"). Only the text up to the
102 end of the current paragraph is accepted, for example:
103 =for example
105 ($x,$y) = $a->func(1,3); # this is part of the accepted info
107 $x = func($a,0,1); # this as well
108 $x = func($a,$b); # but this isn't
110 To make the resulting pod documentation also easily digestible for the
112 existing pod filters (pod2man, pod2text, pod2html, etc) the actual
113 textblock of information must be separated from the "=for" directive by
114 at least one blank line. Otherwise, the textblock will be lost in the
115 translation process when the "normal" podformatters are used. The gen‐
116 eral idea behind this format is that it should be easy to extract the
117 information for online documentation, automatic generation of a refer‐
118 ence card, etc but at the same time the documentation should be trans‐
119 lated by the standard podformatters without loss of contents (and with‐
120 out requiring any changes in the existing POD format).
121 The preceding explanations should be further explained by the following
123 example (extracted from PDL/IO/Misc/misc.pd):
124 =head2 rcols()
126 =for ref
128 Read ASCII whitespaced cols from file into piddles efficiently.
130 If no columns are specified all are assumed
132 Will optionally only process lines matching a pattern.
133 Can take file name or *HANDLE.
134 =for usage
136 Usage: ($x,$y,...) = rcols(*HANDLE⎪"filename", ["/pattern/",$col1, $col2,] ...)
138 e.g.,
140 =for example
142 ($x,$y) = rcols 'file1'
144 ($x,$y,$z) = rcols 'file2', "/foo/",3,4
145 $x = PDL->rcols 'file1';
146 Note: currently quotes are required on the pattern.
148 which is translated by, e.g, the standard "pod2text" converter into:
150 rcols()
152 Read ASCII whitespaced cols from file into piddles efficiently.
154 If no columns are specified all are assumed Will optionally only
156 process lines matching a pattern. Can take file name or *HANDLE.
157 Usage: ($x,$y,...) = rcols(*HANDLE⎪"filename", ["/pattern/",$col1, $col2,] ...)
159 e.g.,
161 ($x,$y) = rcols 'file1'
163 ($x,$y,$z) = rcols 'file2', "/foo/",3,4
164 $x = PDL->rcols 'file1';
165 Note: currently quotes are required on the pattern.
167 It should be clear from the preceding example that readable output can
169 be obtained from this format using the standard converters and the
170 reader will hopefully get a feeling how he can easily intersperse the
171 special "=for" directives with the normal POD documentation.
172 Which directives should be contained in the documentation
174 The module documentation should start with the
176 =head1 NAME
178 PDL::Modulename -- do something with piddles
180 section (as anyway required by "pod2man") since the PDL podparser
182 extracts the name of the module this function belongs to from that sec‐
183 tion.
184 Each function that is not only for internal use by the module should be
186 documented, introduced with the "=head2" directive in the "=head1 FUNC‐
187 TIONS" section. The only field that every function documented along
188 these lines should have is the Ref field preceding a one line descrip‐
189 tion of its intended functionality (suitable for inclusion in a concise
190 reference card). PP defined functions (see PDL::PP) should have a Sig
191 field stating their signature. To facilitate maintainance of this docu‐
192 mentation for such functions the 'Doc' field has been introduced into
193 the definition of "pp_def" (see again PDL::PP) which will take care
194 that name and signature of the so defined function are documented in
195 this way (for examples of this usage see, for example, the PDL::Slices
196 module, especially slices.pd and the resulting Slices.pm). Similarly,
197 the 'BadDoc' field provides a means of specifying information on how
198 the routine handles the presence of bad values: this will be autpmati‐
199 cally created if "BadDoc" is not supplied, or set to "undef".
200 Furthermore, the documentation for each function should contain at
202 least one of the Usage or Examples fields. Depending on the calling
203 conventions for the function under consideration presence of both
204 fields may be warranted.
205 If a function has options that should be given as a hash reference in
207 the form
208 {Option => Value, ...}
210 then the possible options (and aproppriate values) should be explained
212 in the textblock following the "=for Opt" directive (see example above
213 and, e.g., PDL::IO::Pic).
214 It is well possible that some of these conventions appear to be clumsy
216 at times and the author is keen to hear of any suggestions for better
217 alternatives.
218
220 new
221 $onlinedc = new PDL::Doc ('file.pdl',[more files]);
223 addfiles
225 add another file to the online database associated with this object.
227 outfile
229 set the name of the output file for this online db
231 ensuredb
233 Make sure that the database is slurped in
235 savedb
237 save the database (i.e., the hash of PDL symbols) to the file associ‐
239 ated with this object.
240 gethash
242 Return the PDL symhash (e.g. for custom search operations)
244 search
246 Search a PDL symhash
248 $onldc->search($regex, $fields [, $sort])
250 Searching is by default case insensitive. Other flags can be given by
252 specifying the regexp in the form "m/regex/ismx" where "/" can be
253 replaced with any other non-alphanumeric character. $fields is an array
254 reference for all hash fields that should be matched against the regex.
255 Valid fields are
256 Name, # name of the function
258 Module, # module the function belongs to
259 Ref, # the one-line reference description
260 Example, # the example for this function
261 Opt, # options
262 File, # the path to the source file this docs have been extracted from
263 scan
265 Scan a source file using the PDL podparser to extract information for
267 online documentation
268 scantree
270 Scan whole directory trees for online documentation in ".pm" (module
272 definition) and "*.pod" (general documentation) files (using the
273 File::Find module).
274 funcdocs
276 extract the complete documentation about a function from its
278 source file using the PDL::Pod::Parser filter.
279
282 Quite a few shortcomings which will hopefully be fixed following dis‐
283 cussions on the pdl-porters mailing list.
284
286 Copyright 1997 Christian Soeller <c.soeller@auckland.ac.nz> and Karl
287 Glazebrook <kgb@aaoepp.aao.gov.au> All rights reserved. There is no
288 warranty. You are allowed to redistribute this software / documentation
289 under certain conditions. For details, see the file COPYING in the PDL
290 distribution. If this file is separated from the PDL distribution, the
291 copyright notice should be included in the file.
292perl v5.8.8 2003-09-15 Doc(3)