XProfan

Auch wenn per XProfan unüblich - so wäre XML wohl das Passenste. Ich erinnere mich (per 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 naturalmente kann ich mir vorstellen das XPSE ein XPDBF nutzt, aber auch XIDE per den Projektexplorer.

Sebastian
König

Ciao,

garnicht so einfach, sich von einem Linux-System aus mit Iceweasel einzuloggen... mein FastLogin-Link funktionierte irgendwie nicht, sodass ich mir erst ein neues Password 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 File auch Teil des Projekts sein, sodass es garnicht unbedingt nötig sein wird, einen eigenen Parser zu schreiben (aber naturalmente possibile, da das Format ja offengelegt und gut dokumentiert werden soll).

iF

XPDB klingt gut, und naturalmente kann ich mir vorstellen das XPSE ein XPDBF nutzt, aber auch XIDE per den Projektexplorer.

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

MfG

Sebastian

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

Alte Profan²-Seite: [...]

H.Brill

Ja, XML wäre auch per mich passend, da dieses Format auch sehr bekannt ist.
Gerade per 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-File, 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 File 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 per jedes Objekt, die Angabe parent im Grunde auch, nur nicht per die Hauptdatei des analysierten Codes
Objekte, auf die sich irgendwo bezogen wird (zum Beispiel im parent-Attribut), müssen in der File 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 potuto man es auch ohne grande Aufwand beim Speichern der XML-File sicherstellen.)
Die ID-Zählung muss innerhalb jeder File 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 per Include-File, das die Verschachtelungstiefe angibt. Auch hier potuto man abhängig vom Typ Pflichtangaben verlangen.

Generell finde ich, dass so wenige Angaben wie possibile zur Pflicht erklärt werden sollten, um die Verwendungsmöglichkeiten der Datenbank-File 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 potuto man projektabhängige File beschreiben welche lokal garnicht auf Platte sind - bzw. Include und Unità beschreiben welche vom Importer halt erst geladen würden... (hatte ich per XIDE eh angeplant)

Nachtrag: Ich würde auch gleich nach dem Testata 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 circa 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 File 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 potuto mir gut vorstellen, hier durch eine Angabe im Testata (absolute,relative,none) mehrere Möglichkeiten zuzulassen.

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

iF

Nachtrag: Ich würde auch gleich nach dem Testata 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 potuto Dir eine solche XML geben - Du öffnest diese in XIDE - XIDE läd und ordnet alle File des Projektes an die richtige Stelle. Solch eine File beschreibt z.B. Aufenthaltsorte von Projektzugehörigen File 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 circa Plgs possibile.

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 File 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 per eine gute Idee.

Mein ursprünglicher Plan war, einfach einen Browser per 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 Io l' Schwerpunkt des Projekts auf das Dateiformat. Irgendwie gefiel mir die Idee... Die ist naturalmente 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 potuto das Format nutzen, um Informationen zu Projekten zu speichern. Beim Öffnen eines Projekts potuto 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 File geschrieben. Voraussetzung per diese Anwendung ist naturalmente, 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: [...]