Archiv verlassen und diese Seite im Standarddesign anzeigen : Entwicklung und Sourceposts
Dieses Thema soll der Veröffentlichung von Sourcecodes abseits von CVS dienen, sodass hier zum Beispiel über völlig neue Sources diskutiert werden kann. Generell sollten alle großen Änderungen im CVS Source auch hier eine Erwähnung haben. Dann erfahren auf diesem Weg auch nicht-Mitentwickler etwas über die Fortschritte des Projekts und können Verbesserungen und Kritik oder Hinweise posten, die sich direkt auf den Code beziehen.
mfg spirit
PS: Könnte vielleicht jemand, der eine funktionierende CVS Konfiguration für unseren CVS Server hat, diese hier posten. Wäre sehr freundlich, dann müssen die anderen sich nicht mehr herumspielen. :)
Aloa
Ich bin gerade - vermutlich - auf einen Bug in assimilators ursprünglichem Listencode in der Population Klasse, genauer der Funktion Population::add(Life *new_life):
...
new_life->nextLife = life;
new_life->prevLife = life->prevLife;
life->prevLife->nextLife = new_life;
life->prevLife = new_life;
...
Das ist der Abschnitt, der zum tragen kommt, wenn schon mindestens 1 Element in der Liste drin ist. Der Listenhead ist life. Durchläuft man jetzt diesen Codeabschnitt (hab's mir mal aufgezeichnet) so wird der life->nextLife Pointer nicht richtig gesetzt.
Ich hab's jetzt soweit abgeändert, als dass beim ersten Element der Liste der prevLife Pointer NULL ist und beim letzten Element der nextLife Pointer auf das erste Element zeigt. Macht imho so erst richtig Sinn.
Und f und g werden nun direkt nach ihrer Verwendung freigegeben.
balk0th
So, ich nehme alles zurück. Der Bug lag an einem anderen Codestück von mir. Neue Versionen von lifespace.cpp, lifespace.h, population.cpp und population.h stehen bald im CVS.
balk0th
Edit: Der Bug liegt vermutlich in der Funktion Lifespace::removeLife. Sehe ich mir morgen dann an, wo der zu finden ist.
life[i] = NULL;
delete life[i];
Das steht im remove(life) aber das kann so nicht hinhaun. Zuerst sollte wohl das delete kommen, dann das NULLen. Ich trau mich im Moment nix zu ändern, da ich bis dato nicht erfolgreich auf CVS zugreifen kann.
mfg
Zum Thema CVS...
Du brauchst für den Developer-Zugriff auf das Sourceforge CVS eben nen CVS Client selbst (ich verwende das Kommandozeilenprogramm von WinCVS dazu) und einen SSH Client (Cygwin/OpenSSH). Die Verzeichnisse, in denen die Executables ssh und cvs liegen, sollten dann selbstverständlich in PATH aufgenommen werden.
Dann einfach noch CVS_RSH=ssh und CVSROOT=:ext:dein_sourceforge_dev_name@cvs.sourcef orge.net:/cvsroot/ev0lution setzen und du kannst z.b. mit cvs checkout ev0lution anfangen..
balk0th
Wegen den Scripts: Irgendwer hat geschrieben, man sollte das einfach als .asm speichern und assemblen. Ich halte das für keine gute Idee, weil dann die Befehle ziemlich weit verstreute Nummern haben. Wenn also niemand was dagegen hat, werd ich flüx 'ne Art "Compiler" coden. Die Befehle können ja dann in 'ner Externen Datei gespeichert werden, nach dem Schema
Bsp-Befehl 0x05
oder so, dann könnte man mit den Nummern bei 0 bzw. 1 anfangen und dann weiterzählen. Ich werd gleich mal anfangen, wenns dann nicht gebraucht wird, ist's auch egal, dauert nur ca. 15 Minuten.
Assimilator
11.05.2003, 09:58
spirit: Ich kann dir TortoiseCVS sehr empfehlen. Das integriert sich im Explorer und nach der Installation kannst du z.B. einfach einen Ordner anwählen, Rechtsklick => CVS => Make new Module, und dort die Sourceforge einstellungen eintragen. Danach kannst du dir mit, Rechtsklick => CVS Update, die Files ziehen und die sind dann grün hervorgehoben, werden aber rot sobald du sie veränderst,.. über Rechtsklick => CVS Commit ..., können sie dann auf dem Server geupdatet werden.
balk0th: Habe mir den Code gesogen und n'bisschen überflogen. Sieht soweit gut aus, saubere arbeit =)
Lizer: Klingt gut. Edit: Vielleicht wäre es gut, die Datei nach dem Format:
#define ASM_NOP 0x01
aufzubauen. Beim einlesen für den compiler hat "#define ASM_" dann zwar keine weitere Bedeutung. Dafür kann aber die gleiche Datei auch bei der VM includet werden.
mfG Assimil8or
@Assimilator: Ups, ist jetzt schon fertig, aber ich kann das noch reinbauen. Ich hab jetzt drei Sachen gecodet:
1) Ein "Compiler", der einen Befehl pro Zeile liest, aber erwitert werden kann, sodass er beliebig viele Parameter hinter jedem Befehl lesen kann, für den Fall, dass das mal benötigt wird.
2) Den selben Compiler, nur vereinfacht. Liest jedes einzelne Wort als Befehl ein, sodass mehrere Commands pro Zeile geschrieben werden können.
3) 'n Disassembler, der die Bytes aus 'nem Binary-Script zurück übersetzt.
Hab alles recht ausführlich dokumentiert (info.text). ich denke, der Code ist durchaus optimierbar, vor allem parse(). Ich häng jetzt hier grad mal das zeug als Tarball an, werd dann heut abend oder morgen das mit dem #define ASM_NOP 0x01... reinbauen.
So, und jetzt geh ich in den park footbag zocken ;)
bis denn, viel Spaß mit dem Kram!
Assimilator
11.05.2003, 14:10
Lizer: Ist sonst auch net so wichtig,.... ;)
Ich habe nun ein Verzeichnis für die Dokumentation erstellt und die virtualmachine.txt dort hochgeladen, damit in zukunft änderungen dort erfolgen können und jeder einfach an die aktuelle version kommen kann. (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ev0lution/docs/) Ich denke es wär ne gute Idee für den Compiler auch noch ein Verzeichnis zu erstellen, da das ja ein eigenständiges Programm ist.
Ich habe mir den Compiler noch net angesehen, werde ich aber gleich tun.
Ich habe auch noch n'bisschen am Interpreter herumgebastelt und einerseits angefangen die Opcodes aus der Dokumentation zu implementieren, andererseits auch darauf geachtet, dass das ganze möglichst modular gehalten wird, damit es später einfach wird sich von der klasse Life eine eigene Lebensform abzuleiten, die evtl. gewisse Dinge anders interpretiert (oder zusätzliche INTs besitzt, etc.)
mfG Assimil8or
delphi_progger
12.05.2003, 18:25
So, ich habe jetzt noch die Unterstützung für die restlichen VM Befehle
eingebaut, es fehlen nur noch die Interrupts. Außerdem fehlen noch die
Befehle asm_xor, asm_ror und asm_rol, da ich die entsprechenden C++
Äquivalente nicht kenne. Die Parameter sind jetzt alle 32Bit signed und
die VM Funktionen geben bei fehlerhaften Parametern, z.B. bei falscher
Interruptnummer oder falscher Registernummer, false zurück (hat im
Moment aber noch keinen Einfluss auf den weiteren Programmverlauf). Die
Jumps sind jetzt alle relativ zur aktuellen Anweisung (waren vorher
absolut).
Das Array code muss außerdem noch auf int umgestellt werden, weil
einige Befehle 32Bit signed Parameter benötigen.
Schön, ich hab da wie im changelog angemerkt noch zwei Kleinigkeiten ausgebessert, wegen denen das Ding bei mir nicht lief. Jetzt läufts.
Außerdem hab ich die drei übrigen Grundbefehle (XOR, ROR, ROL) implementiert.
Juhuu endlich funkt das CVS auch bei mir, man muss die ssh2.exe ins WinCVS Verzeichnis kopieren und unter WinCVS als Alternative zu rsh, ssh2 einstellen, dann klappts..
mfg spirit
/ Load value into register
bool Life::asm_load(int parameter1, int parameter2)
{
if (checkRegister(parameter1)&&checkRegister(parameter2))
{
reg[parameter1]=parameter2;
return true;
}
else return false;
}
Ich frage mich mal, was genau parameter2 hier sein soll. Ist es a) ein Register, dann sollte wohl eher reg[parameter1] = reg[parameter2] stehen, oder ist es b) keines, dann ist allerdings fraglich, wozu checkRegister[parameter2] dient.
Nur mal als Frage.. :)
So, habe neue Dateien ins CVS hochgeladen.
Nur mal als Frage, wie's euch lieber ist:
sollten getPosition und getFieldByPos eher Zeiger auf eine KOPIE des entsprechenden Feldes oder direkt auf das Feld zeigen ? Im Moment habe ich es auf letzteres umgestellt, das könnte jedoch eher zu Problemen führen..
Meinungen bitte.
delphi_progger
17.05.2003, 10:27
Ich frage mich mal, was genau parameter2 hier sein soll. Ist es
a) ein Register, dann sollte wohl eher reg[parameter1] =
reg[parameter2] stehen, oder ist es b) keines, dann ist allerdings
fraglich, wozu checkRegister[parameter2] dient.
Es sollte ein Wert sein, also Variante b. Sorry, hab ich nicht bemerkt,
dass ich vergessen habe, das checkRegister wegzumachen.
sollten getPosition und getFieldByPos eher Zeiger auf eine KOPIE
des entsprechenden Feldes oder direkt auf das Feld zeigen ? Im Moment
habe ich es auf letzteres umgestellt, das könnte jedoch eher zu
Problemen führen..
Ich würde sagen, die Zeiger sollten direkt auf das Feld zeigen. Man
muss dann eben aufpassen, dass man nicht versehentlich was an dem Feld
ändert.
Mir ist noch was eingefallen: Was soll die VM machen, wenn eine
Division durch null auftritt (bei der Anweisung div)? Das Skript gleich
killen oder einen Fehlercode zurückgeben?
Außerdem habe ich noch zwei neue Anweisungen hinzugefügt, read und
write. Damit kann das Skript auf seinen Code zugreifen und ihn auch
verändern.
bin auch dafür keine Kopien anzulegen, schließlich sollten wir bei der ganzen Sache extrem auf Performance achtgeben. !!
Division duch null killt das Skript wie alle anderen Ausnahmefehler über den illegal_instruction Schalter würde ich sagen.
Bin gespannt ob eine der LFen die sich durchsetzen jemals read und/oder write verwendet. Trotzdem sind die Befehle glaub ich wichtig und gut!
Und nicht vergessen: Änderungen und Programmierzeit bitte in den openevo Zweig zu stecken und nicht in die alten Sources. :)
mfg