Welcome to iraf.net Friday, April 19 2024 @ 01:01 PM GMT
IRAF V2.15.1a Release Now Available
- Monday, November 22 2010 @ 11:24 PM GMT
- Contributed by: fitz
- Views: 3,335
The release of the IRAF V2.15 system (featuring 64-bit platform support) is now available from NOAO. This release covers both 32- and 64-bit Linux and Mac OSX systems (Intel and PPC) and is now recommended for all users and developers. Modified sources for some 30 external packages which have been ported to 64-bit are also available from the FTP archive extern directory. Support for additional platforms and updated external package distributions will be made available in the coming weeks.
IRAF v2.15 is now distributed as a single-file download for each supported platform. Installation is now just a matter of unpacking this single tarfile and executing the iraf install script. Similarly, v2.15 also features a new external package mechanism to automate the download and installation of packages. A full list of features and changes is detailed in the Release Notes.
IRAF v2.15 Distribution Files:This release include a unified linux architecture suitable for all 32-bit Linux distributions. Similarly, the macosx architecture is now a Universal (Intel and PPC) 32-bit distribution. On 64-bit linux platforms the architecture name is linux64, the macintel architecture name now refers explicitly to 64-bit OSX (Intel). Despite the architecture name changes, older external packages can continue to be used (see the README or 64-bit Port Guide for details).
Please contact us or post questions to the support forums with any problems or questions you may have.
Update 1/26/11: An IRAF v2.15.1 Patch is now available, see story below for details.
Update 1/27/11: Exernal package repository now linkec against v2.15.1
Update 2/21/11: An IRAF v2.15.1a Patch release is now available, see story below for details. All external package releases are now linked against this version of the system for all platforms.
IRAF V2.15 Release Notes
November 22, 2010
Revised February 24, 2011
These notes provide a summary of the major changes in the V2.15
release. IRAF V2.15 is a major release of the IRAF system for all supported
platforms. The main feature of this release is support for 64-bit Linux and
Mac OSX systems, although there are numerous other enhancements as well.
Because changes to the system interfaces were fairly substantial, and
extended test release was made available to the community to gather feedback
about potential problems in the science code. There were only a few reported
problems and we now consider the system to be stable for general release and
recommended for all users.
More detailed technical documentation of all system changes will
be found in the 'notes.v214' 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
'sysnotes.v215' file in this directory for a detailed list of the V2.15
changes, and similar files for the detailed revisions of each patch.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Contents:
=========
1. V2.15 Upgrade/Installation Instructions
- Single-File Downloads
- Building IRAF From Source
- External Package Management
o Getting Started
o Installing and Updating Packages
o How it Works
o Repositories
o Server-Side Repository Description
- Mixed 64-bit IRAF and 32-bit External Packages
- External Package Changes in v2.15
- External Packages -- They're Not All The Same, Anymore
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 path from earlier releases. This is, in part, due to
some architecture name changes, and in part due to new installation
procedures. This applies only to the core IRAF system, existing external
packages may continue to be used (after proper installation) however we
generally recommend that packages be updated in this release as well.
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 distribution file for your platform there.
2) Define $iraf in your environment (with a trailing '/')
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 distribution
file for the host platform
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 the default you'll redefine $iraf and run
the install script
3) Set $iraf and $IRAFARCH in your environment as appropriate for
the desired version before running the 'cl' command or compiling
software
- I want to build the IRAF system from source:
1) Download the iraf-src.tar.gz (or as.pcix.gen.gz) source-only
distribution file
2) Create a new iraf root directory and unpack the distro
3) Define $iraf, $IRAFARCH in your environment and source the
$iraf/unix/hlib/irafuser.csh script. Note a C-shell is required
for this step
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/ and
iraf$noao/bin. directory. Note there are combined Linux
(iraf-linux.tar.gz) and OSX (iraf-osx.tar.gz) distribution files
as well as a single distribution that includes all supported
binaries (iraf-all.tar.gz)
3) Define $iraf in your environment (with a trailing '/')
4) Run the $iraf/unix/hlib/install script to install the system
We recommend if possible that a dedicated machine be used for testing
to avoid possible confusion with a multi-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.
---------------------
Single-File Downloads
---------------------
This release introduces a change in the distribution model used for
IRAF. Specifically, we recognize the majority of users will be running on
single-user machines such as personal laptops or desktop systems (the
earlier distribution model was based on the idea of a central server
supporting many client machines). As such, the need for separate source
and binary distributions and a separation of these in the directory
hierarchy is now unnecessarily complicated for most users. While the
previous form of the distribution files are still available, the preferred
method is to use the single-file distributions. All distribution files
include full source, differences are in which binaries are also included.
These distribution files are as follows:
iraf-src.tar.gz Source-only distribution
iraf-all.tar.gz All support binary platforms
iraf-linux.tar.gz Combined 32/64-bit Linux distribution
iraf-macosx.tar.gz Combined 32/64-bit Mac OSX distribution
iraf.lnux.x86.tar.gz 32-bit 'linux' architecture
iraf.lnux.x86_64.tar.gz 64-bit 'linux64' architecture
iraf.macosx.uni.tar.gz 32-bit 'macosx' architecture (Universal Intel/PPC)
iraf.macosx.x86_64.tar.gz 64-bit 'macintel' architecture (Intel only)
All that is required for a complete IRAF installation is to download one of
the above files and unpack in the desired iraf root directory before running
the hlib$install script.
-------------------------
Building IRAF From Source
-------------------------
For source-only distributions, v2.15 includes a toplevel Makefile that
automates the system build process. For example,
% mkdir -p /iraf/iraf # create iraf root dir
% cd /iraf/iraf # go there
% tar zxf /path/iraf-src.tar.gz # unpack source tarball
% setenv iraf /iraf/iraf/ # trailing '/' required
% setenv IRAFARCH # set platform architecture
% source $iraf/unix/hlib/irafuser.csh # pick up other env definitions
% $iraf/unix/hlib/install # run the install script
% make # configure system architecture
% make sysgen # build the system
While building the system from source is not required for most users, it
is now much simpler. Where this new 'make' capabiity may be useful is in
the case of user support recommending a code change to fix a bug and a
recompile of the system is needed. This process is now just a matter of
% setenv iraf /iraf/iraf/ # trailing '/' required
% setenv IRAFARCH # set platform architecture
% make # configure system architecture
% make update # update the system
This process is now the same whether there is an indivual application
change, or a system interface change that affects all tasks needing
relinking.
---------------------------
External Package Management
---------------------------
Dynamic package loading is a new feature in v2.15 that allows for
package directories created in the iraf$extern directory to be automatically
defined when the CL is started. The means that external package installation
no longer *requires* that the hlib$extern.pkg file be edited to define the
package, although that remains an option for packages which somehow cannot
conform to this new scheme.
Getting Started
---------------
The IRAF v2.15 system is shipped with no defined external packages,
instead we assume packages will be installed using this new feature. To
begin, simply execute the 'configure' script in this directory to create
the files needed. For example,
% ./configure
This will create a local 'manifest' file of packages available form
the IRAF reposistory and iraf.noao.edu and skeleton directories of
available packages will be created automatically along with a Makefile
used to do the actual installation. THIS STEP IS REQUIRED BEFORE PACKAGE
INSTALLATION!
To get a listing of packages that can be installed, or to check
which installed packages might need to be updated or are newly available,
use the command:
% make check
Each listed package may then be installed using a simple 'make' command.
For packages not on the list, a manual install is still required.
The external package tree may be initialize to the distribution state
using the command:
% make init
Updates to the distribution mechanism itself is done using the command:
% make self_update
This last command is used to update the system to new features or bug fixes
that might be available as the mechanism evolves.
Installing and Updating Packages
--------------------------------
External packages may now be installed with a command such as:
% make ctio mscred stsdas
Note that dependency packages for each requested package will automatically
be added to the installation so you do not need to necessarily list every
package (e.g. you'll get FITSUTIL automatically by installing MSCRED,
TABLES for STSDAS, etc). The next time you login to the CL the requested
package will be defined.
To update packages to the latest version at any time, use the command
% make update
The information about available packages will be updated, then a comparison
of the timestamps of your installed packages with those on the repository
will be made. If newer package versions are available they will be updated
(along with dependencies) automatically.
If a binary repository distribution of a package is not available
at the moment, a 'source only' distribution will be installed and you will
note a "[SOURCE ONLY]' status from the make command. The user is then
responsible for compiling the packages locally even though the package will
still be defined for use (but unusable). Our goal is to provide a binary
distribution for all available packages we can reasonably support. Script-
only packages will be installed and available for all platforms.
How it Works
------------
This scheme relies on IRAF v2.15 changes to the CL login process to
scan this directory for packages, as well as a server-side respository of
distribution files suited for this method (see below). The 'configure'
script customizes the package information for your platform and creates a
'Makefile' based on that information. Subsequent commands update these
files, however we don't yet provide an automated system for multi-platform
support. Multi-platform packages may be installed by setting the IRAFARCH
environment variable to the desired architecture before issuing a 'make'
command to install the package.
The bulk of the work is done using utility scripts found in the iraf@util
directory and called from the iraf$extern/Makefile. The management of the
repository files is the responsibility of the distribution maintainers (by
default, NOAO). Please contact us if you wish to have your package added to
this repository system.
Repositories
------------
The default package repository is defined in the $iraf/util/pkgrepo
script and may be changed to point to a local respository (e.g. a mirror
site). It may also be changed by pointing the 'IRAF_REPO' environment
variable to a new URI source, e.g.
setenv IRAF_REPO "ftp://localhost/myrepository"
Of course, a network connection is assumed to exist in all cases. Local
repositories may be preferred for faster local access via mirrors, please
contact us for information on creating one.
Server-Side Repository Description
----------------------------------
[The following comes from the README file on the repository]
This is the IRAF v2.15 distribution repository directory. Files
here are bundled so as to allow them to operate with the dynamic
package mechanism or IRAF install procedurs for v2.15. Aside from
the repository files themselves, this directory contains
README This file
REPO.DESC A description of each package
MK Utility script to update repo checksum/manifest
CHECKSUM Checksums files on repo tarballs created by MK
REPO.MANIFEST Manifest file
The MK script is used to generate the CHECKSUMS file and REPO.MANIFEST
file automatically, it should be run whenever a package is installed
or updated. The REPO.DESC file is a handcrafted description of the
available package, this is important to describing the dependencies
of each package. The MK script is also capable of determining
which of the available packages may be used on which platform.
For example, a "redhat" package will suffice for both a linux64
and linux IRAF system if there is no specific version available.
The manifest file created will then list the redhat version as the
file to be installed for the linux/linux64 platforms.
If a binary distribution for a particular package is not provided,
the MK script will default to use the source distribution tarball
(if available). On the receiving end the user will then have the
option of compiling the package locally. The reserved name
"universal" is used for script-only packages, or distributions
containing binaries for all supported platforms.
When packages are installed in the IRAF dynamic package tree,
both the REPO.MANIFEST and REPO.DESC files are downloaded. Scripts
use these files to build up package lists that are available for a
particular platform, as well as which packages are required to be
installed to support the requested package. We assume the REPO.DESC
file lists full dependencies, e.g. if A requires B, and B requires
C the the dependency list for A is both B and C.
The convention for file names is as follows:
-.tar.gz
where is the package name and is the iraf architecture.
For external packages, tarfiles are build at the toplevel, i.e.
when unpacked, a subdirectory of the package is created in th current
directory. For IRAF distributions we violate this rule and assume the
tarball is built from the $iraf root directory.
When installing a new package, the REPO.DESC file should be edited and
the MK script should be run.
When installing an update to an existing repo package, or a new
architecture version of a package, the MK script should be re-run.
----------------------------------------------
Mixed 64-bit IRAF and 32-bit External Packages
----------------------------------------------
In some cases, external packages can or will not be ported to 64-bit
systems or otherwise updated with a new release, however IRAF v2.15 is very
forgiving in the way that is allows multiple architectures to be used. For
example, where the core system architecture might be 'linux64', external
packages containing only the 32-bit 'linux' or older 'redhat' bin
directories will be used automatically when a native 'linux64' binary
cannot be found. The same is true for mixing the macintel and macosx
architectures.
Especially for 64-bit platforms we recommend users re-install external
packages to get the latest version, however simply using an existing
directory tree of packages that are defined in the hlib$extern.pkg file
should continue to work as with all earlier IRAF releases.
---------------------------------
External Package Changes in v2.15
---------------------------------
Support for 64-bit systems required changes to applications code that
includes tasks in external packages. In many cases, these changes were
trivial to make, in other cases it was realized that some external packages
have either become redundant with core system tools, or are otherwise now
obsolete. Because there are now source-code incompatabilities between
v2.15 and earlier systems (specifically, a package modified for v2.15 might
not compile on an earlier system), a new directory of v2.15 external
packages was created to remove from distribution those packages that are no
longer required, to release updated versions of supported packages that are
now 64-bit enabled, and to re-bundle distribution files of packages
maintained by outside sites that can be installed by the new package
manager.
A summary of the major changes to distributed v2.15 packages follows:
COLOR Package is now part of v2.15 PROTO package without change.
Need for external version is obsolete.
FITSUTIL The NHEDIT task was removed and moved to the GMISC extpkg.
This task has a different parameter interface than the version
installed in v2.14 and the FITSUTIL version is only required
for GEMINI package support. Moving this task to GMISC
satisfied the GEMINI requirement and avoids conflicts caused
by FITSUTIL in other packages. Package otherwise now
compatible with v2.15.
GEMINI Gemini has requested their package be removed from the v2.15
distribution system. We have no reason to believe this
package is incompatible with IRAF v2.15 or other external
package changes introduced in this release.
GMISC Now includes the version of NHEDIT from an earlier FITSUTIL
package version. This package will be mad eobsolete in a
future IRAF release.
MFILTERS All tasks are already included the core system. This package
should no longer be listed as a dependency by other packages.
NMISC All tasks are already included the core system. This package
should no longer be listed as a dependency by other packages.
STECF Distribution updated to last v1.5 release.
STSDAS STScI has issued a statement about their plans for 64-bit
support at
http://www.stsci.edu/resources/software_hardware/stsdas/iraf64
Until/when a newer STSDAS package is available, the latest
release of this package will continue to function under v2.15.
TABLES TABLES was a required package for building core IRAF as well
as several external packages. Thanks to the cooperation of
STScI, the 'tbtables' library and TTOOLS tasks in this package
are now part of the v2.15 system and satisfy these external
requirements. Future TABLES releases will likely follow the
model outlined above for STSDAS 64-bit support, however NOAO
has now assumed primary responsibility for tbtables/TTOOLS
platform support in v2.15 and beyond.
The TABLES code in the core system is now essentially
frozen except for bug fixes. To avoid conflicts with an
existing TABLES installation, the TABLES.TTOOLS package tasks
are installed as an NTTOOLS package in the UTIITIES package.
For the moment, TABLES v3.12 and IRAF v2.15 UTILITIES.NTTOOLS
are essentially the same code base, and since the TABLES code
hasn't been updated in a while, there is some measure of
backward-compatability with earlier TABLES versions even
when using IRAF v2.15 and there is some confusion about which
package currently is loaded.
VOL Package is now part of v2.15 PROTO package without change.
Need for external version is obsolete.
In some cases there is no actual update of a package we distribute
other than how the tar file is created (e.g. for script-only packages or
re-packaging of packages developed by non-NOAO sites). While it may not
always be possible to relink locally-developed packages against v2.15,
neither is it required for these packages to continue to be used. A
package which include binaries compatible on a v2.14 or earlier system can
be declared for use in v2.15 without needing to be recompiled. Obviously,
on 64-bit systems these packages will continue to run in 32-bit mode,
developers are urged to review the 64-bit Porting Guide for information on
how to update this code.
------------------------------------------------------
External Packages -- They're Not All The Same, Anymore
-------------------------------------------------------
IRAF 64-bit support requires code changes, and in some cases NOAO has
no actual control over what is supported by external developers, in other
cases packages have limited usage in the community and don't automatically
deserve the same level of support as more active packages. This leads to a
stratification of external package support given our limited resources and
our development model that an IRAF port do as much as possible to "bring
along" external code to a new platform/release. IRAF v2.15 was designed to
allow continued use of older package code whenever possible.
Packages are now classified (in terms of how much support they'll receive)
in an ad-hoc manner as follows:
ACTIVE NOAO assumes responsibility for the package code and
will update as needed for continued platform support.
Examples include FITSUTIL, MSCRED, and NFEXTERN. An
ACTIVE package might also include older code that is
no longer being maintained by the original developers,
but so long as it is trivial to build on supported IRAF
platforms, can be built as a supported distribution.
Examples include CTIO, RGO, MEM0 and XDIMSUM.
UNIVERSAL Script-only packages require no specific platform
support. Future releases will be checked for parameter
changes, but otherwise we assume these packages work for
all platforms. Examples include ESOWFI and CFH12K.
DEPRECATED Existing packages which will be supported on platforms
where the code compiles easily, however no extraordinary
measures will be taken to provide binaries for all
IRAF v2.15+ platforms. Examples include EUV and IUE.
OBSOLETE These include packages no longer required to be external
to the core system because tasks have already been included
in the core release. If a re-issue of the package is
required to expose new features this will become an
ACTIVE package, otherwise these packages will no longer
be available in the v2.15 release system. Examples include
DIGIPHOTX, MFILTERS, and RVX.
EXTERNAL These are packages actively maintained by non-NOAO
institutions, often with their own release schedule and
priorities. While we'll try to provide binary distrib-
utions built from standard sources for the convenience
of our users, we cannot offer direct support for applic-
ations or support for 64-bit systems (due to code changes
and testing required). Distribution binaries built for
these packages will be unchanged, additional binaries
we buid will be shared-risk, and we will refer questions
to the developers for assistance when needed. Examples
include STSDAS/TABLES, GEMINI and RVSAO.
Developers who wish to include their packages in the IRAF v2.15 code
repository system are encouraged to contact us to simplify installation for
users. Likewise, code we now describe as 'obsolete' can be added to the
repository upon request.
============================================================================
2. Highlights of This Release:
============================================================================
o 64-bit Platform Binary Support
Linux and Mac OSX systems running 64-bit operating systems are
now supported in native 64-bit binary mode. There are currently
NO plans to support 64-bit versions of other operating systems
(e.g. Windows, Solaris, or FreeBSD).
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. A suite of environment variables
can now also be set to manage/monitor this new interface (see below).
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 that were inherently
incompatibile. These differences have since become irrelevant
and now impose a burden to support and maintain separate platforms,
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 (in v2.14) of 'suse' has now been
removed entirely. Since 64-bit support requires a new architecture
name (i.e. 'linux' versus 'linux64') there will be no confusion
between the 32- and 64-bit versions of systems.
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, we decided that future IRAF systems
will favor 64-bit Intel architectures as users upgrade machines.
What this means is that starting with v2.15, the IRAF
'macintel' architecture will now 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 made the most sense. (In
hindsight, we would have preferred to be able to use 'macosx' as
being more descriptive).
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 32-bit 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 tag.
o Simplified Build From Source
At the request of users, a toplevel 'Makefile' is now available
for building or configuring the system with a single command. This
Makefile is a simple driver for scripts that do all the work
using conventional IRAF commands. Allowed 'make' command targets
include:
all alias for 'update'
sysgen do a complete sysgen
update update system since last sysgen
updatex update with debugging flags enabled
src clean system of current binaries
clean clean system of current binaries
pristine clean system of all binaries
noao compile the NOAO package
summary print core/noao/tables spool file summaries
showarch show currently configure arch
reconfigure for named architecture
o Simplified Download/Install Process
See the Single-File Installation description above.
o Simplified External Package Installation
See the External Package description above.
o COLOR and VOL packages now part of Core System
Both the COLOR and VOL external packages have been incorporated
into the PROTO package. These packages are no longer being
developed but are required by some users so will continue to be
supported as prototype software.
o Improved Documentation
Thanks to Jason Quinn, the help pages for dozens of tasks have been
cleaned of long-standing typo and formatting errors. In many cases
Jason's suggestions have also served to clarify the meaning of the
text, or correct the help wrt to how to task actually operates.
============================================================================
3. Platform Support:
============================================================================
IRAF V2.15 supports only the following platforms:
PC-IRAF - supports RedHat 9 thru Fedora/RHEL/Centos (LNUX)
- supports Mac OS X 10.4 and higher (ppc and intel) (MACX)
- supports Debian 3.1 and higher (LNUX)
(The following platforms are planned but not yet available:)
- supports FreeBSD 6.3 and higher (FBSD)
- supports Solaris 10 (x86) (SSOL)
- supports Cygwin (Windows XP and Vista) (CYGW)
Sun/IRAF - supports SunOS 4.1 (SOS4)
- supports Solaris 5.5.1 thru Solaris 10 (SSUN)
Note that PC platforms not mentioned here specifically may still be
supported by one or more of the distributions (e.g. Ubuntu can use LNUX).
============================================================================
4. CORE IRAF REVISIONS SUMMARY
============================================================================
This section describes changes to tasks in the IRAF core system
other than routine bug fixes.
New Tasks
---------
images.imcoords:
hpctran - Convert between HEALPix row and spherical coordinate
proto:
mkglbhdr - Make global header from keywords in images and reference
system:
bench - Demonstration benchmark task
Existing Tasks with New Parameters or New Parameter Defaults
------------------------------------------------------------
images.imfit.fit1d
Adds new 'bpm' bad pixel mask parameter
images.imutil.nhedit
A 'rename' parameter switch was added to renaming a keyword.
Existing Tasks with New Capabilities
------------------------------------
images.immatch.imcombine
New 'quadrature' and 'nmodel' options to the 'combine' parameter
are used for error propagation either with input sigma images
(quadrature) or where the pixel sigmas may be computed by the
noise model used by this task (nmodel).
==============================================================================
5. NOAO PACKAGE REVISIONS SUMMARY
==============================================================================
This section describes changes to tasks in the NOAO package tasks
other than routine bug fixes.
New NOAO Package Tasks
----------------------
noao.nproto:
skygroup - Group a list containing RA and Dec into spatial sublists
skysep - Compute arc separation of two RA/Dec values
Existing Packages and Tasks with New Parameters or New Parameter Defaults
-------------------------------------------------------------------------
artdata.mkpattern
Added 'long' to allowed list of data types.
onedspec.specplot
Added new 'transform' parameter to allow scaling the spectrum
pixel values. Currently only 'log' is implemented.
twodspec.apextract.apall
Changed default for 'maxsep from 1000 to 100000.
Existing Tasks with New Capabilities
------------------------------------
astcat.agetcat
Added usnob1@usno, usnoa2@usno, nomad@usno and act@usno
imred.doecslit
imred.doefoe
imred.doslit
Changed the default maxsep from 1000 to 100000. Unless users reset
the default their expectation is that marking apertures will not
skip an aperture number no matter how far apart the aperturers are.
fibers.skysub.cl
Added 'sum' as an enumerated "combine" choice.
nproto.skysep
Added an 'enum' to the 'raunit' param to enforce choices.
obsutil.sptime
Made all graphs auto-scale. Added a "generic" disperser type to
force using the desired wavelength and dispersion without defining
a grating whose mapping between position on the detector and wave-
length might be wrong.
twodspec.apextract
The 's' key now works on the current aperture rather than the nearest.
==============================================================================
6. BUG LOGS FIXED BY THIS RELEASE
==============================================================================
The following buglog entries are fixed by the this V2.15 release:
NUMBER: 567
MODULE: apall, apedit
SYSTEM: V2.11-V2.14.1
DATE: Tue Oct 7 10:53:14 MST 2008
FROM: valdes
BUG: The :parameters and :apertures commands cause the task to exit with
an error that parameter "apertures" isn't found. This problem has
existed for a long time due to a missing parameter in the hidden
parameter sets.
STATUS: Fixed for the next release.
NUMBER: 568
MODULE: imcombine
SYSTEM: -V2.14.1
DATE: Tue Oct 7 12:52:35 MST 2008
FROM: valdes
BUG: When using avsigclip, ccdclip, or sigclip rejection around the
median (mclip=yes) the resulting final median may be incorrect.
This will generally only occur if unusually small low sigma values,
such as lsigma=1, are used. This was due to using a wrong
variable.
STATUS: This is fixed for the next release.
NUMBER: 570
MODULE: imexpr, mskexpr, or tasks other asks using the expression evaluator
SYSTEM: -V2.14.1
DATE: Mon Nov 3 22:16:41 MST 2008
FROM: valdes
BUG: Use of the built-in functions mod, min, max, and median produce an
"incompatible types" error even though the types of the arguments are
correct. This is a due to a coding error. There is no workaround
other than using alternative ways to express the desired
expression.
STATUS: Fixed for the next release.
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.
NUMBER: 573
MODULE: mscimage
SYSTEM: - V4.9 August, 2008
DATE: Fri Sep 18 08:36:30 MST 2009
FROM: valdes (discovered and diagosed by Thomas de Boer)
BUG: The task ignores the parameters "boundary" and "blank" which are
fixed to be "constant" and "0." respectively.
STATUS: This is fixed for the next release.
The following comments are owned by whomever posted them. This site is not responsible for what they say.
- 2nd "64-bit Port Guide" link in the news text is missing 'D'. It links to PORT.GUIE
- Where is iraf_v215-src.tar.gz ?
Thanks for your time, N::addition of a 'src' and combined-binary distribution files
later today (there'll be new links on the homepage), the
repository files and docs are being polished as well.
cheers, Jim
binary (will run on 64-bit). There've also been some
recent posts about this suggesting how to make a symlink
to resolve the library, e.g.
https://iraf.net/phpBB2/viewtopic.php?t=90517
ftp://iraf.noao.edu/iraf/v215/support
for each platform that was linked against the '-lncurses'
library instead of the older '-ltermcap' lib that should
hopefully fix this problem. There are still issues with
building a static version of the binary, however if you
want one a 32-bit linux static binary is available at
https://iraf.net/pub/fitz/ecl.e
If you still have problems with shared libs in the above
binaries please post back.
---
Rob Steele (Robert.D.Steele@jpl.nasa.gov)
Not yet, it'll be in the next round of platform releases.
Also, there are no plans (or means) to support 64-bit on
Cygwin (32-bit XP is still the baseline system used to build
the release).
---
Rob Steele (Robert.D.Steele@jpl.nasa.gov)
the next few months as time permits. Cygwin is not a
major platform for us.