-
Notifications
You must be signed in to change notification settings - Fork 4
/
119.latex
152 lines (127 loc) · 7.39 KB
/
119.latex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
\documentstyle{article}
\begin{document}
\begin{center}
\Large
{\bf Basic Libraries Report}
\end{center}
\normalsize
\begin{center}
Bob Payne, Mark Stupar\\
18 March 1992
\end{center}
{\it Basic Libraries} consist of the lowest level classes, sufficiently
general in scope to have utility for everyone. It includes portability
(wrappers for platform specific ideosyncracies), number crunching
({\it e.g.}, math oriented matrix classes), containers, low level
miscellaneous classes ({\it e.g.}, strings and complex), and exception
handling. Added to this is the task of recommending an existing graphics
package containing (at a minimum) both graphics primitives and drivers for
both {\tt X} windows and {\tt PostScript}, with {\tt CIC} specifically
mentioned as a candidate.
\section{Past Work}
Our approach has been to build on existing freeware and shareware rather
than just sitting down and coding everything from scratch.
Consequently, the bulk of our time to date has been spent in prowling
around anonymous ftp servers for source code, porting potentially useful
candidates to Charlottesville, and examining them in some detail.
Packages considered for adoption have also been compiled and tested
(though not extensively exercised).
In this manner, we've discarded most candidates, for a variety of reasons:
requires use of a commercial package such as {\tt Motif}; doesn't compile
by following the instructions, or with a managable amount of hacking;
doesn't look useful; looks like it will create as many problems as it
solves; etc.
We've also used this opportunity to compare the available compilers and
environments, and to obtain needed technical information ({\it e.g.}:
assessing the feasibility of compilers; determining the required setup
and mechanics of integrating FORTRAN subroutines into C++ classes;
comparing the implementation of various packages to determine good and
bad ways of doing things; accumulating classes which can profitably be
used in implementing {\tt AIPS++} classes, so as to avoid re-inventing
wheels; the considerations and proper implementation of shared libraries;
incorporating documentation in the code for use on-line).
This having been completed, we're up to speed and ready to proceed to the
next phase of the project: implementing the classes within the
responsibility of {\it Basic Libraries}.
The remainder of this report (1) makes specific recommendations regarding
the import of pre-existing graphics into {\tt AIPS++}, (2) briefly
discusses what classes will implemented by us in general terms, and
(3) discusses problems that may or will give us trouble. War stories,
regurgitations of experiences, and techno-minutiae are intentionally
omitted.
\section{Graphics}
We recommend that {\tt InterViews} be adopted. Indeed, it is the only
C++ package we have found that is feasible within the criteria specified,
and both {\tt InterViews} and the applications library distributed with it
offer immediate benefits to the {\it User Interface} group.
{\tt InterViews} is immediately usable by this project upon its adoption.
We have found nothing that offers similar benefits to the {\it Image
Handling} group. Of the packages we have examined, most offer some
image handling capability, but all are ancilliary to the purposes of
the packages of which they are a part, and are tailored to the needs of
those packages. The best course we can suggest is to pick and choose
among the available application packages, extracting those parts that are
of interest, with the intent of modifying and building upon the code that
is so borrowed. Feasible packages from which code can be borrowed
are {\tt CIC} and UNC's {\tt COOL}, as well as portions of {\tt MIRIAD}'s
{\tt MVX} ({\it e.g.}, palette manipulation, spreadsheeting, slice and
dice, as well as sundry other features).
We also suggest that {\tt PEX} (PHIGS+ Extended for X) be considered for
use for the sake of its 3D capabilities. QUALIFICATION: as it comes with
the {\tt X} distribution, it is intended that {\tt PEX} be installed under
the X11 tree, and any given site might have chosen not to install that
portion of {\tt X}. Use of {\tt PEX}, other than the simple borrowing of
code, requires the installation of {\tt PEX} at the site. While 3D
capability is not a criterion for {\tt AIPS++}, it should be advantageous
to have that capability for the future, and we have found no other package
that we can use towards this end. While its protocol is not fully
implemented, its shortcomings are all in 3D areas that do not impair its
utility to this project.
One graphics related issue seems to be in no specific group's area of
responsibility. We note the availability of {\tt WIP}, an existing package
for the generation of production quality image hardcopy. While it is
a part of {\tt MIRIAD}, it is completely standalone, aside from its use of
{\tt PGPLOT}. It currently reads {\tt MIRIAD} and {\tt FITS} formats, but
others can be added. The author (Jim Morgan, Maryland) is a member of
BIMA, and attended the OOD/C++ class in Charlottesville this past
January. The adoption of {\tt WIP}, modified to read {\tt AIPS++} data
format, gives this project an immediately available means of compositing
and annotating images.
Caveat: note that the as-is adoption of packages such as {\tt InterViews},
which does not have a class naming convention assuring uniquenesss across
different packages, precludes the use of like-named classes elsewhere within
{\tt AIPS++}.
\section{Basic Library Classes}
This is the area in which we expect to spend the remainder of our time
on this project. Work estimates will be no better than faked numbers
at present, but we are confident that we can implement the
{\it Basic Libraries} in the time remaining.
No package that we've found adequately serves the needs of this project,
and we are resigned to writing and tailoring classes for the particular
needs of {\tt AIPS++}. To this end, we will implement the classes with
{\tt AIPS++} functionality that are within the responsibility of this
group, relying on other groups to specify their needs to us. We've
assembled a number of packages from which code can be borrowed and
modified, and will use these to the extent possible.
The packages we expect to be most used by us are {\tt GNU libg++}
(particularly rich in functionality), {\tt TI COOL} (excellent docs and
it both complements and slightly overlaps {\tt libg++}), and
{\tt RWVector2.2} (interfaces to numerical FORTRAN subroutines). A number
of other packages are available for ad hoc borrowing (eg, from NIH) on an
anecdotal basis.
This in no way constrains the other groups of the project to read or
become familiar with any existing package, nor do we expect them to do
anything more than to tell us what they want ({\it i.e.}, the software
packages mentioned above are intended for use by {\it Basic Libraries} as
a means of avoiding the re-invention of wheels).
We'll provide lists and documents on what is available (to serve the
other groups as idea sources) and will begin work immediately on those
fundamental classes whose need is ``intuitively obvious''.
\section{Current Concerns and Problems}
We don't have the upgrade to Sun's C++ that allows parameterized
templates. The importance of the features available in this upgrade
cannot be overemphasized.
Practical exception handling as a generality is not available except for
trivially conceived circumstances (eg, divide by zero); its design would
be ad hoc and highly local in scope.
\end{document}