Free addendum software for linux

mod_include is a post processing of SSI variables, Apache module.

Doesnt sound too helpful ? Well, maybe not, but I found that during construction of this site that I was frequently replicating 5 lines of text with only a single word altered (the left menu). This was both inefficient and awkward to debug, and didnt lend itself to keeping a common look and feel for the site as a whole. This extension allows large blocks of text to be stored as a variable, and for the small changable part to be altered just before the result is displayed.

Whats wrong with set anyway ?

When a variable is used in the value entry of a set command the system searches for the current value of the variable and substitutes it immediately. This fixes the value of the variable created so that it never changes, which is good for some applications, but lousy for dynamic content.

Usage

This module is an extension of the normal Apache behaviour, and should be read as an addendum to the basic mod_include commands.

define

This command sets up a variable in the same way as the set directive, except that any variable names used are not parsed at this time, but stored as names until displayed with the macro directive.

var

The name of the variable (macro) to define.

value

The value of the variable (macro).

macro

This command will expand a previously defined variable and replace any instances of the variable named in var in the variable def with the value given in value. Note that like other mod_include commands, the order of the variables is important, and should be declared in the sequence shown below:

var

The name of the variable to replace inside the macro.

value

The value to replace the variable with.

def

The previously defined macro to seach through.

PDL::IO::FITS Perl module offers a simple FITS support for PDL.

SYNOPSIS

use PDL;
use PDL::IO::FITS;

$a = rfits(foo.fits); # read a FITS file
$a->wfits(bar.fits); # write a FITS file

This module provides basic FITS support for PDL, in the sense of reading and writing whole FITS files. (For more complex operations, such as prefiltering rows out of tables or performing operations on the FITS file in-place on disk), you can use the Astro::FITS::CFITSIO module that is available on CPAN.

Basic FITS image files are supported, along with BINTABLE and IMAGE extensions. ASCII Table support is planned, as are the HEASARC bintable extensions that are recommended in the 1999 FITS standard.

Table support is based on hashes and named columns, rather than the less convenient (but slightly more congruent) technique of perl lists of numbered columns.

The principle interface routines are rfits and wfits, for reading and writing respectively. FITS headers are returned as perl hashes or (if the module is present) Astro::FITS::Header objects that are tied to perl hashes.

Astro::FITS::Header objects provide convenient access through the tied hash interface, but also allow you to control the card structure in more detail using a separate method interface; see the Astro::FITS::Header documentation for details.

FUNCTIONS

rfits()

Simple piddle FITS reader.

$pdl = rfits(file.fits); # Read a simple FITS image

Suffix magic:

$pdl = rfits(file.fits.gz); # Read a file with gunzip(1)
$pdl = rfits(file.fits.Z); # Read a file with uncompress(1)

$pdl = rfits(file.fits[2]); # Read 2nd extension
$pdl = rfits(file.fits.gz[3]); # Read 3rd extension
@pdls = rfits(file.fits); # Read primary data and extensions

$hdr = rfits(file.fits,{data=>0}); # Options hash changes behavior

In list context, rfits reads the primary image and all possible extensions, returning them in the same order that they occurred in the file. In scalar context, the default is to read the primary HDU. One can read other HDUs by using the [n] syntax, the second one is [1]. Currently recognized extensions are IMAGE and BINTABLE. (See the addendum on EXTENSIONS for details).

rfits accepts several options that may be passed in as a hash ref if desired:
bscale (default=1)

Determines whether the data are linearly scaled using the BSCALE/BZERO keywords in the FITS header. To read in the exact data values in the file, set this to 0.

data (default=1)

Determines whether to read the data, or just the header. If you set this to 0, you will get back the FITS header rather than the data themselves. (Note that the header is normally returned as the hdr field of the returned PDL; this causes it to be returned as a hash ref directly.)

hdrcpy (default=0)

Determines whether the hdrcpy flag is set in the returned PDL. Setting the flag will cause an explicit deep copy of the header whenever you use the returned PDL in an arithmetic or slicing operation. That is useful in many circumstances but also causes a hit in speed.

FITS image headers are stored in the output PDL and can be retrieved with hdr or gethdr. The hdrcpy flag of the PDL is set so that the header is copied to derived piddles by default. (This is inefficient if you are planning to do lots of small operations on the data; clear the flag with "->hcpy(0)" or via the options hash if thats the case.)

The header is a hash whose keys are the keywords in the FITS header. If you have the "Astro::FITS::Header" module installed, the header is actually a tied hash to a FITS header object, which can give you more control over card order, comment fields, and variable types. (see Astro::FITS::Header for details).
The header keywords are converted to uppercase per the FITS standard. Access is case-insensitive on the perl side, provided that Astro::FITS::Header is installed.

If Astro::FITS::Header is not installed, then a built-in legacy parser is used to generate the header hash. Keyword-associated comments in the headers are stored under the hash key < keyword >_COMMENT >. All HISTORY cards in the header are collected into a single multiline string stored in the HISTORY key. All COMMENT cards are similarly collected under the COMMENT key.