Jammer-Thread

[eXile]

Vorneweg: Ich bin aktiver Benutzer eines eignen, privaten Git-Servers und eines Git-Servers in der Uni (und nein, ich benutze täglich ausschließlich Windows). Die Codebasis hier hat mehrere Branches und einige Merges. Ich habe sogar einmal an einen Branch genommen, und allen Commits eine ganze Reihe neuer Commits vorangestellt; so ganz vertrottelt werde ich wohl nicht sein.

Trotzdem ist jede größere Aktion in git meiner Meinung nach noch immer ein ziemlicher Krampf. Es gab einen einzigen Grund zwei Gründe, weshalb ich überhaupt git genommen habe: Wegen der besseren Branch-Verwaltung im Vergleich zu SVN, und der Möglichkeit, auch unterwegs ins lokale Repository zu committen. Aber alleine, dass ich keine leeren Verzeichnisse dort reinstellen kann, finde ich ziemlich nervig (und ja, jetzt kommt bestimmt wieder einer, der sagt, ich kann ja beliebige Informationsentitäten, und das sind hier Dateien, damit verwalten, daher haben leere Verzeichnisse damit nichts zu suchen; bitte nicht).

Nach dreimonatiger Benutzung kommt man damit dann auch halbwegs produktiv drin zurecht. Immerhin gibt es mittlerweile gute Unterstützung mit Kontextmenüerweitungern und Visual-Studio-Intergration. In diesem Sinne:

[youtube]CDeG4S-mJts[/youtube]

[antisteo]

Trotzdem ist jede größere Aktion in git meiner Meinung nach noch immer ein ziemlicher Krampf.

Korrekt.

Es gab einen einzigen Grund zwei Gründe, weshalb ich überhaupt git genommen habe: Wegen der besseren Branch-Verwaltung im Vergleich zu SVN, und der Möglichkeit, auch unterwegs ins lokale Repository zu committen.

Okay, das kann Mercurial auch. Außerdem hat Mercurial eine stabile History, ist weniger komplex und es gibt gute Anleitungen wie GermanUnderstandingMercurial. Warum nimmst du also Git?

Aber alleine, dass ich keine leeren Verzeichnisse dort reinstellen kann, finde ich ziemlich nervig (und ja, jetzt kommt bestimmt wieder einer, der sagt, ich kann ja beliebige Informationsentitäten, und das sind hier Dateien, damit verwalten, daher haben leere Verzeichnisse damit nichts zu suchen;

Dass man sowohl in Git als auch Mercurial keine leeren Verzeichnisse haben kann, nervt ein bisschen, das stimmt. Ich helfe mir dann mit einer Dummy-Datei.

bitte nicht).

Hier stimme ich auch den meisten Punkten vorbehaltlos zu. Die meisten Probleme hat ebenfalls Mercurial nicht.

Ich bin persönlich Mercurial-Fan einfach deshalb, weil es gute Dokumentation für HG gibt und das System nicht zu komplex ist. Git wäre aber das nächste Versionskontrollsystem, auf das ich umsteigen würde.

[antisteo]

Das HDMI des Pandaboard funktioniert nur direkt am Bildschirm und nicht über den Switch.
Wenn ich aber den Bildschirm kurz direkt anstecke und dann den Switch wieder rein, klappt alles.

Dann ist es aber sinnlos, den Switch zu haben, weil ich ja trotzdem unter den Tisch kriechen muss.

[Krishty]

Bah, die ganzen Websites, die sich für Echtzeitanwendungen halten. Wi-der-lich. box.com ist schon schlimm und u.A. der festen Meinung, ich dürfe nur in einem einzigen Tab darin surfen. io9.com macht ununterbrochen irgendwas, und sobald mein Internet weg ist, sind auch alle offenen Tabs unbrauchbar. Trauriger Spitzenreiter ist aber Twitter – dort braucht Chrome 5 Sekunden, um ein Tab zu schließen; eine Zeit, in der mein Rechner die Fourier-Transformation von 50 Milliarden Werten berechnen könnte.

Wirklich unfassbar, was für minderbemittelte Mikroben heute die Säulen unserer Gesellschaft programmieren.

[Krishty]

Eingabeverarbeitung unter Windows.

Zuerst einmal sind WM_KEYDOWN und WM_KEYUP kaum zu gebrauchen, weil sie für manche Tasten asymmetrisch auftreten (z.B. bewirkt Drucken WM_PRINT gefolgt von WM_KEYUP). Das artet also schnell in ein Moloch von Ausnahmen aus.

Raw Input ist besser; dort wird man immer und über alle Tasten auf gleiche Art und Weise informiert. Allerdings wird das Verhalten auch hier inkonsistent, sobald zwischen Fenstern hin- und hergewechselt wird; und man muss sich immernoch um solche Sachen kümmern wie Tasten, die zu selten losgelassen werden. Außerdem ist es eine Qual, damit zu arbeiten, weil die Dokumentation unter aller Sau ist.

Mit Raw Input zu arbeiten bedeutet außerdem, dass man das Nachrichtenaufkommen der Anwendung mindestens verdoppelt. Es gibt zwar die Möglichkeit, WM_KEYDOWN, WM_MOUSEMOVE, usw (die werden wohl Legacy Windows Messages genannt) abzuschalten, aber das bewirkt (selbstverständlich und logisch – man hätte es aber trotzdem gern nochmal in der MSDN erwähnen können), dass die Standardbefehle wie Alt+F4 mit diesem Fenster nicht mehr funktionieren. Nicht einmal mehr Klicks auf X, weil Windows einfach alle Eingaben komplett zum Programmierer schmeißt.

Nachtrag: Die Richtung des Mausrads ist in Raw Input gegenüber WM_MOUSEWHEEL negiert. Nein wie süß von denen! Und exzellent dokumentiert!

Außerdem wird man mit Tastaturwiederholrate über eine gedrückte Taste informiert. Im Gegensatz zu den Legacy Messages gibt es dabei aber keinen Wiederholungszähler; man weiß also nie, wann sich die Taste tatsächlich von nicht gedrückt zu gedrückt geändert hat …

[glassbear]

ARGH. Da will ich mal Bugs reporten an verschiedene Projekte und alle wollen erstmal einen eigenen Account. Der muss dann jeweils aktiviert werden. Und Passwoerter vergeben. Und so weiter... Da dauert das reporten dann doppelt so lange wie Reproduzieren und Fix finden :evil:
Am besten sind dann noch Anti-Spam-Bestaetige-deine-Emailadresse-Sachen.

Warum muss jeder verfickte Bugtracker aus 20+ Feldern bestehen? Reichen nicht drei:

1) Subject
2) Description
3) optional: Email Address

So ganz ohne Registrierung mit einfach und so? Echt so schwer?? Oder werden uebereifrige Software Quality Manager nach der Anzahl an Feldern und wie sehr sie Leuten damit auf den Sack gehen bezahlt? Liest die Felder ueberhaupt jemand? NEIN!

Und wozu muss ich alle Library- & Paket -Versionen selber ermitteln? Sind wir hier in 1980, wo es keine Skripte fuer sowas gibt?

[glassbear]

Unsere IT installiert gerade automatisch Windows 7 Service Pack 1 x86 auf meinem x64 Laptop. Die Installation wird erzwungen. Hat gerade das Windows geschrottet.
Und ich soll doch jetzt bitte den Laptop nach Shanghai zu unserem Service Partner schicken fuer Reparaturen. In 6-8 Wochen hab ich den zurueck.


Chef kauft mir einen neuen Laptop :roll:

[Krishty]

Es geht los! Die Black Sparrow Press hat die erste meiner Kurzgeschichten zurückgeschickt.

(Lies: Mein erster VC-Bugreport dieses Jahres wurde kommentarlos auf gelöst als zurückgestellt geschaltet.)

Zwei zu gehen.

[Krishty]

Wo wir gerade bei Visual Studio sind: Ich hatte heute einen faszinierenden Bug mit treat warnings as errors. Die kurze Version ist: Kompiliert die Release-Versionen eurer Libs niemals damit!

Die erweiterte Version: Während der LTCG hat Visual C++ eine erweiterte Erreichbarkeitsanalyse durchgeführt, und kam zu dem Ergebnis, dass ein bestimmter Programmzweig nicht erreichbar ist. Das an sich war noch kein Fehler, aber eine Warnung. Weiterhin bestand dieser Programmzweig aus einem Funktionsaufruf, der geinlinet wurde. Und der bestand wiederum aus einem Funktionsaufruf, der ebenso geinlinet wurde. Der geinlinete Maschinentext stammte dabei aus der Bibliothek, die mit treat warnings as errors kompiliert war. Ihr merkt, worauf das hinausläuft: Durch das Inlining wanderte die Verantwortung vom einbindenden Projekt zum eingebundenen; und LTCG wurde aufgrund der Warnung abgebrochen, obwohl das Projekt überhaupt nicht mit treat warnings as errors kompiliert wurde, sondern nur die eingebundene Bibliothek!

Meine Experimente haben gezeigt, dass Microsoft die Warnung in diesem Fall eigentlich absichtlich deaktiviert. Durch fiese Umstände (Templates mit virtuellen Funktionen über drei Bibliotheken in 60k Zeilen) ist sie aber doch irgendwie durchgekommen; und wer nach warning c4702 ltcg googelt, sieht, dass das kein Einzelfall war. Das bedeutet: Ihr könnt beim Kompilieren eurer Bibliotheken garnicht wissen, was für Warnungen auftreten; weil sich das erst nach Anwendungsart, Macht der Optimierungen, und Fehler derer Implementierung entscheidet. In meinem Fall war es quasi unmöglich, alle Stellen zu finden, die eine Funktion aufrufen, die die Funktion mit der Warnung aufruft; und darauf jeweils eine manuelle Erreichbarkeitsanalyse durchzuführen. Dementsprechend fahrt ihr den Anwender der Bibliothek in die Scheiße, indem ihr mit /WX kompiliert.

[Schrompf]

Ich dagegen wünschte mir gerade eine Warnung.

Code: Alles auswählen

Bla* zeiger = MachSchon();
if( zeiger < 0 )
  TuWas();

Warum warnt mich da niemand? Wenigstens eine "Bei dem Datentyp ist die Bedingung immer true"-Warnung, die VS ja definitiv kann.

Hintergrund: AngelScript hat lange Zeit alle möglichen Daten per ID gehandhabt, mit -1 für "nicht existent". Neulich wurde aber nun die ID-Geschichte rausgebaut und jetzt arbeitet man mit Zeigern und mit 0 für "nicht existent". Und ich habe wohl eine Stelle übersehen, die ich beim Umbau hätte anpassen müssen.

[dot]

Die Bedingung ist nicht immer true, es handelt sich um unspecified behavior (§5.9/2)... ;)

[Schrompf]

Och menno! Jetzt werd mal nicht sachlich! Ich will da trotzdem eine Warnung.

[dot]

Versteh ich, nachdem ich grad festgestellt hab, dass MSVC da offenbar auch kein anderwertig dokumentiertes Verhalten hat, wär eine Warnung natürlich wünschenswert...

[antisteo]

Die Bedingung ist nicht immer true, es handelt sich um unspecified behavior (§5.9/2)... ;)

Dann soll halt eine Warnung wegen "unsecified behaviour" raus...


Hmmm, der GCC warnt mich auch nicht, allerdings optimiert er den Bedingungs-Körper raus

Edit:

Code: Alles auswählen

$ gcc test.c -Wextra
test.c: In function ‘main’:
test.c:6:6: warning: ordered comparison of pointer with integer zero [-Wextra]

[antisteo]

Ich mag die Entwicklung mit den Google Glasses nicht.

Bei so viel Komfort bietet sich ja förmlich an, einen Überwachungsstaat aufzubauen. Ich hab' ja schon mit dem DRM-System Android meine Probleme. Es wird immer schlimmer.

[Aramis]

Viel wichtiger: Ich bin davon ueberzeugt, dass Skynet plant, unsere Datenbrillen am Tag X ein paar nette Loecher in unsere Netzhaeute hineinlasern zu lassen.

[Krishty]

eine meiner Funktionen legt 40 MiB lokale Variablen an und jetzt verweigert mir Visual Studio den Call Stack darunter

ganz ehrlich: falls Skynet das besser schafft als die Menschheit, hat die sich ihre Augenlaser verdient

[Krishty]

Unglaublich, wozu mich Visual Studio wieder zwingt. See this shit?

    Count const numberOfVertices = myToNextVertex - begin(myVertexBatch);
    gpu->DrawPrimitiveUP(D3DPT_TRIANGLELIST, DWORD(numberOfVertices / 3u), begin(myVertexBatch), sizeof(Vertex));

STOP! Da werden zwei Zeiger subtrahiert und danach wird das Ergebnis durch 3 geteilt? Wir wissen doch ganz genau, dass Visual Studio die Division von Zeigerarithmetik nicht wegoptimiert! Also:

    Size const sizeOfVertices = reinterpret_cast<Byte const *>(myToNextVertex) - reinterpret_cast<Byte const *>(begin(myVertexBatch));
    gpu->DrawPrimitiveUP(D3DPT_TRIANGLELIST, DWORD(sizeOfVertices / (3u * sizeof(Vertex))), begin(myVertexBatch), sizeof(Vertex));

TADAAAAH, wieder was was gespart.

Übrigens ist es nicht immer katastrophal. Diese Zeigerarithmetik auf einem statischen Array etwa wird perfekt optimiert:

    if(myToNextVertex > end(myVertexBatch) - 3u) { // No room for another triangle?

Das evaluiert zu zwei lea und einem cmp jbe, wie es sich gehört. Aber kommt bloß nicht auf die Idee,

    if(end(myVertexBatch) - myToNextVertex < 3)

zu schreiben … also etwa size() bei einem std::vector<> aufzurufen …

[Krishty]

Warum gibt es kein do for each?! Hat denn kein Sprachentwickler dieser Welt Sinn für Zustand?

P.S.: do while ist sowieso total abgefuckt. Fucking Scope rules. Warum muss ich meine Iteratoren außerhalb der Schleife definieren?! Das läuft immer auf den alten VC6-Workaround mit dem Extrablock um alle Schleifen hinaus:

    {
        auto toCurrent = begin(range);
        auto toEnd = end(range);
        do {
            toCurrent->fuckThatSh*t(…);
        } while(toCurrent < toEnd);
    }

IGITT ICH BENUTZ NUR NOCH GOTO

warum nicht einfach

    do {
        current.fuckThatSh*t(…);
    } for(auto & current : range);


————

Wisst ihr, wie Visual C++ meine Matrizen kopiert?

    toJob->mat = matParameter;

wird zu

    mov rcx,qword ptr [matParameter]
    mov eax,dword ptr [rcx]
    mov dword ptr [rdx],eax
    mov eax,dword ptr [rcx+4]
    mov dword ptr [rdx+4],eax
    mov eax,dword ptr [rcx+8]
    mov dword ptr [rdx+8],eax
    mov eax,dword ptr [rcx+0Ch]
    mov dword ptr [rdx+0Ch],eax
    mov eax,dword ptr [rcx+10h]
    mov dword ptr [rdx+10h],eax
    mov eax,dword ptr [rcx+14h]
    mov dword ptr [rdx+14h],eax
    mov eax,dword ptr [rcx+18h]
    mov dword ptr [rdx+18h],eax
    mov eax,dword ptr [rcx+1Ch]
    mov dword ptr [rdx+1Ch],eax
    mov eax,dword ptr [rcx+20h]
    mov dword ptr [rdx+20h],eax
    mov eax,dword ptr [rcx+24h]
    mov dword ptr [rdx+24h],eax
    mov eax,dword ptr [rcx+28h]
    mov dword ptr [rdx+28h],eax
    mov eax,dword ptr [rcx+2Ch]
    mov dword ptr [rdx+2Ch],eax

WOLLT IHR MICH VERARSCHEN

Oh und memcpy() hinschreiben geht nicht, weil das nicht inline kompiliert wird (!!!) … warum kopiert der meine floats durch Integer-Register? Warum benutzt der 32-Bit-Register statt 64ern oder 128ern? Warum nicht durch drei movups alles in einem Takt kopieren? Ich will nicht mehr

[CodingCat]

IGITT ICH BENUTZ NUR NOCH GOTO

warum nicht einfach

    do {
        current.fuckThatSh*t(…);
    } for(auto & current : range);

Weil das zu großem Unfug einladen würde. Ich verstehe zwar, dass die Machtlosigkeit, den Compiler anderweitig zur Generierung vergleichbaren Maschinentextes zu bewegen, in höchstem Maße frustrierend ist; auf Sprachebene ergibt das Konstrukt dennoch keinen Sinn.

[Krishty]

Kleiner Nachtrag zu dem mov-Wahnsinn oben: 32-Bit-mov nullt die oberen Bits des angesprochenen 64-Bit-Registers, und das gilt als Dependency Breaking. Wird von Intel sogar explizit empfohlen:

Assembly/Compiler Coding Rule 37. (M impact, MH generality) Break dependences on portions of registers between instructions by operating on 32-bit registers instead of partial registers. For moves, this can be accomplished with 32-bit moves or by using MOVZX.

Durch das Register Windowing wird die Kopie wahrscheinlich auch auf CPU-Ebene parallelisiert.

128-Bit-movaps wird nicht verwendet weil die Daten nicht ausgerichtet im Speicher liegen. Seit einer oder zwei CPU-Generationen kann man movups mit derselben Leistung verwenden; früher war es aber deutlich langsamer, und deshalb wird es wohl immernoch gemieden.

Bleibt die Frage: Warum keine 64-Bit-Schritte?

[Krishty]

Klassenname des Tages: CD3DDDIDX10 (aus ddd3ddd9.dddll)

[CodingCat]

Ich weiß schon, warum ich mich um Texturen bis Dato so gerne gedrückt habe.

Wer will denn bitte Texturen für jedes Objekt einzeln malen? :| Und wie groß wird der Spaß erst mit Tessellation.

[Krishty]

Was (welche Stellen im Schnappschuss) genau meinst du?

[CodingCat]

Alle harten Kanten eigentlich. Einen Teil kriegt man natürlich gut kaschiert, so sollte man z.B. den Rand der Plattform einfach zu einer Art Fassung umgestalten, die dann überhaupt nicht mit der Oberfläche der Plattform zusammenpassen muss; Böden hängen ohnehin selten einfach so im Raum. Am meisten Sorgen bereiten mir immer noch Steinmauern, die aus mehr als einer Richtung betrachtbar sind. Jetzt wo ich darüber nachdenke, würde man den Fenstern vermutlich auch einfach Rahmen verpassen, sodass der Sprung hier keine Rolle mehr spielt. Eventuell bleiben am Ende tatsächlich "nur" freistehende Mauern als Sorgenkinder übrig. Hier bleibt das Problem jedoch bestehen: Wie möglichst effizient eine zusammenhängende Oberflächenstruktur erreichen?

[Krishty]

3D-Texturen mit Entfernungs- und Displacement-Vektor-Feldern drin.

[mnemonix]

Hm, ich kenne mich da zwar noch nicht ganz so gut aus, weil ich es noch nie ausprobiert habe, aber Tri-planar Texturing (siehe auch GPU Gems 3 - Abschnitt 1.5) klingt doch dafür sehr interessant.

[Artificial Mind]

Das macht man nur mit einigermaßen stochastischen/strukturlosen Texturen. Bei Steinen versagt es jämmerlich ;)

[mnemonix]

Ein Versuch war es wert. :D Jetzt bin ich auch schlauer.

[CodingCat]

Mein aktueller Plan (insbesondere für Displacement Mapping) sieht nun folgendes vor: Mit normalen "seamless" Textures lässt sich auf den vertikalen Flächen schonmal ein (zylindrisch) zusammenhängendes Ergebnis erreichen. Der Fall, dass man von oben/unten auf eine Mauer schaut, erscheint mir deutlich seltener als der, dass man von verschiedenen Seiten draufschaut. Schaut man doch mal von oben, gibt es zwei Fälle: Entweder die Mauer ist von der Seitenansicht nach oben abgeschlossen; i.d.F. kann man von oben eigentlich draufpacken was man will. Oder Steine gucken raus, i.d.F. braucht man oben wohl eine zur Seitentextur passende Extratextur.

Zu Displacement: Damit an den scharfen Objektkanten keine Löcher in der Geometrie entstehen, fällt mir momentan nur ein, die scharfen Kanten durch schmale abgerundete (mit interpolierter Normale) zu ersetzen. In der Natur ist ohnehin keine Kante wirklich scharf, insofern tut das dem Realismus keinen Abbruch. So wären Unstetigkeiten in den Oberflächennormalen beseitig, ohne dass man auf umständlich durchgereichte Adjazenzinformationen zurückgreifen muss. Ob dieses Vorgehen in der Praxis funktioniert, wird sich zeigen.