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

[w9ya]

Hey again !;

On Mon, Sep 10, 2012 at 10:13 AM, Thomas Beierlein <address@hidden> wrote:
> Hi Bob,
>
> Am Mon, 10 Sep 2012 07:35:23 -0600
> schrieb w9ya <address@hidden>:
>> 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 <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
>
>
>
> --
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
>
>
>
> --
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
>
>
> _______________________________________________
> Tlf-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tlf-devel