DevIO Anpassung

[Sidey]

Hi,

ich würde das Thema Absturz nach update - verursacher Signalduino? mal gerne hier aufgreifen. Es wurde ja schon einiges dazu im verknüpften Beitrag geschrieben. Da gehört die weitere Diskussion aber nicht hin.

Aus meiner Sicht eine Verkettung unglücklicher Umstände, die sich aber verbessern lässt.
Ich hab noch keine konkreten Ideen entwickelt, möchte aber gerne mal meine Sicht auf die Dinge teilen, da Annahmen im Raum stehen, die ich zumindest für diesen Fehler teilweise entkräften kann:

1)
Zum einen habe ich UnitTests auf meine Anpassungen von gestern laufen, das passiert bei mir bei jede Codeänderung automatisch.
Dabei wird auch das Aufrufen der Callback verifiziert.
Der Test lief gestern so gegen 22:30 Uhr fehlerfrei, da ich zum Testen das package von debian.fhem.de verwende

Code Auswählen Erweitern

Setting up fhem (6.0.21624) deutet für mich auf Folgenden Stand hin: Commit 21624. Laut https://debian.fhem.de/ ist das auch der letzte nightly build.

Lässt man den Test mit use strict laufen, taucht er auch auf und mein kompletter Unittest bricht an der Stelle ab (was gewollt ist):

Wer ein Update in FHEM macht, bekommt aber eine neuere "nightly" Version. Egal was ich im Test verwendet hätte, keine der beiden Wege hätte gestern den commit mit der Anpassung hervorgehoben.

Vielleicht lässt sich diese Situation ja verbessern, dass wir uns Entwicklern die Möglichkeit geben, Codeanpassungen vor dem Verteilen via update oder debian package auf unsere Module testen zu können.
Ich habe mich an dieser Stelle absichtlichtlich dagegen entschieden die Version aus dem SVN zu nehmen, da dort manchmal tagsüber mehrere commits zu einer Datei erfolgen

Zu meinen bestehenden Test lässt sich sagen, dass dieser Umstand durchaus aufgeflogen wäre, denn der Fehler wird auf dem Testystem provoziert. Und das ganz ohne, dass ein pysisches Gerät angebunden sein muss:

Code Auswählen Erweitern

2020.04.14 22:17:43 3: Can't use string ("SIGNALduino_Connect") as a subroutine ref while "strict refs" in use at FHEM/DevIo.pm line 238.

2)
Mein Vorab Syntax Check, den ich nur auf meine eigenen Module laufen lasse, findet dieses Zusammenspiel leider nicht. Der Syntax ist ja nicht das Problem.


3)
Ein Blick ins Wiki deutet jetzt auch nicht unbedingt darauf hin, dass die Verwendung von Strings als Funktionsname nicht mehr unterstützt werden. (Von so Codestellen finden sich in FHEM noch etliche mehr)
Wenn man am Interface etwas verändert, wäre es durchaus gut, wenn man eine neue Schnittstelle erstellt und die alte mit etwas Vorlauf abkündigt. Eine Abfrage, ob der übergebene Wert ein coderef ist, könnte man ggf. auch für die Übergangszeit verwenden.



Grüße Sidey

[RichardCZ]

Wenn man am Interface etwas verändert, wäre es durchaus gut, wenn man eine neue Schnittstelle erstellt und die alte mit etwas Vorlauf abkündigt. Eine Abfrage, ob der übergebene Wert ein coderef ist, könnte man ggf. auch für die Übergangszeit verwenden.

Wenn ein use strict ganz fehlt und man macht ihn rein und dann fliegt einem was um die Ohren (ggf. auch verspätet), dann ist das nicht "die Schuld" des Reinmachens von use strict. Kein Mensch hat was an der Schnittstelle verändert oder gar eine neue Schnittstelle erstellt.

Sollte man auf dem Dampfer der Schuldsuche sein, dann könnte man Schuld beim mangelnden Test nach so einer Änderung suchen, aber die unbequeme Wahrheit ist doch, dass die Schuld schon vor langer langer Zeit aufgenommen wurde.

Ich spreche von technischer Schuld (Technical Debt). Diese erfolgte nämlich bereits zu dem Zeitpunkt, als man sich entschied den Code produktiv zu nehmen ohne "use strict & use warnings". Nuja - beim gegenwärtigen Versuch aus dieser Schuldenfalle rauszukommen passieren halt unangenehme Dinge. Man bekommt vor die Nase gehalten wie sehr man eigentlich auf Pump gelebt hat. "Hat aber Jahrzehnte ohne Probleme funktioniert und hätte weiter funktioniert, hätte man nix gemacht." ist bitte ein Satz, den ich hier nicht hören möchte (aber vermutlich trotzdem hören werde).

Man könnte auch weiterhin auf (kleinerem) Pump leben, indem man den Code eben mit der üblichen Dreifaltigkeit

no strict qw(refs);
$symbol->(@args);
use strict qw(refs);

besprenkelt. Ich habe die SItuation sehr genau beobachtet mit use strict, warning rein, warnings raus, use strict raus...
Alleine das sollte einem zu denken geben in was für eine Situation man sich da manövriert hat. Und nein, der "Absturz nach Update" ist nicht das größte Problem in diesem Fall.

Ich glaube heute habe ich via PM jemandem meine "Vision" dieser Dreifaltigkeit vorgeschlagen:

no warnings qw(refs);
ref $callback eq 'CODE' ? $callback->(@args) : Log(1, "Flenn");
no warnings qw(refs);

und ansonsten würde ich ein:

sub _internal_messieblock {
    my $callback = shift;
    my @args     = @_;

    no warnings qw(refs);
    ref $callback eq 'CODE' ? $callback->(@args) : Log(1, "Flenn");
    no warnings qw(refs)

   return;
}

vorschlagen. Dann macht man das nur einmal und hat im code dann nur die _internal_messieblock($fnname, $arg1, $arg2) ... rumhängen

[Sidey]

Sollte man auf dem Dampfer der Schuldsuche sein, dann könnte man Schuld beim mangelnden Test nach so einer Änderung suchen, aber die unbequeme Wahrheit ist doch, dass die Schuld schon vor langer langer Zeit aufgenommen wurde.

War ich nicht, denn ich glaube nicht dass es uns weiterbringt jemandem die Schuld zu geben. Hätten wir ein übergreifendes Testvorgehen, und meine Tests wären ein Teil davon, dann hätte mein Test nach der Anpassung von DevIo.pm durchlaufen können und den Fehler unmittlebar zu Tage gebracht.
Noch besser wäre natürlich, dass die im Wiki hinterlegte Syntax direkt auf das Perlmodul getestet würde. Naja, das schaff ich bei meinen Sachen halt auch kaum.

Ich spreche von technischer Schuld (Technical Debt). Diese erfolgte nämlich bereits zu dem Zeitpunkt, als man sich entschied den Code produktiv zu nehmen ohne "use strict & use warnings". Nuja - beim gegenwärtigen Versuch aus dieser Schuldenfalle rauszukommen passieren halt unangenehme Dinge.

Ja, diese Schulden sind bereits vorhanden. Die lösen sich leider auch nicht mehr ohne Tilgung auf

sub _internal_messieblock {
    my $callback = shift;
    my @args     = @_;

    no warnings qw(refs);
    ref $callback eq 'CODE' ? $callback->(@args) : Log(1, "Flenn");
    no warnings qw(refs)

   return;
}

Gib es schon fast und nennt sich CallFn.Die Abfrage nach 'CODE' ging mir in etwa auch so durch den Kopf mit der Logausgabe für die Entwickler.