XProfan

- Seite 2 -

Sebastian
König

Die URL bezog sich eher auf ein Dateiobjekt.

Auch das ist natürlich möglich. Hauptsächlich wird das wahrscheinlich im Zusammenhang mit Units Verwendung finden.

iF

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.

Ah, ok.

iF

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.)

Würde ich selbstverständlich gern machen

. Ich könnte dafür aus meinem Code eine statische Bibliothek mit Low-Level-Zugriff auf die von mir erstellte Datenbank-Klasse bereitstellen - bei Bedarf auch mit einer nicht objektorientierten Schnittstelle, weil der Zugriff darauf in ASM vielleicht etwas umständlich wäre. Hier könnte ich mich ganz an Euren Wünschen orientieren.

Bislang verarbeitet mein Parser nur reines XProfan (und auch davon nur einen kleinen Teil, da ich mit der Arbeit daran gerade erst begonnen habe...) Unterstützung für XPSE möchte ich gern einbauen - aber selbst parsen halte ich für unnötige Arbeit... man doch einfach XPSE aufrufen und mit der Ausgabe weiterarbeiten, oder?

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

Alte Profan²-Seite: [...]

11.09.2007 ▲

Die URL bezog sich eher auf ein Dateiobjekt.

Auch das ist natürlich möglich. Hauptsächlich wird das wahrscheinlich im Zusammenhang mit Units Verwendung finden.

Ich dachte da eher nicht unbedingt an Units, eher an ein offenes (mini!) CVS was die XProfan.Com bereits unter der Haube trägt (wegen XIDE). Hiermit soll es möglich sein aus XIDE heraus ein komplettes Projekt hochzuladen und innerhalb von XIDE gemeinsam zeitgleich an einem Projekt zu arbeiten.

Sebastian König

Bislang verarbeitet mein Parser nur reines XProfan (und auch davon nur einen kleinen Teil, da ich mit der Arbeit daran gerade erst begonnen habe...) Unterstützung für XPSE möchte ich gern einbauen - aber selbst parsen halte ich für unnötige Arbeit... man doch einfach XPSE aufrufen und mit der Ausgabe weiterarbeiten, oder?

Wäre komplizierter da man prüfen müsste ob überhaupt XPSE angewandt wird (und dann auch noch jedes mal einen Prozess starten - phew...) . Lediglich nach #include & include und ein wenig {/} geparse ist nötig (z.B. für die Funktions/Prozedurerkennung)
Im Prinzip ist alles vor { wenn es nicht if while & co ist, eine Funktion/Prozedur.
Kompilieren Markieren Separieren

#include meineinclude.inc// mit dem # davor ists ein include_once
include meineinclude.inc
myproc{}

while 1{}

Die Sache ist nur, ich habe hier wg. der XIDE natürlich ein viel neueren XPSE als es hier zum DW gibt, dennoch sollte die aktuelle hier-downloadbare Version hierfür ausreichen.

11.09.2007 ▲

Sebastian
König

Ok, so langsam verstehe ich, was Du meinst. Es würde wohl reichen, statt der file Angabe einfach alternativ oder zusätzlich url zu erlauben, oder?

iF

Hmm... ok, im Prinzip könnte ich das wohl auch direkt einbauen. Wäre es denn nötig, dafür mein zeilenbasiertes Parsen (genauer: Zusammenfügen von per Backslash verbundenen Zeilen und anschließendes Auftrennen, falls Doppelpunkte vorkommen) aufzugeben? Deine XPSE-Codes erinnern ja mittlerweile sehr an C++ oder Java, wo Zeilengrenzen einfach nur Leerräume sind...

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

Alte Profan²-Seite: [...]

11.09.2007 ▲

Ok, so langsam verstehe ich, was Du meinst. Es würde wohl reichen, statt der file Angabe einfach alternativ oder zusätzlich url zu erlauben, oder?

Genau, und wenn mgl. auch noch eine Dateiversionsangabe - z.B. FileVer. Das rührt daher das alle XIDE-Panel/Plugin-SDK-Quelltextdateien eine Versionsinfo im Source tragen welche z.B. auch vom Updatecheck genutzt wird. Hierfür gibts 2 Varianten:
Kompilieren Markieren Separieren

//Version:0.0.0
/Version:0.0.0

Diese Info könnte Dein Parser ebenfalls aus dem Source lesen und der XML beifügen.

Sebastian König

Tatsächlich parst xpse nicht Zeilenbasiert, hätte da aber ne Idee wie Du Deinen Parser dennoch kleinhalten kannst wobei man nicht einmal das Semikolon als (xpse)möglichen Zeilentrenner wegdenken muss. (Das unten aber nur funktioniert da Du ja den Source nicht wirklich prüfen musst etc.)

Sehen wir uns mal die drei einfacheren Problemfälle an:
Kompilieren Markieren Separieren

meineProc(string a,b,c,float x,y,z,long q,w,e){

    return true

}

//oder
meineProc(string a,b,c,float x,y,z,long q,w,e)

{

    return true

}

//oder
meineProc(string a,b,c,float x,y,z,long q,w,e){return true}

Angenommen das ganze File liegt in einem String s und wir haben zusätzlich das pseudo whiletranslate (
Kompilieren Markieren Separieren

whiletranslate(string s,from,to) {

    while instr(from,s) {s=translate$(s,from,to)}

    return s

}

) zu Verfügung, dann gilt:
Kompilieren Markieren Separieren

//source säubern
s=translate(s,	,x20)
s=whiletranslate(s,x20x20,x20)
s=whiletranslate(s,
x20,
)
s=whiletranslate(s,x20
,
)
s=whiletranslate(s,
,
)
//andere Zeilentrenner
s=translate(s,;,
)
s=translate(s,:,
)
//klammern lösen

s=translate(s,{,

    {

        )

    s=translate(s,},

}

)
s=whiletranslate(s,
,
)

Nach diesem Pass liegt eigentlich alles Zeilenbasiert vor. Kann sein das ich etwas übersehen habe da ichs hier einfach hineingetippt hab und es nur zum Verständnis dienen soll. Natürlich ist nach diesem Pass der Source zerstört - aber ich meine Dein Parser braucht keinen brauchbaren Source und sollte den Source ruhig derart zerhechseln können das leicht die Informationen extrahierbar sind welche für die XML nötig sind.

Der Parser müsste dann nur noch schauen ob die nächste Zeile exakt ein { ist, um zu wissen das die aktuelle Zeile eine Proc sein soll. (Wenn nicht grad while if whileloop & co).

Ein klein wenig gemeiner ist die Tatsache das xpse auch folgendes beherrscht:
Kompilieren Markieren Separieren

string meineProc(string a,b,c,float x,y,z,long q,w,e){//hierbei würde der Rückgabewert True vor Rückgabe in einen String konvertiert

    return true

}

//oder
long meineProc(string a,b,c,float x,y,z,long q,w,e)//hierbei würde der Rückgabewert 12 vor Rückgabe in ein Long konvertiert

{

    return 12

}

//oder
int meineProc(string a,b,c,float x,y,z,long q,w,e){return true}
// es gibt (xpse kennt) bool, int, long, float, string und mem

Hoffe das hilft ein wenig.

Sebastian
König

//Version:0.0.0
/Version:0.0.0

Diese Info könnte Dein Parser ebenfalls aus dem Source lesen und der XML beifügen.

.

iF

Gewissermaßen... ich bin jetzt doch wieder stark der Meinung, dass diese Arbeit nicht in meinen Parser gehört und ihn unnötigerweise auf eine Vielfaches des bisherigen Umfangs aufblähen würde...

Ich denke aber, ich habe einen schönen Alternativ-Vorschlag: Ich könnte ohne großen Aufwand eine Schnittstelle einbauen, die beliebige Präprozessoren unterstützt. Es läuft dann einfach so, dass die Adresse einer Callback-Funktion angegeben werden muss, welche mein internes GetNextLine() ersetzt. Alles, was diese Funktion leisten müsste, ist die Zeile in reinem XProfan und die zugehörige Zeilennummer aus der Quelldatei zu liefern.

In dieser Variante müsste mein Parser dann garnichts über zusätzliche Syntax-Features wissen und wäre völlig allgemein gehalten. Außerdem würden eventuelle zukünftige XPSE-Erweiterungen und auch XPIA automatisch unterstützt werden. Und ein zusätzlicher Prozess müsste auch nicht gestartet werden...

In der Anwendung liefe es dann so, dass ein Projekt wie zum Beispiel XIDE einfach zwei Bibliotheken (libxpdb.lib und libxpse.lib) dazulinkt und dem XPDB-Parser das Plug-In bekanntmacht.

Je länger ich darüber nachdenke, desto besser gefällt mir diese Lösung. Sie hält beide Aufgabenbereiche schön modular getrennt und gestattet somit sehr einfache Wartung und Erweiterung. Was hältst Du davon?

MfG

Sebastian

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

Alte Profan²-Seite: [...]

GetNextLine könnte aber nicht ausreichen in Fällen wie diesen:
Kompilieren Markieren Separieren

myproc(string abc)

{

    return abc

}

Sebastian
König

GetNextLine könnte aber nicht ausreichen in Fällen wie diesen:
Kompilieren Markieren Separieren

myproc(string abc)

{

    return abc

}

Wieso nicht? Es sollte in so einem Fall einfach folgendes liefern (jede Zeile entspricht einem Aufruf von GetNextLine, im Kommentar steht die Zeilennummer, die zusätzlich geliefert wird):
Kompilieren Markieren Separieren

proc myproc 1

    parameters abc$ 1
    return abc$ 3
    endproc 4

Du verstehst?

MfG

Sebastian

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

Alte Profan²-Seite: [...]

Hrm ich verstehe sehrwohl, deshalb meine ich ja das GetNextLine nicht ausreichen könnte. In og. xpse Zeile 1 ist - ohne das Zeile 2 bekannt ist nicht ermittelbar das es sich um eine proc handelt! Was hältst Du von der Variante den Code einfach bevor Du ihn passierst komplett an einen externen Parser zu geben? Du könntest dann einfach mit dem Rückgabeergebnis arbeiten welches halt auch den kompletten Code enthält.

Sebastian
König

Hrm ich verstehe sehrwohl, deshalb meine ich ja das GetNextLine nicht ausreichen könnte. In og. xpse Zeile 1 ist - ohne das Zeile 2 bekannt ist nicht ermittelbar das es sich um eine proc handelt!

Hmm... möglicherweise verstehen wir uns gegenseitig falsch, aber das sollte doch kein Problem sein... der Prä-Parser ;) kann ja schon Zeile 2 und meinetwegen noch mehr im voraus lesen - wichtig wäre nur, das Ergebnis dann meinem Parser zeilenweise vorzusetzen... (so meinte ich mein Beispiel). Aber egal, denn:

iF

Was hältst Du von der Variante den Code einfach bevor Du ihn passierst komplett an einen externen Parser zu geben? Du könntest dann einfach mit dem Rückgabeergebnis arbeiten welches halt auch den kompletten Code enthält.

Gefällt mir sehr gut!

Im Grunde lautete so ja mein erster Vorschlag (Aufruf von XPSE durch meinen Parser). Natürlich kann man das dann wie bei der GetNextLine-Variante auf der Plug-In/Callback-Basis machen und so das ständige Starten eines weiteren Prozesses vermeiden. Wichtig wäre nur, dass das ganze auf Include-Ebene stattfindet, also dass immer nur genau die angegebene Datei verarbeitet wird und $I-Anweisungen im Code bleiben. Ich nehme mal an, es wäre kein großer Aufwand, eine passende Lib aus deinem bestehenden XPSE-Code zu erzeugen, oder?

MfG

Sebastian

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

Alte Profan²-Seite: [...]

Der Aufwand hält sich in Grenzen, klebt dann aber doch wieder an mir.

Ich meine aber ich würde XPSE nicht als Grundlage für die Lib nehmen - das Abspecken (oder verteilen von ifdefs) wäre deutlich aufwändiger als das bisl Parserei. Ich glaub ich schreib aber einfach eine Funktion und schubs Dir den C-Code rüber den Du dann direkt gleich einbauen kannst. Das mit der Lib können wir uns bei dem kleinen Teil sparen.

13.09.2007 ▲

Sebastian
König

Der Aufwand hält sich in Grenzen, klebt dann aber doch wieder an mir.

Ok, natürlich kann ich die Arbeit auf Basis Deines Codes gern übernehmen - also nur her damit

. In welcher Form genau ich das ganze einbaue, schaue ich dann mal - ich möchte die Schnittstelle dafür auf jeden Fall allgemein halten...

Priorität hat auch erstmal, dass alles grundsätzlich funktioniert und ich dann nur noch Erweiterungen für weitere Syntax-Elemente einbauen muss. Priorität haben zunächst Includes, Header, Units und Procs.

MfG

Sebastian

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

Alte Profan²-Seite: [...]

13.09.2007 ▲