ZFX + Developia

Schönes Problem, das Thunderbird mit dem letzten GUI-Refactoring eingeführt hat: Es werden nicht nur markierte Nachrichten gelöscht, sondern auch fokussierte. Beispiel: Drei Nachrichten

1. ◯ Spam
2. ◯ Antwort auf eure Bewerbung
3. ◯ Spam

Ihr markiert alle drei via Strg+A, oder durch Rechteckauswahl, wie auch immer:

1. ⬤ Spam
2. ⬤ Antwort auf eure Bewerbung
3. ⬤ Spam

Dann entfernt ihr die mittlere Nachricht aus der Auswahl, indem ihr Strg gedrückt haltet und draufklickt:

1. ⬤ Spam
2. ◯ Antwort auf eure Bewerbung
3. ⬤ Spam

Wenn ihr jetzt Del drückt, welche Nachrichten werden gelöscht?

Alle drei. 1+3 weil sie ausgewählt sind, und 2 weil noch der Fokus drauf ist (auf die hattet ihr ja zuletzt geklickt).

Das ist definitiv NICHT das Verhalten, das ich gewohnt bin …

Ich kenne keine Anwendung, die das so macht. Sicher, dass das nicht einfach ein Bug ist?

Das ist ja gerade mein Punkt – die GUI hat 20 Jahre funktioniert, aber sie müssen ständig was ändern, und machen dabei dauernd was kaputt.

Auch lustig: Das neue Design von Visual Studio geht wieder Richtung XP/Vista. Besonders deutlich an den Tabs. War wohl doch nicht so toll ohne Rahmen?!

Nagt Thunderbird an mir nach Spenden. Google ich mal kurz, geht ihnen eigentlich gut. Aber ich will ja auch, dass es solche Tools weiter gibt, also will ich ihnen spenden. Zahlungsabwicklung über Paypal war stressarm, aber dann wollen sie von mir Namen und Mailadresse. Und es muss eine gültige Mailadresse sein.

Warum? Ist mein Geld allein nicht gut genug? Tja.

Vielleicht irgendwelche Scheinmaßnahmen gegen Geldwäsche und so?

Division und Right-Shift sind in C/C++ für negative Zahlen unterschiedlich … gets me every fucking time

Oh, ja, stimmt! :-D Binär ergibt's Sinn, aber mei... technisches Detail #3482659, dass man im Kopf haben muss.

Ist Right Shift auf Signed Ints nicht Undefined Behaviour?

Schrompf hat geschrieben: ↑03.12.2023, 23:46Ist Right Shift auf Signed Ints nicht Undefined Behaviour?

Früher war es implementation defined, seit C++20 ist es wohldefiniert.

Heisst das, dass bei C++20 bei einem Right Shift auf eine negative Zahl (Zweierkomplement) jetzt in jedem Fall eine 1 nachgeschoben wird?
Wie siehts bei C23 aus? Hat man das ebenfalls von implementation defined auf 0 bei positiv und 1 bei negativ abgeändert?

Es gibt in Assembler verschiedene Shift-Arten. Bei Arithmetic Shift Right bleibt das oberste Bit erhalten und das 2.höchste Bit bekommt trotzdem das höchste Bit. Macht auch Sinn, zumindest war das beim 68000er so. C++ gibt das nur in Assembler weiter.

LLVM mag neuerdings keine getyppten pointer mehr. Als ob einem das Typsystem in der Vergangenheit nicht dabei geholfen hätte funktionierende Backends zu implementieren. Zugegeben braucht man da jenachdem was man will, eigentlich polymorphe, monomorphe oder ungetyppte pointer. Sie gleich komplett überall rauszuschießen wirkt aber wirklich nicht hilfreich. Kann mir auch nicht vorstellen, dass sich das gut auf die Performance auswirkt. Weder Compilezeit noch Laufzeit, wenn man voll optimieren will.
Aber dafür sind jetzt die Release notes übersichtlicher und gut erklärt.

Hat Apple das Projekt aufgegeben? Frage ich mich gerade ganz im Ernst. Dachte das ist die Grundlage von Swift und das die Grundlage von deren Software.

Lord Delvin hat geschrieben: ↑09.12.2023, 18:08 Kann mir auch nicht vorstellen, dass sich das gut auf die Performance auswirkt. Weder Compilezeit noch Laufzeit, wenn man voll optimieren will.

Meinem Verständnis nach waren die Typen von Pointern auf LLVM IR Ebene schon seit langem nicht (nie?) für Optimierungen nutzbar. Und Typechecking ist etwas, was eh das Frontend schon besser macht. Was für den Optimizer wirklich interessant ist, ist zu wissen ob und wo welche Pointer aliasen oder nicht. Und das wird nicht über Typen sondern über andere Metadata gehandled. Von daher seh ich eigentlich nicht, was hier das Problem sein sollte. Wenn überhaupt, sollte die Performance davon profitieren, dass nutzlose Komplexität losgeworden wird. Der Artikel erklärt es auch:

LLVM IR pointers can be cast back and forth between pointers with different pointee types. The pointee type does not necessarily represent the actual underlying type in memory. In other words, the pointee type carries no real semantics.

[…], the community realized that pointee types were more of a hindrance for LLVM development and that the extra type checking with some frontends wasn’t worth it.

Also im Kern kann ich den Gedanken nachvollziehen, dass man lieber TBAA macht, als dafür das LLVM-Typsystem mit Zeigeranalysen zu kombinieren. Mein Problem damit ist, dass man das a) machen muss und b) die Abstraktion in TBAA zu dem passen muss, was die Quellsprache an Typtheorie hat. Ich habe im Kopf mir das mal für Tyr angeschaut zu haben und ich habe momentan keine Implementierung dafür, woraus ich schließe, dass es zumindest damals nicht zusammen gepasst hat. Vermutlich weil meine OOP-RTTI-Implementierung von dem was C++ macht sehr weit weg ist. Vermutlich muss ich mir in ein-zwei Jahren nochmal anschauen, wie da der Stand ist und das dann nochmal bewerten. Bin ehrlich gesagt gerade zu müde das qualifiziert zu bewerten. Was ich mich aber frage ist, was passiert wenn die Typen und damit die MDNodes rekursiv sind. Meine VTables sind Objects. Hoffen wir einfach dass das noch jemand anderes so gemacht hat und für mich sicherstellt, dass das funktioniert :-/

TBAA funktioniert nicht mit C/C++.

Es gab ein schönes Ticket für einen Compiler-Bug im GCC ca. 2010 2006, in dem die Entwickler langsam begriffen haben, dass ihr TBAA prinzipiell ungeeignet ist, und es dann als absurde Fehlinterpretation des Standards abgestritten haben. Daraufhin hat ein Kommitee-Mitglied gesagt „ich war im Raum, als wir das entschieden haben, und es war in der Tat genau so gemeint!“. Muss ich mal raussuchen.

Die Notwendigkeit bei C ergibt sich aus memcpy(), memcmp() usw. – diese Funktionen basieren darauf, dass jedes Objekt mit char * gealiast werden kann, damit sich die Bytes der Binärrepräsentation inspizieren lassen (wie auch immer sie dann aussehen).

Bei C++ ergibt sie sich natürlich aus Vererbung – einer Funktion foo(Base *) kann ich einen Zeiger auf Derived übergeben; der deklarierte Typ stimmt also nicht mit dem Laufzeittyp überein und durch Mehrfachvererbung können auch Adresse und Layout radikal verschieden sein.

Und, weniger natürlich, aus Placement new. Beispiel (ich glaube, das war der GCC-Bug):

  int var;
  for(int i = 0; i < 123; i++) {
    if(i & 1)
      new (&var) int(42);
    else
      new (&var) float(42.f);
    someFunction(var);
  }

Bei jedem geraden Schleifendurchlauf ist var ein float und bei jedem ungeraden ein int. In someFunction() hat TBAA keine Chance, Aliasing aufzulösen. Bist du optimistisch, hast du einen Compiler-Bug. Bist du pessimistisch, hast du keine Optimierung mehr.

Edit: Hier ist das Ticket – viel Spaß beim Lesen.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286#c18 hat geschrieben:What is your position based upon? Mine is based upon having been in the room when we decided what the C rules probably were, what the C++ rules could be, […]

Edit 2: Interessantes Zeug drin.

TBAA accounts for about 7-25% of alias disambiguations in the real world for C and C++ (combined). This is according to both papers published by Intel about ICC, papers published by MS about VC, papers published by IBM about XLC, and testing of Google's codebase with and without -fno-strict-aliasing (with the caveat that we know our codebase is not entirely strict aliasing safe)

Krishty hat geschrieben: ↑12.12.2023, 20:56 Und, weniger natürlich, aus Placement new. Beispiel (ich glaube, das war der GCC-Bug):

  int var;
  for(int i = 0; i < 123; i++) {
    if(i & 1)
      new (&var) int(42);
    else
      new (&var) float(42.f);
    someFunction(var);
  }

Bei jedem geraden Schleifendurchlauf ist var ein float und bei jedem ungeraden ein int. In someFunction() hat TBAA keine Chance, Aliasing aufzulösen. Bist du optimistisch, hast du einen Compiler-Bug. Bist du pessimistisch, hast du keine Optimierung mehr.

Das invoked im ersten Durchlauf UB. var ist nicht transparently replaceable mit einem float.

dot hat geschrieben: ↑12.12.2023, 22:30Das invoked im ersten Durchlauf UB. var ist nicht transparently replaceable mit einem float.

Aber erst ab C++20 IIRC? In C++17 und davor dürfte das gültig sein, weil es dieses Konzept damals noch nicht gab.

Krishty hat geschrieben: ↑12.12.2023, 23:29

dot hat geschrieben: ↑12.12.2023, 22:30Das invoked im ersten Durchlauf UB. var ist nicht transparently replaceable mit einem float.

Aber erst ab C++20 IIRC? In C++17 und davor dürfte das gültig sein, weil es dieses Konzept damals noch nicht gab.

Soweit ich das sehe war das seit C++98 UB. C++20 hat lediglich die Anforderungen bezüglich const etwas gelockert. Hier die entsprechende Passage aus C++11 (steht genau gleich auch in meinem C++03 PDF hier): https://timsong-cpp.github.io/cppwp/n33 ... c.life#7.2

dot hat geschrieben: ↑12.12.2023, 23:41Soweit ich das sehe war das seit C++98 UB. C++20 hat lediglich die Anforderungen bezüglich const etwas gelockert. Hier die entsprechende Passage aus C++11 (steht genau gleich auch in meinem C++03 PDF hier): https://timsong-cpp.github.io/cppwp/n33 ... c.life#7.2

Oh, ich lese es jetzt anders. Ich muss den Satz etwas zusammenkürzen weil der so lang ist:

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied

Das gilt für:

  int i = 42; // lifetime i begin
  new (&i) float{ 42.f }; // lifetime i end
  // to be continued

Denn:

The lifetime of an object o of type T ends when: […] the storage which the object occupies is released, or is reused by an object that is not nested within o

Aus dem Rest deines Paragraphen streiche ich mal den Clutter, der hier nicht zutrifft:

a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if the original object is transparently replaceable (see below)

Der Absatz bezieht sich ausschließlich auf Manipulation des neuen Objekts durch den alten Namen, also:

  i = 42; // Illegal! Nicht transparently replaceable! Dies ist nun ein float!

Das Ergebnis des Placement New kann hingegen problemlos genutzt werden, um das Objekt zu manipulieren:

  float * f = new (&i) float{ 42.f }; // lifetime i end; f ist nun Alias auf i
  *f = 43.f; // OK

Bitte lies Kommentare 17 und 18 im GCC-Ticket!

Krishty hat geschrieben: ↑13.12.2023, 09:12 Der Absatz bezieht sich ausschließlich auf Manipulation des neuen Objekts durch den alten Namen, also:

  i = 42; // Illegal! Nicht transparently replaceable! Dies ist nun ein float!

Das Ergebnis des Placement New kann hingegen problemlos genutzt werden, um das Objekt zu manipulieren:

  float * f = new (&i) float{ 42.f }; // lifetime i end; f ist nun Alias auf i
  *f = 43.f; // OK

Bitte lies Kommentare 17 und 18 im GCC-Ticket!

In deinem Beispiel benutzt du den alten Namen (`var`) um eine Funktion aufzurufen, no?

Ich habe zum Standard keine Meinung, für mich ist lediglich nicht offensichtlich wieso das ursprünglich Beispiel vom zweiten Typ dieser neuen Beispiele sein soll. Welchen Typ hat der Parameter von `someFunction`?

Krishty hat geschrieben: ↑13.12.2023, 09:12 Das Ergebnis des Placement New kann hingegen problemlos genutzt werden, um das Objekt zu manipulieren:

  float * f = new (&i) float{ 42.f }; // lifetime i end; f ist nun Alias auf i
  *f = 43.f; // OK

Korrekt, das Ergebnis des Placement-New kann problemlos genutzt werden. Das ursprüngliche Beispiel nutzt aber nicht das Ergebnis des Placement-New, sondern den alten Namen des Objektes. Und der kann nicht mehr genutzt werden, weil das Placement-New die Lifetime des entsprechenden Objektes beendet hat und das alte Objekt nicht transparently replaceable durch das Neue ist (bzw. pre C++20: nicht den selben Typ hat).

Stimmt – der Aufruf someFunc() mit dem alten Namen ist UB; da habt ihr beide recht!

Das ist genau der Grund warum ich das nicht nach 9-10h Arbeit noch Abends in meinen Compiler reinbastel ;)

2023 war crazy, aber jetzt habe ich endlich das Video des Jahres gefunden

Krishty hat geschrieben: ↑22.12.2023, 23:04 2023 war crazy, aber jetzt habe ich endlich das Video des Jahres gefunden

Ich habe aus irgendeinem Grund "Classic Tetris vs. New Teams" gelesen, was auch immer dir das über deine Brand sagt. Fand das Video vor dem Hintergrund leider enttäuschend.

🤣

Dass sie mit 10s TTVC zufrieden sind. Alta. Hab, nur um zu prüfen ob meine Erinnerung nicht falsch ist, gerade nochmal Pidgin gestartet. Deutlich subsecond. In meiner Erinnerung war es das auf deutlich schwächerer Hardware auch. Und was sie natürlich nicht erwähnen bei ihrer tollen Aufräumaktion ist, dass erstmal fucking 500MB kein Erfolg sind und alle die ich kenne wieder zurückgewechselt sind, weil das neue Teams funktionale Probleme hat.

Eigentlich demonstrieren sie nur, wie sehr sie nicht verstanden haben, was ihre Aufgabe wäre. Wäre interessant zu sehen, was das enterprise Skype, was ja irgendwo das Vorgängerprodukt ist, für TTVC hat und Ressourcenverbrauch hat. Ist natürlich ein hinkender Vergleich, weil das keine Sharepointuniversalplattform mit Excel und Word integriert ist...was ich auch nicht brauche.

Richtig, darum ging es mir. Teams (neu oder alt) ist in allem unterirdisch schlecht. Auf so etwas noch stolz zu sein spricht Längen über die Leute, die da am Werk sind. Das Ganze Video mutet wie ein Monthy-Python-Sketch an.

Auch geil, dass Scrollen jetzt funktioniert. Kann jedes Chat-Programm seit 25 Jahren. Aber jetzt sogar ohne Ladepausen!!!

Ich denke, sie haben einfach den „Hack“ gefunden, dass Kunden Regressionen schulterzuckend hinnehmen, sich dran gewöhnen, und man ihnen den Fix ein Jahr später als Meilenstein verkaufen kann. Wir hatten ja so etwas ähnliches mit Windows 11 („kann neuerdings die Icon-Positionen auf deinem Desktop richtig abspeichern“ oder so).

Das liegt doch daran, dass jetzt alles als PWAs bzw. mit irgendwelchen WebViews von Webentwicklern (no offense intended) entwickelt wird, statt mit nativen Desktop-Anwendungs-Frameworks... Wenn das ganze auch im Browser laufen soll, mit gleicher UX und so kann ich den Ansatz auch nachvollziehen. Nervt halt, dass es dann so ein blöder SPA-Ansatz sein muss, der das schlechte aus beiden Welten vereint.

Chromanoid hat geschrieben: ↑23.12.2023, 20:35mit irgendwelchen WebViews von Webentwicklern (no offense intended)

Also bei mir wäre da schon offense intendet ;) Der ganze Web-Quatsch ist doch das schlimmste und ineffizienteste, was die Informatik in den letzten 50 Jahren Zustande gebracht hat. Der erste Firefox ist jetzt fast 20 Jahre alt, und der hat damals wie heute ein bisschen Menüs, ein bisschen Text und ein bisschen Bilder dargestellt. Natürlich gibts zig Kleinigkeiten die man irgendwie als verbessert argumentieren kann, aber vergleich das mal mit dem was sich z.B. in 3D Grafik getan hat.
Noch dazu kommt, dass viel zu viele Webseiten nervig bis komplett kaputt sind. Im Jahr 2023 eine EMailadresse nicht akzeptieren, weil in der Domain 2 Punkte vorkommen? Der Webentwickler hat jede Offense verdient. Der ganze Webkram sind sehr mäßige Technologien, die die Hälfte der Zeit falsch benutzt werden und am Ende ist alles im besten Falle ineffizient und im schlimmsten Falle einfach kaputt.

Ich bin jetzt kein Frontend-Entwickler. Nach meiner Kenntnis wird selbst bei moderaten Anforderungen (muss auf Windows, Mac, iOS, Android laufen, sollte neuer aussehen als Windows XP) die Luft schon arg dünn. Und eure Framework-Empfehlung so?

Ich meine ist Cool was Krishty mit Win32 zaubert, keine Frage, aber halt null pragmatisch.