Motivation bei Privatprojekten (Split aus Diamond of Death)
-
Ich war halt Stolz darauf, ist das denn ein Verbrechen?
-
314159265358979 schrieb:
Ich war halt Stolz darauf, ist das denn ein Verbrechen?
ErbrauchtAufmerksamkeit schrieb:
Aha.
314159265358979 schrieb:
Ja genau, ich suche mit einem nicht mal annähernd fertigen Projekt Aufmerksamkeit. Du hast mich durchschaut
-
Dass ich stolz bin, impliziert nicht, dass ich Aufmerksamkeit suche.
-
Wenn mans dann zeigt vieleicht irgendwie schon.
Find ich aber auch kein Bischen schlimm. Extrinsische Motivation ist ein starker Faktor und zusätzlich zu technischen Tipps kann Zuspruch genauso nützlich sein. Im Tricking-Forum (so eine Art Akrobatik), in dem ich sonst viel bin, postet man ständig Videos von seinen Sprüngen und bekommt dann gesagt, dass das, was man tut, super ist.
Wenn man beim Programmieren keinen Chef hat, der einem mal "Hey, gut gemacht, weiter so." sagt, ist so ein Forum dafür doch auch nicht schlecht, oder?
Selbst Programmierer sind Menschen.
-
314159265358979 schrieb:
Dass ich stolz bin, impliziert nicht, dass ich Aufmerksamkeit suche.
Richtig.
Dass du das herzeigst worauf du stolz bist impliziert allerdings dass du Aufmerksamkeit & Bestätigung suchst.Was ja nichts schlimmes ist.
Aber ist halt lustig, wenn du es dann so vehement bestreitest.
-
Ja, über etwas Zuspruch würde ich mich freuen. Aber ich wäre auch schon zufrieden, wenn solche unnötigen Posts nicht kämen und einfach zum Thema passend geantwortet würde.
Aber nun wieder was zum Design. Ich habe mich entschieden, die Kommunikation mit den Plugins nun doch über Sockets zu machen. Damit kann man Plugins auch in anderen Programmiersprachen schreiben, außerdem ist das Steuern eines shared memory komplizierter, als ich zuerst dachte. -> Lohnt nicht
Weiters können Plugins auch auf einem entfernten System laufen.Weiters werde ich die Nachrichten einfach ganz normal an die Plugins weiterreichen und nicht erst parsen, da die Nachrichten dann für die Plugin-Sockets nochmal serialisiert und deserialisiert werden müssten.
Eine entsprechende Plugin API muss dann natürlich auch noch her.
-
Dobi schrieb:
Selbst Programmierer sind Menschen.
Quelle?
-
David W schrieb:
Dobi schrieb:
Selbst Programmierer sind Menschen.
Quelle?
http://de.wikipedia.org/wiki/Programmierer schrieb:
Ein Programmierer ist eine Person, [...]
Allerdings:
http://de.wikipedia.org/wiki/Programmierer schrieb:
Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (bspw. Einzelnachweisen) ausgestattet.
Das sollte man genauer untersuchen.
-
314159265358979 schrieb:
Aber nun wieder was zum Design. Ich habe mich entschieden, die Kommunikation mit den Plugins nun doch über Sockets zu machen. Damit kann man Plugins auch in anderen Programmiersprachen schreiben, außerdem ist das Steuern eines shared memory komplizierter, als ich zuerst dachte. -> Lohnt nicht
Weiters können Plugins auch auf einem entfernten System laufen.Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
-
Du meinst, ich soll mit den Plugins über deren cin und cout kommunizieren? Dann hätte ich ja wieder das Problem, das ich auch bei der Server-Konsole habe. Das möchte ich mir ehrlich gesagt sparen.
-
Öhm.
Muss stdin/stdout zwangsläufig std::cin/std::cout sein?Müsste doch auch anders gehen. Ich würd' mich mal umsehen was Boost.Iostreams anbietet, und ob man da nicht nen Filter/Wrapper/... basteln könnte den man dann von aussen "unterbrechen" kann.
(Der Wrapper müsste sich dann halt selbst darum kümmern die Sache threadsafe zu machen)EDIT:
Damit müsste es auch gehen:
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/reference/posix__stream_descriptor.htmlIch denke es müsste reichen wenn du so einem Teil einfach
_fileno(stdin)bzw._fileno(stdout)als "native handle" übergibst.Dann hast du nen ASIO Stream für stdin/stdout den du "ganz normal asynchron" verwenden kannst.
-
Ist halt die Frage, wie einfach man dann in anderen Sprachen darauf zugreifen kann. Klingt aber interessant, werde ich mir ansehen
Remote-Plugins scheiden dadurch komplett aus.Edit: Damit könnte ich doch vielleicht auch das Konsolen-Problem des Bots lösen, oder?
-
314159265358979 schrieb:
Ist halt die Frage, wie einfach man dann in anderen Sprachen darauf zugreifen kann.
Äh. GANZ einfach würde ich sagen. stdin/stdout geht überall. Sogar in Brainfuck.
Remote-Plugins scheiden dadurch komplett aus.
Wieso?
Denk mal, wenn das über stdin/stdout geht kannst du auch Shell-Scripts als Plugins bzw. "Wrapper" für Plugins verwenden.
Und wenn wir schon bei Shell-Scripts sind, denk einfach mal an SSH...Edit: Damit könnte ich doch vielleicht auch das Konsolen-Problem des Bots lösen, oder?
Klar könnte man das.
ps: dafür wie wenig du Windows leiden kannst, bist du mit dem "Unix-way-of-doing-it" nicht gerade sehr gut vertraut
ps2: dass ich als "Windows-only" Mensch dir das sage, grenz schon fast an Comdey
-
Plugins würde ich in der ersten Version auf jeden Fall weglassen.
Und dann würde ich über Plugins nachdenken, die durch Hinzufügen einer *.cpp-Datei geschehen. Vielleicht kann man Obervers absetzen? Befehlshandler natürlich. Überhaupt Handler für Nachrichtentypen.
Zu früh würde die Datenschnittstelle die Programmierschnittstelle dominieren, was zielstrebig zur Frickelcode in den Plugins führt, oder?
-
hustbaer schrieb:
Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
Wenn es jedoch mehrere Plugins werden sollen, sind Sockets vom Handling her wesentlich einfacher. Auch kann man dann stdin und stdout für die eigentliche Ein- und Ausgabe aufheben.
-
Stimmt, ich bin mit Unix noch nicht so vertraut. Aber je mehr ich für Unix programmiere, desto lieber mag ich es. Beispielsweise, dass Shared Memory unter Unix Kernel Persistance hat, oder eben dieses "Alles ist eine File" Verhalten. Auch sind die Unix C APIs irgendwie schöner meiner Meinung nach.
Nachdem ich fileno gegoogelt habe, ist mir allerdings etwas lustiges aufgefallen. Unter Linux heißt die Funktione "fileno" http://linux.die.net/man/3/fileno.
Unter Windows gibts sowohl "fileno", als auch "_fileno", wobei bei fileno dabei steht, dass die Funktion deprecated ist, da _fileno mit dem ISO C++ Standard-konform ist. Blöderweise taucht diese Funktion nur nirgens im Standard auf
http://msdn.microsoft.com/en-us/library/zs6wbdhx%28v=vs.80%29.aspx
http://msdn.microsoft.com/en-US/library/ms235401%28v=VS.80%29.aspx
-
314159265358979 schrieb:
Remote-Plugins scheiden dadurch komplett aus.
Nein, tun sie nicht. Wenn du auf Linux arbeitest, kannst du mit einem Programm wie socat die Standardeingabe/Standardausgabe eines beliebigen Programms in ein TCP-Socket verwandeln, und auf dem Ziel-PC dann wieder zurückwandeln in Standardeingabe/Standardausgabe.
Oder du startest ein Plugin remote per ssh, das wär vielleicht einfacher. Dann hättest du stdin/stdout des Plugins auch direkt.
-
ipsec schrieb:
hustbaer schrieb:
Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
Wenn es jedoch mehrere Plugins werden sollen, sind Sockets vom Handling her wesentlich einfacher. Auch kann man dann stdin und stdout für die eigentliche Ein- und Ausgabe aufheben.
Huch?
Ich meine ja nicht stdin/stdout des IRC-Bots, sondern stdin/stdout der Plugins.
Der IRC-Bot spielt dabei sozusagen Shell für die Plugins.
Das ermöglicht zumindest mal mehrere Plugins.Und wenn es ähnlich funktioniert wie unter Windows, dann kann der IRC-Bot Prozess einfach zwei Pipes erzeugen, und diese dem Plugin-Prozess als stdin/stdout unterjubeln. (Kann sein dass unter Linux sogar Sockets gehen als stdin/stdout, SO gut kenn' ich mich in der *NIX Welt nicht aus)
Und da er vermutlich sowieso Boost.Asio verwenden will/wird, wo Sockets/Pipes/... ziemlich gleich verwendet werden können, ist es vom Handling her dann auch nicht komplizierter.
-
hustbaer schrieb:
ipsec schrieb:
hustbaer schrieb:
Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
Wenn es jedoch mehrere Plugins werden sollen, sind Sockets vom Handling her wesentlich einfacher. Auch kann man dann stdin und stdout für die eigentliche Ein- und Ausgabe aufheben.
Huch?
Ich meine ja nicht stdin/stdout des IRC-Bots, sondern stdin/stdout der Plugins.
Ah ok, da gab es ein kleines Missverständnis. So finde ich das auch sinnvoll.
-
volkard schrieb:
Plugins würde ich in der ersten Version auf jeden Fall weglassen.
Und dann würde ich über Plugins nachdenken, die durch Hinzufügen einer *.cpp-Datei geschehen. Vielleicht kann man Obervers absetzen? Befehlshandler natürlich. Überhaupt Handler für Nachrichtentypen.
Zu früh würde die Datenschnittstelle die Programmierschnittstelle dominieren, was zielstrebig zur Frickelcode in den Plugins führt, oder?Plugins sind doch das "eigentliche" Feature des Bots. Der Bot soll ja selbst nichts tun, nur eine einfache Schnittstelle sein. Wieso soll ich denn da die Plugins weglassen?
