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 <n...@n0nb.us>: > > > > 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 _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
