I had the same problem as Bruce several times: an error in the name of
an equate was unnoticed and it took me a long time before I noticed it.
In parallel, I used a lot the the "equate to undefined" feature to
compile small subsections of a large survey and I find it very useful.
However, for the same survey subsections, the nightmare is to verify
that all equates are correctly taken into account when considered in
the large survey, since the warning are hidden in the (potentially very
long) list of unused fixed points.
Keeping the meaning of equate as it is right now (i.e. create a synonym
if one of the stations is not defined) is of course necessary for
compatibility with previous surveys. However, one could imagine to
create a more constrained command (e.g. equate* like in latex?) whose
meaning would be a zero length shot between two existing stations and a
error if one of them is undefined. It could also make sense to have an
option in therion to force the interpretation of equate as equate* for
debugging.
Xavier
Le 02/12/2013 10:58, Wookey a écrit :
> +++ Olly Betts [2013-12-01 23:02 +]:
>> But in your original example, you're linking to a non-existent station
>> in a different survey (if I follow the therion syntax correctly), and
>> the equivalent situation gets a warning from Survex:
>>
>> badequate.svx:1: warning: Station "kb.kb51_29" referred to just once, with
>> an explicit prefix - typo?
>>
>> I think we made this a warning rather than an error because it makes
>> processing subsections of a large survey (e.g. a single cave) easier.
> Yes, we did.
>
> And that's still useful functionality, although the need for processing
> small sections is much reduced these days. Consideration could be given
> to whether it would now be appropriate to declare that the smallest
> section of processing is now 'a system', and provide better visibility
> controls for viewing subsections. (and if you want to process smaller
> sections in isolation you'll have to make efforts to include 'stub' or
> reference connection points to avoid errors). There are both pros and
> cons to this and some thought would be needed on where the balance lies.
>
> Does therion process subsections using survex, or collect it all up into
> a complete dataset and proces that?
>
> Presumably bruce's problem is solved simply by better visibility of the
> existing warning, which shouldn't be hard?
>
> Wookey
--
> -
> Xavier Pennec
> Senior Research Scientist / Directeur de recherche
> Asclepios project-team, INRIA Sophia-Antipolis
> 2004 Route des Lucioles, BP93
> F-06902 Sophia-Antipolis Cedex, France
> +33 4 92 38 76 64
> +33 6 78 35 16 90
> http://www-sop.inria.fr/asclepios/
> ---
