Re: [Tlf-devel] bugs in tlf-1.2.0_pre2

[w9ya]

Hey all;

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.

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

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.

Thanks for reading this far OM es

VY 73 de;

- Bob
w9ya


On Mon, Sep 10, 2012 at 6:55 AM, Thomas Beierlein <address@hidden> wrote:
> Hi Martin, hi Fred,
>
> Am Mon, 10 Sep 2012 11:44:41 +0200
> schrieb Martin Kratoska <address@hidden>:
>
>> 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
>> > address@hidden
>> > https://lists.nongnu.org/mailman/listinfo/tlf-devel
>> >
>>
>>
>> _______________________________________________
>> Tlf-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/tlf-devel
>
>
>
> --
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
>
>
> _______________________________________________
> Tlf-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tlf-devel