Re: [Tlf-devel] Handling multiplier aliases?

[Thomas Beierlein]

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 <address@hidden>:

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

pgpMfacVfSF_z.pgp
Description: Digitale Signatur von OpenPGP