Bereits in einem früheren Beitrag wurde die Unterstützung von getakteten Modulen diskutiert. In diesem Zusammenhang habe ich über die Möglichkeit der Nutzung von Methoden mit mehr als einem Parameter als Eingänge für Module nachgedacht...
Die Idee hierzu kam mir während einer Autofahrt. Ich werde sie zunächst einmal so formulieren, wie sie mir
zwischen zwei Schlaglöchern erschien - es kann sein, dass ich sie in zwei Wochen (oder Tagen) für Humbug halte. Dann werde ich das natürlich
ebenso hier dokumentieren.
Es besteht ja immer ein Problem bei Anwendungsfällen, in denen ein Modul mehrere Eingänge hat, die aber irgendwie synchronisiert werden müssen - was ich meine ist, dass die Verarbeitung des Modules noch nicht loslaufen darf, wenn zwar an den Eingängen A und B bereits zwei Botschaften eingetroffen sind, an Eingang C aber noch keine einzige.
Bisher wurde dieser Anwendungsfall in dWb+ nicht adressiert: jede eingehende Botschaft startet die Verarbeitung - wenn an einem der Eingänge noch keine Botschaft angekommen war, muss das Modul damit klarkommen. Das Modul selbst kann natürlich so implementiert sein, dass es einfach keine Verarbeitung durchführt, wenn einer der Eingänge noch keine Daten empfangen hat - aber dann ist das eben Sache des Moduls und nicht des Frameworks dWb+.
Es existiert bisher nur eine Hilfestellung für das Synchronisieren von Inputs durch das Framework: sogenannte getaktete Module: Dabei ist es so, dass die Botschaften an den Eingängen nicht sofort an das Modul weitergegeben werden, sondern erst dann, wenn eine Botschaft an einem speziellen Eingang - dem sogenannten Takteingang - empfangen wird. Das entspricht ein wenig dem Vorgehen in digitalen Schaltungen.
Die eigentliche Idee war jetzt, auch Methoden mit mehreren Parametern als Eingänge in dWb+ zu betrachten, wobei dann gelten soll, dass die zugehörige Methode erst dann aufgerufen wird, wenn seit Instantiierung des Moduls oder seit der letzten Ausführung der Methode für jeden Parameter mindestens eine Botschaft eingegangen ist.
24.06.2018
Nachdem ich vor einiger Zeit die Planung von Wrappern für Module angekündigt habe, steht die dafür notwendige interne Umbau der Lösung nunmehr vor dem Abschluss...
Derangement - theoretische Betrachtungen
23.12.2020
Ich habe bereits über meine Implementierung eines Derangement berichtet - hier noch einige theoretische Nachbetrachtungen...
WeiterlesenAndroid Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Go GUI Gui Hardware Java Java. Komponenten Jupyter JupyterBinder Komponenten Links Linux Markdown Markup Music Numerik OpenSource PKI-X.509-CA Präsentationen Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
Asymmetrische KryptographieIch habe mich mit der Idee schon länger getragen: Nochmal einen Rundumschlag zu asymmetrischer Kryptographie zu machen. Dabei werde ich mich auf Demonstrationen der einzelnen Konzepte und Operationen mit Beispielcode konzentrieren und zu jedem der vorgestellten Konzepte mehr oder weniger ausführlich bezüglich der Einsatzszenarien und Vor- und Nachteile Stellung beziehen
WeiterlesenDieser Vortrag wurde zum 39C3 eingereicht und abgelehnt. Ich möchte einige Open-Source-Frameworks für verschiedene Programmiersprachen vorstellen, mit denen sich Architekturregeln pro Projekt oder Organisation festlegen und mithilfe gängiger Testinfrastrukturen durchsetzen lassen.
WeiterlesenDas ist ein Abstract eines Vortrages, den ich auf dem 39C3 halten wurde, der aber abgelehnt wurde
WeiterlesenManche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen Codeberg-Repositories findet man hier.