Wikifunctions:Status-Updates/2024-06-06

◀

Wikifunctions Status-Updates

▶

Neuer Typ: Zeichen

Wir führen diese Woche einen neuen Typ ein: Zeichen.

Zeichen ist eine Auflistung mit drei Werten:

Wir gehen nicht davon aus, dass sehr viele Funktionen nur mit Zeichen arbeiten, haben aber zwei Funktionen für Zeichen als Beispielfunktionen eingeführt: Eine Funktion zum Überprüfen zweier Argumente von Zeichen auf Gleichheit und eine Funktion, die ein gegebenes Zeichen umkehrt.

Wir haben Zeichen diese Woche eingeführt, um unseren ersten komplexen, im Wiki definierten Typ, Integer, vorzubereiten, d. h. natürliche Zahlen mit einem Zeichen. Unsere Tests haben jedoch einige Probleme aufgedeckt, die wir gerne beheben möchten, bevor wir Integer mit Vorzeichen einführen. Es sollte nicht zu lange dauern! Bis dahin möchten wir darum bitten, den neuen Typ Integer weiterhin nicht zu verwenden. Er ist auch deutlich als “Nicht verwenden” gekennzeichnet.

Letzte Änderungen an der Software

Letzte Woche war eine unserer regulären "Reparatur"-Wochen, in der wir an technischen Rückständen, Produktoptimierungen, Designproblemen und anderen kleineren Dingen arbeiten.

In Bezug auf benutzerseitige Verbesserungen sind dir vielleicht vier Dinge aufgefallen. Wir haben die Fehlerbehandlung von Funktionen zur Typenanzeige ("Renderer") so korrigiert, dass sie sowohl im Ansichtsmodus als auch im Bearbeitungsmodus funktioniert (T362519). Wir haben einen Codefehler gefunden, der dazu führte, dass Backlinks (die Spezial:Links auf diese Seite antreiben) größtenteils nicht befüllt wurden; dies sollte nun behoben sein, und die Auflistungen der Objekte werden sich langsam von selbst reparieren, wenn die Seiten erneut analysiert oder bearbeitet werden (T361701). Wir haben den Platzhalter zum Hinzufügen von Text zu einer Z11/einsprachigen Zeichenkette korrigiert, der auf Englisch fest codiert war (T359782). Der Front-End-Code löscht nun beim Veröffentlichen zuverlässiger leere Bezeichnungen und nummeriert Schlüssel neu, was gelegentliche Störungen vermeiden sollte (T359869).

Wir haben eine Reihe von Verbesserungen am Front-End-Vue-Code vorgenommen, darunter die Reduzierung der Anzahl der zwischen Komponenten ausgegebenen Ereignisse, die Wiederverwendung von Komfortmethoden sowie die Erweiterung und Verbesserung von Tests. Wir haben außerdem eine umfassende Neuorganisation und Umbenennung unserer Codebasis vorgenommen, um Konsistenz zu gewährleisten und unser neueres Verständnis dessen widerzuspiegeln, was wo benötigt wird. Wir haben die Anzahl der Funktionen reduziert, die unser älterer Code in den globalen Bereich einfügte, aber hier gibt es noch mehr zu tun.

Als wir letzten Monat unsere Front-End-Interaktionsmetriken auf die Datenplattform umstellten, vermissten wir Ereignisse im Zusammenhang mit Inhaltsänderungen. Diese werden nun konsistent mit dem alten Datenschema gemessen, sowohl bei Funktionsbearbeitungen und Bearbeitungen des "Über-Dialogs" als auch bei anderen Dingen (T365548). Wir haben auch damit begonnen, zu verfolgen, wie oft Benutzer Funktionsaufrufe auf der PHP-Ebene durchführen, nicht nur auf der JavaScript-UX-Ebene, damit wir die Verwendung von Funktionsaufrufen direkter messen können (T356228 und T360369).

Wir haben (hoffentlich!) einige Produktionsprobleme behoben. Erstens schlugen API-Anfragen für Objekte manchmal, aber nicht wiederholt, fehl, wenn Abhängigkeiten mit nicht aktuellen Versionen abgerufen wurden (T365152). Zweitens versuchen einige Codepfade im Zusammenhang mit laufenden Tests anscheinend, ungültige Sprachen festzulegen; diese schlagen jetzt sicher fehl und wir protokollieren dies, um zukünftige Verbesserungen zu ermöglichen (T364961). Wir haben versehentlich eine defekte Version des Funktionsorchestrierers im Beta-Cluster eingeführt; um das Debuggen dieser Probleme in Zukunft einfacher zu machen, haben wir dem Funktionsaufruf-API-Code eine bessere Protokollierung hinzugefügt.

Sowohl letzte als auch diese Woche haben wir unsere Produktionsdienste auf neuere Versionen umgestellt.

Der Funktions-Orchestrierer hat einige Verbesserungen erfahren, die mit unserer vierteljährlichen Arbeit an einfacherem Debugging für Wikifunctions-Benutzer zusammenhängen (T363384), indem wir "Bereiche" für die Ausführung von Funktionsaufrufen konsistenter anfügen (T337589) und die Pipeline überarbeitet haben, damit wir Metadaten von Unteraufrufen einfügen und zusammenführen können, wenn sie verfügbar werden (T351473). Wir haben auch schrittweise an dem technischen Rückstand gearbeitet, der mit der Entfernung der Legacy-Unterstützung für Inline-Objekte von Z61/Programmiersprache anstelle von Referenzen zusammenhängt (T287154). Für unseren Code zum Anfordern von Kopien von Objekten aus dem Wiki können jetzt Ratenbegrenzung und Lebensdauer konfiguriert werden (T340561) und wir testen dies jetzt (T340562). Wir haben unseren Code zum Auffinden von Identitätsschlüsseln verallgemeinert und zwischen Repos geteilt (T350176) und unseren Code zum Festlegen und Anpassen von Metadatenwerten so gestaltet, dass ein bestimmtes Objekt mutiert, anstatt es zu klonen (T365151).

Auf der Funktionsauswertungsseite haben wir eine direktere Möglichkeit hinzugefügt, den Ausführungsprozess nach Abschluss zu beenden, im Gegensatz zu der Art und Weise, wie Docker versucht, unsere Threads zu verwalten. Dies sollte lang andauernde, nicht verbundene Zombie-Prozesse vermeiden, die wir in der Produktion gefunden haben (T364889). Darüber hinaus testen wir jetzt besser auf mehrere ungültige Ausgaben der Ausführer (T362703) und legen die Version von RustPython (T364563) und QuickJS (T364564), die wir in WASM ausliefern, auf bestimmte Commits fest. Wir haben eine chaotische Integrationsschicht mit WASM-Edge bereinigt und verstehen sie jetzt besser (T362738). Wir haben unsere Benchmark-Tests verbessert, um Ratenbegrenzungen zu vermeiden, die ihre Ergebnisse künstlich veränderten und manchmal zum Scheitern brachten (T363710).

Wir haben unsere Sprachen optimiert und Z1394/sr-latn und Z1181/sr-cyrl so aktualisiert, dass sie die internationalen Standardsprachencodes als primäre und die nicht standardmäßigen MediaWiki-Codes 'sr-el' und 'sr-ec' als sekundäre Codes haben (T360676 und T360677). Wir haben Unterstützung für die Z1923/ekp "Ekpeye"-Sprache hinzugefügt, da diese in ganz MediaWiki unterstützt wird (T365263).

Wir und der gesamte von Wikimedia bereitgestellte Code verwenden seit dieser Woche die neueste Version der Codex-UX-Bibliothek, v1.6.1, die die etwa jährliche Erhöhung unserer Vue-Version von 3.3.9 auf 3.4.27 beinhaltet (T364789). Es sollte keine für den Benutzer sichtbaren Änderungen an Wikifunctions geben, also kommentiere bitte in der Projektdiskussion oder erstelle einen Phabricator-Task, wenn du ein Problem bemerkst.

Freiwilligentreffen am 3. Juni

Wir haben uns am Montag mit einigen unserer wunderbaren Wikifunctions-Freiwilligen getroffen. Wir haben unsere letzten Updates besprochen und gemeinsam eine Funktion erstellt, wie es bei diesem Treffen üblich ist. Die Aufzeichnung des Treffens ist auf Wikimedia Commons verfügbar.

Funktion der Woche: Ist der Monat nach diesem Monat?

Jeden Monat erstellen wir beim Freiwilligentreffen gemeinsam eine Funktion. Diese Woche war es “ist der Monat nach diesem Monat in dem Jahr?” (Z16648), inspiriert von der bereits vorhandenen Komplementärfunktion “ist der Monat vor diesem Monat?”. Die Funktion nimmt zwei Monate und gibt einen booleschen Wert zurück: wenn der erste Monat in der Reihenfolge der Monate innerhalb eines Kalenderjahres strikt nach dem zweiten liegt, gibt sie wahr zurück, andernfalls falsch.

Wir haben vier Tests erstellt:

November ist nach Februar, testet einen wahren Fall
Juni ist nicht nach Dezember, testet einen falschen Fall
Dezember ist nach Januar, testet einen Randfall
January ist nicht nach sich selbst, testet die Striktheit der Funktion

Theoretisch könnten die Tests vollständig sein, aber das würde zu 144 Tests führen, und ich bin nicht sicher, ob wir das wollen. Ich bin ziemlich sicher, dass Wikifunctions mit so vielen Tests Probleme hätte.

Wir haben fünf Implementierungen erstellt, eine in jeder der von uns unterstützten Programmiersprachen und drei Kompositionen. Es kann aufschlussreich sein, sich die verschiedenen Kompositionen anzusehen und zu versuchen, sie zu verstehen.

In JavaScript verwenden wir einfach den Operator “>”, “größer als”, da wir für JavaScript die Monate in Zahlen umwandeln, die ihre Reihenfolge in der Liste der Monate darstellen
Ebenso in Python
Eine Komposition folgt dem gleichen Muster wie die beiden vorherigen Implementierungen: Zuerst wandelt sie die beiden Monate in ihre jeweiligen Monatszahlen um und verwendet dann die Funktion größer als, um sie zu vergleichen.
Eine Komposition verwendet einfach die vorhandene Komplementärfunktion “ist der Monat vor diesem Monat?”, vertauscht jedoch die Argumente. Da die Frage, ob Juni vor Juni liegt, mit Falsch beantwortet wird, was auch für die Frage gilt, ob Juni nach Juni liegt – das nennt man in diesem Fall Striktheit –, funktioniert das einfache Vertauschen der Argumente auch bei den Randfällen.
Die letzte Komposition, die wir haben, verwendet ebenfalls die Funktion “ist der Monat vor diesem Monat?”, verwendet dann aber eine Verneinung, um die Antwort umzukehren. Da dies zu einem Fehler führen würde, wenn beide Argumente der gleichen Monat sind, stellen wir eine wenn-Prüfung voran, um zu prüfen, ob beide Argumente der gleiche Monat sind: Wenn dies der Fall ist, geben wir falsch zurück und decken damit diesen Randfall ab.

Danke an alle, die am Freiwilligentreffen teilgenommen haben! Du kannst dir die Aufzeichnung ansehen, um zu sehen, wie diese Funktion erstellt wird.