From: Stan Shebs <shebs@apple.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>,
fnf@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: RFA: "maint print type" should print all the flag bits
Date: Tue, 11 Dec 2001 11:16:00 -0000 [thread overview]
Message-ID: <3C165B8A.51ABC0A2@apple.com> (raw)
In-Reply-To: <npy9k9ziu2.fsf@zwingli.cygnus.com>
Jim Blandy wrote:
>
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> > > They're only meant for use by GDB developers.
> >
> > How do you expect the GDB developers to discover their existence if
> > they aren't documented? Even if they do discover their existence, how
> > would a developer who never used a particular command know what it
> > does? The built-in doc strings are terse and don't explain much. For
> > example, suppose i use "maint print type" and see it print
> > TYPE_FLAG_TARGET_STUB--how do I figure out what that means? (If you
> > think that GDB's sources explain that clearly, think again ;-)
> >
> > I think every command should be documented in the manual.
>
> Well, you're right, of course. There's no good reason *not* to
> document them, other than laziness.
I'll mention again a script that I had Jason write one time (that's
probably lost to posterity), which was to collect all the
commands in the sources, and all the commands documented in the
manual, and diff the two. Very handy, because it shows commands
that are not documented, and encourages both manual and source to
be written in a fashion that makes it easy for the script to find
them.
(And yes, the followup suggestion will be to generate both source
and doc from a single file, but that's a big project. The comparison
script would only take an hour or two to get to the point of bein
useful.)
On the location of maint command docs, I don't think it matters
much whether it is in appendix or regular chapter. Readers will
be smart enough to realize that they don't need to use the commands
unless a GDB maintainer asks them to run one.
Stan
prev parent reply other threads:[~2001-12-11 19:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-09 11:14 Fred Fish
2001-12-09 19:08 ` Jim Blandy
2001-12-10 1:03 ` Eli Zaretskii
2001-12-10 12:44 ` Jim Blandy
2001-12-11 0:18 ` Eli Zaretskii
[not found] ` <3C162900.288B@redhat.com>
2001-12-11 9:21 ` Eli Zaretskii
2001-12-11 10:59 ` Andrew Cagney
2001-12-11 11:44 ` Daniel Jacobowitz
2001-12-11 17:47 ` Andrew Cagney
2001-12-11 19:14 ` Daniel Jacobowitz
2001-12-12 0:29 ` Eli Zaretskii
2001-12-12 0:29 ` Eli Zaretskii
2001-12-11 10:55 ` Jim Blandy
2001-12-11 11:16 ` Stan Shebs [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C165B8A.51ABC0A2@apple.com \
--to=shebs@apple.com \
--cc=eliz@is.elta.co.il \
--cc=fnf@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@zwingli.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox