Delphi-Parser und Prettyprinter

[dmey]

Ich habe kürzlich eine Grammatik für Delphi 4/5 zur Generierung von Parsern mittels des TextTransformer-Programms veröffentlicht und könnte mir vorstellen, dass sich der eine oder andere hier dafür interessiert.

Delphi-Parser

Es ist meines Wissens die einzige veröffentliche Delphi-Grammatik für einen Parsergenerator, die ohne schwerwiegende Einschränkungen funktioniert. Die gesamte VCL und über 2000 pas-Dateien meiner installierten Komponenten konnte ich damit parsen.

Der Delphi-Parser benutzt einen Präprozessor zur bedingten Kompilierung der Quellen. Das ist sehr praktisch, weil damit weitere pas-Dateien unmittelbar getestet werden können.

Delphi-Präprozessor

Als Demonstration für die Verwendbarkeit des Parsers gibt es einen Prettyprinter:

Delphi-Prettyprinter

Der Prettyprinter ist auch in den freien Komponenten enthalten. Mit der ebenfalls enthaltenen Beispielsanwendung kann er geladen und unmittelbar ausgeführt werden.

TetraComponents

Die TetraComponents erlauben es TextTransformer-Projekte innerhalb von Delphi oder CBuilder-Programmen zu benutzen. Sie werden mit der ebenfalls frei verfügbaren tetra_engine.dll ausgeführt (interpretiert).

Fragen und Feedback sind erwünscht

dmey

[edit=MrSpock]Ersten Link gemäß Post #3 korrigiert. Mfg, MrSpock[/edit]

[himitsu]

Zitat:

Es ist meines Wissens die einzige veröffentliche Delphi-Grammatik für einen Parsergenerator, die ohne schwerwiegende Einschränkungen funktioniert. Die gesamte VCL und über 2000 pas-Dateien meiner installierten Komponenten konnte ich damit parsen.

die von 4/5 ist aber auch nicht gerade mehr die Neuste ... ich fürchte meine D7-Projekte werden diesen Parser nicht mögen ... bzw. der Parser sie nicht :?

Falls du die grauenhaftesten Härtetestst für soeinen Parser haben willst, dann laß sie auf meine Units los ... bisher hatten damit eigentlich alle Probleme :oops:
> himXML

ich werd's dann mal selber ausprobieren, wie weit der meine "Verbrechen" mag, aber soooo große Hoffnungen hab ich nicht, daß der damit wirklich klarkommt ... vorallem da diese Codes für D2006-D2009 und noch teilweise bis runter zu D7 erstellt wurden. :angel:

[add]
OK, ich kann's nicht probieren ... Browser meint was 404, bei deinem Parser :roll:

[dmey]

Zitat:

Browser meint was 404, bei deinem Parser

danke für den Hinweis. Nochmal der korrigierte Link:

Delphi-Parser

Zitat:

grauenhaftesten Hätetestst

ich hab's gleich ausprobiert. Bei einigen Dateien haperts am Präprozessor. Das muss ich mir noch genauer ansehen. Die meisten Dateien (24 von 31) werden geparst.
Am besten geht das übrigens im TextTransformer-Programm zu testen. Da gibt es einen Transformations-Manager, in dem man alle Dateien auf einmal auswählen kann.

Das himXML-Projekt find ich übrigens auch interessant. Vielleicht könnte man damit aus geparsten Texten direkt XML-Bäume bauen.

[dmey]

Der Präprozessor ist bisher in erster Linie dazu gedacht den Parser einfacher testen zu können. Es ist daher nur die Berechnung relativ einfacher Ausdrücke möglich. Bei den himXML-Dateien scheiterte er an: "{$IF SizeOf( x ) ..." und an "Declared( himXML.TStream )". Ich hab jetzt eine verbesserte Version hochgeladen, die diese Ausdrücke zwar parsen, aber nicht korrekt auswerten kann.

- Der Parser kannte kein "strict private". Das ist jetzt eingebaut.

- Anscheinend werden Dateien in neueren Delphi-Versionen als UTF8 gespeichert. Der TextTransformer kann zwar auch UTF8 einlesen, das wird aber im generierten Code nicht automatisch unterstützt. Deshalb hab ich zunächst als Hack eingebaut, dass ""? am Anfang der Datei überlesen wird.

- Der Parser scheitert an erweiterten Records mit Sichtabkeitsattributen etc. Das ist ein neueres Delphi-Feature. Es kommt in vier Dateien vor:

himXML.pas
himXMLi.pas
himXML_Tools.pas
OmniXMLUtils.pas

Alle anderen Dateien werden nun geparst bzw. geprettyprinted.
Die Originaldateien sind m.E. durchaus gut lesbar. Der PrettyPrinter verbessert das Bild nicht. Er ist auch mehr als Demo oder für wirklich konfusen Code gedacht. Bei verschachtelten Anweisungen macht er die Struktur deutlich.

Für diejenigen, die es interessiert hab ich das Ergebnis als zip-Datei angefügt.

Leider bin ich auf ein anderes Problem gestoßen, dass durch einen fehlerhaften regulären Ausdruck bisher verdeckt war. Vielleicht kann mir da jemand weiterhelfen: Gibt es ein eindeutiges Kriterium dafür, wann ^a ein Zeichen und wann einen Zeiger darstellt?

[p80286]

Zitat:

Zitat von dmey

Leider bin ich auf ein anderes Problem gestoßen, dass durch einen fehlerhaften regulären Ausdruck bisher verdeckt war. Vielleicht kann mir da jemand weiterhelfen: Gibt es ein eindeutiges Kriterium dafür, wann ^a ein Zeichen und wann einen Zeiger darstellt?

Ist da etwas nicht richtig rüber gekommen/verloren gegangen?

a^ ist ein Zeiger(a^.feld1, a^.last......) bzw. a ist der Zeiger und a^ der Inhalt auf den a zeigt
und
â ist ein Zeichen, ^a sind zwei Zeichen/String

(leichte Verwirrung ob der Frage)

Gruß
K-H

[himitsu]

arg, ich kann das umstellen wie ich will ... das schaltet sich ab und zu einfach wieder um :wall:
(bin vor 'ner Woche schonmal extra durch alle Units und hatte die eigentlich auf ANSI zurückgestellt)


ist nicht von mir OmniXMLUtils.pas
himXML.pas, himXMLi.pas und himXML_Tools.pas sind gerade die 3 wichtigsten Hauptdateien des Projekts :lol:

[dmey]

Z.B. im gerade behandelten Code werden Steuerzeichen verwendet:

Delphi-Quellcode:

var  DefaultIndentText: String = ^I;
resourcestring SSimpleXmlError6 = 'Íåâåðíîå çíà÷åíèå àòðèáóòà "%s" ýëåìåíòà "%s".'^M^J +
      'Äîïóñòèìûå çíà÷åíèÿ:'^M^J +
      '%s';

Definitionen für Zeigertypen sehen aber ähnlich aus:

pointer type ::= '^' type_identifier

Nun ist

type ::= simple_type oder pointer_type oder ...
simple_type ::= simple_expr

Formal könnten damit Ausdrücke für Typen auch mit einer Stringkonstanten und damit mit einem Steuerzeichen beginnen. Das scheint mir unsinnig und würde zu besageter Doppeldeutigkeit führen.

[himitsu]

toll, erst läßt sich dieses TextTransformerDingens nicht nutzen, da es bei Start nur dieses anzeigt und sich wieder beendet

Zitat:

---------------------------
Fehler
---------------------------
Error: Access violation at 0x016E2D0C (tried to read from 0x80502F5A), program terminated.
---------------------------
OK
---------------------------

und beim Deinstallieren hat es mit mein D7 teilweise zerschossen, weil es gemeinsam genutzte Dateien gelöscht hat.

[dmey]

es tut mir sehr leid, wenn das so bei Dir passiert ist. Ich hör das zum ersten mal und ich arbeite schon seit sieben Jahren an dem Programm. Ich bin gern bereit zu versuchen Dich auf irgendeine Weise zu entschädigen. Mir wäre sehr daran gelegen, genauer zu erfahren, wie das passiert ist.

Meinst Du mit TextTransformerDingens das TextTransformer-Programm? unter welchem Betriebssystem arbeitest Du? An welcher Stelle trat der Fehler auf? Vor oder nach Kopieren der Benutzerdaten? Der Installer arbeitet eigentlich so, dass alle gemeinsam genutzten Dateien hochgezählt werden. Bei der Deinstallation wird der Zähler wieder heruntergesetzt. Könnte es sein, dass die verschwundene Datei zuvor von Hand in das Systemverzeichnis kopiert worden ist? Kannst Du mir sagen, was genau bei der Deinstallation gelöscht wurde?

Einen unabhängigen fehlerfreien Installationstest für den TextTransformer ist übrigens hier zu sehen:

TextTransformer Installation

[himitsu]

Das lag nicht am Programm selber, abgesehn von der Exception.
Das Löschen noch genutzter Dateien wurde ja vom Installer verbrochen.
Aber ist ja nicht so schlimm, denn erstens zieht die Software eh in den nächsten Tagen um,
danach gibt's dann ach wieder VM's zum Testen und ich nutze D7 nicht mehr sooo oft, so daß ich auf Sachen, wie SharedMemory (die zugehörige DLL wurde mit gelöscht), erstmal verzichten kann.