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.

[dmey]

Ich bin froh, dass sich Dein anfänglicher Ärger etwas gelegt hat. Aber für mich bzw. für andere Benutzer bleibt die Sache ein Katastrophe.

Zitat:

SharedMemory (die zugehörige DLL wurde mit gelöscht)

Damit meinst Du wahrscheinlich die borlndmm.dll, oder? Ich hab nochmal in meinem Inno-Setup-Script nachgeschaut. Dort sind die Attribute "sharedfile onlyifdoesntexist" gesetzt, d.h, sie wird nur installiert, wenn noch nicht vorhanden und:

Zitat:

Uses Windows' shared file counting feature (located in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\SharedDLLs). This enables a file to be shared between applications, without worrying about it being inadvertently removed. Each time the file is installed, the reference count for the file is incremented. When an application using the file is uninstalled, the reference count is decremented. If the count reaches zero, the file is deleted (with the user's confirmation, unless the uninsnosharedfileprompt flag is also specified).

Wenn Du mir helfen könntest, den Grund für die Exception herauszufinden, würde ich Dir eine kostenlose Lizenz des Programms überlassen. Dein momentanes sich in den letzten Zügen befindliches System scheint die ideale Testumgebung zu sein. Auf sauberen VM's hab ich die Installation und den Programmstart schon bis zum Erbrechen getestet.
Am anfälligsten hat sich bisher die Verwaltung des Fensterlayouts gezeigt. Das Layout ist in der Datei "EditDefault_ge.ds" gespeichert und wird bei der Installation ins Settingsverzeichnis kopiert. Evtl. startet der TT fehlerlos, wenn man die datei umbenennt. (Dann sind alle Fenster nebeneinander angeordnet.) Ein weiterer Punkt der mich interessieren würde ist, ob eine Tetra.ini im Settings-Verzeichnis angelegt wurde.

[himitsu]

Zitat:

Zitat von dmey

Damit meinst Du wahrscheinlich die borlndmm.dll, oder?

jupp, und via D7 war sie ja schon vorhanden

Zitat:

Zitat von dmey

Wenn Du mir helfen könntest, den Grund für die Exception herauszufinden,

ich kann ja mal demnächst nachsehn, wenn ich etwas Zeit dafür hab.

das XP läuft ja eh auf einer unwichtigen und ich würd's mal "externen" Platte nennen.
ich kann es also noch eine Weile aufheben und auch später nochmal reingucken :stupid:

[dmey]

Nochmals zu dem Problem mit den Steuerzeichen und Zeigertypen. Als Nicht-Delphianer wundere ich mich dass zwar folgende Typdefinition möglich ist:

Delphi-Quellcode:

Type1 = 1..12;

nicht aber

Delphi-Quellcode:

Type2 = ^A..^F;

Das hab ich nur empirisch getestet. Es geht aus dem wenigen, was es an formalen Grammatiken für Delphi gibt nicht hervor. Ich habe daraus geschlossen, dass Typdefinition keine Steuerzeichen in besagter Schreibart enthalten dürfen und habe das TextTransformer-Projekt entsprechend verbessert.

[DP-Maintenance]

Dieses Thema wurde von "MrSpock" von "Object-Pascal / Delphi-Language" nach "Tools rund um Delphi" verschoben.
Ist eher ein Tool für Delphi.

[alzaimar]

Zitat:

Zitat von dmey

Als Nicht-Delphianer wundere ich mich dass zwar folgende Typdefinition möglich ist:

Delphi-Quellcode:

Type1 = 1..12;

nicht aber

Delphi-Quellcode:

Type2 = ^A..^F;

Das erste ist ein Untertyp für ganze Zahlen, das zweite wäre ein Untertyp für Zeichen. Ersteres ist eben möglich, Letzteres nicht. Is einfach so.

[Sailor]

Wieso soll das nicht gehen?

TYPE
TType1 = 1..12;
TType2 = 'A'..'F';
TType3 = #00..#31;

[dmey]

Wenn man einen Parser entwickelt ist die Fragestellung nicht die, nur die eine oder andere Möglichkeit zu finden, wie ich ein entsprechendes Array definiere, sondern alle zulässigen Möglichkeiten zu erfassen. Und "Type2 = ^A..^F;" ist eben nicht erlaubt. Das hat für die Entwicklung des Parsers den Vorteil, dass, wenn hinter dem Gleichheitszeichen einer Typdefinition ein Caret-Zeichen steht, sofort klar ist, dass es sich um einen Zeiger handeln muss.

In einem anderen Forum hatte mir jemand vorgeschlagen den Parser an der Testsuite von Free-Pascal zu testen. Das hab ich gemacht und der Delphi-Parser konnte dadurch in etlichen speziellen Fällen nochmals verbessert werden.

Die Testsuite und mehr Erläuterungen gibt es hier:

Delphi-Parser mit Testsuite

[dmey]

Aus dem Delphi Parser hab ich jetzt das Programm Delphi2Cpp gebaut, das Delphi Quellcode in C++ Code konvertiert.

Delphi2Cpp : Konverter von Delphi nach C++

Bisher ist die Übersetzung auf den CBuilder zugeschnitten und Delphi-Features, die nach Delphi 4/5 eingeführt wurden können noch nicht geparst werden. Die Konvertierung erspart alle einfachen Ersetzungen und Umstellungen des Codes, die den weitaus größten Teil der Übersetzungsarbeit ausmachen. Außerdem werden eine Reihe weiterer komplexerer Übersetzungsschritte ausgeführt. In den meisten Fällen wird allerdings eine manuelle Nachbearbeitung des erzeugten Codes erforderlich sein.
Die besten Ergebnisse erhält man, wenn in den Optionen die Pfade zur VCL gesetzt werden (das kann auch die aktuellen VCL sein, optimal ist aber die VCL 4/5). Delphi2Cpp wird dann bei der Übersetzung der ersten Dateien relativ langsam, merkt sich aber die Informationen derjenigen Dateien, die bereits einmal geparst wurden, so dass es zunehmend schneller wird.


Mehr Details zu den einzelnen Übersetzungsleistungen sind hier aufgelistet:

Delphi2Cpp Details


Das Programm ist Shareware und 30 Tage kostenlos zu testen. Über Feedback würde ich mich freuen.

[himitsu]

Andersrum (C > Delphi) würde mir besser gefallen :angel2:

[dmey]

So einen Kommentar hatte ich schon erwartet. Hier wendet sich die Qualität von Delphi gegen sich selbst. Die Sprache ist so aufgebaut, dass sie verhältnismäßig leicht und sehr schnell geparst werden kann. Einen Parser für C++ zu schreiben ist ungleich schwerer. Immerhin habe ich das einmal zur Konvertierung einer Firmensoftware von C++ nach Java gemacht. Für eine vorgegebene Menge an C++ Code könnte ich es auch für Delphi machen, aber leider nicht allgemein. :(