Vereinigung von FAH 3.0 mit GAH 2.0

[Arnim Weber]

Ach Ja: Ich habe nun wieder beide XP´s auf Fah gesetzt. Falten wieder ganz gut ran ... Allerdings habe wir im Vergöeich zu gestern wieder 4 CPU´s/ Pro Woche weniger... so´n scheiss Die Advertico Hightec- Fuzzies haben übrigends mittlerer weile mehr als 220 User... hat wohl irgendein Team fusioniert ...

[Euler]

<snipped>
Aber eigentlich braucht man doch nur eine vernünftige Modularisierung, um so ein Programm für mehrere Projekte nutzen zu können.
<snipped>
Ciao, Michael.

Hast Du ein wenig OOP background? Stichwort "pluggable","reusable" ?

Könnte man gut mit Python oder SmallScript (Smalltalk) lösen.
Das "Bunte" lassen wir mal die Sorge anderer sein ,
da ich mich nur mit den "BackEnds" beschäftigen würde.

Wir sollten vielleicht mal näheren Kontakt via Email aufnehmen?!

Euler

[Bananeweizen]

Hast Du ein wenig OOP background? Stichwort "pluggable","reusable" ?
Könnte man gut mit Python oder SmallScript (Smalltalk) lösen.

Bisher war pluggable bei mir hautpsächlich "DLL".

Das "Bunte" lassen wir mal die Sorge anderer sein ,
da ich mich nur mit den "BackEnds" beschäftigen würde.

Also ich mache sogar lieber in GUIs als in Skripten

Trotzdem können wir das mal per Mail oder in einem anderen Thread diskutieren. Da könnten dann alle anderen auch mitreden.

Ciao, Michael.

[Michael H.W. Weber]

@Euler & Bananeweizen: FoldMonitor macht Unsinn seit ich den neuen "core_65.exe" laufen habe. Meldet die "frames" inkorrekt. Erst war es stets eins zu wenig - jetzt sind es sogar zwei zu wenig - keine Ahnung, woran das liegen kann. Als "Steuerprogramm" habe ich immer noch"fah2console.exe" v2.15. Ob sich das mit dem neuen "core" beißt? Rechnen tut der Kram bislang korrekt und zügig.
Wenn ihr einen Monitor schreiben wollt - vor allem einen, der für möglichst viele dc-Projekte einsetzbar ist (insbesondere FAH/GAH/DF) - dann wäre soetwas natürlich absolute Spitze hinsichtlich Werbung für unsere jeweiligen Teams und Rechenkraft.net (sollte dann aber unbedingt auch in Englisch sein). Ich habe bislang FoldMonitor verwendet, da ich mir dafür einen eigenen "skin" zusammengeschustert habe - wenn ihr bei sowas Hilfe brauchen könnt, bin ich dabei - zum Programmieren reichen meine Kenntnisse nicht aus. In GenomeSpy sind übrigens etliche der Funktionalitäten integriert worden, die ich Herb mal vorgeschlagen hatte (er war ja mal im Team Germany unter GAH) - da hätte ich diverse weitere Vorschläge für neue Monitorprogramme zu machen - falls gewünscht.

Michael.

[Euler]

<snipped>
- da hätte ich diverse weitere Vorschläge für neue Monitorprogramme zu machen - falls gewünscht.

Michael.

Absolut!

Wenn Du ein paar freie Minuten hast, mach mal ein kleines Layout/Pflichtenheft.
Die technische Realisierung können wir dann diskutieren.

BTW english is a matter of course, naturally

Das geht heute "nahezu" automatisch mit sogenannten I18N Methoden,
sauberes Design vorausgestzt...



Euler

[Euler]

@Euler & Bananeweizen: FoldMonitor macht Unsinn seit ich den neuen "core_65.exe" laufen habe. Meldet die "frames" inkorrekt. Erst war es stets eins zu wenig - jetzt sind es sogar zwei zu wenig - keine Ahnung, woran das liegen kann.
<snipped>

Das liegt daran das es einfach doof ist !!!

Es "rechnet" mit Echtzeit, statt die Timestamps auszuwerten.
Das verstehe wer will...

Da der neue Core schneller ist, kommt er irgendwie ins Trudeln, wahrscheinlich hat er irgendwelche timing-constants "hard wired"
im Programm stehen. Mit das schlimmste, was ich mir vorstellen kann.

Bei Monster WUs wie ProteinA, liegt er am Schluss ca. 10 Frames zurück.
Noch nichtmal mitzählen kann das dumme Teil.
Ganz zu Schweigen von Anzeigen wie Frame# 8.5 ...
Was bitte ist Frame# 8.5?
Selbst wenn Sprachen wie Perl keine Integer Arithmetik beherrschen,
könnte man wenigstens dafür sorgen dass das 8.0 heißt, hehe ...

Eine andere logische Glanzleistung ist die Anzeige:

Avg. time per frame: 199 sec.
Total time elapsed: 105 sec.

Wer das programmiert hat, ist nicht "sauber". Garantiert!

Euler

[Michael H.W. Weber]

Jawoll - das mit der Auswertung der "time-stamps" ging mir auch schon mächtig auf den Wecker. Ich habe es sogar mal im Stanford-Forum posten müssen, weil die Leute dort echt durcheinander kamen mit den Angaben des Programms. Auch der GenomeSpy macht da immer noch Unsinn. Ich vermute, die Biester merken sich zunächst mal nur die Ankunft der aktuellen WU auf dem lokalen Rechner und werten dann das "log" aus, um eine durchschnittliche Berechnungsdauer pro "frame" zu ermitteln. Wenn die dann nicht mit der Realität übereinstimmt wird irgendwie der aktuelle Wert angenähert (was aber bis Ende der WU immer inkorrekt bleibt, auch wenn sich der gemeldete Wert der tatsächlichen Dauer mehr und mehr nähert).
Ich bin ja froh, daß diese "gebrochenen Zahlangaben" auch bei Dir auftreten. Bis zur "core_65.exe"-Version vom 22. Januar 2002 war das alles nämlich noch okay.
Was die Monitorprogrammentwicklunge angeht - ich werde zunächst mal eine Liste mit den grundlegendsten "Soll-Features" für FAH/GAH/DF-Überwachung zusammenstellen.

Michael.

[LadySilver]

Ganz zu Schweigen von Anzeigen wie Frame# 8.5 ...
Was bitte ist Frame# 8.5?
Selbst wenn Sprachen wie Perl keine Integer Arithmetik beherrschen,
könnte man wenigstens dafür sorgen dass das 8.0 heißt, hehe ...

Wem sagst du das! Ich könnte mich jedesmal kugeln vor lachen, wenn er zwar vor dem Komma schön brav vorwärts zählt, aber nach dem Komma zählt er die Dezimalstellen rückwärts. z.B. 6,7.....7,6.....8,5.....9,4
Was für eine Logik!

Ich werd wohl auch mal das Electron Microscope ausprobieren!

[huraxprax]

Also ich benutz schon lange keine Monitorprogramme mehr außer meine kleinen shellscripts und gkrellm
Foldmonitor hab ich aber früher mal gehabt, keine Probleme gefunden. Aber ihr beide schreit doch immer nach der GPL, Foldmonitor ist GPL und außerdem nur ein einfaches Perl/TK-script, was hindert euch daran da einfach ein sprintf() einzufügen um die Dezimalen abzuschneiden? Ihr braucht ja nicht einmal was neu zu kompilieren!

"FoldMonitor macht Unsinn seit ich den neuen "core_65.exe" laufen habe"
Wenn man die undokumentierte Ausgabe von anderen Programmen auswerten muß, ist das das selbe wie strukturierte Webseiten auswerten. Eine kleine Änderung von der du vorher natürlich nichts erfährst, und das Script produziert nur mehr mist und du darfst wieder fröhlich debuggen :/

Ciao, Benno

[Euler]

Also ich benutz schon lange keine Monitorprogramme mehr außer meine kleinen shellscripts und gkrellm
Foldmonitor hab ich aber früher mal gehabt, keine Probleme gefunden. Aber ihr beide schreit doch immer nach der GPL, Foldmonitor ist GPL und außerdem nur ein einfaches Perl/TK-script, was hindert euch daran da einfach ein sprintf() einzufügen um die Dezimalen abzuschneiden? Ihr braucht ja nicht einmal was neu zu kompilieren!

Also weißt Du, ehe ich mich an soetwas "vergreife", schmeiß ich es lieber weg.
Bei Dir ist die GPL doch wohl nicht zum Gütesiegel für Schwachsinn verkommen,
den andere reparieren können/dürfen/müssen/sollen, nur weil er GPL lizensiert ist?

Anscheinend hast Du aber wieder den Punkt nicht getroffen.
Die gebrochenen Frame# dienten nur als Beispiel für fortgeschrittenen Dilletantismus,
die eigentlichen Übel liegen da tiefer.

Und was du als "einfaches" Perl/Tk Script bezeichnest, ist software-technisch
eine einzige Katastrophe, und 20 Jahre alter BASIC Spaghetti-Code dagegen eine Lektion in strukturiertem Programmieren!
Daran ist nichts "einfach" ,außer der Tatsache, daß es "einfach" nichts taugt.

Versteh mich nicht falsch, ich bin ein absoluter Fan von einfachen Dingen.
Aber Perl Scripts sind's nun mal nicht...

Wenn man die undokumentierte Ausgabe von anderen Programmen auswerten muß, ist das das selbe wie strukturierte Webseiten auswerten. Eine kleine Änderung von der du vorher natürlich nichts erfährst, und das Script produziert nur mehr mist und du darfst wieder fröhlich debuggen :/

Ciao, Benno

Was ist denn an einem simplen Timestamp [HH:MM:SS] zu dokumentieren?

Jemand der alle 5 Sinne beisammen hat, erkennt die Struktur auf Anhieb.

Dieses Timestamp-pattern hat sich auch gar nicht verändert, sondern wird einfach nicht ausgewertet.
Stattdessen jongliert er mit Echtzeit rum, was niemand versteht, der etwas von Software Design versteht.
Stichwort "leverage" -> Nutze alle Informationen aus, die Du gratis bekommen kannst.

Wenn Dein Script "Mist" produziert, dann hast Du vorher logischen "Mist" gemacht, indem Du es falsch designed hast und unrichtige Annahmen gemacht hast. Das kann man mit etwas Logik vor dem hacken umgehen.
(-> GIGO, Garbage In Garbage Out)


Euler

[Sascha_Luehrs]

Hallöle, ich weiß gar nicht, ob ich in diesem Thread richtig bin, aber ich hatte gerade keine Lust, noch länger nach einem passenderen zu suchen *verlegenGrins* Es geht darum, daß ich bei meinen FAH3.14-ConsoleClient (tritt mit der Grafik-Version aber auch auf) Genome@home als Priorität eingestellt habe, und beim Rechnen von g@h-Einheiten mit dem FahCore_c9.exe sich offenbar ab und zu eine Art Fehler ereignet:

Code: Alles auswählen

[16:07:38] [SPA]  90.0 %                                               
[16:08:07] [SPA] 100.0 %                                               
[16:08:07] [SPA] Sequence 30 completed:                                
[16:08:07] NKTQLNTYTPESGGGYPTYYPGQMLPVAGS                              
[16:08:07] Iterations: 6000 of 6000
[16:08:08] Finished
[16:08:08] [SPA] Design complete                                       
[16:08:08] [SPA] completed successfully                                
[16:08:09] 
[16:08:09] Finished Work Unit
[16:08:09] work_hdr.len_arcfile: 49500
[16:08:10] Leaving Run
[16:08:10] - Writing 50012 bytes of core data to disk. 
[16:08:10]   end (WriteWorkResults)
[16:08:10] - Shutting down core
[16:08:10] 
[16:08:10] Genome@Home2 Core Shutdown: FINISHED_UNIT
[16:08:10] can't delete keyfile
[16:08:10] Failed to delete temporary files
CoreStatus = 64 (100)
Sending work to server

+ Attempting to send results
- Reading file work/wuresults_07.dat from core
  (Read 50012 bytes from disk)
- Connecting to server (171.64.122.107:8080)
Initial: 0000 + Results successfully sent
+ Number of Units Completed: 17

Es geht um die darin enthaltenen Meldungen "cant delete keyfile" und "failed to delete temporary files". Diese Meldung tritt beim Beenden einer Einheit oft, aber nicht immer auf, und wie es scheint auch nur beim arbeiten mit dem gah-Core (FahCore_c9.exe). Woran kann das wohl liegen?

P.S.: An NTFS kanns übrigens nicht liegen, ich habe FAH (zufällig) auf einer meiner beiden FAT32-Partitionen installiert.

[sthaler]

Bald ist es so weit: FAH und GAH kommen zusammen.
...sobald es akut wird - SOFORT auf GAH 2.0 umzusteigen, damit wir von Anfang an dabei sind...

Gibt es beim neuen Client auch eine -nonet Option oder eine Möglichkeit WU zu bunkern ?
Ich bin nur einmal am Tag im Internet und rechne normal FAH, wenn Zeit übrig bleibt GAH und da verwende ich heute -nonet, so daß auf jeden Fall Arbeit bis zur nächsten Anmeldung vorhanden ist. Im Moment ist für GAH wenig Zeit übrig weil die 80er und 82-er WUs ca. für 2 Tage reichen, aber das wird sicher nicht immer so bleiben.

Sepp