Re: What is the tlf future?

[Martin Kratoska]

Python3 ... I spent several hours with the error message
==========================
Traceback (most recent call last):
  File 
"/home/martin/cqrlog-data-checker-main/cqrlog-data-checker/dxcc_checker.py", 
line 3, in <module>
    import tools
  File 
"/home/martin/cqrlog-data-checker-main/cqrlog-data-checker/tools.py", 
line 3, in <module>
    from rich.console import Console
ModuleNotFoundError: No module named 'rich'
==========================
while trying to check the CQRlog country files with my checker (made by 
OK2CQR, attached) which worked perfectly with ver. 3.9.
The only change was upgrade from 3.9 to 3.10.

I must be stupid ... or?

73,
Martin, OK1RR

P.S. This is the reason why I HATE Python!





Dne 14. 10. 22 v 14:53 Csahok Zoltan napsal(a):
> Hi Martin,
>
> You have probably experienced the Pyhton 2-to-3 switchover that caused a number 
> of troubles.
> Since 2020 version 3 is the only active one and as far as see it's reasonable 
> stable.
> Of course things can change, but I see no future issues at the moment.
>
> Regarding the development of TLF I can only give my point of view.
> For me a big pro that is can run in a single terminal without any
> desktop environment involved. It also fits in my unix-like approach:
> "do one thing and do it well". A loggers task is to allow logging QSOs
> (meaning also helping sending the right messages) and as a bonus
> it does score calculation, a bandmap view, and can save the log ready to be 
> submitted.
> It can also control the rig, but the actual low level control is done via 
> Hamlib.
> Same for keying: any cwdaemon compatible program can be used.
> Or for voice messages: we let external tools play or record them.
> All these are just as loosely coupled as neccessary.
> As I use mostly the same rig+keyer rigctld and cwdaemon are
> both started automatically at system boot. No need to touch them later on.
>
> Configuration is typically a one time task, normally done before the contest.
> I'm quite OK with editing some text files, see no benefit of a GUI.
> Nevertheless it could be added even as a companion tool,
> just as it was done for a graphical bandmap 
> (https://github.com/zcsahok/tlf_bandmap)
> The very first step would be to come up with a usable design.
> Who and when implements it depends on the priorities and resources available
> to the involved parties, as always.
>
> In the last few years the somewhat rusty code base was considerably improved.
> My goal was to be able to add new contests reasonably easily and also
> to be able to run a contest end-to-end until generating a Cabrillo file.
> We still have a number of open topics and broken features (like networking)
> that will need considerable efforts. But all in all I see a remarkable progress.
> What is vital is the user feedback as it help us stay on the right track.
>
>
> 73,
> Zoli

cqrlog-data-checker-main.zip
Description: Zip archive