Hi Nate, hi Ervin, sorry to jump in late in the discussion. Our local field day kept me busy the last days.
Am Mon, 11 Jun 2018 21:51:30 -0500 schrieb Nate Bargmann <n...@n0nb.us>: > Let me start over on this as I think there are a few > misunderstandings. > > * On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: > > Hi all, > > > > On Mon, Jun 11, 2018 at 08:18:11AM -0500, Nate Bargmann wrote: > > > One thought I had would be to create a parallel mults file > > > definition using GKeyFile as the means for setting groups for > > > mults, alias, and alias_mults. I am thinking along the lines of: > > > > > > [Mults] > > > AL > > > AK > > > AZ > > > . > > > . > > > . > > > WV > > > WY > > > > > > [Alias] > > > KS > > > > > > [AliasMults] > > > (County abbreviations) > > > > > > > > > Then the code could look for the Mults group and if found process > > > it and if not, then revert to the current mults file style. > > > > > > In this format, any AliasMult entered would be applied as the > > > Alias. > > > > > > Thoughts? > > > > and you should pass this file to Tlf through parse_logcfg.c? > > No. This is in the mults file and should be handled in the same code > area as the present mults file is read. > > Correct me if I'm wrong, but I didn't think parse_logcfg.c handled the > mults file processing. > > Here is my outline of the logic flow (based on my likely > misunderstanding of the process). > > The open mults file function is called. > > The GKeyFile functions are used to open the mults file and test if the > group "[Mults]" is present. If so, the Mults, Alias, and AliasMults > are loaded into their respective data structures. If not, the > present mults processing code is used and the file is loaded into the > mults data structure. > Yes Nate, your understanding is correct. > During logging operations the exchange validator can process the mults > structures as follows. > > Any string appearing in [Mults] is subject to the rules for mults > defined elsewhere, either internally or in the rules file. > > Any string appearing in [AliasMults] is applied to the [Alias] value > which is then subject to the mults rules. > > In the case of the Kansas QSO Party, here is how it would work. > > An in-state participant has 64 mults available--50 US states, 13 > Canadian provinces, and "DX". > > When an in-state op works another in-state op we exchange the county > abbreviations ([AliasMults]) and the first one counts as the KS mult > and any subsequent counties are not counted toward the mults. > Yep. > The current implementation of Tlf does not allow for the 105 Kansas > counties to only count toward KS one time. In order to validate the > exchange I included the 105 counties in the mults file (attached in a > previous mail) so Tlf treats it as 169 mults! Therefore I have a > custom script to calculate my raw score. > > It's not a big deal, it's just a nice to have feature. > > 73, Nate > For me there are two distinct points in that discussion: a) How to present the multis and their alias (e.g. by the GKey format as proposed) b) How to present and score it internally. Wrt b) I had some time to think about and there are some first ideas. Regarding the format I am 100% for the GKeyFile format - at least in the long run. At the moment we would introduce a new concept to TLF's users. So I am not sure if something like the following could do also: # plain multis AL AK AZ . . . WV WY # aliased multi with aliases KS:ALL,AND,ATC,... # additional entries KS:WAB,WAL,WAS, ... The format is also easy to write (and to parse). Any comments? 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea --
pgpUAXqbzYPwt.pgp
Description: Digitale Signatur von OpenPGP
_______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
