Sie dir bitte in TRUNK die hash32.cpp und hash64.cpp die Zeilen 132 bzw. 133
Code: Alles auswählen
it->SetHash( hash );
Code: Alles auswählen
it->SetHash( hash );
cloidnerux hat geschrieben: Wir erleben hier ein sehr typisches Problem: Mangelnde Kommunikation!
Ich bin verantwortlich für die hashklasse, werde also selber dort Änderungen einführen und Fehler korrigieren.
Wenn du etwas änderst im Trunk und ich davon nichts weiß, kann ich sie auch nicht übernehmen.
Im gegenteil, wie jetzt geschehen habe ich meine neue Version vom branch nach Trunk kopiert.
Ich habe aber in der aktuellen Version alle Fehler beseitigt und die Quellen im Branch sind neu, die habe ich erst vorhin hochgeladen.
Ich Denke, wir sollten uns über einem kürzeren Kommunikationskanal verständigen, sprich ICQ/Skype sonstige Chats und Videokonferenzen.
Ich gebe dir teilweise Recht und teilweise auch nicht. Das mit der Kommunikation stimmt, ich habe nicht darauf hingewiesen, dass ich beim Integrieren der Hashklasse Fehler fixen musste.cloidnerux hat geschrieben: SVN hat extra einen Branch und Trunk. Man soll immer eine Stabile Version im Trunk und alles Instabile und "Work in progress" im branch lassen, das alle die Möglichkeit haben immer eine Funktionierende Version aus dem trunk zu ziehen.
Im gegenteil: du schadest wenn du im Trunk arbeitest! Dadurch das die Dateien im Trunk neuer sind, wird jeder der in seinem Branch weitermachen will auf alte Dateien stoßen, die nur wieder Probleme hervorrufen.
Als erstes: Trunk enthält momentan die aktuellste Version. Der Code kompiliert, allerdings erhalte ich jetzt statt eines bad_alloc Fehlers bei sehr großen Dateien ein Segmentation fault. Kleine Dateien werden problemlos gehasht, ab 6 GB aufwärts Segmentation fault. Da ich vier GB Ram und 2 GB Swap habe, vermute ich mal, das der Ram noch immer überläuft.cloidnerux hat geschrieben: Die Lösung dieses Problems ist einfach: hash.GetHash();
Wir wollen das hier nicht zu einer Grundsatzdiskussion zu Softwareplanung und dem Einsatz von Versionsmanagement Systemen werden lassen.Achtung hier folgt mein persönliches Verständnis/Meinung zum Thema SVN nach Konsum der vorherrschender Meinung hier im Dedupe Projekt und den SVN Richtlinien: Sobald ein Feature fertig entwickelt ist und nach Trunk wandert, finden kleiner Korrekturen und Verbesserungen, wie z. B. das Hinzufügen einer Funktion in Trunk statt, vor allem wenn es sich um Fixes handelt, die in anderen Teilen des Projektes benötigt werden. Wenn jemand dann in seinem Branch weiterentwickeln will, muss er selber darauf achten, das Trunk und Branch nicht zu weit auseinanderdriften und inkompatibel werden, sprich er muss Trunk regelmäßig auf den Branch mergen, damit er mit dem aktuellen Stand arbeiten kann, weil sich zum Beispiel Klasseninterfaces verändert haben.
Wer Argumentiert, beleidigt nicht. Auch hast du es als persönliche Meinung gekennzeichnet und als solche muss ich sie Akzeptieren.Bitte werte das nicht als persönlichen Angriff, ich hoffe der Ton ist sachlich und nicht beleidigend, das war nie meine Absicht.
So wie das Konzept des Algorithmus jetzt ist, wird 100MB ram angefordert, es werden 100MB oder eben bis zum Ende der Datei gelesen und dann sequenziell gehasht.Kleine Dateien werden problemlos gehasht, ab 6 GB aufwärts Segmentation fault. Da ich vier GB Ram und 2 GB Swap habe, vermute ich mal, das der Ram noch immer überläuft.
Code: Alles auswählen
int length
Code: Alles auswählen
unsigned long long int length
Code: Alles auswählen
delete data;
Ich kann dir meine Skype-Adresse anbieten, dann könne wir uns da in Zukunft schneller kurz schließen und solche Probleme von vornherein vermeiden.cloidnerux hat geschrieben:Es war ein Fehler auf beiden Seiten und viel Ignoranz von mir, da ich nicht einmal in der History nachgeschaut habe.
Der Fehler entstand aber auch nur, weil das ganze zu einem Recht Instabilen System wurde, weil hauptsächlich du daran Arbeitest, also du auch genau weißt wie alles ist und deswegen nichts Zerstörst. Da ich aber dies nicht wusste, ist das System Teilweise Kollabiert.
Ein weiteres Problem ist, dass ich den Code noch gar nicht testen Konnte, weil ich noch nicht die zeit fand, alle bindings zu Installieren und zu testen. Zudem gab mir die Mixtur aus Code vom branch und trunk haufenweise Fehler, jetzt weiß ich ja wodran es liegt.
Dann sind wir schon zwei, so ellenlange Texte zu schreiben kostet ganz schön viel Zeitcloidnerux hat geschrieben: Und ehrlich gesagt habe ich besseres zu tun, als über denn Sinn und Unsinn des ganzen zu Diskutieren
Ich werde das mal lokal an der Arbeitskopie ausprobieren. Ich nutze den 64 bit Hashcloidnerux hat geschrieben: So wie das Konzept des Algorithmus jetzt ist, wird 100MB ram angefordert, es werden 100MB oder eben bis zum Ende der Datei gelesen und dann sequenziell gehasht.
Am besten wird erstmal dasgegen einCode: Alles auswählen
int length
ausgetauscht, damit nicht bei 2GB Schluss ist, noch so ein Dämlicher Fehler.Code: Alles auswählen
unsigned long long int length
Dann müsste man mal ausprobieren, dashinter die for-schleife zu ziehen. Nutzt du den 32 oder 64-Bit Hash?Code: Alles auswählen
delete data;
Ich hab dir schnell meinen Namen geschickt, damit wir das Problem schnellstmöglich vom Tisch haben.Ich kann dir meine Skype-Adresse anbieten, dann könne wir uns da in Zukunft schneller kurz schließen und solche Probleme von vornherein vermeiden.
Und mich kostet es viel zeit sie zu Lesen^^Dann sind wir schon zwei, so ellenlange Texte zu schreiben kostet ganz schön viel Zeit
Dann schaue ich mir das mal genauer an.Ich werde das mal lokal an der Arbeitskopie ausprobieren. Ich nutze den 64 bit Hash
Sollte ich die SVN doku richtig verstanden habe, ist das auch übliche Praxis. Branches sind noch dazu tatsächlich tot und können (ohne irgendwelche spielereien mit svnprops) rein technisch nicht mehr nach zurückgemerget werden.[/quote]Damit zum aktuellen "Problemfall": Die Entwicklung der Hashklasse war vor Monaten abgeschlossen und dementsprechend hast du sie völlig korrekt nach Trunk kopiert. Damit ist der Branch eigentlich tot, er hat seinen Zweck erfüllt.
Ich finde gerade am Anfang ist es wichtig den Fokus darauf zu legen dass das ding erstmal kompiliert. Ich habs in den letzten Monaten ein paar mal mit svn up && cmake && make versucht, aber so einfach gehts leider noch nicht.cloidnerux hat geschrieben:Es war ein Fehler auf beiden Seiten und viel Ignoranz von mir, da ich nicht einmal in der History nachgeschaut habe.
Der Fehler entstand aber auch nur, weil das ganze zu einem Recht Instabilen System wurde, weil hauptsächlich du daran Arbeitest, also du auch genau weißt wie alles ist und deswegen nichts Zerstörst. Da ich aber dies nicht wusste, ist das System Teilweise Kollabiert.
Ein weiteres Problem ist, dass ich den Code noch gar nicht testen Konnte, weil ich noch nicht die zeit fand, alle bindings zu Installieren und zu testen. Zudem gab mir die Mixtur aus
Code vom branch und trunk haufenweise Fehler, jetzt weiß ich ja wodran es liegt.
Warum eigentlich nicht? Gehört auch geregelt und geklärt.Wir wollen das hier nicht zu einer Grundsatzdiskussion zu Softwareplanung und dem Einsatz von Versionsmanagement Systemen werden lassen.
So einfach ist das leider nicht. Erstens ist long long int nicht in C++03-Standard enthalten, sondern nur in C99 oder C++0x. Es funktioniert auf dem GCC zwar als erweiterung, aber "echtes C++" ist das nicht.Am besten wird erstmal dasgegen einCode: Alles auswählen
int length
ausgetauscht, damit nicht bei 2GB Schluss ist, noch so ein Dämlicher Fehler.Code: Alles auswählen
unsigned long long int length
Ja hoffentlich, man kann doch speicher mehrmals benutzen, oder nutzt der sich ab?Dann müsste man mal ausprobieren, dashinter die for-schleife zu ziehen. Nutzt du den 32 oder 64-Bit Hash?Code: Alles auswählen
delete data;
Wenn man tools wie SVN einsetz, muss man es auch Konsequent nutzen. Es ist aber gängige Praxis, das nach 5 tagen alles per MBIC(Management by infiniete chaos) geregelt wird.Ich finde gerade am Anfang ist es wichtig den Fokus darauf zu legen dass das ding erstmal kompiliert. Ich habs in den letzten Monaten ein paar mal mit svn up && cmake && make versucht, aber so einfach gehts leider noch nicht.
Gehört es auch, aber nicht in diesem Thread.Warum eigentlich nicht? Gehört auch geregelt und geklärt.
Wäre ja auch fast zu schönSo einfach ist das leider nicht. Erstens ist long long int nicht in C++03-Standard enthalten, sondern nur in C99 oder C++0x. Es funktioniert auf dem GCC zwar als erweiterung, aber "echtes C++" ist das nicht.
Dann muss ich mir in der nächsten zeit wohl etwas Freiraum schaffen und Kaffee kochen^^Zweitens wirds bei großen Dateien mit der Standardbibliothek schwierig.
Ich glaube hier musst man einfach die bittere Pille schlucken und akzeptieren dass es ohne #ifdef's nicht geht. Dazu ein paar Links zur Anregung:
Ok, mir fällt auch der geniale Denkfehler des ganzen auf: es wird ja weiterhin Speicher angefordert *kopf->tisch*Ja hoffentlich, man kann doch speicher mehrmals benutzen, oder nutzt der sich ab?
Bei welchen Compilern, bzw. Systemen werden wir mit long long int auf Probleme stoßen?fat-lobyte hat geschrieben: So einfach ist das leider nicht. Erstens ist long long int nicht in C++03-Standard enthalten, sondern nur in C99 oder C++0x. Es funktioniert auf dem GCC zwar als erweiterung, aber "echtes C++" ist das nicht.
Zweitens wirds bei großen Dateien mit der Standardbibliothek schwierig.
Ich glaube hier musst man einfach die bittere Pille schlucken und akzeptieren dass es ohne #ifdef's nicht geht.
Wenn, dann an der 2 GB Grenze, da viele Funktionen der C-Bibliothek noch int's als Größenvariablen verwenden.Bebu hat geschrieben:Wie groß muss die Ausgangsdatei sein, damit sie Schwierigkeiten macht?
Gute Frage. Ich glaube das Hauptproblem sind eben die auf manchen Systemen zu kleinen Variablen. Ich habe hier mal ein kleines Testprogramm geschrieben, das auf verschiedenen Systemen (Windows, Linux, Mac, 64 bit und vor allem 32 bit!) ausgeführt werden sollte um mal zu schauen wie das System auf große dateien reagiert:Bebu hat geschrieben:Bei welchen Compilern, bzw. Systemen werden wir mit long long int auf Probleme stoßen?
Code: Alles auswählen
#include <iostream>
#include <fstream>
#include <cstdio>
#include <cstring>
int main(int argc, char* argv[])
{
std::cout<<
"sizeof(int) = "<<sizeof(int)<<'\n'<<
"sizeof(long int) = "<<sizeof(long int)<<'\n'
<<std::endl;
if (argc != 2)
{
std::cerr<<"Expecting filename as an argument.\n";
return 1;
}
FILE* file_fstruct = fopen(argv[1], "r");
if (file_fstruct == NULL)
{
perror("fopen()");
}
else
{
// seek to the end
fseek(file_fstruct, 0, SEEK_END);
long int siz = ftell(file_fstruct);
if (siz == -1L)
perror("ftell()");
else
std::cout<<"Filesize appears to be "<<siz<<" ("<< (siz >> 30) <<" GB)\n";
// seek to 2GB boundary,
int two_GB_boundary = 0x7FFFFFFF;
int ret = fseek(file_fstruct, two_GB_boundary, SEEK_SET);
if (ret)
perror("fseek() to 2 GB");
else
{
int data_buffer[4];
// now try to read past the 2 gigs boundary
size_t el_read = fread(data_buffer, sizeof(int), 4, file_fstruct);
if (el_read != 4)
perror("fread() after 2 GB boundary failed");
else
std::cout<<"fread() after 2 GB boundary succeeded\n";
}
// seek to 4GB boundary,
int four_GB_boundary = 0xFFFFFFFF;
ret = fseek(file_fstruct, four_GB_boundary, SEEK_SET);
if (ret)
perror("fseek() to 4 GB");
else
{
int data_buffer[4];
// now try to read past the 4 gigs boundary
size_t el_read = fread(data_buffer, sizeof(int), 4, file_fstruct);
if (el_read != 4)
perror("fread() after 4 GB boundary failed");
else
std::cout<<"fread() after 4 GB boundary succeeded.\n";
}
fclose(file_fstruct);
}
return 0;
}
Code: Alles auswählen
./largefile /media/4EBC5FB82435B0EE/isos/einegrossedatei.iso
sizeof(int) = 4
sizeof(long int) = 8
Filesize appears to be 7084402688 (6 GB)
fread() after 2 GB boundary succeeded
fread() after 4 GB boundary succeeded