XProfan

Auch wenn für XProfan unüblich - so wäre XML wohl das Passenste. Ich erinnere mich (für und in) XProfan auch schon einen XML-Parser geschrieben zu haben - nur an die Performance vermag ich mich nicht zu erinnern.

Vlt. wäre ein simples TXT ala:

root
_file_typ_item
_file_typ_item_additionalInfos

einfacher zu handhaben.

XPDB klingt gut, und natürlich kann ich mir vorstellen das XPSE ein XPDBF nutzt, aber auch XIDE für den Projektexplorer.

Sebastian
König

Hallo,

garnicht so einfach, sich von einem Linux-System aus mit Iceweasel einzuloggen... mein FastLogin-Link funktionierte irgendwie nicht, sodass ich mir erst ein neues Passwort besorgen musste...

iF

XML war in der Tat auch mein erster Gedanke und die aktuelle XPDB-Arbeitsversion erzeugt die Ausgabe schon in diesem Format (ich wollte nur in meinem ersten Posting zu dem Thema noch nicht zu sehr ins Detail gehen und erstmal allgemeine Meinungen zu dem Thema einholen...). Wenn ich nachher zuhause bin, werde ich mal eine Beispiel-Ausgabe, wie ich sie mir bis jetzt vorstelle, posten. Die Geschwindigkeit des Parsers sollte kein Problem sein, denke ich. Außerdem wird eine Funktion zum Einlesen der Dateien auch Teil des Projekts sein, sodass es garnicht unbedingt nötig sein wird, einen eigenen Parser zu schreiben (aber natürlich möglich, da das Format ja offengelegt und gut dokumentiert werden soll).

iF

XPDB klingt gut, und natürlich kann ich mir vorstellen das XPSE ein XPDBF nutzt, aber auch XIDE für den Projektexplorer.

Ja, mir gefällt der Name auch! Wenn auch die XIDE das Format nutzen würde, wäre das natürlich super!

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

H.Brill

Ja, XML wäre auch für mich passend, da dieses Format auch sehr bekannt ist.
Gerade für diejenigen (auch ich), die mit mehreren Programmiersprachen
arbeiten, bietet sich das an.

Benutze XPROFAN X3 + FREEPROFAN
Wir sind die XProfaner.
Sie werden von uns assimiliert.
Widerstand ist zwecklos!
Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.

Was die Borg können, können wir schon lange.

Sebastian
König

So, hier also wie versprochen mehr Informationen:

Wie schon erwähnt, ist die Speicherung im XML-Format die von mir favourisierte und auch bereits implementierte Variante. Ein mit der aktuellen XPDB-Version erzeugtes Beispiel habe ich unten angehängt (tatsächlich werden auch schon Informationen zu Prozeduren gespeichert, aber das habe ich zur besseren Übersichtlichkeit hier mal weggelassen...)

Wahrscheinlich ist der Code so schon sehr einfach zu verstehen, aber trotzdem ein paar Anmerkungen:

Jedes gespeicherte Element ist ein object - das ergab sich ganz direkt aus meiner internen Klassen-Hierarchie.
Um was genau es sich handelt, steht im Attribut type, so gilt zum Beispiel 1=Include-Datei, 2=Header usw.
Was in name steht ist im Grunde beliebig, sollte sich aber in der Regel automatisch aus dem analysierten Code ergeben
Das Attribut id sollte innerhalb jeder Datei eindeutig sein.

Neben der Voraussetzung, dass es sich um gültiges und wohlgeformtes XML handeln muss, würde ich zusätzlich folgende Bedingungen an den Aufbau vorschlagen:

Die Attribute type, id und name sind Pflichtangaben für jedes Objekt, die Angabe parent im Grunde auch, nur nicht für die Hauptdatei des analysierten Codes
Objekte, auf die sich irgendwo bezogen wird (zum Beispiel im parent-Attribut), müssen in der Datei VOR der Referenzierung stehen. (Damit wird vermieden, dass man den Code per Multi-Pass-Verfahren parsen oder Referenzen später ermitteln muss. In der Regel sollte die Bedingung bei der sequentiellen Analyse eines Projekts automatisch erfüllt sein, aber zur Not könnte man es auch ohne großen Aufwand beim Speichern der XML-Datei sicherstellen.)
Die ID-Zählung muss innerhalb jeder Datei bei 1 beginnen. (Das erleichtert ggf. das Zusammenfügen von Datenbanken.)

Zusätzlich zu den (Pflicht-)Attributen, die direkt im < object > -Tag stehen, können abhängig vom Typ auch weitere Informationen gespeichert werden; ich nenne diese dann Werte. Ein Beispiel wäre level für Include-Dateien, das die Verschachtelungstiefe angibt. Auch hier könnte man abhängig vom Typ Pflichtangaben verlangen.

Generell finde ich, dass so wenige Angaben wie möglich zur Pflicht erklärt werden sollten, um die Verwendungsmöglichkeiten der Datenbank-Dateien sehr allgemein bleiben. Wenn man zum Beispiel einfach nur die von einer Unit exportierten Prozeduren beschreiben möchte, ist das Attribut line sicher nicht allzu sinnvoll...

Ok, soviel erstmal zu meinen bisherigen Gedanken... gibt es dazu soweit Meinungen, Anregungen oder Einsprüche?

MfG

Sebastian

Mit XPDB erzeugter Beispiel-Code:
Kompilieren Markieren Separieren

<?xml version=1.0 standalone=yes?>
<xpdb>
<header>
<version>0.1</version>
<generator>XPDB Alpha 0.2</generator>
</header>
<object id=1 type=1 name=XProfEd.prf>
<file>D:ProgrammeXProfan100SourceXProfEd.prf</file>
<level>0</level>
</object>
<object id=2 type=2 name=windows.ph parent=1 line=4>
<file>D:ProgrammeXProfan100Includewindows.ph</file>
</object>
<object id=3 type=2 name=messages.ph parent=1 line=5>
<file>D:ProgrammeXProfan100Includemessages.ph</file>
</object>
<object id=4 type=2 name=commctrl.ph parent=1 line=6>
<file>D:ProgrammeXProfan100Includecommctrl.ph</file>
</object>
<object id=5 type=2 name=structs.ph parent=1 line=7>
<file>D:ProgrammeXProfan100Includestructs.ph</file>
</object>
<object id=6 type=1 name=RGHToolbar.inc parent=1 line=11>
<file>D:ProgrammeXProfan100SourceRGHToolbar.inc</file>
<level>1</level>
</object>
<object id=7 type=1 name=XPrfEditClass.prf parent=1 line=12>
<file>D:ProgrammeXProfan100SourceXPrfEditClass.prf</file>
<level>1</level>
</object>
<object id=8 type=2 name=XPrfEdit.ph parent=7 line=2>
<file>D:ProgrammeXProfan100SourceXPrfEdit.ph</file>
</object>
<object id=9 type=1 name=LetzteDateien.inc parent=1 line=13>
<file>D:ProgrammeXProfan100SourceLetzteDateien.inc</file>
<level>1</level>
</object>
</xpdb>

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

Feste Pfadangaben in einem XPDBF?

Es fehlt auch ein Parameter URL, somit könnte man projektabhängige Dateien beschreiben welche lokal garnicht auf Platte sind - bzw. Includes und Units beschreiben welche vom Importer halt erst geladen würden... (hatte ich für XIDE eh angeplant)

Nachtrag: Ich würde auch gleich nach dem Header nicht mit den Objekten beginnen, hier fehlt eine weitere Kapselung.

Michael
Wodrich

Sieht gut aus und ist verständlich.

Nicht so wie die Delphi und VB Projektdateien, wo man nicht mal MIT Handbuch durchsteigt.

XML-NotePad freut sich auch über das Format.

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Frank
Abbing

Kannst du bitte mal genauer erklären, wofür diese Dateien am Ende sinnvoll sind?

Sebastian
König

Die bisherige Zustimmung zum XML-Format freut mich erstmal!

Feste Pfadangaben in einem XPDBF?

Das mit den Pfadangaben habe ich erstmal vorläufig so gemacht... ist wahrscheinlich wirklich nicht immer sinnvoll. Ich könnte mir gut vorstellen, hier durch eine Angabe im Header (absolute,relative,none) mehrere Möglichkeiten zuzulassen.

Auch eine optional URL-Angabe im Header ist eine gute Idee.

iF

Nachtrag: Ich würde auch gleich nach dem Header nicht mit den Objekten beginnen, hier fehlt eine weitere Kapselung.

Stimmt - werde ich einbauen.

EDIT: Was stimmt denn hier mit den Zitaten nicht?

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

Die URL bezog sich eher auf ein Dateiobjekt.

Mit den Quotes ist alles IO, Du hattest nur hinter einem Quote (und vor dem Gleichzeichen) ein Freizeichen mit eingebaut, und [quote = blub] gibt es nicht was iFBB im Bezug aufs Quote zum Abschalten zwang.

@Frank: Ich könnte Dir eine solche XML geben - Du öffnest diese in XIDE - XIDE läd und ordnet alle Dateien des Projektes an die richtige Stelle. Solch eine Datei beschreibt z.B. Aufenthaltsorte von Projektzugehörigen Dateien und Einstellungen. Das müssen wir XIDE zwar noch beibringen, aber ich denke vom ASM-Core her gibts da nichts neues hinzuzufügen - soll heissen - alles über Plgs möglich.

Ich hatte ja so oder so vor genau diese Funktionalität in die XIDE hineinzukatapultieren - Stichworte Projekt-Assistent/Explorer - vlt. nimmt Sebastian uns dabei etwas Arbeit ab.

(vorausgesetzt sein Parser zuckt nicht bei XPSE-Codes und versteht diese ebenso wie normale XCodes.)

Sebastian
König

Frank Abbing

Kannst du bitte mal genauer erklären, wofür diese Dateien am Ende sinnvoll sind?

Zum Beispiel zur Beschreibung von Unit-Inhalten. Zugegeben, hier gibt es schon das bereits erwähnte .def-Format vom XPSE, aber ein flexibles, allgemein unterstütztes Format halte ich irgendwie für eine gute Idee.

Mein ursprünglicher Plan war, einfach einen Browser für die Struktur von XProfan-Projekten zu schreiben - als ich darauf kam, dass man die ermittelten Informationen auch speichern können sollte (um nicht immer den ganzen Code parsen zu müssen), verlagerte ich den Schwerpunkt des Projekts auf das Dateiformat. Irgendwie gefiel mir die Idee... Die ist natürlich nicht neu! Ein bischen wurde ich auch von den Browse-Informationen, die mein Visual C++ generiert, inspiriert.

Das bringt mich gleich zum nächsten Punkt, den auch iF schon angesprochen hat: XIDE könnte das Format nutzen, um Informationen zu Projekten zu speichern. Beim Öffnen eines Projekts könnte dann sehr schnell die Struktur eingelesen werden, ohne dass der ganze Code einmal gelesen werden muss. Bei Änderungen muss dann nur die Datenbank im Speicher aktualisiert werden und beim Schließen des Projekts wird alles wieder in die Datei geschrieben. Voraussetzung für diese Anwendung ist natürlich, dass ein solcher Projekt-Browser Teil der IDE sein soll... (Informationen dazu gibt es ja bisher kaum)

Auch Zusatzprogramme wie zum Beispiel Debugger könnten vielleicht von einer solchen Projekt-Datenbank profitieren...

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]