🚀 go-pugleaf

mitch@lynx.UUCP (Mitch Bunnell) writes:
>	You might think -- why not look at the g++ or gdb source --.  We
>	have.  It is a big, fat, bloody mess.  It will take some time to
>	gleam the information from it.  I think this will be more cost
>	effective than signing an agreement with Cygnus, however.
>
>	I personally believe that it is more important to have published
>	file formats then published source code. According to the Cygnus
>	Support Overview, "Free software is truly open software."  Not
>	if the associated file formats remain secret!

Boo, hiss.  You can hardly call the file formats secret when you have the
source code.  And I would not go so far as to call the source code a mess,
Admittedly the GNU project has a far more verbose coding style than I do,
but g++ and gdb are non-trivial programs. Remember, they have written working
C compilers and debuggers, you haven't (Like the bumper sticker says, I may
be slow, but I'm in front of you.) If you are not competent enough
to work out the file formats given the source code, you are probably wise
to sign an agreement with Cygnus (but then I haven't seen their price
schedule).  (Actually if you call the file formats secret given the C source
maybe you should consider another line of work?) If you are really serious
about doing a software project that interfaces to the gnu debugger,
the time you spend looking at their software will pay you rich dividends
when you do your work, yes it will take time in the short run, but in the
long run I bet you get your project done faster.

On the flip side of all these nasty flames -- I too would applaud whatever
documentation the Gnu folks can manage to crank out.  However, I think I
can guess two of their explanations (excuses) for not generating more.
One is that most of their stuff is Unix-like and you can get most of the
way just looking at the unix man pages (ld is a good example) if you just
want to use the stuff.  The other is that they are eager to get on with
the real heart of the Gnu project (namely the kernel) rather than loose
momentum documenting support utilities.  The code is verbose enough and
well documented that not much internal documentation is usually needed.
They have done very well documenting the stuff they have that is truly
unique (emacs, gnu-tar, gas (rumor has it the gas.doc stuff has evaporated?))

For me, the best documentation IS the source code -- lay it on me.
--
	Tom Trebisky	ttrebisky@as.arizona.edu	(Internet)
	Steward Observatory	University of Arizona	Tucson, Arizona