Mail Archives: djgpp/1995/06/09/14:38:27
Joel Hunter (jhunter AT kendaco DOT telebyte DOT com) wrote:
: dj AT delorie DOT com (DJ Delorie) wrote:
: [HUGE CHUNK OF VERY RELEVANT STUFF DELETED]
: >> software that's going to go away in the near future, the documentation of
: >> GO32 would be a horrible amount of effort. Right? Now, if you've looked
: >> at V2 and see similar problems, that might be a lot more important.
: >> But... Who's gonna do the writing?
Everyone and anyone. If you make changes to code, try to
ensure that others will be able to follow it, perhapse > 1 comment
every 5 lines (i usually do >1 comment /line because the meaning
and sideffects of code are so complex etc). Think about it you can
spend a whole day hacking 100 lines. Now 20 lines (or even 100)
explaining those hacks takes 30 minutes.
: >Well, enough from me. Remember, "you are free to do what you want, as
: >long as you don't stop others from being free to do what they want."
Well i didnt mean rigidized coding rules. Only written
guidelines how contributers would (ideally) set about making their
code explicitly and implicitly documenting. Now if someone really
hasnt got the time, and puts up a quick hack, and its really useful,
then i'm sure some people are going to go thru all the tedium of
deciphering the code, and fixing it. After code is hard to come by.
: Is this a request? How about the guy who started this thread try to
: organize such an ordeal. Even if I didn't write the libraries, I'll
: bet that at least 50% (probably more like 80%) are clear enough that
I'm the person that started this thread (and an important one
IMHO).
The libraries and most of the utilities are fine (but like most
FSF source, comments are lacking). I dont think there is any need to
document the libraries; they are relatively self-contained, short,
good naming schemes, and their functionality is well understood. And
there are many equivalent sources to fall back on.
As mensioned, the go32 sources are.....well....interesting
to understand. There is some truth that go32 will go away in favour
of cwsdpmi; one wonders exactly why go32 needed to be dropped
and parts re-written.
However cwsdpmi (i havent really looked closely at the sources
yet, since it seems to work quite reliably, but i suspect its written
well) and the hooks/stubs to dpmi are what *make* djgpp. There is nothing
else to fall back on when things go wrong (except maybe rsw/gccdpmi).
We all know that N heads are better than one. The problem
(as with any concurrent system) is getting the message accross to the
N heads. This doesnt reflect on the original message (author), being
merely a matter of communication and protocol. And lets face it, its
quite unfair that all the burden of developing djgpp is lumped on
Charles Sandmann or DJ. So people want to contribute and accellerate
djgpp becoming a mature enviornment, but chicken and the egg problem;
we want to help, but we cant understand, but we need to understand to
help.
So as a sign of good faith, i will document all of go32targ.c
(the djgpp hooks for gdb) in the next release of gdb20pat.zip
.. I hope this helps, since djgpp's gdb has quite a few more bugs to
squash. I also hope that it demonstrates to people that i'm not just
winging, code bashing, or documentation preaching. Code standards
are a necessity, because we need to be professional, we need to make
our job easier, we need to leave something for the next person to
understand, and we need to be proud of the code we write (after all
we're not getting paid for it).
BTW would anyone that has made changes to the gdb sources
get in touch with me. Re readline/readline.c Mr "TGR". Fertile
gounds for hacking! If only i could figure out why so many changes
were made.
Junaid Walker.
- Raw text -