Re: [Tlf-devel] Fw: WARC bands

[Ervin Hegedüs]

hi all,

On Sat, Jan 25, 2014 at 07:22:38AM +0100, Thomas Beierlein wrote:
> Am Fri, 24 Jan 2014 09:13:14 -0600
> schrieb Nate Bargmann <address@hidden>:
> > 
> > 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.

and then all backend needs to know all feature? :)
 
> >  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.

yes, that's really true.
 
> > 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. 

yes, in a mathematically modell with this way you can generate
the finite number rules of permutation of usable keys.

In other way, you can "programming" (without hard coding) the
"infinite" number rules :)

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

That's the point.
 
> > 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.

may be I confused here - I don't want to write any part of code
in Python. I just suggested to use that for it would be good to describe
the rule files.


73,

Ervin
HA2OS

-- 
I � UTF-8