BlitzMax Extended

	Lador	So, Mai 06, 2012 14:29
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
Mein aktuelles Projekt: 2D-Rollenspiel "Iliran" Screenshot \| Worklog Fortschritt: ca. 70%

Lador

So, Mai 06, 2012 14:29

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

Mein aktuelles Projekt:
2D-Rollenspiel "Iliran"
Screenshot | Worklog
Fortschritt: ca. 70%

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Rückruf	So, Mai 06, 2012 15:25
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.

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Rückruf

So, Mai 06, 2012 15:25

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.

	Thunder	Mo, Mai 07, 2012 17:31
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.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Mai 07, 2012 17:31

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 Smile

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

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Namenmsänderungen	Mo, Mai 07, 2012 20:13
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.

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Namenmsänderungen

Mo, Mai 07, 2012 20:13

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.

	Hagbard	Mi, Jun 27, 2012 10:58
Mitleser: +1

Hagbard

Mi, Jun 27, 2012 10:58

Mitleser: +1

	DAK	Mi, Jun 27, 2012 11:32
Lese auch mit und finde es sehr intessant. Find ich gut was du machst! Viel Erfolg
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Jun 27, 2012 11:32

Lese auch mit und finde es sehr intessant. Find ich gut was du machst! Viel Erfolg

Gewinner der 6. und der 68. BlitzCodeCompo

	Noobody	Sa, Jun 30, 2012 12:16
Zitat: Es gibt jetzt einen internes struct bb_debugscope_t, wo genau dieses Feld als decls[] 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 )
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Sa, Jun 30, 2012 12:16

Zitat:

Es gibt jetzt einen internes struct bb_debugscope_t, wo genau dieses Feld als decls[]
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 Razz

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 Razz

(ah, und ein bisschen weniger Memes wären ganz nett - ist ja ein Programmiererworklog, kein Imageboard Wink

)

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Malloc und Memes	Sa, Jun 30, 2012 15:19
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.

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Malloc und Memes

Sa, Jun 30, 2012 15:19

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.

	Thunder	So, Jul 08, 2012 10:01
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: /home/christian/BlitzMax/mod/brl.mod/timer.mod/timer.release.linux.x86.a(timer.linux.c.release.linux.x86.o): In function `timerProc': 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.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

So, Jul 08, 2012 10:01

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:

/home/christian/BlitzMax/mod/brl.mod/timer.mod/timer.release.linux.x86.a(timer.linux.c.release.linux.x86.o): In function `timerProc':
timer.linux.c Sad

.text+0x1c): undefined reference to `bbMilliSecs'
timer.linux.c Sad

.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 Sad

.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 Sad

.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 Sad

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

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	FWeinb ehemals "ich"	So, Jul 08, 2012 14:14
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] [EINKLAPPEN] Print Int(CurrentDate().Split(" ")[2])
"Wenn die Menschen nur über das sprächen, was sie begreifen, dann würde es sehr still auf der Welt sein." Albert Einstein (1879-1955) "If you live each day as if it was your last, someday you'll most certainly be right." Steve Jobs

FWeinb

ehemals "ich"

So, Jul 08, 2012 14:14

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])

"Wenn die Menschen nur über das sprächen, was sie begreifen, dann würde es sehr still auf der Welt sein." Albert Einstein (1879-1955)
"If you live each day as if it was your last, someday you'll most certainly be right." Steve Jobs

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Fixes	So, Jul 08, 2012 18:22
Danke für die Rückmeldungen. 1. Thunder: Das Fehlen der Funktionen liegt höchstwahrscheinlich daran, dass BB_OS_LINUX nicht definiert wurde. Ich habe bisher nur auf "__linux__" getestet, da "__linux" veraltet ist. FIX: Test auf beide vordefinierten Kompilerkonstanten 2. ich Der Fehler kam nur im experimentellen Modus vor, das habe ich wohl übersehen. FIX: Kein spezieller "experimenteller" Code mehr in bbStringSplit. Läuft jetzt in allen Modi. Das Update ist im Worklog verlinkt.

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Fixes

So, Jul 08, 2012 18:22

Danke für die Rückmeldungen.

1. Thunder:
Das Fehlen der Funktionen liegt höchstwahrscheinlich daran, dass BB_OS_LINUX nicht definiert wurde.
Ich habe bisher nur auf "__linux__" getestet, da "__linux" veraltet ist.

FIX: Test auf beide vordefinierten Kompilerkonstanten

2. ich
Der Fehler kam nur im experimentellen Modus vor, das habe ich wohl übersehen.

FIX: Kein spezieller "experimenteller" Code mehr in bbStringSplit. Läuft jetzt in allen Modi.

Das Update ist im Worklog verlinkt.

	Lobby	Mi, Jul 18, 2012 14:16
Wenn ich dann einmal als Teil der Fenster-und-Sanduhr-Fraktion etwas zu deinem Projekt sagen darf: es funktioniert nicht. Um genauer zu sein, kommt beim Versuch das ganze zu kompilieren die folgende Ausgabe: http://pastebin.com/CtzDeX1L Ich habe einfach deinen blitz.mod-Ordner den bisherigen überschreiben lassen. Mein gcc hat die Version 3.4.5 von 2004, weil ich mit neueren Versionen Probleme beim Kompilieren von anderen Modulen hatte.
TheoTown - Eine Stadtaufbausimulation für Android, iOS, Windows, Mac OS und Linux

Lobby

Mi, Jul 18, 2012 14:16

Wenn ich dann einmal als Teil der Fenster-und-Sanduhr-Fraktion etwas zu deinem Projekt sagen darf: es funktioniert nicht.
Um genauer zu sein, kommt beim Versuch das ganze zu kompilieren die folgende Ausgabe: http://pastebin.com/CtzDeX1L
Ich habe einfach deinen blitz.mod-Ordner den bisherigen überschreiben lassen. Mein gcc hat die Version 3.4.5 von 2004, weil ich mit neueren Versionen Probleme beim Kompilieren von anderen Modulen hatte.

TheoTown - Eine Stadtaufbausimulation für Android, iOS, Windows, Mac OS und Linux

	Nova	Mi, Jul 18, 2012 17:42
Kann mir jemand eine kurze Erklärung geben, was das ganze überhaupt soll? Sind das alles nur "Aufräumaktionen" an grundlegenden Sachen von BlitzMax oder soll es auch noch speziellere Verbesserungen geben? Wird man einfach die Original-Version ersetzen können, neu compilieren und alles ist gut? Ich bin nicht so ganz auf der Höhe, was hier so alles passiert. Ein paar einfache Worte für die "niedere Programmiererschicht" der "Fenster-und-Sanduhr-Fraktion" wäre daher wirklich nett! ;D
AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

Nova

Mi, Jul 18, 2012 17:42

Kann mir jemand eine kurze Erklärung geben, was das ganze überhaupt soll? Sind das alles nur "Aufräumaktionen" an grundlegenden Sachen von BlitzMax oder soll es auch noch speziellere Verbesserungen geben? Wird man einfach die Original-Version ersetzen können, neu compilieren und alles ist gut?
Ich bin nicht so ganz auf der Höhe, was hier so alles passiert. Ein paar einfache Worte für die "niedere Programmiererschicht" der "Fenster-und-Sanduhr-Fraktion" wäre daher wirklich nett! ;D

AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Sinn und Zweck	Mi, Jul 18, 2012 18:18
@Nova: Ja, man kann dann einfach das originale brl.blitz Modul ersetzen. Ja, es soll ein aufgeräumterer Quellcode mit ausführlicherer Dokumentation werden. Ja, es sind neue Funktionen mit eingebaut worden. (Mehr für die C/C++-API, aber auch für BlitzMax ist viel dabei.) Es lohnt sich denke ich für alle, die "extended" Version zu nutzen. Schon allein, weil an der originalen nur wenig gemacht wird. Außerdem gibt es viele neue Funktionen und alte Funktionen, die schneller und sicherer geworden sind. @Lobby: Das sieht ja nicht gerade gut aus, werde mir das mal anschauen. Auch wenn natürlich ein 8 Jahre alter Kompiler nicht so dufte ist. Sieht das bei der ganzen Windows-Fraktion so aus, dass man den alten GCC verwenden muss?

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Sinn und Zweck

Mi, Jul 18, 2012 18:18

@Nova:

Ja, man kann dann einfach das originale brl.blitz Modul ersetzen.
Ja, es soll ein aufgeräumterer Quellcode mit ausführlicherer Dokumentation werden.
Ja, es sind neue Funktionen mit eingebaut worden. (Mehr für die C/C++-API, aber auch für BlitzMax ist viel dabei.)

Es lohnt sich denke ich für alle, die "extended" Version zu nutzen. Schon allein, weil an der originalen nur wenig gemacht wird.
Außerdem gibt es viele neue Funktionen und alte Funktionen, die schneller und sicherer geworden sind.

@Lobby:

Das sieht ja nicht gerade gut aus, werde mir das mal anschauen. Auch wenn natürlich ein 8 Jahre alter Kompiler nicht so dufte ist.
Sieht das bei der ganzen Windows-Fraktion so aus, dass man den alten GCC verwenden muss?

	Nova	Mi, Jul 18, 2012 18:41
Sind diese Geschwindkeitsvorteile allgemein gehalten (sind also bei fast jedem Projekt präsent) oder muss man für diese wirklich bestimmte Funktionen nutzen? Auf jeden Fall sehr schön, dass auch solche Dinge noch Verbesserungen (wenn auch keine offizielle) erfahren. Finde ich auf jeden Fall gut.
AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

Nova

Mi, Jul 18, 2012 18:41

Sind diese Geschwindkeitsvorteile allgemein gehalten (sind also bei fast jedem Projekt präsent) oder muss man für diese wirklich bestimmte Funktionen nutzen?

Auf jeden Fall sehr schön, dass auch solche Dinge noch Verbesserungen (wenn auch keine offizielle) erfahren. Finde ich auf jeden Fall gut. Smile

AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

	ProfJake ehemals "DTC" / "Fabian Niemann"	Mi, Jul 18, 2012 19:15
@Nova: Wenn du die neuen Features benutzt statt BlitzMax-Implementationen, werden deine Programme schneller sein als vorher – versprochen. (z.B isLower/isUpper kriegst du mit BlitzMax nicht ohne weiters so schnell hin) Ansonsten werde ich beim erreichen der BETA, wenn alles an Features soweit drin und funktionsfähig ist, nochmal speziell auf Geschwindigkeit optimieren. (Vielleicht sogar beim kompilieren einstellbar: schnell oder klein) @Lobby: Habe den Link mal gegen den zu einer neuen Version ausgetauscht. Könnte sein, dass einfach nur die Zeile, die "windows.h" inkludiert an der falschen Position stand.

ProfJake

ehemals "DTC" / "Fabian Niemann"

Mi, Jul 18, 2012 19:15

@Nova:

Wenn du die neuen Features benutzt statt BlitzMax-Implementationen, werden deine Programme schneller sein als vorher – versprochen. (z.B isLower/isUpper kriegst du mit BlitzMax nicht ohne weiters so schnell hin)
Ansonsten werde ich beim erreichen der BETA, wenn alles an Features soweit drin und funktionsfähig ist, nochmal speziell auf Geschwindigkeit optimieren.

(Vielleicht sogar beim kompilieren einstellbar: schnell oder klein)

@Lobby:

Habe den Link mal gegen den zu einer neuen Version ausgetauscht.
Könnte sein, dass einfach nur die Zeile, die "windows.h" inkludiert an der falschen Position stand.

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Geschwindigkeit	Do, Jul 19, 2012 00:04
Nochmal klarer auf den Punkt gebracht: BlitzMaxExtended ist im Durchschnitt etwas schneller als das Original, mindestens aber genauso schnell.

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Geschwindigkeit

Do, Jul 19, 2012 00:04

Nochmal klarer auf den Punkt gebracht:

BlitzMaxExtended ist im Durchschnitt etwas schneller als das Original, mindestens aber genauso schnell.

	blackgecko Betreff: makedocs kaputt machen...	So, Okt 07, 2012 19:46
Getestet auf Fedora 17: Kompiliert ohne Probleme. Beim Durchlaufen steigt zwischendurch der RAM-Verbrauch ziemlich stark an, was beim Original nicht so ist. Aber es läuft komplett durch. Hoffe das hilft weiter.
So long and thanks for all the fish. Fedora 17 \| Windows 7 \|\| BlitzPlus \| BlitzMax Rechtschreibflame GO!!! Deppenapostroph \| SeidSeit \| Deppenakzent \| DassDas \| Deppenleerzeichen \| TodTot \| enzigste.info - Ja, ich sammel die.

blackgecko

Betreff: makedocs kaputt machen...

So, Okt 07, 2012 19:46

Getestet auf Fedora 17:
Kompiliert ohne Probleme. Beim Durchlaufen steigt zwischendurch der RAM-Verbrauch ziemlich stark an, was beim Original nicht so ist. Aber es läuft komplett durch.
Hoffe das hilft weiter.

So long and thanks for all the fish.
Fedora 17 | Windows 7 || BlitzPlus | BlitzMax
Rechtschreibflame GO!!! Deppenapostroph | SeidSeit | Deppenakzent | DassDas | Deppenleerzeichen | TodTot | enzigste.info - Ja, ich sammel die.

	kog Betreff: Fehler beim Compilieren	Mi, Okt 24, 2012 18:18
Guten Tag, Ich wollte es gerade ausprobieren, habe den Inhalt aus dem Archiv in einen neuen Ordner namens brl.blitz getan, Kompliert keine probleme mit bmk. Jedoch wenn ich den Test starten will im Archiv, kommt folgende Fehlermeldung: Code: [AUSKLAPPEN] [EINKLAPPEN] D:/BlitzMax/lib/libmingwex.a(pformat.o):pformat.c:(.text+0x355): undefined reference to `__umoddi3' D:/BlitzMax/lib/libmingwex.a(pformat.o):pformat.c:(.text+0x377): undefined reference to `__udivdi3'
Windows 7 Home Premium 64bit CPU: Intel Core i5 3450 Ivy Bridge GPU: HIS HD 4870 1GB GDDR5 RAM: 4x 4GB DDR3-SDRAM Dual Channel

kog

Betreff: Fehler beim Compilieren

Mi, Okt 24, 2012 18:18

Guten Tag,

Ich wollte es gerade ausprobieren, habe den Inhalt aus dem Archiv in einen neuen Ordner namens brl.blitz getan, Kompliert keine probleme mit bmk.

Jedoch wenn ich den Test starten will im Archiv, kommt folgende Fehlermeldung:
Code: [AUSKLAPPEN]

D:/BlitzMax/lib/libmingwex.a(pformat.o):pformat.c:(.text+0x355): undefined reference to `__umoddi3'
D:/BlitzMax/lib/libmingwex.a(pformat.o):pformat.c:(.text+0x377): undefined reference to `__udivdi3'

Windows 7 Home Premium 64bit
CPU: Intel Core i5 3450 Ivy Bridge
GPU: HIS HD 4870 1GB GDDR5
RAM: 4x 4GB DDR3-SDRAM Dual Channel

	ProfJake ehemals "DTC" / "Fabian Niemann" Betreff: Linker of Lame	Mi, Okt 24, 2012 23:29
Hi kog, genau das gleiche Problem hatte Lobby auch und ich hab bis jetzt ehrlich gesagt eher in die Röhre als durchgesehen. Es ist ja offensichtlich ein Linkerproblem und damit doof zu lösen für mich als Mac-Typie. Im vorliegenden Fall ist es der GCC, der eine Schleife optimiert und dafür dieses Modulozeugs einsetzt. Natürlich sind Optimierungen super, aber wenn MinGW sie nicht unterstützt ist das eine ganz andere Geschichte. Hier wurde das Problem schonmal diskutiert – probier es mal aus. ABER: Diese Linkeroptionen sind eigentlich schon gesetzt. Von daher bin ich mir nicht sicher, ob das heute noch viel hilft (v1.49). Ich habe bei der neuesten Version mal den Optimierungslevel auf Standard (O2) gelassen. Vielleicht reicht das schon. Ansonsten den neusten MinGW besorgen und die hier vorgeschlagene Lösung ausprobieren. ProfJake

ProfJake

ehemals "DTC" / "Fabian Niemann"

Betreff: Linker of Lame

Mi, Okt 24, 2012 23:29

Hi kog,

genau das gleiche Problem hatte Lobby auch und ich hab bis jetzt ehrlich gesagt eher in die Röhre als durchgesehen. Es ist ja offensichtlich ein Linkerproblem und damit doof zu lösen für mich als Mac-Typie.

Im vorliegenden Fall ist es der GCC, der eine Schleife optimiert und dafür dieses Modulozeugs einsetzt. Natürlich sind Optimierungen super, aber wenn MinGW sie nicht unterstützt ist das eine ganz andere Geschichte.

Hier wurde das Problem schonmal diskutiert – probier es mal aus. ABER: Diese Linkeroptionen sind eigentlich schon gesetzt. Von daher bin ich mir nicht sicher, ob das heute noch viel hilft (v1.49).

Ich habe bei der neuesten Version mal den Optimierungslevel auf Standard (O2) gelassen. Vielleicht reicht das schon.

Ansonsten den neusten MinGW besorgen und die hier vorgeschlagene Lösung ausprobieren.

ProfJake

Übersicht

Kommentare

Worklogs

BlitzBasic Portal

Betreff: Rückruf

Betreff: Namenmsänderungen

Betreff: Malloc und Memes

Betreff: Fixes

Betreff: Sinn und Zweck

Betreff: Geschwindigkeit

Betreff: makedocs kaputt machen...

Betreff: Fehler beim Compilieren

Betreff: Linker of Lame