Re: [Tlf-devel] Handling multiplier aliases?
Hi Nate and others, sorry for writing the last letter to early. Please stop the tests of the new feature for now. I just found that I forgot to change one point. Have to fix that first. 73, de Tom Am Sun, 27 Jan 2019 13:10:40 +0100 schrieb Thomas Beierlein : > Hi Nate, > > in last days I found time to implement the mechanism for handling > multiplier aliases. Please have a look at the 'alias_multi' branch at > https://github.com/dl1jbe/tlf/tree/alias_multi > > As proposed you can add the following lines to the multsfile: > > NV:...,...,..., ... > WY:...,...,..., ... > > There may be a plain NV or WY line before and you can even have more > than one line with same Multi and different aliases. The aliases will > add in that case. > > The only to point to look for is that the aliases should be unique. > > Please check if it works as expected and report back. The code > still needs some cleanup and also the documentation in man page is > missing. I will do that after getting some feedback. > > 73, de Tom DL1JBE > > > > Am Tue, 12 Jun 2018 12:34:47 -0500 > schrieb Nate Bargmann : > > > * On 2018 12 Jun 12:08 -0500, Thomas Beierlein wrote: > > > Hi Nate, > > > > > Yes, it was. Weather was a little bit tough (thunderstorm in the > > > evening) but all went well. > > > > A storm line formed overhead last night and there was hail reported > > about 20 miles east of here and in the next county east there were > > tornado warnings. I'm glad that we missed out on that "fun"! > > > > > > It occurred to me later that GKeyFile expects entries to be > > > > key=value pairs. My list would seem to be breaking that as it > > > > would, at best, merely be a list of keys. I *think* that would > > > > be workable, but maybe not. > > > > > > > > I like your method of defining the alias mult and its aliases. > > > > In fact, for those parties that require it, multiple mults and > > > > aliases could be easily defined. for the 7 Land QSO Party it > > > > could be: > > > Yes, that was one reason behind that solution. > > > > Excellent! > > > > > > NV:...,...,..., ... > > > > WY:...,...,..., ... > > > > > > > > etc. > > > > > > > > That is actually quite clever. > > > > > > Ok, then we will head in that direction. > > > > > > I will try to finish TLF-1.3.1 over the weekend. We added a lot of > > > stuff in last year - time to bring it out. Afterwards I will start > > > adding the 'alias mults' feature. > > > > Sounds good, Tom. I'm ready to test. :-) > > > > 73, Nate > > > > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- pgpDi4jGwoyrd.pgp Description: Digitale Signatur von OpenPGP ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
Hi Nate, in last days I found time to implement the mechanism for handling multiplier aliases. Please have a look at the 'alias_multi' branch at https://github.com/dl1jbe/tlf/tree/alias_multi As proposed you can add the following lines to the multsfile: NV:...,...,..., ... WY:...,...,..., ... There may be a plain NV or WY line before and you can even have more than one line with same Multi and different aliases. The aliases will add in that case. The only to point to look for is that the aliases should be unique. Please check if it works as expected and report back. The code still needs some cleanup and also the documentation in man page is missing. I will do that after getting some feedback. 73, de Tom DL1JBE Am Tue, 12 Jun 2018 12:34:47 -0500 schrieb Nate Bargmann : > * On 2018 12 Jun 12:08 -0500, Thomas Beierlein wrote: > > Hi Nate, > > > Yes, it was. Weather was a little bit tough (thunderstorm in the > > evening) but all went well. > > A storm line formed overhead last night and there was hail reported > about 20 miles east of here and in the next county east there were > tornado warnings. I'm glad that we missed out on that "fun"! > > > > It occurred to me later that GKeyFile expects entries to be > > > key=value pairs. My list would seem to be breaking that as it > > > would, at best, merely be a list of keys. I *think* that would > > > be workable, but maybe not. > > > > > > I like your method of defining the alias mult and its aliases. In > > > fact, for those parties that require it, multiple mults and > > > aliases could be easily defined. for the 7 Land QSO Party it > > > could be: > > Yes, that was one reason behind that solution. > > Excellent! > > > > NV:...,...,..., ... > > > WY:...,...,..., ... > > > > > > etc. > > > > > > That is actually quite clever. > > > > Ok, then we will head in that direction. > > > > I will try to finish TLF-1.3.1 over the weekend. We added a lot of > > stuff in last year - time to bring it out. Afterwards I will start > > adding the 'alias mults' feature. > > Sounds good, Tom. I'm ready to test. :-) > > 73, Nate > -- "Do what is needful!" Ursula LeGuin: Earthsea -- pgpVkQ4C1OynO.pgp Description: Digitale Signatur von OpenPGP ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 12 Jun 12:08 -0500, Thomas Beierlein wrote: > Hi Nate, > Yes, it was. Weather was a little bit tough (thunderstorm in the > evening) but all went well. A storm line formed overhead last night and there was hail reported about 20 miles east of here and in the next county east there were tornado warnings. I'm glad that we missed out on that "fun"! > > It occurred to me later that GKeyFile expects entries to be key=value > > pairs. My list would seem to be breaking that as it would, at best, > > merely be a list of keys. I *think* that would be workable, but maybe > > not. > > > > I like your method of defining the alias mult and its aliases. In > > fact, for those parties that require it, multiple mults and aliases > > could be easily defined. for the 7 Land QSO Party it could be: > > > Yes, that was one reason behind that solution. Excellent! > > NV:...,...,..., ... > > WY:...,...,..., ... > > > > etc. > > > > That is actually quite clever. > > Ok, then we will head in that direction. > > I will try to finish TLF-1.3.1 over the weekend. We added a lot of > stuff in last year - time to bring it out. Afterwards I will start > adding the 'alias mults' feature. Sounds good, Tom. I'm ready to test. :-) 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
Hi Nate, Am Tue, 12 Jun 2018 07:23:01 -0500 schrieb Nate Bargmann : > * On 2018 12 Jun 00:29 -0500, Thomas Beierlein wrote: > > Hi Nate, hi Ervin, > > > > sorry to jump in late in the discussion. Our local field day kept me > > busy the last days. > > Hope you had fun. > Yes, it was. Weather was a little bit tough (thunderstorm in the evening) but all went well. > > 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? > > It occurred to me later that GKeyFile expects entries to be key=value > pairs. My list would seem to be breaking that as it would, at best, > merely be a list of keys. I *think* that would be workable, but maybe > not. > > I like your method of defining the alias mult and its aliases. In > fact, for those parties that require it, multiple mults and aliases > could be easily defined. for the 7 Land QSO Party it could be: > Yes, that was one reason behind that solution. > NV:...,...,..., ... > WY:...,...,..., ... > > etc. > > That is actually quite clever. Ok, then we will head in that direction. I will try to finish TLF-1.3.1 over the weekend. We added a lot of stuff in last year - time to bring it out. Afterwards I will start adding the 'alias mults' feature. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- pgpqC0QpSrw0G.pgp Description: Digitale Signatur von OpenPGP ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 12 Jun 00:29 -0500, Thomas Beierlein wrote: > Hi Nate, hi Ervin, > > sorry to jump in late in the discussion. Our local field day kept me > busy the last days. Hope you had fun. > 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? It occurred to me later that GKeyFile expects entries to be key=value pairs. My list would seem to be breaking that as it would, at best, merely be a list of keys. I *think* that would be workable, but maybe not. I like your method of defining the alias mult and its aliases. In fact, for those parties that require it, multiple mults and aliases could be easily defined. for the 7 Land QSO Party it could be: NV:...,...,..., ... WY:...,...,..., ... etc. That is actually quite clever. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
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 : > 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
Re: [Tlf-devel] Handling multiplier aliases?
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. 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. 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 -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
Hi Nate, On Mon, Jun 11, 2018 at 01:22:04PM -0500, Nate Bargmann wrote: > * On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: > > Hi Ervin! > > > and you should pass this file to Tlf through parse_logcfg.c? > > > > brrr > > > > :) > > It's been a while since I followed the logic. Maybe that's why I sent > the email first. ;-) I'm sorry, that would be just a joke :) > > How many contest could we use this feature? > > I think it would be useful for a lot of US QSO parties. Not every state > has its own party so there are far less than 50 as some states do one > party as a group. Also, this probably only affects in-state > participants. How many Tlf users would this impact immediately, well, > me, for one. :-D good to read it :) (Anyway, that's sad but true, I didn't found any stat about the used loggers at biggest contests (CQWW/WPX, ARRL-DX). The only one stat is the Debian popcorn: https://qa.debian.org/popcon.php?package=tlf, which is - I think - not so bad!) > > Once upon I proposed that we sould start to a new direction in > > config file/rules parsing. I'm still thinking that the best way > > would be implement some external scripting language, as module, > > eg. Python and/or Lua. With one of those, everyone can make a > > more sophisticate rule for every contests. > > > > Here is my original opinion: > > > > http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00101.html > > Thanks for the pointer back into that thread. I tossed a number of > lofty ideas out there! This post from Tom is apropos to this thread: > > http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00104.html yes, I've also re-read that thread, and I think now I put myself together, and start to implement the Python config :) 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: Hi Ervin! > and you should pass this file to Tlf through parse_logcfg.c? > > brrr > > :) It's been a while since I followed the logic. Maybe that's why I sent the email first. ;-) > I think the codebase of Tlf is already very complex. I agree. I use 'git grep' a lot to find my way around. I do this with Hamlib and I've been developing on it for 15 years or so! > How many contest could we use this feature? I think it would be useful for a lot of US QSO parties. Not every state has its own party so there are far less than 50 as some states do one party as a group. Also, this probably only affects in-state participants. How many Tlf users would this impact immediately, well, me, for one. :-D > Once upon I proposed that we sould start to a new direction in > config file/rules parsing. I'm still thinking that the best way > would be implement some external scripting language, as module, > eg. Python and/or Lua. With one of those, everyone can make a > more sophisticate rule for every contests. > > Here is my original opinion: > > http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00101.html Thanks for the pointer back into that thread. I tossed a number of lofty ideas out there! This post from Tom is apropos to this thread: http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00104.html 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
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? brrr :) I think the codebase of Tlf is already very complex. How many contest could we use this feature? Once upon I proposed that we sould start to a new direction in config file/rules parsing. I'm still thinking that the best way would be implement some external scripting language, as module, eg. Python and/or Lua. With one of those, everyone can make a more sophisticate rule for every contests. Here is my original opinion: http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00101.html 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
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? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
* On 2018 05 Jun 22:21 -0500, Thomas Beierlein wrote: > Hi Nate, > > ltns, hope you are well. Oh, I am doing fine. Been working on Hamlib documentation after getting 3.2 out into the wild, doing some FT-8 lately, fixing a noisy DG-5 for my TS-520SE, looking at a friend's FT-890 and hooking up my FT-890 for a radio to check into nets while the K3 does FT-8 duty. Just small stuff. :-) > We will look into it, but it would be nice to have some more > information. > > Can you please provide us with your logcfg.dat, a sample log with > marked errors/problems and maybe your python script as a starter? I'll attach the 2017 log, logcfg.dat, rules file, my mults file, and the Perl script (thought I'd done it in Python, but this is in the directory. You can play with the scoring and adding new QSOs with the KS counties to see what Tlf does. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB # General contest mode # # CONTEST=ksqp LOGFILE=ksqp_2017.log CONTEST_MODE CABRILLO=UNIVERSAL # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S_TU_MSG= # ## # % = call # # @ = hiscall # # # = serial# # [ = RST # # + = increase cw speed # # - = decrease cw speed # ## ## # F1=CQ KQP % F2=@ DE % F3=@ 5NN MSH F4= TU F5=@ F6=% F7=@ SRI QSO B4 GL F8=AGN F9=? F10=QRZ? F11=PSE K F12=CQ KQP % # CQ_TU_MSG=TU % S_TU_MSG=TU 5NN MSH # #ALT_0= #ALT_1= #ALT_2= #ALT_3= #ALT_4= #ALT_5= #ALT_6= #ALT_7= #ALT_8= #ALT_9= # #SEND_DE # # # # # Voice Keyer Files# #(F1 to F12)# # # VKM1=/home/nate/logs/wav/N0N/kqp/F1.wav VKM2=/home/nate/logs/wav/N0N/kqp/F2.wav VKM3=/home/nate/logs/wav/N0N/kqp/F3.wav VKM4=/home/nate/logs/wav/N0N/kqp/F4.wav #VKM5= VKM6=/home/nate/logs/wav/N0N/kqp/F6.wav #VKM7= VKM8=/home/nate/logs/wav/N0N/kqp/F8.wav #VKM9= VKM10=/home/nate/logs/wav/N0N/kqp/F10.wav VKM11=/home/nate/logs/wav/N0N/kqp/F11.wav VKM12=/home/nate/logs/wav/N0N/kqp/F12.wav VKSPM=/home/nate/logs/wav/N0N/kqp/SPM.wav VKCQM=/home/nate/logs/wav/N0N/kqp/CQM.wav # # # # Scoring rules# # # MIXED RECALL_MULTS SSBPOINTS=2 CWPOINTS=3 WYSIWYG_ONCE MULT_LIST=ksqp.txt ### END # # DX DX # Canada provinces AB BC MB NB NL NT NS NU ON PE QC SK YT # US states (50) AL AK AZ AR CA CO CT DE FL GA HI ID IL IN IA KS KY LA ME MD MA MI MN MS MO MT NE NV NH NJ NM NY NC ND OH OK OR PA RI SC SD TN TX UT VT VA WA WV WI WY # KS counties (105) ALL AND ATC BAR BRT BOU BRO BUT CHS CHT CHE CHY CLK CLY CLO COF COM COW CRA DEC DIC DON DOU EDW ELK ELL ELS FIN FOR FRA GEA GOV GRM GRT GRY GLY GRE HAM HPR HVY HAS HOG JAC JEF JEW JOH KEA KIN KIO LAB LAN LEA LCN LIN LOG LYO MRN MSH MCP MEA MIA MIT MGY MOR MTN NEM NEO NES NOR OSA OSB OTT PAW PHI POT PRA RAW REN REP RIC RIL ROO RUS RSL SAL SCO SED SEW SHA SHE SMN SMI STA STN STE SUM THO TRE WAB WAL WAS WIC WIL WOO WYA 20CW 26-Aug-17 14:00 0001 K3MB 599 599 PA 3 14042.2 20CW 26-Aug-17 14:03 0002 KN4Y 599 599 FL 3 14042.2 20CW 26-Aug-17 14:05 0003 N8II 599 599 WV 3 14042.2 20CW 26-Aug-17 14:09 0004 K0PV 599 599 CO 3 14042.2 20CW 26-Aug-17 14:11 0005 K4XI 599 599 FL 3 14042.2 20CW 26-Aug-17 14:12 0006 K4ZGB 599 599 AL 3 14042.2 20CW 26-Aug-17 14:18 0007 VE3AYR 599 599 ON 3 14042.2 20CW 26-Aug-17 14:20 0008 WB2PJH 599 599 NJ 3 14042.2 20CW 26-Aug-17 14:20 0009 N6MU 599 599 CA 3 14042.2 20CW 26-Aug-17 14:21 0010 KD8DEU 599 599 MI 3 14042.2 20CW 26-Aug-17 14:21 0011 AE1T 599 599 NH 3 14042.2 20CW 26-Aug-17 14:22 0012 K3TN 599 599 MD 3 14042.2 20CW 26-Aug-17 14:26 0013 VE4EA 599 599 MB 3 14042.2 20CW 26-Aug-17 14:28 0014 WA2FZB 599 599 NJ 3 14042.2 20CW 26-Aug-17 14:28 0015 N4UP 599 599 VA 3 14042.2 20CW 26-Aug-17 14:29 0016 K2HVN 599 599 DE 3 14042.2 20CW 26-Aug-17 14:30 0017 N4NQ 599 599 GA 3 14042.2 20CW 26-Aug-17 14:30 0018
Re: [Tlf-devel] Handling multiplier aliases?
Hi Nate, ltns, hope you are well. Am Sat, 2 Jun 2018 09:05:47 -0500 schrieb Nate Bargmann : > One of the limitations I have had with Tlf in the past is aliasing a > list of multiplier strings to a single multiplier. To wit, like many > US QSO Parties, the Kansas QSO Party has a different set of > multipliers for in-state and out of state stations. > > For out of state stations the situation is straight forward, the 105 > counties in Kansas which are three characters in length. For in-state > stations, such as myself, it is a bit more complicated as our > multipliers are the other 49 states using the USPS two-letter state > abbreviations and the 14 Canadian provinces, also by a two letter > abbreviation, and DX for the rest of the world. When an in-state > works another in-state we exchange the three letter county > abbreviation, however, only the first exchange counts for Kansas, so > we have a total of 64 multipliers! > > In its current iteration, Tlf treats the three letter county > abbreviations as a new multiplier for each, but this is clearly wrong > per our rules. To provide an accurate log summary I use a custom > Python script to process the log after the event. It would be nice > to have Tlf count the multipliers properly and verify the entered > exchange against the list to avoid typing errors. > > How best can we accomplish this? > We will look into it, but it would be nice to have some more information. Can you please provide us with your logcfg.dat, a sample log with marked errors/problems and maybe your python script as a starter? 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- pgpO560YJytHG.pgp Description: Digitale Signatur von OpenPGP ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
