>>>>> Only right at the end did I discover it was a compiler bug.

> Absolutely not IMHO, at least in the realm of bug fixing. Finding the
> source of a bug can often be only half the effort. Actually, 
> more often then not FIXING the bug is more work then finding it.

But even then finding is still at the end of the search, and "end" in
"at the end did I discover" reads to me as the end of searching, not as
"the end of the search-and-solve processes". But maybe that's my
non-native English (hinein-) interpretation.

But, IME (In My Experience) finding is often the largest part, much more
difficult than solving.

A side note about finding "the" problem. Way back when I was employed by
software/hardware companies I was often called to ckack the realy
difficult problems. One technique of locating the source of a problem is
a kind of binary search: disable part of the program (or hardware), if
the problem disappears you focus on that part and disable a smaller part
of it, if it persists you re-enable that part and look elsewhere. I
found that this technique failed me more often than I expected, because
the problem at hand (as it manifested itself) had two (I don't recall
more than two) independent sources. So whatever part you disable, the
problem would still persists (unless you happened to disable both
sources - not likely. I don't think this is typical for everyday
problems, but it happened to me more often than I expected.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist