BlitzBasic Portal Worklogs - BlitzMax Extended

Der String war's

ProfJake — Mon, 08 Oct 2012 20:02:21 +0200

Jop, jop, jop.

Der Fehler hat wurde gestellt und standesgerecht ersch.. beseitigt : )
Es lag wohl am Code in bbStringFind, den ich etwas unglücklich verschlimmbessert hatte.
An dieser Stelle auch einen Dank an blackgecko, obwohl ich mir nicht sicher bin, wie das
bei ihm vorher schon so problemlos durchlief – schwarze Magie wahrscheinlich.

Ich hab jetzt auch gar nicht so unglaublich Zeit, deshalb jetzt nur schnell der Link und weiter geht's.
Beim nächsten Mal werde ich wohl genauer auf ein paar praktische Neuerungen im Bereich der Arrays
eingehen. Wer Muße hat, kann sich ja mal die Funktionen toCArray, FromCArray und filterInt
anschauen. Speziell bei den Filterfunktionen könnte es aber noch Änderungen geben,
da ich noch am grübeln bin, ob ich das Array mit als Parameter übergebe oder nicht.

Anyways.

Download (Source)

Stay caffeinated,
ProfJake

EDIT: HOT-FIX gegen Probleme mit inline und restrict

Kurz und kaputt

ProfJake — Sun, 07 Oct 2012 18:30:11 +0200

Schönen Sonntag euch allen,

hier gibt's die neueste Portion BlitzMaxExtended. Obwohl ich einige schwerwiegende Fehler finden
und beheben konnte, treibt sich aber immernoch ein besonders nerviger im Quelltext rum.

Mir ist er erst aufgefallen als ich makedocs kompilieren wollte um eine Änderung im
bekanntermaßen nicht ganz so schönen Dokumentations-HTML einzubauen. Daraufhin kamen ein
paar Fehler auf, die zum Glück (?) das Programm mit einer netten Fehlermeldung abstürzen
ließen. Diesen Gefallen hat mir der noch nicht beseitigte nicht getan.

Macht mal was kaputt
Wie ihr helfen könntet, so ihr denn gewillt seid.

Es wäre praktisch, wenn ihr auch mal versuchen könntet makedocs zu kompilieren und auszuführen.
Bei mir schafft er mal mehr mal weniger Module und stürzt dann mittendrin einfach ab.
Sang und klanglos.

Meine Hoffnung ist jetzt, dass eure Systeme vielleicht musikalischer sind und in ihrem Abgesang
noch eine hilfreiche Information ausspucken. Daran wäre ich dezent interessiert, wie man sich sicher
denken kann.

Download (Source)

Das war's auch schon wieder für heute.

Stay caffeinated,
ProfJake

Lahmarschig, aber am Leben

ProfJake — Sun, 30 Sep 2012 02:38:58 +0200

Hi Jungs,

inzwischen bin ich umgezogen und hab mich ein wenig in der Realität vergnügt, aber meine Hass-Liebe
sitzt anscheinend tiefer als gedacht. Von daher gibt's nun mal wieder ein kleines Update,
welches eigentlich nur die Dokumentation ein wenig aufräumt sowie einige Rechtschreibfehler behebt.

Mehr ein Lebenszeichen als ein Meilenstein also : )

Download (Source)

Stay caffeinated,
Fabian

Pinguin: Check!

ProfJake — Tue, 17 Jul 2012 22:07:23 +0200

Hi folks,

bei der Linux-Version gab es ja noch kleinere Schwierigkeiten – soll heißen nix ging – die jetzt der Vergangenheit angehören.
Getestet wurde es unter Mint und Debian. An dieser Stelle speziellen Dank an Thunder, der einer von zwei Lesern ist, die mal
eine Rückmeldung gegeben und auf ein Problem hingewiesen haben. Problem gelöst, das hat er nun davon.

Download (Source)

Jetzt fehlt nur noch eine Wortmeldung der Fenster-und-Sanduhr-Fraktion. Ein einfaches true (läuft) oder false (Blut, Morde und Festplatten-Moshpit)
in der Kommentarabteilung würde schon reichen, um mich ruhig schlafen zu lassen.

Stay caffeinated,
Fabian

EDIT: HOT-FIX für Windows – der Zweite.

Husch, husch

ProfJake — Wed, 11 Jul 2012 20:51:12 +0200

Hi, heute mal ganz kurz.

Mir ist aufgefallen, dass die neuen Funktionen nur in C dokumentiert sind, blöd.
Hier also eine erste Dokumentation in BlitzMax. Zusammenfassung:

Buf-fixes in blitz_array.c
neue Funktionen bbArrayFind und bbArrayContains
minimale BlitzMax Dokumentation
C-Dokumentation verbessert (aus bbdoc aufrufbar)

Download (Source)

EDIT

Die früher schonmal erwähnten Klassen (Interfaces) IEnumerator und IEnumerable sind jetzt
auch mit dokumentiert worden. Sie sind einfach eine Deklaration der schon eingebauten
Funktionalität um Klassen mit ForEach zu nutzen (z.B TList).

[syntax="bmax"]Type IEnumerator Abstract
Method hasNext:Int() Abstract
Method nextObject:Object() Abstract
End Type

Type IEnumerable Abstract
Method objectEnumerator:IEnumerator() Abstract
End Type[/syntax]

Sie haben zwar keine eigene Funktionalität (= Interface), aber ich finde das ist sauberer als zu sagen:
"Um mit ForEach kompatibel zu sein musst du deine Methoden so und so nennen. Durch Magie klappt das
dann und die Namen kannst du dir gefälligst aus dem Quelltext oder irgendwo aus der Hilfe raussuchen."

Stay caffeinated,
Fabian

Alpha aka Die Vorschauversion

ProfJake — Sat, 07 Jul 2012 21:16:18 +0200

Hola, Compadres!

Bei uns in der Region kommt gerade die halbe Ostsee vom Himmel geregnet. Da dachte ich mir wenn dass bei
euch so ähnlich ist, habt ihr bestimmt total viel Lust darauf mal einen ersten Blick auf die Alpha-Version zu werfen.

Der Deal ist folgender: Ihr könnt damit machen was ihr wollt, aber ich würde wirklich gerne eure Meinung dazu hören.
Und mit Meinung meine ich speziell Fehlermeldungen. Mein System ist ein MacOS X 10.6.8 und hier scheint alles zu laufen.
Getestet habe ich größtenteils mit den beigelegten samples von BlitzMax sowie MiniB3D.

Download (Source)

Zur Installation ganz einfach den originalen brl.blitz Ordner durch diesen ersetzen (vorher Sicherheitskopie).

Schönes Wochenende,
Fabian

EDIT: Aktualisierte Version 0.8.10 (Fix) verlinkt.

Schon wieder kein Download, meh.

ProfJake — Sat, 30 Jun 2012 10:34:47 +0200

Hi there,

und "high" sehe ich bestimmt auch gerade aus, nach der Nacht und der 3. Badewanne voll C8H10N4O2. [/bad-joke]

Reflection
Ins Innere von BlitzMax schauen.

Reflection in BlitzMax setzt einen korrekt befüllten BBDebugScope vorraus. Normalerweise erledigt das
der Kompiler, indem er alles dafür notwendige aus dem Quelltext ausliest. Das ist mir natürlich alles viel
zu komfortabel, weshalb ich – nachdem die C Implementierung fertig war – mir schon gut 'nen halben
Zahn daran ausgebissen habe, den ganzen Spaß zum Laufen zu bekommen.

Problem? aka "U MAD, BRO?"

Erstmal blitz_debug.h und den Assembler-Output vom bcc überflogen und festgestellt: Easy!
Doch wie so oft .. ihr wisst schon: Teufel, Detail, Blut & Morde! Irgendwie hab ich das Problem immer weiter
nach hinten geschoben. Denn "theoretisch" hätte es funktionieren müssen, was es aber natürlich nicht tat.

Um die folgenden zwei Bösewichter geht's:

Code: [AUSKLAPPEN]

struct BBDebugDecl
{
BBDebugDeclKind    kind;
const char       *name;
const char       *type_tag;

union {
   BBString*    const_value;
   BBSize       local_offset;
   BBSize       field_offset;
   void       *global_address;
};
};

struct BBDebugScope
{
BBDebugScopeKind kind;
const char       *name;
BBDebugDecl       decls[1]; // Problem
};

Das Problem war erst, das decls Feld des DebugScopes richtig zu füllen, worum sich der gute Herr
Sibly ja in seinem C-Code gedrückt hat. Sein Kompiler wird das Geheimnis mit ins Grab nehmen *MUHAHA* ..
.. nicht, natürlich. Ist ja alles sehr simpel aufgebaut. Lösung folgt.

Solution? aka "Thanks, CAPT. OBVIOUS!"

Die meiste Zeit habe ich damit verbracht, ganz klassisch an der falschen Stelle zu suchen. Die neue Helferfunktion
bb_class_register_multiple sollte einfach das Registrieren mehrerer Klassen beschleunigen, aber durch
einen Geniestreich ohnegleichen habe ich nur den ersten Wert der va_list registriert.

Soll heißen, die neue Funktion für mehrere Klassen gleichzeitig registriert doch nur eine.

Wenn man sich dann auf sein neues Spielzeug verlässt und alle anderen Code-Teile wüst beschimpft, dann
kann das schon etwas dauern, bis man die Lösung findet. Nun gut, jetzt läuft es ja.

Das das decls Feld betreffende Problem habe ich durch ein bisschen schummeln gelöst.
Es gibt jetzt einen internes struct bb_debugscope_t, wo genau dieses Feld als decls[]
anstatt decls[1] deklariert ist. Wird wahrscheinlich den wenigsten etwas sagen, daher ein Beispiel:

TBaseException

Basis-Exception-Klasse für alle BlitzMax internen Exceptions und auch für eure eigenen.
Der Name TBaseException rührt daher, dass TException in den Aufgabenbereich der BSL gehört.
Es ist wirklich nur die minimale Funktionalität, später mehr dazu. Hier sieht man, wie die Klasse in BlitzMax aussehen
würde, wäre sie denn auch darin implementiert. Für die Anwender kommt das aber auf's Gleiche raus.

[syntax="bmax"]Type TBaseException Abstract
' Private: Nur für C/C++
Field cause:TBaseException

Method initCause(cause:TBaseException)
If Not Self.cause And cause <> Self Then
Self.cause = cause
End If
End Method

Method getCause:TBaseException() Final
Return Self.cause
End Method
End Type
[/syntax]

Da C viel zu cool ist, um sich um BlitzMax zu kümmern, findet man die Klasse in blitz_exception.h / .c
als BBException mit dazugehöriger bbExceptionClass.

Der vielbesungene BBDebugScope sieht intern so aus:

Code: [AUSKLAPPEN]

// blitz_exception.c
static const bb_debugscope_t ClassScope =
{
.kind = BBDEBUGSCOPE_USERTYPE,
.name = "TBaseException",
.decls = {
   [0] = {
      BBDEBUGDECL_TYPEMETHOD,
      "initCause", "(:TBaseException)i",
      BBCLASS_VFN_OFFSETOF(__BBEXCEPTION_VFN_INITCAUSE__)
   },
   [1] = {
      BBDEBUGDECL_TYPEMETHOD,
      "getCause", "():TBaseException",
      BBCLASS_VFN_OFFSETOF(__BBEXCEPTION_VFN_GETCAUSE__)
   },
   BBDEBUGDECL_END
}
};

Alles hier definierte wird dann von allen abgeleiteten Klassen übernommen, muss also nicht nochmal geschrieben
werden und Platz wegnehmen.

Hier sieht man nebenbei auch schön einige der internen Features, dass Makro BBCLASS_VFN_OFFSETOF z.B. gibt hier
den Offset der virtuellen Funktion (Method oder Function einer Klasse) für den übergebenen Index zurück.

Arrays und Alpha
Was sonst noch so passiert

Wie man merkt, schreib ich gerade nicht mehr ganz geradeaus. Deshalb nur so viel: Es gibt noch 'ne Menge zu tun.
Einiges wird sich ändern, aufgeräumt muss noch werden und die Dokumentation muss ich nochmal "glattbügeln".

Die Arrays sind wieder ein bisschen gewachsen: um einen Parameter und eine Methode.

Find*

Neuer Parameter für alte, neue Methode. Nutzt jetzt intern z.B das BBIntArray Helfer-Object
und unterstützt nur noch Arrays des gleichen Typs (=schneller).

[syntax="bmax"]Array.findInt:Int(num:Int, start_index:Int = 0)[/syntax]

StartsWith & EndsWith

Funktionieren genau wie bei Strings, das zu testende Array muss gleichen Typs wie das aufrufende sein.

[syntax="bmax"]Array.startsWith:Int(other:Array)
Array.endsWith:Int(other:Array)[/syntax]

Dies ermöglicht recht eleganten Quelltext zu schreiben, z.B

[syntax="bmax"]If arr.startsWith([1, 2, 3]) Then [...][/syntax]

So, fertig.

Fragen, Anregungen und Goldbarren sind jederzeit willkommen.
(Goldbarren nur Werktags zwischen 8 und 18 Uhr.)

Stay caffeinated,
Fabian

Ich kam, debugte und siegte!

ProfJake — Fri, 29 Jun 2012 00:56:17 +0200

Guten Abend die Damen und Herren,

nachdem ich das zweifelhafte Vergnügen hatte den ganzen Tag einem Bug hinterherzujagen,
dachte ich etwas Erholung könnte nicht schaden. Daher habe ich noch ein bisschen Features reingepackt.

Schon lustig, aber neue Funktionen schreiben macht ungleich viel mehr Spaß als der ganze andere
Aufräum- und Dokumentationskrams. Aber das habe ich mir ja wohl selbst zuzuschreiben.

String

Hier hat sich ein kleines Problem ergeben, da ich die Anzahl der virtuellen Funktionen einer BBClass
mittlerweile komplett gefüllt habe. Vor Urzeiten hatte ich mal getestet, ob BlitzMax selbst so ein Limit (32)
hat und ich glaube nicht. Irgendwie muss das also gehen. Aber bis jetzt ging's ja auch mit dem was da war
ganz gut, von daher hat das keine Priorität.

FindAny

Durchsucht einen String nach dem ersten Vorkommen eines beliebigen Strings aus dem Such-Array.

Passt keiner der gegebenen Such-Strings so recht, dann wird String.NOT_FOUND zurückgegeben.
[syntax="bmax"]String.FindAny:Int(all_subs:String[], start_index:Int = 0)[/syntax]

IsLower/IsUpper

Prüft ob der String komplett klein/groß geschrieben ist.
[syntax="bmax"]String.isLower:Int()
String.isUpper:Int()[/syntax]

Das ist viel schneller als z.B
[syntax="bmax"]If str = str.toLower() Then [...][/syntax]
Denn hier muss keine neue Stringinstanz erzeugt werden

IsASCII

Eher ein Gimmick was rausfliegen wird, wenn ich keinen anderen Weg finde z.B. pad reinzubekommen.

Prüft ob alle Buchstaben durch den ASCII-Code repräsentiert werden können (keine Code Points über 127).
[syntax="bmax"]String.isASCII:Int()[/syntax]

Array

Ja, auch der Bug-Verursacher und Schlaf-Räuber des heutigen Tages kriegt ein kleines Geschenkchen.

Rotate

Rotiert die Elemente eines Arrays um eine gewisse Anzahl an Positionen.
Gibt das rotierte Array zurück. Wenn die Anzahl der Rotationen kleiner als 2 ist,
wird das Original unverändert zurückgegeben.

[syntax="bmax"]Array.rotate:Array(count:Int = 1)[/syntax]

Beispiel

[syntax="bmax"]Local arr:Int[] = [1,2,3,4,5].rotate(1)

Print arr[0] + ", " + arr[1] + ", " + arr[2] + ", " + arr[3] + ", " + arr[4]
' Output: 5, 1, 2, 3, 4[/syntax]

Und sonst so?
Was dem Backend so zugestoßen ist ..

Wie schon gesagt wurde viel rausgehauen (z.B StringBuffer, Iteratoren, Exception-Hierarchien)
weil brl.blitz nicht optional ist und ALLE DAS BENUTZEN MÜSSEN. Weil .. deshalb.

Nein, Spaß beiseite: Es geht natürlich um Modulgröße, Kompatibilität und Einfachheit.
Sollte die BSL in diesem Leben nochmal fertig werden, wird's ein Monster. Aber das hier
eben nicht. Trotzdem hat sich einiges geändert:

neue TBaseException Klasse von der alle abgeleitet werden (auch TBlitzException)
TArrayBoundsException, TNullObjectException, TNullMethodException, TNullFunctionException und TOutOfDataException sind jetzt Final
alles ist in C implementiert (auch die gerade genannten Exceptions)
IEnumerator und IEnumerable Interfaces (tun nix, sind aber schick )

Jo.

Stay caffeinated,
Fabian

Ausmistungsunternehmung

ProfJake — Wed, 27 Jun 2012 06:00:02 +0200

"Weniger ist mehr." – Vielzitierter Klugscheißer

Entgegen der gerade genannten Weisheit habe ich, als ich meinen Blick heute Nacht mal wieder
über das Projekt habe schweifen lassen, festgestellt, dass ich zu viel Funktionalität reingestopft habe.
Funktionalität, die eigentlich besser in der BSL (da war doch was) aufgehoben wäre.
Also ging es erst einmal an's Aufräumen und Rausschmeißen.

Das war soweit auch schon alles, ich wollte nur zu Protokoll geben, dass das Projekt noch lebt.
Es läuft auch fleißig und ich denke, beim nächsten Mal werde ich zumindest eine Alpha raushauen.
Dann können die zwei Personen, die das hier mitlesen ("Höre ich drei? Wer bietet drei?") mal schauen können,
was dabei alles kaputt geht : p

Stay caffeinated,

Fabian

Ein paar Neue

ProfJake — Thu, 17 May 2012 00:38:06 +0200

Wie beim letzten Mal versprochen, gibt's jetzt erstmal eine kurze Auflistung einiger neuer Sachen.

String

Die Stringklasse wurde größtenteils unter der Haube aufgehübscht, aber es gibt natürlich auch auf
Seiten von BlitzMax einige Neuerungen.

Trim

Der altbekannte Leerzeichenabschneider hat jetzt einen Parameter, der festlegt auf welcher Seite
die unerwünschten Zeichen abgetrennt werden sollen.

Es gibt die logischen drei Optionen: String.SIDE_LEFT, String.SIDE_RIGHT und String.SIDE_BOTH
Zur Zeit verhält sich die Methode so, als ob immer SIDE_BOTH übergeben würde.

[syntax="bmax"]String.trim(side:Int = String.SIDE_BOTH)[/syntax]

FindAll

Will man alle gefundenen Substrings aus einem String herauskitzeln, so muss man jetzt keine
eigene Funktion mehr schreiben.

Es wird ein eindimensionales Int[] Array mit allen Indexes zurückgegeben, oder eben Null wenn
gar nichts gefunden wurde.

[syntax="bmax"]String.findAll:Int[](sub:String, start_index:Int = 0)[/syntax]

Count

Zählt alle enthaltenen Teilstrings. Ganz einfach.

[syntax="bmax"]String.count(sub:String)[/syntax]

Reverse

Noch so ein alter Bekannter aus der BSL. Diese Methode dreht quasi den String
komplett Zeichen für Zeichen um.

[syntax="bmax"]String.reverse:String()[/syntax]

Times

Gibt einen String mehrfach wiederholt zurück. Beim Parameterwert 1 gibt's den übergebenen
String einfach wieder. Wenn man dagegen 0 übergibt, bekommt man auch Null zurück : )

[syntax="bmax"]String.times:String(count:Int)[/syntax]

Sub

Eine alternative Möglichkeit einen Teilstring zu erhalten. Im Gegensatz zu den Slices nimmt er
aber nicht zwei Indexes und gibt alles dazwischen zurück, sondern es wird aus einem Startindex
und der Länge des Substrings berechnet.

Ist die resultierende Länge zu groß, wird alles bis zum Ende des originalen Strings zurückgegeben.
Bei negativem Startindex, wird von hinten angefangen zu zählen, so dass man die Methode sehr
vielfältig einsetzen kann.

[syntax="bmax"]String.sub:String(start_index:Int, length:Int)[/syntax]

Clone

Gibt eine neue Instanz des Strings zurück. Gleicher Inhalt in neuem String quasi. Das ist für Strings
nur bedingt sinnvoll, aber ich habe diktatorisch festgelegt, dass eine der sinnlos herumgammelnden
reservierten Methoden von BBClass ab jetzt eine Clone Method ist.

[syntax="bmax"]String.clone:String()[/syntax]

Object

Besagte Clone-Methoden-Kur wurde natürlich auch dem Basisobjekt verpasst. Es enthält jetzt eine
generische Methode, die von den im BBDebugScope gespeicherten Werten (siehe letzter Worklog)
ausgehend alle möglichen Objekte klonen kann.

Ich bin noch am überlegen, ob da nicht vielleicht eine abstrakte Platzhaltermethode sinnvoller wäre,
die einen Fehler ausgibt. Aber wenn man alles klonen kann und dass auch noch viel schneller als über
Reflection, warum dann nicht gleich implementieren?

[syntax="bmax"]Object.clone:Object()[/syntax]

Arrays

Die guten alten Speicherknechte sind ja relativ leer ausgegangen als es um die Bestückung mit
Werkzeug aka Methoden ging. Viel habe ich da auch noch nicht gemacht, aber das wird noch.

ToString

Ja gut, ToString kennt jeder. Leider ist das standardmäßig so unglaublich unnütz, dass es weh tut.
Es gibt die Speicheraddresse eines Objekes aus. Aha. Hab ich ehrlich gesagt noch nie gebraucht.

Ab sofort spuckt ein Aufruf oben genannter Methode eine kurze Beschreibung des Arrays aus:

[syntax="bmax"]Local arr1:Int[] = [1, 2, 3, 4, 5]
Print arr1.toString() ' Ausgabe: (Array) Int[5]

Local arr2:Float[1,2,3,4,5]
Print arr2.toString() ' Ausgabe: (Array) Float[1,2,3,4,5][/syntax]

Find*

Arrays zu durchsuchen ist ja keine ungewöhnliche Aufgabe, aber durch die fehlende Funktionsüberladung
in BlitzMax steht es schlecht um die datentyp-neutrale Suchwertübergabe. Ich hab das Ganze natürlich sehr
elegant *hust* gelöst.

Es haben einfach alle Datentypen ihre eigene Suchmethode. Beispiel gefällig?

[syntax="bmax"]Array.findInt:Int(value:Int)[/syntax]

Das findet den Index, des ersten Feldes mit dem übergebenen Wert. Ich werde mal schauen, ob ich noch
mehr hinzufüge (FindLast, Replace, Reverse) aber ich denke das würde Sinn ergeben.

Stay caffeinated,
Fabian