Neues Plugin: Logikprozessor.pl

[mivola]

Jmd Ideen?

Ja, ich :-) Aber eine für einen anderen Ansatz - aber leider noch ohne Lösung: wäre es evtl. sinnvoller die "persönlichen" Ferien/Urlaub in einer GA zu speichern? Diese kann über diverse Wege (linknx, andere Plugins, Logikprozessor selbst, ...) gesetzt werden und in der "is_holiday"-Funktion ausgelesen werden. Die Frage wäre nur: welcher DPT wäre das? Und in welchem Format stehen dort die Werte drin? Kommaseparierte Liste der Zahlen (Tag des Jahres)?

Fragen über Fragen... und die wichtigste: bin ich der einzige, der so große Unterschiede zwischen Werktag und Wochenende/Ferien/Feiertag hat, dass ihn dieses Thema interessiert?

VG
Micha

[jensgulow]

Nö, ich habe bisher die Sachen "händisch" im LP eingepflegt (recht unsmart) - wäre also definitiv an einer Lösung interessiert.

[Fry]

Hi Micha,

Du bist da etwas über die -zugegebenermaßen gewöhnungsbedürfige- Perl-Syntax gestolpert. (nur zur Verteidigung von Perl, diese Syntax war seinerzeit so gewählt worden, um Ähnlichkeiten mit bash/awk/sed usw. herzustellen, damit die Umgewöhnung leicht fällt).

Mit eckigen Klammern und Dollarzeichen geht das:

%settings {
    holidays=>[354, 355]
};

my $settings=$plugin_cache{$plugname}{settings};
my $myHoliday = $settings->{holidays};
plugin_log($plugname, "settings->{holidays}: ".join(",",@{$myHoliday}));

Hoffe das hilft...

VG, Fry

[mivola]

Danke Fry, so klappts dann auch mit den Ferien :-)

Hier nun meine Anpassungen:

• Logikprozessor.pl#is_holiday() - vor der return-Anweisung
  

  	# settings aus der .conf auslesen
  	my $settings=$plugin_cache{$plugname}{settings};
  	if (exists $settings->{holidays}) {
  		my $myHoliday = $settings->{holidays};
  		
  		# beide arrays zusammenfügen (in @holidays)
  		push(@holidays, @{$myHoliday});
  	}

• Logikprozessor.conf
  

  %settings=(
    holidays=>[356,357,358,359,363,364,365,2]
  );

@Fry: bitte schau mal drüber. Sicher kennst du noch bessere/elegantere Wege... Wenn es für dich OK ist, dann kann es auch gern ins SVN.

Danke und VG
Micha

[Fry]

Kannst du gerne ins SVN einchecken. Bitte nimm statt "exists" besser "defined".
Und mach es bitte kürzer:

   # settings aus der .conf auslesen     
    my $settings=$plugin_cache{$plugname}{settings};     
    push @holidays, @{$settings->{holidays}} 
                    if defined $settings->{holidays};

Ich finde das so besser lesbar...

Danke übrigens!

VG, Fry

[mivola]

Kannst du gerne ins SVN einchecken.

OK, würde ich machen. Dazu ein paar Fragen:
- ich habe noch die Option "execute_on_input_changes_and_previous_state_is_cac hed_only" drin; ist das OK?
- ich habe auch noch addRssLog und sendNma drin; auch OK?
- die sample-conf würde ich entsprechend erweitern, oder?
- ich habe glaube ich keine Berechtigung um ins SVN zu schreiben - kannst du mir das einrichten?

Danke,
Micha

[Fry]

Hi Micha,
nimm's mir nicht übel, aber die anderen Add-Ons finde ich nicht zentral genug (für alle User), um sie in den LP zu integrieren.
Im Rückblick würde ich auch gerne sendProwl wieder rausnehmen, und das von mir genutzte samurai habe ich sogar schon rausgenommen. Diese Geschichten sind einfach zu speziell. Meine Meinung. Aber der LP ist GPL, also feel free to fork...
VG, Fry

[tger977]

Hallo Fry, Micha,

ich finde gerade die AddOn's RSS und auch sendNMA sehr interessant.

Vorschlag da ich auch schon bei meiner damaligen Erstinstallation über das nicht funktionierende samurai gestolpert bin: Warum kann man diese AddOn's nicht in der Config einfach konfigurierbar machen und in der Standardkonfig die im SVN landet deaktivieren. Damit würde es beim Otto Normal User nicht stören, könnte aber auch einfach bei Bedarf von jedermann aktiviert werden.

Gruß
Andi

P.S. Falls die AddOn's von Micha doch nicht ins SVN wandern hätte ich trotzdem Interesse an der Variante.

[Fry]

Wie gesagt habe ich nichts gegen einen Fork, sozusagen den "Logikprozessor Plus". Ich möchte meine Version allerdings eher abspecken (um Prowl) als anreichern (um RSS usw.).

Außerdem mal ganz allgemein geschrieben: Wieso denkt ihr eigentlich, jede Funktion, die in euren Logiken vorkommt, müsste gleich in den Body des Plugins Logikprozessor.pl selbst rein? Das ist wenig elegant und hat schwerwiegende Nachteile.

Wenn wir zB im Logikprozessor.pl ein externes Paket hinzulinken (Samurai, Net::SMTP oder ähnliches), müssen ALLE User, die den LP einbinden, auch das CPAN-Paket installieren. Deswegen klares Veto gegen die Featuritis beim LP. Funktionen wie Samurai, Prowl, Email, RSS, sendNMA gehören in separate Plugins ODER in die Logikprozessor.conf. Ich habe seinerzeit den Samurai rein- und auch wieder rausgetan, und Prowl habe ich nur dringelassen, weil ich seinerzeit zugestimmt habe, ihn reinzutun. Ich nutze Prowl aber nicht - wie vermutlich 95% der LP-Anwender - und es ist daher Ballast.

Anders sehe ich es _grundsätzlich_ bei echten Logikerweiterungen, also nicht einfach Schnittstellen zu anderen Paketen. Solche Erweiterungen der Funktionalität belasten nicht mit "use"-Statements und liefern u.U. einen echten Zugewinn Michas Option "execute_on_input_changes_and_previous_state_is_cac hed_only" wäre eigentlich ein Beispiel dafür, nur diesen konkreten Fall finde ich (i) viel zu exotisch und zu selten, um daraus eine vordefinierte Option zu machen (falls man das doch mal braucht, kann man diese Funktionalität leicht selbst durch ein "if" im translate-Teil realisieren, ohne gleich den LP zu erweitern) und (ii) ist eine Option, die gleich ZWEI Bedingungen abfragt, wenig elegant - man möchte doch lieber mit jeder Option nur einen Schalter setzen und dann im konkreten Fall beide Optionen setzen, oder?

Bitte blast mir den LP nicht zu sehr auf. Er wird dann unwartbar und buggy. Und vergesst nicht - es gibt keinen kommerziellen Support dafür.

VG, Fry

PS. Ich selbst nutze Samurai übrigens immer noch im LP - und dennoch ist es nicht mehr im Body des Plugins selbst drin. Die Subroutine ist in einem ANDEREN Plugin definiert, und da die Plugins untereinander einen einzigen Namespace nutzen, kann man die Subroutine auch aus Logiken heraus aufrufen.

[tger977]

Wenn wir zB im Logikprozessor.pl ein externes Paket hinzulinken (Samurai, Net::SMTP oder ähnliches), müssen ALLE User, die den LP einbinden, auch das CPAN-Paket installieren.

Bitte blast mir den LP nicht zu sehr auf. Er wird dann unwartbar und buggy. Und vergesst nicht - es gibt keinen kommerziellen Support dafür.

PS. Ich selbst nutze Samurai übrigens immer noch im LP - und dennoch ist es nicht mehr im Body des Plugins selbst drin. Die Subroutine ist in einem ANDEREN Plugin definiert, und da die Plugins untereinander einen einzigen Namespace nutzen, kann man die Subroutine auch aus Logiken heraus aufrufen.

ok, Fry. Gute Argumente überzeugen immer!

Ich verstehe daß Du diese Feature nicht im LP haben willst. Mit deinem PS Teil ist das eine interessante Alternative. Ich komme leider erst so langsam in die Perlwelt rein, daher für mich noch alles etwas schwierig, aber könnte man dann für die Features samurai, NMA, Prowl dann irgendwie solche subroutinen oder "Skeleton Plugins mit diesen Subroutinen" erstellen und zur Verfügung stellen?

[StefanW]

Bitte blast mir den LP nicht zu sehr auf. Er wird dann unwartbar und buggy. Und vergesst nicht - es gibt keinen kommerziellen Support dafür.

Sehr gut!




Stefan

PS: Wir denken durchaus daran, den LP auch zu integrieren. Je schlanker desto machbarer. Wenn noch andere Pakete dazu müssen, wird es zu teuer...

[mivola]

PS. Ich selbst nutze Samurai übrigens immer noch im LP - und dennoch ist es nicht mehr im Body des Plugins selbst drin. Die Subroutine ist in einem ANDEREN Plugin definiert, und da die Plugins untereinander einen einzigen Namespace nutzen, kann man die Subroutine auch aus Logiken heraus aufrufen.

Das wäre natürlich die beste Möglichkeit. An sowas wie AddOns/Plugins für den LP hatte ich auch gedacht, aber für zu aufwändig erachtet. Wenn ich die subs also einfach in ein "Logikprozessor.addRssLog.pl" etc stecke, würde das ganze auch funktionieren? Das wäre natürlich super!

Einen Fork möchte ich natürlich vermeiden, aber die Option "execute_on_input_changes_and_previous_state_is_cac hed_only" wäre mir schon wichtig, eben um ein identisches "if" in 19 Logiken zu vermeiden. Wenn es aber keine weiteren Befürworter gibt, dann lasse ich es einfach nur bei mir lokal drin; das wäre auch kein Problem.

VG
Micha

[Fry]

PS: Wir denken durchaus daran, den LP auch zu integrieren. Je schlanker desto machbarer. Wenn noch andere Pakete dazu müssen, wird es zu teuer...

Guter Ansatz. Ich helfe ggf. gern dabei.

Würde ich den LP heute nochmal überarbeiten - um es gleich zu sagen, ich habe es aktuell nicht vor - dann würden die "$state"-Variable und Prowl rausgenommen. Beide Funktionalitäten lassen sich leicht anders realisieren, und der Code des LP selbst würde wohl 50-100 Zeilen kürzer und damit lesbarer/wartbarer.

Naja, aber es ist jetzt halt so, wie es ist. Und eine stabile Codebasis ist auch was wert - die haben wir nun seit längerem, bis auf den kürzlichen Mini-Patch (bezüglich "$/", um den LP mit dem Email-Plugin kompatibel zu machen).

VG, Fry

[mivola]

Kannst du gerne ins SVN einchecken.

Also: die Holiday-Funktion ist nun im SVN: https://sourceforge.net/p/openautomation/code/2304/

Zusätzlich auch "AddOns" (also subs in eigenen Dateien) für sendNma und addRssLog. Damit kann jeder nach Gutdünken Funktionen zum LP hinzufügen indem er einfach diese Dateien unter /etc/wiregate/plugin/generic ablegt und in den Logiken benutzt: https://sourceforge.net/p/openautomation/code/2303/

Bei Problemen bitte hier melden.

VG
Micha

[jensgulow]

$date überprüfen in translate-Anweisung

Ich wollte gerne einer follow-up logik beibringen, dass sie halt nur vom 07.01. - 30.11. gelten soll.
Dieser Code in der config:

jalo_west_runter =>             {transmit=>['2/2/5','3/2/45','3/2/55'], translate=>sub{return $date ('01/07'-'11/30')? 1:undef;}, debug=> 1},

erzeugt folgenden Fehler - also sollte ja wahrscheinlich mit meinem Denkansatz $ date zu überprüfen irgendetwas falsch sein. Und wieso eigentlich wird "01/04" angemahnt, wenn in der fraglichen anweisung 01/07 steht ?????

2015-01-04 16:54:40.582,Logikprozessor.pl,Run-time error: Can't use string ("01/04") as a symbol ref while "strict refs" in use at (eval 33889) line 113. ,0s,Can't use string ("01/04") as a symbol ref while "strict refs" in use at (eval 33889) line 113.