[wiregate] - √ - Nutzung Perl-Module

[JoeKool]

Hallo zusammen,
ich habe meine Basisfunktionen für meine Plugins schön in einem Modul abgelegt. Geht auch alles...
Nun habe ich aber den Effekt, dass WireGate sich den Inhalt der *.pm irgendwie "cached" oder so.
Jegliche Änderung in der *.pm hat keinen Effekt. Selbst das Löschen (!) des Moduls zeigt keine Wirkung. Das Plugin wird brav und vollständig ausgeführt und greift dabei auf das (nicht mehr vorhandene) Modul zu.

Ist das eine Perl-Einstellung?
Oder eien WireGate-Spezialität?
Gibt's da einen "refresh"?

Viele Grüße
Joe

[perf]

Neustart von wiregated.pl im Webmin?

/Per

[JoeKool]

Neustart von wiregated.pl im Webmin?

Super! Das war's!
Vielen Dank!


Ich hake das Thema gleich ab, aber wenn mir noch jemand (makki?) erklären könnte, warum das so ist, dann wäre das auch toll...

[makki]

Nun, das ist ganz einfach:
das .pm ist erstmal eine Textdatei, die zum Start (oder bei der ersten Verwendung durch "use .." in einem Plugin) interpretiert - und dann sinnigerweise (im selben Prozess, hier wiregated) wiederverwendet wird. Änderung-> egal, die wird nichtmal angeschaut.. Soweit simply Perl.

Das erste woran ich bei bei .pm denke (in exakt dieser Reihenfolge): schlecht, miserabel, theoretisch toll - praktisch unbrauchbar, ineffizient, 99% sicheres Speicherleck..

-> Mal "böse" gesagt: Sind die Funktionen in der PM sooo heftig, schreib ne C-Lib, ansonsten scheib sie ins Plugin und fertig, das Konzept der PM ist mmN weitgehend kaputt was nicht XS angeht (in C, wie Perl selbst), wenn man sich den Source mal anguckt..

Makki

Edit/PS: das laden einer Config::Std (ohne die config zu lesen!) dauert ungefähr Faktor 50-100 wie wenn das direkt drin steht..

[JoeKool]

... und dann sinnigerweise (im selben Prozess, hier wiregated) wiederverwendet wird...

Alles klar. Mir war bei meinem Post noch nicht klar, dass die Plugins eigentlich gar keine Skripte sind, die jeden Mal "neu" aufgerufen werden.
Die sind eigentlich schon "subs" in der wiregated.
Dann ist natürlich auch klar, dass die nie mehr wieder angeschaut werden.

...
-> Mal "böse" gesagt: Sind die Funktionen in der PM sooo heftig, schreib ne C-Lib, ansonsten scheib sie ins Plugin und fertig...

Okay... schon verstanden.
Aber sooo hefrig sind die Funktionen auch nicht. Ich finde es aber 1000-Mal geschickter z.B. meine alle meine E-Mails mit einem lockeren

$plugin_info{$plugname.'_result'} = &wiregatemod::SMTP_eMail($Betreff, $text);

zu schicken, als in verschienen Plugins jedes Mal den gleichen Code drin zu haben und den dann auch noch an x Stellen pflegen zu müssen...

Ich versuch' mal die Speicherleaks zu vermeiden...

Viele Grüße
Joe

[makki]

Alles klar. Mir war bei meinem Post noch nicht klar, dass die Plugins eigentlich gar keine Skripte sind, die jeden Mal "neu" aufgerufen werden.
Die sind eigentlich schon "subs" in der wiregated.
Dann ist natürlich auch klar, dass die nie mehr wieder angeschaut werden.
..

Ja und Nein.

Doch das werden sie! die Plugins werden bei jedem Aufruf komplett ge"evaled", das klingt ineffizient, ist es aber nicht..
PM dagegen nicht, passiert nur einmal; weil das wäre ineffzient, denn das ist im Vergleich langsam wie hulle..
Der Eval eines Plugins mit 1000 Zeilen Code dauert max. 50 ms, der eines PM auch mal gerne 500-1500ms.
So ist Perl halt.. Quintessenz: PM sind in diesem Fall nicht zielführend.

Makki

[ajuno]

Wenn ich mir die Empfehlungen für Plugins (zB Auslagerung der Konfiguration) ansehe so sehe ich durchaus Bedarf an einem eigenen "wiregate Modul". Es macht für mich wenig Sinn in JEDEM Plugin den Code für das Einlesen der <plugname>.conf Datei zu haben. Auch könnte man andere Standardfunktionen wie zB. Syntax Überprüfungen (GA) dorthin auslagern?

sg Lois

[AlexBehring]

Hi,

ist vielleicht schon etwas alt, aber ich habe jetzt das gleiche Problem wie Lois:

Wenn ich mir die Empfehlungen für Plugins (zB Auslagerung der Konfiguration) ansehe so sehe ich durchaus Bedarf an einem eigenen "wiregate Modul".

Aktuell habe ich das auch über ein PM gelöst, aber natürlich würde ich ungern Makkis Kommentar von oben ignorieren

Man / ich könnte doch einfach den Code in i) ein separates Plugin schreiben oder ii) in eine separate Datei und diese mit do einlesen, ... Das schöne an dem Wiregate-Eval-Konzept ist, dass ich von allen Plugins auf alles zugreifen kann. Also auch den ge-eval-ten Code.

Und wenn ich was geändert habe, muss ich vielleicht einfach nur das do nochmal ausführen (also das "Basis-Pugin")?

Oder bin ich komplett auf dem Holzweg?

Danke.
Grüße,
Alex

[makki]

Alex,

es gibt wie immer: viele Wege nach Rom
(ich bin schon mitm Auto hingefahren und würde trotzdem das Segelboot bevorzugen)

Zurück zum Thema: das kann man per .conf, PM bewerkstelligen; ich bin kein Freund der .conf - nicht weil es nicht überaus schlau ist! - sondern weil es überaus Fehlerträchtig ist.

Für eine simple Logik: macht euch doch das Leben nicht unnötig schwer?!

Makki

[AlexBehring]

Just 2 cent

Hallo Zusammen,

interessiert vielleicht niemand, aber bevor ich die Erkenntnisse der letzten Stunden mit ins Grab nehme, teile ich sie mal....

Vorab: ich möchte ein Framework aufbauen, welches ich im Hintergrund aus mehreren Plugins heraus nutzen kann. Eine globale Konfig (und globalen Code), wo die Räume definiert sind und dann Plugin-spezifische Konfigs (und Code), z.B. für die Heizungseinstellungen.

In Bastellaune habe ich mal sklavisch das Konzept "alles ins Eval rein" umgesetzt, und nutze in meinen "Cross Plugin" Plugin diverse Package Deklarationen und definiere og. für alle Plugins nutzbaren Routinen. Natürlich ist da auch die generische "Read my Config" sub dabei.

Die Read-my-Config sub schreibt u.a. auch ein Plugin-Log Eintrag. Rufe ich diese generische Read-my-Config sub aus dem sie definierenden Cross-Plugin Plugin auf, wird das korrekte Plugin als "Autor" im Log angezeigt. Rufe ich sie aus einem anderen Plugin auf, wird das Cross-Plugin als Autor angezeigt. Doof.

Take-Away nach Untersuchung von wiregate.pl: die im sub check_generic_plugins definierten lexikalischen Variablen werden "lokal" pro Eval - also pro Plugin lokal.

Hier ein Beispiel, was das illustriert:

my $var = 'Test 1';
my %plugin_code = ();

sub defSubs {

    my $plugname="A";
    eval '
    $plugin_code{$plugname}=sub {
        sub showValue {
            print $plugname . " reports: Value of var in scope " . @_[0] . ": " . $var . "\n";
        }
        
        showValue();
    };
    ';
    print "Error Def 1: " . $@ . "\n";

    $plugname="B";
    eval '
    $plugin_code{$plugname}=sub {
        sub secondShow {
            showValue();
        }
        secondShow();
    };
    ';
    print "Error Def 2: " .  $@ ."\n";

    print "Plugins definiert: " . scalar( keys %plugin_code ) . "\n";    
}


sub callIt {    
    my $plugname='A';
    eval { $plugin_code{$plugname}->() };
    print $@;

    $plugname='B';
    eval { $plugin_code{$plugname}->() };
    print $@;
}


defSubs();
callIt();
$var = 'Test 2';
callIt();

Man würde erwarten, dass immer abwechselnd "A reports" und "B reports" angezeigt werden. Wird aber nicht, sondern wg. des "local Scope" resultiert der Code in:

> perl ./test.pl
Error Def 1:
Error Def 2:
Plugins definiert: 2
B reports: Value of var in scope : Test 1
B reports: Value of var in scope : Test 1
B reports: Value of var in scope : Test 2
B reports: Value of var in scope : Test 2

Ich will aber ein paar Dinge Cross-Plugin bereitstellen und dabei auch auf die wiregate.pl Variablen zugreifen. Daher wird mir wohl nix anners übrig bleiben, als den Wiregate.pl zu "batschen" und die benötigten Vars in eine größeren lexikalischen Scope zu schieben.
(Aller Voraussicht nach %msg, $fh und $plugname, da ich Fry's Aufrufgrundermittlung nutze.)

Grüße,
Alex

P.S.: Und wenn's niemandem geholfen hat - der Erkenntnis willen war's das Wert

[makki]

Alex, hmm, also:

Vorwort
Die Plugins wurden (vor Jahren) erfunden, um genau zwei gewissen Usern einen PI-Regler + gewisse Sonderlocken im VPN-Betrieb zu ermöglichen.
Nicht mehr, nicht weniger.
Solche Sachen wie Fry's genialer Logik-Prozessor waren damals nicht auf dem Plan.

Natürlich sind die Variablen "lokal", sonst würden sich Plugins ja gegenseitig stören.
(ergibt sich aber schon durch das eval..)

Was allerdings durchaus auch auf dem Plan war:
- Thread-safe
- Robust
- (sicherer!) Datenaustausch, persistent -> $plugin_info

$plugin_info ist Dein Freund! Man kann da ablegen, was man will..
https://sourceforge.net/p/openautoma...toreComplex.pl

Makki

[AlexBehring]

Danke für die Info Makki!

Grüße,
Alex