Re: [Tlf-devel] Fw: WARC bands

[Nate Bargmann]

* On 2014 24 Jan 00:33 -0600, Thomas Beierlein wrote:
> While I was talking about scoring and contest handling in my mail, you
> are quite right. It would be good to write a completely new tlf.
> Question is have we time and man power to do it? Anyway - I am in for
> it. 

While it is a large task, it will be manageable when broken down into
prioritized smaller tasks.  I would say pick a module and break it out
first then move on to another.

> At the moment I would favor a tab separated list for the log format
> with a header line documenting the order and contents of the columns.
> That can be easily parsed, extended and even read and written without a
> special program. It can also be handled with any scripting language
> without problems.

This is where I think multiple storage "backends" could be useful.
Perhaps I am a bit naive here, but an SQLite backend, for example,
would put the work of parsing on the SQLite engine.  Maybe this is a
part better done by each UI?  OTOH, once the library is used to setup
the event parameters, it would also be easy to write an SQL query based
on call per band, or call per event, or call per mode, or call per
band/mode, etc.

> Besides the above comments one major step forward would be an unified
> handling of the mass of contest rules around. Ervin did already wrote
> about that in his answer to your mail. I would like to add a little bit
> here:
> 
> If we look over to other contest programs we see that most of them have
> the different contests hard coded and can simply choose which one to
> use. Easy for the user - hard for maintenance (it requires a lot of man
> power for development). N1MM seems to be an exception - he has a
> contest rule generator for simple cases. 
> 
> Tlf tried another way: Some hard coded contests and some configuration
> keywords to roll your own rule file. At present the chosen keywords
> normally solve only special problems. It is not easy to know which one
> to use without looking into the code and often we miss a keyword and
> hurry to add just anther special one (Sounds familiar?)
> 
> As I see it the following could be a good way:
> 
> - Have some very general keywords to roll your own simple contest. The
>   MY_COUNTRY/MY_CONTINENT_/DX_ POINTS may be a good idea for point
>   scoring.
> - Have some simple general configurable rules for multiplier counting:
>   What to look at (call, exchange,...), what qualifies as a multi, once
>   per band or once per contest,
>   e.g. COUNTRY, DXCC, PER_BAND or CALL, PREFIX, PER_CONTEST
> - Allow more than one rule and allow to specify how to combine them,
>   e.g. DXCC and WPX-PREFIX added
> 
> - What can not be done these simple way (different points per band,
>   special station bonus points, .......) have to be hard coded. These
>   should be doable by the normal ham without a knowledge of the inner
>   working of the program and without a need to compile code for the
>   program.
> 
>   As Ervin told there are two ways. I too would prefer the second one -
>   using a scripting language for that and I too think python is the way
>   to go. It is easy to learn and program, the scripts can be debugged
>   and tested independent of tlf and can be easily integrated into tlf.
>   (I even did some thinking if we can not write the whole program in
>   python...)

In general, I agree, but maybe too much effort is being put into
calculating the score?  I know it is something the contest loggers have
always done and it seems to be expected, but it seems like the final
score calculated by the contest sponsor was never the same as that which
I submitted (that could be a "here" thing, though).  IMO, at best a raw
score is only good for posting to 3830 and at worst requires a lot of
coding and debugging effort.  I honestly think that not calculating a
score in real time relieves much of the complexity of writing an event
definition (personally, I found the displayed score to be a distraction
over the years).  A module that parses the log and then does a score
calculation after the event may have its uses.

That paragraph may have ruffled a few feathers!

Ideally, writing a contest definition should not require knowing or
learning a scripting language.  Most of what is needed seems to fit into
the key:value paradigm and there are various ways to represent that.
Among the easiest for non-programmers to understand would be the
GKeyFile:

https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html

which has a syntax similar to .ini files found on Windows but is
extended in several respects.  It is easy to read and would be easy for
people with a list of keywords and possible values either in an example
file or manual page to understand and submit a new event file to the
developers. (Note that I am considering these arguments for extending
Hamlib at some future time as well so this point has been rattling
around in my brain for some time).

Scripting could be useful, but may be a bit over rated?  There is a lot
of software that includes some scripting capability or plugin and in my
own experience it is rarely used.  I could well be wrong on this point.

IMO, a library should be written in C due to the formalized standards of
the language and the standardized ABI.  Every higher level language in
popular use has a means for interfacing to C libraries so it is a lowest
common denominator.  I certainly have no interest in trying to do this
in Python for various reasons.  How would a UI written in C link to a
Python "library", for example?  Since a lot of the code that would make
up such a library is already written in C in Tlf and maybe some other
software to borrow from, it is mostly written and debugged already.

Working with Xdx for the past couple of weeks introduced me to the
number of facilities provided by Glib and Tlf already makes use of some
Glib functionality so there is no additional dependency by choosing to
use it in more areas.  It has a number of data structures that should be
useful (and are already used in Tlf) that *should* reduce development
time and some bugs.

Hopefully these mental ramblings make some sense!

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us