From: Eli Zaretskii <eliz@gnu.org>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 12/12] NEWS and Doc on --available-children-only
Date: Fri, 14 Feb 2014 09:40:00 -0000 [thread overview]
Message-ID: <83ha82c9rf.fsf@gnu.org> (raw)
In-Reply-To: <1392367471-13527-13-git-send-email-yao@codesourcery.com>
> From: Yao Qi <yao@codesourcery.com>
> Date: Fri, 14 Feb 2014 16:44:31 +0800
>
> gdb/doc:
>
> 2014-02-14 Pedro Alves <pedro@codesourcery.com>
> Yao Qi <yao@codesourcery.com>
>
> * gdb.texinfo (GDB/MI Variable Objects): Update doc of MI
> commands "-var-create", "-var-info-num-children" and
> "-var-list-children".
> (GDB/MI Support Commands): Document the new
> "available-children-only" entry in the output of the
> "-list-features" command.
Thanks. I have a few comments:
> + ** The commands -var-create, -var-info-num-children and
> + -var-list-children now accept an option
> + "--available-children-only". When used, only the available
> + children are displayed. Support for this feature can be verified
> + using the "-list-features" command, which should contain
> + "available-children-only".
This doesn't really say much about the new option, because what
"available children" means is not explained at all. Can you add a
sentence about that, or, better, reword this sentence
When used, only the available children are displayed.
so that the second part explains which children will be displayed and
which won't?
> +If the @samp{--available-children-only} option is specified, then only
> +available or collected children of the varobj are considered.
Again, without explaining what "available children" means, or maybe
which children might be "unavailable", this description just repeats
the name of the option.
> The number of children of the varobj. This number is not necessarily
> -reliable for a dynamic varobj. Instead, you must examine the
> -@samp{has_more} attribute.
> +reliable for a dynamic varobj or for a non-dynamic varobj if the
> +@samp{--available-children-only} option was specified.
When --available-children-only is specified, isn't it true that this
number is unreliable for _any_ varobj? If so, please rephrase to make
that explicit.
> -For a dynamic varobj, this indicates whether there appear to be any
> -children available. For a non-dynamic varobj, this will be 0.
> +For a dynamic varobj, or for a non-dynamic varobj when the
> +@samp{--available-children-only} option is specified, this indicates
> +whether there appear to be more children that haven't been listed yet,
> +which can be listed with a following @code{-var-list-children}
> +command. For the other cases, this will be 0.
Same here.
> +Note that this number is not completely reliable for a dynamic varobj
> +or for a non-dynamic varobj that is listing only available or
> +collected children. It will return the current number of children,
> +but more children may be available.
And here.
> +If for a given varobj, the presence of the
> +@samp{--available-children-only} option changes between invocations of
> +the @code{-var-create}, @code{-var-list-children} or
> +@code{-var-info-num-children} commands, the list of children is
> +reinitialized.
"Presence of the ... option changes" sounds awkward. Does this
sentence say anything important? IOW, does reinitialization of the
list of children have any user-visible effects? If not, perhaps it is
better to delete it. If you think this is needed, then I'd rephrase
like this:
If you use any of the commands @code{-var-create},
@code{-var-list-children}, or @code{-var-info-num-children} with the
@samp{--available-children-only} option followed by any of these
commands without that option, or vice versa, the list of children is
reinitialized.
> @smallexample
> - -var-list-children [@var{print-values}] @var{name} [@var{from} @var{to}]
> + -var-list-children
> + [--available-children-only]
> + [@var{print-values}] @var{name} [@var{from} @var{to}]
> @end smallexample
Will the reader understand that this is one long line broken for
readability? If not, perhaps you should tell that explicitly.
> +If the @samp{--available-children-only} option is specified, then only
> +available or collected children of the varobj are considered.
Once again, "available children" needs to be explained.
> +If for a given varobj, the presence of the
> +@samp{--available-children-only} option changes between invocations of
> +the @code{-var-create}, @code{-var-list-children} or
> +@code{-var-info-num-children} commands, the list of children is
> +reinitialized.
Same comment as above.
> @item new_num_children
> -For a dynamic varobj, if the number of children changed, or if the
> -type changed, this will be the new number of children.
> +For a dynamic varobj, or non-dynamic varobj that had been created as
> +consequence of the @samp{--available-children-only} option to the
> +@code{-var-create}, @code{-var-list-children} or
> +@code{-var-info-num-children} commands, if the number of children
> +changed, or if the type changed, this will be the new number of
> +children.
This sentence is now too long and complicated to be clear. Suggest to
break into 2 sentences. E.g., leave the original sentence as is, and
then add something like
Similarly for a non-dynamic varobj that was created as result of the
@samp{--available-children-only} option ...
next prev parent reply other threads:[~2014-02-14 9:40 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-14 8:46 [RFC 00/12 V2] Visit varobj available children only in MI Yao Qi
2014-02-14 8:46 ` [PATCH 07/12] MI option --available-children-only Yao Qi
2014-04-24 20:02 ` Keith Seitz
2014-02-14 8:46 ` [PATCH 05/12] Rename varobj_pretty_printed_p to varobj_is_dynamic_p Yao Qi
2014-04-24 17:39 ` Keith Seitz
2014-05-21 18:02 ` Tom Tromey
2014-02-14 8:46 ` [PATCH 01/12] Use 'struct varobj_item' to represent name and value pair Yao Qi
2014-04-23 18:16 ` Keith Seitz
2014-05-21 17:53 ` Tom Tromey
2014-02-14 8:46 ` [PATCH 11/12] Test case Yao Qi
2014-04-18 11:45 ` Yao Qi
2014-04-24 20:53 ` Keith Seitz
2014-02-14 8:46 ` [PATCH 08/12] Iterator varobj_items by their availability Yao Qi
2014-04-24 20:28 ` Keith Seitz
2014-02-14 8:46 ` [PATCH 10/12] Match dynamic="1" in the output of -var-list-children Yao Qi
2014-04-24 20:50 ` Keith Seitz
2014-02-14 8:46 ` [PATCH 09/12] Delete varobj's children on traceframe is changed Yao Qi
2014-04-24 20:45 ` Keith Seitz
2014-02-14 8:46 ` [PATCH 06/12] Use varobj_is_dynamic_p more widely Yao Qi
2014-04-24 18:17 ` Keith Seitz
2014-05-21 18:04 ` Tom Tromey
2014-02-14 8:46 ` [PATCH 04/12] Remove #if HAVE_PYTHON Yao Qi
2014-04-23 19:25 ` Keith Seitz
2014-05-21 17:52 ` Tom Tromey
2014-02-14 8:46 ` [PATCH 02/12] Generalize varobj iterator Yao Qi
2014-04-23 19:24 ` Keith Seitz
2014-05-21 17:51 ` Tom Tromey
2014-05-23 1:23 ` Yao Qi
2014-06-04 20:21 ` Tom Tromey
2014-06-05 5:36 ` Yao Qi
2014-06-05 18:21 ` Tom Tromey
2014-02-14 8:46 ` [PATCH 12/12] NEWS and Doc on --available-children-only Yao Qi
2014-02-14 9:40 ` Eli Zaretskii [this message]
2014-02-17 9:46 ` Yao Qi
2014-02-17 15:04 ` Eli Zaretskii
2014-02-18 2:01 ` Yao Qi
2014-02-18 5:11 ` Eli Zaretskii
2014-02-18 7:14 ` Yao Qi
2014-02-18 15:07 ` Eli Zaretskii
2014-02-14 8:46 ` [PATCH 03/12] Iterate over 'struct varobj_item' instead of PyObject Yao Qi
2014-04-23 19:29 ` Keith Seitz
2014-05-21 18:01 ` Tom Tromey
2014-05-23 1:33 ` Yao Qi
2014-06-04 20:22 ` Tom Tromey
[not found] ` <5327A296.3050605@codesourcery.com>
2014-04-04 2:00 ` [RFC 00/12 V2] Visit varobj available children only in MI Yao Qi
2014-04-17 1:12 ` ping : " Yao Qi
2014-04-21 16:20 ` Joel Brobecker
2014-04-22 2:54 ` Yao Qi
2014-06-12 7:37 ` Yao Qi
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=83ha82c9rf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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