"use POSIX" aus einem Modul werfen - Beispiel WeekdayTimer

Begonnen von Beta-User, 25 März 2020, 12:21:47

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

ich nehme mal Bezug auf das hier:
Zitat von: Beta-User am 24 März 2020, 09:02:49
...würde mich auch interessieren, habe grade mal geschaut, ob ich den WeekdayTimer "verbessern" kann

Kurz zum Hintergrund:
Ich bin "Gelegenheitsmaintainer" und habe praktisch nur diverse bestehende Module übernommen und teils weiterentwickelt. Kurz: mein Verständnis reicht grade mal eben, um das einigermaßen unfallfrei hinzubekommen, die Module selbst stammen von zwei sehr unterschiedlichen Entwickertypen:
Die Timer-Module (WeekdayTimer und RandomTimer) stammen wohl auch aus der Feder eines Gelegenheitsmaintainers, der den Code ursprünglich als myUtils-Code für sich selbst entwickelt zu haben scheint und den Code der Module (es gehörten noch zwei weitere zu dem Paket: TWILIGHT und HEATING_CONTROL) teils stark miteinander verschränkt hatte (mit TWILIGHT als "Leitmodul", das zentrale Funktionen enthielt).
Die anderen (MySensors-) Module wurden von jemandem entwickelt, der teils wohl auch Code - soweit er nicht FHEM-Spezifisch war - in cpan einchecken wollte (?) und z.B. mit Packages gearbeitet hat und einiges an zentralem Code bereitgestellt hat, der dann auch in den MQTT-Modulen der ersten Generation verwendet wird (GP_Utils).

Zum eigentlichen Thema:
Im WeekdayTimer steht jetzt also zu Beginn das "ungeliebte" "use POSIX".
Jetzt habe ich aber leider keine wirklich zündende Idee, wie ich sicherstellen kann, dass das Modul auch noch funktioniert, falls im gesamten FHEM-Code sämtliche "use POSIX" irgendwann eliminiert sein sollten. Kurz:

Wie kann ich auf einfache Weise feststellen, welche Funktionen aus POSIX WeekdayTimer tatsächlich auch nutzt?
Geht das auch irgendwie automatisiert?
(Dann könnte ich nämlich auch den RandomTimer darauf durchsehen, ob der ohne entsprechendes "use" nicht "versehentlich" doch eigentlich das "use" haben müßte und auf Funktionen aus POSIX zugreift...).

Oder habe ich das Problem gar nicht richtig erfaßt?

Danke vorab für erhellende Worte,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Eine gute Möglichkeit wäre wenn Du Dein Modul auf packages um stellst. Ein neuer Namensraum bedarf auch neuer use sofern nicht mittels Vererbung gearbeitet wurde.
Gehe aber nicht davon aus.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Was den WDT angeht, ist das mit Packages nicht ganz so einfach: Heating_Control nutzt den intern nämlich auch noch weiterhin. Gibt zwar nur noch 105 in statistics auftauchende Nutzer, aber vor FHEM 6.2 (oder wenigstens 6.1) ist das m.E. keine Option - da fliegt Heating_Control nämlich voraussichtlich raus, jedenfalls werde ich da die Maintainer-Rolle dafür nicht weiter übernehmen.
Packages ist dafür auch noch an einer anderen Stelle evtl. "gefährlich": das setzt iVm. mit weekprofile nämlich voraus, dass JSON extrahiert werden kann. Die entsprechenden Code-Teile läd aber bereits weekprofile in main... Wenn man das ändert, wird es ggf. "lustig".

Für den RandomTimer mache ich das mit packages ggf. bei Gelegenheit, aber das ist "low prio" - aber wenn du magst, kannst du gerne einen patch dafür liefern. Das wäre ggf. für weitere Maintainer als gutes Beispiel hilfreich? der RT-Code ist ja nicht besonders umfangreich...

Was WDT angeht, bin ich jetzt schlicht Rudis Beispiel gefolgt und habe die "use POSIX;"-Zeilen rausgeworfen (und an ein paar  weiteren Stellen auch, die "mir gehören"). Solange keiner in fhem.pl was beschränkt, sollte es egal sein, aber ich wäre weiter daran interessiert zu erfahren, wie wir die "richtigen" (=zukünftig ggf. notwendigen) use's finden können...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RichardCZ

Zitat von: Beta-User am 25 März 2020, 12:21:47
Wie kann ich auf einfache Weise feststellen, welche Funktionen aus POSIX WeekdayTimer tatsächlich auch nutzt?
Geht das auch irgendwie automatisiert?

Es geht halbautomatisiert. Max. 5 Minuten Aufwand (bei mir im Repo, weil ich viele Prototypes schon losgeworden bin):

Man kommentiert use POSIX aus und ruft "perl -c 98_WeekdayTimer.pm" auf.

Dann schlägt einem erstmal eine Welle globalen Unrats ins Gesicht:

$ perl -c 98_WeekdayTimer.pm
Number found where operator expected at 98_WeekdayTimer.pm line 212, near "Log 3"
Global symbol "$readingFnAttributes" requires explicit package name (did you forget to declare "my $readingFnAttributes"?) at 98_WeekdayTimer.pm line 49.
Global symbol "%modules" requires explicit package name (did you forget to declare "my %modules"?) at 98_WeekdayTimer.pm line 91.
Global symbol "%defs" requires explicit package name (did you forget to declare "my %defs"?) at 98_WeekdayTimer.pm line 117.
Global symbol "%attr" requires explicit package name (did you forget to declare "my %attr"?) at 98_WeekdayTimer.pm line 124.
Global symbol "%attr" requires explicit package name (did you forget to declare "my %attr"?) at 98_WeekdayTimer.pm line 124.
Global symbol "%defs" requires explicit package name (did you forget to declare "my %defs"?) at 98_WeekdayTimer.pm line 125.


Also fügt man das ein worüber er sich beschwert. Im Endeffekt stellt man den Perl Parser wie folgt still:

package main;
use strict;
use warnings;
#use POSIX;  # <---- das wollen wir

#### MORPHIUM PFLASTER START

sub Log ($$);
sub Log3 ($$$);

my (%attr, %modules, %defs);
my $readingFnAttributes;
my $init_done;

use constant {
    DAYSECONDS    => 86400,
    HOURSECONDS   =>  3600,
    HOURMINUTES   =>    60,
    MINUTESECONDS =>    60,
};
#### MORPHIUM PFLASTER END

use Time::Local 'timelocal_nocheck';


Du siehtst zwischen dem auskommentierten use POSIX und dem use Time::Local ein paar sachen aus fhem.pl die ich reingeknödelt habe.
Das ist nur temporär. Macht man das und es kommt:

$ perl -c 98_WeekdayTimer.pm
98_WeekdayTimer.pm syntax OK


weißt Du jetzt, dass man POSIX bedenkenlos rausschmeissen kann. Und Du siehst natürlich auch welche Bindungen an globale Werte bestehen.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Beta-User

OK,

sogar ohne das "Morphium" wäre mir jetzt soweit klar gewesen, dass es unbedenklich war, das rauszuwerfen...

Daher: DANKE für den Hinweis auf "perl -c"! Solche "Kleinigkeiten" sind wirklich hilfreich ;D .

Jetzt habe ich diese Übung gleich beim RandomTimer gemacht und komme aber leider nicht drauf, was mir der Parser mit dieser Rückmeldung hier sagen will (der Rest ist "ähnliches unverdächtiges Gemüse" wie beim WeekdayTimer):
Zitatsyntax error at 98_RandomTimer.pm line 319, near "} else"
Die Klammersetzung scheint mir ok zu sein, "else" finde ich unverdächtig und Rückmeldungen, dass das Modul irgendwelche Fehler hätte, sind mir auch nicht bekannt...

Hast du auf die Schnelle eine Idee, das ich als DAM (M=Maintainer) da übersehe?

Oder sollte man für sowas hier dann gleich ein gesondertes Thema aufmachen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RichardCZ

Zitat von: Beta-User am 25 März 2020, 13:44:55
Hast du auf die Schnelle eine Idee, das ich als DAM (M=Maintainer) da übersehe?

Oder sollte man für sowas hier dann gleich ein gesondertes Thema aufmachen?

$ perl -c 98_RandomTimer.pm
98_RandomTimer.pm syntax OK

Mein Tipp wäre jetzt, dass Du irgendwo die Syntax zerschossen hast. Also noch 3x prüfen, ansonsten neuer thread und dort das FIle anhängen
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.