Mercurial > hg > octave-nkf
changeset 11399:36dbe5124d21
Remove obsolete documentation files SENDING-PATCHES and README.Cray
author | Rik <octave@nomad.inbox5.com> |
---|---|
date | Mon, 20 Dec 2010 14:59:41 -0800 |
parents | f1a4db353da5 |
children | 277d891afae2 |
files | ChangeLog Makefile.am README.Cray SENDING-PATCHES |
diffstat | 4 files changed, 4 insertions(+), 177 deletions(-) [+] |
line wrap: on
line diff
--- 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.