06:11:04 Schrompf joined the channel
08:02:38 xq: moin
08:04:19 IceMichael: moin
08:06:08 xq: ich hab am WE mal wieder n bisschen was reissen können beim coden
08:06:31 IceMichael: oh, nice. Was denn?
08:06:43 xq: ich hab an Dunstwolke weitergearbeitet
08:06:53 IceMichael: vv
08:06:54 xq: also diesem obskuren riesenprojekt mit UI-Framework
08:07:12 xq: hab jetzt zum einen ne kleine *echte* Anwendung gebaut
08:07:42 xq: und kann jetzt eine Steckdosenleiste damit remote controllen
08:08:00 xq: hab dabei das System von Callbacks auf Event-Polling umgeschaltet
08:08:06 xq: sehr lohnenswerter Refactor
08:08:25 IceMichael: oh, das klingt ja sehr cool. Welches Device hängt dann an der Steckdosenleiste zum schalten?
08:08:31 IceMichael: und inwiefern bringt der Refactor was?
08:08:39 xq: Die Leiste selbst ist ein EnerGenie LAN
08:08:51 xq: die Devices sind grade: Die Wii, der Monitor, der Gaming-PC
08:09:32 IceMichael: Und worauf läuft der Client zum schalten? Die Wii steuert die Leiste?
08:10:28 xq: Na, das wäre Blöd :D
08:10:41 xq: wenn die wii die leiste steuert,tut sie das solange, bis sie sich vom strom trennt *rofl*
08:11:40 xq: Ne, momentan läuft die Anwendung noch "in-dev" aufm Laptop
08:11:58 xq: soll aber später auf einem der vielen PIs oder dem Homeserver laufen
08:12:17 xq: die UI dazu kann man sich ja auf jedem Dunstblick-Display-Client anzeigen *grins*
08:12:45 Schrompf: klingt alles schon ganz nice
08:13:08 IceMichael: ok, wenn die Wii an selbiger Leiste ist, wär's natürlich geil :D
08:13:19 Schrompf: wireless selbstmord
08:13:22 xq: https://git.random-projects.net/dunstwolke/power.xq
08:13:23 IceMichael: wie diese Maschine, die selbst immer den Schalter zurück umlegt...
08:13:38 xq: unter src/main.zig ist der ganze source code
08:13:56 xq: sind < 300 LOC für das HTTP-API der Steckdosenleiste und die Logik für die UI :)
08:16:03 xq: hab auch gestern nacht noch den layout-compiler umgestellt
08:16:14 xq: der ist jetzt tatsächlich in einem zustand "usable" :D
08:16:24 IceMichael: standup, schaue danach
08:35:54 IceMichael: ach ich dacht Zig wär wie C, d.h. ohne Memberfunktionen
08:36:36 xq: nur semantisch wie C
08:36:46 xq: sind ja keine memberfunktionen, ist nur eine bequeme art des function calls
08:37:01 xq: keine ahnung, wie man das nennt
08:37:13 IceMichael: wo liegt dann eh der Unterschied?
08:37:27 xq: Ich verbinde "member" mit OOP-Begriffen
08:37:35 IceMichael: ich könnt mir in C ja auch "Klassen" bauen, indem ich structs mache mit Funktionen, die struct-ptr als 1. Param haben
08:37:48 xq: jo, ist ja auch gang und gäbe
08:37:51 IceMichael: jap
08:37:56 xq: nennt sich dann strukturiertes programmieren :D
08:38:25 IceMichael: oder man sagt, Polymorphie/Vererbung sind die Hauptunterschiede
08:38:38 IceMichael: aber falls Zig mix-ins kann, wackelt das ja auch
08:39:00 xq: nur zu compilezeit
08:39:08 xq: und auch nur für funktionen
08:39:14 IceMichael: ja ok
08:39:24 IceMichael: nice jedenfalls, sieht simpel genug aus :)
08:39:31 xq: also eher so ein "du kannst nen common code block zwischen strukturen teilen"
08:40:08 IceMichael: und wo genießt du jetzt Events mehr als Callbacks? Flexibler?
08:40:19 xq: weniger schmerz im allgemeinen
08:40:28 xq: wie behandelst du fehler aus nem callback anständig?
08:41:07 IceMichael: hm, wie aus nem event? Geht's dir um die Rückmeldung oder darum an die richtigen Variablen zu kommen?
08:41:16 xq: rückmeldung
08:41:41 xq: ich behandle hier ja events auf meinem scope und nicht in einem scope der library (callback)
08:41:52 xq: das heißt, ich kann entscheiden, wie es nach dem event weiter geht
08:42:10 xq: brb
08:42:15 IceMichael: hm, für mich sind callbacks user-scope, die man an die lib reicht, die es dann aufruft
08:42:56 IceMichael: also außer bzgl. der Gleichzeitigkeit natürlich
08:43:20 IceMichael: ok, hast so gesehen mehr/einfacherere Kontrolle, sonst müsstest du irgendwie Fehlerarrays aufbauen, im callback anreichern und dann auf die pollen und reagieren, klingt nach mehr pain
08:44:30 IceMichael: Schrompf, ich hab übrigens mein Verfahren jetzt verfeinert, habe tatsächlich jetzt eine Art Regelbaum, allerdings nicht auf Einzelkartenbasis (das bringt nämlich so gut wie keine Aggregationsmöglichkeiten), sondenr mit mehr Pokerwissen drin :)
08:44:49 Schrompf: ok, prima
08:44:57 IceMichael: na ja, im Endeffekt musste ich einfach selbst "nachdenken", was so für Regeln gelten. Automatisiertes Finden wär zu komplex gewesen
08:45:22 IceMichael: Und dann ist es jetzt im Endeffekt zwar immer noch viel, aber überschaubar. Hab mir ein superschlichtes Rulesystem überlegt, was ich leicht erweitern kann
08:45:41 IceMichael: aber dein Design gab mir da eine gute Idee vor, also danke nochmal :+1:
08:47:12 Schrompf: \o/
08:55:12 xq: IceMichael: die frage, welche variante besser ist, lässt sich auf mit der Frage "Ist A einfacher in B zu implementieren oder B einfacher in A?"
08:55:29 IceMichael: hm, interessanter Hilfsgedanke
08:55:59 IceMichael: trifft hier natürlich obv zu
08:56:07 xq: jo
08:56:13 xq: ist aber grundlegend ne gute entscheidungshilfe
08:56:29 IceMichael: ja, wenn A und B beide wichtig sind, bringt das bestimmt häufig was, merk ich mir
08:56:39 IceMichael: beide wichtig und beide häufig
08:56:59 xq: Die andere Frage ist: Does it allocate?
08:57:45 IceMichael: warum gerade die?
09:00:07 xq: allocations sind langsam (relativ), steigern die menge an management/fehlerquellen drastisch, können fehlschlagen (und brauchen daher anständige fehlerbehandlung)
09:00:54 xq: ich hab mich tatsächlich hier für eine event queue *mit* allocations entschieden
09:00:59 xq: aber: das ist nen implementation detail
09:01:15 xq: mit mehr kopf könnte ich den client zu 90% allocation-free hinbekommen
09:01:22 xq: das event-zeug quasi vollständig
09:01:53 IceMichael: was allokierst du denn überhaupt?
09:02:05 xq: in dem fall events und strings
09:02:22 xq: (die architektur ist intern immer noch "callback"-basiert
09:02:34 xq: und ich hab jede invocation eines callback ersetzt durch das enqueuen von events
09:02:55 IceMichael: okay und wie würde man das ohne Allokationen gestalten?
09:03:10 IceMichael: also scheint ja ein Zig-Detail zu sein?
09:03:32 xq: nö, isses nicht
09:03:50 xq: ist nur ein detail, was in der nicht-zig-welt häufig komplett ignoriert wird
09:03:58 xq: mit ner komplexeren state machine
09:04:21 xq: jeder call an "pollEvent" führt die interne netzwerkverarbeitung genau so weit weiter aus, bis ein event dabei auftritt"
09:04:23 xq: ist die lösung
09:04:29 xq: dann returned man dieses
09:04:35 xq: und im nächsten call gehts weiter
09:04:52 xq: klar, man braucht für dynamische strings auch n bissi allokationen
09:05:04 xq: genauso wie fürs anlegen von verwaltungsobjekten für connections
09:05:11 xq: aber der core loop wäre damit allocation-free
09:05:15 xq: und damit relativ flott
09:05:24 xq: aktuell ist der loop bei mir allocation-minimiert
09:05:35 xq: das heißt, ich benutze die events in einer art ringbuffer
09:05:39 xq: und recycle diese
09:06:17 xq: das skaliert relativ gut und benötigt im regelfall nur eine einzige allocation für den kompletten betrieb
09:09:10 IceMichael: ja
09:09:18 IceMichael: okay, verstehe. Also Lösung wäre blocking pollEvent einfach
09:09:31 xq: nö, wieso blocking? ;)
09:09:32 IceMichael: was voraussetzt, dass man außer Reaktion auf Events nix macht?
09:09:48 IceMichael: hm, coroutines?
09:09:51 xq: du kannst doch mit poll()/select()/epoll()/… nonblocking code schreiben
09:10:13 IceMichael: na weil du meintest, du returnst es
09:10:17 IceMichael: aber egal, das sind jetzt echt Details
09:10:40 IceMichael: klingt auf alle Fälle effizient und easy-to-use, also ist doch top
09:10:47 IceMichael: was steht als nächstes auf der Speisekarte?
09:12:04 xq: Den Display-Client neu schreiben
09:12:15 xq: das ist grade nen rießges Kuddelmuddel aus APIs, Sprachen und was weiß ich
09:12:27 xq: zudem sind da auch noch echt fehlende Dinge
09:12:30 xq: a'la TextBox usw
09:13:02 IceMichael: okay, also einiges an Arbeit
09:13:03 xq: und: android-port
09:13:08 xq: das wird lustig :D
09:13:17 IceMichael: ja, da war doch die Frage, auf welchem Level du ansetzt oder so?
09:13:35 IceMichael: du wolltest ja irgendwie recht niedrig im ISO/OSI-Modell ansetzen netzwerktechnisch, wenn es geht
09:13:51 xq: ja, das wird aber nen anderes subprojekt erst mal
09:13:54 IceMichael: was wiederum schwierig ist, wenn auf Android alles in Java *schauder* geschrieben wird auf appl-Ebene (wobei geht ja sicher lower level?)
09:13:59 xq: nein? :D
09:14:06 IceMichael: geht nicht lower level?
09:14:12 xq: https://fosdem.org/2021/schedule/event/zig_android/
09:14:14 xq: watch this!
09:14:18 IceMichael: gott sei dank
09:14:31 IceMichael: vids während Arbeit gehen nicht, sind zu ineffizient zu schauen
09:14:34 xq: :D
09:14:38 xq: also: es tut :D
09:14:46 xq: ich hab ne zig-only app
09:14:51 IceMichael: hm nice
09:14:58 xq: aber: bin mal afk, muss mal gen büro :D
09:15:11 IceMichael: phhh, ja muss auch sprint-related work tun
09:15:19 IceMichael: wieder so nen lahmem Bug fixen falsche timezone, spannend
10:08:50 xq: sodele, büro :D
10:28:56 IceMichael: es ist echt nicht der Ernst... der Build dauert normalerweise from scratch 20min
10:28:59 IceMichael: jetzt dauert er schon 2h
10:29:05 IceMichael: sehr produktiver Vormittag :D
10:58:50 xq: :D
11:54:36 Schrompf: Eigentlich war's ein Scheiß-Vormittag. Die neuen Felder, die ich in die Stats exportiere, kommen dort auf Testing nicht in der DB an. Wir lösen zusammen unverständliche CMake-Fehler, die nur bei manchen der Maschinisten auftreten und herden von Linkerfehlern verursachen.
11:54:47 Schrompf: kein Fortschritt, aber immerhin an allen Fronten
15:06:17 IceMichael: Schrompf, "kein Fortschritt, aber immerhin an allen Fronten" ist mein Motto seit Wochen :D
15:06:48 IceMichael: na ja, jedenfalls in Karriere & Projekten. Privat gut. Aber ich krieg irgendwie nix mehr hin
15:07:09 IceMichael: und wurd heut auch mal schön in unseren Retros deutlich. Ich hab bemängelt, dass wir ne Story nicht geschafft haben, im Endeffekt wurd durch die Blume gesagt, dass es an mir lag, cool
15:07:28 IceMichael: was geschafft wurde, wurde präsentiert, aber natürlich nicht von mir :D ergo, ich hab nur kacke gemacht, die Leistung kam von woanders. Logisch
16:57:54 Schrompf joined the channel
19:46:49 Schrompf: Ein Hoch auf das ZFX im Allgemeinen und Krishty im Besonderen
20:08:51 Hannes joined the channel
20:09:31 xq: huhu
20:09:33 xq: Schrompf: ACK
20:11:05 Hannes: ein hoch auf elSchrompfo und dem irc-chat
20:11:17 Hannes: und auch auf xq
20:11:24 Schrompf: Danke
20:11:51 Schrompf: Ich bin halt nur congenial: ich bringe die wahre Größe in Menschen hervor, trage aber selbst nichts bei
20:12:10 Hannes: ich zocke die ganze zeit nur noch Immortals Fenyx Rising
20:12:30 Hannes: macht spaß
20:13:11 Schrompf: habsch auf der liste
20:14:40 Hannes: welche liste?
20:22:52 Hannes: die niemals Anfang weil zu zeitintensiv Liste?
20:23:39 Hannes: xq, den prozessor?
20:25:00 xq: jap
20:25:08 xq: hab jetzt nen Ryzen 3600
20:25:15 xq: 6 Kerne, 12 Threads, 3600 RAM
20:29:18 xq: das fluppt ganz schön
20:29:32 xq: hat auch alles auf anhieb funktioniert \o/
20:29:39 xq: nur: immer noch ne GT 1030
20:29:43 xq: GPU saugt halt
21:41:35 Hannes: gn8