Plugin Aufrufzeit

[Fry]

Damit das Plugin nicht mehr auf GA1 hört, musst du in deinem Code den Subscribe wieder löschen:

delete plugin_subscribe{GA}{$plugname};

Grüße,Fry

[Fry]

Nachdem ich nicht so Perl-bewandert bin ... kann man irgendwie auslesen, welche GAs mittels $plugin_subscribe{$GA}{$plugname} gesetzt sind?

Guckst du hier.

VG, Fry

[Fry]

Etwas Hintergrund, manchmal hat Spaghetticode auch Vorteile: es wird völlig wertfrei nachgesehen ob die letzte zyklische Ausführung länger her ist als time()-plugin...cycle.

(Hervorhebung von mir). Das ist wesentlich. Und was passiert, wenn es noch gar keine zyklische Ausführung gab? Dann gilt der anfängliche (init) call nach dem letzten Speichern oder nach Daemon-Reset oder Reboot als zyklischer Aufruf.

Eine "Garbage Collection" sowohl in plugin_info als auch in plugin_subscribe fehlt aber noch, wenn ich das richtig überblicke... beides ist aber vielleicht besser als Plugin statt als Teil des Wiregate-Kerns zu realisieren.

VG, Fry

PS. Wieso Spaghetticode?

[Fry]

Hier ist eine Möglichkeit, eine automatische Garbage Collection für Plugins zu bauen. Funktioniert bei mir.

Und etwas zur Code-Disziplin: Wenn ein Plugin von einer GA aufgerufen wird, auf die es eigentlich nicht reagieren will, so sollte es nicht einfach ein "return" machen sondern vorher den Eintrag in plugin_subscribe löschen!

Ich glaube es ist an der Zeit, ein "Plugin Guide" herauszugeben. Die Qualität des Codes im Plugin-SVN ist... nunja.... und das liegt nicht daran, dass Perl eine schlechte Programmiersprache wäre. Im Gegenteil.

(noch schlimmer finde ich aber, dass die Zahl der im SVN eingestellten Plugins vergleichsweise gering ist. Community ist Geben & Nehmen, oder? Also Leute, stellt eure Plugins ins SVN!)

VG
Fry

[StefanW]

Ich glaube es ist an der Zeit, ein "Plugin Guide" herauszugeben.

JAAAAAA, sehr gerne, das wäre sehr dienlich.

(noch schlimmer finde ich aber, dass die Zahl der im SVN eingestellten Plugins vergleichsweise gering ist. Community ist Geben & Nehmen, oder? Also Leute, stellt eure Plugins ins SVN!)

Jaaaa, auch sehr dafür.

Die Qualität des Codes im Plugin-SVN ist... nunja.... und das liegt nicht daran, dass Perl eine schlechte Programmiersprache wäre. Im Gegenteil.

Das ist etwas kontraproduktiv, weil einerseits die Anwender für die schlechte Codequalität zu schelten aber aufzurufen diesen Code zu veröffentlichen beißt sich....

lg

Stefan

[Fry]

Ich glaube es ist an der Zeit, ein "Plugin Guide" herauszugeben. Die Qualität des Codes im Plugin-SVN ist... nunja.... und das liegt nicht daran, dass Perl eine schlechte Programmiersprache wäre. Im Gegenteil.

JAAAAAA, sehr gerne, das wäre sehr dienlich.

Hier ist ein erster Ansatz - ohne jeden Anspruch auf die endgültige Weisheit. Bin gespannt, was Könner wie ChrisM oder Makki ggf. daran ändern würden.

Viele Grüße
Fry

[makki]

Und etwas zur Code-Disziplin: Wenn ein Plugin von einer GA aufgerufen wird, auf die es eigentlich nicht reagieren will, so sollte es nicht einfach ein "return" machen sondern vorher den Eintrag in plugin_subscribe löschen!

Das ist ein bisschen "gewachsen", hier ist halt der Kopf (Layer 8) des Entwicklers gefragt, ist aber normalerweise kein Problem, weil Windows-User sind es eh gewohnt, erstmal durchzustarten bevor man an ein Problem denkt Und dann ist es weg (*subscribe ist nicht persistent)

Die Qualität des Codes im Plugin-SVN ist... nunja.... und das liegt nicht daran, dass Perl eine schlechte Programmiersprache wäre. Im Gegenteil.

Ja und nein, da gebe ich Dir recht. Die Codequalität entspricht in etwa der von CPAN (sigh!), da machen halt Hanni und Nanni so wie ich was sie gerade denken.. Ich schreibe gerade an dem Artikel "memleaks trotz Perl vermeiden"..

(noch schlimmer finde ich aber, dass die Zahl der im SVN eingestellten Plugins vergleichsweise gering ist.

Nun, das tun die wenigsten, ob das nun egoismus, faulheit oder ... ist sei mal dahingestellt. Ich versuche möglichst viele einzusammeln bzw. dazu zu motivieren, das muss wohl reichen..
(Da könnte ich die GPL-Diskussion jetzt grad mal flott umdrehen, weil jedes Plugin ist mal so de-fakto implizit GPL ))

Makki

[Fry]

(Da könnte ich die GPL-Diskussion jetzt grad mal flott umdrehen, weil jedes Plugin ist mal so de-fakto implizit GPL ))

Das stimmt! - nur geschieht bei einem Plugin die Weiterverteilung zwangsläufig im Source, also GPL-konform.
Fry

[Chris M.]

Ich glaube es ist an der Zeit, ein "Plugin Guide" herauszugeben.

Denke ich auch. Man lernt erst über die Zeit manche Features gut zu nutzen und um fehlendes geschickt herum zu Coden. Dieses Wissen sollte man zusammenfassen um den Einstieg und die Lern-Kurve zu verbessern.

Die Qualität des Codes im Plugin-SVN ist... nunja....

Das liegt genau daran. Erst mit ausreichend Erfahrung mit den Plugins weiß man effektiv damit umzugehen. Meine heutigen Plugins sehen auch ganz anders aus als meine ersten...

Aber: über Qualität im SVN zu schimpfen ist nicht erlaubt! Es ist schließlich Open Source und ein Repository, da äußert man seine (konstruktive) Kritik durch einen Commit

Hier ist ein erster Ansatz - ohne jeden Anspruch auf die endgültige Weisheit. Bin gespannt, was Könner wie ChrisM oder Makki ggf. daran ändern würden.

Da ist schon mal viel schönes zu sehen.

Was mir aber immer nicht gefällt, sind in jedem Plugin lange Initialisierungs-Orgien die bei jedem Aufruf durchlaufen müssen. Das mit dem conf.d muss man halt schlucken um Daten und Code sauber trennen zu können und damit ein öffentliches Plugin-Repository wirklich Sinn macht.

Das eibshort hätte ich dagegen weg gelassen und lieber einfach oben im Plugin (oder in der conf.d-Datei) die GA einfach in eine Variable mit sprechendem Namen gesteckt (wir können hier ja keinen Namensraum versauen).
Meist nutzt ein Plugin ja auch nur ein paar wenige und spezifische GAs. Plugins wie der Multi-RTR sind die große Ausnahme und auch nicht im Entwicklungs-Scope für jemanden, der noch einen Plugin-Guide nutzen müsste.

[JuMi2006]

Das mit dem conf.d muss man halt schlucken um Daten und Code sauber trennen zu können

Kannst Du das mal kurz erklären? Das wurde irgendwie während meiner Bauabwesenheit eingeführt. Was bringt das? Irgendwie sehe ich da nicht ganz durch was eine conf.d bewirken soll.

Danke!
Mirko

[Chris M.]

Irgendwie sehe ich da nicht ganz durch was eine conf.d bewirken soll.

Du trennst die Konfiguration des Plugins vom Code. So kannst Du z.B. den Code (also das klassische Plugin selbst) 1:1 durch eine neue Version (z.B. aus dem SVN Repository) ersetzen ohne Änderungen vornehmen zu müssen.

Für kleine, spezielle, private Plugins lohnt sich das nicht.
Bei universellen Plugins, die viele verwenden können dagegen sehr.

[Fry]

Aber: über Qualität im SVN zu schimpfen ist nicht erlaubt! Es ist schließlich Open Source und ein Repository, da äußert man seine (konstruktive) Kritik durch einen Commit

Du hast Recht. War eigentlich auch nicht als Schimpfen gemeint (sonst hätte ich nicht "nunja" geschrieben sondern irgendein "§$%&"). Sorry, wenn das falsch rüberkommt.

Was mir aber immer nicht gefällt, sind in jedem Plugin lange Initialisierungs-Orgien die bei jedem Aufruf durchlaufen müssen. Das mit dem conf.d muss man halt schlucken um Daten und Code sauber trennen zu können und damit ein öffentliches Plugin-Repository wirklich Sinn macht.

Stimmt. Genau das könnte man im wiregated.pl fixen - z.B. indem der eine $event-Variable direkt mitgibt, auf die man ein "given...when" zur Fallunterscheidung des Aufrufgrundes machen kann.

Das eibshort hätte ich dagegen weg gelassen und lieber einfach oben im Plugin (oder in der conf.d-Datei) die GA einfach in eine Variable mit sprechendem Namen gesteckt (wir können hier ja keinen Namensraum versauen).

Halb einig, halb anderer Meinung. Meine bevorzugte Lösung wäre eine %eibgaconf, die mehrfach indiziert ist. Habe ich gerade als wiregate-Patch gehackt und hier gepostet (die $event-Variable wäre ebenfalls sehr leicht in den wiregated.pl einzufügen). Ich hoffe nun darauf, dass Makki meinen Code gutheißt und übernimmt... sicher gibt es immer für und wider, und alle Daemon-Modifikationen bergen natürlich kleinere Inkompatibilitäten zu früheren Plugins. Für mich überwiegt aber das "Für". Oder man führt gleich einen Backward-Compatibility-Flag ein.

Meist nutzt ein Plugin ja auch nur ein paar wenige und spezifische GAs. Plugins wie der Multi-RTR sind die große Ausnahme und auch nicht im Entwicklungs-Scope für jemanden, der noch einen Plugin-Guide nutzen müsste.

Wieder ein Argument, das %eibgaconf-Lookup bereits im Daemon mächtiger zu machen. Speicherplatz ist mE kein Argument, weil das Linux-Memory Management bei Forks ja ein copy-on-write macht, dh. die entsprechenden Pages werden gar nicht kopiert.

Außerdem... hab ich schon erwähnt, dass ich nackte Zahlen hässlich finde? Man wird bei KNX aber leider ständig damit konfrontiert, auch in der ETS. Da ist die Menschheit von Telefonnummern bis zu Webadressen gekommen, da ist DHCP und DNS erfunden worden, aber im KNX-Bereich braucht es natürlich unbedingt die nackten Zahlen....

VG,
Fry

[Chris M.]

Stimmt. Genau das könnte man im wiregated.pl fixen - z.B. indem der eine $event-Variable direkt mitgibt [...] [... weitere wiregated.pl Erweiterungen ...]

Sehe ich auch so und hatte ähnliches auch schon mal im einen oder anderen Thread vorsichtig nachgefragt. (Auch das conf.d könnte man evtl. dorthin auslagern)

Da aber gerade intensiv an der Plugin-Inftrastruktur geschraubt wird, dürfte dass wohl erst danach kommen können...

Wieder ein Argument, das %eibgaconf-Lookup bereits im Daemon mächtiger zu machen. Speicherplatz ist mE kein Argument, weil das Linux-Memory Management bei Forks ja ein copy-on-write macht, dh. die entsprechenden Pages werden gar nicht kopiert.

Perl-Thread != (Linux-)Thread.

Ich hab mich zwar nie mit den Perl-Threads beschäftigt, die scheinen aber eher (beschönigend ausgedrückt) suboptimal zu sein.

Wenn ich denn mal zu meiner eigenen Logik-Engine komme, würde diese Stelle eh ganz anders aussehen (und dann gleich richtiges C++ sein)

[Fry]

Perl-Thread != (Linux-)Thread.

Ich hab mich zwar nie mit den Perl-Threads beschäftigt, die scheinen aber eher (beschönigend ausgedrückt) suboptimal zu sein.

Ich sprach von Prozess-Forks, bei denen Linux nicht alles kopiert sondern nur Speicherseiten auf copy-on-write setzt. Da %eibgaconf von Plugins eigentlich nicht beschrieben werden sollten, sollten Forks an dieser Stelle keinen Speicher verbrauchen.

Bei Threads ist es noch einfacher: da die "by design" gemeinsamen Speicher nutzen, wird erst recht nichts kopiert. Also verstehe ich nicht, warum 10 parallel laufende Threads den %eibgaconf-Hash kopieren sollten und entsprechend viel Speicher verbrauchen.

oder kann mich da mal jemand aufs Pferd heben?

[StefanW]

Sollte man das nicht besser im WireGate-Beta-Forum besprechen, wie auch alle anderen Ideen und Vorschläge von Dir Fry?

Weil ich denke die Vorschläge zur Weiterentwicklung und die doch sehr spezifische Diskussion verwirrt - auch bei der Menge an parallelen Threads zum Thema Plugin-System - die Anwender doch sehr.

Seid Ihr mit dem Verschieben einverstanden?

lg

Stefan