Ich bin am Kochen und muss das mal eben loswerden. (Der Thread kann
ruhig gelöscht werden, ich muss nur gerade einfach meine Wut in die
Tastatur kanalisieren, um nicht Elkos die Beinchen rauszureissen, mit
dem 5Kg-Hammer zu Atmel zu fahren oder eine Oma auf der Straße zu
verprügeln. ;-)
Ich bin heute Nacht um etwa 2:30 aufgewacht und konnte nicht wieder
einschlafen. Also ab an den Rechner, um am Source meiner
Trenntrafo-Anzeige zu hacken. Um etwa 4:30 habe ich eingesehen, dass das
mit dem Pennen wohl nichts mehr wird, habe gespeichert, mir erst mal
einen Leckerkaffee gemacht und dabei über die Realisierung der Ausgabe
sinniert. Dann bekam ich einen Hackflash der bis eben andauerte. Die
ganze Zeit wie in Trance bis zum ersten "fertig" durchgehackt. Dann auf
den Button zum Kompilieren geklickt, auf den ersten Fehler (fehlendes
Semikolon) geklickt, und da war Plötzlich der Source, wie ich ihn vor
meinem Kaffee abgespeichert hatte. - Der ganze Hackflash ist nach
/dev/null gegangen.
AVR Studio 4 hat wohl das automatische Speichern übersprungen, und beim
Klicken auf den Fehler die Alte Datei in das Editorfenster geladen.
Megamöööp :-(
(Gibt es eigentlich einen Smiley für "sich in den Sack beißen"?)
Nachtrag:
Nachdem ich alles neu eingehackt und gesichert hatte, bemerkte ich, dass
mein Editorfenster den Dateinamen komplett in Kleinbuchstaben hatte,
während meine Datei gemischte groß- und Kleinbuchstaben hat. Dort war
die Datei, die ich vorhin vermisst hatte. :-D
Winfried J. schrieb:> Manchmal sollte man doch etwas schlafen, dann bekommt man auch wieder> mal die Augen auf.
Eigentlich sind die nächtlichen Hacks die besten. :)
Markus Müller schrieb:> Oder man nimmt besser gleich Windoof.
Gibt es AVR Studio auch für etwas anderes? - Der Ursprung des Problems
scheint ja irgendwie in der Unfähigkeit von Windows, zwischen Groß- und
Kleinbuchstaben unterscheiden zu können, bei gleichzeitiger Fähigkeit,
Dateinamen mit Groß- und Kleinbuchstaben anlegen zu können, begründet zu
sein.
Icke ®. schrieb:> Immer die Packungsbeilagen lesen!
Blos nicht! Dann bekommt man doch die Nebenwirkungen!
( http://de.wikipedia.org/wiki/Nocebo-Effekt )
Michael G. schrieb:> Fuer sowas hat man ueblicherweise Versionskontrollsysteme oder man> drueckt oefter mal "Speichern". Selber schuld.
RCS ist etwas feines, nur wenn man nicht speichert, hilft es wenig. :-D
Übrigens: Man ist immer selber schuld.
Philipp Klostermann schrieb:> Eigentlich sind die nächtlichen Hacks die besten. :)
Das schon aber bevor man einschläft sollte speichern und sich dann
schlafen legen.
Namaste
Da hilft keine Versionsverwaltung nix. AVR Studio hat bei mir manchmal
die Meise, dass es einfach nebenbei zum Compilieren eine alte Version
öffnet, statt die neue vor dem Compilieren zu speichern.
Erstmal muss man merken, warum die Änderungen nix bewirken. Und wenn
man dann nicht tierisch aufpasst, hat man schnell seine Änderungen
überschrieben...
Eines meiner ersten MFC-Programme mit Wuschelzeh 1.0 war eines, dass
sich das Fenster von der IDE schnappt und dem sein File/Save Kommando
schickt. Ich habe das gerade gesucht und nicht wieder gefunden. Eine
Neuimplementierung war aber schnell erledigt.
Diese implementierung sendet alle 30 Sekunden die Nachricht an das
Hauptfenster von AVR Studio 4.0, die das Fenster erhält, wenn der User
File/Save aufruft.
Wenn kein solches Fenster gefunden wird, weil AVR Studio gerade nicht
offen ist, passiert nichts.
Ich habe die .exe mal angehangen. Wer mir nicht traut, kann sich das
auch selbst kompilieren. Einfach ein leeres Dialog-Applikation-Projekt
erzeugen, per Class-Wizard um einen WM_TIMER-Handler erweitern und den
Code wie folgt ergänzen oder das .zip entpacken.
Es kann sein, dass der Klassenname und das Kommando bei anderen
(Sub-)Versionen vom AVR Studio anderes ist, aber das ist mit Spy oder
Spy++ schnell herausgefunden.
Eine Kleinigkeit hatte ich vergessen:
Wenn man gar nichts geändert hat, gerade im Debugegr ist und trotzdem
gesichert wird, fragt er mitten in der Debug-Session, ob er das Projekt
neu bauen soll.
Ich habe das jetzt so geändert, dass das Kommando nur gesendet wird,
wenn in der Titelleiste des Fensters ein "*" (geändert) ist:
Timm Thaler schrieb:> Erstmal muss man merken, warum die Änderungen nix bewirken. Und wenn> man dann nicht tierisch aufpasst, hat man schnell seine Änderungen> überschrieben...
Bei mir ist das Abspeichern von Änderungen von dem Wechsel zwischen
Editorfenstern oder vor dem Übersetzen längst zum Reflex geworden. Aber
nicht wegen Atmel, sondern generell.
Philipp Klostermann schrieb:> Diese implementierung sendet alle 30 Sekunden die Nachricht an das> Hauptfenster von AVR Studio 4.0, die das Fenster erhält, wenn der User> File/Save aufruft.
Das ist aber auch nicht ganz ungefährlich: Wenn das AVR-Studio auf Grund
eines Bugs in einen fehlerhaften Zustand gerät, aber noch in der Lage
ist, die File-Save-Nachricht zu empfangen und auszuführen, wird u.U.
eine verhunzte Datei gespeichert, wodurch nicht nur die letzten Änderun-
gen verloren gehen, sondern gleich die geamte Arbeit.
Ich habe das mit einer früheren Version von Excel leider schon erlebt.
Nachdem das Programm erkennbar verrückt gespielt hat, ist wohl noch
einmal ein Autosave getriggert worden. Die Datei exisitierte danach zwar
noch und enthielt auch Daten. Beim Versuch sie zu laden, meckerte Excel
aber jedesmal, dass es sich um keine gültige Excel-Datei handle. Seither
deaktiviere ich bei zweifelhaften Programmen (und das sind für mich fast
alle) grundsätzlich die Autosave-Funktion.
Auf Grund dieser Problematik speichern bessere und neuere Programme den
Autosave unter einem anderen Dateinamen ab, so dass im Fehlerfall
wenigstens nur die Änderungen seit dem letzten manuellen Speichern
verloren gehen.
Den "humangetriggerten" Autosave, der vor dem Kompilieren, vor einem
Wechsel in eine andere Anwendung und vor längeren Denkpausen die Datei
speichert, halte ich aber nach wie vor für die bessere Lösung. Mich
schüttelt es immer wieder, wenn ich Kollegen sehe, die mehrere Word-,
Excel- und Powerpoint-Dateien gleichzeitig und ungespeichert offen haben
und dann Mittagessen gehen =8-[
Yalu X. schrieb:> Wenn das AVR-Studio auf Grund> eines Bugs in einen fehlerhaften Zustand gerät, aber noch in der Lage> ist, die File-Save-Nachricht zu empfangen und auszuführen, wird u.U.> eine verhunzte Datei gespeichert, wodurch nicht nur die letzten Änderun-> gen verloren gehen, sondern gleich die geamte Arbeit.
Den kannte ich noch nicht, weil der bei mir noch nicht aufgetreten ist,
sondern nur der andere, den ich eingangs beschrieben habe. Danke für den
Hinweis. Kann ich diesen fehlerhaften Zustand irgendwie erkennen, so
dass ich dann mein Programm (vielleicht noch rechtzeitig) beenden kann?
Philipp Klostermann schrieb:> Den kannte ich noch nicht, weil der bei mir noch nicht aufgetreten ist,> sondern nur der andere, den ich eingangs beschrieben habe.
Das ist kein spezifischer, bekannter Bug, sondern ein hypothetischer,
bei dem du aber nicht sicher sein kannst, dass er nicht exisitiert.
Jede komplexere Software (außer TeX natürlich ;-)) ist, wie wir alle
wissen, fehlerhaft. Fehler wie Pufferüberläufe u.ä. führen oft dazu,
dass Datenstrukturen im Speicher überschrieben werden. Wird der Inhalt
dieser versaubeutelten Strukturen in eine Datei gespeichert, ist diese
ebenfalls versaubeutelt.
Ich gehe deswegen immer folgendermaßen vor: Wenn ich feststelle, dass
sich eine Anwendung irgendwie seltsam verhält (überlange Reaktionszei-
ten, Fehler in der Bildschirmdarstellung usw.), versuche ich, das
aktuelle Dokument unter einem neuen Namen abzuspeichern, und starte die
Anwendung (oder ggf. den gesamten PC) neu. Mit etwas Glück kann ich dann
die zuletzt geschriebene Datei wieder einlesen. Wenn nicht (weil sie aus
o.g. Gründen versaubeutelt ist), habe ich immer noch die Version mit dem
ursprünglichen Dateinamen, die zwar die letzten Änderungen noch nicht
enthält, aber immerhin den ganzen Rest der Arbeit.
Bei jeder Autosave-Funktion (egal, ob in die Software integriert oder —
wie bei dir — von extern getriggert), die beim Speichern die Original-
datei überschreibt, besteht eben die Gefahr, dass man hinterher nur
noch eine versaubeutelte Datei übrig hat.
Yalu X. schrieb:> Bei jeder Autosave-Funktion (egal, ob in die Software integriert oder —> wie bei dir — von extern getriggert), die beim Speichern die Original-> datei überschreibt, besteht eben die Gefahr, dass man hinterher nur> noch eine versaubeutelte Datei übrig hat.
Wie A.K. es schon oben beschrieb, ist bei mir die Sicherung auch schon
eine Art Reflex. Ich mache das mit einem Command-File (Batch), welches
wirklich das gesamte Projekt zippt, mit Projektnamen und Zeitstempel im
Dateinamen, und die Datei wird auch an einen ganz anderen Ort geschoben.
So wird auch nie eine vorherige Datei überschrieben. Den Zeitstempel im
Dateinamen deswegen, damit ich im Sicherungsverzeichnis nach Namen und
Datum gemeinsam sortieren kann. Das geht doch heute in
Sekundenbruchteilen, wo man früher dem Zipper noch minutenlang bei der
Arbeit zuschauen konnte. Aber das kann ja jeder machen, wie er will.
Die Sicherung wird sowohl bei jedem Compilerlauf ausgelöst, als auch mit
einem Button unten in der Taskleiste. OK, man muß mal etwas Zeit
investieren, um das Batch-File aufzusetzen, und die Tools, die darin
verwendet werden. Aber das macht man ja nur ein mal. Mir half vor Jahren
mal ein Softwerker dabei, der sich auch gut mit Schleifen in Batch-Files
auskannte. Das war schon ein paar Stunden Arbeit, bis alles lief.
Hinterher habe ich zwar 30 Zip-Files am Tag in einem Ordner, und wenn
die Arbeit erfolgreich war, lösche ich 28 überflüssige, und behalte
vielleicht 2.
Aber da gibt es auch böse Überraschungen: Eine for-Schleife für
Dateilöschung in einem Arbeitsverzeichnis, die einen Syntaxfehler hatte,
löschte mir auf der Arbeit mal das komplette Laufwerk D, die zweite
Partition auf der Festplatte. Natürlich ohne Verwendung des
Papierkorbes. Dort war alles drauf, was mit meiner Arbeit zu tun hatte,
wie Projektverzeichnisse, Datenblätter aus Recherchen, usw..
Glücklicherweise war die Arbeit aber auf dem zentralen Server, und so
war der Schaden nur die 2 letzten Stunden Arbeit.
MPLAB hat sogar einen extra Button nur zum Zippen und Sichern.
Überschreibt leider aber auch die alte Datei.
Genau wie Philipp versaubeutelte sich ein Kommilitone mal das
Programmierprojekt fürs Studium, wo 3 Wochen Arbeit drin steckten. Er
meinte nach einer Party in guter Bierlaune, noch ein Stündchen daran
arbeiten zu müssen. So schnell wie nach dieser Aktion wurde der seit dem
wohl nie wieder schlagartig nüchtern. Diese Geschichte vergesse ich nie
mehr.
Yalu X. schrieb:> Bei jeder Autosave-Funktion (egal, ob in die Software integriert oder —> wie bei dir — von extern getriggert), die beim Speichern die Original-> datei überschreibt, besteht eben die Gefahr, dass man hinterher nur> noch eine versaubeutelte Datei übrig hat.
Das lässt sich vielleicht lösen, wenn man das Backup-Konzept von Wilhelm
mit der Autosave-Funktion kombiniert.
Etwa so:
- senfilesavecmd.exe wird um folgende Punkte erweitert:
1. Eine Liste von Verzeichnissen, per .ini-File (hierfür ist die
Registry unpraktischer) konfigurierbar und per UI editierbar. (Listbox
mit Kontextmenü, Handeingabe und "Verzeichnis Suchen"-Dialog)
2. Eine konfigurierbare Liste von Aktionen mit Platzhaltern für Pfad und
Datei, die als Backup-Prozess ausgeführt werden.
Aus einem Thread heraus werden diese Verzeichnisse per
FindFirstChangeNotification()/FindNextChangeNotification() beobachtet,
ihr Inhalt wird bei Änderungen mit einer Liste pro Verzeichnis ver- und
abgeglichen und und bei Änderungen wird für jede geänderte Datei der
Backupprozess mit diesem Verzeichnis und dieser Datei als Parameter
gestartet.
Hat jemand einen besseren/alternativen Vorschlag?
Wilhelm Ferkes schrieb:> ...> Hinterher habe ich zwar 30 Zip-Files am Tag in einem Ordner, und wenn> die Arbeit erfolgreich war, lösche ich 28 überflüssige, und behalte> vielleicht 2.
Und genau dafür sind Revision Control Systems (RCS) gut.
Simon K. schrieb:> Wilhelm Ferkes schrieb:>> ...>> Hinterher habe ich zwar 30 Zip-Files am Tag in einem Ordner, und wenn>> die Arbeit erfolgreich war, lösche ich 28 überflüssige, und behalte>> vielleicht 2.> Und genau dafür sind Revision Control Systems (RCS) gut.
Ja, stimmt. Aber hier im Hobby habe ich im Augenblick keinen Bock
darauf. Hauptsache, es sind funktionierende Projekte mit allen Ständen
überhaupt irgendwo gesichert.
Außer dem Erstellen des Command-Files brauchte ich weiter nichts, aber
noch einen Satz Unix-Tools, die man sich bei Sourceforge herunter laden
kann, die das Datum und die Uhrzeit in den Dateinamen einfügen.
