                      The Reduce "bin" directory
                      ==========================


The files in this directory are intended to provide an easy way to launch
Reduce. From the Reduce "trunk" you can just issue a command such as
             bin/redpsl
         or  bin/redcsl
to use the PSL or CSL version of Reduce (supposing that you have configured
and built it!).

There are some features of the scripts used here that may not at first seem
obvious, and so I will try to explain here what these features are trying
to achieve.

The first thing is that each script here can be invoked from anywhere - the
directory that is current when you trigger one of these scripts does not
matter. So, for instance, you can put this directory on your PATH and then use
Reduce freely. This remark may seem obvious, but the important aspect of it
is that these scripts identify directories where various Reduce resources are
to be found, and contain curious-looking code to do this. However you should
not copy any of these scripts and place them in a directory other than here
since they rely on paths relative to the place where they themselves live.

The second matter is that some people in some contexts have a single shared
file-space that they access from a variety of different models of computer.
The binaries that relate to different operating systems and computer
architectures have to be kept separate, and the main configure and build
scripts for Reduce achieve this by building binaries in sub-directories
with name such as pslbuild/i686-pc-windows or cslbuild/x84_64-unknown-suse11.1.
The scripts here automatically detect the nature on the machine that they are
being run on and on that basis link through and launch the relevant version
of the code.

Finally there is a matter of overhead. Detecting and decoding file locations
costs some effort. At one stage I had an elaborate scheme where the first time
a script was run it replaced itself with either a symbolic link or a shorter
script that invoked the program faster. Further investigation showed that the
relevant scripts were only seriously or uncomfortably slow on cygwin, and that
by re-working them I could make them fast enough that I am happy to go back to
the marginally simpler setup.

When I had this scheme that automatically updated scripts to match the current
machine I needed versions of the scripts that did not do that, and I gave then
names with a suffix "-s". Those scripts are now redundand and will be removed
sometime.

The file .../trunk/scripts/resetall.sh can be used to restore all these
scripts to their original state, and should be used before creating an
archive for distribution.

The programs provided for at present are

   redcsl        Reduce using the CSL Lisp system. Note that just calling
                 redcsl will probably cause a window to pop up, but
                 "redcsl -w" causes the code to run as a console application.
   redpsl        Reduce using the PSL Lisp system.
   redpslw       On Microsoft Windows this runs the PSL Reduce in a window

The following may be of use of CSL developers but are not intended to be
of general use to people who are not suffering problems or debugging new code:

   bootstrapreduce  A slower CSL version that is used while building the
                 full version, and where the function "lisp mapstore()" may
                 be used to collect profiling information.
   csl           The CSL Lisp system.
   fontdemo      tests or demonstrates the Maths fonts used here
   fwindemo      tests or demonstrates the user-interface aspect of CSL Reduce
   showmathdemo  tests or demonstrates maths display in the CSL version 


At present for the CSL versions there is one further complication. If an
exact match for your operating system can not be found in the set of installed
binaries then the first available "soft match" will be tried, with a message
displayed to explain. There is no clever arrangement to cause near matches
to be tested for in a special order. The idea behind this is so that eg if
you had binaries for say fedora 9 installed and were actually running a
different version of fedora (say 10) then the code will TRY the fedora 9
binary. But in this case it will not replace the script with a faster way
of accessing the potentially suspect version.


                                                     Arthur Norman. July 2009
