Commit 8565ec00 authored by Robert P. Goldman's avatar Robert P. Goldman
Browse files

Fixed orphaned section header.

The title for section 4 was orphaned at the bottom of a column, away from
its body.  I fixed this by adding a newpage and then had to trim a bunch of
odd words here and there downstream to get back the one line pushed onto
page 16.
parent a3b9cb96
......@@ -214,6 +214,7 @@ suggestions for future improvements to {\ASDF}, and a brief conclusion.
\input{upgrade}
\pagebreak[4]
\section{Interface Modifications}
\subsection{Objectives and limitations}
......@@ -352,7 +353,7 @@ so using logical pathnames simply
replaces one hairy problem with another even hairier.
A common strategy using {\ASDFi} was to minimize
the amount of changes required to the \lisp{asdf:*central-registry*}
changes required to the \lisp{asdf:*central-registry*}
by setting up ``link farms.''
A single directory, the link farm, would be added to the registry, and
that directory would hold the actual state of the configuration,
......@@ -1201,7 +1202,7 @@ has many features that {\ASDF} doesn't have and could not be evolved to have,
including a deterministic build model, cross-compilation,
and enforcement of declared dependencies.
On the other hand, XCVB requires {\CL} software to be adapted
to its different build specification format and
to its build specification format and
its slightly stricter build constraints,
and it doesn't currently support as many target platforms as does {\ASDF}.
Development of XCVB is ongoing, but from the simple one-paragraph idea
......@@ -1213,7 +1214,7 @@ and some others as well,
from the fine semantics of UNIX signals
to distinctions between host and target system
that appear in cross-compilation.
On the other hand, XCVB has the advantages of clean slate redesign on its side.
On the other hand, XCVB has the advantage of clean slate redesign on its side.
\paragraph{Yale tools}
\label{sec:ytools}
......@@ -1382,7 +1383,7 @@ especially if we were to choose to add nested steps to {\ASDF} plans.
%Some interested developers might also consider making the operations
%\lisp{TEST-OP} and \lisp{DOC-OP} first class citizens.
More modest extensions would include
More modest extensions include
adding new standard operations and components to {\ASDF}.
There have been calls to add a \lisp{doc-op},
whose purpose would be to build documentation for a system.
......@@ -1399,10 +1400,10 @@ does not provide a standard return value.\footnote{
to raise an error and abort on the first failure;
typically one wants a report of all passing and failing tests.}
One component type that has been repeatedly added by system definers
(and often in a buggy way) is that of a ``load-only'' {\CL} source file.
This is a file that is to be directly loaded and \emph{never} compiled.
(and often in a buggy way) is a ``load-only'' {\CL} source file.
This is a file that is to be loaded but \emph{never} compiled.
Previous system defining facilities, including
{\mkdefsys}~\cite{kantrowitz:91}, have included such a component type.
{\mkdefsys}~\cite{kantrowitz:91}, have included such components.
%Finally, and perhaps simultaneously most important and least appealing is
%improving the {\ASDF} documentation.
......@@ -1410,7 +1411,7 @@ Perhaps the most valuable extension one could make would be
to improve {\ASDF}'s documentation.
We have begun this project, but have
not done the thorough, end-to-end rewrite that is needed.
Documentation is a pain to write, and it is still a weakness of {\ASDFii}.
%Documentation is a pain to write, and it is still a weakness of {\ASDFii}.
A particular need in this area is to clearly document
the {\ASDF} protocols for operations and components.
{\ASDF} claims to be extensible through its use of {\CLOS},
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment