Motivation bei Privatprojekten (Split aus Diamond of Death)
-
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?
-
Damits simpler wird und schneller ein Erfolgserlebnis da ist.
-
Mal mein Projektfortschritt:
- Config-Loader fertig
- Logger fertig
- Plugin und Plugin-Manager Klassen fertig
- Socket-Klasse fertig
- Console fertig
- Befehlshandler für Konsole fehlen
- Bot-Klasse, die die einzelnen Teile Koordiniert fehlt
- Plugin API fehltJa, natürlich will ich Aufmerksamkeit, was denn sonst!
-
Sehr gut, weiter so.
-
Sag mal kann es sein das du Aufmerksamkeit brauchst?
-
Ja mit so einem Kiddieprojekt wird bestimmt jeder Mega Respekt haben.
-
top schrieb:
Sag mal kann es sein das du Aufmerksamkeit brauchst?
Natürlich, kannst du nicht lesen?
KennerDerPeinlichen schrieb:
Ja mit so einem Kiddieprojekt wird bestimmt jeder Mega Respekt haben.
Will ich doch hoffen :p
-
Kleine Designfrage.
Ich möchte gerade die console-handler einbauen. Nun ist es so, dass die Klasse 'bot' ein console-Objekt, ein config-Objekt, ein socket-Objekt und ein plugin_manager-Objekt hat. Die Handler werden logischerweise bei der console registriert. Nun braucht man ja von außen auch Zugriff, um diese Handler registrieren zu können. Dafür könnte ich ja eine Funktion machen. Aber die Handler brauchen ja auch Zugriff auf die anderen Komponenten, um z.B. ein Plugin starten zu können. Wie mache ich das am schönsten?
