Re: [Tlf-devel] Fw: WARC bands

[Thomas Beierlein]

Am Fri, 24 Jan 2014 09:13:14 -0600
schrieb Nate Bargmann <address@hidden>:

> * 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.
> 
Yes, I think we are already on that way. The problem is the 'breaking
out'. The code at the moment is very intertwisted. But I have some
ideas already and there were more suggested here on the list. I just
wanted to finish the 1.2.0 version before going into major
restructuring.

> > 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 
> part better done by each UI? 

Interesting idea. Until now I was in favor of a plain text file.
but I did some quick lookup. SQLite would make some task for reading,
writing and especially editing the log much more easy.

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

I see your point here. But than you couple a lot of the internal working
logic to the database approach. That is a little bit against the idea of
different exchangeable back-ends.

> > 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:
> > ...
> 
> 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).  

It got also much more less important as we use cabrillo in most cases.

>  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).  
> 
While you do not need the 'exact' total score we need to score the
entries anyway by points and multi. During contest you want to know
which multis are missing, if waiting for some station is worth the
time, which special bonus you miss and so on.

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

Sorry, I have to disagree here. You are right on that the key:value
paradigm allows an easy control of internal working of a program. But
you can only control what already is build in. 

I looked at some newer contest definitions in last time and found very
creative rules here: different points per band and mode, different 
scoring for special stations, bonus points .... And I thought how to
implement it. And I see not way to catch all that variety easily by
built-in logic. Contest organizers are much too intentive and will
always find new rules you have not dreamed about.

I think a lot of the rules can be supported by a well chosen set of
internal functions, controlled by keywords (or key:value pairs). But
there will always be dead ends. And instead in such cases each time to
hurry to find someone to code that new algorithm, to turn on your
compiler and make a new tlf I would like to have a way to extend tlf
for that special case on a relatively easy way.

Please get me right here: The most contests should be going without
a need for scripting, but if it doesn't you have that joker back in
your sleeve.


> 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).
> 
I already have the GKeyFile on my my to do list for a rework of tlf's
configuration logic :-). Thats why I already started using it for the
cabrillo format definitions.

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

You are totally right here. When I wrote about writing tlf in python in
had no library in mind. There are well established bindings to a C
library or a lot of languages and that is an very important reason to
stay with C here.
> 
> 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!

They make a lot of sense! Thanks for starting the discussion.

73, de Tom
> 
> 73, de Nate >>
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--