Seite 1 von 2 12 LetzteLetzte
Zeige Ergebnis 1 bis 15 von 20
  1. #1

    Werkzeug - vjassdoc

    Aktualisierungen:
    2009-12-02: Mappedia-Link gesetzt.
    2009-11-09: Version 0.3 ist da. Es gibt eine Menge Änderungen, die ich hier lieber nicht alle auflisten werde :-).
    2009-08-08: Beschreibung im Thread angepasst.
    2009-04-04: Eine SVN-Ablage des Programms ist jetzt auf sourceforge.net verfügbar.
    2009-03-09: Version 0.2.3 ist da. Es gibt jetzt die Optionen --private und --textmacros, womit sich endlich auch private Objekte und Textmakrobereiche parsen lassen. Zusätzlich wurden sehr viele Fehler behoben.
    2009-02-11: Version 0.2.2 ist da. Zu den bedeutenden Änderungen zählen unter anderem die Funktionalität der Datenbankerzeugung, die Erzeugung vollständiger Seiten für jede Art von Objekt und die einfache Auflistung aller Objekte auf der Index-Seite.
    2009-01-25: Version 0.2.1 ist da. Allerdings ist es gut möglich, dass sie sich unter Windows nicht richtig kompilieren lässt, da ich das noch nicht ausprobiert habe. Es wird nun cmake verwendet. Die Übersetzungsdateien lassen sich vermutlich wenn überhaupt vorerst nur unter Linux benutzen. Die Makros UNIX und WIN32 werden jetzt per cmake gesetzt. Außerdem gab es eine Menge Fehlerbehebungen (siehe ChangeLog). Ich arbeite gerade an einer RPM- und einer ebuild-Datei für die gängigsten Linux-Distributionen. Die Seiten werden noch nicht alle korrekt ausgegeben. Dies wird sich im Laufe der nächsten Tage noch ändern.
    2009-01-15: Hurra, jauchzet und frohlocket: Eine neue Version ist da!
    2008-10-11: Das Programm wurde in einem komprimierten Archiv zusammengefasst und unter die GPLv2 gestellt.

    Beschreibung:
    Mappedia-Artikel

    Hinweise:
    • Kritik ist wie bei allen meinen Veröffentlichungen ausdrücklich erwünscht.
    • Ich komme nicht oft dazu, das Programm unter Windows zu testen, weshalb es bei diesem Betriebssystem eher zu Fehlern kommen kann (eigentlich nur bei der Installation/Kompilierung).


    Herunterladen:
    Die Veröffentlichungsversionen findet ihr hier.
    Der Quell-Code kann mittels SVN mit folgendem Befehl heruntergeladen werden: svn co https://vjasssdk.svn.sourceforge.net...sssdk/vjassdoc vjassdoc.

  2. #2
    Ex-Webmaster
    Staff Maps
    Benutzerbild von peq
    Registriert seit
    Jul 2008
    BNet Account
    peq
    Beiträge
    3.922
    So, ich hab das mal getestet, aber zur Zeit finde ich die Ausgabe noch nicht so hilfreich.
    Wäre schön, wenn du mal beschreibst, wie die Ausgabe aussehen soll, wenn das Programm fertig ist.

    Wichtig fände ich, dass man in der Dokumentation auch die Struktur des Codes behält, also Struct-Methoden auch ihrem Struct zugeordnet sind und das Programm auch zwischen public und private unterscheidet.



    Für windows kompilierte Version ist im Anhang:

  3. #3
    Jup, war jetzt zwei Wochen im Urlaub und hab auch schon an der nächsten Version gearbeitet.
    Ich bin allerdings noch am Überlegen, wie die Ausgabe in der Endversion aussehen soll. Eventuell werde ich auch Sachen wie eine Klassenhierachieabbildung oder so einbauen. Bis jetzt haben sich schon einige Grundlegende Dinge, wie z.B. das farbliche Schema oder die Navigation geändert.
    Auch der Code wurde etwas umstrukturiert, damit nicht mehr Dinge wie die Bibliothek, der Bezugsrahmen, die Struktur und die Schnittstelle bei jedem Objekt gespeichert werden, auch wenn diese gar keine dieser Eigenschaften besitzen kann.
    Momentan ist es so, dass der private-Code gar nicht geparst wird, da der Anwender des Codes diesen ja sowieso nicht verwenden soll.
    Danke für die kompilierte Version, ich werd sie gleich mal auf den Server packen.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  4. #4
    So hallo.
    Nach langer Zeit gibt es auch bei diesem Projekt mal wieder etwas zu melden. In den letzten Tagen habe ich viel Zeit in die Entwicklung von vjassdoc gesteckt und bin jetzt so weit, den Quell-Code zumindest schon einmal vorläufig zu veröffentlichen.

    Vielleicht finden sich so ja noch einige Fehler, die ich selbst erst viel zu spät bemerkt hätte. Außerdem ist die HTML-Ausgabe meiner Meinung nach schon wesentlich besser als die der letzten Version.

    Leider kam ich noch nicht dazu all jene Extras einzubauen, die in der fertigen Version 0.2 enthalten sein sollten.

    Es ist schon zwar schon teilweise möglich eine SQLite-Datenbank aus den geparsten Daten zu erzeugen, allerdings gibt es dabei noch einiges zu richten, sodass man die Option --database (-b) besser nicht verwenden sollte.

    Anstatt eines Ausgabedatei-Arguments wird nun das Ausgabepfad-Argument --dir verwendet, da ich schon damit begonnen habe, einen Seitenmodus zu implementieren, der für jedes Objekt dessen eigene Seite erzeugt.

    Mit der Option --alphabetical (-a) werden die Objekte vor der Ausgabe in die Index-Datei alphabetisch sortiert.

    Die Option --verbose (-v) dient einer detailierteren Ausgabe. Leider verlangsamt sie das Programm enorm, weshalb ich sie noch niemandem empfehlen würde.

    Die Optiom --time (-t) zeigt am Ende des Programmablaufs die Dauer, zum Einen in ihrer tatsächlichen Zeit und zum Anderen in umgerechneten CPU-Ticks, dessen an.

    Um für jedes Objekt eine eigene Seite erzeugen zu lassen, was bis jetzt eigentlich noch nichts bringt, muss man die Option --pages (-p) benutzen.

    Ansonsten hat sich eigentlich außer der Code-Struktur an sich nicht viel geändert.
    Die Schlüsselwörter delegate und library_once, sowie so genannte Array-Strukturen (struct Bla extends array[10]) sollten nun korrekt geparst werden.

    Zum Kompilieren wird derzeit noch das Programm make verwendet. Das soll sich demnächst ändern. Ich werde vermutlich auf cmake umsteigen, was das Kompilieren hoffentlich angenehmer machen wird.

    Zur Internationalisierung verwende ich das GNU-Programm gettext, weshalb man das Programm auch mit der gettext-Bibliothek linken muss/sollte.
    Dem zufolge, was ich gelesen habe, existiert auch eine Windows-Portierung von gettext. Ich bitte alle Benutzer der neuen Version zu berücksichtigen, dass ich an diesem Programm ausschließlich unter Linux arbeite/gearbeitet habe.

    Geschwindigkeitsvergleiche zwischen der alten und der neuen Version habe ich bis jetzt noch keine durchgeführt. Es wäre aber sicherlich mal interessant zu sehen, ob die neue Version (ohne --verbose-Option ;-)) wirklich wesentlich langsamer ist als die alte.

    Im Quell-Code-Archiv befindet sich außerdem noch ein sehr einfaches Style-Sheet, welches man ins Verzeichnis der erstellten API-Referenz kopieren/verschieben kann, um etwas schönere Tabellen angezeigt zu bekommen.
    Falls jemand noch einige Vorschläge des Designs wegen hat: Nur her damit!
    Ich möchte an dieser Stelle noch meinem Bruder für seine heutige Hilfe beim Verständnis einer korrekten Verwendung von HTML und gettext danken, auch wenn er das niemals liesen wird :-).

    So, jetzt hab ich ne Menge geschrieben. Ich freue mich wie immer über jede Art von einigermaßen konstruktiver oder wenigstens lustigen Kritik.

    Und zu guter Letzt folgt noch der Link zum Archiv:
    !!!!!!!!!111111111einseinselfhuhn

    Achso, ich wollte eigentlich auch schon längst auf SVN umsteigen, da sich das beim Server meines Bruders auch sehr schön anbietet. Das wird aber wohl noch ne Weile dauern.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  5. #5
    gexxo
    Guest
    sorry aber der kommentar muss sein:

    Soetwas könnte man sicher viel schneller mit einem gsl script erledigen als das ganze nochmal in c++ zu coden
    (jaja ich weiss, das Programm gibts länger als gsl, egal, der kommentar muss sein )

  6. #6
    Viel schneller? Ich würde eher sagen: Viel einfacher.
    Denn immerhin gibt es dieses Werkzeug ja schon eine Weile und die Entwicklung einfach abzubrechen wäre ziemlich sinnlos, da es ja schon recht schnell ist.
    Ich code also nichts nochmal sondern immernoch.

    Wie schnell würde das denn mit GSL laufen? Wie schnell ist GSL im Vergleich zu C++ und wie lange braucht es um ein Map-Script zu interpretieren? Existieren da bereits Konstrukte, die die geparsten Code-Objekte enthalten?
    Falls nicht, dann wäre es nicht einmal einfacher. Ein kurzer Blick in den GMSI-Thread zeigt mir nur ein Map-Struct, dass halt den Code enthält.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  7. #7
    Ex-Webmaster
    Staff Maps
    Benutzerbild von peq
    Registriert seit
    Jul 2008
    BNet Account
    peq
    Beiträge
    3.922
    Im Anhang dann mal die Windows-Bins. Habs leider nur so hinbekommen, dass man noch ein par cygwin-dlls dazu braucht. Ich versuchs morgen oder so mal anders.

    Beim compilen ist mir aufgefallen, dass man Win_32 besser nicht setzt, sonst kommen erstmal Fehler

    Code:
    #elif WIN_32
    sollte denke ich heißen
    Code:
    #elif defined WIN_32
    Aber gebracht hat mir das Ändern dann auch nix, habe das i = 0 wieder in i = 1 geändert und an der anderen Stelle habe ich auch einfach mal den Linux-Teil genommen.


    So nun zur eigentlichen Kritik am Tool:

    - sollte UTF-8 Unterstütung haben, oder zumindest die deutschen Sonderzeichen im HTML als ä etc. schreiben. (oder funktioniert das nur unter Windows nicht?)

    - erkennt private struct / public structs nicht

    - structs sollten richtig ausführlich dokumentiert werden, mit ihren methoden und attributen.

    - einige parameter, die man dem programm übergeben kann würde ich umdrehen. Hatte jetzt zum Testen immer
    vjassdoc.exe --title MyTestFile --files test.j -j -h -p
    Ich denke -j und -h hat man öfter aktiviert als deaktiviert

    - Die Option -p erzeugt nur leere Seiten?


    Insgesamt sieht das ganze noch recht unfertig aus, finde ich. Jedenfalls gibt die erstellte html-datei noch nicht so viel her.

    Ich würde die Idee mit den mehreren Seiten weiterverfolgen. Die Index-Seite sollte nur alle librarys auflisten und alles was nicht in Librarys ist. Auf den Library-Seiten sollte dann alles sein, was in der Library ist, aber alles was nochmal untergeordnet ist (wie struct-member) sollte auch erst mal untergeordnet bleiben.

    Ich würde dann auch die einzelnen Dateien nicht einfach Nummerieren sondern ihnen sinnvolle Namen geben. Die Seite zu einer Methode create eines structs Einheit in der Library Hallo könnte dann zum Beispiel Hallo.Einheit.create.html heißen.


    So das wars dann erstmal. Hier nun die Windows-Bin inklusive Design-Vorschlag in Form einer css-Datei

    http://peq.bplaced.de/uploads/peq/vjassdoc.zip

  8. #8
    Original geschrieben von peq
    Im Anhang dann mal die Windows-Bins. Habs leider nur so hinbekommen, dass man noch ein par cygwin-dlls dazu braucht. Ich versuchs morgen oder so mal anders.

    Beim compilen ist mir aufgefallen, dass man Win_32 besser nicht setzt, sonst kommen erstmal Fehler

    Code:
    #elif WIN_32
    sollte denke ich heißen
    Code:
    #elif defined WIN_32
    Aber gebracht hat mir das Ändern dann auch nix, habe das i = 0 wieder in i = 1 geändert und an der anderen Stelle habe ich auch einfach mal den Linux-Teil genommen.
    Ja, das werd ich dann mal richten. Ich war mir nicht sicher, ob man das /-Zeichen auch unter Windows als Verzeichnistrennzeichen verwenden kann.

    Original geschrieben von peq
    So nun zur eigentlichen Kritik am Tool:

    - sollte UTF-8 Unterstütung haben, oder zumindest die deutschen Sonderzeichen im HTML als ä etc. schreiben. (oder funktioniert das nur unter Windows nicht?)
    Also meine Code-Dateien sind UTF-8-kodiert und wenn die Index-Datei erzeugt wird, dann werden die Umlaute auch korrekt ausgegeben. Sollte das unter Windows tatsächlich nicht gehen, dann muss halt eine Makro-Lösung mit einer Ersetzungsfunktion her :-/.

    Original geschrieben von peq
    - erkennt private struct / public structs nicht
    Public-Structs sollte er eigentlich. Das dürfte ein Bug sein. Private-Zeugs wird immer übersprungen. Das ist schon seit Version 0.1 so, da man mit der API-Referenz eigentlich nur das Zeug dokumentieren soll, was ein anderer benutzen kann. Vielleicht baue ich besser noch eine Option ein, mit deren Hilfe man private Sachen auch parsen kann.

    Original geschrieben von peq
    - structs sollten richtig ausführlich dokumentiert werden, mit ihren methoden und attributen.
    Ist alles im Kommen: Siehe Seitenoption.

    Original geschrieben von peq
    - einige parameter, die man dem programm übergeben kann würde ich umdrehen. Hatte jetzt zum Testen immer
    vjassdoc.exe --title MyTestFile --files test.j -j -h -p
    Ich denke -j und -h hat man öfter aktiviert als deaktiviert
    Mal schauen. Da hast du schon Recht. Vielleicht kommt das in der nächsten Version, aber irgendwie ist es dann später auch dumm, dass man, wenn man nur eine Datenbank erzeugen möchte, den HTML-Modus deaktivieren muss. Wenn dann würde ich höchstens die vJass-Option explizit deaktivieren lassen.

    Original geschrieben von peq
    - Die Option -p erzeugt nur leere Seiten?
    Da bin ich grade am Werkeln. Diese Seiten sollen natürlich nicht leer bleiben.

    Original geschrieben von peq
    Insgesamt sieht das ganze noch recht unfertig aus, finde ich. Jedenfalls gibt die erstellte html-datei noch nicht so viel her.
    Ja, das ist alles etwas unübersichtlich. Ich hätte wohl lieber gleich zu einen mehrseitigen Modus wechseln sollen, wie es bei normalen API-Dokumentationen auch der Fall ist.

    Original geschrieben von peq
    Ich würde die Idee mit den mehreren Seiten weiterverfolgen. Die Index-Seite sollte nur alle librarys auflisten und alles was nicht in Librarys ist. Auf den Library-Seiten sollte dann alles sein, was in der Library ist, aber alles was nochmal untergeordnet ist (wie struct-member) sollte auch erst mal untergeordnet bleiben.
    Sowas in der Art wird es auch werden. Ich werde jetzt erstmal versuchen, die einzelnen Seiten entsprechend zu füllen und am Ende dann die Index-Datei zu ändern, damit man in der Zwischenzeit (falls ich nochmal neue Versionen veröffentliche) nicht ganz ohne Ausgabe da steht.

    Original geschrieben von peq
    Ich würde dann auch die einzelnen Dateien nicht einfach Nummerieren sondern ihnen sinnvolle Namen geben. Die Seite zu einer Methode create eines structs Einheit in der Library Hallo könnte dann zum Beispiel Hallo.Einheit.create.html heißen.
    Könnte man machen. Ich sehe aber keinen richtigen Sinn darin. Immerhin geht man sowieso meistens über die Index-Datei auf die einzelnen Seiten.

    Original geschrieben von peq
    So das wars dann erstmal. Hier nun die Windows-Bin inklusive Design-Vorschlag in Form einer css-Datei

    http://peq.bplaced.de/uploads/peq/vjassdoc.zip
    Ja, vielen Dank mal wieder, dass du sie für Windows kompiliert und mir konstrutive Kritik gegeben hast.

    edit:
    Dein Archiv lässt sich bei mir nicht öffnen :-(.

    edit2:
    Original geschrieben von peq
    Aber gebracht hat mir das Ändern dann auch nix, habe das i = 0 wieder in i = 1 geändert und an der anderen Stelle habe ich auch einfach mal den Linux-Teil genommen.
    Heißt das, dass unter Windows das erste Argument auch der Programmname oder irgendwas anderes ist? Laut einem meiner C++-Bücher sollte das eigentlich anders sein.

    Bzw. habe ich auf die Datentypen wstring und wchar_t verzichtet, da eigentlich nur in den Dokumententations- und normalen Kommentaren größerer Unicode-Zeichen vorkommen.
    Gut, vielleicht auch noch in String-Literalen, aber das war's. Demnach, was ich gelesen habe, werden diese Datentypen unter Windows als richtige Unicode-Datentypen gebraucht und nicht einfach nur als Zeichen mit größeren Werten.
    Vielleicht hat das ja was damit zu tun, allerdings kenne ich mich nicht besonders mit Windows aus.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  9. #9
    gexxo
    Guest
    Original geschrieben von Barade
    Viel schneller? Ich würde eher sagen: Viel einfacher.
    Denn immerhin gibt es dieses Werkzeug ja schon eine Weile und die Entwicklung einfach abzubrechen wäre ziemlich sinnlos, da es ja schon recht schnell ist.
    Ich code also nichts nochmal sondern immernoch.

    Wie schnell würde das denn mit GSL laufen? Wie schnell ist GSL im Vergleich zu C++ und wie lange braucht es um ein Map-Script zu interpretieren? Existieren da bereits Konstrukte, die die geparsten Code-Objekte enthalten?
    Falls nicht, dann wäre es nicht einmal einfacher. Ein kurzer Blick in den GMSI-Thread zeigt mir nur ein Map-Struct, dass halt den Code enthält.
    Mit "Schneller" meinte ich einfacher, oder halt "schneller geschrieben".

    Natürlich ist C++ theoretisch eine ganze Nase schneller als GSL, da GSL doppelt interpretiert wird. Ich schätze mal für map öffnen + doc parsen + in html datei speichern würde es 2 sekunden brauchen.
    Klar, in C++ geht's sicher in 0,2. Aber mal ehrlich: Bei programmen die so kurz brauchen ist es doch relativ egal, ob sie 0,2 oder 2 sek brauchen.

    Ich will auch gar nicht, dass du es umschreibst, hab den kommentar nur abgegeben, da mir da mal wieder aufgefallen ist, für was das script nützlich sein kann .

    Aber mal etwas weiter gedankengespielt:
    GMSI hat in der library functions.gsl einen parsemechanismus für funktionen, diesen müsste man nur noch auf structs und den anderen vJass firlefanz ausweiten, dann sollte es klappen.
    GSL hat halt den vorteil, dass es Java pattern matching benutzen kann, das relativ effizient und einfach ist.
    Klar gibt es solche pattern matching frameworks auch für C++, wenn du schon ein solches verwendest, dann ist gut.
    Der Vorteil, den ich in GSL sehe, ist, dass es die meisten nervigen Sachen für dich wegabstrahiert: Map auspacken, trigger laden,... das macht alles das Programm, in C++ musst du das selbst machen. Aber klar, da du das ja jetzt auch schon gemacht hast, ist es ja egal, das wäre eher eine Frage wenn du jetzt anfangen würdest das tool zu entwickeln.

    Aber interessant find ich es schon sowas in GSL zu versuchen, nur mal als kleinen Proove of Concept.
    Ich werd mal ein kleines Beispielscript schreiben wenn ich zeit hab.

  10. #10
    Das viel schneller hab ich schon richtig verstanden. Ich meinte nur, dass da dieses Programm schon existiert, man es ja nicht noch mal schreiben muss, sondern nur verbessern und das dauert im Verhältnis nicht unbedingt länger.

    Ich verwende kein solches Framework und das ist auch nicht unbedingt schlecht. Dieses Programm ist speziell für Jass bzw. vJass zugeschnitten worden und wühlt sich durch jede Zeile und wertet diese entsprechend aus. Vielleicht kann ich das hier und da noch etwas optimieren, aber ich denke, dass es so eigentlich noch schneller läuft als wenn man ein abstraktes Framework verwendet.
    Kann natürlich auch anders sein, ich denke, dass das 1. auf das Framework und 2. auf die Qualität meines Codes ankommt. Wenn der sich nicht allzu lahm durchwühlt, sollte es auf jeden Fall schneller sein.

    Ja das Map-Auslesen würde abstrahiert werden, aber das ist auch nicht die Aufgabe dieses Programms. Man könnte ja vielleicht in GMSI-Skript schreiben, dass den ausgelesenen Code an dieses Programm übergibt. Das wäre auch eine sinnvolle Kombination.
    Ich selbst entwickle zur Zeit noch eine vJass-IDE, die ebenfalls dieses Programm verwendet und auch MPQ-Dateien anspricht. Meine Erfahrung sagt mir halt, dass es am sinnvollsten ist, erstmal das Vorhandene zu suchen und es dann anzusprechen als gleich mit einer Eigenentwicklung kommen zu wollen.

    Zur Geschwindigkeit:
    Also wenn ich eine ältere Version meines Projekts ASL parse (10832 Zeilen auf 97 Dateien verteilt) dauert das ca. 0,82 Sekunden. Allerdings schwankt die Zeit irgendwie auch ziemlich. Vorhin hat es noch 2.6 Sekunden oder so gebraucht. Vielleicht liefen da auch einige Hintergrundprozesse, was weiß ich?

    @peq:
    Ich habe jetzt mal auch standardmäßig eingestellt, dass die Argumente bei 1 beginnen, was anscheinend auf allen Systemen so ist.
    Außerdem habe ich noch den Fehler behoben, dass Windows-Dateipfade richtig abgeschnitten werden.
    Das Argument --vjass wurde nun durch das Argument --jass ersetzt, wodurch vJass-Code standardmäßig mitgeparst wird.
    Bevor ich die neue Version hochlade, will ich noch die Seitenerstellung von einigen Objekten verbessern, damit sich auch wirklich was geändert hat.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  11. #11
    gexxo
    Guest
    Original geschrieben von Barade


    Ich verwende kein solches Framework und das ist auch nicht unbedingt schlecht. Dieses Programm ist speziell für Jass bzw. vJass zugeschnitten worden und wühlt sich durch jede Zeile und wertet diese entsprechend aus. Vielleicht kann ich das hier und da noch etwas optimieren, aber ich denke, dass es so eigentlich noch schneller läuft als wenn man ein abstraktes Framework verwendet.
    Kann natürlich auch anders sein, ich denke, dass das 1. auf das Framework und 2. auf die Qualität meines Codes ankommt. Wenn der sich nicht allzu lahm durchwühlt, sollte es auf jeden Fall schneller sein.
    Jein, das Framework ist zwar abstrakt, aber dafür hochoptimiert und durchdacht.
    Das Patternmatching framework baut zum beispiel aus der übergebenen expression einen endlichen automaten und lässt diesen auf die Eingabe los. Das ist unglaublich schnell und vor allem auch unglaublich einfach:

    Beispiel:
    Code:
    findAll(EINGABESTRING,"function\\s+(\\w+)\\s+takes\\s+(.+?)\\s+returns\\s+(\\w+)\\s*\\n(.*?)\\n?\\s*endfunction");
    Diese eine einzige Zeile findet alle jass funktionen in dem <EINGABESTRING> und speichert noch dazu sofort:
    -ihren namen
    -ihre signatur
    -ihren rückgabewert
    -ihren funktionskörper
    in extra variablen (alles was bei patterns innerhalb von klammern steht wird automatisch gespeichert, stichwort "capturing groups").

    Für dieselbe funktionalität ohne pattern matching framework brauchst du garantiert ne menge zeilen und es wird garantiert nicht so effektiv ablaufen.

  12. #12
    Natürlich ist es wesentlich einfacher es so zu machen. Da ich aber schon angefangen hatte es von Hand zu coden, habe ich es auch so weitergeführt, weil der Parser ja bereits recht gut funktioniert hat.

    Ich bezweifle nicht, dass es so sehr effektiv ist, aber, dass es so wirklich schneller ist usw. weil das Programm z. B. auch erstmal den Ausdruck auswerten muss und eben abstrahiert ist.
    Es macht nicht unbedingt viel aus, aber doch schon etwas.

    Würde ich das Programm nochmal ganz neu schreiben, dann würde ich eventuell auch mit einem Framework anfangen, um mir die Arbeit zu sparen, aber nachträglich hätte das natürlich kaum einen Sinn.

    Einziger Vorteil wäre vielleicht eine Vereinfachung der Wartung des Quell-Codes. Ich versuche ihn recht verständlich zu halten und solange ich der Hauptverantwortliche für dieses Programm bin, ist es sowieso kein Problem. Falls ich natürlich irgendwann nicht mehr weiterentwickle und immer mehr vJass-Features rauskommen, wäre es eventuell ein Problem für einen anderen, dieses Programm zu erweitern.

    Davon gehe ich aber nicht unbedingt aus. Es gab jetzt mit Version 0.2 schon bedeutende Verbesserungen in der Code-Strukturierung, da ich die Objekte gescheit in Klassen zerlegt habe und der Prozess wesentlich übersichtlicher abläuft (Vorher hatten die Objekte keine eindeutige Id und Pointer-Elemente ihrer Eigenschaften, wie der zugehörigen Bibliothek usw., stattedessen wurde alles umständlich in einem String gespeichert, der ständig zerlegt werden musste).

    Möglicherweise wird sich hier auch noch einiges tun, allerdings bezweifle ich, dass ich ganz auf ein Framework umsteigen werde. Mal schauen, mit Sicherheit sagen kann ich es noch nicht.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  13. #13
    Version 0.2.3 ist da und bringt die beiden neuen Optionen --private und --textmacros mit sich. Leider kam ich immer noch nicht dazu ein entsprechendes ebuild bzw. eine RPM-Datei zu erstellen.

    Auch der Seitenaufbau einiger Objekte wurde überarbeitet. Derzeit arbeite ich noch an der Möglichkeit mittels @struct structname, @interface interface usw. Objekte in Dokumentationskommentaren verlinken kann.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  14. #14
    Die aktuelle Version in der SVN-Ablage unterstützt jetzt endlich Module. Außerdem kann man eine Vererbungsliste in Form einer einfachen HTML-Seite erzeugen.
    Es lassen sich jetzt sogar lokale Variablen bzw. Funktionsblöcke parsen. Das ist zwar nicht besonders sinnvoll, aber wer's braucht ...
    Bis ich allerdings Version 0.3 veröffentliche dauert es noch eine Weile, da ich die Datenbankoption endlich mal zum Laufen bekommen will, auch wenn die Meisten sie nicht brauchen werden.
    Kann sein, dass es einen Fehler bei Textmakros gibt, da sich das Programm einmal aufgehängt hat, als ich die ASL parsen wollte. Den werde ich natürlich so schnell wie möglich beheben.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

  15. #15
    Die beiden neuen Features des JassHelpers - keys und Blockkommentare - werden jetzt unterstützt.
    Ich arbeite noch daran Dokumentationsblockkommentare zu unterstützen, also /** */.
    wc3lib (C++-Entwickler gesucht)
    Advanced Script Library (vJass-Entwickler gesucht)
    Die Macht des Feuers (Modelierer und 2d-Grafiker gesucht)
    Die-Macht-des-Feuers-Blog
    Mappedia

Seite 1 von 2 12 LetzteLetzte

Forumregeln

  • Es ist dir nicht erlaubt, neue Themen zu verfassen.
  • Es ist dir nicht erlaubt, auf Beiträge zu antworten.
  • Es ist dir nicht erlaubt, Anhänge hochzuladen.
  • Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
  •