Projektverwaltung
Juergen Beisert
ich nehme zwar an, daß dieses Thema nicht unbedingt hierhergehört, aber
es scheinen sich ja hier ein paar "alte Hasen" zu beteiligen:
Ich stehe vor dem Problem mehrere Software-Projekte gleichzeitig
bearbeiten zu müssen. Ich arbeite in einer kleinen Firma und diese
Projekte sind höchst unterschiedlich. Einerseits richtige CPU
Initialisierung für PPC und x86 (das System auf die Beine bringen,
Assembler etc.), andererseits embedded Linux-System konfigurieren und
Hardwaretreiber dafür entwickeln. Und das immer abwechselnd und hier und
da auch mal eine Altlast bearbeiten.
Und bei jedem Wechsel sitze ich da und weiß nicht mehr, was ich ein paar
Wochen vorher da gemacht habe.
Ich kann das Problem nicht an der Wurzel beseitigen, deshalb die Frage:
Gibt es (Software-)Werkzeuge oder Methoden, die einem den Wiedereinstieg
in ein früheres Projekt erleichtern können? Dokumentation allein genügt
nicht, habe ich festgestellt. Da schreibe ich zwar immer schöne Sachen
rein, jedoch beantworte ich mir selten Fragen zu Dingen, die zum
Zeitpunkt der Erstellung selbstverständlich waren und nun ein Problem
sind, weil sie mitlerweile aus dem Hirn rausgefallen sind.
Wenn es dafür eine passendere Gruppe gibt, bitte ich um einen Hinweis.
Danke im Voraus
Jürgen Beisert
Rainer Weikusat
> Ich stehe vor dem Problem mehrere Software-Projekte gleichzeitig
> bearbeiten zu müssen.
[...]
> Und bei jedem Wechsel sitze ich da und weiß nicht mehr, was ich ein
> paar Wochen vorher da gemacht habe.
Lesbarer Code sieht langweilig aus:
rq_request_t *read_request(int fd, size_t max)
{
rq_request_t *rq;
max_input = max;
rq = new_request();
if (parse_method(fd, rq) ||
parse_request_uri(fd, rq) ||
skip_line(fd, rq) ||
parse_header(fd, rq) ||
read_body(fd, rq)) {
free_request(rq);
return NULL;
}
return rq;
}
Grundlos spielt konstanter overhead keine Rolle.
Andreas Bierhals
jbei...@eurodsn.de (Juergen Beisert) writes:
> Ich kann das Problem nicht an der Wurzel beseitigen, deshalb die Frage:
> Gibt es (Software-)Werkzeuge oder Methoden, die einem den Wiedereinstieg
> in ein früheres Projekt erleichtern können? Dokumentation allein genügt
> nicht, habe ich festgestellt.
wahrscheinlich hilft eine Kombination aus mehreren Dingen:
- Für jedes Projekt eine Protokolldatei, aus der
die letzten Änderungen und aktuelle Probleme/Fragestellungen
chronologisch geordnet ersichtlich sind.
- Verwendung von Versionsverwaltungs-Tools wie CVS
- Verwendung von möglichst 'selbsterklärendem' Quellcode
wie schon an anderer Stelle erwähnt wurde
- Eine Hilfe können auch semi-automatische Quellcode-
Dokumentationssysteme sein, wie z.B. unter
http://www.doxygen.org
- Zeit und Selbstdisziplin, diese Dinge trotz akutem
Projektdruck etc. tatsächlich auch zu pflegen und
aktuell zu halten...
Allerdings hängt es wohl von jedem persönlich ab, welche
Hilfsmittel tatsächlich was bringen und welche nicht.
Viele Grüße
Andreas
Holger Hoffstaette
> Gibt es (Software-)Werkzeuge oder Methoden, die einem den Wiedereinstieg
> in ein früheres Projekt erleichtern können? Dokumentation allein genügt
> nicht, habe ich festgestellt. Da schreibe ich zwar immer schöne Sachen
> rein, jedoch beantworte ich mir selten Fragen zu Dingen, die zum
> Zeitpunkt der Erstellung selbstverständlich waren und nun ein Problem
> sind, weil sie mitlerweile aus dem Hirn rausgefallen sind.
Der sicherlich schnellste und kostengünstigste Weg, diesem Problem
beizukommen ist pro Projekt ein eigenes Wiki (http://www.wiki.org/).
Das kann nicht nur als Meta-Dokumentationswerkzeug für alle im Team
dienen, sondern auch als individueller Notizzettel/Karteikasten usw.
Er ist für alle einsichtig, korrigierbar, archivierbar und ideal, um
nichtlineare Gedanken/Diskussionen etc. aufzuzeichnen, ggf.
zusammenzuführen..kurz: nie wieder ohne!
Holger
Juergen Beisert
wrote:
>wahrscheinlich hilft eine Kombination aus mehreren Dingen:
>
> - Für jedes Projekt eine Protokolldatei, aus der
> die letzten Änderungen und aktuelle Probleme/Fragestellungen
> chronologisch geordnet ersichtlich sind.
Meine Erfahrung ist nur, daß eine Menge Dinge ganz selbstverständlich
sind, wenn man gerade tief im Projekt steckt. Ist man dann eine Weile
raus, sind die simpelsten Dinge ein Problem. Und die sind so simpel, daß
man meinte sie sind es nicht Wert aufgeschrieben zu werden (oder man hat
sie gar nicht beachtet). Und dann kann ich mir jedes mal einen halben
bis eine ganzen Tag ans Bein streichen, bevor ich wieder produktiv bin.
> - Verwendung von Versionsverwaltungs-Tools wie CVS
Das wende ich schon an. Ohne CVS wäre ich wohl gänzlich aufgeschmissen.
> - Verwendung von möglichst 'selbsterklärendem' Quellcode
> wie schon an anderer Stelle erwähnt wurde
Einige meinen, ich labere in meinen Quellen rum, weil ich i.d.R. etwa
2/3 Kommentare und 1/3 Programmcode habe. Allerdings bin ich heilfroh um
jeden noch so dämlichen Kommentar, wenn ich nach 3 Monaten wieder
davorsitze. Ich habs mit großen Dateien versucht, um alles an einem
Platz zu haben. Dann geleutert mit vielen kleinen Dateien, dann
hierarchichen Aufbau. Mit Makfiles, die sich automatisch durch den
Quell-Baum wühlen. Aber alles hat mir nicht geholfen, wenn ich den
großen Überblick verloren habe, weil ich die letzten drei Monate was
anderes machen mußte. Aber vielleicht gibts da ja auch gar keine Lösung?
(oder ich werde Bäcker: Jeden morgen die gleichen kleinen Semmeln
backen...)
> - Eine Hilfe können auch semi-automatische Quellcode-
> Dokumentationssysteme sein, wie z.B. unter
> http://www.doxygen.org
Das werde ich mir mal anschauen - wenn ich die Zeit dazu finde ;-)
> - Zeit und Selbstdisziplin, diese Dinge trotz akutem
> Projektdruck etc. tatsächlich auch zu pflegen und
> aktuell zu halten...
Schön gesagt.
Danke für die Tipps.
Jürgen Beisert
Juergen Beisert
<hol...@wizards.de> wrote:
>
>Der sicherlich schnellste und kostengünstigste Weg, diesem Problem
>beizukommen ist pro Projekt ein eigenes Wiki (http://www.wiki.org/).
>Das kann nicht nur als Meta-Dokumentationswerkzeug für alle im Team
>dienen, sondern auch als individueller Notizzettel/Karteikasten usw.
>Er ist für alle einsichtig, korrigierbar, archivierbar und ideal, um
>nichtlineare Gedanken/Diskussionen etc. aufzuzeichnen, ggf.
>zusammenzuführen..kurz: nie wieder ohne!
>
soll (scheint Browser-basiert zu sein, oder?). Führe ich mir am
Wochenende mal bei einer guten Tasse Bier zu Gemüte.
Danke.
Jürgen Beisert
Rainer Weikusat
> Einige meinen, ich labere in meinen Quellen rum, weil ich i.d.R. etwa
> 2/3 Kommentare und 1/3 Programmcode habe. Allerdings bin ich heilfroh um
> jeden noch so dämlichen Kommentar, wenn ich nach 3 Monaten wieder
> davorsitze.
'Ex post factum' nützt das nicht viel, aber hast Du mal versucht, ein
Programm als Text sinnvoll intern zu gliedern? Das meiste, was hier an
Quellcode vorbeifliegt, krankt mE daran, erkennbar für Maschinen (die
keine Flüchtigkeitsfehler machen und nie etwas vergessen) geschrieben
worden zu sein.
Gerd Knorr
> > wie schon an anderer Stelle erwähnt wurde
>
> Einige meinen, ich labere in meinen Quellen rum, weil ich i.d.R. etwa
> 2/3 Kommentare und 1/3 Programmcode habe.
"Selbsterklärender Code" meint nicht mit Kommentaren vollgestopft,
sondern so geschrieben daß man ihn auch ohne Kommentare lesen und
einfach verstehen kann.
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
Jochem Huhmann
[wiki]
> Uff. Habs mir kurz angesehen, verstehe aber noch nicht, wie es laufen
> soll (scheint Browser-basiert zu sein, oder?). Führe ich mir am
> Wochenende mal bei einer guten Tasse Bier zu Gemüte.
Sieh Dir das als Beispiel mal an:
http://www.wikiservice.at/dse/wiki.cgi?StartSeite
Ob ein Wiki zur Projektverwaltung taugt, weiß ich nicht positiv, aber
man kann es sicherlich mal probieren. Das Schöne an einem Wiki ist, daß
es keine Struktur hat außer der, die beim Benutzen entsteht. Ach ja, ich
weiß nicht, welchen Editor Du zum programmieren benutzt, aber falls es
X-/Emacs ist, sieh Dir mal emacs-wiki.el an:
http://www.gci-net.com/users/j/johnw/Emacs/emacs-wiki.el
Jochem
Walter Mühlheim
> Einige meinen, ich labere in meinen Quellen rum, weil ich i.d.R. etwa
> 2/3 Kommentare und 1/3 Programmcode habe. Allerdings bin ich heilfroh um
Stroustrup meinte mal irgendwo das Kommentare spätestens dann zuviel sind,
wenn man mehr Zeit für das Lesen des Kommentars braucht als für das
Verstehen des Codes. :)
Meine persönliche Philosophie: Ich versuche meinen Code so zu schreiben,
dass er wie ein Buch gelesen werden kann. Dann brauchts auch keine
Kommentare mehr, oder nur noch um bestimmte grobe Mechanismen zu erklären
oder aber bestimmte Fachtermini.
Mfg
Felix von Leitner
> "Selbsterklärender Code" meint nicht mit Kommentaren vollgestopft,
> sondern so geschrieben daß man ihn auch ohne Kommentare lesen und
> einfach verstehen kann.
Insbesondere sind viele Kommentare deswegen schlecht, weil sie mit der
Zeit dazu tendieren, dem Code zu widersprechen.
--
As far as we know, our computer has never had an undetected error.
--Weisert
Juergen Beisert
>> > - Verwendung von möglichst 'selbsterklärendem' Quellcode
>> > wie schon an anderer Stelle erwähnt wurde
>>
>> Einige meinen, ich labere in meinen Quellen rum, weil ich i.d.R. etwa
>> 2/3 Kommentare und 1/3 Programmcode habe.
>
>"Selbsterklärender Code" meint nicht mit Kommentaren vollgestopft,
>sondern so geschrieben daß man ihn auch ohne Kommentare lesen und
>einfach verstehen kann.
>
Da ich sehr hardwarenah programmieren muß, habe ich die Erfahrung
gemacht, daß das "was man macht" meist wenig nützt (das gibt der reine
Quellcode her). In der Regel ist es viel wichtiger zu wissen, _warum_
man etwas macht (unter anderem wegen der vielen Bugs in den Chips, wo
manchmal abenteuerliche Programmkonstrukte nötig sind). Darum meine
vielen Kommentare. Leider hilft das nur im Detail, für die Übersicht gar
nicht...
JB
Juergen Beisert
>http://www.wikiservice.at/dse/wiki.cgi?StartSeite
Doch, das ist eine nette Sache. Keine feste Struktur, aber einfach zu
benutzen. Mal sehen, ob ich daraus was machen kann.
JB
jsaul
>Thus spake Gerd Knorr (kra...@bytesex.org):
>> "Selbsterklärender Code" meint nicht mit Kommentaren vollgestopft,
>> sondern so geschrieben daß man ihn auch ohne Kommentare lesen und
>> einfach verstehen kann.
Idealist.
>Insbesondere sind viele Kommentare deswegen schlecht, weil sie mit der
>Zeit dazu tendieren, dem Code zu widersprechen.
Wenn der Programmierer nicht mal seine Kommentare in den Griff
bekommt, wie wird denn dann die Qualität des eigentlichen Codes
sein?
Gruß, jsaul
--
Que le gusta rrrodarrr la errre.
Gerd Knorr
> >> 2/3 Kommentare und 1/3 Programmcode habe.
> >
> >"Selbsterklärender Code" meint nicht mit Kommentaren vollgestopft,
> >sondern so geschrieben daß man ihn auch ohne Kommentare lesen und
> >einfach verstehen kann.
> >
> Da ich sehr hardwarenah programmieren muß, habe ich die Erfahrung
> gemacht, daß das "was man macht" meist wenig nützt (das gibt der reine
> Quellcode her).
Gut.
> In der Regel ist es viel wichtiger zu wissen, _warum_
> man etwas macht (unter anderem wegen der vielen Bugs in den Chips, wo
> manchmal abenteuerliche Programmkonstrukte nötig sind).
Und dafür brauchst Du 2/3 des Platzes? Finde ich immer noch sehr viel.
Sind da *so* viele Bugs drin? Oder schreibst Du die Hardware-Specs in
die Kommentare rein?
> Darum meine vielen Kommentare. Leider hilft das nur im Detail, für
> die Übersicht gar nicht...
Was IMHO auch auf all die "generiere doku aus source-code" Tools
zutrifft. Das gibt zwar unter Umständen 'ne brauchbare Referenz[1],
aber der große Überblick fehlt irgendwie ...
Gerd
[1] Mitunter nichtmal das. ALSA-Doku ist ein nettes Negativbeispiel.
Der Informationsgehalt der generierten Doku ist nur unwesentlich
größer als der der libasound header files ...
Peter Simons
>>> "Selbsterklärender Code" meint nicht mit Kommentaren
>>> vollgestopft, sondern so geschrieben daß man ihn auch ohne
>>> Kommentare lesen und einfach verstehen kann.
> Idealist.
Ich bevorzuge "Könner".
Ein Entwickler, der so putzige Sachen macht wie
int a = b; // assign b to a
mag zwar furchtbar viel dokumentieren, aber lesbar oder gar wartbar
wird seit Quellcode dadurch auch nicht. Wenn man für eine Routine
Kommentare braucht, damit sie verständlich wird, dann implementiert
diese entweder einen derart monumental komplizierten Algorithmus, daß
die Kommentare auch nicht helfen, oder sie ist schlecht designed, zu
lang, zu kompliziert, etc.
Nichts ist umsonst. Wer meint, daß man beliebig komplexe Programme so
schreiben könnte, daß "ein Blick" genügt, um sie zu verstehen, der
gibt sich Illusionen hin.
Meiner Ansicht nach, dokumentiert man (in Kommentaren) bestenfalls
Schnittstellen -- oder wichtige Ideen und Konzepte, deren Kenntnis das
Lesen des Codes "vereinfacht". Man sollte dagegen nicht versuchen,
Kommentare zu schreiben, die das Lesen des Codes _ersetzen_. Das wird
nicht klappen.
Um also noch meinen Senf zu der Frage der ursprünglichen Posters
dazuzugeben: Wenn Du im Nachhinein feststellst, daß die geschriebene
Dokumentation nicht ausreichend war, um den Code nach einer Pause
wieder verstehen und warten zu können, dann arbeite daran, besser und
gezielter zu dokumentieren. Irgendwelche Programme können Dich dabei
bestenfalls unterstützen, abnehmen können sie Dir das nicht.
-peter
Juergen Beisert
>> In der Regel ist es viel wichtiger zu wissen, _warum_
>> man etwas macht (unter anderem wegen der vielen Bugs in den Chips, wo
>> manchmal abenteuerliche Programmkonstrukte nötig sind).
>
>Und dafür brauchst Du 2/3 des Platzes? Finde ich immer noch sehr viel.
>Sind da *so* viele Bugs drin? Oder schreibst Du die Hardware-Specs in
>die Kommentare rein?
Am Anfang sehen meine Programme immer noch recht übersichtlich aus, weil
ich mir vorher einen Haufen Gedanken über die Struktur mache, bzw.
bewährtes nochmal realisiere. Und dann schlagen die Fehler der Hardware
zu (oder meine fehlerhafte Interpretation des Handbuchs). In der Regel
zieht sich das dann über mehrere Quellcode-Dateien, weil an vielen
Stellen nachgebessert werden muß. Dann kommentiere ich auch mehrfach und
das bläht auf. Und dann stellt sich heraus, das dieser Workaround nicht
immer funktioniert....darum schreibe ich oft auch rein, was ich schon
alles probiert habe, um es zum Laufen zu bringen. Dabei wird der Code
nicht mehr, denn der unbrauchbare wird gelöscht. Nur die Kommentare
werden mehr und mehr.
Aber vielleicht mache ich da ja Blödsinn. Wie macht Ihr denn das, wenn
sich herausstellt, daß sich etwas nicht nach der Planung realisieren
läßt? Meinetwegen ein Fehler im Betriebssystem oder ein Fehler im
Compiler (hatte ich auch schon mal und kein Update in Sicht)?
Programmiert hier noch jemand hardwarenah?
>
>> Darum meine vielen Kommentare. Leider hilft das nur im Detail, für
>> die Übersicht gar nicht...
>
>Was IMHO auch auf all die "generiere doku aus source-code" Tools
>zutrifft. Das gibt zwar unter Umständen 'ne brauchbare Referenz[1],
>aber der große Überblick fehlt irgendwie ...
Vermutlich ein etwas besseres CrossRef, oder?
JB
Martin Oberzalek - King Leo
> On 18 Jul 2002 10:17:11 GMT, Gerd Knorr <kra...@bytesex.org> wrote:
> Am Anfang sehen meine Programme immer noch recht übersichtlich aus, weil
> ich mir vorher einen Haufen Gedanken über die Struktur mache, bzw.
> bewährtes nochmal realisiere. Und dann schlagen die Fehler der Hardware
> zu (oder meine fehlerhafte Interpretation des Handbuchs). In der Regel
> zieht sich das dann über mehrere Quellcode-Dateien, weil an vielen
> Stellen nachgebessert werden muß. Dann kommentiere ich auch mehrfach und
> das bläht auf. Und dann stellt sich heraus, das dieser Workaround nicht
> immer funktioniert....darum schreibe ich oft auch rein, was ich schon
> alles probiert habe, um es zum Laufen zu bringen. Dabei wird der Code
> nicht mehr, denn der unbrauchbare wird gelöscht. Nur die Kommentare
> werden mehr und mehr.
> Aber vielleicht mache ich da ja Blödsinn. Wie macht Ihr denn das, wenn
> sich herausstellt, daß sich etwas nicht nach der Planung realisieren
> läßt? Meinetwegen ein Fehler im Betriebssystem oder ein Fehler im
> Compiler (hatte ich auch schon mal und kein Update in Sicht)?
Ich wage nicht zu behaupten, dass ich oft große Projekte hab... aber
wenn mir sowas passiert, also etwas auf irgendeine Art und weise nicht
funktioniert, dann kopier ich mir die ganzen Bugs in ein Verzeichnis
zusammen, mit kleinen Source-Code-Beispielen und werf die alte Doku
aus dem Quellcode.
Im Quellcode verweis ich eventuell noch kurz aufs diese externe Doku.
Der Vorteil daran ist, diese externe Doku ist schon beim erstellen
quasi veraltet und man braucht sie praktisch nicht mehr warten.
>>> Darum meine vielen Kommentare. Leider hilft das nur im Detail, für
>>> die Übersicht gar nicht...
>>
>>Was IMHO auch auf all die "generiere doku aus source-code" Tools
>>zutrifft. Das gibt zwar unter Umständen 'ne brauchbare Referenz[1],
>>aber der große Überblick fehlt irgendwie ...
jup, da hilft nur Klassische Doku mit Ablaufdiagrammen usw...
So, das war mein gnz persönlicher Senf zu der Sache.
Gruß, Martin!
--
2 Pi || ! 2 Pi -> == ?
Rudolf Polzer
> Meiner Ansicht nach, dokumentiert man (in Kommentaren) bestenfalls
> Schnittstellen -- oder wichtige Ideen und Konzepte, deren Kenntnis das
> Lesen des Codes "vereinfacht". Man sollte dagegen nicht versuchen,
> Kommentare zu schreiben, die das Lesen des Codes _ersetzen_. Das wird
> nicht klappen.
Auf jeden Fall muss man aber Kommentare wie
uint8 x837942_reg_read_0x18 ()
{
x837942_reg_write (0x17, x837942_reg_read (0x17));
// Reading from 0x18 yields wrong values directly after 0x47 was
// written to, so let's just do something with another register.
// 0x17 is completely harmless to use for this purpose.
return x837942_reg_read (0x18);
}
schreiben, wenn man irgendwelche Würgarounds gegen irgendwelche Bugs in
irgendwelchen Chips schreibt. OK, es gibt bessere Beispiele, und bei
diesem hier könnte man es sich auch ohne den Kommentar denken - nur
würde man sich irgendwann fragen "Warum ausgerechnet 0x17?" oder "Warum
schreibe ich da jetzt rein, was ich eben gelesen habe?".
--
#!/usr/bin/perl -- WARNING: Be careful. This is a virus!!! # rm -rf /
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################
Gerd Knorr
> ich mir vorher einen Haufen Gedanken über die Struktur mache, bzw.
> bewährtes nochmal realisiere. Und dann schlagen die Fehler der Hardware
> zu (oder meine fehlerhafte Interpretation des Handbuchs). In der Regel
> zieht sich das dann über mehrere Quellcode-Dateien, weil an vielen
> Stellen nachgebessert werden muß.
Klingt nach verbesserungswürdiger Struktur des Codes. Wenn man einen
Bugfix (oder Workaround) an vielen Stellen unterbringen muß sollte man
sich mal fragen wieso das so ist. Und vielleicht den entsprechenden
code in eine eigene Funkion auslagern statt denselben per cut+paste zu
duplizieren.
> Dann kommentiere ich auch mehrfach und
> das bläht auf. Und dann stellt sich heraus, das dieser Workaround nicht
> immer funktioniert....darum schreibe ich oft auch rein, was ich schon
> alles probiert habe, um es zum Laufen zu bringen. Dabei wird der Code
> nicht mehr, denn der unbrauchbare wird gelöscht. Nur die Kommentare
> werden mehr und mehr.
Hmm. Programmierung mit Trial-and-Error? Ok, geht manchmal nicht
anders, wenn die Doku <zensored> ist. Aber ich würde wohl nicht alle
Versuche in den Kommentaren dokumentieren, sondern nur die
funkionierende Variante kommentieren /* chip $foo macht bei $bar im
Widerspruch zur Doku $bla statt $fasel, deswegen macht der code hier
$würgaround */
> Aber vielleicht mache ich da ja Blödsinn. Wie macht Ihr denn das, wenn
> sich herausstellt, daß sich etwas nicht nach der Planung realisieren
> läßt? Meinetwegen ein Fehler im Betriebssystem oder ein Fehler im
> Compiler (hatte ich auch schon mal und kein Update in Sicht)?
Komnt drauf an was genau klemmt. Im Extremfall wegwerfen und
neuschreiben. Ja, das ist ernst gemeint. Mit den Erfahrungen des
ersten Versuches einen zweiten neu zu starten kann durchaus einfacher
sein als den ersten Versuch zu fixen.
> Programmiert hier noch jemand hardwarenah?
Ja.
Gerd
Juergen Beisert
>Klingt nach verbesserungswürdiger Struktur des Codes. Wenn man einen
>Bugfix (oder Workaround) an vielen Stellen unterbringen muß sollte man
>sich mal fragen wieso das so ist. Und vielleicht den entsprechenden
>code in eine eigene Funkion auslagern statt denselben per cut+paste zu
>duplizieren.
War nicht ganz so gemeint. Der eigentliche Bugfix ist schon an nur einer
Stelle. Aber mancchmal zieht sich das nach oben weiter. Dann muß schon
in der Aufrufhierarchie was geändert werden und spätestens, wenn man ein
Programm von oben her versucht zu analysieren, ist man dankbar wenn
einem was unverständliches unterkommt und man den Hinweis hat: Das ist
so weil weiter unten was nötig war...
Beispielsweise in einer schönen eleganten Interruptroutine. Nur daß der
blöde Chip hin und wieder einen Interrupt vergißt. Aber natürlich nicht
immer, sondern nur bei ganz bestimmten Operationen (wär ja sonst zu
einfach). Also noch einen Timer dazugenommen, den ich aber an einer ganz
anderen Stelle aufsetzen muß, weil es in der Interruptroutine nicht
geht. Und dann steckt der Workaround plötzlich an Stellen, wo man beim
Lesen rein gar nichts damit anfangen kann.
>
>Hmm. Programmierung mit Trial-and-Error? Ok, geht manchmal nicht
>anders, wenn die Doku <zensored> ist. Aber ich würde wohl nicht alle
>Versuche in den Kommentaren dokumentieren, sondern nur die
>funkionierende Variante kommentieren
Soll eigentlich nur verhindern, daß ich nochmals einen alten
Lösungsansatz (der nicht funktionierte) probiere, weil ich ein paar
Monate nichts damit gemacht habe. "Doku <zensored> ist" ist gut. Ich
habe einen haufen Register, deren Werte nur anhand von ein paar
Beispielen gegeben wurden. Die passen natürlich nicht zu meiner
Umgebung. Also trial and error (von etwa 220 Registern sind 38 nicht
näher erklärt, nur das sie halt da sind).
>
>> Aber vielleicht mache ich da ja Blödsinn. Wie macht Ihr denn das, wenn
>> sich herausstellt, daß sich etwas nicht nach der Planung realisieren
>> läßt? Meinetwegen ein Fehler im Betriebssystem oder ein Fehler im
>> Compiler (hatte ich auch schon mal und kein Update in Sicht)?
>
>Komnt drauf an was genau klemmt. Im Extremfall wegwerfen und
>neuschreiben. Ja, das ist ernst gemeint. Mit den Erfahrungen des
>ersten Versuches einen zweiten neu zu starten kann durchaus einfacher
>sein als den ersten Versuch zu fixen.
Seufz ;-)
JB
Juergen Beisert
<kin...@gmx.at> wrote:
>> On 18 Jul 2002 10:17:11 GMT, Gerd Knorr <kra...@bytesex.org> wrote:
>
>
>Ich wage nicht zu behaupten, dass ich oft große Projekte hab... aber
>wenn mir sowas passiert, also etwas auf irgendeine Art und weise nicht
>funktioniert, dann kopier ich mir die ganzen Bugs in ein Verzeichnis
>zusammen, mit kleinen Source-Code-Beispielen und werf die alte Doku
>aus dem Quellcode.
>
>Im Quellcode verweis ich eventuell noch kurz aufs diese externe Doku.
>
>Der Vorteil daran ist, diese externe Doku ist schon beim erstellen
>quasi veraltet und man braucht sie praktisch nicht mehr warten.
>
Das ist eine gute Idee. Man muß zwar auch wieder an mehreren Stellen
suchen, um sich einen Überblick zu verschaffen, aber vielliecht
überwiegt der Vorteil. Bisher bin ich eher der Meinung gewesen, daß
Informationen, die zusammegehören auch an der selben Stelle erwähnt
werden sollten. Aber so richtig weiter bringt mich diese Methode ja nun
nicht mehr...
JB
Andreas Bierhals
Rudolf Polzer <AntiATFiel...@durchnull.de> writes:
> Auf jeden Fall muss man aber Kommentare wie
>
> uint8 x837942_reg_read_0x18 ()
> {
> x837942_reg_write (0x17, x837942_reg_read (0x17));
> // Reading from 0x18 yields wrong values directly after 0x47 was
> // written to, so let's just do something with another register.
> // 0x17 is completely harmless to use for this purpose.
>
> return x837942_reg_read (0x18);
> }
>
> schreiben...
nicht zwingend... Warum nicht so ein Konstrukt wie
// bugfixes.cc
// ...
void avoid_0x18_bug(void) {
x837942_reg_write (0x17, x837942_reg_read (0x17));
}
// steuerung.cc ...
uint8 x837942_reg_read_0x18 () {
avoid_0x18_bug();
return x837942_reg_read(0x18);
}
MfG
Andreas
Rudolf Polzer
> Rudolf Polzer <AntiATFiel...@durchnull.de> writes:
> > Auf jeden Fall muss man aber Kommentare wie
> >
> > uint8 x837942_reg_read_0x18 ()
> > {
> > x837942_reg_write (0x17, x837942_reg_read (0x17));
> > // Reading from 0x18 yields wrong values directly after 0x47 was
> > // written to, so let's just do something with another register.
> > // 0x17 is completely harmless to use for this purpose.
> >
> > return x837942_reg_read (0x18);
> > }
> >
> > schreiben...
>
> nicht zwingend... Warum nicht so ein Konstrukt wie
>
> // bugfixes.cc
C++?
> // ...
>
> void avoid_0x18_bug(void) {
^
Wenn schon C++, dann gleich noch "inline" und in einen anonymen
Namespace rein. Bei C noch sowas wie "static INLINE" davor (mit einem
entsprechenden INLINE-Makro, das je nach Compiler zu inline oder nichts
wird).
[...]
Das ist auch so eine Stilfrage - wenn der Bug auch beim Schreiben auf
das Register 0x18 auftreten kann, ist es gut, den Würgaround in einer
Funktion zu haben. Wenn ich aber eine Funktion nur an einer einzigen
Stelle aufrufe und das auch weiß, würde ich den Code nur an dieser einen
Stelle hinschreiben und nicht in eine Funktion (aber evtl. in einen
Block) packen.
Was aber hier nach wie vor fehlt, wäre:
- dass der Bug nur nach Schreiben auf 0x47 auftritt
(Optimierungspotenzial!)
- dass 0x17 ein reines RW-Datenregister ist (für den Fall, dass man
später noch einen anderen Chip unterstützen will, bei dem man 0x17
nicht mehr so einfach dafür verwenden kann)
Gerd Knorr
> blöde Chip hin und wieder einen Interrupt vergißt. Aber natürlich nicht
> immer, sondern nur bei ganz bestimmten Operationen (wär ja sonst zu
> einfach). Also noch einen Timer dazugenommen, den ich aber an einer ganz
> anderen Stelle aufsetzen muß, weil es in der Interruptroutine nicht
> geht.
Aargh. Welches $unix ist das? Der Linux-Kernel erlaubt das Starten
eines Timers auch im IRQ-Kontext. Das braucht man auch dringend, weil
das Absichern von irqs per timeout-timer _immer_ eine gute Idee ist,
nicht nur bei bekannten HW-Bugs ...
Juergen Beisert
>Aargh. Welches $unix ist das? Der Linux-Kernel erlaubt das Starten
>eines Timers auch im IRQ-Kontext. Das braucht man auch dringend, weil
>das Absichern von irqs per timeout-timer _immer_ eine gute Idee ist,
>nicht nur bei bekannten HW-Bugs ...
In dem Fall mal kein Linux, sondern ein Microcontroller mit nur 4k RAM
und einem Bildverarbeitungs-Chip. Mußte alles sehr sparsam programmiert
werden. Wäre auch schön und elegant geworden, wenn der Chip nicht
soviele Macken hätte...
JB