Mail Archives: djgpp/1995/06/06/02:52:20

Date: Tue, 6 Jun 1995 15:08:43 +1000 (EST)
From: "Junaid A. Walker" <junaid AT barney DOT eng DOT monash DOT edu DOT AU>
Subject: Re: fork()/join()
To: DJ Delorie <dj>
Cc: terra AT diku DOT dk, djgpp AT sun DOT soe DOT clarkson DOT edu

On Sat, 3 Jun 1995, DJ Delorie wrote:

> > >  Wow.  The first actual down-right rude reply I have ever seen on the
> > >DJGPP mailing-list/newsgroup.  Since when is ignorance and/or
> > >incompetence met with this level of hostility?
> > 
> > Hmm.  I do that occasionally when somebody gets the idea that they
> > are in a position to start demanding that things get done, and get
> > done now.
> > 
> > When it coincides with people whom I have never seen contribute I
> > get mad.  I assume that (e.g.) DJ also gets mad, but he's much
> > more polite.  Since he's low on sleep try pressing the issue.
> While I agree in principle, I find it much easier to just delete the
> mail than to worry about it.  I wrote djgpp for personal reasons, and
> 	"Calm down, it's only ones and zeros!"
> DJ

	Goody, because you wont mind me commenting on the coding
style of go32 and friends. Please dont take offence, just my humble

1) Serious lack of comments. This discourages people from working on
the code. Most people do like to fix code in the extender etc, but
(I) become dazzed by the code, with no comments to explain what's
happening, especially around the extender, which because it has so
much OS dependent code, is already hard to understand. Take a look at
GDB, its well comented and identifiers are carefully chosen.
I spent a day tracking down a serious bug in go32 support in gdb
(already knowing what and why it was happenning). There was very
little indication of what was going on in go32targ.c . Had to get
out the magnifying glass and pour over the code, both in go32targ.c
and gdb to figure out how and what was going on in go32targ.c .Then
fall back on fsdb to see how things should be done. Lucky it was a
trivial bug fix.

2) There really needs to be some doc describing the code changes with
versions of go32 etc (changes.doc). This is usually informative to
people making changes; they know what weaknesses exist in general,
what has been done to try and fix things in the past, and which
'problem' files exist.

3) the tex info docs seem to getting along well, atleast you can 
plug and go, and edit them.

	This all sounds like  a lot of work. But from past experience,
documenting the code is trivial...and saves a lot of hack work later on
when you are fuzzy on what things do (yes djgpp is getting that big).
As a raw guess, one line of working bug free code takes 600% more time
to get right than one line of comment. So comments that contribute
to code legibility and reliability can really pay off when they
reinforce what the coder intended (and we can check this off with what
the code really does)

	I thinks its all about minimizing effort and maximizing
results. From this point of view, djgpp has really go a raw deal,
with only a handful of good apps using it, and more revisions than


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019