Motivation bei Privatprojekten (Split aus Diamond of Death)

314159265358979 schrieb:

Lauter so Dinge, die ein sinnvolles Arbeiten unmöglich machen.

Wie gesagt, evtl das System neu aufsetzen...? Oder sonst zumindest die GCC nochmal neu drauf und andere boost Version probieren. Oder so.

EXDW

314159265358979 schrieb:

Ist es etwa zu viel verlangt, dass etwas, das über MacPorts installiert wird, auch funktioniert?

Wenn man bei der Entwicklung etwas falsch macht dann bringt auch eine Saubere Installation nichts.

314159265358979 schrieb:

Ich habe den Bot versucht in der Schule zu testen. Da hier aber die Ports gesperrt sind, ist der Verbindungsversuch fehlgeschlagen -> Segfault.

Verbindungsabbrüche oder das eine Verbindung nicht aufgebaut werden kann muss man abfangen, kannst du das eventuell vorher irgendwie Prüfen oder fangen (Try & Catch)?

314159265358979 schrieb:

Am Programm liegts nicht, wenn ich mir die Fehlermeldungen der boost-error_code Klasse holen möchte, kriege ich ebenfalls einen Segfault.

Jemand der sich damit besser auskennt als ich könnte dir eventuell mehr sagen ob du es eventuell falsch geholt hast.

314159265358979 schrieb:

Das ganze passiert auch beim Iterieren über ein Verzeichnis mittels der Funktionen aus dirent.h bei der kleinsten Kleinigkeit. Ich hatte da eine do-while Schleife, die abgestürzt ist. Dann habe ich sie in eine for(;-Schleife mit Bedingung im Block umgeformt -> lief.

Vielleicht hast du keine Zugriffsrechte gehabt und bei der Umformung etwas umgestellt das dies abfing, sagtest ja "mit Bedingung".

Was ich sagen möchte ist, bei der Softwareentwicklung wirst du immer über solche Probleme stolpern. Das sind die alltäglichen die man Lösen muss. Beim Programmieren ist man, wenn man es genau nimmt, nur mit Problemlösungen beschäftigt.

Ich hatte erst am Freitag den Fall, ich schrieb an ein Visual Studio 2010 Add-in welcher sich dynamisch über die WCF an einem Service anmeldet.
Aber VS hat einfach die blöde config Datei nicht gefunden. Ich habe es gelöst indem ich die Einstellungen im Code gesetzt habe.

Wie sagte jemand mal (Ich weiß leider nicht wer): "Beim programmieren löst man Probleme die man nicht hätte würde man nicht programmieren".
Wenn du mehr Entwicklung betreiben willst, bleib am Ball, sei hartnäckig und probiere aus, du wirst dadurch erfahrener. Beim nächsten mal hast du sowieso wieder andere neuere Probleme. Nicht weil es an dir liegt, sondern in der Natur der Softwareentwicklung.

(Ob dein Code gut ist oder nicht kann ich nicht beurteilen, bin aus C++ zu sehr raus, du hast aber von Dobi schon gesagt bekommen das es ein guten Eindruck macht :))

//Dazu
Arbeite doch erstmal ohne Boost

die datei bot.cpp finde ich nicht gut, da ist für jede fehlermeldung 2 x der string vorhanden

logger::warning("host missing in config file.");
user_info("host missing in config file.");

das is die hölle

314159265358979

Ja, dafür wollte ich mir noch was überlegen. Aber das ist nicht so schlimm, IMO.

volkard

dry schrieb:

die datei bot.cpp finde ich nicht gut, da ist für jede fehlermeldung 2 x der string vorhanden
logger::warning("host missing in config file.");
user_info("host missing in config file.");
das is die hölle

string pooling sollte der compiler können.

314159265358979

Irgendwie habt ihr mich nun motiviert, trotzdem weiterzumachen. Ich habe nun den Code etwas aufgeräumt und noch etwas Funktionalität hinzugefügt.

Nun zu meiner nächsten Designfrage (Plugin API). Die Plugins bekommen die Nachrichten von stdin und senden über stdout. Nun ist es aber so, dass wenn ein Plugin z.B. den Nickname ändern will, dass es dann nicht direkt die Antwort bekommt. Der Server könnte andere Antworten zuerst senden und danach z.B. dass der Nickname schon vergeben ist. Wie könnte man da vorgehen?

volkard

Das Plugin registriert beim Server, auf welche Nachrichten es wartet, zum Beispiel als Nachrichtentyp und Regexp /^nick changed/ und lokaler ID oder so?

CodeBlocks, NetBeans, Eclipse, XCode 3 + 4. Möglicherweise hab ich jetzt eine vergessen. Davon ist Eclipse aber immer noch die beste. Gibts sonst noch was erwähnenswertes?

KDevelop!

314159265358979

Ich dachte mir, dass ich den Plugins grundsätzlich alle Nachrichten weiterleite und das sortieren dann dort mache. Aber egal, wie das nun aussieht, die Antwort kann ja trotzdem irgendwann kommen...

volkard

314159265358979 schrieb:

Ich dachte mir, dass ich den Plugins grundsätzlich alle Nachrichten weiterleite und das sortieren dann dort mache. Aber egal, wie das nun aussieht, die Antwort kann ja trotzdem irgendwann kommen...

Und wenn sie kommt, wird sie dem NickchangeJob-Objekt zugeführt. Oder alle laufenden Job-Objekte bekommen alle Zeilen oder alle laufenden Job-Objekte holen sich alle Zeilen. Das hat wohl dann den Nachteil, daß komplexere Handlungen zunächst von der prozedurelen Sicht in endliche Automaten übersetzt werden müssen. Eine Sache, mit der ich nie zufrieden war.

314159265358979

Hm, ich habe mir gerade folgendes überlegt: Ich arbeite mit mehreren Threads. 1 Thread fürs lesen und mehrere Threads für die Handler. Wenn dann jemand einen Nickchange ausführen will, ruft er in etwa so eine Funktion auf:

bool change_nick(string newnick)
{
    write_line(nickchange(newnick));

    response r = wait_for_response();

    return r.success;
}

Der Handler-Thread wartet also im Hintergrund, während weitere Nachrichten eintreffen und bearbeitet werden können. Dann kann man auch noch timeouts einbauen.

volkard

314159265358979 schrieb:

Hm, ich habe mir gerade folgendes überlegt: Ich arbeite mit mehreren Threads. 1 Thread fürs lesen und mehrere Threads für die Handler. Wenn dann jemand einen Nickchange ausführen will, ruft er in etwa so eine Funktion auf:
bool change_nick(string newnick)
{
    write_line(nickchange(newnick));

    response r = wait_for_response();

    return r.success;
}
Der Handler-Thread wartet also im Hintergrund, während weitere Nachrichten eintreffen und bearbeitet werden können. Dann kann man auch noch timeouts einbauen.

Und jeder dieser Threads lauscht an allen Nachrichten, wozu er sich natürlich beim Server an- und abmelden muß.
Jeder dieser Threads ist also eigentlich das, was bisher ein Plugin war.

314159265358979

Nein, die Threads sind nur für die Bearbeitung der Nachrichten zuständig. Gelauscht wird immer nur von einem Thread. Was mir allerdings gerade einfällt: Wenn mehr Nachrichten kommen, als Threads frei sind, gibts ein Problem. Hrmpf.