Getting Started Documentation Glish Learn More Programming Contact Us
Version 1.9 Build 1556
News FAQ
Search Home

NOTE 220 - AIPS++ SYSTEM PLAN

Ger van Diepen

26 September 1999

A (gzipped) postscript version of this note is available (21kB).

Contents

Introduction

The purpose of this document is to sketch the developments needed and envisaged in the system area. It gives the dependencies of AIPS++ on its environment (e.g. compilers, standards) and how they may change in the future.

The priorities for the AIPS++ project are:

Current system

AIPS++ can be executed on any UNIX system with X-windows. It has proven to run under SUN Solaris, HP-UX, Linux, SGI/Irix, and Digital Unix on a variety of machines. It requires little extra software. The public domain package Tcl/Tk is needed for the graphical interface provided by glish. Netscape is needed for browsing the documentation.

Developing in AIPS++ requires much more software, all of it available in the public domain area. The following software is needed:

The offical project C++ compiler is egcs 1.1.2, which works fine for all supported UNIX platforms. GNU and egcs have merged again, so the newest g++ compiler is 2.95, which will be adopted in the future by the AIPS++ consortium. New compilers are often based on the EDG front-end. Ports to the KAI and SGI compilers, based on EDG, are mostly completed.
The C++ code is quite heavily templated. Templates are explicitly instantiated, because automatic instantiation led to excessive link times.
AIPS++ has some Fortran77 code, which can be compiled with g77 or a commercial Fortran compiler.

In October 1999 the first release of AIPS++ was distributed on CDs, which contain executables, libraries, documentation, and source code. It is possible to get updates via ftp.
Sites actively developing AIPS++ can obtain and update a development version via ftp.

Future developments

C++ standard and Compilers

C++ has now an official ANSI/ISO standard. Several new possibilities in the C++ standard are already used in AIPS++.

Some other options are of interest and might be used in the future.

The AIPS++ consortium sites use the products purify, purecoverage, and quantify to check the code thoroughly. Unfortunately Rational only supports egcs 1.0.3 for these products. Therefore only those C++ constructs can be used that are supported by egcs 1.0.3 or can easily be emulated.

Porting to Windows NT

A port to Windows NT is underway as part of the parallellization efforts at NCSA to use AIPS++ on an NT cluster. Apart from that it is foreseen that NT will be an important platform. It raises the problems how to map the UNIX and X11 functionality to Windows NT.
Windows NT has the POSIX standard implemented, but when using it the Win32 API cannot be used anymore. This limitation is not acceptable.

AIPS++ uses several UNIX system and library calls. The most important are file handling, pipes, sockets, time, environment variables. X11 is used heavily in aipsview. It is also used in the Display Library, but the class structure is such that it should be easy to use classes dedicated to NT.

There are a few public domain and commercially available packages being able to aid in a port. Amongst them are:

When doing the port it has to be decided what is the best way to go. There are a few scenario's possible.

A possible porting strategy could be:
1.
Handle parts of the basic library not dependent on UNIX or X11.
2.
Handle UNIX-dependent library code.
3.
Handle glish. Tcl/Tk has already been ported to Windows NT, so the glish graphics should not be a problem.
4.
The final step is porting X11-dependent code.
It has to be decided if and which porting tools will be used. Using Win32 calls directly results in best performance, but tools make the porting easier.

As soon as code development will be done on Windows NT, a code management system (integrated with the UNIX side) and a build system should also work on it.

Code Management

The current configuration, code management, and build system has a few problems: It has to be investigated whether current subsystems have to be replaced by other packages (public domain or commercial).

Another problem is the size of the libaips library. It is already quite large and will get twice as large once the trial code is moved to aips. It requires that the aips package is split into a few subpackages. A requirement is that they are layered and that a lower level layer is not dependent on a higher level layer. This may be hard for DO implementations which tend to use a lot of classes.
Splitting the library can be done in a simple way by having a few packages at the aips level. A more fundamental approach is to have a subpackage layer under aips. That makes it possible that other packages (nrao, dish) are split in subpackages.

An extra directory level could also be useful in the apps tree. One can think of an application group (with maybe some common source files) and in subdirectories the individual applications.

Shared libraries and dynamically loadable code are used to make dynamically configurable code possible. The glishtk part of glish is relying on shared libraries.
Some experiments have been done with using shared libraries to reduce the size of the system. So far they have not been successful, because too many seldomly used code got linked into the shared libraries. Also the use of static variables gave problems. After splitting the libraries another attempt can be done.

Documentation

The current user documentation system, based on latex and latex2html, is fragile and hard to configure. It needs to be stabilized. At the moment Kate Weatherall and Wes Young are investigating other methods like SGML-based systems..

Care should be taken that no latex constructs are used which are not (yet) supported by latex2html. Having to do very frequent latex2html updates can be a pain for some users.

It should regularly be checked if the search facility for the AIPS++ html pages is selective enough.

The code documentation system is based on the Perl script cxx2html which extracts declarations and comments (with special tags) from the header files. It is doing a very good job, but needs some changes to make nicer html output.

Release support

On a regular base AIPS++ releases are done on CD. In October 1999 the first release was done. Users can get updates via ftp. In order the reduce ftp traffic a mechanism is needed to make the updates selective, i.e. that only the parts needed are ftp-ed. It would also be nice if the dependencies are such that linking a program is based on changes in the source code and not on changes in a library. In that way a program is only linked when really needed, thus also ftp-ed when really needed.

Support of industry standards

There are several industry standards which are of use to AIPS++. It has to be decided if and how they are supported in AIPS++.

Priorities for system

After the release in October 1999 two formal releases are foreseen until the end of 2000. The last release is meant to be used by any programmer who likes to develop code using AIPS++ classes.

Before the next release the following needs to be done:

1.
Implement data proposal of Wim Brouw.
2.
Improve using native exceptions. To prevent memory leaks, all variables on the heap should be put into an AutoPtr object until their pointer is taken over.
3.
Split the library into some layered subpackages.
4.
Build shared libraries from the lowest layers. Static variables sometimes cause problems, so we should try to get rid of them.
5.
Improve the stability of the documentation system.
6.
Improve cxx2html.
7.
Have a better dependency analysis to link based on source code changes instead of library changes.

Before the following release:

1.
Use threads in DO's to make them non-blocking. It requires that static data is thread-safe.
2.
Port to Windows NT.
3.
See if automatic template instantiation can be used. This is needed when heavily templated classes in Blitz++ or STL are going to be used.
4.
Replace some of our classes by classes from the C++ Standard Library. Candidates are String, Complex, Map, Block. Other classes like valarray should also be looked at.
5.
Use Blitz++ or techniques used in it to speed up the Array arithmetic.
6.
Investigate how CORBA, DCOM, OLE, XML, ODMG, and Java can be used.

next up previous home.gif
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-10-15