Scripts Documentation
From SpeechWiki
Contents |
Where to find documentation
Via the web
The high-level descriptions of (some of) the scripts is here.
The auto-generated documentation is available for
- perl scripts and modules
- python scripts and modules.
Via the IFP network
The auto-generated documentation is in: /cworkspace/ifp-32-1/hasegawa/programs/scripts/doc
The location of scripts themselves
The scripts themselves are all in svn://mickey/scripts.
A version of SVN is checked out into /cworkspace/ifp-32-1/hasegawa/programs/scripts on the ifp-32 cluster. It is intended to always be in usable state, and our SST group should use it from there. The readme.html file there explains the structure.
A web view onto the official version is temporarily at http://mickey.ifp.uiuc.edu/speech/akantor/fisher/scripts/
Instructions for contributors
How to auto-document the scripts
- Make sure your path for perl and python is set up so you can run the scripts
- Do:
cd /cworkspace/ifp-32-1/hasegawa/programs/scripts/doc ./makeDoc.sh
You need doxygen, doxygenfilter, epydoc installed, and the doxygen needs the patch in /cworkspace/ifp-32-1/hasegawa/programs/scripts/doc/makeDoc.conf/PerlFilter.pm
How to comment your scripts for auto-documentation
In both perl and java you can write comments using the javadoc conventions (more precisely, epydoc for python and doxygen for perl, although both should be supersets of javadoc)
Both perl and python documentation additionally include the usage text that should display when one runs the script with the --help option.
python
Python documentation is pretty well taken care of with epydoc, with the command-line
--help documentation and the web documentation being generated from the
same place, with some minimal requirements for the way people write
their scripts. They can follow examples of the existing ones.
Basically, you need a file docstring to contain somewhere a %InsertOptionParserUsage%
string which will be replaced by usage documentation
""" %InsertOptionParserUsage% The rest of the file documentation... @author ... @see ... """
and also you need to augment the __doc__ string with the usage info whenever the file is interpreted by python.
Putting the following at the end of the file works:
#the parser is used for generating documentation, so create it always, and augment __doc__ with usage info
#This messes up epydoc a little, but allows us to keep a single version of documentation for all purposes
parser = makeParser()
__doc__ = __doc__.replace("%InsertOptionParserUsage%\n", parser.format_help())
if __name__ == "__main__":
main(sys.argv)
If you don't do the above, the documentation will be generated without the --help usage. """
perl
Perl documentation is generated with doxygen and a doxygenfilter script modified to generate --help usage.
Comments used for doc generation should have the first line start with a ##, like this:
## @file # Based on genPhonePhonePos2WholePhoneStateDTs.pl from the gmtk Aurora tutorial
If a comment with @file directive is present (as above). The documentation is associated with the file. In this case, doxygenfilter simply runs the file with the --help option, file.py --help and includes the output with the documentation.
Admittedly this is a little dangerous, but I (Arthur) tried to do this quickly, so anyone is welcome to improve this.
Also note that perl does not really have named arguments, so doxygenfilter actually tries to parse the code for common assignment of the argument list to vars (e.g. my ($arg1, arg2) = @_;), and generates the argument names from there. You can of course specify the arguments in the documentation too:
## @fn private void debug(@args)
# A simple function for debugging. Prints the arguments to STDERR.
# @param args The stuff to be printed.
sub debug {
my(@args) = @_;
}
