Für gewöhnlich fangen BlitzMax Programme einfach bei der ersten Code-Zeile an laufen dann durch.
Selbstverständlich ist es jedem freigestellt, sich einen eigenen Application-Type zu schreiben (wxMax macht das beispielsweise) und diesen dann zu initiieren. Aber da kocht natürlich wieder jeder sein Süppchen.

Java hat sie, Monkey hat sie (naja, fast) und jetzt auch BlitzMax: Eine feste Klasse für Applications.

TApplication

Ein abstrakter Type, dessen als letzter registrierter Child Type automatisch erkannt wird. Von diesem wird dann ohne weiteres Zutun des Programmierers die run() Methode aufgerufen. Das passiert hinter den Kulissen mit ein bisschen C-Magie : )

Hier mal ein Beispiel:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Import std.application

Type TExampleApplication Extends TApplication

	Method run()
		Print "BlitzMax still has got some suprises for you!"
	End Method

End Type

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Output: "BlitzMax still has got some suprises for you!"

Ich denke, den Type könnte man später sehr komfortabel erweitern, z.B TGUIApplication.

Bei dem Thema Event-Handling bin ich mir noch nicht ganz sicher, wie ich das handhaben werde.
Methoden wie onStartup, onExit sind zur Zeit eingebaut. Das könnte man natürlich auch über New und Delete lösen, aber bei weiteren geplanten Aktionen, wie z.B onActive, wäre das dann etwas inkonsistent.


Keep coding,

Fabian

Hi,

nach langer Auszeit hab ich nun endlich wieder Internetanschluss, was der Produktivität doch merklich zugute kommt.

Die BSL wächst und wächst stetig weiter und obwohl noch längst nicht alles in Tüten ist, sind schon viele neue Features geplant und teils implementiert. So bastele ich so nebenbei noch an einem eigenen Threading Modul, was mehr auf OOP zugeschnitten ist.

Um auch mal was Konkretes für die Netzgemeinde zu melden, noch ein paar Funktionen des neuen Char Types. Damit wird die Überprüfung und Umwandlung von Character Codes wesentlich eleganter gelöst, als durch ständig selbstgeschriebene Funktionen.
Die Funktionalität wird sich an der anderer Sprachen wie C/Java anlehnen, aber ich bin noch am experimentieren. (Unicode etc)
Hier ein kleiner Ausblick:


isAlpha

Char.isAlpha:Int(character:Int)

Prüft, ob der angegebene character ein Buchstabe des Alphabets ist.
Als alphabetische Buchstaben gelten folgende: A a B b C c D d E e F f G g H h I i J j K k L l M m N n O o P p Q q R r S s T t U u V v W w X x Y y Z z

isDigit

Char.isDigit:Int(character:Int)

Prüft, ob der angegebene character eine dezimale Ziffer ist.
Als dezimale Ziffern gelten folgende: 0 1 2 3 4 5 6 7 8 9


isHexDigit

Char.isHexDigit:Int(character:Int)

Prüft, ob der angegebene character eine hexadezimale Ziffer ist.
Als hexadezimale Ziffern gelten folgende: 0 1 2 3 4 5 6 7 8 9 A a B b C c D d E e F f


Das ganze wird im Modul brl.blitz enthalten sein, kann also auf die interne Code Tabelle von BlitzMax zugreifen und beispielsweise sehr effizient in Groß- & Kleinschreibung umwandeln.
Dazu musste ich die interne Struktur des Moduls wieder etwas ändern, aber natürlich ändert sich an der API faktisch nichts.

Keep coding,

Fabian

Kleiner Zwischebericht:

BlitzMax kommt wohl mit dem erweiterten Object Type nicht so wirklich klar, deshalb musste ich die toHandle/fromHandle Geschichte wieder entfernen.
Dafür gibt's jetzt freshe Iteratoren und der Bug ist gefixt. Testprogramme mit MiniB3D laufen problemlos.

Kleiner Vorgeschmack:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

For Local character:String = EachIn "abc".reverse()
    Print character
Next

' Output: c b a

Eine genauere Beschreibung der Iteratoren kommt später, jetzt erstmal nur so viel: Alle Iteratoren implementieren das IIterator Interface, das die Methoden hasNext, setNext und getCurrent bereitstellt.

Keep coding,

Fabian

Hi Blitzer,

ich ärgere mich immer noch mit dem Code-Highlighting rum (in JavaScript - kennt da jemand was gutes für BlitzMax?) deshalb hab ich mich zur Abwechslung mal um das Logo gekümmert.
Eigentlich war es nur als Platzhalter gedacht, aber mittlerweile gefällt es mir doch recht gut.



Gefällt's euch? Und noch viel wichtiger .. liest das hier überhaupt jemand??


Fabian

Okay, Nikolaus ist nichts geworden, da ein Bug aufgetreten ist, den ich noch nicht fixen konnte.
Dafür erzähle ich euch heute was über den Garbage Collector (GC) von BlitzMax.

Die Funktionen GCCollect(), GCSetMode() etc sind euch ja sicher bekannt (ansonsten: Dokumentation lesen). Da zusammenhangslose Funktionen aber irgendwie dem top-modernen Ansatz ( ) von BlitzMax widersprechen, habe ich alle die mit dem GC zusammenhängen in einen eigenen Type verfrachtet. So sind die beiden gerade genannten jetzt zum Beispiel als GC.collect() und GC.setMode() zu finden.

Von der Geschwindigkeit her sind sie nur unmerklich langsamer, da ich sie nicht in BlitzMax implementiert habe.
Genau genommen sind sie nicht einmal in C implementiert, sondern irgendwo dazwischen einfach deklariert.
Die Funktionen des GC Types rufen deshalb ohne Umwege die original C Funktionen auf. Desweiteren ist der Type nicht von Object abgeleitet und als Abstract Final implementiert. Ich glaube mehr kann man da nicht optimieren.

Und *Trommelwirbel* es gibt natürlich neues Spielzeug. Zwei Konstanten GC.ModeAutomatic:Int = 1 und GC.ModeManual:Int = 2 repräsentieren die beiden möglichen Modi. Der Modus in dem der GC arbeitet, kann wie schon erwähnt mit GC.setMode gesetzt werden. Zusätzlich kann er jetzt aber auch ganz simpel ausgelesen werden:

getMode

GC.getMode:Int()

Liefert den Modus in dem der GC aktuell arbeitet. Standard ist GC.ModeAutomatic

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

GC.setMode(GC.Manual)
Print "GC mode: " + GC.getMode()
' Output: 2

Das war's erstmal von mir. Als nächstes werde ich erstmal den Bug fixen müssen. Ansonsten bastle ich gerade an der Dokumentation, die sich von der doch recht drögen Klotz-Doku des Originals doch stark unterscheidet.


Fabian

Kaum zu Glauben, aber BlitzMax hat ein eigenes System um ein Integer Handle eines Objects zu bekommen und daraus selbstverständlich später wieder das Objekt zu bekommen.
Die zwei Befehle HandleFromObject und HandleToObject sind dafür zuständig ein Handle zu erstellen oder ein zu dem Handle gehörendes Objekt zu erhalten.

Ich habe das ganze kurzerhand in den Object Type reingepackt, da ich denke, dass es dort eher hingehört.
Object hat jetzt also eine neue Methode und eine neue Funktion.

toHandle

Object.toHandle:Int() Final

Erzeugt ein Handle, dass das Object repräsentiert.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Print foo.toHandle()
' Entspricht
Print HandleFromObject(foo)

fromHandle

Object.fromHandle:Object(handle:Int) Final

Liefert das zu dem Handle gehörende Object.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Print Object.fromHandle(bar).toString()
' Entspricht
Print HandleToObject(bar).toString()

Ich bin der Ansicht, dass das so einfach mehr dem OOP Gedanken entspricht, als die zwei einzelnen Funktionen.

Das war's auch schon für heute, beim nächsten Mal gibt's aber bestimmt mehr zu erzählen.
Speziell die Themen Exceptions und Iteratoren sind gerade in Arbeit.

Fabian

Hi.

Ich geb's zu, ich hab schon ewig nichts mehr gemacht. Aber da ich gerade krankheitsbedingt zu Hause bleiben muss, hab ich mal den Dancefloor gegen das gute alte BlitzMax ausgetauscht und mich wieder rangesetzt.
Da ich mich mittlerweile recht gut im brl.blitz Code auskenne (dem Kern von BlitzMax in C) hab ich gleich alles wieder über den Haufen geworfen und fange nochmal ganz von vorne an. Klingt erstmal nicht so gut, ich weiß.

Aber das ganze hat auch sein gutes: Die neue BSL (BlitzMax Standard Library) wird jetzt nochmal ein ganzen Zacken praktischer. Da der gute Herr Sibly ja in letzter Zeit ganz von seinem neuen Baby BMX2 eingenommen ist und Updates ja in der Regel recht gut dokumentiert werden, habe ich kurzer Hand einfach das brl.blitz Modul umgeschrieben. Also eigentlich stecke ich noch mittendrin, aber egal.

Das neue Modul, welches Teil der BSL ist, enthält die schon optimierten Routinen - arbeitet also schneller - und bringt einige doch recht nette Features mit sich. So habe ich zum Beispiel den String Type erweitert, der jetzt ein paar nützliche neue Methoden hat:

reverse

String.reverse:String()

Liefert eine umgedrehte Version des Strings.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Print "abc".reverse()
' Output: "bca"

count

String.count:Int(substring:String, caseSensitive:Int = True)

Liefert die Anzahl der im String enthaltenen Substrings.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Print "abc ABC abc".count("abc")
' Output: 2

Print "abc ABC abc".count("abc", False)
' Output: 3

sub

String.sub:String(start:Int, length:Int)

Liefert einen Teil des Strings zurück.
Wenn start negativ ist, wird von hinten gezählt.
Wenn start + length größer als die Länge des Strings ist, wird natürlich nur bis zum Ende des Strings zurückgegeben.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Print "abcdefg".sub(2, 3)
' Output: "cde"

Print "abcdefg".sub(-3, 1)
' Output: "e"

Außerdem gibt's kleine Erweiterungen für die Standardmethoden.

find

String.find:Int(substring:String, start:Int = 0, caseSensitive:Int = True)

Findet jetzt auf Wunsch auch substrings ohne Beachtung von Groß/Kleinschreibung.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Print "BlitzMax hat POTENTIAL".find("potential", 0, False)
' Output: 13

Die Defaultwerte sind so gesetzt, dass sich für den Normalverbraucher nichts ändert. 100% kompatibel also. Kleines Detail am Rande: Der String Type enthält jetzt die Konstante NotFound (= -1) für bessere Lesbarkeit.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

If foo.find("bar") = String.NotFound Then [...]

Das läuft alles schon schön stabil, aber hochgeladen ist noch nichts, da müsst ihr euch noch etwas gedulden.
Vielleicht gibt's ja was zum Nikolaus?


Fabian

P.S. Wer noch Vorschläge hat, was unbedingt noch mit reinmuss: klick

Ich bin ganz gut vorangekommen, jetzt baut auch das ganze Vektorenmodul auf der C API auf. Zudem gibt's jetzt auch die komplette Funktionalität der BlitzMax Version auch in C. Dass heißt für Engines oder solche Späße, kann man jetzt ganz lässig die rechenintensiven Sachen in C schreiben und dann einfach mit BlitzMax die letzten Details herausarbeiten.

Mark, was tust du?
Ich will weder von mir behaupten ein guter C Programmierer zu sein noch überhaupt zur Crème de la Crème der Coder zu gehören, aber was der gute Herr Sibly da mit dem Quellcode anstellt ist wirklich teilweise recht suboptimal. Ich habe mir beim wrappen schon überlegt, ob man vieles davon nicht gleich neu schreiben sollte, aber wer benutzt das dann schlussendlich? Naja, zumindest habe ich ein paar String-Funktionen neu geschrieben. Jetzt läuft find bei mir mehr als doppelt so schnell wie das Original. Die dazugehörige Funktion heißt bmStringFind und funktioniert genau wie die BRL-Version. Für den Endverbraucher ändert sich dabei wahrscheinlich kaum was, aber ich werde die Funktionen bald an anderer Stelle in der BMSL brauchen. Ich habe das schon mal testweise mit einem TPath Type ausprobiert und die Geschwindigkeit kann sich sehen lassen. Die BRL-Funktionen wie ExtractDir hängt es trotz OOP locker ab.

Bis ich das release dauert es aber noch ein Weilchen, irgendwann muss ich die Matrix und Quaternion Types schließlich auch noch machen.

Ordnung im Array

Ist zwar nur eine kleine Änderung, aber gerade deshalb sollte ich vielleicht darauf hinweisen. Wenn ihr die Arrays, die mit toArray erzeugt werden auslesen wollt, nehmt die Konstanten XIndex, YIndex, ZIndex und WIndex.

Ach ja, man kann jetzt neben clamp auch clampToRange benutzen.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

vector.clamp(range.getMinimum(), range.getMaximum())
' ist langsamer als ..
vector.clampToRange(range)

P.S.: Ich warte immer noch auf gute Ideen, wie ich die C API am besten so verpacken kann, dass nur die Funktionen die die BlitzMax-Version wirklich benutzt auch importiert werden und der Rest dann extra eingebunden werden kann, wenn nötig.

P.P.S.: Es gab einen kleinen Bug in den getLength Funktionen - wurde behoben.

Fabian

So die Range Types setzen jetzt alle auf die neue C API auf. Jedenfalls dort wo es Geschwindigkeitsvorteile gibt. Wenn die native BlitzMax-Implementierung schneller ist, wird die natürlich verwendet. Dass das 'ne total spannende Arbeit ist das alles durchzuchecken muss ich wohl nicht dazusagen

C API

"C in der BlitzMax Standard Library? Hä?"
Tja, da die Blitzer (und ich auch) Wert auf Ausführungsgeschwindigkeit legen musste ich mir was einfallen lassen. Denn das ganze soll gleichzeitig schnell, aber auch verdammt sauber und vollständig sein. Assembler fällt eh weg, das kann ich nicht und ist glaub ich auch nicht mehr so überwichtig. Der GCC optimiert ordentlich - besser als ich - nehme ich an.

Okay, zurück zum Thema: Die C API ist eigentlich verdammt einfach aufgebaut, da sie sich quasi 100% an BlitzMax orientiert, ist ja auch die BlitzMax Standard Library. Schaun wir's uns an.

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Local color:TColor = TColor.Create(1.0, 1.0, 1.0, 1.0)
color.setGreen(0.25)

Code: [AUSKLAPPEN] [EINKLAPPEN]

Für die Kommunikation mit C haben alle Instanz Typen (von denen also Instanzen erzeugt werden) die Methoden toC() und fromC(). Damit kann ein Object ganz einfach an die C API übergeben werden. Lohn der Mühe: Einige Methoden sind jetzt mit C Untersatz mehr als 10x so schnell. Natürlich nicht alle - manchmal würde sich's eigentlich kaum lohnen. Aber die Funktionen sind eh da, was soll's?

Ich weiß nur noch nicht genau, wie ich das mache mit den Funktionen die von BlitzMax eigentlich gar nicht benutzt werden. Die also quasi nur für C da sind (z.B. bsCreate/bsFree). Die gammeln zur Zeit einfach noch im Modul rum. Wenn da jemand was weiß, her damit. Ich habe schon ein paar Ideen, die aber alle nicht so 100% befriedigend sind.


Genug für heute.

Fabian

Endlich habe ich mich dazu durchgerungen das ganze Zeug auf SVN umzustellen. Der Grund für diese Aktion ist ganz einfach, dass ich nicht mehr durchsehe. Wenn ich hier und da ein bisschen an den Modulen rumschraube hab ich danach oft nicht mehr so den Überblick, was alles als .zip neu hochgeladen werden muss. (siehe gestern)
Ich hoffe jetzt wird das ganze ein wenig leichter für euch (und mich natürlich auch )

Fabian

SVN