CoCalc Logo Icon
StoreFeaturesDocsShareSupportNewsAboutSign UpSign In

Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.

| Download

GAP 4.8.9 installation with standard packages -- copy to your CoCalc project to get it

Views: 418346
1
2
1 Getting started using AutoDoc
3
4
AutoDoc is a GAP package which is meant to aid GAP package authors in
5
creating and maintaining the documentation of their packages. In this
6
capacity it builds upon GAPDoc, and is not a replacement for GAPDoc, but
7
rather complements it.
8
9
In this chapter we describe how to get started using AutoDoc for your
10
package. First, we explain in Section 1.1 how to write a new package manual
11
from scratch.
12
13
Then we show in Section 1.3 how you might benefit from AutoDoc even if you
14
already have a complete manual written using GAPDoc.
15
16
In Section 1.4, we explain how you may use AutoDoc to generate a title page
17
and the main XML file for your manual.
18
19
Finally, Section 1.5, explains what AutoDoc worksheets are and how to use
20
them.
21
22
23
1.1 Creating a package manual from scratch
24
25
Suppose your package is already up and running, but so far has no manual.
26
Then you can rapidly generate a scaffold for a package manual using the
27
AutoDoc (4.1-1) command like this, while running GAP from within your
28
package's directory (the one containing the PackageInfo.g file):
29
30

31
LoadPackage( "AutoDoc" );
32
AutoDoc( rec( scaffold := true ) );
33

34
35
This first reads the PackageInfo.g file from the current directory. It
36
extracts information about package from it (such as its name and version,
37
see Section 1.4-1). It then creates two XML files
38
doc/NAME_OF_YOUR_PACKAGE.xml and doc/title.xml insider the package
39
directory. Finally, it runs GAPDoc on them to produce a nice initial PDF and
40
HTML version of your fresh manual.
41
42
To ensure that the GAP help system picks up your package manual, you should
43
also add something like the following to your PackageInfo.g:
44
45

46
PackageDoc := rec(
47
 BookName := ~.PackageName,
48
 ArchiveURLSubset := ["doc"],
49
 HTMLStart := "doc/chap0.html",
50
 PDFFile := "doc/manual.pdf",
51
 SixFile := "doc/manual.six",
52
 LongTitle := ~.Subtitle,
53
),
54

55
56
Congratulations, your package now has a minimal working manual. Of course it
57
will be mostly empty for now, but it already should contain some useful
58
information, based on the data in your PackageInfo.g. This includes your
59
package's name, version and description as well as information about its
60
authors. And if you ever change the package data, (e.g. because your email
61
address changed), just re-run the above command to regenerate the two main
62
XML files with the latest information.
63
64
Next of course you need to provide actual content (unfortunately, we were
65
not yet able to automate that for you, more research on artificial
66
intelligence is required). To add more content, you have several options:
67
You could add further GAPDoc XML files containing extra chapters, sections
68
and so on. Or you could use classic GAPDoc source comments (in either case,
69
see Section 1.3 on how to teach the AutoDoc (4.1-1) command to include this
70
extra documentation). Or you could use the special documentation facilities
71
AutoDoc provides (see Section 1.2).
72
73
You will probably want to re-run the AutoDoc (4.1-1) command frequently,
74
e.g. whenever you modified your documentation or your PackageInfo.g. To make
75
this more convenient and reproducible, we recommend putting its invocation
76
into a file makedoc.g in your package directory, with content based on the
77
following example:
78
79

80
LoadPackage( "AutoDoc" );
81
AutoDoc( rec( autodoc := true ) );
82
QUIT;
83

84
85
Then you can regenerate the package manual from the command line with the
86
following command, executed from within in the package directory:
87
88

89
gap makedoc.g
90

91
92
93
1.2 Documenting code with AutoDoc
94
95
To get one of your global functions, operations, attributes etc. to appear
96
in the package manual, simply insert an AutoDoc comment of the form #!
97
directly in front of it. For example:
98
99

100
#!
101
DeclareOperation( "ToricVariety", [ IsConvexObject ] );
102

103
104
This tiny change is already sufficient to ensure that the operation appears
105
in the manual. In general, you will want to add further information about
106
the operation, such as in the following example:
107
108

109
#! @Arguments conv
110
#! @Returns a toric variety
111
#! @Description
112
#! Creates a toric variety out
113
#! of the convex object <A>conv</A>.
114
DeclareOperation( "ToricVariety", [ IsConvexObject ] );
115

116
117
For a thorough description of what you can do with AutoDoc documentation
118
comments, please refer to chapter 2.
119
120
Suppose you have not been using GAPDoc before but instead used the process
121
described in section 1.1 to create your manual. Then the following GAP
122
command will regenerate the manual and automatically include all newly
123
documented functions, operations etc.:
124
125

126
LoadPackage( "AutoDoc" );
127
AutoDoc( rec( scaffold := true,
128
 autodoc := true ) );
129

130
131
If you are not using the scaffolding feature, e.g. because you already have
132
an existing GAPDoc based manual, then you can still use AutoDoc
133
documentation comments. Just make sure to first edit the main XML file of
134
your documentation, and insert the line
135
136

137
#Include SYSTEM "_AutoDocMainFile.xml"
138

139
140
in a suitable place. This means that you can mix AutoDoc documentation
141
comment freely with your existing documentation; you can even still make use
142
of any existing GAPDoc documentation comments in your code. The following
143
command should be useful for you in this case; it still scans the package
144
code for AutoDoc documentation comments and the runs GAPDoc to produce HTML
145
and PDF output, but does not touch your documentation XML files otherwise.
146
147

148
LoadPackage( "AutoDoc" );
149
AutoDoc( rec( autodoc := true ) );
150

151
152
153
1.3 Using AutoDoc in an existing GAPDoc manual
154
155
Even if you already have an existing GAPDoc manual, it might be interesting
156
for you to use AutoDoc for two purposes:
157
158
First off, with AutoDoc is very convenient to regenerate your documentation.
159
160
Secondly, the scaffolding feature which generates a title package with all
161
the metadata of your package in a uniform way is very handy. The somewhat
162
tedious process of keeping your title page in sync with your PackageInfo.g
163
is fully automated this way (including the correct version, release data,
164
author information and so on).
165
166
There are various examples of packages using AutoDoc for only this purpose,
167
e.g. IO and orb.
168
169
170
1.3-1 Using AutoDoc on a complete GAPDoc manual
171
172
Suppose you already have a complete XML manual, with some main and title XML
173
files and some documentation for operations distributed over all your .g,
174
.gd, and .gi files. Suppose the main XML file is named PACKAGENAME.xml and
175
is in the /doc subfolder of your package. Then you can rebuild your manual
176
by executing the following two GAP commands from a GAP sessions started
177
started in the root directory of your package:
178
179

180
LoadPackage( "AutoDoc" );
181
AutoDoc( );
182

183
184
In contrast, the RingsForHomalg currently uses essentially the following
185
code in its makedoc.g file to achieve the same result
186
187

188
LoadPackage( "GAPDoc" );
189
SetGapDocLaTeXOptions( "utf8" );
190
bib := ParseBibFiles( "doc/RingsForHomalg.bib" );
191
WriteBibXMLextFile( "doc/RingsForHomalgBib.xml", bib );
192
list := [
193
 "../gap/RingsForHomalg.gd",
194
 "../gap/RingsForHomalg.gi",
195
 "../gap/Singular.gi",
196
 "../gap/SingularBasic.gi",
197
 "../examples/RingConstructionsExternalGAP.g",
198
 "../examples/RingConstructionsSingular.g",
199
 "../examples/RingConstructionsMAGMA.g",
200
 "../examples/RingConstructionsMacaulay2.g",
201
 "../examples/RingConstructionsSage.g",
202
 "../examples/RingConstructionsMaple.g",
203
 ];
204
MakeGAPDocDoc( "doc", "RingsForHomalg", list, "RingsForHomalg" );
205
GAPDocManualLab( "RingsForHomalg" );
206

207
208
Note that in particular, you do not have to worry about keeping a list of
209
your implementation files up-to-date.
210
211
But there is more. AutoDoc can create a maketest.g file, which uses the
212
examples in your manual to test your package. This can be achieved via
213
214

215
LoadPackage( "AutoDoc" );
216
AutoDoc( rec( maketest := true ) );
217

218
219
Now the file maketest.g appears in your package directory, and
220
221

222
gap maketest.g
223

224
225
test the examples from your manual.
226
227
228
1.3-2 Setting different GAPDoc options
229
230
Sometimes, the default values for the GAPDoc command used by AutoDoc may not
231
be suitable for your manual.
232
233
Suppose your main XML file is not named PACKAGENAME.xml, but rather
234
something else, e.g. main.xml. Then you can tell AutoDoc to use this file as
235
the main XML file via
236
237

238
LoadPackage( "AutoDoc" );
239
AutoDoc( rec( gapdoc := rec( main := "main" ) ) );
240

241
242
As explained above, by default AutoDoc scans all .g, .gd and .gi files it
243
can find inside of your package root directory, and in the subdirectories
244
gap, lib, examples and examples/doc as well. If you keep source files with
245
documentation in other directories, you can adjust the list of directories
246
AutoDoc scans via the scan_dirs option. The following example illustrates
247
this by instructing AutoDoc to only search in the subdirectory
248
package_sources of the packages root directory.
249
250

251
LoadPackage( "AutoDoc" );
252
AutoDoc( rec( gapdoc := rec( scan_dirs := [ "package_source" ] ) ) );
253

254
255
You can also specify an explicit list of files containing documentation,
256
which will be searched in addition to any files located within the scan
257
directories:
258
259

260
LoadPackage( "AutoDoc" );
261
AutoDoc( rec( gapdoc := rec( files := [ "path/to/some/hidden/file.gds" ] ) ) );
262

263
264
Giving such a file does not prevent the standard scan_dirs from being
265
scanned for other files.
266
267
Next, GAPDoc supports the documentation to be built with relative paths.
268
This means, links to manuals of other packages or the GAP library will not
269
be absolute, but relative from your documentation. This can be particularly
270
useful if you want to build a release tarball or move your GAP installation
271
around later. Suppose you are starting GAP in the root path of your package
272
as always, and the standard call of AutoDoc (4.1-1) will then build the
273
documentation in the doc subfolder of your package. From this folder, the
274
gap root directory has the relative path ../../... Then you can enable the
275
relative paths by
276
277

278
LoadPackage( "AutoDoc" );
279
AutoDoc( rec( gapdoc := rec( gap_root_relative_path := "../../.." ) ) );
280

281
282
or, since ../../.. is the standard option for gap_root_relative_path, by
283
284

285
LoadPackage( "AutoDoc" );
286
AutoDoc( rec( gapdoc := rec( gap_root_relative_path := true ) ) );
287

288
289
290
1.4 Scaffolds
291
292
293
1.4-1 Generating a title page
294
295
For most (if not all) GAP packages, the title page of the package manual
296
lists information such as the release date, version, names and contact
297
details of the authors, and so on. All this data is also contained in your
298
PackageInfo.g, and whenever you make a change to that file, there is a risk
299
that you forget to update your manual to match. And even if you don't forget
300
it, you of course have to spend some time to adjust the manual. GAPDoc can
301
help to a degree with this via entities. Thus, you will sometimes see code
302
like this in PackageInfo.g files:
303
304

305
Version := "1.2.3",
306
Date := "20/01/2015",
307
## <#GAPDoc Label="PKGVERSIONDATA">
308
## <!ENTITY VERSION "1.2.3">
309
## <!ENTITY RELEASEDATE "20 January 2015">
310
## <!ENTITY RELEASEYEAR "2015">
311
## <#/GAPDoc>
312

313
314
However, it is still easy to forget both of these versions. And it doesn't
315
solve the problem of updating package authors addresses. Neither of these is
316
a big issue, of course, but there have been plenty examples in the past
317
where people forget either of these two things, and it can be slightly
318
embarrassing. It may even require you to make a new release just to fix the
319
issue, which in our opinion is a sad waste of your valuable time.
320
321
So instead of worrying about manually synchronising these things, you can
322
instruct AutoDoc to generate a title page for your manual based on the
323
information in your PackageInfo.g. The following commands do just that (in
324
addition to building your manual), by generating a file called
325
doc/title.xml.
326
327

328
LoadPackage( "AutoDoc" );
329
AutoDoc( rec( scaffold := rec( MainPage := false ) ) );
330

331
332
Note that this only outputs doc/title.xml but does not touch any other files
333
of your documentation. In particular, you need to explicitly include
334
doc/title.xml from your main XML file.
335
336
However, you can also tell AutoDoc to maintain the main XML file for you, in
337
which case this is automatic. In fact, this is the default if you enabling
338
scaffolding; the above example command explicitly told AutoDoc not to
339
generate a main page. More o
340
341
342
1.4-2 Generating the main XML file
343
344
The following generates a main XML file for your documentation in addition
345
to the title page. The main XML file includes the title page by default, as
346
well as any documentation generated from AutoDoc documentation comments.
347
348

349
LoadPackage( "AutoDoc" );
350
AutoDoc( rec( scaffold := true ) );
351

352
353
You can instruct AutoDoc to include additional XML files by giving it a list
354
of filenames, as in the following example:
355
356

357
LoadPackage( "AutoDoc" );
358
AutoDoc(rec(
359
 scaffold := rec(
360
 includes := [ "somefile.xml", "anotherfile.xml" ]
361
 )
362
));
363

364
365
For more information, please consult the documentation of the AutoDoc
366
(4.1-1) function.
367
368
369
1.4-3 What data is extracted from PackageInfo.g?
370
371
AutoDoc can extract data from PackageInfo.g in order to generate a title
372
page. Specifically, the following components of the package info record are
373
looked at:
374
375
Version
376
This is used to set the <Version> element of the title page, with the
377
string Version  prepended.
378
379
Date
380
This is used to set the <Date> element of the title page.
381
382
Subtitle
383
This is used to set the <Subtitle> element of the title page (the
384
<Title> is set to the package name).
385
386
Persons
387
This is used to generate <Author> elements in the generated title
388
page.
389
390
PackageDoc
391
This is a record (or a list of records) which is used to tell the GAP
392
help system about the package manual. Currently AutoDoc extracts the
393
value of the PackageDoc.BookName component and then passes that on to
394
GAPDoc when creating the HTML, PDF and text versions of the manual.
395
396
AutoDoc
397
This is a record which can be used to control the scaffolding
398
performed by AutoDoc, specifically to provide extra information for
399
the title page. For example, you can set AutoDoc.TitlePage.Copyright
400
to a string which will then be inserted on the generated title page.
401
Using this method you can customize the following title page elements:
402
TitleComment, Abstract, Copyright, Acknowledgements and Colophon.
403
404
Note that AutoDoc.TitlePage behaves exactly the same as the
405
scaffold.TitlePage parameter of the AutoDoc (4.1-1) function.
406
407
408
1.5 AutoDoc worksheets
409
410
AutoDoc worksheets can be used to create HTML and PDF documents using
411
AutoDoc syntax and possibly including GAP examples and implementations
412
without having them associated to a package. A file for a worksheet could
413
look like this:
414
415

416
#! @Title My first worksheet
417
#! @Author Charlie Brown
418

419
#! @Chapter Some groups
420

421
#! @BeginExample
422
S3 := SymmetricGroup( 3 );;
423
S4 := SymmetricGroup( 4 );;
424
#! @EndExample
425

426
427
Now, one can create a PDF and HTML document, like a package documentation
428
out of it. Suppose the document above is saved as worksheet.g. Then, when
429
GAP is started in the folder of this file, the command
430
431

432
AutoDocWorksheet( "worksheet.g" );
433

434
435
will create a subfolder called doc of the current directory in which it will
436
create the documentation. There are several options to configure the output
437
of the worksheet command, which are identical to the options of the AutoDoc
438
(4.1-1) command. It is even possible to test the examples in the worksheet
439
using the maketest option from the AutoDoc command.
440
441
Since the worksheets do not have a PackageInfo.g to extract information, all
442
possible tags that GAPDoc supports for the title page can be set into the
443
document. A fully typed title page can look like this:
444
445

446
#! @Title My first worksheet
447
#! @Subtitle Some small examples
448
#! @Author Charlie Brown
449

450
#! @Version 0.1
451
#! @TitleComment Some worksheet
452
#! @Date 01/01/2016
453
#! @Address TU Kaiserslautern
454
#! @Abstract
455
#! A worksheet showing some small examples about groups.
456
#! @Copyright 2016 Charlie Brown
457
#! @Acknowledgements Woodstock
458
#! @Colophon Some colophon
459

460
#! @Chapter Some groups
461

462
#! @BeginExample
463
S3 := SymmetricGroup( 3 );;
464
S4 := SymmetricGroup( 4 );;
465
#! @EndExample
466

467
468
469