Hey again !; On Mon, Sep 10, 2012 at 10:13 AM, Thomas Beierlein <t...@forth-ev.de> wrote: > Hi Bob, > > Am Mon, 10 Sep 2012 07:35:23 -0600 > schrieb w9ya <w...@qrparci.net>: >> If you want some ideas on how to do the various things listed below >> (including the rig freq. input, flexible cabrillo output defined from >> without the in-line program code, point and mult. definition from >> without the subroutines, and etc....), you can check out another open >> source logging program that I have been maintaining the last year or >> so: yfktest. >> > To be honest: yfktest gave me some of the ideas to think about :-).
COOL ! > >> One feature, the incorporation of coding algorithms from within each >> contest's definition file (called a ".def" file and unique to each >> contest) was added many years ago as coding feature designed to get >> away from hardwired/in-line coding of scoring (sub)routines you >> mention below. > > Well it is a little bit easier to do in yfktest because of the use of > perl as programming language. You can easy refer to the variables > internally used by their names. In C that names are only accesible at > compile time and we need a little bit of interpretation each time we > want to name internal variables in such a config file. O.K. > >> This code was authored by ws6z. To be useful it >> did/does require a more robust way of combining mults and points, and >> much of that work I did more recently. >> > Nice to know. > > Last time I had a look (some month ago) there were still > some hard coded algorithms for scoring points and multis for some of > the contests. I want to give up such algorithms alltogether, but let us > see if we can manage to that point Well, I kept all of the in-line subroutine coding intact as it is working. But I want to use the def. file coding as much as possible and even extend its' capability further. . > >> To wit: I finally got to use this incorporated feature in the two most >> recent contests that I added: cwops-open and uba-fd. It works fb and >> might be something worth studying. The two contest files for these can >> be examined in the svn code base in the "defs" folder. You can begin >> by going to my website here: >> >> < bfinch.net > >> bfinch.net >> >> Anyways, I understand the need for different contest logging programs, >> and I am a big supporter of tlf even though I decided to put my >> efforts towards another set of code. i.e. I find it nice to have >> something like tlf AND yfktest available for a variety of useful >> reasons not the least of which is to offer choice and the fruits from >> such choice. >> >> Oh yeah: I hope I haven't offended anyone with the suggestion to code >> review the yfktest code for one way towards the feature implementation >> you are searching for. It is not my intention to offend but rather to >> help. > > At least not me :). It is always a good idea too look into neighbours > garden and see what flowers they grow .... > > Thanks for your suggestions, Your always welcome es Vy 73 om de; - Bob w9ya > > 73 de Tom DL1JBE. >> >> Thanks for reading this far OM es >> >> VY 73 de; >> >> - Bob >> w9ya >> >> >> On Mon, Sep 10, 2012 at 6:55 AM, Thomas Beierlein <t...@forth-ev.de> >> wrote: >> > Hi Martin, hi Fred, >> > >> > Am Mon, 10 Sep 2012 11:44:41 +0200 >> > schrieb Martin Kratoska <mar...@centrum.cz>: >> > >> >> Hi Fred, >> >> >> >> although I cannot find it (now) in the source code, I suspect the >> >> intial work of Rein, PA0R, which included some "hardwired" >> >> contests. >> > >> > You are quite right. Nearly all contest logic in TLF is hardwired. >> > That goes for counting points and multipliers, what is to be >> > displayed in the summary, the calculation of claimed points, the >> > format of the log and the cabrillo file and much much more. >> > >> > While the code for that contests do mostly work the problems are in >> > the area of self defined contests. Rein did some work to allow >> > giving more or less points to different class of QSO's and also a >> > start of a multiplier logic (WYSIWYG and others). But that always >> > solved problems only for special contests. So by time there were >> > more and more special rules, which do not fit together for modern >> > contests. As Martin said it must be fixed soon. >> > >> >> If tlf should have any future, it must be cleaned from the remnants >> >> of hardwired contests, also it must be freely configurable. >> > >> > Right. But it is a lot of work and time is sparse. >> > >> > The actual work on the 1.2 series is a start in that direction. It >> > will have two main new features: >> > >> > - record actual frequencies from rig as requested by more and more >> > contests (that part is done and can be tested in 1.2.0_pre1 and >> > pre2) and >> > - a complete new routine to write the cabrillo logs. >> > >> > (First as you both pointed out, the actual implementation of >> > write_cabrillo is broken and works only for some special contests. >> > Second we have some new contests which are not covered by the >> > routine at all.) >> > >> > The new implementation will be controlled by a textual >> > description of the cabrillo line which points out what to put in >> > the line, where to put it and how much characters the field should >> > be have (on github you can have a first look at that description >> > syntax in share/cabrillo.fmt). >> > That format description can be extended by each user of tlf so we >> > can easily adapt new contests not covered in tlf's code. >> > >> > I am just on the way to complete the second part. I hope to finish >> > it in the next two weeks. That should fix the wrong cabrillo >> > formats and is a first step to make the whole tlf completely >> > configurable. >> > >> > >> > To make the whole tlf contest logic free configurable there are some >> > more steps to go: >> > >> > - specify rules to give points to qsos and to count multis (What are >> > points given for, how to handle unequal points for different >> > bands, modes, for low power stations and so on. What counts as a >> > multi, which possibilities are needed to have uncommon multi >> > rules....) >> > - specify what to display on the summary panel and how to calculate >> > the total score >> > - find an easy way to formulate theses rules in a consistent text >> > file. >> > >> > >> >> The mess can be tracked down in the rule files. Although you define >> >> your own contest, your rule file still needs to begin with a >> >> CONTEST=**** directive which has ***PROBABLY*** another meaning >> >> than just a contest name. >> > >> > No, in the rules file that information is quite useless. It has >> > only to go to the logcfg.dat. It is just in the rule file to make >> > sure it is the right file. >> > >> >> If you put there CONTEST=cqww you will get a >> >> hardwired (predefined) DXCC and CQZ mults. In other hand, you don't >> >> need to define any mult, the hardwired items are still there. >> >> >> >> My sincere apologies if my conclusions are totally false, actually >> >> I have a mess in my files since tlf 0.9.3 and my programming >> >> (un)skills preventing me from more thorough research of tlf >> >> internals. I hope that some day a tlf expert comes with a deep and >> >> thorough explanation of the tlf mechanics. >> >> >> > Yeah. tlf's internal working is quite a hardcoded mess. It took me >> > nearly a year to understand its working (at least I hope so). The >> > whole logic is scattered around a lot of places which makes it >> > difficult to change a single piece without doing damage on other >> > things. >> > >> > In the last months I did a lot of cleanup to uncouple some of that >> > code and make it more maintainable. but it is far from done. >> > >> > 73, de Tom DL1JBE >> > >> >> 73 >> >> Martin, OK1RR >> >> >> >> Dne 10.9.2012 11:00, FS napsal(a): >> >> > The interesting thing is that, in some contests like CQWW this >> >> > works, in some not. If it works the number is printed with 4 >> >> > digits. >> >> > >> >> > 73 Fred >> >> > >> >> > On 09/10/2012 01:19 AM, Martin Kratoska wrote: >> >> >> The September CWopen by CWops discovered following bugs in >> >> >> tlf-1.2.0_pre2: >> >> > >> >> >> Another bug - if defining the part of exchange containing the >> >> >> serial number (with #), the serial is actually not put into log, >> >> >> the # character appears instead. >> >> > >> >> > _______________________________________________ >> >> > Tlf-devel mailing list >> >> > Tlf-devel@nongnu.org >> >> > https://lists.nongnu.org/mailman/listinfo/tlf-devel >> >> > >> >> >> >> >> >> _______________________________________________ >> >> Tlf-devel mailing list >> >> Tlf-devel@nongnu.org >> >> https://lists.nongnu.org/mailman/listinfo/tlf-devel >> > >> > >> > >> > -- >> > "Do what is needful!" >> > Ursula LeGuin: Earthsea >> > -- >> > >> > >> > _______________________________________________ >> > Tlf-devel mailing list >> > Tlf-devel@nongnu.org >> > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- > > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- > > > _______________________________________________ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
