ZFX + Developia

Schonmal auf anderer Hardware getestet?

C:/Users/UpdatusUser
Nvidia WTF? -.-

Entdeckung des Tages:
Man kann objC Properties statt auf existierende Variablen einfach auf nicht existente wie z.B. einfache Tippfehler zugreifen lassen, gibt kein Warning, kein nichts, es wird dann einfach eine Variable erzeugt und den Compiler interessiert es nicht die Bohne, dass die nirgends initalisiert wird und außerhalb der readonly property nicht benutzt wird, "it's a feature, not a bug!" *argh*

Oh, und wo wir schon dabei sind - was mich schon immer aufgeregt hat:
Der GCC optimiert in switches einfach states weg, in denen nichts passiert oder die er nicht anspringt, auch in der debug Config, womit in dem Beispiel Quelltext mit einem Breakpoint in jedem Case einfach keiner der Cases angesprungen wird...
Keine Ahnung, ob man ihm das irgendwie abgewöhnen kann durch andere Projekteinstellungen.

ObjC ist voll von solchen Späßen. Sicher das man nicht irgendwo die höchste Warnstufe einstellen kann und das dann angezeigt wird?

Chromanoid hat geschrieben:ObjC ist voll von solchen Späßen. Sicher das man nicht irgendwo die höchste Warnstufe einstellen kann und das dann angezeigt wird?

Sowas wie warning-level gibts im gcc/clang ja nicht, man kann eben einen Haufen warnings einzeln an- und abschalten und natürlich alles an und dann treat warnings as errors, wovon ich unter Xcode stark abrate (da das nämlich auch so Sachen, wie your Provising profile is about to expire" als Warnings anzeigt, obwohl man es erst verlängern kann, wenn es tatsächlich ausgelaufen ist...).
Ich bezweifle aber, dass sich die implizite Variablenerzeugung für Properties als Warning anzeigen lässt, da es wohlgemerkt als Feature gedacht ist (vor 2 Jahren mit älteren Xcode Versionen gabs Fehlermeldungen, wenn die Property eine synthesize auf eine nicht existente Variable hatte, bei den gleichen Projekten mit den gleichen Settings erzeugen aktuelle Xcode Versionen die Variable jetzt einfach).

ic ich glaube ich habe noch eine etwas ältere version gehabt. Als Java Freund ist man es ja gar nicht gewöhnt so genau hinzuschauen. Als ich damals an einem App entwickelt hab, habe ich also erst mal laufend irgendwelche unbekannten signale verschickt... Das war dann der Moment an dem ich begonnen habe Warnungen ernst zu nehmen :D.

Als Java Freund ist man es ja gar nicht gewöhnt so genau hinzuschauen.

Wieso auch? Java wird nicht besser wenn man dabei auch noch hinguckt. *scnr*

-.- :D Java programmiert sich praktisch von alleine, in Netbeans sieht Programmieren bei mir im Grunde so aus: CTRL+Space Cursor Cursor = CTRL+Space Cursor ( CTRL+Space , CTRL+Space Cursor ); CTRL+Space Cursor Enter Cursor Cursor... :) Alles was irgendwie schlechter Stil ist oder zu Fehlern führen könnte, wird sofort gelb markiert, mit einem Tipp versehen und kann meistens automatisch behoben werden. Ich muss eigentlich nur Wörter schreiben wenn ich Dinge bename und Klassen und Funktionsköpfe definiere.... Achja manchmal tauchen noch keywords wie for, if, new oder while auf, aber da geht dann meistens auch sofort ein template los, das die gewünschte geschichte mit klammern versieht und ausschreibt. Konstruktoren, Getter&Setter, Funktionen von Interfaces etc. werden ja eh automatisch auf Knopfdruck generiert.
In XCode war das soweit ich mich erinnere noch etwas rudimentärer wenn es um solche Dinge ging.

Chromanoid hat geschrieben:ic ich glaube ich habe noch eine etwas ältere version gehabt. Als Java Freund ist man es ja gar nicht gewöhnt so genau hinzuschauen. Als ich damals an einem App entwickelt hab, habe ich also erst mal laufend irgendwelche unbekannten signale verschickt... Das war dann der Moment an dem ich begonnen habe Warnungen ernst zu nehmen :D.

Das hat aber auch mich, der aus dem Bereich C/C++ kommt, anfangs irritiert, dass ich in objC zur Kompilierzeit jede Methode auf jeder Klasse aufrufen kann und erst zur Laufzeit geprüft wird, ob die Klasse überhaupt eine Methode mit dem Namen und der Signatur kennt.

ERNSTHAFT? Der neue nVida-Treiber meldet meinen Zweitbildschirm bei JEDEM Abschalten der Anzeige zwecks Energiesparen IM SYSTEM AB?! Muss ich mir jetzt ERNSTHAFT alle 5 Minuten Inaktivität mein komplettes Monitorsetup MANUELL wiederherstellen? AAAOOAAAAHHH!



@dot: Nein, werde ich testen, sobald ich dazu komme.

Ach, printf-Syntax ist doch was feines:
Gerade zur Vermeidung von magic-numbers bei der Angabe des Mindestplatzes für bestimmte Parameter einen Formatstring genutzt, der das Format für die Kreation des eigentlichen Formatstrings, welcher dann den tatsächlichen String kreiert, festlegt.
Sieht dann so aus:
L"%%-%dls %%-%ds %%-%dls line: %%%dd - %%ls"
OK, die magic-numbers bin ich los, aber ob dieses unleserliche Ding jetzt wartbarer ist? :?

PS:
Bevor jemand mit der Idee kommt, doch einfach C++ Strings zu nutzen statt cstrings: Geht in purem C leider nicht.

Kopf -> Wand

kaiserludi hat geschrieben:

Code: Alles auswählen

			// Formatierte Stringausgabe in C:
			// ascii string in formatierten ascii string Ausgabe:
			printf("%s\n", "foo0"); // VS: ok, GCC: ok - wie erwartet
			printf("%S\n", "foo1"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hs\n", "foo2"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", "foo3"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hS\n", "foo4"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			printf("%lS\n", "foo5"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into ascii: nur %s funzt plattformunabhängig

			// unicode string in formatierten ascii string Ausgabe:
			printf("%s\n", L"foo6"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%S\n", L"foo7"); // VS: ok, GCC: ok - wie erwartet
			printf("%hs\n", L"foo8"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", L"foo9"); // VS: ok, GCC: ok - wie erwartet
			printf("%hS\n", L"foo10"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein Hs
			printf("%lS\n", L"foo11"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into ascii: %S und %ls funzen plattformunabhängig

			// ascii string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", "foo12"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%S\n", "foo13"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", "foo14"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", "foo15"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			wprintf(L"%hS\n", "foo16"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", "foo17"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into unicode: überhaupt nichts funzt plattformunabhängig

			// unicode string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", L"foo18"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%S\n", L"foo19"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", L"foo20"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", L"foo21"); // VS: ok, GCC: ok - wie erwartet
			wprintf(L"%hS\n", L"foo22"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", L"foo23"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into unicode: nur %ls funzt plattformunabhängig

Kopf -> Wand

That's the reason why you should use utf-8

antisteo hat geschrieben:

kaiserludi hat geschrieben:

Code: Alles auswählen

			// Formatierte Stringausgabe in C:
			// ascii string in formatierten ascii string Ausgabe:
			printf("%s\n", "foo0"); // VS: ok, GCC: ok - wie erwartet
			printf("%S\n", "foo1"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hs\n", "foo2"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", "foo3"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hS\n", "foo4"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			printf("%lS\n", "foo5"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into ascii: nur %s funzt plattformunabhängig

			// unicode string in formatierten ascii string Ausgabe:
			printf("%s\n", L"foo6"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%S\n", L"foo7"); // VS: ok, GCC: ok - wie erwartet
			printf("%hs\n", L"foo8"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", L"foo9"); // VS: ok, GCC: ok - wie erwartet
			printf("%hS\n", L"foo10"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein Hs
			printf("%lS\n", L"foo11"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into ascii: %S und %ls funzen plattformunabhängig

			// ascii string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", "foo12"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%S\n", "foo13"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", "foo14"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", "foo15"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			wprintf(L"%hS\n", "foo16"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", "foo17"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into unicode: überhaupt nichts funzt plattformunabhängig

			// unicode string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", L"foo18"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%S\n", L"foo19"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", L"foo20"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", L"foo21"); // VS: ok, GCC: ok - wie erwartet
			wprintf(L"%hS\n", L"foo22"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", L"foo23"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into unicode: nur %ls funzt plattformunabhängig

Kopf -> Wand

That's the reason why you should use utf-8

Wenn die lösung so einfach wäre, aber dummerweise unterstützen wir auch Plattformen, auf denen UTF8-Support praktisch nicht vorhanden ist und man daher auf widestrings angewiesen ist, von sonstigen auch auf anderen Plattformen vorhandenen Nachteilen von utf8 in der API (Performance und Komplexität von Operationen auf dem String, wenn nicht alle Characters die gleiche Größe haben) mal ganz zu schweigen.

kaiserludi hat geschrieben:

antisteo hat geschrieben:

kaiserludi hat geschrieben:

Code: Alles auswählen

			// Formatierte Stringausgabe in C:
			// ascii string in formatierten ascii string Ausgabe:
			printf("%s\n", "foo0"); // VS: ok, GCC: ok - wie erwartet
			printf("%S\n", "foo1"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hs\n", "foo2"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", "foo3"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hS\n", "foo4"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			printf("%lS\n", "foo5"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into ascii: nur %s funzt plattformunabhängig

			// unicode string in formatierten ascii string Ausgabe:
			printf("%s\n", L"foo6"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%S\n", L"foo7"); // VS: ok, GCC: ok - wie erwartet
			printf("%hs\n", L"foo8"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", L"foo9"); // VS: ok, GCC: ok - wie erwartet
			printf("%hS\n", L"foo10"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein Hs
			printf("%lS\n", L"foo11"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into ascii: %S und %ls funzen plattformunabhängig

			// ascii string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", "foo12"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%S\n", "foo13"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", "foo14"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", "foo15"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			wprintf(L"%hS\n", "foo16"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", "foo17"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into unicode: überhaupt nichts funzt plattformunabhängig

			// unicode string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", L"foo18"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%S\n", L"foo19"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", L"foo20"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", L"foo21"); // VS: ok, GCC: ok - wie erwartet
			wprintf(L"%hS\n", L"foo22"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", L"foo23"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into unicode: nur %ls funzt plattformunabhängig

Kopf -> Wand

That's the reason why you should use utf-8

Wenn die lösung so einfach wäre, aber dummerweise unterstützen wir auch Plattformen, auf denen UTF8-Support praktisch nicht vorhanden ist und man daher auf widestrings angewiesen ist, von sonstigen auch auf anderen Plattformen vorhandenen Nachteilen von utf8 in der API (Performance und Komplexität von Operationen auf dem String, wenn nicht alle Characters die gleiche Größe haben) mal ganz zu schweigen.

Dazu hat Lazarus dann die Funktion utf8towidestring ;) (oder ich glaub der castet sogar implizit)

antisteo hat geschrieben:

kaiserludi hat geschrieben:

antisteo hat geschrieben:

kaiserludi hat geschrieben:

Code: Alles auswählen

			// Formatierte Stringausgabe in C:
			// ascii string in formatierten ascii string Ausgabe:
			printf("%s\n", "foo0"); // VS: ok, GCC: ok - wie erwartet
			printf("%S\n", "foo1"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hs\n", "foo2"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", "foo3"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%hS\n", "foo4"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			printf("%lS\n", "foo5"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into ascii: nur %s funzt plattformunabhängig

			// unicode string in formatierten ascii string Ausgabe:
			printf("%s\n", L"foo6"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			printf("%S\n", L"foo7"); // VS: ok, GCC: ok - wie erwartet
			printf("%hs\n", L"foo8"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			printf("%ls\n", L"foo9"); // VS: ok, GCC: ok - wie erwartet
			printf("%hS\n", L"foo10"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein Hs
			printf("%lS\n", L"foo11"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into ascii: %S und %ls funzen plattformunabhängig

			// ascii string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", "foo12"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%S\n", "foo13"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", "foo14"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", "foo15"); // VS: nicht ok, GCC: nicht ok - wie erwartet
			wprintf(L"%hS\n", "foo16"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", "foo17"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> ascii into unicode: überhaupt nichts funzt plattformunabhängig

			// unicode string in formatierten unicode string Ausgabe:
			wprintf(L"%s\n", L"foo18"); // VS: ok, GCC: nicht ok - os-abhängiges Verhalten
			wprintf(L"%S\n", L"foo19"); // VS: nicht ok, GCC: ok - os-abhängiges Verhalten
			wprintf(L"%hs\n", L"foo20"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hs
			wprintf(L"%ls\n", L"foo21"); // VS: ok, GCC: ok - wie erwartet
			wprintf(L"%hS\n", L"foo22"); // VS: nicht ok, GCC: compiler-warning - GCC unterstützt kein hS
			wprintf(L"%lS\n", L"foo23"); // VS: ok, GCC: compiler-warning - GCC unterstützt kein lS
			// Fazit -> unicode into unicode: nur %ls funzt plattformunabhängig

Kopf -> Wand

That's the reason why you should use utf-8

Wenn die lösung so einfach wäre, aber dummerweise unterstützen wir auch Plattformen, auf denen UTF8-Support praktisch nicht vorhanden ist und man daher auf widestrings angewiesen ist, von sonstigen auch auf anderen Plattformen vorhandenen Nachteilen von utf8 in der API (Performance und Komplexität von Operationen auf dem String, wenn nicht alle Characters die gleiche Größe haben) mal ganz zu schweigen.

Dazu hat Lazarus dann die Funktion utf8towidestring ;) (oder ich glaub der castet sogar implizit)

Die ich auch fleißig nutze, aber das bedeutet eben, um widestrings komme ich dennoch nicht rum.

Instabile 10kbit/s sind echt das letzte :evil: :evil: :evil: ISP meint, die Daempungswerte der Leitung seien seit einer Woche voellig im Einer. Schoen. Und nu? Machen koennen oder wollen die angeblich nix. Hab erstmal ein neues DSL-Modem bekommen... Das hilft bestimmt bei einer kaputten Leitung. Wenn das morgen mit dem neuen Modem nicht besser laeuft, kann oder will ich nicht mehr fuer den Anschluss zahlen :roll:

Wie kann man nur auf die Idee kommen, einen Compositor auf Basis von glReadPixels zu implementieren, wenn man Alternativen wie FBOs oder Pixmaps hat, die alles "auf der GPU" lassen koennten?

Clang's Codegenerierung für C++-Templates ist noch nicht die allerbeste.
Mich sollte es ja nicht stören, da ich kein C++ benutze... Weit gefehlt. opt und llc (beides LLVM-Komponenten) werden mit clang kompiliert und laufen dementsprechend langsamer.

Seitdem ich vor ca. 2 Wochen den Windows Aero Desktop endgültig abgeschaltet habe, habe ich in all meinen Grafikanwendungen keinen einzigen Ruckler mehr gehabt (selbst bei ca. 20 FPS wirkt alles noch rund!). Das ist ein ganz neues Entwicklergefühl, wenn man sich nicht mehr bei jedem Testlauf fragen muss, ob man trotz vollkommen allokationsfreier Frameberechnung und ausgefuchster Framezeitnormalisierung mittels gleitenden Durchschnitts immer noch unfähig ist, eine Anwendung mit auch nur einigermaßen gleichmäßiger Framezeit zu schreiben (einigermaßen bezieht sich hier auf besser als ein VERHÄLTNIS aufeinanderfolgender Framezeiten von 1:10, was bei angeschaltetem Windows Aero quasi die Regel ist!).

Glew ist ein Drecksverein: benutzen seit Ewigkeiten glGetString(GL_EXTENSIONS) obwohl es seit OGL 3.1 removed ist ...

Also glew neukompiliert als C++ Projekt und intern das Problem gefixt...

Visual C++ mit /Oi (ohne Gewähr aus dem Gedächtnis):

double const infinity = -::log(0.0);
// Gleicht:
union {
    unsigned __int64 const infinityAsInt;
    double infinity;
} const = { 0x7ff0000000000000ull };

void foo() {
    static double const infinity = -::log(0.0);
    // Gleicht:
    static bool set = false;
    if(!set) {
        asm {
            fld 0.0
            call _Cllog
            fld -1.0
            fmul
            fstp qword ptr [infinity]
        }
        set = true;
    }
}

void foo() {
    double const infinity = -::log(0.0);
    // Gleicht:
   asm {
        fld 0.0
        call _Cllog
        fld -1.0
        fmul
        fstp qword ptr [infinity]
    }
}

/Oi bringt’s echt

Das alte Windows war so hässlich.

SO HÄSSLICH wie jetzt Windows Vista ohne Aero Desktop. Framezeiten hin oder her, ich vermisse eine halbwegs ansprechende UI.

Vermisse sie so sehr.

Windows’ Explorer ordnet allem, was die Dateinamenerweiterung .jpg hat, den Elementtyp JPEG-Bild zu.

Zeigt aber darunter die Abmessungen an, selbst, falls es sich tatsächlich um einen anderen Bildtyp handelt. So ein Scheiß.

Am geilsten ist Marmalade: Das ist ein SDK, was seinen Nutzer von der unterliegenden Platform unabhängig macht oder zumindest das tun sollte, aber je nachdem, ob ich für X86 oder ARM baue, nutzt es entweder die Windows- oder die Ansi-Variante der Format Specifier...

Artificial Mind hat geschrieben:Glew ist ein Drecksverein: benutzen seit Ewigkeiten glGetString(GL_EXTENSIONS) obwohl es seit OGL 3.1 removed ist ...

Also glew neukompiliert als C++ Projekt und intern das Problem gefixt...

Wenn ich nicht ganz falsch liege, ist GLEW ein OpenSource Projekt. Was hindert dich daran mitzuarbeiten und deinen Fix upstream zu bringen, damit sich andere Leute nicht mehr drüber ärgern müssen?

Wieso wird OpenSource oft als "da haben sich andere drum zu kümmern, die haben schließlich das Projekt gegründet" verstanden?

Weil es mindestens seit einem Jahr 3 pending Patches gibt, die alle auf verschiedene Art und Weise genau diesen Bug, der mindestens schon genauso lange bekannt ist, beheben wollen - und noch keiner wurde eingebaut.

EDIT: und mein Patch "upgraded" glew auf C++ und wird deswegen sicher nicht akzeptiert, mal davon abgesehen, dass er relativ quick'n'dirty ist. (Tut halt seinen Dienst)

Für heute morgen war endlich mal die Ordnung der Rechnungen und des Papierkrams und die erste Umsatzsteuer-Voranmeldung geplant. Nun ist der Morgen vorbei und ich habe die Zeit mit der Suche nach meinen Aktendullis* verbracht. Verdammt, so groß ist die Wohnung doch gar nicht!

*Für Westdeutsche: Heftstreifen. Den Begriff habe ich grad erst ergoogelt.

Und weitergejammert: meine Festplatte stirbt. Ich glaube, ich habe genau das vor einer Weile schonmal hier geschrieben. Es kotzt mich an, dass ich mich immer und immer wieder mit diesem Thema beschäftigen muss. Die aktuelle 2TB-WesternDigital ist gerade mal ein Jahr alt geworden, da sterben jetzt die Sektoren in Serie und bei jedem Hochfahren rappelt Windows das ganze Dateisystem durch, sortiert zerstörte Dateien aus und fügte neue fehlerhafte Cluster zur Tabelle hinzu. Ich frage mich, wie groß die werden kann.

Und jetzt, da ich eine neue holen will, stellt sich heraus, dass seit einer Woche alle Festplatten das Dreifache kosten. Warum? Die Flut in Thailand. Es gibt nur noch zwei Festplatten-Hersteller auf der Welt: Seagate hat Samsungs Plattensparte gekauft, Western Digital die von Hitachi. Und beide Firmen haben nunmal mehr als die Hälfte ihrer Produktionsstätten in Thailand und sind gerade abgesoffen. Gerade jetzt, da ich eh schon unter dünner Geldbörse leide. So ein Mist.

- Windows unterstützt kein dynamisches Linken, aber GetProcAddress(0, 'fname') hilft ja
- In der wineconsole kann man nicht scrollen. Vor allem doof, wenn man die Fehlermeldungen lesen will
[Edit:] - Windows kennt die Pipe (|) nur in Verbindung mit more. Alles andere funktioniert einfach nicht