June 24, 2019

Grinder - Viva la Revolucion!

Can the oven software be "liberated" from IRAF? Should it be? As always, the answer is maybe. Let's look first at some reasons why, then look at how.

The why could be given as the undertain future of IRAF, along with the claim that the software will be more maintainable, if not more transparent, if it could be run as plain old compiled C on a unix/linux platform. Using the IRAF encapsulated software on linux will generate FITS files by default, which is highly desirable in any event. The next step would be to write those same files without the help of IRAF.

IRAF has value for visualization and plotting. I would suggest that ograph and odisp would be retained "as-is" whatever the case. As long as the FITS file format remains unchanged and the shared memory database stays the same this should be no problem. Alternate visualization tools independent of IRAF could be written as desired as a final step in this process.

Some goals and steps in the process:

Tackle the "oven" program first

This is the bulk of the code at any event. The first step is just to get it to compile cleanly with a standard Makefile, using only the files that are actually necessary.

It was fairly easy to modify oven.h to yield a proper compile with a 64 bit compiler (longs and pointers yield the mischief). This is cleaned up with typdefs in oven.h. Another 64 bit issue was the time() system call, which wants to produced 64 bit objects with the standard library, this led to some simple code changes.

Introducing the "curses" library was done by adding a console.c layer that maps calls either to curses or the IRAF terminal library calls. All IRAF specific calls in domenu.c were moved to console.c and all such calls are now named "con_xxx". Some of these calls were to SPP routines and a few have yet to be implemented in the curses environment.

Some unpleasant debugging ensued when the Makefile was incomplete and did not fully rebuild everything when oven.h was revised to be proper on a 64 bit system. This was tracked down, and now "make clean; make" will yield a proper recompile of the entire package.

The file "protos.h" was introduced to hold ANSI prototypes. The "cproto" utility makes this easy and less error prone.


Have any comments? Questions? Drop me a line!

Tom's home page / tom@mmto.org