Ich habe mich vor einiger Zeit lange damit beschäftigt und eine Bibliothek geschrieben, die mit dem Minecraft Protokoll umgeht. Das ganze ist aber leider aktuell veraltet(der letzte Commit ist knapp 1.5 Jahre alt), aber vielleicht hilft es dir weiter.
Sich darauf zu verlassen, dass Packete am Stück ankommen ist generell keine gute Idee, Ich habe damals eine Abstraktionsschicht über den Netzwerkstream geschrieben, welcher mir sicherstellt, dass immer so viel gelesen wird, wie ich erwarte.
Das einzige was mir jetzt einfallen würde ist, dass du ausversehen "Scope to this" (oder das deutsche equivalent) ausgewählt hast. Du kannst im Projektmappenexplorer auf das Haus Symbol klicken um zur Ursprungsansicht zu kommen.
Hast du schonmal ein anderes System ausprobiert? Liegt es vielleicht daran? Ansonsten versuch mal mit git bisect (oder manuell mit binärer Suche) die Änderung rauszufinden, die den Fehler eingeführt hat.
Zwei Rechtecke sind kollidiert, genau dann wenn einer der Eckpunkte von Rechteck 1 in Rechteck 2 liegt oder einer der Eckpunkte von Rechteck 2 in Rechteck 1 liegt.
ich könnte mir vorstellen, dass man die .NET Compiler Platform Roslyn nutzen könnte, um selbst einen Quellcode-Obfuscator zu erstellen.
Mit Roslyn könnte man sowas sehr leicht umsetzen. Identifier umbenennen, whitespaces entfernen, unnötige Klammern hinzufügen, konstante Ausdrücke verkomplizieren, vielleicht noch schön hässliche gotos einfügen sollten sehr einfach sein
Ich habe gerade ODA - The Online Disassembler gefunden der wohl einzelne Anweisungen ohne Dateiheader dekompilieren können soll. Die Frage ist dann ob man mit dem Assember weiterkommt
Ja ich bin mir da sicher. Ich hab vor Jahren mal kurz damit rumgespielt. Man kann so nativen Machinencode ausführen. Bei Aufruf des delegates wird einfach an den Anfang des Speicherbereiches gesprungen und ausgeführt. Ist es vielleicht 64bit Code?
BlockingCollection wäre super, wenn nicht die Anforderung wäre Operationen die sich in der Auflistung befinden zwichenzeitlich abzubrechen, was diese leider nicht unterstützt (meines Wissens nach)
Auch eine List ist nicht besonders gut dafür geeignet Elemente aus der mitte zu entfernen. Die List Klasse ist intern als Array implementiert, so das wenn man ein Element löscht jeweils der komplette rest umkopiert werden muss.
Ein Kandidat der das Effizienter kann ist die Linked List. Diese ist besonders effizient beim Einfügen/Löschen an beliebigen Positionen.
Nachteil: Die Linked list ist nichtthread safe. hier muss man also mit locks
Warum die Fehlermeldung auftritt dürfte klar sein. Das Xml Dokument ist nicht Standardkonform, da ein Xml Dokument immer nur ein Root Element haben darf. Da das Dokument ja, wie du geschrieben hast groß ist würde ich vielleicht versuchen einen eigenen TextReader zu schreiben, der das Xml Dokument beim einlesen repariert und ein Dummy Root Element einfügt, und ansonsten die Daten einfach durchreicht.
Was du bei der Methode der kleinsten Quadrate versuchst, ist die Summe der quadrierten Abstände deiner Schätzfunktion von den realen Werten zu minimierten. Also du musst k so wählen, das \sum_{i=0}^{n-1} (y_i - f_k(x_i))^2 möglichst klein wird. Das kannst du wahrscheinlich relativ gut Approximieren. Ansonsten ist vllt ddieser Algorithmus etwas für dich: Levenberg-Marquardt-Algorithmus
Ich persönlich finde es einfacher immer wieder durch 2 zu teilen anstatt durch 16. Klar hast du dann mehr Schritte, aber ich zumindest komme damit besser klar. Und wenn du die Zahl per Hand soweit runtergebrochen hast so das sie in den Taschenrechner passt kannst du ja damit weitermachen. Ist ja eigentlich schon nett dass ihr überhaupt einen benutzen dürft ;)
Was du ja haben willst, ist das du alles zwichen [] finden willst. Also brauchst du auf jedenfall etwas der Form \[xxx\]. Jetzt willst du den Inhalt in den Klammern schlussendlich lesen, also packst du da eine entsprechende Gruppe dafür rein \[(?<match>xxx)\]. Jetzt wär es sinnvoll eine möglichst Präzise Beschreibung des Inhaltes zu bekommen. Welche Zeichen dürfen in der Klammer sein? Das sind alle, außer [ und ]. Also hast du für den INhalt die Beschreibung [^\[\]], und das darf sich natürlich beliebig oft wiederholen, so fehlt noch ein * dahinter. dadurch erhällst du den Ausdruck \[(?<match>[^\[\]]*)\]. Damit findest du jetzt schon eine Klammer. Jetzt musst du probieren, durch wiederholung alle Klammern zu finden. Zwichen den Klammern darf ja alles stehen, außer [ und ]. Also Matcht \[(?<match>[^\[\]]*)\][^\[\]]* einen Klammerausdruck, und den Bereich bis zum nächsten. Und das ist genau was du willst. denn ab da kannst du den Asdruck wieder von vorne anwenden. Also fehlen nur noch einmal ein * dahinter und der Ausdruck sollte passen: (\[(?<match>[^\[\]]*)\][^\[\]]*)*
Es sieht wirklich komplizierter aus als es ist, vorallem durch die vielen Klammern. Aber so gehe ich vor wenn ich einen solchen Ausdruck aufstelle.
Du könntest auch das Kopieren der Dateien, und das anzeigen des Fortschrittdialoges mit Restdaueranzeige komplett Windows überlasen mittels SHFileOperation. Das Windows API Code Pack hat das soweit ich weiss alles vorgefertigt drin.
Du könntest versuchen mittels des Parent Prozesses zu entscheiden. Wenn in der Aufrufskette cmd oder powershell auftaucht die Konsolenversion nutzen, und sonst auf Forms zurückweichen