BlitzMax Extended
Worklogs
BlitzMax Extended Kommentare
Habe es auf Lion 10.7.4 getestet und versucht die aktuelle Version von [url=logic4dude.flowersoft.info]logic4dude[/url] zu kompilieren. Es kommt folgende Fehlermeldung. "Unhandled Exception:àíÿ¿R[ASSERT FAILED] for "len < BBSTRING_MAX_LENGTH" in "/Users/Fabrice/BlitzMax/mod/brl.mod/blitz.mod/c/blitz_string.c" line 159: String is too long."
In der Zeile wird folgendes gemacht: (Abgewandelt)
Code: [AUSKLAPPEN]
Print Int(CurrentDate().Split(" ")[2])
Habe die Alpha jetzt versucht auf Linux zu testen... versucht.
Beim Kompilieren deines brl.blitz bekomme ich einen Fehler, dass MUTEX_RECURSIVE nicht definiert ist. Nachdem ich es manuell aus dem #if-Block geholt habe, funktioniert das Kompilieren.
Dann habe ich zur Sicherheit das komplette brl-Modul neu kompiliert und dann versucht ein Programm zu kompilieren, aber es fehlen, wie es aussieht, ein paar Funktionen:
Zitat:
timer.linux.c
.text+0x1c): undefined reference to `bbMilliSecs'
timer.linux.c
.text+0x28): undefined reference to `bbDelay'
/home/christian/BlitzMax/mod/brl.mod/timer.mod/timer.release.linux.x86.a(timer.linux.c.release.linux.x86.o): In function `bbTimerStart':
timer.linux.c
.text+0xe6): undefined reference to `bbMilliSecs'
/home/christian/BlitzMax/mod/brl.mod/blitz.mod/blitz.release.linux.x86.a(blitz_app.c.release.linux.x86.o): In function `bbStartup':
blitz_app.c
.text+0x2d7): undefined reference to `startup'
/home/christian/BlitzMax/mod/brl.mod/blitz.mod/blitz.release.linux.x86.a(blitz_app.c.release.linux.x86.o): In function `bbLibStartup':
blitz_app.c
.text+0x2e1): undefined reference to `startup'
/home/christian/BlitzMax/mod/brl.mod/graphics.mod/graphics.release.linux.x86.a(graphics.bmx.release.linux.x86.o): In function `brl_graphics_Flip':
(code+0x862): undefined reference to `bbMilliSecs'
/home/christian/BlitzMax/mod/brl.mod/graphics.mod/graphics.release.linux.x86.a(graphics.bmx.release.linux.x86.o): In function `brl_graphics_Flip':
(code+0x86f): undefined reference to `bbDelay'
/home/christian/BlitzMax/mod/brl.mod/graphics.mod/graphics.release.linux.x86.a(graphics.bmx.release.linux.x86.o): In function `brl_graphics_Graphics':
(code+0x9d4): undefined reference to `bbMilliSecs'
Da hab ich dann nicht weiter nachgeforscht. Vielleicht schau ich später nochmal darüber. Wenn du was weißt, wäre ich natürlich auch froh, wenn du mir sagst, was ich probieren könnte.
Malloc und Memes
Samstag, 30. Juni 2012 um 15:19 Uhr von ProfJake
1. Danke für die Mühe variable-sized structs zu erklären, hatte ich keinen Nerv mehr dazu. Allerdings ist mir
durchaus bewusst, was das bedeutet und ich versuch nicht nur auf Krampf neue Typen reinzustopfen :'D
Das Modul muss sowieso im C99-kompatiblen Modus kompiliert werden ("-std=gnu99"),
also ist das mit der Kompatibilität auch kein Problem (zumal es intern ist, die API kratzt das nicht).
Den wirklichen Vorteil hast du selbst schon genannt: malloc. Der bcc initialisiert die Werte des BBDebugScope's
statisch, was ja auch Sinn ergibt. Wenn ich jetzt für jede C-Klasse zu Beginn ein malloc (selbst mit memory pool)
aufrufen müsste, neh das würde alles nur unnötig verlangsamen. So kann ich alles beim Kompilieren fertig haben.
2. Sorry für die vielen Memes im letzten Beitrag. Bin davon ausgegangen, dass das ein universelles Vokabular
für alle internetaffinen Menschen wäre, um lange Texte auf billige Art und Weise aufzulockern.
Zitat:
anstatt decls[1] deklariert ist.
Warum?
Ein Array mit Grösse 1 am Ende eines Structs bedeutet nicht etwa, dass hier tatsächlich ein Array mit Grösse 1 gewollt ist. Es ist der uralte C-Hack für PODs variabler Grösse, um Arrays mit zur Laufzeit bestimmten Grössen effizient zu machen (man braucht nur ein malloc, nicht zwei). z.B. BBArray benutzt das gleiche, um Platz für Metadaten und eigentlichem Array-Inhalt in einem Rutsch zu schaffen..
Der Trick ist es, für das struct mehr Speicher zu allozieren, als die Definition eigentlich benötigt; dann kann man mittels des letzten Members (in diesem Fall decls) beliebig über gesetzte Arraygrenzen (1 im Falle des Hacks) hinaus lesen und schreiben. Da man die allozierte Grösse mittels malloc zur Laufzeit bestimmen kann, hat man so einen Mechanismus, um ein struct, welches ein Array mit variabler Grösse beinhaltet, mit nur einer einzigen Allokation zu erstellen. Limitierung ist natürlich, dass man höchstens ein solches Array pro struct haben darf und es immer am Ende des structs stehen muss, aber meistens reicht das ja.
decls[] bedeuted quasi dasselbe, nur ist es nicht ganz so portabel. Es wurde damals im C99-Standard eingeführt, um genauer zu signalisieren, was man hier vorhat. Das [] ist nämlich eindeutig, während das [1] auf den ersten Blick keinen Sinn ergibt
Grundsätzlich bedeutet es aber genau dasselbe (semantisch hat sich zwischen bb_debugscope_t und BBDebugScope nichts geändert).
Problem ist, dass es nur in C eingeführt wurde; ein C++-Compiler wird unter normalen Umständen ein [] in diesem Kontext anstreichen.
gcc sollte sowas afaik akzeptieren, aber so oder so ist es eine gute Idee, sich an den Coding Stil des umgebenden Codes zu halten - und Mark benutzt halt die old school Variante
(ah, und ein bisschen weniger Memes wären ganz nett - ist ja ein Programmiererworklog, kein Imageboard
)
Lese auch mit und finde es sehr intessant. Find ich gut was du machst! Viel Erfolg
Mitleser: +1
Namenmsänderungen
Montag, 7. Mai 2012 um 20:13 Uhr von ProfJake
Ja, das mit den Namensänderungen war damals eher eine Trotzreaktion
auf den Präfix "bb", der suggeriert, dass BlitzMax einfach nur BlitzBasic
auf mehreren Plattformen ist. War nicht so die beste Entscheidung.
Die aktuelle Version ist komplett binärkompatibel, wobei jedoch einige
Features als "deprecated" gekennzeichnet sind und beim kompilieren
deaktiviert werden können. Das aus der Reihe fallende BBARRAYDATA
Makro wird z.B. ersetzt durch BBARRAY_DATA.
Werde ich mit Interesse verfolgen, denn das Gefühl ("DAFUQ?" - btw sehr treffend ausgedrückt) kenne ich. Du willst also es für diejenigen, die sich mit dem Standardlib-Code auseinandersetzen, einfacher machen, ihn zu verstehen? Durch Kommentare und aufgeräumteren Sourcecode? - Freue mich schon den Quelltext zu durchblicken, weil ich mir bisher nicht die Zeit dazu genommen habe.
Der Punkt "Features hinzufügen" hat mich noch extra neugierig gemacht 
- habe mich auch damals bei BSL auf dem Laufenden gehalten.
Ich habe aber z.B. die Namensänderungen nicht so sinnvoll gefunden, ich hoffe, die kommt diesmal nicht. Jemand, der schon auf die C API zugreift, muss seinen Code komplett umschreiben und so sehr stört es dann auch nicht, dass BB vorangestellt wird und nicht BM.
Rückruf
Sonntag, 6. Mai 2012 um 15:25 Uhr von ProfJake
Der charmante Südamerikaner hinter mir meint gerade mit Nachdruck,
dass alles, was ich in den Tüten gesehen habe nur reiner Puderzucker war.
Ich entschuldige mich also für Missverständnisse, es waren einfache Puderzuckerhändler aus Kolumbien, die mich damals für den Geburtstag
ihres Sohnes Juan in ihre verminte Landvilla geordert hatten.
Depressionen und Klinikaufenthalte, bedeutet dagegen hier in der Region
"Bauchschmerzen und Karies vom Kuchenessen mit Oma". True story.
Ein weiteres interessantes Worklog-Projekt.
Ist das mit den Depressionen, Klinikaufenthalten und kolumbianischen Drogenbossen eigentlich wahr oder hab ich eine neue Redewendung verpasst?
MFG Lador