ZFX + Developia

http://www.spiegel.de/netzwelt/games/ca ... 77519.html

Für Dick-Fans ist das Spiel ein Fest.

Dick-Fans

m[

bzw.

heutzutage gibt es dafür ja Emojis. Aber den kann ich hier nicht einfügen, weil dann ein SQL-Fehler auftritt. Wann wird die Forum-Software drauf umgestellt?

Jonathan hat geschrieben:Mit Qt5 kann man anscheinend keine OpenGL Function Loader mehr in der selben Datei wie ein QGlWidget benutzen. Nun ist aber mein Framework ein relativ flaches, das OpenGL nicht komplett wegkapselt und halt leider auch in den Header OpenGL Funktionen nach außen exportiert. Sprich ich muss jetzt meine Anwendungen umschreiben und zusätzliche Klassen einfügen damit nicht in einer Datei meine eigenen und die Qt Header von OpenGL eingebunden werden.

C++ ist einfach nur so kaputt. Scheiß Header.

Da kann ich dir helfen!
Du kannst einfach manuell den Header Guard von der qopenglfunctions.h definieren. NIEMAND nutzt diese scheiß Funktionen, nicht mal Qt. Also einfach den Header ausblenden :)

Installation Word Viewer + PowerPoint Viewer + Excel Viewer: 158 MiB

Sicherheitsupdates Word Viewer + PowerPoint Viewer + Excel Viewer: 164,3 MiB

ach, Microsoft

Das einzige, was sie nicht ersetzt zu haben scheinen, sind die Strings. Der Word Viewer behauptet nämlich hartnäckig, er wäre die 2003er Version, obwohl ich 2007 installiert habe.

Genau so behauptet auch mein Visual Studio, es sei 2015 ohne Update 1, obwohl ich mit installiert habe. Und wenn ich die Installation neu starte, sagt er mir, ich könne kein altes Produkt über ein neueres installieren.

Mein Rechner hat übrigens vorgestern 16 Stunden lang Updates gesucht, und gestern über zwölf.

Ein ganz erfülltes Leben habe ich hier!

Kein Kommentar -.-

https://support.microsoft.com/en-us/kb/3035583

Die sind ja echt beharrlich. Wäre sogar bewundernswert, wenn es nicht so eine gottverdammte Unverschämtheit wäre.

Das wurde aber doch schon vor zwei oder drei Monaten verteilt, oder? Bin sicher, dass ich es schon ausgeblendet habe.

Du hast recht; das ist eine Februar-2016-Version. fuckdisshit.png

Wo wir gerade beim Thema sind: der OpenGL Vulkan-Treiber, den nVidia über Windows Update verteilt, lässt sich nicht installieren (Fehler 0x800schlagmichtot). Ich musste das händisch machen. Meh.

Manchmal verketten sich Bedingungen, so dass man am Ende in selbstgewähltem Elend endet.

Mein Voxel-Scheiß muss aller weniger Meter Kamerabewegung ein paar dutzend Meshes neu generieren. Das hackt aktuell ziemlich heftig, weswegen ich es parallelisieren will. Und das ist ein Job für mein Angeblich-Funky-Fiber-System. Das baut auf Boost.Context auf, was ne plattform-übergreifende minimale Implementation von User Space Threads ist. Ich baue Boost jetzt selbst, weil die fertig gebauten Libs so hochempfindlich gegenüber jeder Compiler-Einstellungsabweichung sind, dass man sich alle möglichen Crashes eintritt und die auch gern mal nur auf 5% der Kundenrechner auftreten. Also muss ich auch Boost.Context selbst bauen. Und da Fibers ziemlich tiefe Eingriffe in die Stack Frames sind, muss man die in Assembler schreiben. Also muss ich in meinem Boost-Build ein paar Assembler Files mitbauen. Visual Studio 2015 hat aber keinen Builtin-Support für Assembler mehr. Und für x64 gab's den eh noch nie. Also muss ich einen manuellen Build-Schritt mit ml/ml64 aufsetzen. Und der scheitert nicht nur an dem meiner Meinung nach korrekten Assembler-File - nein, die Fehlermeldungen sind in der Ausgabe überschrieben. Das liest sich dann so:
Besonderer Hingucker: die letzte Fehlermeldung ist so kurz, dass der überschreibende Buffer gar nicht vollständig ausgegeben wird. Man kann nur spekulieren, was für Puffermagie da abläuft, aber da waren echt Profis am Werk.

Hehe, kenne ich. Nebenläufige Kompilierung abschalten oder Datei einzeln kompilieren (Rechtsklick im Solution Explorer -> Compile), dann geht’s.

Assembler hinzufügen ist eigentlich kein Problem (auch unter x64 nicht); ich vergesse nur bei jedem Projekt auf’s neue, wie es geht …

P.S.: Darum mache ich alles selber. Seit zwei Jahren lässt mein Jammern hier stetig nach, weil ich nur noch mich selber anschwärzen kann, wenn was kaputt ist.

Ne, die Asm-Datei einzeln kompilieren hat auch nix gebracht. Würde mich auch wundern. Ich hab jetzt aber mal ne längliche Mail an die Boost-MailingList geschrieben. Zumindest der Author von Boost.Context ist da sehr aktiv und ziemlich bemüht, guten Support zu liefern.

Seine anderen Libs, die auf Boost.Context aufbauen, sind dann aber wieder ein Prachtbeispiel dafür, warum niemand mehr Boost ernsthaft benutzen will - ein akademisches Gefrickel mit type_traits und gigantischer Template-Wüste, und die mitgelieferten Code-Beispiele machen nicht etwa ne simple nachvollziehbare Yield-Schleife, sondern implementieren nen Parser mit so heldenhaften Codezeilen wie return some_type<void (int)>::type_traits::return_type(...), was eigentlich nur getch() heißen sollte. Aber da kommt mein Gemecker zu spät, wie ich gerade lese - inzwischen sind die Beispiele dafür *etwas* bodenständiger.

Mit einzelner Kompilierung sollten nur die Meldungen lesbar werden; nicht die Fehler verschwinden. Sorry :)

Nein, diese Art von Pufferüberschreiber ist anscheinend fest eingebaut :)

Artificial Mind hat geschrieben:

Jonathan hat geschrieben:Mit Qt5 kann man anscheinend keine OpenGL Function Loader mehr in der selben Datei wie ein QGlWidget benutzen. Nun ist aber mein Framework ein relativ flaches, das OpenGL nicht komplett wegkapselt und halt leider auch in den Header OpenGL Funktionen nach außen exportiert. Sprich ich muss jetzt meine Anwendungen umschreiben und zusätzliche Klassen einfügen damit nicht in einer Datei meine eigenen und die Qt Header von OpenGL eingebunden werden.

C++ ist einfach nur so kaputt. Scheiß Header.

Da kann ich dir helfen!
Du kannst einfach manuell den Header Guard von der qopenglfunctions.h definieren. NIEMAND nutzt diese scheiß Funktionen, nicht mal Qt. Also einfach den Header ausblenden :)

Zu spät, mittlerweile habe ich allen Render-Code in eine eigene Klasse ausgelagert, die nix mehr mit Qt zu tun hat.

Aaaaallerdings ist immer noch alles doof. Mein Render-Code stürzt ab, sobald ich irgendetwas nicht-triviales mache. Ich habe jetzt versucht, bei Widget-Erstellen die GL-Version anzupassen, wenn ich da etwas falsch mache, kompilieren meine Shader zumindest nicht mehr, was für mich so viel heißt, wie dass es doch irgendwie zusammenhängt. Allerdings ist ja OpenGL sowas von veraltet, dass man nie wissen kann, was hinter all den Funktionszeiger jetzt eigentlich im Hintergrund passiert. Und jetzt lese ich auch noch, dass das Qt-Widget alles in einen Frame-Buffer rendern will und ich kein 0er Framebuffer mehr binden darf - ich soll also meinen Render-Code umschreiben, weil Qt das jetzt nunmal alles anders haben will. Auf eine diffuse Art, die ich noch nicht verstehe, und deren Missachtung in Abstürzen resultiert. Total motivierend und so.

Aber was mich an der ganzen Sache eigentlich so richtig frustriert ist, dass es so unglaublich unproduktiv ist. Da wurschtelt man abendelang an seinem Code und hat am Ende eine pupsige Qt-Anwendung, die ein Modell rendert. Such Fame! Much Glory! So Wow!
Und dabei benutzt das neue Qt immer noch für jeden Quatsch seine eigenen Klassen. Ich weiß gar nicht mehr, warum ich überhaupt auf die neue Version umsteigen wollte....

Heute ist wieder so ein Tag, an dem ich am liebsten die Welt niederbrennen würde...

Nachdem ich einige Tage zu genervt war, irgendetwas zu programmieren, habe ich mich heute nochmal an meinen OpenGL-Absturz gesetzt (s.o.). Und ihn gelöst. Des Rätsels Lösung: Eine ungünstige Kombination mehrerer Umstände.

Wie gesagt, ich habe meinen alten Render-Code in eine neue Qt-Anwendung gepackt. Jetzt lade ich also ein Modell, und es stürzt ab. Zugriffsverletzung, mal wieder auf einer Ebene wo der Debugger nutzlos ist und einem einfach gar nichts anzeigt. Durch manuelles Durchsteppen kam ich aber schnell zur Stelle: Ein glDrawElements-Aufruf. Das ist eine OpenGL-Funktion, und die dürfen nicht einfach so abstürzen, sondern müssen irgendeinen vernünftigen Fehler produzieren, und anzunehmen, dass meine OpenGL Implementierung dahingehend kaputt ist, wäre vermessen. Naheliegend ist also, dass diese Funktionszeiger wieder kaputt sind, also irgendwelche OpenGL-Extensions falsch geladen sind. Wie gesagt, Qt hatte da was verändert, gut möglich, dass irgendetwas inkompatibel ist.
Das war es aber nicht, die Funktionszeiger sind ok. Und eine Menge anderer OpenGL-Kram funktionierte ja auch. Nun, die nächste Spur ist, dass glDrawElements mehrdeutig ist: Man kann damit entweder direkt Daten aus dem Hauptspeicher rendern, indem man einen Zeiger übergibt, oooder man benutzt Vertex-Array-Objects um die Daten auf der Grafikakrte zu halten, und übergibt in dem Falle einen Null-Zeiger. Jetzt stellte sich heraus, dass mein VAO irgendwie kaputt ist, OpenGL denkt, ich würde keines benutzen und meinen Null-Zeiger dereferenziert, weil da ja meine Daten liegen, die ich rendern will (nicht). Also ist der Absturz vollkommen gerechtfertigt.
An dieser Stelle sollte ich vielleicht erwähnen, dass mir nSight auch nicht weiterhelfen konnte, weil es nur manchmal funktioniert. Es ist also nicht nur OpenGL vollkommen kaputt, es gibt auch keinen zuverlässigen Debugger dafür.
Mehr durch zufall (weil ich testweise Text gerendert hatte und das funktionierte) kam ich auf die entscheidende Idee: Während dem Modell-Laden (irgendein GUI-Event) ist mein OpenGL Context nicht der aktuelle (welcher denn dann? Hab doch nur einen?), also ist das VAO hinterher beim Rendern kaputt. Problem gelöst.

Was mich daran so wahnsinnig aufregt, ist dass das alles nur passiert ist, weil mehrere furchtbar schlechte Designentscheidungen zusammen gekommen sind. Fassen wir also noch einmal zusammen, was alles so schlimm ist:
- OpenGL Funktionszeiger
- das Funktionen wie glDrawElements je nach globalem Zustand Parametern eine vollkommen andere Bedeutung geben
- OpenGL Contexte. Meine Güte.

Und genau deswegen will ich alles niederbrennen. Weil das alles nur passiert ist, weil hundert Jahre alte Programmiermodelle benutzt werden. Es ist absolut möglich Programmiersprache zu haben, in denen solche Fehler einfach unmöglich passieren können. Weil der Compiler sie schon erkennt und eine vernünftige Fehlermeldung generiert. Aber nein, wir müssen ja immer noch irgendeinen C-Scheiß benutzen mit globalen Zustanden, und Funktionen die ständig irgendetwas machen. Weil man bequem ist und nix ändern will und gerade noch eine kleine Anpassung macht anstatt es vernünftig neu aufzusetzen und das dann 30 Jahre am Stück macht und dann sowas wie das aktuelle OpenGL dabei herauskommt.

Ja OpenGL ist und war immer schon ein furchtbarer Misthaufen. Ich kann fast nicht glauben, dass ich jemals zu diesem Punkt kommen sollte, aber zur Verteidigung der restlichen Welt sollte gesagt werden, dass das Design von OpenGL aus irgendeinem Grund wirklich außerordentlich mehr kaputt ist, als deine durchschnittliche API (zumindest wenn wir mal an die wirklich wichtigen APIs da draußen denken)...

Vor zehn Jahren waren die Joint Strike Fighter Air Vehicle Coding Standards einer der vorherrschenden C++-Style-Guides, neben Googles. (Jedenfalls in meinem Umfeld.)

JSF brachte die F-35 hervor; das aktuelle Mehrzweckkampfflugzeug der USA. Wow! C++ statt COBOL in einem Kampfflugzeug? So richtig mit Klassen und Vererbung und virtuellen Funktionen und Konstruktoren und Destruktoren? Total OOP? (Aber ohne Exceptions, weil ihre Compiler das nicht können …)

*nach heute vorspul*

Die F-35 ist das so ziemlich größte finanzielle Desaster, mit dem sich das Pentagon aktuell herumplagen muss. Der Zeitplan musste x-Mal verschoben worden, die Konstruktionspläne wurden von chinesischen Hackern geklaut … und ein großes Sorgenkind ist die Software. Habe eben in einer Fachzeitschrift gelesen, dass die Sensordaten regelmäßig überlaufen (zu wenig Rechenleistung) und dann etliche Subsysteme abstürzen. Nach mittlerweile zwei Patches tritt dieses Problem noch immer alle vier Stunden auf m[

Da hätten sie auch gleich C# nehmen können!

Man sollte alle Hard- und Software dieser Welt in einem riesengroßen apokalyptischen Feuer verbrennen. Dann wird jeder Programmierer gezwungen folgende Anzahl an Sekunden seine Hände in die Glut zu stecken: [Anzahl der von ihm verursachten Bugs] * [Anzahl der betroffenen User]... Anlass meiner Weltuntergangsträume: a) die statische IP-Verwaltung der Fritzbox: statische IP am Handy "*.203" -> Fritzbox "immer selbe IP" -> DHCP am Handy -> IP: ".22"... Würde dem verantwortlichen Entwickler gerne die Hände abhacken. b) Windows 7: Standardprogram auswählen -> Durchsuchen -> exe auswählen -> von Windows ignoriert und verarscht werden... beide Hände des verantwortlichen AB!!!

Was die Standardprogramme in Windows10 angeht, ist das ein bisschen schlimm geworden. Da poppt regelmäßig ein Fenster auf: "diese App weiterhin verwenden?". Und ich denk mir so: klar, deswegen habe ich sie eingestellt.

*Wahrscheinlich* ist das ein Versuch von MS, dem Nutzer die neuen Möglichkeiten anzubieten, wenn ein neues Programm installiert wurde, dass irgendwie vermittelt, es könne mit diesem Dateityp umgehen. In der Praxis wirkt das aber wie ein weiterer Bettelzug von MS für ihren dämlichen AppStore.

https://support.microsoft.com/de-de/kb/2952664

Dieses Update führt Diagnosen auf Windows-Systemen durch, die am Windows Customer Experience Improvement-Programm teilnehmen. Diese Diagnose hilft festzustellen, ob Kompatibilitätsprobleme auftreten können, wenn das neueste Windows-Betriebssystem installiert ist. Dieses Update hilft Microsoft und seinen Partnern Kompatibilität für Kunden sicherzustellen, die das neueste Windows-Betriebssystem installieren möchten.

https://support.microsoft.com/de-de/kb/3138612

Dieses Update enthält die Windows Update-Client in Windows 7 SP1 und Windows Server 2008 R2 SP1 verbessern.

-------------------------------------------------------------

Update und Verbessern. Du mich auch. Aber schon dreist. Von Windows 10 steht da nun nichts mehr ...

Facebook unterstützt leider seit einer Weile kein XMPP mehr. Damit funktionieren so nette Progrämmchen wie Xabber unter Android nicht mehr mit dem Facebook Chat. Für den Desktop gibt es für Pidgin mit purple-facebook ein funktionierendes Plugin mit nativem Facebook Protokoll. Kennt zufällig jemand eine Alternative zum Facebook Messenger für Android? (Weigere mich seit die Facebook App keinen Chat mehr unterstützt aus Prinzip das Zeug von denen zu installieren)

• Drittbibliothek
• schreibt ihre Daten via std::ostream
• liest ihre Daten via std::istream
• „Geil, das ist ja ein sauberes und einfaches Interface!“
• bis … Laden funktioniert nicht
• daswirdeinelangenacht.jpg
• Stream ist okay, alle Daten sind okay, Funktionen sehen richtig aus
• Google Groups hilft
• „Versionsnummer via iword() mitgeben“

std::ios_base::iword()

First, allocates or resizes the private storage (dynamic array of long or another indexable data structure) sufficiently to make index a valid index, then returns a reference to the long element of the private storage with the index index.

Für die Liebe von Gott, warum?! Was hat eine komplette Property-Registry-Implementierung in der Basisklasse für I/O-Streams zu suchen?! Und wer benutzt so einen Dreck auch noch?!

@Tiles: 2952664 ist Bullshit; stimmt & danke dafür! Aber 3138612? Könnte doch genau so gut ein Bugfix sein, oder?

Tja, wenn man das halt wüsste. Das Update ist jedenfalls kein wichtiges, sondern "nur" ein empfohlenes ^^

Hab’s installiert, und kein Windows 10 in Sicht.

Mich würde trotzdem interessieren, warum sie den Client jetzt monatlich austauschen.

Ach, C++. Alle Monate auf’s Neue probiere ich eines dieser schicken neuen Features aus und alles brennt nieder. Heute: constexpr.

  Angle4B angleFromDegrees(int degrees) {
    assert(0 <= degrees && degrees <= 359);
    return { unsigned(degrees) * 11930465 }; // * 2³² / 360
  }

*constexpr davorschreib*

  error C3249: illegal statement or sub-expression for 'constexpr' function

Ach so, ich darf da kein assert() benutzen. Außer durch ein Template, das die Bedingung als Lambda an einen constexpr-Wrapper weiterleitet. Stimmt ja.

Dann mal was Leichteres:

  __m128 xxxxFrom(float x) {
      return _mm_set_ps(x, x, x, x);
  }

*kompilier*

  error C3249: illegal statement or sub-expression for 'constexpr' function

Ach so, Intrinsics sind nicht constexpr. Ich kann das also in allen Funktionen vergessen, die irgendwas mit Vektoren machen oder int und float konvertieren oder mathematische Funktionen nutzen. Ich vergaß.

Dann tschüss, constexpr, bis zum nächsten Standard! Danke für die Zeitverschwendung!

errno ist das Problem. In GCC sind sie trotzdem alle constexpr :?

Nicht nur das – Mathefunktionen sind auch noch abhängig vom Rounding Mode :( Können wir mit Software bitte nochmal neu anfangen?

Visual C++ 2015 hat /DEBUG:FASTLINK als Standard eingeführt. Damit geht aber SymGetLineFromAddr64() nicht mehr, bzw weitaus schlimmer -- stürzt manchmal mit Zugriffsverletzung ab. Ich nutze es nur, um meine Assertions aufzufrischen; aber falls das jemand in ausgeliefertem Code hat: seid auf der Hut.

Oh, guter Hinweis. Mir kommt da gerade ein finsterer Verdacht.

Hatte geplant, auf ein Roger Cicero Konzert zu gehen...

Ja, das kam echt unerwartet :(

————

Eben aus China zurück. Dort sind alle Google-Dienste zensiert (z.B. YouTube), aber auch viele Image-Hoster (wie mein gebliebtes abload.de). Konnte deshalb von euren Projekten kaum was sehen und muss jetzt alles nochmal lesen.

Warum nutzt ihr so selten die Bildanhang-Funktion? Weil sie nicht so hübsch ist wie [img]-Tags? Da könnten wir sicher Abhilfe schaffen. Weil die Dateigröße oder Bildanzahl limitiert ist? Lässt sich alles einstellen …