Autor Thema: Parser  (Gelesen 3470 mal)

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4986
  • Are we just self-replicating DNA?
Parser
« am: 03 Januar 2013, 20:02:08 »
Hallo,

die Syntax mit ;; und %% ist für viele Anwender verwirrend und im Perl-Skripting mühsam zu handhaben (siehe http://www.fhemwiki.de/wiki/DevelopmentOpenIssues#.3B.3B_und_.25.25). Die Lösung wäre ein echter Parser für die Kommandozeile. Ich habe mich über die Feiertage umgesehen und Parse::RecDescent http://search.cpan.org/~jtbraun/Parse-RecDescent-1.967009/lib/Parse/RecDescent.pm entdeckt. Das Modul hat keine Nicht-Standard-Abhängigkeiten, könnte wohl in FHEM/lib mitgeliefert werden, und es gibt gute Tutorials http://www.perl.com/pub/2001/06/13/recdecent.html. Mit etwas Durchhaltevermögen ließe sich eine Grammatik für einen praktikablen Parser für die fhem-Kommandozeile bauen. Es müßte nur die Bereitschaft da sein, die alten Zöpfe ;; und %% durch eine []- und %EVENT-Syntax zu ersetzen mit allen Folgen für bestehende Konfigurationen und das Wiki.

Was meint Ihr?

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline Matthias Gehre

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 707
Aw: Parser
« Antwort #1 am: 03 Januar 2013, 23:24:03 »
Könnte man nicht als "light" Alternative die ";" und "%" per String-Ersetzung zu ";;" und "%%" machen,
bevor man das mit evaluiert?
Für Rückwärtskompatibilität kann man dies bei bereits doppeltem ";;" nicht tun.

Ich hab mir nicht genau angeschaut, wie das im FHEM Code realisiert wird, aber aus ";" ein ";;" zu machen
scheint die perfekte Aufgabe für etwas Perl Code zu sein (und nicht für den Anwender).

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24513
Aw: Parser
« Antwort #2 am: 04 Januar 2013, 09:19:36 »
Ich habe nichts dagegen bzw. bin bereit zum Zoepfe schneiden, wuesste aber gerne, wieviel Speicherplatz uns das kostet. Wenn es viel ist, dann ist es mir wichtig es optional zu haben.

Das % bzw. @ Problem kann man auch ohne einen Parser loesen, ist nur mit Zoepfe schneiden verbunden. Ich wuerde kein %EVENT mehr nehmen, sondern $sender, $event, $eventPart1, usw. Das wuerde ich erst parallel einfuehren, um eine Umstellung zu erleichtern. Man kann auch vorher auf $event/$sender pruefen, und falls vorhanden, keine @/% Ersetzung durchfuehren. Steht ab auf meiner TODO Liste.

@Matthias: die ;; Loesung stammt aus der Dilemma, wie man folgendes auseinanderhaelt, d.h. was wird im at ausgefuehrt, was danach.
  define mAt at 08:00 set Lampe1 on; set Lampe2 on
und etwas komplexer:
  define mAt at 08:00 { if($we) { fhem("set Lampe1 on; set Lampe2 on"); } ; set Lampe3 on
Da bin ich mir nicht mal sicher, wie ein Parser uns dabei hilft, es sei denn wir fuegen sowas wie
BEGIN/END zum fhem Syntax hinzu.

Offline Matthias Gehre

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 707
Aw: Parser
« Antwort #3 am: 04 Januar 2013, 11:18:49 »
Ich dachte, die geschweiften Klammern sind zwingend, also
  define mAt at 08:00 {set Lampe1 on; set Lampe2 on}
Die Klammern wären dann Begin/End.

Was genau ist denn die zweite Interpretation von
  define mAt at 08:00 set Lampe1 on; set Lampe2 on?
Dass "set Lampe1 on" um 8 Uhr ausgeführt wird und "set Lampe2 on" schon beim Parsen der fhem.cfg?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24513
Aw: Parser
« Antwort #4 am: 04 Januar 2013, 11:37:00 »
> Ich dachte, die geschweiften Klammern sind zwingend

Natuerlich nicht, siehe auch http://fhem.de/commandref.html#command


> Dass "set Lampe1 on" um 8 Uhr ausgeführt wird und "set Lampe2 on" schon beim Parsen der

Ja, sinnvoller ist aber folgendes Beispiel, mit aktuell gueltigen Syntax:

fhem> define mAt at 08:00 set Lampe1 on;; set Lampe2 on
was um08:00 folgendes macht:
fhem> set Lampe1 on; set Lampe2 on

Beides wird vom "gleichen" Parser verdaut, der es wissen muss, dass im ersten Fall alles als Argument fuer define zu nehmen ist, im zweiten Fall aber zwei Befehle einzeln abzuarbeiten sind.
Wenn man nur ; hat, dann ist die Entscheidung schwierig.

Offline gagga

  • Jr. Member
  • **
  • Beiträge: 51
Aw: Parser
« Antwort #5 am: 04 Januar 2013, 16:27:47 »
Hallo Rudi,

Falls ich eine rechte Erinnerung an Sprachentheorie im Studium vor einem Viertel-Jahrhundert habe, war es zumindest damals ein No-Go ein solches Konstrukt mit Trennern (;;) statt ({}) zu verwenden: Klammerung wäre auch ähnlicher zu allem was man so kennt.

Ciao,
Christof
fhem tagesaktuell aus SVN auf QNAP TS-419PII - 1 x CUL mit culfw1.49 - 1 x MAX! Cube - 3 x MAX! Thermostate - 2 x MAX! Fensterkontakt - 3 x HM Rauchmelder - 1 x HM Bewegungsmelder - 1 x HM Temperaturfühler - 3 x Elro-IT Steckdosen (Schrott) - 1 x FS20 WS1

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4986
  • Are we just self-replicating DNA?
Aw: Parser
« Antwort #6 am: 04 Januar 2013, 19:41:18 »
Zitat von: rudolfkoenig schrieb am Fr, 04 Januar 2013 09:19
Ich habe nichts dagegen bzw. bin bereit zum Zoepfe schneiden, wuesste aber gerne, wieviel Speicherplatz uns das kostet. Wenn es viel ist, dann ist es mir wichtig es optional zu haben


Das ist ein Wort! Ich werde mich damit befassen, einen lokalen vsl. nichtfunktionalen Prototypen mit Mini-Grammatik zu bauen, und dann den Mehrverbrauch an Speicher zu ermitteln à la


root@raspi ~ # ps -o pid,ruser,size,vsize,command -u fhem
  PID RUSER     SIZE    VSZ COMMAND
14331 fhem     43816  54968 /usr/bin/perl fhem.pl /opt/fhem/conf/fhem.conf


Ich melde mich wieder, wenn ich damit durch bin.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!