Hmm, may need to think about this.
We risk adding adhoc patches on adhoc patches and painting ourselves into a
corner.
Agree we should not add a new keyword just to emulate an obscure special case
that is not well understood or well handled by 'ignore'. So a modifier of
'ignore' would be better, as Tarquin suggests.
>extend ignore end 8 7 #or
>extend ignore 8 7 end
Not sure about the word 'end', as it will not always be evident which end of a
loop is the 'end’. Especially where there are loops within loops or beside
loops. Maybe 'force'. Not sure about that either, but the user rule of thumb
could be, if 'ignore' does not work, try 'ignore force'.
extend ignore force 8 7 #or
extend ignore 8 7 force
Maybe we should take time to think about it for a while. We have a tentative
solution right now, as Stacho has found, using the combination.
extend start 1
extend ignore 7 8
extend ignore 8 7
ie, if extend ignore <leg> does not work, try following it with extend ignore
<reversed leg>
Using Tarquin's example this gives a log like...
START 1@extendedloop
RIGHT 2@extendedloop
RIGHT 10@extendedloop
RIGHT 9@extendedloop
RIGHT 8@extendedloop #ie random branch taken as far as 8
BACK 9@extendedloop
BACK 10@extendedloop
BACK 2@extendedloop #step back to 2
RIGHT 3@extendedloop
RIGHT 4@extendedloop
RIGHT 5@extendedloop
RIGHT 6@extendedloop
RIGHT 7@extendedloop
RIGHT 11@extendedloop #at end branch 11…
BACK 7@extendedloop
BACK 6@extendedloop
BACK 5@extendedloop
BACK 4@extendedloop
BACK 3@extendedloop
BACK 2@extendedloop
BACK 1@extendedloop #step all the way back to 1
START 8@extendedloop #auto restart at 8
RIGHT 7@extendedloop #finish the last leg
done
And vise versa
extend start 1
extend ignore 8 7
extend ignore 7 8
START 1@extendedloop
RIGHT 2@extendedloop
RIGHT 10@extendedloop
RIGHT 9@extendedloop
RIGHT 8@extendedloop #ie random branch taken as far as 8
BACK 9@extendedloop
BACK 10@extendedloop
BACK 2@extendedloop #ie random branch taken as far as 8
RIGHT 3@extendedloop
RIGHT 4@extendedloop
RIGHT 5@extendedloop
RIGHT 6@extendedloop
RIGHT 7@extendedloop
RIGHT 11@extendedloop #at end branch 11…
BACK 7@extendedloop
BACK 6@extendedloop
BACK 5@extendedloop
BACK 4@extendedloop
BACK 3@extendedloop
BACK 2@extendedloop
BACK 1@extendedloop #step all the way back to 1
START 8@extendedloop#auto restart at 8
RIGHT 7@extendedloop #finish the last leg
done
It disturbs me that the sequence is exactly the same.
I agree with Tarquin, “it smells like there will be some unpredictable hidden
behaviours in there”.
A question Stacho.
Are extend statements processed in sequence they are written, or are they all
read by Therion before Therion chooses best order to process them (as it does
with survey data)?
I’m suspecting the latter.
Bruce
-----Original Message-----
From: Therion <therion-boun...@speleo.sk> On Behalf Of Tarquin Wilton-Jones via
Therion
Sent: Wednesday, 8 July 2020 02:42
To: therion@speleo.sk
Cc: Tarquin Wilton-Jones <tarquin.wilton-jo...@ntlworld.com>
Subject: Re: [Therion] Revisiting Breaking extended elevations on specific
stations
> Well, there is one workaround. But to be honest, I have no idea why :/
>
> extend ignore 7 8
> extend ignore 8 7
Wow!
First thought is; that ... really shouldn't work, and it looks almost like a
bug.
Maybe there is logic though, if you look at those two statements in the
opposite order (which also works, by the way).
Therion proceeds along 1-2-10-9-8-7-11
"Therion, please ignore 8-7"
Therion breaks the survey at 8. Therion now goes:
10-9-8 8
/ /
1-2-3-4-5-6-7-11
"Therion, please ignore 7-8"
Therion breaks the survey at 7. It now has a floating 7-8 leg not connected to
anything. So it connects it to the 10-9-8 branch, and ends up with the desired
output.
So maybe this is trustworthy rather than a bug? But it hurts my head to read
it, and it smells like there will be some unpredictable hidden behaviours in
there.
> Something like:
>
> extend end 8 7
>
> ... would be definitely better. Is it OK to implement it like that?
I like that it will never clash with existing stuff. I don't like that it
introduces a new keyword instead of "ignore", that does the same thing as
"ignore". I would personally prefer it as a modifier rather than a keyword, for
consistency:
extend ignore end 8 7
extend ignore 8 7 end
But others may have stronger opinions.
_______________________________________________
Therion mailing list
<mailto:Therion@speleo.sk> Therion@speleo.sk
<https://mailman.speleo.sk/listinfo/therion>
https://mailman.speleo.sk/listinfo/therion
_______________________________________________
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
