Update #30102013 (Damerau)-Levenstein Update

Hier nun mein 2. Update an diesem Tag, welchen ich im SVN-Trunk R22 implementiert wird.

Die Funktionen der Levenstein und Damerau-Levenstein sind nun vollständig implementiert.

zu verwenden ist das ganze in den Rules folgendermaßen:

<Rule Wert="Hallo" Vergleich="eq" RegexID="1" Distance="1" DistanceType="DLD">
<Event Start="Beep">
<Arg Value="" />
<Wait Value="True" />
</Event>
</Rule>

Die Verarbeitung läuft nun nach folgendem Regelwerk ab:

Der Regex wird von der Programm-Regex geerbt und gibt bei der Eingabe "Hollo"
durch das Pattern "^(.*?)$" 'Hollo' an die Default-Prüfung weiter.
Regex-ID: 1 liefert den Arraywert (X)(1) zurück. ('Hollo').

Nun wird 'Hollo' mit der in DistanceType angegebenen Distanzfunktion 'DLD'
(Damerau-Levenstein-Distanz) überprüft. Der Wert des Vergleichs ist 1
(a wurde durch o ersetzt). = 1 Änderung
nun wird der Wert der DLD mit dem Vergleichsoperator aus Vergleich mit dem
in Distance angegebenen Wert überprüft.
( 1 eq 1) und liefert als Ergebnis der Prüfung ein "Wahr" zurück, welches die
Untergeordneten Aktionen (Beep) startet.

Update #30102013 Implementieren einer Fuzzy-Logik durch (Damerau)-Levenstein Distanz in den Rules.

Implementieren einer Fuzzy-Logik durch (Damerau)-Levenstein Distanz in den Rules.

Im heutigen Update geht es um die Vergleichsoperatoren einer Regel.
Diese teilt sich in 2 unterschiedliche Regeln auf. Die Levenstein und die
Damerau-Levensthein-Distanz, welche Sie in den Regeln unter folgenden 4 Typen
angeben können: 

"SDLD" => sensitive (groß-kleinschhreibung beachtet, Damerau-Levensthein-Distanz) 
"SLD" => sensitive (groß-kleinschhreibung beachtet, Levensthein-Distanz) 
"DLD" => sensitive (groß-kleinschhreibung ignoriert, Damerau-Levensthein-Distanz) 
"LD" => sensitive (groß-kleinschhreibung ignoriert, Levensthein-Distanz) 

Der Unterschied zwischen Levensthein und Damerau-Levensthein ist einfach zu erläutern.

Die Levensthein Distanz kennt Bewertet die Aktionen:
löschen, ersetzen und anfügen
wobei die Damerau-Levensthein-Distanz um die Funktion 
tauschen erweitert wurde.

Bsp.:

'Hallo' zu 'Hollo' => 1 getauscht (bei beiden)
'Hallo' zu 'Hllo' => 1 gelöscht (bei beiden)
'Hallo' zu 'Hallio' => 1 angefügt (bei beiden)
'Hallo' zu 'Hlalo' => 1 (Damerau Levensthein) => 1 getauscht ( al <-> la )
'Hallo' zu 'Hlalo' => 2 (Levensthein) => 2 ersetzt ( a <-> l, a <-> l )
'Hallo' zu 'Hoiallo' => 2 (bei beiden)

Diese Funktion ist besonders sinnvoll wenn es um Benutzereingaben geht, bei denen
Schreibfehler oder Fehler in der Spracherkennung auftreten können.
Die Distanz ist immer Abhängig von der Länge des gewünschten Textes zu bewerten!
Bei 'ABC' lässt eine Distanz von 3 Alles der Zeichenlänge 3 zu ! (Hier max. Distanz 1 empfohlen)

Für die Public-Rules bedeuted dieses z.B. dass die WinGui, die z.B. 'XBMC_ON' auswertet und
das Webinterface dass '/XBMC_ON' auswertet unter einer Levensthein-Distanz mit Distanz 1 geprüft
werden können. 

Besondere Vorsicht ist geboten wenn der Match in das Argument mit übergeben wird. Hier würde
der Match durch den "Original-Eingabestring" ersetzt werden. (Mit Schreibfehler).
Was z.B. bei Spracheingabe für Module wie Google oder Youtube unproblematisch wäre, da diese
die gleiche Distanzbestimmung bei ihren Suchalgorytmen verwenden.

(Siehe Wikipedia: unscharfe Suche, Pattern Matching, Levensthein, Damerau-Levensthein)

Update #27101013 Erster Trunk und Verbesserungen.

Heute ist die erste Trunk Version der EVAGui2 freigegeben worden @Rev 12.
diese Version enthält alle vorherigen Updates sowie 2 neue Funktionen:

Starten einer Applikation mit Argumenten abweichend der Config.
Redirect per STDIn an einen Deamon von einer Benutzereingabe.

Neues Modul MOD_SSH für SSH Zugriff auf Linux.
WSUS ist nun in die Bins integriert und kann für Systemupdates verwendet werden.

SVN Trunk in GoogleCode verfügbar

EVAGui2 kann jetzt als Trunk von GoogleCode
heruntergeladen werden. 

Ich werde versuchen dort immer die aktuellsten Updates
zur EVAGUI2 zur Verfügung zu stellen. Bei einem Update
ist also bevorzugt der SVN zu verwenden.
Die Version auf Sourceforge sind dann alle stable
Releases.

http://evagui2.googlecode.com/

Update #24102013

Im heutigen Update geht es um viele Verbesserungen,
die ich hier vorstellen möchte.

Als erstes wurde das Debugging für verschiedenste Arten von Fehlern verbessert.
z.B. Deamons mit Wait = True

Die LUA-Scripting Engine kann nun verschiedene Werte verarbeiten. Hierzu gehören
STDOut, STDErr und der Exitcode, so wie gehabt das Regex-Array und der Value
der Regel-Angabe.

Die Unterscheidung zwischen STDOut, STDErr und Exitcode funktioniert nun auch
in den Default- Rules.

Desweiteren wurde die Regel und Aktionsverarbeitung optimiert.

Aktionen unterstützen nun auch die Systemfunktionen (FKT) Beep und Sleep (Wait).

Das Webinterface wurde auf weitere Kommandos erweitert.

Programme enthalten nun die zusätzliche Information welche Importdatei verwendet
wurde.

Zudem gibt es nun in der Main-Definitionsdatei zusätzlich zu den Imports Pulic-Regeln.
Ziel und Zweck dieser Regeln ist dass z.B. WinGui und der Webserver auf die gleichen
Regeln reagieren. Diese Regeln können dann unter Publics abgelegt werden.

Debugging-Tipps:

Main-File enthält alle Grundprogramme ohne Funktionen und Imports
für die Ordner der Deamons ...
Die Deamons enthalten einen Import auf die Mainfile.
So werden beim Defaultlauf alle Deamons geladen, jedoch
bei einem Deamon alle Programme geladen.

Es gibt jetzt auch Else Regeln, welche als "_Else" zu definieren sind.
Diese Regel wird ausgeführt, wenn keine andere Regel aktiv wurde.

Als Modulvorbereitung befindet sich im Moment ein SSH, Modul mit dem
es möglich ist Kommandos auf einem Linux auszuführen und die Ausgabe
an die Pipe zu leiten.

Statement bzgl. Viren in der EVAGUI2

Statement bzgl. Viren in der EVAGUI2

Da die EVAGUI2 ein relativ neues Programm ist, kann es vorkommen dass diese
von Virenscannern wie dem Avast-Antivirus als "putenziell unerwünschte Software PUP"
erkannt werden. Das bedeutet dass die EVAGUI2 entweder in einer Sandbox oder gar nicht
gestartet wird. Ich als alleiniger Programmierer der Software garantiere dass EVAGUI2
und die von mir entwickelten Module frei von Schadsoftware sind!
Die Anfragen auf Freischaltung von Netzwerkports durch die Firewall ist bedingt durch
den bzw. die Webserver. Auch diverse andere Anwendungen können eine Freischaltung von
Ports an der Firewall erfordern. Diese Dienste sind in der Konfigurationsdatei zu definieren
und können jederzeit abgeschaltet werden. (Nginx, Apache, MOD_Webserver, NodeJS, NCAT)

Als weitere Information möchte ich anfügen dass kein Hacker oder Coder, der eine Schadsoftware
entwickelt, seinen Namen so öffentlich preisgeben würde!

Module der EVAGUI2 beziehen sich auf die Programme in dem Ordner Module. Die externen Anwendungen, die in der EVAGUI2 verwendet wurden, wurden von mir sorgfältig auf Viren geprüft. Verantwortlich für die Anwendungen aus dem Ordner Bin sind jedoch die Hersteller der Anwendungen!

Es kann vorkommen dass manche Anwendungen aus dem Ordner Bin als Viren erkannt werden. Der Grund
hierfür ist dass z.B. Anwendungen wie NCAT (NetCat - Dass Schweizer Taschenmesser für Netzwerkadmins) .Bei unsachgemäßer Verwendung (oder Einrichtung durch dritte) Sicherheitslücken im System öffnen können.

NCAT als Programm kann sowohl sinnvoll als auch als Backdoor verwendet werden. Das Programm ohne
Kommandozeilenparameter stellt jedoch keinerlei Gefahr dar!

Update #19102013 Typenbindungen

Im heutigen Update geht es um das Parsen der Argumente.

Die Argumente wurden bis Dato intern als String verarbeitet und wurden
jetzt durch Enumerationen ersetzt.
Betroffen von dieser Änderung sind die in den Screenshots angegebenen Typen.

Update #18102013 LUA und Rules Else

Im heutigen Update geht es um die vollständige Implementierung von LUA als Regel
und die Funtion Rule Else.

Für LUA wurde in den Regeln ein Unterknoten LUA mit einem! CDATA-Segment eingeführt.
Dieses CDATA-Segment kann den LUA Quelltext enthalten oder den Dateinamen des LUA
Codes. Als was das CDATA Segment gewertet wird hängt davon ab ob in der Regel der Type
auf LUAC oder LUAF steht. (C = Code, F = File).

Ebenfalls kann eine *ansonsten* Regel definiert werden. Diese Regel ist mit dem Type "Else"
zu versehen. wird nun keine der vorhandenen Regeln ausgeführt, so wird die Else-Regel ausgeführt.
Else Regeln können genauso wie Normale Regeln verschachtelt werden und haben die gleiche Funktionalität.

Zudem kann nun in Jeder Regel eine "Source" - Attribut mit den Werten "STDOut" oder "STDErr" oder "ExitCode" vergeben werden. die angegebene Regel wird dann nur auf den Inhalt aus dieser Pipe angewendet. Bleibt dass Feld leer, so wird STDOUTERR verwendet, welcher Out und Err beinhaltet.

Update #14102013 LUA Scripting Engine

Im nächsten Update bzw. in Vorbereitung ist im Moment die LUA Scripting Engine,
die sich in das Regelsystem perfekt einarbeiten lässt. (Mit Erweiterung der Rules auf ein
2-Dimensionales Array).

Funktionsweise des LUA in den Rules:

nehmen wir an, wir haben eine Matrix mit dem folgenden Inhalt:

12 neue Mails erhalten
14 neue RSS-Feeds erhalten

mit folgendem Ausdruck:
(..) neue (.*?) erhalten.

ergibt sich als Resultatsmatrix:

LC |  1  | 2
1    | 12 | Mails
2    | 14 | RSS Feeds.

Die Regel kann nun lauten: Vergleich: gt IDL(ine): 2 IDC: 1 mit Wert "5"
Sprich: wenn der Wert aus Zeile 2, Spalte 1 größer 5 ist dann ist das Ergebnis wahr!

=> Ergebnis aus der neuen Rules-Definition

Wird nun der Typ auf "LUAC" eingestellt, so kann unter Code (unter Attribute "LUA"):
folgendermaßen lauten:

(Match[1][1] > 1) => Die Zielmatrix wird an LUA übertragen und auf den Wert >1
geprüft. Ist das Ergebnis wahr, so wird True zurückgeliefert.

Das gesamte Regex-Array wird an LUA übertragen und steht unter "Match"
zur Verfügung. der Index beginnt ab 1 (Spalte und Zeile).
Match[1][1] bezieht sich also auf "12" aus Zeile1, Spalte 1.

der Ausdruck aus der internen Auswertung kann mit Result abgerufen
und verarbeitet werden. Steht also im LUA-Code Result > 1 dann wird
wahr zurückgegeben, wenn sich das Ergebnis aus unserem Regex-Ausdruck
IDL 2, IDC 1 größer als 1 ist (Result > 1)

Der Typ kann ebenfalls "LUAF" heißen, was bedeutet dass unter LUA ein
Dateiname des zu ladenden LUA-Codes enthalten ist.

Bei Auswahl eines LUA-Typen wird der interne Vergleich nicht angewendet !
(Vergleich + Wert) wird ignoriert !

Aufgrund des LUA-Codes mit Vergleichen, wird der LUA-Code in den Unterknoten
LUA in ein CDATA-Segment gekapselt:

<Rule IDC="1" IDL="1" Type="LUA">
<LUA>
<![CDATA[
Result = (Match[1][1] < 5)
]]> 
</LUA>

Bildunterschrift hinzufügen

Update #11102013 Bugfixes

EVAGUI2 clustert jetzt die Zeitdefinition in die Programmklasse, was den Fehler der 

Mehrfacheingabe bei den undefinierten Zeiten behebt. (= [?])

Beim starten von Shell-Programmen funktioniert nun das Ausblenden des Status der PID wenn

dass Programm geschlossen wurde.

Desweiteren wurde der Zeitmessung die Anzahl der laufenden Prozesse dieses Programms
hinzugefügt. Dies ist Sinnvoll, wenn Prozesse sich nicht innerhalb des gewohnten Zeitraumes beenden.

Hinzugefügt wurden neue Module für das Systemlog (Error jede Minute) und eine Anzeige des letzten
empfangenen Text von Programmen (nicht anwendbar bei Deamons). (Programminfo)

Update #06101013 Imports, Systemauslastung, Vererbung

Im heutigen Update gibt es einige kleine Neuerungen, die das Arbeiten mit der EVAGUI2 
einfacher gestalten.

Performance:

Das Update der Prozessliste wird nun bei einem minimierten Fenster unterbunden. Das Update der
Prozessstatusinformationen nimmt unter gegebenen Umständen ~20 % CPU Leistung auf einem
2-Kern I5 Prozessor ein. Das Fenster wird nach dem Starten in den Infobereich minimiert und erscheint dort als Symbol mit 2 Zahnrädern. Ein Doppelklick auf das Symbol öffnet die Prozessliste mit den aktuellen
Informationen. Zudem wird bei aktiver Prozessliste durch eine neue Routine die Prozessorlast gesenkt.

Imports:

Das Arbeiten mit der XML-Datei wurde durch Imports erleichtert. In der XML-Datei unter "EVA"
kann nun ein Knoten "Imports" erstellt werden, der mehrere Knoten "File" mit dem Attribut "Name"
besitzt und den Namen der Datei (relativ Anwendungspfad oder absolut auf Filesystem) beinhaltet.
Die Importdateien müssen genauso wie die Originaldatei aufgebaut sein. Somit kann (wenn die EVAGUI2 mit dem Parameter "-C" gestartet wird) eine andere Quelldatei ausgewählt und getestet werden.
Wird unter dem Attribut "File" ein Ordnerpfad angegeben, so werden alle unterliegenden Dateien aus diesem Ordner geladen.
Das Laden geschieht in verschiedenen Stufen. Gruppen werden wenn neue vorhanden erstellt.
Programme mit gleichem Namen überschreiben Programme mit gleichem Namen!
Imports von Importdateien werden nicht berücksichtigt !

Vererbung:

Programme enthalten Regex-Definitionen, die ggf. durch Regex-Definitionen von Unterregeln ersetzt werden. Wird die Regex-Definition des Programms überschrieben, enthält jedoch weitere Unterregeln, so wird die
Regex-Definition der übergeordneten Regel verwendet.

-> Programm (Regex = ^(.*?)$)
     -> Rule (Regex = ^(.*?) (.*?)$) <- ersetzt den Regex des Programms
          -> Rule (Regel = "") <- Hier wird der Regex der Übergeordneten Regel "geerbt" und ist somit
                  (Regex = ^(.*?) (.*?)$)
                  -> Event (Hat keine Regel)
                       -> untergeordnete Regeln (falls verfügbar) erhalten die Regex des Programms, dass unter
                            start definiert ist.

Update #05102013 ThreadStates und Zeitmessung

Im heutigen Update der EVAGUI2 wurde die Anzeige der Threadstates verbessert.

Wird ein Prozess (Egal ob Programm oder Deamon, Shell oder nicht Shell) gestartet,
so wird der Listeneintrag des Prozesses Grün und verbleibt in diesem Status bis ein Event eintrifft.
Die Zeitmessung erfolgt ab Start des Prozesses und wird jede Sekunde mit dem Vermerk "W: " angezeigt.

Erhält der Prozess eine Nachricht über STDIn oder STDErr, so wird der Verarbeitungsprozess
und Events gestartet. Die Zeit des Verarbeitungsprozesses wird mit dem Vermerk ("R: ") angezeigt.
Diese Verarbeitung bezieht sich auf die Abarbeitung der Events, nicht die Laufzeit der asynchronen Events selbst.
Wird ein Prozess in einer Regel asynchron gestartet, so wird nur die Zeit zum Starten gemessen, nicht
jedoch die Zeit, die der gestartete Prozess benötigt. Bei Deamon-Redirects werden ebenfalls nur die
Redirect-Zeiten gemessen. Während der Verarbeitung der Regeln wird der Listeneintrag Rot angezeigt.
Der Wert verbleibt dann 1 Timerzyklus im Status.

Wird der Prozess beendet, so wird der Timer angehalten und gibt einen Status der gesamten Prozesslaufzeit aus. Dieser Status wird mit "C: " angezeigt. Der Eintrag des Prozesses wird weiß.

Durch diese Angaben ist es möglich Prozesse zu timen. nehmen wir an der Prozess "Mailabruf" benötigt
8 Sekunden, wird aber alle 5 Sekunden gestartet, so sammeln sich die laufenden Prozesse Mail im Hintergrund an. Jeder Prozess beeinflusst zusätzlich die gesamte Systemperformance und die Laufzeit der anderen Prozesse.
Durch die Anzeige der Regelverarbeitungszeiten ist es möglich die Regelstrukturen
zu optimieren und somit ein flüssiges laufendes System zu gewährleisten.

Update #03102013 WaitState und asynchronität

Das Multithreadingkonzept der EVAGUI2 wurde überarbeitet.

Durch die asychronität der Prozesse funktionierte der Waitstate (Event - Wait = True) nicht mehr.
Folgende Multithreading-Architektur wurde nun implementiert:

Start -> Deamons (als asynchroner Thread)
Click -> Programm (als asynchroner Thread)
Time -> Programm (als asynchroner Thread)

wenn aus den Threads heraus nun ein Event getriggert wird, so werden die Prozesse in folgendem
Ablauf gestartet:

Regel (1...n) -> (synchron in Thread) -> Applikation (Wait = False) (asynchron in Thread)
Regel (1...n) -> (synchron in Thread) -> Applikation (Wait = True) (synchron in Thread)

Aus der Applikation heraus werden die Regeln und Threads im gleichen Ablauf gestartet.
laufende Deamons ignorieren den Waitstate, da diese niemals beendet werden und somit keine
Freigabe an den übergoerdneten Regel-Thread gesendet wird.

Der WaitState einer Applikation in einem Threads beeinflusst somit nur den Thread der Applikation
und keine anderen Threads die parallel in anderen Threads laufen.