AnalyRIM Files

See the section below "BUILDING AnalyRIM" for build and install
instructions.

This is AnalyRim, spreadsheet/dbms, rebuilt for Linux.
Written by Glenn C. Everhart, from 1982 to 2022 (with long hiatus
prior to 2015).
  Note: analylinuxwrk.zip contains binaries, sources, and documents
for this program. Everything is there. Also analylinux-and-cygwin.zip
contains everything. You don't need to download more than one.

Full documents are in .txt files (mostly) and cover things like the
database, FFTs, goalseeking, matrix math, multiple regressions, doing
graphics (with Gnuplot, but another tool is being worked on again that
also does plots), as well as the many standard and financial functions
and features. Each cell can have one or more formulae, internal or run from
external command files, with ranges supported in rows, columns, or a third
dimension ("depth"). The design (from 1982) is not identical to anyone's
commercial spreadsheet but the program is fast and powerful.

Updates: 
Fixed column onscreen display to omit leading spaces in column names
Fixed some file open problems so e.g., a permission fail in opening a new file
will not crash the spreadsheet
Pivot type commands now are standard
Added more sources of auxiliary functions that can be incorporated.
Added more docs
Added sources for graphing file that compiles now; testing in the works.

Added many more document files, so pretty much everything is now
described somewhere. Also got multi-dimensional code back in, updated
Windows build (using Cygwin), cleaned up escape sequence and mouse
handling, wrote summary of addressing modes for cells, made display sheet
mapping max size configurable by one simple include file, added "analyticalc"
command that takes care of terminal settings and cleanup. Began work on
getting graphics via GHASP cleaned up again. Gnuplot interface seems ok
as long as gnuplot is present.

COPYRIGHT MATTERS (i.e., use freely, copy freely etc.)

When this was written it was common to put copyright notices on files
but give them away freely for free use.

Since that is less common now, note:
Notwithstanding any copyright notices in the AnalyRIM code,
it may be used and copied and distributed freely, according to
either the BSD license or the GPL V2 license or the LGPL V2 license
or the MIT license, whatever the user prefers. 

I ask only that those who alter the code (especially if they fix any bugs)
share their alterations back with me, Glenn C. Everhart. I can be reached
at gce@gce.com. I also ask that derivative works give credit to me as well
for what is contributed here.

Glenn C. Everhart
November 2015
January 2019


More Commentary:

Many text files of documents are included in the zip. Have a look at them; the
built in help (commands H0 thru H9) covers only a little of the functions.

This spreadsheet was written in 1982. If you are aware of the history of these
things you will realize that the IBM PC was introduced only in 1981, and
there were only a few spreadsheet programs around at that time. Also, back
then, Fortran was "the universal assembler". That is, it was the main language
for portability then. C became widely available on non-unix systems later, and
at that time if you were not in an educational institution, Unix cost something
like $40,000 from AT&T. There was no GCC then, though there were some C compilers
you could buy. In this background I decided to write in Fortran.

In that era too, most all fullscreen applications used terminals with escape
sequences. AnalyRIM does that too.

I had seen a couple demos of spreadsheets on other systems. VisiCalc had been
written but ran only on Apple II, and there were a few spreadsheets on CP/M.
I had access to a pdp11 and the F4P compiler (which was fairly decent, as
opposed to the junky "MOP" (midnight optimized Polish) compiler DEC had
used on DOS-11). I had not then had actual use of any spreadsheet, just saw
a few demos of the idea. The pdp11 ran RSX11M, a very nice multitasking exec
with a frighteningly capable linker, which enabled me to get it all to fit in
a 64KB address space by dint of 5 or 6 cotrees and as I recall something order
of magnitude 150 leaves. I loved moving to VMS where everything just built
flat and changing a line in one function didn't mean I had to redo the entire
overlay scheme. In MSDOS, I got it to work with overlays too, but there were
only a couple cotrees and many fewer leaves (and 256KB of address space).
You are looking here at a bit of history. 

To allow displays to be made alterable, the program defined two abstractions:
the "physical" sheet, on which all calculations and so on ran, and the "display"
sheet which is what gets viewed (or partly viewed) on the screen. The display
sheet is a mapping to parts of the physical sheet, so that regions or even
every displayed cell can be separately pointed at the physical sheet locations
where they come from. Also, commands to enter anything into the program tend
to be read as lines of text. Thus you use "E 1234.56789" to enter 1234.56789 in
the cell the cursor is pointed to, rather than just typing the number or
formula. This has been somewhat amended by an "enter mostly" mode which will
accept numbers directly, usable when it is possible to read data without waiting
for a line terminator. In Linux you can use stty raw noecho to achieve this,
and in other systems it was possible to do it also. The line oriented input
method still works though. It also facilitates writing input scripts which
can set up spreadsheets. The initial command letter(s) make it clear what is
being done.

The function names are common, coming from computer languages mostly. The
calculator program used to do computation has accumulators named A,B,C,D,...Z
available, though, and some functions use these to return results. For
example the MAX[arglist] function returns the maximum value of the cells in
the arglist (a range). However, it also returns the column and row of the cell
that has this maximum value in two of the accumulators. There is also an
address mode for cells that allows you to refer to a cell by these coordinates
or to go to that cell.

Each cell has 108 characters for its contents, which can be one or more formulae
or numbers (separated by \). Looping within a cell is possible. Calculation of
a sheet is always a raster scan, L to R, top to bottom, so you can predict
what accumulators might do left over from previous cells. Note though that
there is an attempt not to recompute values of numbers once they are known. You
can force recomputation but normally will not need to.

Cells can be addressed in a large variety of modes. They can be addressed by
name (R23 or some such), by their offsets from physical sheet locations
(P#offset#offset), their offsets on the display sheet (D#offset#offset) which
follows the mapping to physical sheet to get data but refers to offsets on
the display sheet. There is a multi-dimensional form allowing up to ~200 dimensions
for addressing, a form using 2 accumulators to address column and row using values
in those accumulators, and formulas can be relocated when copying cells with
relocation. There is an override which lets you tell the system not to relocate
a cell name ($L$200 would be L200 with relocation disabled for both column (L) and
row (200).)

See the documents to get an idea what goes on. Also, there is a very brief
help system. The commands H0 thru H9 show some of the commands and functions
available, from within the sheet.

AnalyRIM is called this because it also incorporates the RIM relational database
and can use it for storage. There are lots of functions to do database things
within the sheet.

Originally this program was named VisiKludge, ViziKludge, later PortaCalc, 
later AnalytiCalc, and later AnalyRIM. 

BUILDING AnalyRIM:

To compile and build
* Copy main directory of the zip file into a directory somewhere.
* use the script
makanaly.sh
(i.e., type ./makanaly.sh)

then do:
cp analy /usr/local/bin/analy.bin
cp analy /usr/local/bin/analy
cp analyticalc /usr/local/bin
chmod 755 /usr/local/bin/analy*
# set up help files that get driven off aux keypad keys
mkdir /DK
chmod 755 /DK
cp dk.tar /DK
chmod 755 /DK/*
chmod 755 /DK
cd /DK
tar xvf dk.tar
chmod 755 /DK/*

(Note these scripts are still being worked on. You can run them by @/DK/AKAB.CMD or
the like but function key parsing is being worked on Linux. This all ran OK on vms,
rsx, sunOS etc. though for SunOS I used xmodmap to generate escape sequences. In
Linux it is still giving me trouble. Sorry, won't last. Since it's been something
like 30 years since I worked on this, please forgive some senior moments. :-)
# Now everything should work. To run analyrim, type "analyticalc" in a terminal window.
# Note the aux keypad keys are expected to generate VT100 key sequences to drive this stuff
# and I don't know fully if xterm or whatever terminal emulator you use gets these right. If
# you have trouble you can try another terminal program. Each file that is in the /DK directory
# is read when the corresponding function key is pressed, and is just an analyticalc command
# file. The manual goes into how such commands are defined.


To run just run "analy".
(Copy analy to /usr/local/bin/analy.bin, copy "analyticalc" to
/usr/local/bin, and use the command "analyticalc" to enable all the
fancier escape sequence handling. You can just use the command
"analy" but arrow keys will work funny (or semi-not work) in that
case.)

Note that this works in Linux terminals.
It expects various .cmd files to be in a directory ~/DK/ so it can
use them as keypad inputs.

Documents (*.doc) are actually TEXT files, not Microsoft Word or any other
heathen formats. The .rno file is Runoff input for the main manual, but there
is a file analyticalc.doc which is output from runoff from approximately this
input file. Other .doc files talk about additional add-ons to the program over
the years.

The program uses commands 1,2,3,4 for arrow keys left, right, up, down.
At this point I have not figured how to get the Linux terminal driver to
terminate reads of escape sequences. Code in analy.for in routine ttyin
tries to do this but the fget() call may not be terminating without a
line terminator. Still debugging this.

Setting the terminal "raw" with stty allows characters to get sent, and
things work that way. What you need to do is
stty -echo raw   (or stty -echo -canon) 
then run analyticalc;typing "analy" at this point will do it.

The "analyticalc" script is just a short script that does this.
HOWEVER I note that getting F keys to generate escape sequences, or getting
keypad keys to do this, seems not to work well. There are some xterm control modes
that seem to have some effect, and there is some logic to attempt to let
Analyticalc parse whatever comes out, but I don't have things all matched up
yet. You can give commands like @/DK/cellreg.cmd to do things like copy a single
cell to a region (relocating), and this can be done with any of the .CMD or .cmd
files in /DK/ (or of course anywhere else). But the pretty keypad pictures and
easier use requires getting escape sequences generated, interpreted, and having
the right named files to match what Analticalc gins up from the escape sequence
characters.
Analyticalc is set up to work with CSI characters using 7 or 8 bits, but
while it tries to turn on the VT100 modes to use keypad sequences, this is not
currently working too well.

The build presumes gfortran to be present and installed but I do not
believe that cinterface.c is needed any more with this version. That
program tries to use curses() to work with linux. It used to work on Amiga
and Unix (sunOS) but for some reason the open function is not able to
connect to the window.

Note: build is:
gcc -x f77 -c -std=legacy -funsigned-char -w -O0 -fno-underscoring -fdollars-in-identifiers analy-i4cellno_color.for
gfortran analy-i4cellno_color
mv a.out analy
cp analy /usr/local/bin
cp analy /usr/local/bin/analy.bin
cp analyticalc /usr/local/bin

Do this more easily by just typing
./makanalyi4.sh  (to also copy to /usr/local/bin)
or
./makanaly.sh    (to just compile and link)


untar dk.tar in /DK/
 (ensure material in /DK is world readable.)

Note too that the help file is stored there (pcchelp.hlp). Intent was that F2 should
call help screen.

Not everything has been rechecked in this environment. AnalyRim is pretty elaborate
and not a clone of anything. There are lots of cells, but there is a "physical" 
spreadsheet, i.e., the actual sheet, and a "display" sheet which is a mapping of
the display onto the physical sheet. This mapping is controlled by lots of commands
and can be customized down to the individual cell. There are also LOADS of addressing
modes for cells, by names, offsets, etc., in many dimensions (if I recall aright,
up to about 200 of them max) and there are 26 global accumulators which can be used.
Some functions generate auxiliary outputs in these. For example functions like MAX[range]
return the maximum value in the range, but return the coordinates where the max
was found in 2 of the accumulators (A and B I think). Several expressions can go into
any cell, just so total length of the expression is under 110 characters. (Just a FYI:
the accumulators A to Z are aliased as pseudo cells A0 to Z0.)

The program has the RIM database linked in and it can use RIM to hold relational
information. The program also has lots of matrix operations and the like. FFT, and
many other tricks. It has a few features useful in text processing also, though
there are no doubt many better ways to accomplish these now. It was composed originally
in late 1982. At that time, Fortran was "the universal assembler" and C compilers were
much harder to find. Thus this was written in what was then a fairly portable language.

This program was initially named VisiKludge, then ViziKludge, PortaCalc, AnalytiCalc,
and AnalyRim. Same program, with different adhering features added in. Versions exist
for RSX11M, RSX11M+, AmigaDos, SunOS, VMS (Vax and Alpha, and they'll probably build on
IA64), and MSDOS. These can all be found on www.gce.com at the moment, or on old
RSX and VMS DECUS sig tapes. This version is however newer.


I use the gfortran fget and fput routines to do character I/O to the console.
It appears xterm does escape sequences well enough that the display looks 
usable.
Glenn C. Everhart
11/2015



Addendum:
It can be a good idea to try "stty raw"
or stty cbreak, and stty -echo  before running AnalyRIM, then
"stty cooked" afterwards to return to normal. This is not fully correct
yet, but allows AnalyRIM to read characters without waiting for a
newline, return, enter, or the like, so it has a chance to handle escape
sequences. There are some rough edges here at this writing, so it does
not really matter much, but they are being worked on.

stty noecho is also needed in this mode.

In this way things are mostly workable. Echo of help needs a bit...

Build files USED TO build 2 versions. Only the newer is done now.
analy-i2cellno - the older code, limited to 32767 active cells at once due to
	a bunch of assumptions that 16 bit integers were big enough
	for indices
analy - newer code, does not have 16 bit cell number limit.
	There are probably still a few I3 format statements that
	limit some arrays to 3 digit sizes but I have loosened the
	worst of these. Reflections, multiple dimensions and the like
	area all in there though.

The makanaly.sh command file now builds only the newest version with 4 byte cell
numbers, larger display sheet internally. Several bugs have been removed also. I don't
know of any formats that limit sizes too badly but I would be cautious editing acinit.prm
(or variants) which control the sizes of internal arrays. Comments there tell you about
constraints that should be followed.

I recommend using the latter. Just rename.
To use,
copy analy to /usr/local/bin/analy (and /usr/local/bin/analy.bin, and then
	copy "analyticalc" (a shell script) to /usr/local/bin also)
and make a directory /DK/ and untar dk.tar into it and make it world readable.

There are big long manuals (as .doc files, but these are really text files,
have nothing to do with MS Word. They are output of Runoff mostly.) There
is not at the moment a .man file but there is a help command...

I have pretty much all the old runoff files (*.rno) available as text files
processed now.

Glenn C. Everhart
gce@gce.name
302 373 5382 cell
Smyrna, Delaware 19977
Elkton, Md 21921



NOTE of late 2018 mods:
A version of AnalyRIM called analy-i4cellno_color.for is present which has code
to try to enable VC (view color), VB (view black and white), and VI (view black and
white and don't mess with display). The color stuff is enabled
with ANSI escape sequences.
 It shows what can be done by editing the screen output (pretty much only). It
does work and is turned on by VC, turned off by VB. Initial display is the VB
black and white mode. The color turns out to be somewhat distracting.

If you find display the wrong size for your window the DB cols,rows command
will redraw things and resize for what will fit.

Other news:
VJ adds some indications at top and left which cell is being pointed to, if the
preexisting ones are not enough. VI also turns that back off.
VxM (where x is B,C,J,I) turns on mouse recognition. Left button will insert
the cell name the mouse points at into the command line. Middle button or left
and right together will insert "L cellname" in the command line, which will
cause one to go to that cell. Right button alone seems to be absorbed by the
system and does not show up.
In "enter mostly" mode this is more useful than in normal command mode. See the
manuals. This is a recent addition, not tested a lot yet.

The DW command has an addition "DW *,wid" allowing you to set widths of all
display columns to "wid" (expected to be a width in characters, 1 to 110). Be aware
that printout can get hard if you try to make things far too wide.

I had the program working using curses() in SunOS. My Linux setup (several versions
back now) when I last tried to get curses() working in Analyticalc gave me grief
linking things so I fell back to directly handling escape sequences.
Note that writing calls the UVT100 subroutine for most everything (which calls swrt
to do actual writing) and the old SunOS version of UVT100 could be bolted back
in if desired. When color is not being handled, what is done is mostly "move to
x,y", write string and a very few other commands like erase screen. It will redraw
a cell if its binary value changes, even though the displayed digits might not change;
in practice this behaves almost the same. Due to this way of handling things,
UVT100 does not really have any global idea what the display looks like, which makes
it more complicated to make a pretty "graphic" type screen like newer spreadsheet
programs have. UVT100 is called to draw what is in one cell, or it is called from
the routine that is trying to draw (or print) the visible spreadsheet. It would be
necessary to add logic to paint in a grid, then paint values inside so the grid
itself was not continually overwritten. Sometime, once I figure out the escape
sequence stuff, maybe. For now, xterm is pretty close to vt100 so the old screen controls
work and can be hacked to even show colors (VC mode). I have fiddled to try to set
alternate lines bold or normal, or use underline mode, but do not use those here because
a terminal display gets very busy and I don't think these make the display much
easier to follow. Rather the contrary. Some old versions of UVT100 with that logic
can be found among the old version code if someone wants to play with them. To
facilitate following along rows or columns, I'm afraid something like a graphics mode
grid really would be needed.