[wiregate] Plugin-Entwicklung / Best practices, Warnungen & Co

[Dirk42]

Hallo,

mit neueren WG-Updates ab etwa Version 1.2 wurden für die Plugins sehr sinnvolle Änderungen eingebaut. So werden jetzt zum Beispiel auch Warnungen ausgegeben, wenn Subroutinen mehrfach definiert werden. Denn es ist sicher nicht jedem Plugin-Entwickler klar, dass alle geladenen Plugins den gleichen Funktionsnamen nur einmal verwenden dürfen. Let's go...

Warnung: "Subroutine verify redefined"
Beispiel

2015-10-11 00:18:56.941,1-Wire Monitor.pl,Warning: Subroutine readConf redefined at (eval 36) line 137.

Lösung: Ein anderes Plugin verwendet den gleichen Funktionsnamen. Wenn es sich um die exakt gleiche Funktion handelt, kann die Warnung IMHO ignoriert werden. Ist es nicht die gleiche Funktion, sollte der Funktionsname angepasst werden. Für Plugin abc zum Beispiel vom generischen readConf in abc_readConf.


Warnung: "Variable is not available"
Beispiel

2015-12-27 22:13:09.186,1-Wire Monitor.pl,Warning: Variable "$PluginCycle" is not available at (eval 35) line 5, <CONF> line 42.

Lösung: Die Lösung habe ich noch nicht gefunden - ich habe die Warnung in der Config-Datei, obwohl die Variable vorher im Plugin definiert wurde... habt Ihr Tipps zur Lösung?


Vorsicht mit Plugin-Kopien
Ich lege gern Code-Kopien an - my_plugin.pl wird in my_plugin.pl.old kopiert. Aber Vorsicht... das WireGate führt auch my_plugin.pl.old aus (oder zumindest wird die Datei auch compiliert).

2015-12-09 23:30:20.569,Logikprozessor.pl.old,compiled in 0.2s

Welche Best Practices verwendet Ihr beim Entwickeln von WireGate Plugins? Welche Warnungen in der wiregate_plugin.log lassen sich wie beheben?

Viele Grüße

Dirk

[koend]

Moin,

bezüglich der Warnung "Subroutine xyz redefined" habe ich die folgende Frage:
- Den Code von https://knx-user-forum.de/wiregate/17...sgefuehrt.html verwendend, habe ich die Definition der Subroutinen in die Initialisierung des Scripts verschoben, z.B.:

if (!$plugin_initflag || $plugin_info{$plugname.'_lastsaved'} > $plugin_info{$plugname.'_last'}) {
(...)  
    sub disableVariaTimeProgram {
        knx_write($_[0],1,1.001);
    }
    
    sub enableVariaTimeProgram {
        knx_write($_[0],0,1.001);
    }
}
else {
 (...)
}

Meine Vermutung war, dass dieser Teil des Scripts nur ausgeführt wird nach einem Reboot oder wenn eine neue Dateiversion gespeichert wurde.

Leider scheint dies nicht so zu sein, denn bei jedem zyklischen Aufruf erscheinen diese Fehlermeldungen in wiregate_plugin.log

2015-12-31 22:52:03.764,periodicHVAC,Warning: Subroutine disableVariaTimeProgram redefined at (eval 112203) line 73.

2015-12-31 22:52:03.764,periodicHVAC,Warning: Subroutine enableVariaTimeProgram redefined at (eval 112203) line 77.

Frage ist also: wie können innerhalb eines Scripts Subroutinen definiert werden, so dass diese nicht bei jedem Zyklus eine warning auslösen (und das log file zumüllen)?

Ein zentrales Subroutinen-Skript habe ich schon, möchte das aber nur für Script-übergreifende Logik nutzen (alles für ein Script an einer Stelle und das Durchreichen von Parametern in Perl finde ich nicht so prickelnd).

Vielen Dank für die Hilfe und viele Grüße

[Chris M.]

Perl scheint hier sehr interessante Vorstellungen zu haben was den Scope von Subs angeht...

Ab Perl Version 5.18 gäbe es wohl die Lösung unserer Probleme, lexical subroutines: http://perldoc.perl.org/perlsub.html...al-Subroutines
Wir haben aber 5.10.

Was immer gehen sollte, wären anonyme Subs, aber deren Aufruf hat nicht nur die übliche hässliche Perl-Syntax, sondern eine extrem hässliche Syntax:

my $foo = sub
{
  print "foo";
};

&$foo();

Was evtl. auch gehen könnte wären Packages:

# Plugin-Datei Plugin0815
package Plugin0815;
sub foo
{
  print "foo\n";
}

# Plugin-Datei Plugin0815
package Plugin0815;
sub foo
{
  print "foo\n";
}

Ich weiß aber nicht ob das mit der Plugin-Infrastruktur funktioniert (sowohl interpretiert als auch kompiliert).
-> Hat hier jemand Erfahrungen?
Es löst aber nicht automatisch das Problem das ich habe mit kopierten und wiederverwendeten Plugin-Gerüsten die jeweils spezifisch ausgefüllt werden.

[mfd]

Gibt es inzwischen schon eine Lösung wie man den Müll in den Logfiles los wird - oder besser gesagt, was zu tun ist um die bestehenden Plugins wieder fehlerfrei einsetzen zu können?

[Dirk42]

Eine einfache Lösung gibt es mit dem Patch 1.2.7, hier kann man einfach in der Admin-Oberfläche aktivieren / deaktivieren, ob Warnungen geloggt werden sollen:
Warnungen loggen.jpg
Für Plugin-Autoren ist es "dank" Perl nicht ganz trivial, die Fehler zu beheben. Meinen 1-Wire Monitor habe ich angepasst (muss ich noch im Artikel aktualisieren), indem ich einen "echten" Fehler behoben und die Subroutine zum Einlesen der Config inline in den Code übernommen habe.

[StefanW]

Gibt es inzwischen schon eine Lösung wie man den Müll in den Logfiles los wird - oder besser gesagt, was zu tun ist um die bestehenden Plugins wieder fehlerfrei einsetzen zu können?

Das ist kein Müll, sondern sind durchaus begründete Warnungen. Diese Warnungen sind das Ergebnis eines Push-Request aus der Community. Ab der 1.2.8 (noch Beta) wird der Grund für die Warnungen besser erklärt.

Entweder werden wir kritisiert, weil wir Push-Requests - vor zwei Jahren zögerlich - umgesetzt hatten oder es wird getadelt, weil nicht jeder mit dem Ergebnis eines Push-Requests zufrieden ist.

==> Liebe Community, überlegt euch bitte was ihr wollt. Wir haben keine Lust, der Spielball dazwischen zu sein. Wenn ihr wollt, dass wir Eure Push-Requests umsetzen, dann respektiert auch das Ergebniss. Wenn ihr wollt, dass wir intern zuerst darüber befinden sollen ob es umgesetzt wird, dann lassen wir künftig alles weg, was aufwändig erklärt werden müsste, dann respektiert ihr dieses dann bitte ebenfalls. Aber bitte, einigt Euch.

lg

Stefan

[heckmannju]

um was geht es den bei den Push-Requests?

[XueSheng]

Gibt es inzwischen schon eine Lösung wie man den Müll in den Logfiles los wird - oder besser gesagt, was zu tun ist um die bestehenden Plugins wieder fehlerfrei einsetzen zu können?

Ich glaub Du hast hier etwas falsch verstanden. Die Warnungen beeinflussen die Funktionsweise Deines Plugins nicht (diese laufen genauso gut bzw. schlecht wie zuvor). Der beste Weg diese Warnungen loszuwerden, ist den Plugin-Code entsprechend zu korrigieren .

Die künftige Möglichkeit solche Warnungen unterdrücken zu können ist zwar gut gemeint, aber eigentlich keine wirkliche Hilfe, wenn man Plugins auch langfristig stabil ans Laufen bekommen möchte.

um was geht es den bei den Push-Requests?

Stefan meint den Patch zu dieser Änderung, den ich seiner Zeit eingereicht hatte (ist auch etwas länger her).

[heckmannju]

Hi,
in meinem absoluten lieblingsplugin rrd_aufzeichnen kommt es jetzt auch immer zu solchen warnungen.

2016-01-26 22:15:02.556,rrd_aufzeichnen,Warning: Constant subroutine main::EVENT_RESTART redefined at /usr/share/perl/5.10/constant.pm line 115.
2016-01-26 22:15:02.557,rrd_aufzeichnen,Warning: Constant subroutine main::EVENT_MODIFIED redefined at /usr/share/perl/5.10/constant.pm line 115.
2016-01-26 22:15:02.558,rrd_aufzeichnen,Warning: Constant subroutine main::EVENT_BUS redefined at /usr/share/perl/5.10/constant.pm line 115.
2016-01-26 22:15:02.558,rrd_aufzeichnen,Warning: Constant subroutine main::EVENT_SOCKET redefined at /usr/share/perl/5.10/constant.pm line 115.
2016-01-26 22:15:02.559,rrd_aufzeichnen,Warning: Constant subroutine main::EVENT_CYCLE redefined at /usr/share/perl/5.10/constant.pm line 115.

ich vermute das es von den constanten kommt.

# Konstanten für Aufrufart
use constant EVENT_RESTART => 'restart';
use constant EVENT_MODIFIED => 'modified';
use constant EVENT_BUS => 'bus';
use constant EVENT_SOCKET => 'socket';
use constant EVENT_CYCLE => 'cycle'; 

was muss ich ändern das ich diese warnungen loswerde? VG Jürgen

[XueSheng]

was muss ich ändern das ich diese warnungen loswerde? VG Jürgen

Ich kenne das Plugin nicht, aber das Problem besteht darin, dass bei jedem Aufruf versucht wird die Konstante neu zu definieren (was natürlich nicht Sinn einer Konstanten ist).

Müssen es wirklich Konstanten sein? Warum nicht einfach normale Variablen verwenden? Wie gesagt, ich kenne das Plugin und die Verwendung der Konstanten in diesem Falle nicht, aber der Einsatz von Variablen könnte die einfachste Lösung sein.

[tger977]

Hallo zusammen,

über diese warnings kann man geteilter Meinung sein...

Auf der einen Seite haben sie mir tatsächlich zwei Stellen in meinen Plugins aufgezeigt in denen Sie wirklich ein Fehlverhalten aufgezeigt haben, auf der anderen Seite sind die redefined warnings sehr nervig, da:

- das sehr Gute Skeleton von fry und auch einige der Plugins in Git direkt zu solchen Meldungen führen obwohl die Plugins einwandfrei funktionieren
- nicht vorkompilierte Plugins mit mindestens einer Subroutine IMMER zu diesen warnings führen!

Grundsätzlich: Beim Erstellen und Testen von Plugins ist es sinnvoll, die warnings anzeigen zu lassen, um mögliche Fehler leicht und früher zu finden.

Abhilfen aus meiner Sicht:

1) ab Version 1.2.7 kann wie oben schon geschrieben der warning Mechanismus komplett deaktiviert werden (aus meiner Sicht auch nicht 100% sinnvoll da damit auch wichtige warnings unterbleiben
2) nur die warnings für redefined per Codezeile im Plugin deaktivieren:

no warnings 'redefine';

dann muß man aber selbst darauf achten daß nicht Namen in den Plugins doppelt verwendet werden! (siehe auch unten bei Hintergrund...)
3) generell in einem Plugin alle warnings ausblenden: ist prinzipiell wie 1) nur halt für einzelne Plugins

no warnings;

4) Plugins complieren mittels

 #COMPILE_PLUGIN

dann muß man aber die Parameter die in der Subroutine aus dem Hauptteil verwendet werden soll explizit übergeben... (s. Hintergrund unten). Für Plugins ohne Subroutines ist nach meiner Erfahrung ein umstellen unkritisch.

Hintergrund zu den redefined Meldungen (danke auch an den Support, speziell "Fr. B" von ElabNet die mir hier sehr geholfen hat das Thema zu verstehen!)

Plugins, die nicht die Zeile #COMPILE_PLUGIN verwenden, werden bei jedem Aufruf eingelesen und dann evaluiert.
Wenn man nun in einem solchen plugin Subroutinen definiert, dann werden diese bei jeder Evaluation neu definiert und führen so zu dieser Warnung.

Nach Neustart des WireGate Serverprozesses sollte beim ersten Aufruf des Plugins keine solche Warnung kommen, denn dann würde man Subroutinen des WireGate Serverprozesses überschreiben.
Beim zweiten und jedem weiteren Aufruf erscheint die Warnung dann aber wieder.

Hintergrund zum Kompilieren von Plugins und dortige Problematik mit Subroutines:

https://knx-user-forum.de/forum/%C3%...erige-memleaks

Bei der Verwendung von "#COMPILE_PLUGIN" wird eine anonyme Subroutine erzeugt, die dann später aufgerufen wird.
In dieser (anonymen) Subroutine verwenden Sie 'named' Subroutinen.
Bei der Ausführung eines Perl Programmes gibt es zwei Phasen: compile time und runtime.
'named' Subroutinen werden zur "compile time" erzeugt, anonyme zur Laufzeit.
Daher können die (named) Subroutinen nicht auf die mit 'my' deklarierten Variablen der anonymen Subroutine zugreifen, und es wird die Warnung 'Variable ... is not available' ausgegeben.
Diese Werte müssten dann als Argumente an die in den Plugins verwendeten Subroutinen übergeben (siehe link)

Die Warnung "Subroutine refined" kommt nur nach einer Änderung des Plugins.
Beim Start des Daemons wird diese Subroutine beim ersten "compilieren" des Plugins erzeugt.
Beim Aufruf des Plugins wird dann die anonyme Funktion aufgerufen. Dabei tritt die redefined Meldung die ohne Compilieren entstehen würde nicht auf.

So ich hoffe ich konnte damit etwas zur Auflösung der Thematik beitragen...

Gruß
Andi

[mivola]

Das ist kein Müll, sondern sind durchaus begründete Warnungen. Diese Warnungen sind das Ergebnis eines Push-Request aus der Community. Ab der 1.2.8 (noch Beta) wird der Grund für die Warnungen besser erklärt.

Entweder werden wir kritisiert, weil wir Push-Requests - vor zwei Jahren zögerlich - umgesetzt hatten oder es wird getadelt, weil nicht jeder mit dem Ergebnis eines Push-Requests zufrieden ist.

==> Liebe Community, überlegt euch bitte was ihr wollt. Wir haben keine Lust, der Spielball dazwischen zu sein. Wenn ihr wollt, dass wir Eure Push-Requests umsetzen, dann respektiert auch das Ergebniss. Wenn ihr wollt, dass wir intern zuerst darüber befinden sollen ob es umgesetzt wird, dann lassen wir künftig alles weg, was aufwändig erklärt werden müsste, dann respektiert ihr dieses dann bitte ebenfalls. Aber bitte, einigt Euch.

lg

Stefan

Hi Stefan,

ich denke, der Kommentar war nicht so krass gemeint wie es evtl. klingt oder von dir aufgenommen wurde. Andi hat den Hintergrund ja sehr gut erklärt und ich denke damit wird klar, dass dies ein wichtiges & hilfreiches Feature ist um die Stabilität des WG weiter zu verbessern!

Ich fände es schade wenn das Know-How und der Aufwand der Community nicht genutzt werden könnte/sollte...

VG
Micha

[Chris M.]

==> Liebe Community, überlegt euch bitte was ihr wollt. Wir haben keine Lust, der Spielball dazwischen zu sein. [...] Aber bitte, einigt Euch.

Durch genau so eine Diskussion wie hier wird die Einigung herbeigeführt. So es überhaupt eine(!) Meinung gibt. Wie so oft wird es am Schluss aber meist wohl nur eine Mehrheitsmeinung geben. Und eine Diskussion über ein Forum dauert nun mal etwas länger als ein Abstimm-Gespräch bei einem Kaffee am Arbeitsplatz...

Zum konkreten Thema:
Wie plötzlich die Warnungen kamen war ich auch verwirrt. Da meine Plugins gleich geblieben waren musste ich von einem Problem im Server-Code ausgehen. Inzwischen weiß ich auch, dass nur bisher unterdrückte aber vorhandene Warnungen angezeigt werden. Das ist grundsätzlich gut! Nicht umsonst wird in größeren Projekten gefordert, dass alle Warnungen als Fehler zu behandeln sind!

Ein Problem ist allerdings, dass die aktuelle Architektur der Plugins kaum die Verwendung von Sub-Routinen zulässt, zumindest wenn man die Warnungen ernst nimmt.
Mir ist klar warum das so ist wie es ist, für die Zukunft wäre hier aber eine warnungsfreie Lösung für Sub-Routinen existieren würde.

[mfd]

Eigentlich war meine Frage dahingehend, was Otto-Normal-Benutzer tun kann/muss um seine Plugins weiterhin vernünftig benutzen zu können...

Wenn ich richtig verstehe heißt das zusammengefasst

• nichts unternehmen (Plugin-Log bleibt dann zugemüllt)
• Warnungen ab 1.27 unterdrücken lassen und damit leben, dass sie im Hintergrund da sind
• Perl vernünftig lernen und die betroffenen Plugins so umschreiben, dass sie fehlerfrei einsetzbar sind

[StefanW]

Warnungen ab 1.27 unterdrücken lassen und damit leben, dass sie im Hintergrund da sind

Eigentlich müsste man sagen "wieder" unterdrücken lassen.

Perl vernünftig lernen und die betroffenen Plugins so umschreiben, dass sie fehlerfrei einsetzbar sind

Ansich ist das der einzig richtige Weg.

Das ist auch der Grund, warum ich nicht der Freund der Plugin-Lösung auf der Basis einer komplexen Programmiersprache bin. Grundsätzlich ist eine jede Programmiersprache korrekt zu nutzen, sonst gibt es eben seitenlange Warnings & Errors durch Interpreter / Compiler. Damit schlagen sich die Profis täglich auch herum. Eine Programmiersprache kümmert sich nicht darum, ob der Experte oder der Otto Normalverbraucher davor sitzt. Entweder die Sache ist Richtig oder Falsch.

Auf den Wunsch von Michael haben wir die korrekten Warnings ausgegeben und auf den Wunsch einiger anderer haben wir dies nun wieder abschaltbar gemacht. Soll jeder für sich entscheiden.

lg

Stefan