Essay - Free Blitz2D

Übersicht

Sonstiges

Smalltalk

Gehe zu Seite Zurück 1, 2, 3, 4

	TheShadow Moderator	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

TheShadow

Moderator

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

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

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.

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] [EINKLAPPEN] TypeDefinition = TYPE Identifier {FIELD Identifier ['%' \| '#' \| '$' \| '.' Identifier] [('[' Expression ']')]} ENDTYPE; Das war die alte Regel, hatte aber nicht so etwas erlaubt: Code: [AUSKLAPPEN] [EINKLAPPEN] Type TTest Field A, B, C ; Mehrere Fields in einer Zeile Field D Field E End Type Mit der neuen geht das: Code: [AUSKLAPPEN] [EINKLAPPEN] TypeField = Identifier ['%' \| '#' \| '$' \| '.' Identifier] [('[' Expression ']')]; TypeDefinition = TYPE Identifier {FIELD TypeField {',' TypeField}} ENDTYPE; Dann die Regel Code: [AUSKLAPPEN] [EINKLAPPEN] 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] [EINKLAPPEN] FOR ObjectName '=' EACH Identifier StatementSequence NEXT; zum tragen kommt. Code: [AUSKLAPPEN] [EINKLAPPEN] 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] [EINKLAPPEN] 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] [EINKLAPPEN] 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] [EINKLAPPEN] 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

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
StatementSequence
NEXT;

zum tragen kommt.

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.

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.

	TheShadow Moderator	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

TheShadow

Moderator

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

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 Smile

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:

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.

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] [EINKLAPPEN] ; A.bb Function MyFunction%(Value%) Value = Value2 End Function ; B.bb Value = Value + 1 Return Value --> // A.c BBInt bbMyFunction(BBInt bbValue); BBInt bbMyFunction(BBInt bbValue) { bbValue = bbValue2; #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

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.

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

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.

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. Urbach ehemals "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] [EINKLAPPEN] bp Test.bpc Die Testdatei mit BMax-ähnlicher Syntax wird daraufhin in XML-Code umgewandelt: Code: [AUSKLAPPEN] [EINKLAPPEN] 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] [EINKLAPPEN] <?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

E. Urbach

ehemals "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 Wink

@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

	TheShadow Moderator	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

TheShadow

Moderator

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

	TheShadow Moderator	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

TheShadow

Moderator

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. Urbach ehemals "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.

E. Urbach

ehemals "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.