--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2010-12-20  Rik  <octave@nomad.inbox5.com>
+
+	* README.Cray, SENDING-PATCHES, Makefile.am: Remove obsolete files.
+
 2010-12-18  Rik  <octave@nomad.inbox5.com>
 
 	* NEWS: Deprecate sphcat and spvcat functions.

--- a/Makefile.am
+++ b/Makefile.am
@@ -48,7 +48,6 @@
   README.Windows \
   README.kpathsea \
   ROADMAP \
-  SENDING-PATCHES \
   autogen.sh \
   bootstrap \
   bootstrap.conf \

deleted file mode 100644
--- a/README.Cray
+++ /dev/null
@@ -1,150 +0,0 @@
-It should now be possible to compile and link Octave on the Cray SV1
-and perhaps other similar Cray systems using the following procedure.
-It even runs and seems to work, at least for the few small things I
-tried.
-
-  * Run
-
-      configure \
-	F77=ftn FFLAGS="-dp -O0" \
-	CC=cc CFLAGS=-O0 CXX=CC \
-	CXXFLAGS="-O0 -h new_for_init -h nomessage=76" \
-	--without-blas --without-lapack --disable-readline
-
-    The last to arguments tell Octave to use the reference blas and
-    lapack implementation in Fortran and to not require the readline
-    library.  If you have the readline library, you can omit the last
-    option.  You can also try to use a vendor library for LAPACK and
-    BLAS, but how are those compiled?  You will need a version of the
-    library that is compiled for 64-bit double precision values, but
-    that uses the D and Z names (I'm not sure that this is the case
-    with the Cray libraries).
-
-    I'm using -O0 in an effort to speed up compilation.  If you want
-    an optimized version and have time to wait for the build to
-    complete, then use whatever -On option you like.
-
-  * Edit the generated Makeconf file and make sure that you have
-
-      FFLAGS = -dp -O0
-      CFLAGS = -O0
-      CXXFLAGS = -O0 -h new_for_init -h nomessage=76
-      FPICFLAG =
-      CPICFLAG =
-      CXXPICFLAG =
-
-    The first three should be handled automatically by the configure
-    arguments, but the others are not (yet).
-
-  * Edit liboctave/data-conv.h and force the definitions of
-    TWO_BYTE_INT and FOUR_BYTE_INT to be int.  These will have to be
-    fixed correctly later, but this fix will allow Octave to compile
-    and even run, though some things like saving and loading data with
-    some binary file formats will be broken.  Suggestions for a good
-    way to fix this are welcome.
-
-  * If building from CVS, you will need to have gperf installed, or
-    you can generate src/oct-gperf.h on some other machine and copy to
-    the src subdirectory in the Cray build tree.
-
-  * If you don't have TeX installed on your SV1, then edit the
-    generated octMakefile and remove doc from the SUBDIRS variable so
-    you won't try to run make in the doc subdirectory.  Otherwise, it
-    will fail because you don't have TeX installed (and why would
-    you?).  This is only a problem when building from CVS or if you
-    build from a distribution and configure with something other than
-    --prefix=/usr/local.
-
-  * Run
-
-      gmake -k omit_deps=true
-
-    and it should run all the way to creating an octave executable
-    (see below for why omit_deps=true is needed).
-
-
-REMAINING PROBLEMS
-------------------
-
-  * I tried to get dependency generation to work, but it seems there is
-    a bug in the C++ compiler because it keeps crashing with errors like
-    this:
-
-      making pathsearch.d from pathsearch.cc
-      CC-1353 CC: INTERNAL File = CColVector.cc, Line = 38
-
-	#include "oct-cmplx.h"
-			      ^
-
-      CC-2202 CC: ERROR
-	"/opt/ctl/CC_sv1/CC_sv1/lib/ccom" (pid 69504) was terminated
-         due to receipt of signal 06:  Abort (core dumped).
-
-    when I try to use the -M option.  Dependency generation is
-    relatively slow, so maybe it would be worth trying to speed it up
-    by using a simpler tool.  We are currently using the compilers to
-    build lists of dependencies that include system header files, but
-    maybe it would be good enough if we only listed the header files
-    that are included with the Octave sources.  In that case, we could
-    probably write a simple script that could do the job and that
-    could run much faster than the compiler.
-
-  * IEEE Inf and NaN (and Octave's NA value, which is a particular NaN
-    value) are all currently set to DBL_MAX since the SV1 doesn't
-    support IEEE floating point numbers.  Will this be true of future
-    machines from Cray?  I don't think it is possible to have a fully
-    functional version of Octave (or Matlab) on a system without IEEE
-    numbers.
-
-  * TWO_BYTE_INT and FOUR_BYTE_INT types, mostly used in load-save.cc.
-    This can probably be solved by using arrays of char values and
-    some masking, but it will probably be a bit tricky.  The problem
-    is that various binary data file formats are specified using
-    integer values of specific sizes, so we need to be able to read
-    and write integer values in 16 and 32 bit formats.
-
-  * The code in liboctave/mach-info.cc that determines the floating
-    point format used by the system assumes that a double is exactly
-    twice as wide as an int.  This should be fixed, since the Cray has
-
-      sizeof (char)   == 1
-      sizeof (short)  == 8
-      sizeof (int)    == 8
-      sizeof (long)   == 8
-      sizeof (double) == 8
-
-    For now, I forced the floating point format based on an #ifdef CRAY.
-
-  * Build a working readline library.  Probably not too hard but I
-    didn't think it was worth the effort yet.  I can't run Octave
-    interactively on the SV1 I have access to anyway, so command line
-    editing doesn't matter much.
-
-  * Build the FFTW library for better fft performance.  Without this,
-    we still have fft and ifft functions using FFTPACK.
-
-  * Build the HDF5 library to support loading and saving of HDF
-    files.  This is not necessary unless you need to access Octave
-    data files that have been stored in the HDF file format.
-
-  * Link with fast BLAS and LAPACK libraries for better performance.
-    There is a Cray library, but I'm not sure whether we can use it
-    directly.  Does DGEMM in the Cray BLAS library use double
-    precision, or is it compiled with the equivalent of -dp?  If it
-    uses double precision (i.e., 128-bit floating point values) then
-    it will take some work to make this functional for Octave, since
-    Octave uses the D and Z names and we would presumably need the S
-    and C names instead.
-
-  * Shared libraries.  Apparently this is not supported on the SV1, so
-    dynamically linked functions (.oct files) will not work on this
-    system.
-
-  * There are a few warnings when compiling glob/glob.c that should
-    probably be fixed.
-
-
-John W. Eaton
-jwe@octave.org
-
-Last updated: Wed Dec 17 15:17:29 2003

deleted file mode 100644
--- a/SENDING-PATCHES
+++ /dev/null
@@ -1,26 +0,0 @@
-[This was originally from Richard Stallman who was writing about
- Emacs.  --jwe]
-
-A reminder for those sending patches for Octave:
-
-  * Always make the diffs with context.  Preferably use diff -c.  It
-    is unreliable to install a diff without context, and therefore we
-    probably will not take the risk of trying; instead we will
-    probably ask you to send a context diff.  You might as well send
-    that in your first message.
-
-  * Always send change log entries with your patches.  Itemize the
-    entries so that they list each of the functions and variables
-    changed.  Look at the ChangeLog files and follow our conventions
-    regarding what information to include and what style to use.
-
-  * If the patch is to fix a bug, send a detailed bug report for the
-    bug.  Make this just as detailed as if you did not have any fix
-    for it.  This information is vital for convincing the maintainer
-    that your fix is necessary and should be installed.  Also, if your
-    fix would cause some other sort of problem, the bug report may
-    enable the maintainer to find some other correct fix.
-
-Everyone, please read the Bugs chapter in the Octave manual to see
-other guidelines on how to write a bug report that makes it possible
-to fix a bug.