Survex 1.0 within sight

[John Pybus]

Olly Betts wrote:
>
> 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.

All the code for the sourceforge site is available, as guess what ... a
sourceforge project ;-), although I've never looked at it so have know
knowledge about how generally useful any of it is.

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

The palm platform is a long way from supporting standard C.  It doesn't
have a concept of files and file descriptors; stdin/stdout; any of the
string handling, or memory allocation functions (although there mainly
are other APIs with equivalent functionality) etc.  My current strategy
involves plenty of dummy header files, wrapper implementations of
standard functions, and a fair few horrendous hacks.  

The palm has very limited stack, and dynamic heap space.  I had cavern
compiling to run as normal allocating from this in June, but it was not
capable of handling many legs.  Most of the memory on a palm device is
given over to static "database" heaps which act as a primative file
system.  Because these are stored in RAM most palm programs work on the
data in place.  To use this I've had to make all memory accesses to
structures through handles rather than pointers (preventing the OS from
moving chunks around is not easy), and a sed script alters your sources
to transform your memory accesses.  Basically I'm rather surprised that
it works at all ;-)

All, I'm ending up using from cavern are the data structures, and the
network routines.

In short if I was starting this again today, I would rather be
developing for one of these: http://www.agendacomputing.com/ . 
Apparently a Linux 2.4 kernel(hmm), a 66MHz MIPS processor, and an X
Windows based display, but of course not actually shipping yet ;-)

> 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...)

No probably not.  To get data into the palm my strategy has been to let
an altered version of cavern read the .svx files, taking care of
calibrations, different data styles etc, and output a list of legs in a
simplified format (basically fix commands, equates, and legs with
delta{x,y,z} and covariance).  The palm device then parses this
constructing a valid palm Database from it.  An early version of the
palm program would only parse the x,y,z values, and it took a while to
work out why strange things were happening, that's all ;-)

I can think of occations when one might be tempted to use a zero
variance leg (e.g. a rigid measuring stick used for a plumbed leg) but a
small positive variance could easily be used, and would probably better
represent the situation anyway.

Yours,

John