Survex 1.0 within sight

[Olly Betts]

Hi folks,

I've just returned from the annual CUCC expedition to Totes Gebirge in
Austria.  With one week left to go we hadn't manged to link the
Kaninchenhoehle/Steinschlagschacht system with the
Eishoehle/Stellerweg/Schwabenschacht/etc system, but the distance between
the surveys is now down to 20m horizontally and 25m vertically.  So at our
best estimate, we're now 32m away from producing a system a little over 50km
long and well over 1km deep.

Anyway, I had a little tumble down an entrance shaft while walking to a cave
entrance.  I escaped remarkably unscathed, but did give my left knee a good
bash.  This made SRT too difficult so I got to sit at base camp fettling
Survex for several days.  I've cleared all the entries on the BUGS list
which were reproducible and fixable, and cleared most of the TODO list.

I've also merged in Phil Underwood's patches for use with his Chasm GUI
frontend.

The floppy I brought the new sources back on has a glitch, but Mark Shinwell
the sources are on the machine out there and on backup tapes so I should be
able to get the new sources next weekend.  I started from 0.93 so I need to
merge the changes with 0.94-prerelease1.  I propose that 0.94-prerelease1
becomes the 0.94 release (no problems have been reported), and that the
merged version becomes 0.95-prerelease1.

We're then well on the road to 1.0.  Here's what I think needs to be done
before 1.0:

* Resolve anything left on TODO and BUGS
* Bring documentation up to date
* Resolve any "FIXME" or "!HACK!" comments in the code
* Utility to install sensible file associations in Windows Registry

If there's anything else you think should go in before 1.0, now's the time
to say.  I do want to keep the list short though - I definitely want to get
1.0 out before the end of 2000, hopefully much sooner.

If anyone fancies helping out, it would be very useful to have someone (or a
few people) read through the documentation and highlight areas which are
unclear, nonsensical, out of date, or just plain wrong.

It would also be good to check everything works as documented.  There's now
an automated test suite, which can be run using "make check" when building
from source.  Most recent bugs have test cases to make sure they stay fixed,
and there are various simple tests that the network solution works
correctly.  However not much basic functionality is tested.  If you fancy
writing test cases to check such things, it's not a hard job and would be
time usefully spent.

The most common type of test consists of a .svx file and the expected .pos
file.  E.g. this .svx file:

*calibrate tape 5.0
*fix 1 0 0 0
1 2 10.00 000 00

should produce this .pos file:

( Easting, Northing, Altitude )
(    0.00,     0.00,     0.00 ) \1
(    0.00,     5.00,     0.00 ) \2

You can also write tests cases which cavern *should* fail on (e.g. *begin
with no matching *end).  It's possible to add other sorts of tests - these
are just the 2 types that there's already a framework for.

I have plans for where to go after 1.0 but I'll save those for another mail.

Cheers,
Olly