Seite 55 von 69

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 08:38
von joggel
Ich bin hier an einem Projekt, wo viel über Singleton-Pattern gelöst wird.
Ich finde das eine saubere Lösung.
So "müllt" man sich zB nicht die Klasse zu, mit Membern die vlt nur _Eine_ aufgabe haben. 8-)

Ich habe aber oft gelesen, das Singleton-Pattern eine "böse" Lösung ist.
Aber warum wird das so gesehen? Und gibt es da vlt eine gute/bessere Alternative?

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 09:08
von RustySpoon
Ich glaube die Diskussion hatten wir hier schon 1-2x. Ich hab das als gefährliches Terrain in Erinnerung. :p

Ich will dich da auch gar nicht belehren. Persönlich betrachte ich das als eine technische Schuld die man eingeht aber es kann gute Gründe für technische Schulden geben. Außerdem ist z.B. Ressourcenmanagement so ein Aspekt, den man früher oder später immer irgendwo zentral erledigen will oder muss. Aber: Es ist und bleibt halt globaler Zustand. Du weißt nie so richtig, wann wer das Ding wie initialisiert hat (oder eben auch nicht). Sie verschleiern halt auch gern die Abläufe im Programm, es ist halt einfach da "mal fix rüberzugreifen". Es ist die Hölle (und ein Synchronisationspunkt) in Multithreading-Umgebungen und vernünftiges Unittesten ist praktisch unmöglich.

Auf der anderen Seite benutz ich die z.B. gern, wenn ich komplett zustandslose "Verhaltensobjekte" brauch. Sowas wie ein Comparator halt, der zum Sortieren einer Liste genutzt wird. Oder ein LabelProvider in der UI, oder ein Validator, oder oder oder... Das ist aber mehr oder weniger nur eine Mikrooptimierung um nicht tausende Mikroobjekte zu spammen und funktioniert ohne die genannten Nachteile nur, wenn die komplett zustandsfrei sind.
joggel hat geschrieben:So "müllt" man sich zB nicht die Klasse zu, mit Membern die vlt nur _Eine_ aufgabe haben.
Wie meinst du das?
Und gibt es da vlt eine gute/bessere Alternative?
Das hängt davon ab, was du damit anstellst und in was für einer Umgebung du Arbeitest. Wenn es dir um die Bequemlichkeit geht auf irgendwelche Services überall zugreifen zu können, solltest du vielleicht mal dein Domänenmodell überdenken. Ansonsten kann es sicher nicht schaden, sich mit sowas wie Dependency Injection zu befassen, das sorgt imho immer ganz gut dafür, dass man solche Schweinereien lässt. ;)

Aber wie gesagt, ohne deinen konkreten Anwendungsfall und Projektsituation zu kennen, finde ich es immer schwierig sowas zu bewerten. Vielleicht ist das in deinem Fall nach wirtschaftlichen Abwägungen etc. tatsächlich die beste Lösung. :)

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 10:48
von joggel
"Wie meinst Du das?"

Ich habe hier eine Klasse (Plugin) mit mehreren Methoden (Callbacks).
Diese Methoden werden von einer anderen Stelle aufgerufen vor oder nachdem etwas passiert ist.
Es wird an einer anderen Stelle eine Kette von Abläufen abgearbeiten.
Vor bzw. nach den einzelnen Schritten werden dann Callbacks aufgerufen.
Innerhalb dieser Callbacks kann ich dann optional spezifische Aufgaben erledigen, je nach Einstellung.
Bsp:
An einer ganz bestimmten Stelle möchte ich Informationen sammeln, wenn immer ein Callback aufgerufen wird.
Nun möchte ich aber nicht in meiner Pluginklasse einen Member (CollectorXY) haben, weil der ja nicht immer benötigt wird.
Also benutze ich an dieser ganz bestimmten Stelle ein Singleton (CollectorXY::instance().add(aXYThing)).

Das meinte ich mit "So 'müllt' man sich zB nicht die Klasse zu, mit Membern die vlt nur _Eine_ aufgabe haben."

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 10:51
von DerAlbi
Ich habe auch vor kurzem auch auf Singletons umgestellt, um Hardwareressourcen über sinnvolles RAII zu verwalten. Es gibt nunmal Peripherie, die es auf einer Platine (oder im Prozessor) nur 1x gibt, und da machen mehrere Instanzen der selben Sache keinen Sinn. Das ist dann über kurz oder lang darin ausgeartet, dass ich die einzelnen Instanzen immer per Referenz durch die Konstruktoren reichen musste, damit irgendeine Popelklasse ganz unten in der Hierarchie Zugriff auf die Hardware hat. Das hat irgendwann heftig gestunken.
Mittlerweile mache ich Referenz-Counting auf ein Singleton-Objekt und da wird es einfach de-initialisiert, wenn es nicht mehr benutzt wird. Dass geht dann sogar soweit, dass sobald alle Hardware die z.B. an einer bestimmen Versorgungsspannung hängt ungenutzt ist, die Versorgungsspannung einfach abgestellt wird, weil deren Referenz auch 0 wird. Power-Management for free.
In meinem Zusammenhang ist auch die Tatsache der Zustandbehaftung gar nicht so wild. Wenn 2 Klassen gleichzeitig den gleichen Schrittmotor treiben wollen, hab ich ein Problem ganz wo anders.

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 11:45
von Chromanoid
Und wenn Du irgendwann mal einen zweiten Schrittmotor einbaust? :D

Nur Spaß, ich kann nur empfehlen Singletons großzügig zu nutzen, das spart Zeit. ABER NUR, wenn die Singletons nicht sich selbst verwalten und eigentlich wie normale Klassen entwickelt werden. Es geht mir nur um den "Lifecycle". D.h. man braucht für den sinnvollen Einsatz von Singletons am besten immer ein weiteres Singleton (Service-Registry oder was auch immer), das die anderen Singletons erzeugt und verfügbar macht. Das kann auch Dependency Injection sein, muss es aber nicht.

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 11:52
von DerAlbi
Naja, da ein zweiter Schrittmotor auch technisch etwas anderes machen wird, wird eine zweite Instanz ein getrenntes Singleton-Objekt werden.. Wenn beide Schrittmotoren zusammenarbeiten (ich hab sogar zwei) sind nicht die einzelnen Schrittmotoren die eigentliche Ressource (wenngleich die für sich selbst dem RAII-Schema folgen, da es getrennte Ansteuer-ICs sind), sondern die Engine, die die Schritte zwischen beiden Synchronisiert [und die 2 Schrittmotoren als Member hat].

Ich glaub du hast editiert, als ich geantwortet habe ^_^

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 11:54
von Chromanoid
DerAlbi hat geschrieben:Ich glaub du hast editiert, als ich geantwortet habe ^_^
Genau, hab's jetzt noch mal hier reingeschoben: Im Falle des zweiten Schrittmotors kann man einfach zwei unterschiedlich benannte "Schrittmotor-Singletons" verwalten, die als Klasse zwar mehrfach instantiiert werden, vom Lifecycle her aber wie Singletons funktionieren.

Der größte Nachteil bei solchen Späßen ist meiner Erfahrung nach eigentlich immer nur Testautomatisierung bei verteilten Systemen (die dann nicht im gleichen Prozess laufen dürfen, da sie sich sonst die Singletons teilen) und aus dem gleichen Grund die Parallelisierung von automatischen Tests. Daher kann es durchaus Sinn machen, sich da etwas mehr Gedanken zu machen, wie die Singletons adressiert werden.

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 12:16
von DerAlbi
Ich weiß nicht, ob das in meinem Fall mit Hardware-Instanzen Sinn macht. Ein zweiter Motor wird z.B. über andere Pins angesteuert werden, dadurch wäre die Klasse nicht die selbe sondern würde sich mindestens in den Template-Argumenten unterscheiden. Ich glaube das ist bei enorm viel Hardware so.. (zumindest mit dem Mikrocontroller-Zeugs mit dem ich hier gerade rumwerkel)

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 14:18
von Matthias Gubisch
Also ich versuche auch bei Hardware-Instanzen eine Singelton Implementierung zu vermeiden.

Meine Klasse wird dann zwar ähnlich dem SingletonPattern genutzt weil ich in dem Fall ein globales Objekt anlege auf das dann alle zugreifen.
Aber es gibt mir die Freiheit sofort eine zweite Instantz mit unterschiedlichen Parametern (in deinem Fall zum Beispiel die Pins) zu erzeugen sollte es doch mal eine zweite Instanz von etwas geben.
Bei externen Resourcen halte ich das sogar für relativ Wahrscheinlich während sich bei internen Microcontrollerresourcen selten was ändern wird.

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 15:50
von DerAlbi
Globale Objekte sind für mMn so etwas keine gute Lösung. Ich arbeite z.B. mit einem STM32 (mehreren). Dort hat z.B. die interne Peripherie Glock-Gating (man kann die lahmlegen und damit Strom sparen). Dadurch macht RAII mehr sinn, weil man sich um das Ein/Ausschalten der Clock z.B in einem Konstruktor/Destruktor kümmern kann. Dafür muss man aber tracken, welche Clock wie oft referenziert wird usw. ICh würde auch in kleinen Mikrocontrollern soweit gehen, das Konzept zu verteidigen. Wer keine statische Speicherverwaltung nutzt [nutzen kann], kann den Singleton einfach mit placement-new in einem statischen char-Array entsprechender Größe erzeugen. Funktioniert super :-)

Re: Anti-Jammer-Thread

Verfasst: 26.04.2018, 19:57
von joggel
Ich glaube ich werde mal in Zukunft den Ansatz globaler Instanzen bzw. Singletons etwas verfolgen...also für mein nächstes Projekt.
Mal so am rande erwähnt..

Re: Anti-Jammer-Thread

Verfasst: 27.04.2018, 13:47
von joeydee
Weiß nicht ob Anti-Jammern oder eher doch Jammern: OpenGL 4 compiliert und läuft nun auch auf dem Mac. PC war problemlos.

Probleme waren u.a.:
- Andere Header für Extensions (für Shader-Pipeline) -> andere Reihenfolge der includes (auch im Zusammenspiel mit SDL)
- Mac hat Versionsanforderung 3.x ignoriert und scheinbar immer automatisch auf 4.1 forward compatibility geschaltet. Plötzlich hagelt es "invalid operations" für Funktionen, die ich nach spec eigentlich vorausgesetzt hatte. Scheint, dass ich nun 4.1 als gemeinsamen Nenner nehmen muss, zumindest für meine Geräte.
- Mein PC verarbeitet dann (unter 3.x und glew) z.B. glDrawElements(GL_QUADS) oder glUniformMatrix4dv(), Mac mag die nüscht. Natürlich ohne Compile- und Laufzeitfehler.
- Der Rest war hausgemacht, da ich z.B. das genaue Zusammenspiel von VBOs und VAOs doch noch nicht so gut kannte. Auch hier scheint der PC mehr zu "verzeihen".

Naja, viel Zeit und Nerven verloren, aber jetzt gehts erstmal. Bin gespannt obs der PC heute abend auch wieder schluckt.
Bis zum nächsten Problem.

Re: Anti-Jammer-Thread

Verfasst: 27.04.2018, 14:24
von xq
- Mac hat Versionsanforderung 3.x ignoriert und scheinbar immer automatisch auf 4.1 forward compatibility geschaltet. Plötzlich hagelt es "invalid operations" für Funktionen, die ich nach spec eigentlich vorausgesetzt hatte. Scheint, dass ich nun 4.1 als gemeinsamen Nenner nehmen muss, zumindest für meine Geräte.
Das ist soweit ich weiß legal mit nem Forward Compatible Context (weil alles ab 3.3 sinnvoll rückwärtskompatibel ist), da du "mindestens 3.3" anforderst und in den nachfolgenden Versionen alles aus den Vorgängern enthalten ist
- Mein PC verarbeitet dann (unter 3.x und glew) z.B. glDrawElements(GL_QUADS) oder glUniformMatrix4dv(), Mac mag die nüscht. Natürlich ohne Compile- und Laufzeitfehler.
GL_QUADS ist seit OpenGL 3 depreciated: https://www.khronos.org/registry/OpenGL ... rays.xhtml
glUniformMatrix4dv ist ne extension, https://www.khronos.org/registry/OpenGL ... r_fp64.txt die wohl nicht überall verfügbar ist. Ist ab OpenGL 4.0 Teil von Core. Mit http://realtech-vr.com/admin/glview bzw. glxinfo unter Linux. Auf Mac OS weiß ich es leider nicht
Auch hier scheint der PC mehr zu "verzeihen".
Falls du nen NVIDIA-Grafiktreiber hast: Mein Beileid, die "fixen" all deine Fehler ohne mit der Wimper zu zucken und reporten dafür nicht mal Diagnostics. Der Code tut dann halt auf AMD und Intel nicht, weil er nach OpenGL-Standard nicht legal ist

Re: Anti-Jammer-Thread

Verfasst: 27.04.2018, 15:50
von joeydee
Mac: AMD Radeon R9 M395; PC: AMD Radeon R7 200
Warum Quads und dv nicht gehen hatte ich schnell rausgefunden, nachdem ich die Fehler weiter eingrenzen konnte. Erst dadurch bin ich darauf gekommen, dass was mit der angeforderten vs. tatsächlichen Version nicht stimmen kann.
Muss ich mir nochmal genauer ansehen, ich verstand das irgendwie anders mit forward und backward, aber bin ja lernfähig.

Re: Anti-Jammer-Thread

Verfasst: 09.05.2018, 14:02
von joggel
Bild

Re: Anti-Jammer-Thread

Verfasst: 09.05.2018, 17:47
von Krishty
Kommentar zur Nachricht, dass Notepad nun auch Linux- und MacOS-Zeilenumbrüche (CR und/oder LF statt CR+LF) darstellen kann (https://blogs.msdn.microsoft.com/comman ... n-notepad/):

Notepad ist tatsächlich bloß ein Fenster mit riesigem Standard-Edit-Feld (Common Control, um in der Win32-Sprache zu bleiben). Das konnte nie was anderes als CR+LF – und das ist ein scheiß Problem bei plattformunabhängiger UI-Programmierung. Auf Windows muss man bei allem, was man ausgibt, die Zeilenenden ändern. Ich hoffe tief und innigst, dass die Meldung bedeutet, dass Standard-Edit-Felder nun ebenfalls alle Arten von Zeilenenden schlucken. Ich habe kein Windows 10, um das zu testen – aber wenn es ginge, wäre die Tragweite klar.

Re: Anti-Jammer-Thread

Verfasst: 09.05.2018, 22:42
von Krishty
And last, but not least in this section, I want to highlight that Visual C++ is now conforming to ++11, C++14, and C++17. Yes: the MSVC compiler toolset in Visual Studio version 15.7 conforms with the C++ Standard!
Wenn mir das vor fünf Jahren jemand prophezeit hätte … ich hätt’s nicht geglaubt.

Re: Anti-Jammer-Thread

Verfasst: 21.05.2018, 23:39
von Krishty
Mein Viewer kompiliert endlich vollständig mit Clang (ohne Microsoft-Erweiterungen, -fno-ms-extensions!).

Das war ein langer Weg.

Bisher sind die Ergebnisse unterirdisch:
  1. die Debug-Version zeigt kein Bild an (bestimmt ein Typo in meinem ungetesteten Vektor-Code)
  2. die Release-Version stürzt ab
  3. die PDB enthält nur Funktionsnamen; keine Quelldatei- oder Zeilenangaben (Debugging wird lustig …)
  4. die Executable ist fett (ich bin leider noch mit Microsofts CRT unterwegs)
  5. ich habe noch keinen Plan, wie ich das Icon einbinde (da muss es aber was geben)
  6. ich bin völlig ratlos, wie ich die statische Analyse ausführen soll
Der Weg wird auch lang bleiben:
  • Manifest von Hand erzeugen statt durch Visual C++
  • Debug-Informationen geradebiegen
  • Debugging
  • mit allen Warnungen kompilieren
  • mit -fsanitize=undefined kompilieren
  • libc statt VCRT einbinden
  • Icons etc. einbinden
… danach habe ich dann hoffentlich einen schönen Compiler-Vergleich. Bestenfalls auch ein besseres Programm.

Ein mega Ärgernis war: __builtin_assume() schmeißt eine Warnung, falls der Ausdruck Side Effects hat. Eigentlich eine gute Idee, würde Clang nicht immer für jede Funktion Side Effects annehmen. Da ich Assumptions im Debug-Modus als Assertions nutze, habe ich aber überall sowas wie assert(isEmpty(data));. Also musste ich 2000 Funktionen __attribute__((pure)) und __attribute__((const)) deklarieren, damit diese Warnungen verschwinden.

Besonders lustig ist in diesem Zusammenhang, dass die Built-Ins von Clang selber nicht korrekt deklariert sind. Ich kriege also Warnungen, wenn ich sowas schreibe wie

  assert(0x000 == (0xFFF & __builtin_ia32_pmovmskb128(min > max))); // All lanes of min must be <= max!

  Warning: '__builtin_assume' has side effects that will be discarded [-Wassume]

Re: Anti-Jammer-Thread

Verfasst: 25.05.2018, 23:28
von Krishty
Jahrelang habe ich auf das Horror-Survival-Driving-Game von Ondrej Svadlena gewartet, und nach langer Stille ist nun plötzlich die Beta raus: https://www.indiedb.com/games/beware/do ... eware-demo
*den Download anfeuer*

[youtube]J4xDWW_4oQs[/youtube]

Nachtrag: Hier leider komplett unspielbar. Ich habe zwar gute 30 fps, aber immer nur eine Sekunde Gameplay, bevor das Spiel für 30 Sekunden in eine Stasis geht, die im Task Manager extrem nach Garbage Collection aussieht. Wenn ich den Debugger anhänge, rauscht alles in einen Nullzeiger-Zugriff :(

Nachtrag 2: Oh, die Log-Datei hat 115.000 Zeilen und davon jede Menge NullReferenceExceptions. I’m not going to space today.

Nachtrag 3: Lol ich hab’s einfach ein paar Minuten im Hintergrund laufen lassen und nun ist’s flüssig. Na dann … Head Bobbing ist sehr stark … selbst für mich, und ich bin eigentlich Fan davon.

Nachtrag 4: Habe den Bugfix: Spiel starten und abwarten, bis es hakt. Dann einen Debugger anhängen. Der ersetzt den Exception Handler des Spiels und meldet eine Access Violation. Dann den Debugger abklemmen. Der Thread mit dem Nullzeiger stürzt ab und das Spiel läuft endlich normal weiter. Nee, doch nicht; muss Zufall gewesen sein. Wenn es endlich läuft, ist es aber echt krass.

Re: Anti-Jammer-Thread

Verfasst: 26.05.2018, 23:13
von Schrompf
Hab das immer auf TigSource verfolgt, aber ich fürchtete schon, dass es ein klassisches Asset-Store-Zusammengekauft-Opfer wird.

Re: Anti-Jammer-Thread

Verfasst: 27.05.2018, 00:16
von Krishty
Die Assets sehen nicht eingekauft aus (bei seinem Hintergrund erwarte ich das auch nicht) und ich verfolge das vor allem weil er Künstler ist statt Techniker. Als ich das erste Mal entdeckt wurde, war das auch verdammt geil gemacht – da ist mir auch wirklich das Herz in die Hose gerutscht. Aber die Demo läuft halt technisch beschissen. Anscheinend nur bei mir und offenbar durch ein bestimmtes Nullptr-Objekt, das die ganze Zeit Unitys C#-VM zumüllt, und dann nach vielen Minuten verschwindet … aber dafür ist es halt die Beta eine einzel-Entwicklers.

Das einzige, was mich bisher substanziell stört, ist die Bewegung des Kopfes beim Lenken. Davon wird mir fast schlecht, obwohl ich da eigentlich richtig tolerant bin und auch in meinem Flugsimulator richtig drauflatze. Ich muss Zeit zum Weiterspielen finden, und zwar UNBEDINGT im Dunkeln.

Ich muss auch nochmal hervorheben, dass das Spiel einen wirklich GARNICHT an die Hand nimmt. Es wird nichts erklärt, es gibt kein HUD, nichts. Man muss wirklich vorgehen wie im echten Leben. Irre.

Nachtrag: Ich möchte ihm gern die Log-Dateien schicken, aber das geht nicht. info@ondrejsvadlena.com und contact@ondrejsvadlena.com schmettern meine Mail ab. Einen Twitter-Account habe ich nicht. Im Read Me stehen keine Kontaktinformationen. Das ist einfach nur unprofessionell :(

Re: Anti-Jammer-Thread

Verfasst: 27.05.2018, 14:04
von Schrompf
Oh, grafisch und atmosphärisch finde ich das großartig. Aber man kann ja auch Code im Asset Store kaufen, und das meinte ich mit "Zusammengekauft". Ich wünsche ihm trotzdem viel Glück, denn athmosphärisch und konzeptuell finde ich das Projekt enorm interessant.

Re: Anti-Jammer-Thread

Verfasst: 28.05.2018, 04:22
von Krishty
Stimmt; AFAIK hat er aber auch ewig (*zu* viel?) in seine selbstgebaute Matschphysik und seine selbstgebauten Karosserieklänge investiert. Mal die nächste Version abwarten.

————

OK, Google: Elon Musk Bald

Re: Anti-Jammer-Thread

Verfasst: 29.05.2018, 19:49
von mrz
Gerade Flatout und Flatout 2 für ~3 EUR bei gog gekauft und dazu noch gratis "Lure of the Temptress", "Beneath a Steel Sky" und "Flight of the Amazon Queen" mitgenommen.

Re: Anti-Jammer-Thread

Verfasst: 30.05.2018, 09:16
von Jonathan
Ahhh, Flatout, was für eine geniale Rennspielserie. Flatout 2 ist auch das einzige Rennspiel bei dem man, wenn man kurz vor der Ziellinie Zweitplatzierter ist und der Wagen vor einem aus der letzten Kurve fliegt, auf den Sieg pfeift und ihm hinten rein fährt um den Crashbonus zu bekommen. Ganz besonders, wenn es Sofia Martinez dieses Miststück ist :D Das Spiel macht einfach soo viel richtig :)

Re: Anti-Jammer-Thread

Verfasst: 30.05.2018, 23:03
von Krishty
Schrompf hat geschrieben:Oh, grafisch und atmosphärisch finde ich das großartig. Aber man kann ja auch Code im Asset Store kaufen, und das meinte ich mit "Zusammengekauft". Ich wünsche ihm trotzdem viel Glück, denn athmosphärisch und konzeptuell finde ich das Projekt enorm interessant.
Fehler gefunden: Ihr dürft nur EIN MAL auf Play drücken. Ich habe den Button einfach so lang dauergeklickt, bis was passiert ist. Dann aht sich das Spiel hundert Mal resettet, bevor ich spielen konnte. Wenn ich einmal drücke und einfach eine Minute warte, startet alles bestens.

Ich habe nun den aktuellen Build getestet, und … wow.
  • Der schönste Nacht-zu-Tag-Übergang, den ich je spielen durfte.
  • Spielt bei völliger Dunkelheit.
  • Lasst euch nicht entdecken. Die KI ist mörderisch und ihr habt keine Chance, wenn ihr einmal entdeckt wurdet.
  • Das Gelände ist riesig. Ein unfassbar großes Labyrinth; trotzdem wiederholt sich keine Ecke. Wie er das alles allein geschafft hat, ist mir ein Rätsel. Allein die Architektur – vom Camping-Platz über die Ferienhäuser bis zum Viertel mit den Designer-Villen …
  • Sucht die Frau mit der Taschenlampe. Falls ihr sie nach einer Stunde noch nicht gefunden habt, guckt euch ein How-To an.

Re: Anti-Jammer-Thread

Verfasst: 13.06.2018, 16:44
von xq
Auch wenn ich gerne über die moderne Computerwelt abrante, ist es schon alles ziemlich geil:
Ich sitze hier, habe eine virtuelle Maschine auf einem Rechner, in dem eine PCI-Messkarte verbaut ist und ein Seriellport. Beide Geräte werden in die VM durchgereicht.
Die VM emuliert jetzt einen virtuellen Seriellport, welcher den physischen Seriellport doubled und mir zusätzlich, den Port via TCP "fremdzunutzen".

Auf meinem Rechner habe ich via VNC eine Verbindung zur virtuellen Maschine und via Putty kann ich dem Seriellport beim Arbeiten zugucken...

Das is schon geil, dieses vernetzte Arbeiten

Re: Anti-Jammer-Thread

Verfasst: 14.06.2018, 14:31
von joggel
Ich habe mir heute beiläufig ein paar Videos/Demos/Dokumentationen/etc von Qt5+ angeschaut:
Sieht ziemlich cool aus, und ich bekomme irgendwie unheimlich Motivation damit wieder mal etwas zu machen :)

Re: Anti-Jammer-Thread

Verfasst: 14.06.2018, 16:09
von xq
Qt5 ist auch n echt ordentliches Stück Software, mit dem man arbeiten kann, mach ja auch viele UI-Sachen damit

Re: Anti-Jammer-Thread

Verfasst: 22.06.2018, 22:35
von Chromanoid
Wir sind jetzt zu dritt :D