Essay - Free Blitz2D
Übersicht Sonstiges SmalltalkGehe zu Seite Zurück 1, 2, 3, 4
TheShadowModerator |
Sa, Nov 17, 2007 12:50 Antworten mit Zitat |
|
---|---|---|
Vertex hat nur einen lexer geschrieben, der code in token splittet - jedoch noch keine Fehlerprüfung durchführt | ||
AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2 |
Silver_Knee |
Sa, Nov 17, 2007 17:32 Antworten mit Zitat |
|
---|---|---|
aso sry | ||
Vertex |
Di, Nov 20, 2007 1:49 Antworten mit Zitat |
|
---|---|---|
Ich habe jetzt nochmal die Grammatik neu aufgestellt:
freeblitz.pdf Ich bin verblüfft wie komplex die Blitz-Syntax ist. Wobei ich das keines Wegs gut heiße. Beim Überblicken lässt sich die Grammatik mit einem LL(1) Parser bewerkstelligen jedoch machen da die Nicht-Terminale ForStatement und EachStatement eine Ausnahme. Sie haben beide als Anfangssymbol FOR und als Follow-Symbol beide einen Identifier. Dennoch baue ich den Top-Down Parser über rekursiven Abstieg. Für die beiden For-Schleifen kann ich dann LL(2) mal einsetzen. mfg olli |
||
vertex.dreamfall.at | GitHub |
lettorTrepuS |
Fr, Nov 23, 2007 7:02 Antworten mit Zitat |
|
---|---|---|
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger. | ||
Vertex |
Fr, Nov 23, 2007 7:34 Antworten mit Zitat |
|
---|---|---|
Ich hänge noch bei der Grammatik fest.
Code: [AUSKLAPPEN] TypeDefinition = TYPE Identifier
{FIELD Identifier ['%' | '#' | '$' | '.' Identifier] [('[' Expression ']')]} ENDTYPE; Das war die alte Regel, hatte aber nicht so etwas erlaubt: Code: [AUSKLAPPEN] Type TTest
Field A, B, C ; Mehrere Fields in einer Zeile Field D Field E End Type Mit der neuen geht das: Code: [AUSKLAPPEN] TypeField = Identifier
['%' | '#' | '$' | '.' Identifier] [('[' Expression ']')]; TypeDefinition = TYPE Identifier {FIELD TypeField {',' TypeField}} ENDTYPE; Dann die Regel Code: [AUSKLAPPEN] VariableName = Name ['%' | '#' | '$' | '.' Identifier]];
ObjectName = Name ['.' Identifier]; Name = Identifier ['(' [Expression {',' Expression}] ')'] [{'\' Identifier}]; funktioniert auch nicht. Sie berücksichtigt bspw. den Indexoperator für statische Blitzarrays nicht. Für ObjectName, die bei for Ob habe ich eine entsprechende Regel gefunden, die bei Code: [AUSKLAPPEN] FOR ObjectName '=' EACH Identifier
zum tragen kommt.
StatementSequence NEXT; Code: [AUSKLAPPEN] DynamicArraySelector = '(' Expression {',' Expression} ')';
StaticArraySelector = '[' Expression ']'; TypeSelector = '.' Identifier; FieldSelector = '\' Identifier; Field = '\' Identifier [('%' | '#' | '$') | [TypeSelector | StaticArraySelector] {Field}]; ObjectName = Identifier [TypeSelector] [DynamicArraySelector] Ich brauch aber noch eine Regel, die soetwas anstandslos aufnimmt: Code: [AUSKLAPPEN] A.TTest(0, 0, 0)\C.TBlub\Z% = 10
Dabei habe ich nur eine entwickelt, bei der auch folgendes möglich wäre: Code: [AUSKLAPPEN] A.TTest(0, 0, 0)\C#\Z% = 10
was natürlich ein Fehler ist. Ich müsste erreichen können, das %, # und $ nur am Ende stehen. VariableName = ObjectName ['%', '#', '$']; geht auch nicht, denn es wäre folgendes Szenario möglich: Code: [AUSKLAPPEN] A.TTest(0, 0, 0)\C.TBlub\Z.TIdent% = 10
Bevor das nicht gelöst ist, kann ich auch nicht mit dem Parser anfangen. Das ganze ist leider essentiell. Weiterhin weiß ich auch noch nicht so recht, wie ich Includedirektive verarbeiten soll. Ich möchte mit Objektdateien und anschließenden Linken arbeiten, aber die Tatsache, dass Include nahezu überall stehen darf, macht es recht schwer. mfg olli |
||
vertex.dreamfall.at | GitHub |
lettorTrepuS |
Fr, Nov 23, 2007 23:48 Antworten mit Zitat |
|
---|---|---|
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger. | ||
TheShadowModerator |
Sa, Nov 24, 2007 22:17 Antworten mit Zitat |
|
---|---|---|
Tja vertex, jetzt siehst du, dass vermeintlich einfache Sachen doch komplexer sind wie gedacht... ein Lexer ist der aller einfachste Part...
Zitat: Bevor das nicht gelöst ist, kann ich auch nicht mit dem Parser anfangen
du denkst falsch... der lexer splittet den code in token - und lässt noch fehlerhafte syntax durchgehen... (fehlerhafte token aber nicht - etwa strings ohne " am Ende) erst z.B. beim parsen müssen syntaxfehler erkannt werden... Zitat: Warum also nicht gleich einiges einfacher lösen? Beispiel: Während die Daten einer BB Datei gesammelt werden muss bereits auf den Include-Befehl reagiert werden. Also ein Datei-Import während der BB Quellcode noch analysiert wird.
yup - anders geht es nicht - es ist ein PRÄPROZESSOR-Befehl ich persönlich bin noch beim lexer am coden... es ist noch nicht fertig - paar files muss ich nochmal durchchecken - aber es funktioniert... |
||
AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2 |
Vertex |
So, Nov 25, 2007 16:17 Antworten mit Zitat |
|
---|---|---|
ShadowTurtle, du haust mich manchmal um, mit deinen riesen Posts - den Sinngehalt kann ich dennoch nicht verstehen
Sicher wird jede Variable in etwa gleich behandelt. Bei Ausdrücken machen MyInt%, MyType\MyField% und MyFunction%() keinen Unterschied. Syntaktisch völlig korrekt. Um es nochmal festzuhalten: - Lexer zerlegt Quellcode in Tokens. Tokens werden durch reguläre Ausdrücke beschrieben - Präprozessor verarbeitet Direktiven - Parser macht zuerst eine syntaktische Analyse basierend auf der Kontextfreien Grammatik definiert in EBNF. Nebenbei arbeitet er mit Attributen für jede Regel um bspw. bei Ausdrücken zwischen Int, String usw. zu unterscheiden. Die Attributierung ist nicht in der EBNF definiert. Weiterhin baut er die Symboltabellen auf. Wie das geschieht, ist ebenfalls nicht in der EBNF beschrieben. Am Ende kommt eine Objektdatei heraus, wobei noch Symbole(bzw. Bezeichner) keine Adresse zugewiesen bekommen haben. - Linker bindet alle Objektdateien zu einer ausführbaren Anwendung und ersetzt Symbole durch ihre Speicheradressen. Bei FreeBlitz sieht es leicht anders aus: - Lexer ist wie gehabt - Präprozessor wird es nicht geben für eine einzige Direktive(nämlich Include) - Parser prüft auch die Syntax, arbeitet mit Attributierung und organisiert ebenfalls eine Symboltabelle - In einem zweiten Pass wird aber das Vorhandensein von Symbolen und Prüfung deren Typ durchgeführt(was eigentlich mal Aufgabe eines Linkers wäre) - Erzeugen einer korrekten C Datei - GCC kompiliert C Datei zu Objektcode(.o Datei) - GCC linkt .o Datei mit fertig kompilierter Runtime(Bibliothekt für LoadImage, CreateTCPServer usw.) - Resultat ist ausführbare Anwendung Zum Thema Includedirektive: Die Includedirektive in C verhält sich genau so wie die von Blitz. Was der C Compiler damit dann anstellt, bleibt ihm überlassen. TheShadow: Das Aufstellen der Syntax mittels EBNF ist der schwerste Part bei einer so komplexen Sprache. Zitat: du denkst falsch... der lexer splittet den code in token - und lässt noch fehlerhafte syntax durchgehen... (fehlerhafte token aber nicht - etwa strings ohne " am Ende) erst z.B. beim parsen müssen syntaxfehler erkannt werden...
Bei was denke ich da falsch? Berufst du dich auf meinen Joker-Token dabei, der bei einem falschen regulären Ausdruck fort fährt beim Lexen? Wenn ja, das ist notwendig um mehrere Fehler ausgeben zu können wie bei C, C# usw. und nicht mit einer einzigen Messagebox die Fehleranalyse abzubrechen. Btw: Ich habe gestern mal J-Algo ausprobiert. Bin ein wenig enttäuscht, da es doch ein zu großer Aufwand, dem Ding die kontextfreie Grammatik beizubringen. Dann habe ich nochmal Jaccie ausprobiert. Den Lexer habe nahezu fertig. Ich muss bloß mal schauen, dass er die Separatoren mir nicht in der Tokenliste ausgibt. Beim Parser sehe ich jedoch schon große Probleme. Keines der mitgelieferten Beispiele lies sich ausprobieren und die Fehlermeldung "Syntaxerror" ist auch nicht besonders aufschlussreich ^^ |
||
vertex.dreamfall.at | GitHub |
lettorTrepuS |
So, Nov 25, 2007 17:34 Antworten mit Zitat |
|
---|---|---|
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger. | ||
Vertex |
So, Nov 25, 2007 18:27 Antworten mit Zitat |
|
---|---|---|
shit, stimmt ^^
Dennoch geht das ganz gut zu handeln. Schließlich braucht jede .bb Datei nur eine .c Datei zu erzeugen. Aber ohne jetzt wieder mit großen Worten zu wedeln mal ein gedachtes Beispiel: Code: [AUSKLAPPEN] ; A.bb
Function MyFunction%(Value%) Value = Value*2 End Function ; B.bb Value = Value + 1 Return Value --> // A.c BBInt bbMyFunction(BBInt bbValue); BBInt bbMyFunction(BBInt bbValue) { bbValue = bbValue*2; #include "B.c" } // B.c bbValue = bbValue + 1; return bbValue Dabei könnte jede .bb Datei a) eine .c Datei erzeugen UND zusätzlich noch eine .sym Datei, wo alle Bezeichner drin stehen. Somit muss beim ändern von A.bb nicht B.bb erneut kompiliert werden. Man kann aber mithilfe der .sym Datei die Bezeichner in A.bb prüfen. Ich will ganz einfach nicht diese stundenlangen Kompilierzeiten haben, weil man das große Projekt in Includes gesplittet hat. Das war bei BlitzBasic der absolute Frusterzeuger. mfg olli |
||
vertex.dreamfall.at | GitHub |
Gast |
So, Nov 25, 2007 18:37 Antworten mit Zitat |
|
---|---|---|
Einfach alle Includes in die Main.bb (Also die wo Compilert wird, die dann als Temp SPeichern und dann Compileren.
Dann gibts kein Problem mit Include. |
||
Vertex |
So, Nov 25, 2007 18:48 Antworten mit Zitat |
|
---|---|---|
Da gibt es keine Probleme aber aus Erfahrung weiß ich, wie lahm das ist. BlitzMax arbeitet ja auch nicht umsonst mit prekompilierten Modulen die dann einfach zum Schluss dazu gelinkt werden. Sonst müsste man ja immer noch jedes Modul zusätzlich kompilieren.
Wir hatten damals ein Spiel in Blitz3D mit mehreren tausend Zeilen Quellcode. Wenn man da Player\X = Player\X + 0.1 in Player\X = Player\X + 0.5 umänderte, mussten die anderen tausende Quellcode Zeilen mit kompiliert werden, nur weil man mal die Geschwindigkeit des Spielers geändert hat. Das Kompilieren hat vllt. eine halbe Minute gedauert. So etwas finde ich nicht zumutbar - besonders nicht für solche wie mich, die alles über Try & Error programmieren. |
||
vertex.dreamfall.at | GitHub |
lettorTrepuS |
Mo, Nov 26, 2007 16:01 Antworten mit Zitat |
|
---|---|---|
-aus Sicherheitsgründen gelöscht- Diese Information ist mit Ihrer Sicherheitsfreigabe leider nicht erhältlich, Bürger. | ||
E. Urbachehemals "Basicprogger" |
So, Dez 02, 2007 12:58 Antworten mit Zitat |
|
---|---|---|
Habe die Version 0.2 endlich fertiggestellt:
Der "New" Operator wird erkannt Funktionsaufrufe werden erkannt Methoden-Aufrufe mit beliebig großer Hierarchie werden erkannt Einige Bugfixes beim mathematischen Parser Die 64-Bit-Version für Linux kann man sich hier herunterladen (32-Bit-Version gibt es leider noch nicht): Download Das Programm muss man im Terminal starten: Code: [AUSKLAPPEN] bp Test.bpc
Die Testdatei mit BMax-ähnlicher Syntax wird daraufhin in XML-Code umgewandelt: Code: [AUSKLAPPEN] Define Size = Int
Local aaa:Int = 3 Local bbb:Int = 4 Local ccc:Int = 5 Local isPythagoreanTriple:Bool = a^2 + b^2 = c^2 If isPythagoreanTriple Local x:MessageBox = New MessageBox(isPythagoreanTriple) x.Show() End If Code: [AUSKLAPPEN] <?xml version="1.0"?>
<module> <header> </header> <code> <define> <term> Size </term> <alias> Int </alias> </define> <local> <var name="aaa"> <type> Int </type> <value> 3 </value> </var> </local> <local> <var name="bbb"> <type> Int </type> <value> 4 </value> </var> </local> <local> <var name="ccc"> <type> Int </type> <value> 5 </value> </var> </local> <local> <var name="isPythagoreanTriple"> <type> Bool </type> <value> <compare> <term> <add> <term> <pow> <term> a </term> <term> 2 </term> </pow> </term> <term> <pow> <term> b </term> <term> 2 </term> </pow> </term> </add> </term> <term> <pow> <term> c </term> <term> 2 </term> </pow> </term> </compare> </value> </var> </local> <if-block> <if> <condition> isPythagoreanTriple </condition> <code> <local> <var name="x"> <type> MessageBox </type> <value> <new> <type> MessageBox </type> <parameter> isPythagoreanTriple </parameter> </new> </value> </var> </local> <call> <term> x </term> <term> <call> <function> Show </function> </call> </term> </call> </code> </if> </if-block> </code> </module> Wie man sieht, gibt es noch keine Fehlerüberprüfung, ob Variablen bzw. Funktionen auch wirklich existieren. Dies werde ich bald nachholen... Das Umwandeln der XML-Struktur in C++ Code ist relativ einfach, ich kümmere mich erstmal um die schwereren Teile. Version 0.3 wird diese Features haben: String-Erkennung und String-ignorierende Suchfunktionen um Bugs zu vermeiden Select/Case While/Wend Repeat/Until Do/While Es wäre sehr hilfreich für mich, wenn jemand, der einen 64-Bit PC mit Linux hat, kurz einige Codes testen könnte. Es sind zwar noch nicht alle Keywords vorhanden, aber mehrzeiliges If/EndIf sowie Type/End Type sollten funktionieren. Wer Fehler entdeckt, sollte mir den Log und den Code bitte per PN schicken oder in diesem Thread posten. Nicht vorhandene Features zählen natürlich nicht als Bugs @TheShadow/Vertex: Wie sieht's bei euch aus? Kann man den Source schon irgendwo downloaden? |
||
The box said, "Requires Windows XP or better", so I installed Ubuntu | Linux is NOT Windows
Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik |
TheShadowModerator |
So, Dez 02, 2007 14:24 Antworten mit Zitat |
|
---|---|---|
vertex hat seine frühere C#-sources ja schon mal hier veröffentlicht (wie ich meine)
Ich bin z.B. noch beim lexer - bin dabei meine C-sources nochmal neu zu organisieren... Im letzten stand konnte ich den source in token umwandeln... nur include ging noch nicht... wenn ich mit dem lexer zufrieden bin und sowas wie include geht, dann werde ich es mit dem parser probieren... ich hab es nicht eilig... source wollt ich pers. noch nicht öffentlich machen - erst wenn die sprache 1.0 erreichen sollte... |
||
AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2 |
TheShadowModerator |
Fr, Dez 28, 2007 16:06 Antworten mit Zitat |
|
---|---|---|
Ich hab ein ähnliches Projekt gefunden:
Vala http://en.wikipedia.org/wiki/Vala_(programming_language) Da wird ein C#-ähnlicher Code nach C konvertiert - dann kann man es mit C-Compiler zu nativer EXE kompilieren... Im Prizip ganz ähnliche Idee... Wobei ich persönlich eher BlitzMax-Syntax bevorzugen würde... Und den Code nach C++ konvertieren würde... |
||
AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2 |
E. Urbachehemals "Basicprogger" |
Fr, Dez 28, 2007 16:29 Antworten mit Zitat |
|
---|---|---|
Danke für den Link, insbesondere die Benchmarks sollte man noch erwähnen. Ich gehe bei meinem Code von einem ähnlichen Ergebnis aus.
Mir gefällt die Syntax allerdings auch nicht, ich bin immer noch für Syntaxunabhängigkeit bei solchen Projekten. An einen zusätzlichen C-Output hatte ich auch schon gedacht, aber ich traue mir ehrlich gesagt nicht zu, dass ich try/catch effizient umsetzen kann. Außerdem: Wieso sollte ich das Rad neu erfinden, wenn g++ sowieso auf allen Systemen, die ich unterstützen möchte, vorhanden ist? Wenn es irgendwen interessiert: Ich bin inzwischen bei Version 0.3 angekommen. Die erste Alpha für Windows und Linux werde ich zum Download anbieten, wenn ich 0.5 fertig habe. |
||
PlasmaBetreff: ich weiß ... |
So, Jan 04, 2009 17:20 Antworten mit Zitat |
|
---|---|---|
alter thread (oder doch nicht ?) .
aber gugt mal hier http://bcx-basic.sourceforge.net/ hilt eventuell weiter . genausogut basm286 ! googelt mal |
||
Gehe zu Seite Zurück 1, 2, 3, 4
Übersicht Sonstiges Smalltalk
Powered by phpBB © 2001 - 2006, phpBB Group