IRAF V2.15-ALPHA Release Notes March 16, 2010 These notes provide a summary of the major changes in the V2.15 release. V2.15 includes a number of bugfixes and new tasks, but is primarily a platform-support release to add support for 64-bit Linux and OSX systems. V2.15-ALPHA is an Alpha release of the IRAF V2.15 system. As such, this release is made with known problems in the system (detailed below) and with the expectation that other problems will be uncovered. It also means this release does NOT contain the final feature set or documentation we plan for the V2.15 release, these will be incorporated in updates to follow. A future Beta release will be closer to what we expect the final V2.15 system to include and will provide an opportunity to test those features. This release is intended to allow real-world user testing of the system, specifically to exercise the science code that could not be extensively tested during the upgrade and port process. It also provides an opportunity for developers to begin upgrading external package code to work with 64-bit platforms. More detailed technical documentation of all system changes will be found in the 'notes.v215' file in the iraf$local directory, detailed revisions notes for each application package are in the package directories in a file called Revisions, e.g. onedspec$Revisions. Please see also the 'v215revs.txt' file in this directory for a complete description of the V2.14.1 release. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Contents: ========= 1. V2.15 Upgrade/Installation Instructions - Upgrading External Packages - Mixed 64-bit IRAF and 32-bit External Packages 2. Highlights of This Release 3. Platform Support 4. Core IRAF Revisions Summary - New Tasks - Existing tasks with new parameters/defaults - Existing tasks with new capabilities 5. NOAO Package Revisions Summary - New NOAO Package Tasks - Existing tasks with new parameters/defaults - Existing tasks with new capabilities 6. Bug Logs Fixed by This Release ============================================================================ 1. V2.15 Installation Instructions ============================================================================ IRAF V2.15 is a major release and will require a new installation, there is no upgrade from earlier releases. This is, in part, due to some architecture name changes, and in part due to new installation procedures. To install this release, you should download the binary distribution file appropriate for your machine (either linux or osx) and then identify yourself as one of the following users and follow the steps described: - I am installing for the First Time: 1) Create an 'iraf' directory (preferrably /iraf/iraf) and unpack the distro file there 2) Define $iraf in your environment 3) Run the $iraf/unix/hlib/install script to install the system - I am replacing an existing IRAF installation: 1) Save any local configuration file (graphcap, extern.pkg, etc) of the existing IRAF installation to a separate directory 2) Delete the existing IRAF tree 3) Unpack the distribution in the existing iraf root directory 4) Replace/merge local configuration files - I am installing multiple IRAF versions: 1) Create a new 'iraf' root directory and unpack the distro file 2) Define $iraf in your environment to be the full path to the IRAF system you wish to be the system-wide default. If this is the existing iraf installation you can skip this step, to make the v215-ALPHA the default you'll redefine $iraf and run the install script. 3) Set $iraf and $IRAFARCH in your environment as appropriate before running the 'cl' command or compiling software. - I want to build the IRAF system from source: 1) Download the iraf_v215-src.tar.gz source-only distribution 2) Create a new iraf root directory and unpack the distro 3) Define $iraf in your environment 4) Run the $iraf/unix/hlib/install script to install the system 5) Configure the directory tree for the proper architecture and compile, e.g. on a 64-bit linux system: % cd /iraf/iraf % setenv iraf /iraf/iraf/ <-- trailing '/' required % setenv IRAFARCH linux64 % make linux64 % make sysgen In future versions this process will be made more robust and automatic, the above steps should compile the core system, NOAO and TABLES packages. We recommend if possible that a dedicated machine be used for testing to avoid possible confusion with a dual-version system. Note that while environment variables can typically be used to control which version of IRAF is started, these same environment variables when defined in startup files such as .login or .cshrc can cause confusion when building software. Installation questions may be directed to the forums at http://iraf.net Upgrading External Packages --------------------------- The v215-ALPHA release contains source code tarballs for some 30 external packages that have had preliminary checks/modifications for 64-bit compatibility. These releases should be considered preliminary updates until the responsible authors have had an opportunity to examine and approve the changes. One major package currently missing is STSDAS due to its size, other major packages such as MSCRED need to be examined by their authors and re-released officially. The distribution directory will be updated as needed with binaries and new versions of source trees during the test period. Mixed 64-bit IRAF and 32-bit External Packages ---------------------------------------------- On 64-bit systems it is possible to still use 32-bit external package binaries (e.g. for packages that haven't been updated yet), however care must be taken to match the architecture names. For example, on Linux systems the arch name is 'linux64' and this will be used to find binaries in external packages as well. For packages such as STSDAS where no 'bin.linux64' binaries are available, you can simply use the 32-bit binaries by making a 'bin.linux64' symlink that points to the 'bin.linux' directory. ============================================================================ 2. Highlights of This Release: ============================================================================ o 64-bit Platform Support o New MEMIO Interface The MEMIO interface was necessarily changed to accomodate the 64-bit upgrade, specifically we added extra structure to a memory object to aid in debugging (e.g. sentinal values before/after a segment, a reporting mechanism etc). This adds a slight bit of overhead to each heap memory allocation but we consider this to be minor given the capabilities of today's systems. o Single 'linux' Architecture for 32-bit Systems This is part of the overall architecture changes implemented in v2.15 systems. The original logic for separate 'suse', 'redhat' and 'linux' architectures was due to differences between these platforms in the GCC/Glibc systems used which were inherently incompatibile. These differences have since become irrelevant and impose a support burden to maintain and so a common 'linux' architecture is now preferred. Because external packages may lag in the changes needed to switch architectures, we try to support legacy references to e.g. 'redhat' as an alias to the new 'linux' structure and hope that the previous deprecation of 'suse' has now been removed entirely. Since 64-bit support requires a new architecture name there will be no confusion between the 32- and 64-bit versions of the system. o Mac OSX Architecture Changes In previous IRAF releases the 'macintel' archicture was used for all OSX versions running on Intel hardware, and 'macosx' was reserved for PowerPC (PPC) CPUs. In order to avoid yet another IRAF architecture name to distinguish 64 and 32-bit Intel systems, and because OSX systems are moving generally towards Intel CPUs with 64-bit capabilities anyway, that future IRAF systems should favor 64-bit architectures as users migrate to new hardware. What this means is that starting with v2.15 the IRAF 'macintel' architecture will refer exclusively to 64-bit Intel hardware. In order to retain compatibility with older systems, the 'macosx' IRAF architecture will encompass 32-bit binaries for both PPC and Intel CPUs in a Universal binary format. This is a departure from past platform architecture naming conventions where a new unique name is used, however future MacOSX systems will all be Intel-based and hardware will be 64-bit capable so shifting the focus to 'macintel' being the primary platform and 'macosx' supporting older systems makes the most sense. (In hindsight we would have preferred to be able to use 'macosx' as it is more descriptive). o 32-bit Mac Universal Binaries The 'macosx' architecture now includes both PPC and Intel binaries in the system libraries (and those produced for external packages) and executables. These binaries are compatible for OSX 10.4 and later systems and the system will automatically use the appropriate binary for the hardware (e.g. on an OSX 10.4 PowerPC machine the PPC binary for the 'macosx' arch will execute the PPC binary in the iraf executable file). While earlier IRAF versions would allow that PPC 'macosx' binaries could be run on Intel systems using the Rosetta sytem, this isn't currently allowed with v2.15 as an Intel system would automatically use the Intel binary. Thus, to test PPC binaries you will need a machine with a PPC CPU. This is seen as something that would affect a minimal number of users. o Compile-Time VOS/Kernel Prototype Checking All library code in the IRAF 'Virtual Operating Interface' (VOS) and IRAF Kernal (i.e. the $iraf/unix//os procedures) now have function prototypes that are checked during compilation of any SPP code. o Intra-Package Prototype Checking This is a feature that will be added in the near future and will provide the same level of prototype checking as with the core system libraries. The idea is that a 'libpkg.a' will produce a local prototype file that ensures all calls within the package meet the prototype calls. As with VOS/Kernel checking, this will validate the code within a package to trap any potential errors. o All C Library Code Converted to Clean ANSI-C As part of the 64-bit port, all C library code in the VOS and kernel was converted from the old-style "K&R" style to true ANSI C with full function prototypes. Additionally, the code was cleaned up to remove any warnings generated by the compiler, i.e. compilation with "-Wall" under GCC now compiles cleanly to further ensure the integrity of the code. o Cross-Compilation of Architectures Compilation is now defined by the user environment rather than the machine used to do the build, as before. What this means is that (within reason) it is now possible to cross-compile for a different IRAF architecture on machines which support such compilation. For instance, on a 64-bit Mac OSX Snow Leopard system (where the native IRAF architecture is 'macintel') one can now compile code for the 32-bit 'macosx' architecture (either PPC or Intel) by simply setting the 'IRAFARCH' environment varable as 'macosx' and reconfiguring the system/package approriately. The same is true for Linux 64-bit systems and 'linux64' and 'linux' architectures, meaning one doesn't need access to machines to produce binaries. Compilation flags are set auomatically based on the IRAFARCH variable in order to produce the desired binaries. o User-Selectable Architectures As with compilation, the IRAFARCH variable can be used to determine which binaries to run. For example, on a 64-bit Linux system (where the default arch would be 'linux64') the commands % setenv IRAFARCH linux % cl would allow a user to run the 32-bit 'linux' binaries and thus switch easily between systems to compare results and validate the science results of a reduction/analysis task. The same is true for Mac (Intel) systems where the 64-bit macintel and 32-bit macosx architectures could be selected by the user. o SVG Graphics Device for Better Web Presentation of Plots SVG graphics are an XML format supported by many modern browsers that permit scalable graphics for web presentation. This means that plots produced by IRAF may be used in web pages without loss of resolution or aliasing effects seen when using e.g. GIF images of a plot. A new 'g-svg' graphcap device was added to make use of this new driver. It produces a file called 'sgiXXXX.svg' in the current working directory (where 'XXXX' is a process id) and may be used as e.g. cl> contour dev$pix dev=g-svg or in cursor mode with a ":.snap g-svg". Either instance should be followed with a 'gflush' or ':.gflush' to flush to output to disk. SVG files can be embedded into HTML documents with the tag, the tag, or the