A database interface has been part of the original IRAF design since 1984, but was never implemented. Originally, the idea was that the DBIO interface would be used to maintain all datafiles, keywords in image headers, data tables and so on. In the original design this was practically an implementation of an entire RDBMS system within IRAF, something not needed today where we have database systems that can be accessed via a daemon (e.g. mysql, postgres) or can be self-contained in text file (e.g. SQLite and accessed via an API.

For those so inclined....

July 28, 2009 A new version of the GEMINI IRAF package is now available. This version, v1.10, requires at minimum IRAF 2.12.2a, but IRAF 2.14 is recommended. The package is now compatible with PyRAF as well as the CL environment. At this time, PyRAF is not required. For those who wish to use PyRAF, the mininum requirement is PyRAF v1.5 and stsci_python v2.6. Announcement available here

[Note: I'd originally intended to be more prolific about these topics, sorry. Please comment on any suggestions you have for ideas, otherwise I may expand the topics to some non-IRAF projects that might be of interest]

IRAF is inherently a multi-process system (i.e. even a simple script requires binaries for the CL and perhaps several packages) and has always had the ability to run background jobs, but users sometime wonder whether tasks can be made multi-threaded as a means of improving performance for highly data-parallel operations (e.g. mosaic image processing). The short answer is that it is possible, but only with some restructuring of the core system, and of course needed changes to applications to enable the threading.

See below for more .....

NFEXTERN is an external IRAF package designed specifically for the reduction of NEWFIRM (an IR mosaic camera) instrument data, but which is also useful for other IR and mosaic reductions. It includes updated tasks found in MSCRED as well as catalog tools found in the ACE package. The package is now available from the downloads area and the ftp archive at NOAO.

See below for more information, please report any problems or comments.

The Science Software Branch of the Space Telescope Science Institute wishes to announce the availability of version 3.10 of the Space Telescope Science Data Analysis Software (STSDAS). Concurrent with the STSDAS release, we have also released v3.10 of the TABLES external package. .....

Changelog and download details in the body of the story.

NUMBER: 572
MODULE: dotasks
SYSTEM: -V2.14
DATE: Tue Apr 28 11:19:41 MST 2009
FROM: valdes

BUG: It is likely that the DO tasks (e.g. doslit) will not work correctly if the input image names have a path. This is because internal database filenames are derived from the image names. The recommended action is to work in the data directory.

STATUS: Work on these and related tasks is currently frozen and since there is a basic workaround (working in the data directory) nothing may be done for some time.

A question that has often been asked over the years is whether IRAF would benefit from specialized hardware (e.g. the Altivec array processor on PPC systems) or high-performance compilers. The short answer is, it depends.

See below for further discussion .....

This is the inaugural message of a topic I hope to make a regular feature on this site. It is an excerpt from a paper recently written meant to inform the reader about various technical aspects of the IRAF system (we hope to also make this paper public in its entirety as well). Topics will cover a range of technical IRAF system matters with the hope of prompting discussion and questions. but will by no means be complete. Your comments and suggestions for future topics are encouraged.

IRAF Memory Usage

IRAF memory requirements are small by any measure; the system will happily process a Mosaic image on a machine with as little as 32MB of memory installed. This is due in large part to the fact that most tasks were written to process images in a line-by-line fashion rather than reading in an entire image, extensions of a mosaic MEF file are processed serially where possible. .....(read more below....)

NUMBER: 571
MODULE: IMAGES.IMUTIL.HSELECT
SYSTEM: V2.14
DATE: Fri Jan 2 21:41:53 MST 2009
FROM: fitz

BUG: The use of a '$' in a field name was causing the 'missing' value to always be printed even if the field exists in the image. This was caused by a failure to check for the character and removing it prior to getting the value from the header. There is no workaround, the code change is trivial.

STATUS: Fixed for the next release.

It was 3 years ago today that iraf.net officially took over user support for our users, and the site has grown considerably since then: In 2008, we had over 75,000 unique visitors, served more than a million pages from the site, served an avg of 157 iraf-help-pages/day from the banner bar, transferred enough bandwidth for hundreds of full IRAF systems, answered many hundreds of user questions, and we are approaching 1200 registered users. 2009 has the potential for significant (and 'official') IRAF development, let's all hope for better budgets in the coming year.

Thanks again to all of you who use this site, and especially to those who regularly contribute to truly make it a community forum.