Survex 1.0 within sight

[Olly Betts]

In message <399AAE00.F0BCEBC@zoo.ox.ac.uk>, John Pybus writes:
>Sorry to hear about your knee in Austria, hope it's on the mend.

It's still sore, but seems to be improving slowly.

>About
>the current survex releases: are you keeping the code in a Revision
>Control system such as CVS?  If so is access possible?

It's in CVS, hosted on a box in Cambridge by Mark Shinwell.  There's no
anonymous CVS access, but I imagine Mark would be willing to offer CVS
accounts to those with a genuine use for them.

>If not, then one possibility would be to host it at sourceforge.net, since
>it is a GPL project.  They run a patched version of cvs, which allows them
>to offer anonymous read-only CVS access which is nice.

I created a sourceforge account a while ago:

http://sourceforge.net/projects/survex/

But there's not much there yet.  We really want to make sourceforge a mirror
of the primary CVS archive since moving it to the US would slow access
(everyone with a CVS account is currently in the UK).  A number of
sourceforge projects seem to want CVS mirroring for similar reasons, but
last time I checked it wasn't available.

If the sourceforge anoncvs patches are available, perhaps Mark could install
them on his machine and allow anoncvs without the usual security concerns.

>I have a port of parts of survex to the PalmOS platform well underway. 
>Currently it's based on v0.93, but once I've got it to a working state,
>I'd like it to be as easy as possible to track the current version.

Cool.

>This is not v1.0 territory, but what would make my stuff much easier
>would be a better seperation of the reporting, and file writing code
>from the network solving routines.

Hopefully the 2.0 plans should address this.

For now, you may be able to make headway by providing an alternative version
of out.h.

>One more thing while I'm at it, which I don't remember seeing on any bug
>lists.  At least in v0.93, in replace_pfx_() the *fix code considers two
>nodes equated if the leg between them has zero variance.  This is not a
>sufficiant condition, you need the delta to also be zero (although in
>most uses it wouldn't be a problem since you have a positive variance on
>an ordinary leg).

This assumption is made in several places.  In cavern, a real leg always has
a non-zero variance so this is valid.

>I noticed this when the testing an early version of
>my palmOS tools which was not yet bothering to set variances on the legs
>it created.

Do you have a genuine need for zero variance legs with length?  This could
cause problems in the network code (loops of zero variance are hard to
solve...)

Cheers,
Olly