IRC Logs for #zfx


2022-06-18

08:23:41 IceMichael: Moin
08:45:24 xq: moin moin
08:45:26 xq: IceMichael: klingt auch nice
08:45:31 xq: aber ist halt wieder *fett* :D
08:45:39 xq: ist auch das ding, was mich an dotnet 6 so massiv stört
08:48:59 IceMichael: xq: ist .net6 dicker als netcore 5 oder .net3 oder wie auch immer?
08:49:13 xq: 60 MB für nen Standalone-Single-Binary Hello World
08:49:14 IceMichael: ist ja common successor also Vereinigungsmenge?
08:49:16 IceMichael: mmm
08:49:19 IceMichael: ja, unschön
08:49:29 IceMichael: sobald man halt html/css/js aufgleist, ist man fett dabei
08:49:46 IceMichael: ist halt immer ein Browser mitgebundled, eh?
08:49:51 IceMichael: kA, was nen Browser wiederum so fett macht
08:50:03 xq: nen Browser ist halt basically nen OS
08:50:05 IceMichael: aber ne Qt App ist wiederum auch saufett
08:50:07 xq: vom Umfang her
08:50:09 IceMichael: ja ok
08:50:12 IceMichael: sandbox usw
08:50:17 xq: Qt Static ist tastächlich sehr klein
08:50:22 IceMichael: oh
08:50:34 IceMichael: na ja, je nachdem, was mit drin steckt, schätz ich
08:50:46 IceMichael: wie klein denn?
08:51:05 IceMichael: gut, die wollen ja embedded mitmachen, da kannst nicht mit 60MB auffahren
08:52:33 xq: exakt
08:52:40 xq: habs noch nicht ausprobiert, aber ich denke so max. 1 MB
08:52:55 xq: static linking mit LTO und -Os macht *echt kleine binaries*
08:58:32 xq: IceMichael: ich bin übrigens grade am überlegen bzgl. der state machine-geschichte
08:59:50 IceMichael: 1MB ist embedded teilweise aber auch dick, ne? aber na ja, mit Qt erstellte Programme sind ja nicht das Allerkleinste
08:59:54 IceMichael: und klingt gut, wo steckst da?
09:00:24 IceMichael: ich bin irgendwie gar nicht so der Freund von state machines, irgendwie macht der state-overarching-context das Ganze doch immer ziemlich fehleranfällig und unübersichtlich... hab da noch keine schöne Lösung gefunden
09:00:52 IceMichael: und wenn State5 irgendwas Globales von "außerhalb" braucht, muss das von State1->...->5 durchgereicht werden
09:00:59 xq: Qt auf Embedded ist kleiner
09:01:04 IceMichael: ah ok
09:01:15 IceMichael: krass, dann haben die ja echt architektonisch irgendwo was richtig gemacht
09:01:19 xq: ho
09:01:20 xq: *yep
09:01:28 xq: bzgl. state machine:
09:01:36 xq: ich hab aktuell alle states ausformuliert und switch cases dafür gebaut
09:01:47 xq: aber irgendwie ist das unbefriedigend ^^
09:01:54 xq: was ich mir jetzt überlegt habe:
09:02:11 xq: ich lege einfach eine liste von transitions an
09:02:28 xq: DefineTransition(SOURCE_STATE, EVENT, Handler)
09:02:32 xq: sowas wie
09:03:15 xq: DefineTransition(STATE_IDLE, EVENT_REQUEST_OPEN, { mqtt_send("open requested"); start_motor(); set_state(STATE_DISABLE_MOTOR); trigger_timeout(100ms); })
09:03:38 xq: DefineTransition(STATE_DISABLE_MOTOR, EVENT_TIMEOUT, { stop_motor(); … });
09:04:00 IceMichael: ja, switch-case wird dafür ja gemeinhin kritisiert, ich find's schon schöner das in eigene Objekte zu packen... wenn es komplexer wird, will man das unabhängig haben, find ich
09:04:02 IceMichael: ok, mal lesen
09:04:43 xq: ich hab halt C ^^
09:05:04 IceMichael: ja, da gehen nur fct pointer für so was
09:05:08 IceMichael: ob man das will, kA
09:05:15 IceMichael: Funktionen reichen ja
09:05:33 xq: jo
09:05:40 xq: siehe oben: "bisschen macro magic" würde auch schon tun
09:05:46 IceMichael: ist der Handler immer so dünn?
09:05:49 xq: meistens, ja
09:05:50 IceMichael: ja, sieht gut aus
09:07:33 xq: mal gucken, ob sich das besser liest damit
09:08:00 xq: das problem ist noch, dass ich zwei arten state transition trigger habe
09:08:08 IceMichael: ich mein, wenn das so wenig Code ist wie da oben, liest es sich so oder so gut, daher schwer zu sagen
09:08:22 IceMichael: also zwei Events?
09:09:04 xq: ne
09:09:10 xq: einmal ein event, ohne daten
09:09:26 xq: einmal eine state transition der türe (auf → zu, zu → verschlossen, …)
09:10:58 IceMichael: ok, nochmal, es gibt state transitions ohne event?
09:11:05 xq: jein
09:11:15 xq: es gibt aktuell setDoorState() und sendEvent()
09:11:22 xq: als interface nach aussen
09:11:35 xq: weil events aktuell keine information haben
09:12:02 IceMichael: hm, kann man das nicht vereinfachen? wenn es schon events gibt, hätt ich alles darüber geregelt und dafür dürften die dann eben auch infos haben
09:12:18 xq: hm
09:12:31 xq: ich kann mir in der state machine ja den zustand merken …
09:12:49 IceMichael: weil ich bin jetzt anscheinend schon zu doof das so zu raffen :D wenn ich das Makro oben anschaue impliziere ich, dass ich von einem State A zu B (mit B maybe =A) über nen Event-Trigger komme
09:13:00 xq: und dann einfach statt "setDoorState" ein EVENT_DOOR_NOW_OPENED, EVENT_DOOR_NOW_CLOSED und EVENT_DOOR_NOW_LOCKED machen
09:13:20 IceMichael: ja, ist dann halt vereinheitlicht
09:13:29 xq: jo
09:13:33 IceMichael: kA, ob's was bringt, bin nicht so tief bei dir drin
09:13:33 xq: ist wahrscheinlich besser so
09:13:44 xq: ja, tatsächlich müsste es das massiv einfacher machen…
09:13:54 IceMichael: ok :)
09:13:55 xq: ich guck mal
09:15:19 IceMichael: ich kämpfe gerade mit meinen Go Integrationstests gegen NTAS
09:15:21 IceMichael: *NATS
09:15:31 IceMichael: Go führt alle Tests als goroutines und damit concurrent auf
09:15:48 IceMichael: normalerweise nett und die Anforderung Tests unabhängig zu gestalten ist für non-integration auch ok
09:16:03 xq: jo, kann ic hmir vorstellen
09:16:04 IceMichael: aber ich baue beim Teststart nen neuen Server auf, ist also eher kacke
09:16:29 IceMichael: ich könnte einen für alle machen, aber ich will eigentlich jedes mal clean state, weil ich auch testen will, was passiert, wenn ich nen nicht vorhandenen account lösche usw.
09:16:43 IceMichael: jetzt hab ich also EINEN Test der die Testfunktionen manuell aufruft, nicht so nett...
09:17:56 xq: https://github.com/shackspace/portal300/blob/master/firmware/door-control/main/state-machine.c
09:18:01 xq: das ist übrigens aktuell die state machine
09:18:39 xq: du siehst relativ schnell: alle transitions sind meist so drei zeilen code
09:59:30 IceMichael: ah mal schaun
09:59:44 IceMichael: (was an Go auch nett ist: JSONs deserialisieren ist super-easy, selbst nested mit arrays)
09:59:50 IceMichael: man baut einmal ne (nested) struct und los geht's
10:00:06 IceMichael: JSON-Name ist durch Annotations bestimmbar, man kann das also unabhängig von den Feldnamen ändern. Sweet
10:00:34 xq: jo, Go macht gut spaß
10:00:48 IceMichael: ja und bei den Integrationstests lag ich falsch. Subtests laufen nämlich nicht concurrent, also easy gelöst
10:01:44 IceMichael: na ja, also ich bin mittlerweile sehr picky bei so was. sm_change_door_state ändert ja nicht nur den State sondern macht ja noch mehr
10:02:05 IceMichael: hm, es gibt irgendwie nen logic_state und der kombiniert mit aktuellem State bestimmt den Zielstate?
10:02:31 IceMichael: also hast ne Untermenge von NxM States?
10:03:01 xq: IceMichael: ne state machine ohne transition events macht wenig sinn ;)
10:03:16 IceMichael: das mein ich ja nicht
10:03:35 IceMichael: log_print würd ich persönlich auch auslagern, ist schon immer das gleiche
10:03:39 xq: ist halt nen Mealy-Automat
10:03:51 xq: logging ist halt zum debugging der state machine da ;)
10:03:59 IceMichael: auslagern != löschen
10:04:10 xq: ja, aber was willstn da auslagern?
10:04:24 IceMichael: log_print(LSS_LOGIC, LL_WARNING, "unexpected door change event in state %u!", sm->logic_state);
10:04:27 IceMichael: das steht doch da drölf mal
10:04:44 IceMichael: in 211 ist's sogar ein C&P error, oder?
10:04:55 xq: stimmt
10:04:58 IceMichael: danach auch usw.
10:05:02 xq: aber: das copy-paste ist gewollt
10:05:14 xq: weil sonst wirds ne riesen fummelei, das nachher einfach anzupassen
10:05:37 IceMichael: du willst unterschiedliche Fehlermeldungen später basteln? ja ok
10:05:46 IceMichael: wobei trotzdem...
10:05:49 IceMichael: aber gut, ist ein Detail
10:05:53 xq: nicht nur das, sondern vorallem auch potentiell komplett andere behandlungen dort einbauen
10:05:55 xq: und erweitern
10:06:05 IceMichael: aber.. das kannst du ja dennoch tun
10:06:15 xq: jo, aber wie willst du das auslagern? :)
10:06:17 xq: gerne konkretes beispiel
10:06:32 IceMichael: ich würd echt ne Einzeiler-Funktion bauen :)
10:06:49 xq: die was tut? ;)
10:06:52 IceMichael: und da einfach log_print(LSS_LOGIC, LL_WARNING, "unexpected door change event in state %u!", sm->logic_state); rein
10:07:09 IceMichael: parametrisiert halt
10:07:21 xq: jo, und dann hab ich den salat mit ich brauch nen neues array :D
10:07:27 IceMichael: hm?
10:07:51 IceMichael: ich seh da gerade kein array
10:08:41 xq: genau
10:08:46 xq: ansonsten printe ich halt nen integer statt nem text
10:08:49 xq: das macht das log lesen echt kacke
10:08:54 xq: weil du dann den source für operating brauchst
10:10:18 IceMichael: ich versteh leider kein Wort
10:10:34 IceMichael: wenn du die Zeilennummer mit im Log willst, kannst auch ein Makro bauen, das ist ja wuascht
10:10:39 IceMichael: aber das ist ja gerade nicht drin?
10:10:45 IceMichael: und immer noch kA, was fürn Array du meinst :D
10:10:48 IceMichael: aber wie gesagt, ist ein Detail
10:10:57 xq: nein, ich will nicht die zeilennummer. ich will den state als string
10:11:16 IceMichael: dann übergeb halt den als Parameter
10:11:21 IceMichael: ist immer noch cleaner und safer gegen c&p
10:11:24 xq: dafür brauch ich wieder nen array ^^
10:11:29 xq: und es ist nur fucking logging :D
10:11:33 IceMichael: wieso ein array?
10:11:37 xq: wie sonst?
10:11:46 xq: ansonten hab ich doch wieder copy-paste
10:11:56 xq: nur halt dann statt im format-string nen parameter-string
10:11:57 IceMichael: kann man in C ner Funktion kein const char* übergeben und als Argument nen ad-hoc string?
10:12:01 xq: same difference am ende
10:12:27 IceMichael: ich hätt jetzt naiv gedacht:
10:12:57 IceMichael: void log_unexpected_change_door_state_error(const char* source_state) {log_print(LSS_LOGIC, LL_WARNING, "unexpected door change event in state %s!", source_state);}
10:13:05 xq: jo, aber wo ist da der gewinn?
10:13:07 IceMichael: und call mit log_unexpected_change_door_state_error("STATE_WAIT_FOR_UNLOCKED")
10:13:12 xq: also, seriously
10:13:21 xq: das ist kein qualitativ großes update
10:13:40 xq: die mögliche fehlerquelle ist die selbe, wir haben jetzt nur eine funktion mehr, die wir verstehen müssen
10:13:52 IceMichael: ist wenig, aber ich find's trotzdem besser. Der variable Anteil, nämlich der State-Name, ist von dem konstanten Anteil getrennt
10:13:57 IceMichael: die C&P Fehler macht man damit eher unwahrscheinlich
10:14:08 xq: *shrug*
10:14:24 IceMichael: ich find's minimal besser, natürlich ist das nicht groundbreaking, ich hätt
10:14:29 IceMichael: s wsl gar nicht ansprechen sollen :D
10:14:32 IceMichael: ok, aber egal
10:14:35 IceMichael: also zur Funktion
10:14:46 IceMichael: also man ändert den door state damit, aber sie ändert ja eigentlich den global state oder wie?
10:15:02 IceMichael: also gibt ja hier mehrere State-Machines? Von der Door und insgesamt? Oder versteh ich falsch?
10:15:29 xq: es gibt eine state machine, die zwei steuer-inputs hat
10:15:31 xq: in der implementierung
10:15:41 xq: events und physical state changes der türe
10:16:03 xq: du kannst die türe gerne als state machine betrachten, aber das ist halt eine no-code solution ^^
10:16:12 IceMichael: ok, versteh ich
10:16:22 IceMichael: weil die Funktion sagt, sie ändert den door state, aber ich find, eigentlich passiert ja viel mehr
10:16:46 IceMichael: eigentlich wird der "logical/global (?) state" geändert mit dem Input des neuen Door-States (bzw. Steuerinputs)
10:16:55 Magister joined the channel
10:16:58 IceMichael: ich stolper über so was, wenn ich den Code nicht kenne, halt
10:17:11 xq: der door_state ist nur für das verhindern von doppelter ausführung
10:17:13 IceMichael: und ich stell mich bei so was absichtlich dumm mittlerweile, weil man damit Details verbessert
10:17:25 IceMichael: ja okay
10:17:37 xq: logic_state ist der state der logik
10:17:41 xq: door_state ist nur der aktuelle zustand der türe
10:17:54 IceMichael: ich würd die Funktion dann halt sm_change_logic_state nennen :D
10:18:13 IceMichael: oder sm_apply_door_state (was apply dann macht ist ungewiss, aber man weiß, es macht mehr)
10:18:15 IceMichael: na ja, naming usw.
10:18:42 IceMichael: aber ehrlicherweise ist die Klarheit des Codes für mich fast nur naming hier
10:20:10 IceMichael: ob man switch-case-state-machines ohne OOP sauberer/lesbarer kriegt, weiß ich nicht. Die Regeln stehen ja alle untereinander, ist nicht weit von deklarativ weg
10:22:09 xq: apply wäre besser, stimt
10:22:16 IceMichael: hm, ok und send_event hm... sendet das was? Es scheint ja, man würde hier eher ein event consumen, was dann den state ändert
10:22:28 xq: die bekommt man auch mit OOP nicht sauber hin ^^
10:22:40 xq: man sendet ein event an die state machine
10:22:51 IceMichael: ach so
10:23:13 xq: oooof, die main state machine wird auch wieder 2D /o\
10:23:19 IceMichael: :/
10:23:23 xq: jo
10:23:26 IceMichael: und ja, OOP bringt hier nix
10:23:34 IceMichael: also mit send verbinde ich persönlich halt immer was Externes
10:23:48 xq: du sagst "schließ mal bitte uff", und dann fängt das halt an, aber es ändert sich noch kein state
10:23:51 xq: https://mq32.de/public/b8dfbd0dbda2d06a5cfa2164545a44ed2db4d6f9.png
10:23:59 xq: das hier ist übrigens die logik des codes, den du grade anguckst
10:24:20 IceMichael: ich find, das Bild braucht's nicht mal, die Funktion schreibt das ja quasi genau so auf
10:24:30 xq: jo, aber es hilft ^^
10:24:34 IceMichael: aber send_event ändert direkt den state, oder?
10:24:44 xq: jo, jede interaktion mit dem ding ändert *potentiell* den state
10:24:55 IceMichael: ok, es signalled was oder ändert den state hm
10:25:09 IceMichael: ach ne
10:25:12 IceMichael: es ändert state oder tut nix
10:26:21 IceMichael: na ja, ich würd wohl beide Funktionen apply_door_state_change und apply_event nennen, dann ist klar, was der Input ist und "apply" ist halt ein wildcard
10:26:27 IceMichael: für alle möglichen Konsequenzen
10:27:08 IceMichael: was OOP übrigens lediglich besser macht, ist, dass ein State ein in sich gekapseltes Objekt ist und man auf einen Blick sieht, was alles passieren kann, wenn man sich in einem State befindet
10:27:23 xq: jo, stimmt
10:27:40 IceMichael: ich hab schon so viel switch-case-Code gesehen, wo doch noch irgendwo ne Bedingung (if state == dingsbums || state == bumsdings) stand, die noch nen side effect hatte
10:27:47 IceMichael: bei uns in der Firma auch, ist ne Katastrophe :D
10:27:56 IceMichael: die schlimmsten und fehleranfälligsten Teile des Codes sind übrigens immer die state machines
10:28:08 IceMichael: wie gesagt, hab noch keine sauberere Lösung gefunden für die Teile :/
10:28:19 xq: gibts auch nicht
10:28:22 xq: die sind einfach fucking komplex
10:28:31 IceMichael: ja, ist mies
10:28:39 IceMichael: aber wenn man es mathematisch formal aufschreibt ist es meist ja schon okay
10:28:47 xq: auch nur so halb ^^
10:29:10 IceMichael: ja :/ Durchreichen und globaler Kontext, das sind die zwei Hässlichmacher, find ich
10:29:19 IceMichael: aber ohne geht's ja idR nicht
10:29:56 IceMichael: man könnte höchstens noch einmal abstrahieren und sagen, states können einfach GAR nicht irgendwas beeinflussen bis auf den nächsten State, die dürfen nur Signale/Events rausballern
10:30:10 IceMichael: aber ob das hilft, puh...
10:30:19 xq: dann musst du global state im state speichern
10:30:23 xq: und dann hast du plötzlich
10:30:29 IceMichael: ja, die brauchen immer noch inputs, stimmt
10:30:35 xq: IDLE_WITH_DOOR_OPEN statt { IDLE, door_open:bool }
10:31:13 xq: bah, ich seh aktuell noch nicht so richtig, wie ich das aktuelle abbilden kann
10:32:39 IceMichael: ok, also ich würd auch sagen, in C geht es nicht viel schöner. Die breaks nerven, die {} überall auch und logs braucht man halt eh... also wenn, dann kann man nur am naming feilen
10:32:49 IceMichael: was ist denn das "aktuelle"= (was es jetzt 2D macht, nehm ich an?)
10:34:20 xq: was du dir grade angeguckt hast ist die steuerung für eine einzelne türe ^^
10:36:54 xq: folgende sache:
10:37:30 xq: https://mq32.de/public/7fb4a16f6e314b59c969d196f02fd663a3d85258.png
10:37:45 xq: das sind meine 4 zustände vom gebäude
10:38:41 xq: jetzt können diverse events in jedem zustand auftreten
10:38:51 xq: https://mq32.de/public/25f751412c8ff858847e9764f741502b2b83df22.png
10:41:41 xq: wenn du jetzt vorne aufschließen willst, machst du ein SSH-Event
10:42:57 IceMichael: ok, klar
10:43:13 IceMichael: die Matrix ist ja trivial
10:43:56 IceMichael: bei den Events ...
10:44:07 xq: heh
10:44:14 xq: und das problem ist: *alles* ist asynchron ^^
10:44:29 IceMichael: ja gut
10:44:35 IceMichael: also die Events sind halt irgendwie auf so vielen Leveln
10:44:58 IceMichael: für mich wären die physikalischen Doorteile irgendwie auf nem andren Layer als SSH
10:46:31 xq: heh
10:46:43 xq: aber: ich kann sowohl via SSH als auch via Knopf den "close"-prozess auslösen
10:46:54 xq: und am ende ist das abgesehen von nem unterschiedlichen log-event das selbe logische ding
10:48:21 IceMichael: ja gut
10:48:33 xq: das sind einfach zwei unterschiedliche inputs und gut
10:48:38 xq: kommen von aussen, und dröppeln rein
10:48:39 IceMichael: ich würd dann die zwei physischen Events in ein "OpenDoorEvent" münden lassen
10:48:53 xq: heh, "open" brauchen wir immer zwei
10:48:56 IceMichael: dann ist überall klar, dass das wirklich äquivalent ist
10:49:08 IceMichael: ach so, ja gut, close meinte ich
10:49:31 IceMichael: die 11 events würd ich bundeln, wenn es irgendwie geht, nimmt immer Komplexität
10:49:48 xq: da ist aber nix mehr zu bundlen
10:50:06 IceMichael: ich dachte, SSH Close Req und Button Close Req ist dasselbe?
10:50:09 xq: die physical locks sind: "jemand dreht am knopf"
10:50:19 xq: ja, abgesehen vom quell-punkt. das wars dann aber auch
10:50:23 IceMichael: genau
10:50:25 IceMichael: das mein ich
10:50:35 xq: das problem ist, dass wir zwei button close requests haben
10:50:39 xq: die sich unterscheiden
10:50:42 xq: vom ssh-close-request :D
10:50:47 IceMichael: irgendwo an einer kleinen Stelle sieht man diese Events überhaupt in der Form wie in deiner Liste. Und daraus werden dann "bessere" Events gebaut
10:50:56 IceMichael: ja, auch dann
10:51:06 xq: weil wenn ich bei B2 aufn knopf drücke, *wenn* abgeschlossen ist, passiert was anderes, als wenn ich auf den C2-Button drücke
10:51:32 xq: die "besseren events" brauchen aber dann alle den selben state
10:51:41 xq: da kann ich wirklich nicht mehr viel entfernen
10:51:49 IceMichael: ne, so gut wie nix
10:51:58 IceMichael: und SSH Close Req ist wie Click auf close-B2 oder close-C2?
10:52:03 IceMichael: oder close-both?
10:52:30 IceMichael: ich freu mich immer, wenn ich so was im Code sehe und da nicht einfach nur zwei switch-cases dasselbe machen
10:52:45 IceMichael: wie gesagt, ist auch wieder nur ein Detail
10:53:03 xq: IceMichael: nope, der close triggered dann potentiell *nicht* den effekt von C2 oder B2
10:53:32 xq: denn: wenn "shack closed", öffnet ein klick auf B2 dann B, und ein klick auf C2 dann C, aber ssh-close macht keine türe auf
10:53:34 IceMichael: na ja, meint Bezug war auf "aber: ich kann sowohl via SSH als auch via Knopf den "close"-prozess auslösen"
10:53:41 IceMichael: ok, klar
10:53:44 xq: richtig, aber wenn geschlossen ist, passieren andere dinge ^^
10:53:50 xq: als "close-prozess anstoßen"
10:53:52 xq: das ist state-dependent
10:54:07 IceMichael: ok klar, die Knöpfe sind open/close toggles
10:54:41 IceMichael: nur an der Stelle im Code, wo ich handle, was daraus passiert, soll mich das eigentlich nicht mehr interessieren
10:54:55 IceMichael: das toggling wurde vorher wegverarbeitet und ist jetzt irrelevant
10:56:02 xq: ne, in dem fall eben nicht
10:56:48 IceMichael: ja, so würde ich das aber aufbauen :D also wenn es toggles sind
10:57:00 xq: sind aber events ^^
10:57:00 IceMichael: ich hab das Gefühl, hier werden zu viele Ebenen vermischt
10:57:11 xq: ne, wir befinden uns tatsächlich nur auf einer ebene
10:57:14 xq: nämlich "high level logic"
10:57:45 IceMichael: also ist die für sich einfach schon zu komplex und nicht zu vereinfachen durch Aufsplitten usw.?
10:58:00 IceMichael: weil gefühlt... ihr habt zwei Türen und viele Aktoren dagegen
10:58:08 xq: yep
10:58:14 xq: wir haben 5 türen
10:58:21 xq: ssh und knöpfe als zugriff
10:58:39 IceMichael: ja. Und wenn so was schon so komplex ist, klingt das danach, als wäre noch nicht das richtige Modell dafür gefunden worden
10:58:44 xq: türen haben drei zustände und können diese jederzeit ändern
10:58:57 xq: das modell ist so minimal wie möglich
10:59:16 IceMichael: minimal ist ja nicht immer am einfachsten
10:59:16 xq: wir haben 4 bit state im system
10:59:37 xq: aber 9 gesamtzustände. die siehst du in der grafik oben
10:59:53 xq: ich hab hier ja schon die riesige state machine aus den türen an sich schon rausgeworfen und ignoriere die grade
11:01:09 IceMichael: ja die 9 States waren ja in deiner C-File, das ist ja ok
11:01:16 IceMichael: 2D wird's durch die Türenzustände?
11:01:56 xq: achtung, du verschmischt grade zwei dinge
11:02:04 xq: das C-File für die neue State Machien gibt es noch nicht
11:02:13 xq: ich arbeite grade an der zweiten State Machine auf nem anderen Device
11:02:42 IceMichael: okay
11:02:51 xq: welche jetzt eben dann primär via MQTT und SSH interagiert
11:04:12 xq: aber ich glaub, ich hab grade nen guten, lesbaren ansatz gefunden :)
11:04:39 xq: ich frag mich aber, wie ich sowas wie "rate limiting" machen kann
11:08:09 xq: weil: wenn ich jetzt die anfrage "mach uff" stelle, aber grade zugeschlossen wird, will ich nicht beides anstoßen, sondern das graceful zurückmelden, dass der request gescheitert ist
11:09:30 IceMichael: oh, was für einen?
11:09:56 IceMichael: hm, was ist daran rate limiting? ist doch einfach ne error message zurück?
11:10:15 IceMichael: so, integration tests für account removal und deserializing accounts vom NSC json input steht
11:10:32 IceMichael: bin mal kurz draußen (obwohl heiß), lese gleich, falls du was schreibst :)
11:10:52 xq: naja, rate limiting ist das falsche
11:10:54 xq: aber:
11:11:13 xq: wenn du sagst "aufschließen" ändert sich der systemzustand (shack closed/locked/open) nicht sofort
11:11:21 xq: sondern die türe fängt dann gemächlich auf, sich aufzuschließen
11:12:03 xq: wenn jetzt aber in der zeit, in der der prozess grade durchläuft, jemand zweites kommt, und aufschließen will, muss ich da ne fehlermeldung zurückgeben
11:12:12 xq: dafür muss ich aber wissen, das aktuell jemand so einen prozess angestoßen hat
11:25:30 xq: AH SHIT
11:25:38 xq: die oben gemalte state machine wird nochmal nen ticken größer /o\
11:28:33 IceMichael: re
11:29:08 IceMichael: xq: aber der Prozess des Öffnens ist doch in der Machine abgebildet, dachte ich?
11:29:18 xq: ha
11:29:24 IceMichael: oder ist's doch easy, state lesen und entsprechend zurückmelden
11:29:24 xq: der prozess des öffnens *einer türe*
11:29:38 xq: nur gibts jetzt zwei aufmach-prozesse für eine türe
11:29:52 xq: nämlich safe (mit den 60 sekunden timeout, dann wieder abschließen) und unsafe (einfach aufmachen)
11:30:19 IceMichael: ok, also die Frage, was passiert, wenn safe oder unsafe öffnen laufen und man das andre mitteilt
11:30:29 IceMichael: am einfachsten wär ja während des Prozesses beide abzulehnen
11:31:14 xq: jo, das sowieso.
11:31:21 xq: aber ich zeig dir gleich mal den code, den ich grade schreibe
11:31:24 xq: der ist *echt* lesbar
11:31:39 IceMichael: also entweder kriegt halt der shack nen state "in progress" und darüber gehst du oder du liest halt den state aller Türen aus, um irgendwie zu reagieren
11:31:46 IceMichael: ok, freue mich schon
11:32:16 IceMichael: hm, ich frag mich auch, ob der shack nicht einen virtuellen state kriegen kann, sprich: der wird nirgendwo gespeichert, sondern automatisch immer nur abgeleitet
11:32:28 IceMichael: das würde viel Konsistenz-Sicherung überflüssig machen
11:32:33 IceMichael: und Bugs verhindern
11:32:47 IceMichael: falls das alles zentral gespeichert wird
11:33:36 xq: jo, hab ich schon
11:33:37 xq: so
11:34:04 xq: ich hab nur den state beider türen gespeichert, daraus leite ich dann den state des shacks ab
11:34:14 xq: lass mich noch kiurz den gedanken fertig hacken
11:36:32 IceMichael: hm, vereinfachst du eigentlich permament? Weil du redest die ganze Zeit von zwei Türen, vorhin waren es 5
11:36:39 xq: https://bpa.st/YMGQ
11:36:50 xq: jain
11:36:53 xq: wir haben 5 türen im system
11:37:13 xq: davon haben zwei türen eine türsteuerung, zwei türen einen öffner und eine klingel und eine türe ignorier ich grade noch vollständig
11:37:37 xq: zeile 107 gehts los
11:38:16 xq: ist leider 3-dimensional geworden /o\
11:38:39 IceMichael: nice :D und die ersten Funktionen oben sind genau das, was ich meinte, damit, dass du die Events nochmal gruppierst
11:38:53 IceMichael: ok, man kann nicht nur auf der Gruppierung arbeiten, aber anyways, nice
11:39:06 xq: gibt eben fälle, wo man einzelne events bruacht
11:39:15 IceMichael: man kann sich noch überlegen, ob man die if-Bedingungen irgendwie benennen kann, das wäre dann noch schöner
11:39:16 xq: aber: überraschend gut lesbar mit KNF, oder? :D
11:39:36 IceMichael: ja
11:41:13 IceMichael: bei den ersten zwei KNFs: Woher weißt du, dass das Öffnen unsafe zustande kam, sodass du die andre Tür unsafe öffnest?
11:42:49 xq: ich bin in einem OPEN_VIA state => der kommt nur zustande, weil ich vorher mit _SAFE geöffnet habe
11:43:09 xq: ich weiß also, dass das öffnen *safe* zustande kam, nicht *unsafe*
11:43:18 xq: weil: ich könnte die türe ja auch manuell aufgeschlossen haben
11:44:08 IceMichael: wenn eine Tür safe geöffnet wurde, darf man die andre unsafe öffnen?
11:45:12 IceMichael: (btw wirklich sehr, sehr clean, nochmal ganz deutlich)
11:46:06 xq: muss man
11:46:27 xq: die idee ist folgende:
11:46:31 xq: du willst vorne ins gebäude
11:46:36 xq: also schließt du vorne auf
11:46:59 xq: wenn du durch betreten des gebäudes bestätigst, dass du physisch anwesend bist, schließt das system automatisch die hintere türe auf (damit du aufs klo kannst)
11:47:06 xq: selbiges gilt in die gegenrichtung (damit du in den keller kannst)
11:47:46 IceMichael: aber Betreten durch manuelles Aufschließen gilt ja als unsafe?
11:47:51 IceMichael: oder umgekehrt?
11:48:25 xq: achtung: "unsafe" heißt in dem kontext, dass die türe sich selbst nicht selbsttätig abschließt
11:49:21 xq: aber ja, betreten durch manuelles aufschließen möchte ich separat handlen
11:49:38 xq: weil : wenn du drin bist, kannste die türen eh einfach aufschließen durch "schlüsselmotor mit hand drehen"
11:50:20 IceMichael: ist das immer in zwei Richtungen? ich hätte gedacht, wenn ich Tür1 durchschreite, gibt's ja noch Tür2 und dessen Motor ist noch weiter innen
11:51:25 xq: guck mal hier:
11:51:25 xq: https://wiki.shackspace.de/_detail/infrastruktur/u300/plaene/u300-eg-plan_tueren_schluessel.gif?id=infrastruktur%3Aportal300
11:51:49 xq: du musst durch { B, dann B2 } oder { C, dann C2 } um in den space zu kommen
11:52:01 xq: B2 und C2 sind jeweils auf gegenüberliegenden seiten des spaces
11:52:24 IceMichael: ah okay
11:52:36 xq: B und C sind jeweils außentüren mit existenter schließanlage
11:52:42 xq: diese können wir nur kurzzeitig aufschließen
11:53:09 xq: aka: "aufn türöffner-knopf in der sprechanlage drücken)
11:54:06 IceMichael: ok
11:55:13 xq: aber: ieh.
11:55:17 xq: komplexity
11:55:29 xq: aber ich glaube, ich habe alles abgehandelt
11:56:06 xq: was noch fehlt, sind die API-Benachrichtigungen, aber das ist ein anderes thema ^^
11:57:12 xq: weil wir brauchen noch ein (permanentes) logging, welche events wann passieren
11:57:27 xq: aber dafür mach ich einfach ne hand voll callbacks und jut (on_shack_state_change, on_door_state_change)
12:04:20 xq: so
12:04:35 xq: ich geh jetzt mal zu einer freundin, erfolgreichen berufsschulabschluss feiern
12:05:09 xq: hat mir übrigens grade viel gebracht
12:05:23 xq: ich hab die neue state machine fertig und bin verdammt happy, dass der kram mit der KNF-Taktik so gut lesbar ist
12:05:40 xq: https://github.com/shackspace/portal300/blob/master/software/src/state-machine.c
12:05:55 xq: den ganzen scheiß zu testen wird so fürchterlich viel aufwand /o\
12:06:54 xq: laters oder so!
12:07:49 IceMichael: laters!
12:24:10 IceMichael: ja, bei mir wird's auch skuril. Ich lasse ja über meinen Go-Service Backend-Container starten, die eigentlich dann mit dem Frontend kommunizieren sollten, na ja
12:24:18 IceMichael: das alles lokal zu testen ist auch Spaß
12:31:52 IceMichael: wär es OSS, ginge das sogar kostenlos via GH
12:36:37 IceMichael: der Mist ist, es dauert ewig diesen doofen Container zu bauen
12:38:37 IceMichael: und c++ compilation ist auch so saulahm :/
19:37:08 Schrompf joined the channel