From: Yao Qi <yao@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/2] Remove varobj_language_string, languages and varobj_languages
Date: Fri, 25 Oct 2013 13:38:00 -0000 [thread overview]
Message-ID: <526A7407.5090301@codesourcery.com> (raw)
In-Reply-To: <20131025041525.GC4769@adacore.com>
On 10/25/2013 12:15 PM, Joel Brobecker wrote:
> I think this can do for now because it is good enough, but I would
> definitely prefer we avoid this type transformation. Instead,
> I'd rather we added a new field in struct language_defn that
> provides the "natural" name.
>
I am OK to add a new field "la_varobj_name" in struct language_defn, but
seems information is duplicated a little, we have both "c++" and "C++"
in one language_defn.
>> >2013-10-18 Yao Qi<yao@codesourcery.com>
>> >
>> > * mi/mi-cmd-var.c: Include "language.h" and <ctype.h>.
>> > (mi_cmd_var_info_expression): Get language name from
>> > language_defn.
>> > * varobj.c (varobj_language_string): Remove.
>> > (variable_language): Remove declaration.
>> > (languages): Remove.
>> > (varobj_get_language): Change the type of return value.
>> > (variable_language): Remove.
>> > * varobj.h (enum varobj_languages): Remove.
>> > (varobj_language_string): Remove declaration.
>> > (varobj_get_language): Update declaration.
> Personally, I would do the language_defn update first, and then get
> rid of the xstrdup/toupper/xfree dance. But I'm open to others'
> opinion.
One drawback of xstrdup/toupper/xfree dance is that we loose the freedom
to show language name in varobj. I'll post patches in the way you
suggested if no one else has other comments here.
--
Yao (é½å°§)
next prev parent reply other threads:[~2013-10-25 13:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 0:54 [PATCH 1/2] New field la_varobj_ops in struct language_defn Yao Qi
2013-10-18 0:54 ` [PATCH 2/2] Remove varobj_language_string, languages and varobj_languages Yao Qi
2013-10-25 4:15 ` Joel Brobecker
2013-10-25 13:38 ` Yao Qi [this message]
2013-10-26 4:09 ` Joel Brobecker
2013-10-28 12:50 ` [PATCH 1/3] Constify 'la_name' in struct language_defn Yao Qi
2013-10-28 12:50 ` [PATCH 2/3] New field 'la_natural_name' " Yao Qi
2013-10-28 18:34 ` Tom Tromey
2013-10-29 8:41 ` Yao Qi
2013-11-07 7:18 ` Yao Qi
2013-10-28 12:50 ` [PATCH 3/3] Remove varobj_language_string, languages and varobj_languages Yao Qi
2013-10-28 18:52 ` Tom Tromey
2013-10-29 8:33 ` Yao Qi
2013-10-29 16:49 ` Eli Zaretskii
2013-10-31 3:10 ` Yao Qi
2013-10-31 17:31 ` Eli Zaretskii
2013-11-07 7:23 ` Yao Qi
2013-10-28 15:02 ` [PATCH 1/3] Constify 'la_name' in struct language_defn Tom Tromey
2013-10-25 3:34 ` [PATCH 1/2] New field la_varobj_ops " Joel Brobecker
2013-10-25 13:16 ` Yao Qi
2013-10-27 12:04 ` Rename field 'lang' to 'lang_ops' ([PATCH 1/2] New field la_varobj_ops in struct language_defn) 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=526A7407.5090301@codesourcery.com \
--to=yao@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).