tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] Fw: WARC bands


From: Ervin Hegedüs - HA2OS
Subject: Re: [Tlf-devel] Fw: WARC bands
Date: Fri, 24 Jan 2014 22:14:09 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi all,

(this is my reply to message of Thomas and Nate),

On Fri, Jan 24, 2014 at 09:13:14AM -0600, Nate Bargmann wrote:
> * On 2014 24 Jan 00:33 -0600, Thomas Beierlein wrote:
> > While I was talking about scoring and contest handling in my mail, you
> > are quite right. It would be good to write a completely new tlf.
> > Question is have we time and man power to do it? Anyway - I am in for
> > it. 

I'm in too,

> While it is a large task, it will be manageable when broken down into
> prioritized smaller tasks.  I would say pick a module and break it out
> first then move on to another.

right,

> > At the moment I would favor a tab separated list for the log format
> > with a header line documenting the order and contents of the columns.
> > That can be easily parsed, extended and even read and written without a
> > special program. It can also be handled with any scripting language
> > without problems.
> 
> 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.  Maybe this is a
> part better done by each UI?  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.

- the "backend" module is just one of the most thing, which
  should be good to make as "multiple"
- every external dependency decrease the portability of software,
  and may be that's not problem, and that modul add more advantage
  than that

> > Besides the above comments one major step forward would be an unified
> > handling of the mass of contest rules around. Ervin did already wrote
> > about that in his answer to your mail. I would like to add a little bit
> > here:
> > 
> > If we look over to other contest programs we see that most of them have
> > the different contests hard coded and can simply choose which one to
> > use. Easy for the user - hard for maintenance (it requires a lot of man
> > power for development).

this is very true... :)

> > N1MM seems to be an exception - he has a
> > contest rule generator for simple cases. 
> > 
> > Tlf tried another way: Some hard coded contests and some configuration
> > keywords to roll your own rule file. At present the chosen keywords
> > normally solve only special problems. It is not easy to know which one
> > to use without looking into the code and often we miss a keyword and
> > hurry to add just anther special one (Sounds familiar?)

absolutely...

> > As I see it the following could be a good way:
> > 
> > - Have some very general keywords to roll your own simple contest. The
> >   MY_COUNTRY/MY_CONTINENT_/DX_ POINTS may be a good idea for point
> >   scoring.
> > - Have some simple general configurable rules for multiplier counting:
> >   What to look at (call, exchange,...), what qualifies as a multi, once
> >   per band or once per contest,
> >   e.g. COUNTRY, DXCC, PER_BAND or CALL, PREFIX, PER_CONTEST
> > - Allow more than one rule and allow to specify how to combine them,
> >   e.g. DXCC and WPX-PREFIX added

right,

> > - What can not be done these simple way (different points per band,
> >   special station bonus points, .......) have to be hard coded. These
> >   should be doable by the normal ham without a knowledge of the inner
> >   working of the program and without a need to compile code for the
> >   program.

I completely agree,

> >   As Ervin told there are two ways. I too would prefer the second one -
> >   using a scripting language for that and I too think python is the way
> >   to go. It is easy to learn and program, the scripts can be debugged
> >   and tested independent of tlf and can be easily integrated into tlf.
> >   (I even did some thinking if we can not write the whole program in
> >   python...)

(as I wrote, I think the use of any markup language (which is the
user friendly - I prefer YML) would better than traditional
config file: VARIABLE=value)

> In general, I agree, but maybe too much effort is being put into
> calculating the score?  I know it is something the contest loggers have
> always done and it seems to be expected, but it seems like the final
> score calculated by the contest sponsor was never the same as that which
> I submitted (that could be a "here" thing, though).  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).  A module that parses the log and then does a score
> calculation after the event may have its uses.
> 
> That paragraph may have ruffled a few feathers!

Sure, the point calculation isn't an important thing - I mean, it doesn't
matter that is it accurate or not. But then why do we write that
code, which calculates the points? Only for approximate value? :)

Anyway, there are many other things which are important, and
difficult to hardcode: multipliers, band weights, exchange's,
check the received data's, and so on. If I need to ordering
these, the most important is the completely exchange handling.

> Ideally, writing a contest definition should not require knowing or
> learning a scripting language. 

that's really true.

And I ask you: how many people write any rule file for Tlf? In
turn that's not a scripting language :):)

> Most of what is needed seems to fit into
> the key:value paradigm and there are various ways to represent that.
> Among the easiest for non-programmers to understand would be the
> GKeyFile:
> 
> https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html
> 
> which has a syntax similar to .ini files found on Windows but is
> extended in several respects.  It is easy to read and would be easy for
> people with a list of keywords and possible values either in an example
> file or manual page to understand and submit a new event file to the
> developers. (Note that I am considering these arguments for extending
> Hamlib at some future time as well so this point has been rattling
> around in my brain for some time).

as I see this is a bit better than traditionally key=value 
structure.

Anyway: the hamlib users don't get any predefined rule files, and
backwards: they don't need complex rule files (I think :))

Back to above: there aren't too many people, who needs to write
rule files. As I wrote, the TRLog supports more than 60, N1MM (as
I see) supports more that 150 contest (on HF - N1MM supports VHF
too). Tlf has 19 rule files, but from those it's easy to make
some more contests - but this number is very small amount...

To coding so much contest rule is very hard work.

To make so much rule file is not possible at this time with this
structure.

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

I met with this solution at Zorp firewall. Generally, the
application level firewall config is very-very difficult. Thence
I met many app level firewall, with experimental GUI - but none
of them could follow the Zorp.
 
> 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 don't see the relationship between this topic. This wouldn't be
a library - this would be an application (the point of view of
user)

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

Not at all.

I think we're talking about two different thing :)

The role of Python is _only_, that it generates values of many
configurable variables. In this case, the one or more "rule file"
is a Python script. When the application starts, it reads the
Python script(s), and evaluates them. Now, the variables (in
different structures, as you want) are presented in your code :)

This is a (very basic(!), simple(!) and ugly(!!!)) example:

class MyMultiList(TlfMultiList):
    """ this class inherited from TlfMultiWeight, which is
        the default multiplier weight descriptor """
    def __init__(self):
        if self.MyCountry == "W":
            self.MultiList = self.DXCC
        else:
            self.MultiList = self.USAStates

where MyCountry, MultiList, DXCC and USAStates are coded
properties, but there is a _possibility_ to replace any of that.

This modell generates the current multiplier list, depending your
country. You can make any relationship to another classes, and
can read or write that variables. All of them makes the "rule".

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

Yes, I think we're talking about two different things :):)
 
> Working with Xdx for the past couple of weeks introduced me to the
> number of facilities provided by Glib and Tlf already makes use of some
> Glib functionality so there is no additional dependency by choosing to
> use it in more areas.  It has a number of data structures that should be
> useful (and are already used in Tlf) that *should* reduce development
> time and some bugs.

I think, we just can solve the problems in short way with this
way. A contest logger software needs a very complex configuration
structure - this is the pitfall or advantage one of them :)

I didn't hear about Xdx before - could you make some comparison
of the configuration method with Tlf and Xdx?

> Hopefully these mental ramblings make some sense!

Yes, sure, absolutely. 


thanks,

73,

Ervin
HA2OS

ps: I know I'm the last one who connected to this project. I
really don't want to "clever" - but when you wrote your idea
about the rewrite from scratch, I felt completely my
own - sorry :)


-- 
I � UTF-8



reply via email to

[Prev in Thread] Current Thread [Next in Thread]