On Tue, 14 Dec 1999 13:38:02 +0100 (MET), Asger K. Alstrup Nielsen
wrote:
>> So my idea was something similar to this:
>>
>> Setup each source file with a comment form just at the beginning,
>> something like the following and ask developers to fill them by and by
>> (I think this will work better than abstract recommendations):
>
>[commenting policy]
>
>Yes, this is very nice. However, it's overkill. Let's just
>clean up the existing header files, and add comments where
>appropriate.
>It is not realistic to impose a policy and expect that all
>random contributors will heed to it. Instead, we should just
>set a nice example.
Developers will soon contribute their own ideas on better comment
policy and give better examples. They are too 'creative' to follow some
dull pattern which they feel they can do better. The idea is only to
encourage them to invest some minutes in thinking of those poor others
which must read their code someday.
An example is good, a small form is better: Makes commenting in fact
easier and is well 'tested' psychology, "recommended by friendly
bureaucrats worldwide" ;-)
>
>> Another somewhat more general point here: cvs is rapidly changing. Once
>> having setup some working patch the update is likely to break it.
>
>Actually, the breakage percentage is not high. cvs does a remarkable job
>at avoiding conflicts.
OK
>[I say that system code is best tested by deployment in an open source
>setting.]
>> Is it really? Bug tracing is AFAIK all in all by far the most costly
>> part of software development (some 10:1 or 20:1 depending on
>> complexity). Some kind of 'quality management' might be painful at
>> first but most cost effective on the long run.
>
>Notice that I was talking about system code. System code is special in
>the sense that the bugs that appear, appear because the interfaces differ
>on different platforms. The only way to determine this is by trying it
>on all different platforms. The best way to try code an all platforms
>is to put it into LyX, and let people report the problems they find.
>
>The only cost effective way to test system code is by testing. It's
>impossible to predict the problems that appear on different platforms,
>because of buggy operating systems, missing standards, and the phase
>of the moon. And since it's impossible for me as an individual person
>to have access to all relevant operating systems and architectures, the
>only way to go about this business is to write the code, release it, and
>then weed out all the inevitable problems that appear.
There is some kind of de facto standard, which may well be observed
right from the beginning [design!] to avoid unneeded trouble. Posix is
good in this respect, ANSI helps much, and there is a modification of
Posix as a de facto standard api, which is present on win32 and OS/2
and works especially well with cygwin or emx.
(The only prominent differences to Posix I can remember now are the
notorious 'drive letter/backslash' issue and the split fork()/exec*()
and spawn*(), resp. Different shell semantics is another well known
problem, which is mostly up to the sysadmin. This should not not be too
difficult to keep in mind and really helps people to avoid
frustration.)
Don't bother about the few losing systems which are totally
incompatible with Posix. (I'll always remember my EpiX shock
(ControlData et. al.), which those lost souls dared to claim to be a
Unix variant, *shudder*).
Others like BeOS are modelled after this, i.e. Posix + variants, so
porting is not so difficult then. (Even complicated api's like pthreads
exist nearly everywhere or are at least a good base for trivial ports
to 'xyz native'.)
Testing is still necessary. You cannot avoid this by any reasonable
effort.
>
>> >The method is not dummy on Unix. It's better to have the same structure
>> >across platforms, even if the implementation is different (or missing.)
>>
>> If a child is started with exec*() instead of spawn*() emx might need a
>> waitForChild() which is not a dummy. Making it dummy is a good way to
>> introduce a hard to trace bug in the future.
>
>Ok, so the solution might be to introduce a new set of functions that
>abstract these two fundamentally different interfaces: One set for
>functions that don't wait, and one that waits.
Sounds nice, I just cannot decide, if it is worthwile.
>
>I think we can agree that using the preprocessor to prevent semantic
>programming errors that are caught at link time is a bad idea. The
>preprocessor is not meant for imposing semantic information, and the
>linker is suboptimal for compile time error diagnostics, because it can
>only say that there is a problem, not where the problem is.
>Let's solve the problem is the correct manner: By imposing the correct
>semantic structure in the code, rather than in the preprocessor.
Yup, use the correct semantics! The prepro traditionally has been
widely used as a last resource for hackish semantic adaptation (think
of all this system specific prepro symbols and assertions, e.g. UNIX,
SYSV, USG, __win32__, __BEOS__, etc.), but this most probably was
always a bad idea. Worse is only to introduce those hidden bugs in the
code, which can be easily avoided.
So, just give the direction, I'll try to implement then.
Greets,
Arnd
