Forward Declaration to different namespaces

Aktuelle arbeite ich an einem kleinen Fix um forward declations in den header files für Klassen, die nicht im aktuellen namespace enthalten sind, zu realisieren.

Das ganze wird ein wenig problematischer wenn man mehrere in einander geschachtelte namespaces hat, aber forwards für einen namespace braucht, der in einem namespace subtree liegt.


namespace ackbar
{
namespace db
{
//
// This is the class
class three {
public:
///
/// @brief TODO
///
/// @param[] aIn
/// @return
///
gui::two convert(gui::one aIn) ;
};

Der vollständige namespace für die Klassen one und two ist “ackbar::gui”. Dafür müsste man also so was generieren.

namespace ackbar
{
namespace gui {
class one;
class two;
}
namespace db
{
//
//  This is the class
class three {
public:
    ///
    /// @brief TODO
    ///
    /// @param[] aIn
    /// @return
    ///
    gui::two convert(gui::one aIn) ;
};

one und two liegen in einem anderen subtree. Das ganze muss natürlich auch noch funktionieren wenn die beiden Teilbäume beliebig tief sind. Denn letztendlich können Klassen, und damit forwards, in jedem namespace auftauchen.

Aktivlautsprecher Prototyp B

Es hat alles ein bisschen gedauert, aber der Prototyp hat ein Upgrade bekommen. Ich habe den Raspberry Pi durch einen Teensy4.0 ersetzt. Wo vorher ein vollwertiger Linux-Rechner seine Arbeit verrichtet hat, werkelt jetzt ein ARM-M7 Micro-Controller ohne OS.

charset=InvalidCharsetId binary comment

Es werden weiterhin HifiBerry Komponenten benutzt um das Audiosignal zu digitalisieren und wieder zurück in die analoge Welt zu transformieren. Nur das der kleine Käfer dort oben innerhalb von 1 Sekunde die Initialisierung des Systems erledigt und super zuverlässig seinen Arbeit, das Filtern der Audiodaten, verrichtet.

Da kann ein Raspberry Pi nicht so ohne weiteres mithalten. Vor allem die vielen Aktivitäten die in einem Linux-System stattfinden, ob man sie braucht oder nicht, machen ein Linux basiertes System für diese spezielle Aufgabe untauglich.

Aber für einen ersten Funktionstest wars gut.

Aktivlautsprecher Prototyp

Ich hatte vor ein paar Monaten aus langer Weile einen Versuch unternommen einen Aktivlautsprecher zu bauen, in dem ein Raspberry Pi als digitale Frequenzweiche fungierte.

Aktivlautsprecher Komponenten

Das hat wunderbar funktioniert, auch wenn beim zweiten Lautsprecher irgendwie der Tief-Mitteltöner verrutscht ist. 😀

Das Holz habe ich aus meinem Restelager genommen, da war noch eine alte Tischplatte übrig.

So sieht das aus

Der Klang ist absolut überzeugend, wenn es auch immer noch ein paar technische Probleme mit dem Raspberry Pi gibt. Aber für ein Experiment hat das alles wunderbar funktioniert.

Software des Simulated-Universe

Auch wenn am Ende kein Browsergame entstanden ist, sind dabei doch viele tausend Zeilen Programm-Code und ein paar interessante Entwicklungs-Tools entstanden.

  • Simulationskern (Application-Core)
  • UML2 Code-Generator (Model2Text Translator)
  • Simulationstester

Simulationskern (Application-Core)

Ich bin dabei die Bezeichnung ein bisschen abzuändern, weil es eben nicht mehr nur ein Simulationskern ist. Das ist jedoch nicht ganz so einfach, weil sie das ursprüngliche Einsatzgebiet durch das gesamte Projekt zieht.

Es ist also nicht ganz einfach aus einem Simulationskern einen Applikationskern zu machen.

Im wesentlichen erfüllt dieser Kern folgende Aufgaben:

  • Kommunikation mit den Clients
  • Kommunikation mit den Datenbanken
  • Laden und Ausführen der Anwendung
Grobe Struktur

UML2 Code-Generator (Model2Text)

Eine der größten Herausforderungen für die Entwicklung einer Anwendung ist eine konsistente Abbildung des Ist-Zustands der Entwicklung.

Grundsätzlich bietet sich dazu die Verwendung eines UML-Modellers an. Die aktuelle Version 2.x definiert eine ausreichende Menge an Modellelementen um alle wesentlichen Bestandteile einer Software beschreiben zu können.

Was jedoch in all den Jahren der Nutzung von UML und UML2 kaum Beachtung fand war die Bereitstellung eines alltagstauglichen Tools, mit dem man die erstellten Modelle in passende Artefakte umwandeln konnte.

Parallel zu der Entwicklung der Kernsoftware ist daraus ein UML2 Code-Generator (aka M2T Translation) entstanden der sich bei mir im täglichen Einsatz für meine diversen Versuche auch kontinuierlich weiter entwickelt.

Aktuell wird er nur zusammen mit StarUML verwendet, da dieses auf allen wichtigen Plattformen zur Verfügung steht. Das Design ist jedoch darauf ausgelegt beliebige UML2-Modeller zu unterstützen. Es wird lediglich ein entsprechender Parser benötigt, der das Modell einliest.

Es werden folgende Programmiersprachen unterstützt:

  • C/C++ (inkl. Qt specials)
  • Simulation-Core description
  • PHP
  • JScript

Da ich im allgemeinen kein PHP und auch kein JScript in meinen Entwicklungen verwende ist der Support entsprechend unvollständig.

Simulationstester

Sowohl nach außen als auch im inneren des Simulationskerns wird mit Messages und Signalen kommuniziert. Wenn an dieser Kommunikation auch noch unterschiedliche Clients beteiligt sind, dann wächst der Testaufwand für die Simulation extrem an und ist schnell nicht mehr von einem einfachen Entwickler zu bewältigen.

Deshalb ist aktuell eine Test-Software in der Entwicklung die in der Lage ist die Simulation mit Messages zu stimulieren und die Reaktionen auf diese Messages auszuwerten.

Für die Auswertung können auch die Datenbanken abgefragt und die darin gespeicherten Werte geprüft werden.

Es werden ganze Test-Suiten in XML-Dateien gespeichert die dann aus einer ganzen reihe von einzelnen Tests bestehen können.

Historie des Simulated-Universe

Ungefähr um das Jahr 2007 herum bin ich durch Zufall über eine kleine Gruppe Browsergame begeisterter Leute gestolpert, die gerne ihre eigenen Ideen in einem Browsergame verwirklicht sehen wollten.

Ich hatte solche Spiele auch schon gespielt und fand den Gedanken faszinierend, mit vielen Spielern gleichzeitig auf einem Spielfeld unterwegs zu sein.

Da sich in der Gruppe kein einziger Programmierer befand, dachte ich mir, man kanns ja mal versuchen.

Ich hatte mir bis dahin keine nennenswerten Gedanken darüber gemacht, wie man ein Browsergame überhaupt lösen könnte. Oder um es deutlicher zu sagen. Ich hatte von Web-Programmierung überhaupt keine Ahnung. Doch das machte die Sache nur noch interessanter.

Während ich mir das nötige Know-How angelesen habe, haben die anderen immer größere und gewaltigere Ideen ausgebrütet. Das ist, wie ich finde, auch völlig in Ordnung, denn man wollte ja was besonderes kreieren.

Nur leider besserte sich die Situation bezüglich der Anzahl der Programmierer überhaupt nicht. Nun finde ich Unmögliches besonders reizvoll, weshalb ich trotzdem dabei geblieben bin. Aber wie sollte man das schaffen?

Größtes Problem dabei war, das ich zwar schon ein recht guter C/C++ Programmierer war, aber von PHP/JS/HTML und was es sonst noch alles gibt, keine Ahnung hatte. Da ich aber in meiner täglichen Arbeit eh nur in C/C++ programmierte, machte es in meinen Augen aus Gründen der Effektivität keinen Sinn noch PHP & Co zu lernen.

Wenn ich das ganze in C/C++ programmieren würde, so hatte ich jedenfalls den Eindruck, dann wäre es letztendlich kein Problem die angedachten Feature auch wirklich zu realisieren.

Dabei würde man wohl am sinnvollsten eine Simulation programmieren in der das Browsergame ablaufen würde. Da wären auch meine Künste aus der C/C++ Programmierung genau am richtigen Ort.

Für die Versorgung des Frontends würde man einen Standard LAMP installation verwenden können. Wenn sich also später noch ein PHP Programmierer finden lassen würde, dann könnte man die Arbeit aufteilen und alles wäre schick gewesen.

Ein wesentliches Problem, das sich weder mit der einen noch der anderen Programmiersprache so einfach lösen lässt, ist die Komplexität und der dadurch mit der Pflege einhergehende Aufwand.

Es brauchte eine Strategie, die es relativ leicht machte, neue Komponenten hinzuzufügen ohne das dabei der bereits funktionierende Teil fehlerhaft wurde. Denn ein Spiel blieb nur solange attraktiv, wie man in der Lage war kontinuierlich neue Inhalte hinzuzufügen. Es würden also kontinuierliche Updates erfolgen. Das würde bei den ersten zwei oder drei Updates wohl recht zuverlässig funktionieren, aber dann neigten die mir bekannten Software-Systeme dazu soviele Fehler zu produzieren, das man eher das ganze neu programmieren musste.

Aus diesen wenigen Anforderungen enstand die Idee zu einer allgemeinen, leistungsstarken Simulation. Um meine eigenen Arbeiten von denen der restlichen Gruppe ein wenig zu trennen und mir die Möglichkeit einer Vermarktung offen zu halten, habe ich dann nach einem treffenden Namen gesucht.

Daraus ist “The Simulated-Universe” entstanden.

Ein Browsergame auf dieser Basis ist jedoch nie entstanden.

Hardware im Einsatz

Immer wenn mir jemand Fragen stellt und ich der Meinung bin, dass die Antwort auch andere interessieren könnte, erstelle ich einen neuen Beitrag.

Jetzt mal zum Thema Hardware. Da gibt es natürlich massenhaft Infos im https://foldingforum.org/

Trotzdem mal ein bisschen was aus der exotischen Ecke.

Das ist ein Tyan – S4985 Mainboard und schon ein bisschen historisch. Hier ist das Board noch als Server im Einsatz. Später hatte ich dann eine Grafik-Karte eingebaut und das Ding als Workstation benutzt.

Da das Boardformat (SSI-MEB) in die Kategorie “riesig” gehört, war es pures Glück noch ein Gehäuse bei Coolermaster auftreiben zu können. Für die Boards im Format SSI-MEB (13″x16″) gibt es nur wenig Tower- und Rack- (19″ Breite) Gehäuse.

Hauptproblem ist die Unterbringung der Stromversorgung, da in den Rack-Gehäusen in der Breite ja nur 3 Zoll übrig bleiben. Aber auch sonst ist da nicht viel Spielraum für Ware von der Stange.

Die CPU-Lüfter durften nicht mehr als 90mm Durchmesser haben, damit die Lamellen der Heatpipe-Kühler sich nicht gegenseitig beim Einbau behindern. Mit den dort verbauten Kühlern war beim normalen Arbeiten bis zu einer mittleren Last kaum was von unterm Tisch zu hören.

Das Board ist mittlerweile als Dekoration im Einsatz.

Das Gehäuse beherbergt nun einen neue Power-Workstation.

folding@home in Berlin-Germany

Die Gründung dieses Teams ist schon so verdammt lange her, ich hab’ es glatt verdrängt. Irgendwann zwischen 2004 und 2007 sollte das liegen.

Ich hielt damals nicht nur die Idee an sich für Super. Vielmehr wollte ich die Folder der Stadt Berlin in einem gemeinsamen Team versammeln. So würden die Anstrengungen einer ganzen Region sichtbar werden.

Das gemeinsame Arbeiten an Lösungen, die nicht nur für einen persönlich wichtig sind, sondern vielmehr alle Menschen dieser Welt betreffen, stellt in meinen Augen eine wichtige Entwicklung der Gesellschaften unserer Welt dar.

Nur wenn das Denken und Handeln nicht mehr nur auf den eigenen Vorteil gerichtet ist, werden die Menschen in der Lage sein eine Weltgemeinschaft zu bilden in der unser aller Mutter Erde einen gleichberechtigten Platz haben wird.

Ist das alles zu idealistisch?

Ja. Aber ohne Ideale ist das Leben doch recht langweilig.