5d9c8cd37764f5e4f3e5ed36aed900cf34be1537
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
f6225d7341 |
Ports: auch die Messwerkzeuge leiten ihre Nummer ab
GEMESSEN, BEVOR ICH ETWAS ANGEFASST HABE:
204 pruef-Dateien, abgeleitete Ports 5000-5409 (dicht belegt)
24 mess-Dateien, Nummern von Hand: 4471 bis 5493
davon IM Pruefbereich: 5387, 5397, 5397, 5399, 5399, 5401, 5403, 5405
untereinander doppelt: 5397, 5399, 5461, 5483, 5491
Aufgefallen ist es, weil mess-buehne und mess-reaktion beide auf 5483
lagen und ein haengengebliebener Lauf gestern einen ganzen Messlauf
gekostet hat.
Beim Umbau kam das Groessere heraus: EINUNDZWANZIG der 24 Messdateien
hatten nicht nur eine Nummer von Hand, sondern ueberhaupt keinen
Waechter -- schlicht `const PORT = 5397;`. Liegt dort schon ein
Server, startet der eigene still nicht, und gemessen wird ab da ein
fremder Stand. Genau der Fehler, gegen den helfer-port.mjs gebaut
wurde; die Messdateien standen die ganze Zeit ausserhalb.
WAS JETZT GILT
Zwei Sorten, zwei Bereiche, beide abgeleitet aus der Stelle im
Alphabet -- jede Sorte unter ihresgleichen, sonst verschoebe eine
neue Pruefung die Nummern aller Messungen. Pruefungen ab 5000,
Messungen ab MESS_BASIS = 5900.
5900 und nicht 5500: dazwischen bleibt Platz fuer 245 weitere
Pruefdateien (bei 5500 waeren es 45). Nach oben 5948 + AUSWEICHEN
4000 = 9948, also unter 10080, der naechsten gesperrten Nummer.
Nachgerechnet, nicht geschaetzt -- eine geschaetzte 4500 hatte bei
BASIS schon einmal danebengelegen.
Eine Wache dazu: Waechst der Pruefbereich bis an MESS_BASIS heran,
bricht die Ableitung ab und sagt, was zu tun ist. Eine stille
Ueberschneidung waere genau der Fehler, den das hier beseitigt.
Die zweite Nummer kommt ueber nr=1, nie ueber `PORT + 1`:
portNummer ueberspringt gesperrte Nummern, deshalb kann die naechste
Zahl die Nummer der naechsten DATEI sein, sobald einmal eine Sperre
dazwischenliegt. Heute liegt dort keine -- das ist Glueck, kein
Entwurf.
NEBENBEI GEFUNDEN UND MIT REPARIERT
Sechs bild-*.mjs riefen den Waechter und warfen seine Antwort weg:
await portMussFreiSein(4315, "das Bildwerkzeug");
process.env.PORT = "4315";
const BASIS = "http://127.0.0.1:4315";
Er lief, meldete nichts und wirkte nicht. Gibt das System den Port
dauerhaft nicht her, weicht er auf Port + 4000 aus und GIBT DIE NEUE
NUMMER ZURUECK -- diese Werkzeuge hoerten danach trotzdem auf der
alten und stuerzten mit `listen EACCES` ab, also mit genau dem
Fehler, gegen den er gebaut wurde. Dazu stand die Zahl dreimal je
Datei. Jetzt einmal, und die Antwort wird benutzt.
tiktok-videos.mjs hatte den Waechter ABGESCHRIEBEN -- eine kurze
eigene Fassung ohne den dritten Ausgang: Bei EACCES meldete sie
"belegt" und brach ab, statt auszuweichen. Auf diesem Rechner ist
genau das am 23.09. eingetreten (Port 5040, Windows-Dienst).
mess-fokus und mess-notizblock hatten dieselbe Abschrift. Eine
abgeschriebene Sicherung ist dieselbe Falle wie eine abgeschriebene
Liste.
GEPRUEFT
pruef-portnummern 15 -> 41 Pruefungen, 0 Fehler
pruef-ports 8 -> 10 Pruefungen, 456 statt 408 Ports geprobt
node --check auf allen 33 geaenderten Dateien
Gegenproben, die wirklich rot werden:
- eine Messdatei auf eine feste Nummer zurueckgesetzt -> 2 FEHL,
danach wieder 41/0
- die Wache: in einem Wegwerf-Ordner mit 452 pruef-Dateien bricht
eigenerPort ab statt still zu ueberlappen; eine Datei knapp
darunter bekommt weiter ihre Nummer (5846)
- die Erkennungen fuer feste Nummern, PORT + 1 und weggeworfene
Waechterantworten je gegen einen gebauten Rueckschritt
Am echten Verhalten gemessen:
- mess-chat-liste und mess-alle-einzelsicht (beide vorher 5397)
GLEICHZEITIG gestartet: 5906 und 5900, beide exit=0. Vorher war
das unmoeglich.
- die 48 neuen Nummern 5900-5947 auf diesem Rechner durchprobiert:
keine belegt, keine vom System gesperrt
- bild-chat.mjs durchgelaufen, drei Bilder, exit=0
Kein Eingriff am laufenden Dienst: helfer-port.mjs wird von index.js
und workspace.js nicht geladen (nachgesehen), nur von Pruef- und
Messwerkzeugen. Beide Haeuser unberuehrt -- es wird keine Zeile
angefasst, die eine Seite ausliefert.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
077925ab25 |
Dreizehn rote Pruefungen, eine Ursache: openssl steht nicht im PATH
DER BEFUND
Im naechtlichen Lauf standen dreizehn Pruefungen mit derselben Zeile
rot:
[uncaughtException] Error: spawnSync openssl ENOENT
Kein Programmfehler. Die Pruefungen brauchen einen https-Vorbau (der
Sitzungskeks des Hauses ist `secure` und kommt ueber http nicht an),
und dafuer erzeugen sie ein Wegwerf-Zertifikat mit openssl.
GEMESSEN, NICHT VERMUTET
openssl liegt hier: C:\Program Files\Git\mingw64\bin\openssl.exe
C:\Program Files\Git\usr\bin\openssl.exe
im System-PATH steht: C:\Program Files\Git\cmd (nur git.exe)
im Benutzer-PATH: nichts mit Git
Wer aus Git Bash startet, erbt die mingw-Pfade und merkt nie etwas.
Die Aufgabenplanung startet `node.exe` DIREKT, ohne Shell -- und
bekommt sie nicht. Bei mir gruen, nachts rot, und der Grund steht
nicht im Code.
Das Schlimmste daran ist nicht der Ausfall: Dreizehn dauerhaft rote
Zeilen in einer Notiz, die Filipe morgens liest, gewoehnen einem das
Hinsehen ab -- und decken dabei die echten Befunde zu.
DIE REPARATUR
`server/helfer-openssl.mjs` sucht openssl erst im PATH (ohne `where`
oder `which` -- beides sind selbst Programme und koennen genauso
fehlen), danach an den Orten, an denen es auf einem Windows-Rechner
mit Git wirklich liegt.
Dazu `zertifikatBauen(schluessel, zertifikat, host)`. Die acht
Aufrufformen im Haus waren identisch bis auf die Variablennamen
(schl/zert, schluesselDatei/zertDatei, zKey/zCrt, sk/zt, key/crt) --
eine Stelle traegt alle neunundzwanzig. Zwei Tage zuvor war eine
davon um ein `-addext` aermer als die anderen; gemerkt hat es
niemand, weil der Browser den fehlenden Alternativnamen erst bei
einer Weiterleitung anmahnt. Eine Stelle kann nicht von sich selbst
abweichen.
KEIN EINTRAG IN DEN SYSTEM-PATH. `mingw64\bin` enthaelt rund hundert
Programme mit Unix-Namen (`find`, `sort`, `link`), die gleichnamige
Windows-Befehle verdecken. Das fuer eine Pruefung zu aendern haette
an ganz anderen Stellen Fehler verursacht, die niemand hierher
zurueckverfolgt.
GEGENPROBE IN BEIDE RICHTUNGEN, mit dem PATH des Nachtlaufs:
vorher (direkter Aufruf): ABSTURZ: spawnSync openssl ENOENT
nachher (ueber den Helfer): Zertifikat gebaut, 1236 Bytes
Und eine echte Pruefung unter denselben Bedingungen:
PATH ohne mingw64 -> pruef-chat-neu-stelle
63 Pruefungen, 0 Fehler, 0 Abstuerze
Genau diese Datei stand im Nachtlauf mit ENOENT rot.
EINE WACHE DAGEGEN
pruef-struktur prueft ab jetzt, dass niemand openssl wieder direkt
ruft -- der naechste merkt es dort und nicht erst in einem
Nachtlauf, den niemand liest. Drei Gegenproben.
Beim ersten Anlauf schlug sie auf ihre EIGENEN Probetexte an: Sie
liest alle Serverdateien, und dazu gehoert sie selbst. Die Texte
werden jetzt zusammengesetzt. Derselbe Selbsttreffer ist mir heute
schon zweimal passiert.
DER DRITTE AUSGANG BLEIBT, WO ER HINGEHOERT
`helfer-kachel-echtfarbe.mjs` faengt den Fehler weiterhin ab und
meldet `moeglich: false` mit Grund, statt abzubrechen. Eine
Sicherung abzuschaffen, weil ihr Anlass gerade behoben ist, ist der
Anfang des naechsten stillen Fehlschlags.
NEBENBEI: pruef-community-sicht
Sie war rot mit "ZU VIEL: reaktion.html" -- mein eigener Rueckstand
vom 28.09. Die Reaction steht als Kachel im Community-Bereich; die
Liste war nicht nachgezogen. Jetzt 10 / 0.
Die Liste bleibt bewusst von Hand gepflegt: Sie ist eine ABSICHT,
keine Ableitung. Aus rechte.js gelesen verglichen sich zwei Kopien
derselben Quelle -- immer gruen, nie ein Beweis.
GEPRUEFT
pruef-struktur ALLES IN ORDNUNG (mit der neuen Wache)
pruef-community-sicht 10 / 0
pruef-chat-neu-stelle 63 / 0 (mit dem PATH des Nachtlaufs)
pruef-notizen, -teamlage-karten, -werdegang: EXIT 0, keine Abstuerze
mess-quer EXIT 0
29 Dateien: node --check auf allen, kein direkter Aufruf mehr
|
||
|
DogFatherGit
|
3dd4cef42d |
Die Handgriffe unter jeder Nachricht: drei Zeilen werden zwei
EINE RECHNUNG, DIE NIE GEMESSEN WURDE
In chat.css stand seit dem 25.09.2026 neben den 44-Pixel-Knoepfen
der Fusszeile:
"Fuenf mal 44 plus vier Abstaende sind 236 px -- eine Blase hat
auf 412 px innen 251 px. Die Reihe bleibt damit einzeilig."
Sie vergisst die Uhrzeit. Die ist 57 Pixel breit und steht in
derselben Reihe; 236 + 57 sind 293.
Auffallen konnte das nicht, weil die Regel nie lief: Alle
Handy-Messungen des Hauses liefen bis gestern mit einem MAUSZEIGER.
`setViewportSize` macht aus einem Browser kein Telefon -- `hasTouch`
gehoert zum Kontext und laesst sich danach nicht mehr setzen. Ohne
ihn meldet der Browser `pointer: fine`, und KEINE einzige Regel aus
`@media (pointer: coarse)` greift. Dort stehen im ganzen Haus die
44-Pixel-Beruehrziele. Die Rechnung wurde also gedacht und nie
gesehen.
Mit Finger gemessen, 412 px: 234 Pixel Platz fuer 277 Pixel Inhalt.
DREI Zeilen, 96 Pixel hoch -- unter jeder einzelnen Nachricht.
DIE UHRZEIT BEKOMMT IHRE EIGENE ZEILE
Sie ist das einzige Stueck der Reihe, das kein Beruehrziel ist.
Damit behalten die fuenf Knoepfe ihre 44 Pixel nebeneinander:
5 x 44 + 4 x 2 = 228 und passen in 234.
Gemessen jetzt: zwei Zeilen, 74 Pixel. Die Knopfzeile braucht 224
von 234.
EIN VERSUCH, DER ES NICHT WURDE
Zuerst hatte ich die Blase am Fingergeraet von `min(66%, 62ch)` auf
82 Prozent verbreitert -- daneben steht ja die Absicht, sie solle
"auf dem Handy trotzdem die Breite ausnutzen". Die Messung kam
SCHLECHTER zurueck (188 statt 234 Pixel Platz), und das lag an der
Messung selbst: Sie las "die erste Fusszeile". Wie breit die ist,
haengt vom Text darueber ab. Dieselbe Aenderung sah dadurch mal
besser und mal schlechter aus, ohne dass sich etwas geaendert hatte.
Der eigentliche Grund, warum 82 Prozent nicht helfen: `max-width`
ist eine Obergrenze, keine Breite. Eine kurze Nachricht hat eine
schmale Blase, und die Fusszeile bricht darin genauso um. Bei
allen vier gemessenen Nachrichten brach sie.
MESSUNG GESCHAERFT
- Sie fragt jetzt, WIE VIELE Fusszeilen umbrechen, nicht wie die
erste aussieht.
- "Inhalt" ist die breiteste ZEILE, nicht die Summe aller Kinder.
Seit die Uhrzeit absichtlich umbricht, waere die Summe die
Breite zweier Zeilen uebereinander -- sie meldete 444 Pixel in
einer 234 Pixel breiten Fusszeile und sah wie ein Ueberlauf aus.
- `mess-notizblock` misst am Handy jetzt ebenfalls mit Finger
(eigener Kontext, `hasTouch`). Vorher zeigten seine
Handy-Bilder eine Seite, die auf keinem Handy so aussieht.
DIE KLAMMERWACHE HAT WIEDER EINEN ECHTEN FUND GEMACHT
Beim Zuruecknehmen des 82-Prozent-Versuchs blieb das schliessende
`}` der Medienabfrage stehen. Zweiter echter Fund in zwei Tagen,
beide Male an meinem eigenen Werkzeug.
GEPRUEFT
pruef-chatkachel, -css-klassen, -tippziele, -handy: alle EXIT 0
mess-chat-optik EXIT 0 -- 2 Zeilen, 74 px (vorher 3 / 96)
mess-notizblock EXIT 0
|
||
|
DogFatherGitandClaude Opus 5
|
bfae4447cd |
Der Chat bekommt Tiefe -- Lichtkante, Glas und Schatten statt flacher Flächen
Filipe: „ich will dass du die komplette seite viel geiler und moderner
machst. die komplette kachel. die chat liste und die chats selber. …
es soll komplett aus der rolle fahren und was was wir noch nie hatten,
ich will es wirklich übertrieben krass."
EIN SYSTEM, NICHT ZWANZIG EINFÄLLE. Alles Folgende geht auf dieselben
drei Regeln zurück, und deshalb passt es zusammen:
1. LICHTKANTE — jede Fläche hat oben eine haardünne helle Linie und
unten eine dunkle. Damit wird aus einer Fläche ein Körper: Licht
fällt von oben. Was VERTIEFT ist (Suchfeld, Knopfgruppe), bekommt
es genau andersherum.
2. TIEFENSCHATTEN — lang und weich, weit unterhalb. Er trägt, er
umrandet nicht.
3. GLAS — was oben liegt, ist leicht durchscheinend und verwischt,
was dahinter ist. Dadurch sieht man die Ebene, ohne eine Linie.
WAS DAS KONKRET HEISST
* Der Rahmen hat eine Kante statt eines Strichs; zwischen den beiden
Spalten stossen zwei Platten aneinander.
* Die Gesprächszeile HEBT sich beim Überfahren, statt sich zu färben
— der Unterschied zwischen einer Tabelle und einer Bedienung.
* Das Zeichen (Kreis mit Buchstabe) ist ein Körper mit Licht, Saum
und eigenem Schein in der Rollenfarbe.
* Die fünf Handgriffe unter jeder Blase waren unterstrichene Wörter
— im Netz heisst das seit dreissig Jahren „führt woandershin", und
genau das tun sie nicht. Jetzt leise Marken. Sie bleiben SICHTBAR:
Die Entscheidung vom 23.09. gilt weiter (auf dem Handy gibt es kein
Überfahren).
* Der Datumstrenner ist ein Schild auf der Linie statt nackter
Grossbuchstaben.
* Die Eingabe ist eine Konsole: Glas, Lichtkante, Schatten nach oben.
Die vier Buchstaben (F K U S) standen frei im Raum — jetzt Schalter
in einem Streifen über dem Schreibfeld.
* Der Verlauf hat einen weichen Saum: Nachrichten laufen UNTER Kopf
und Konsole, statt an einer harten Kante abzubrechen.
* Titel, Unterzeile und die vier Kopfknöpfe (jetzt eine Gruppe in
einer Mulde) bekommen eine Rangfolge.
WAS ABSICHTLICH UNANGETASTET BLEIBT: die FARBE der Blase. Sie ist die
persönliche Kachel und wird von pruef-chatkachel gemessen — die Prüfung
rechnet mit dem Farbwert selbst. Ein Verlauf oder Glas darauf hätte den
gemessenen und den gesehenen Wert auseinandergebracht, und zwar still.
Die Blase bekommt Tiefe über Kante und Schatten, nicht über den Grund.
DREI EIGENE FEHLER, VON DEN PRÜFUNGEN GEFUNDEN
* Die Formatknöpfe hatte ich auf 32 px verkleinert — hübscher, und
damit unter der Grenze von 44 px, unter der ein Daumen danebentrifft.
* Vier statt zwei Pixel Abstand dazwischen = sechs Pixel mehr an der
schmalsten Stelle. Die Zeile ist dort seit dem 23.09. auf den Pixel
voll.
* Meine erste Fassung der Gestaltungsleiste zerlegte die Konsole in
drei Zeilen.
UND EIN FEHLALARM, DER SEIT LANGEM ROT WAR: pruef-chat-optik verglich
die OBERKANTEN von Schreibfeld und Senden-Knopf. Die Zeile ist aber
unten bündig, das Feld zwei Zeilen hoch — die Oberkanten liegen
zwangsläufig 24 px auseinander, obwohl beide nebeneinander stehen.
Gemerkt habe ich es erst, als zwei Reparaturen die Zahl nicht bewegt
haben: Eine Zahl, die sich durch die Reparatur nicht ändert, misst
etwas anderes, als man denkt. Sie fragt jetzt nach der GEMEINSAMEN
Höhe (44 von 44) und ist damit strenger als vorher.
GEPRÜFT: chat-optik, chatkachel, chat-ausbau, chat, chat-neu,
chat-kanaele, css-klassen, tippziele, lesbarkeit — alle 0 Fehler.
Dazu mess-chat-optik.mjs: vier Bilder (Liste und Verlauf, 1440 und
412 px) auf eigener Wegwerf-Datenbank.
Co-Authored-By: Claude Opus 5 <[email protected]>
|