public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: John Baldwin <jhb@FreeBSD.org>
Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
Subject: Re: [PATCH 0/8] Rewrite gdbarch.sh in Python
Date: Thu, 16 Dec 2021 12:13:43 -0700	[thread overview]
Message-ID: <87wnk4wefs.fsf@tromey.com> (raw)
In-Reply-To: <c951ec77-b66f-7d7c-b3d8-a01e4e3fe3be@FreeBSD.org> (John Baldwin's message of "Thu, 16 Dec 2021 10:02:21 -0800")

John> I do like having the data (components.py) separate from the generator
John> (gdbarch.py).  I would agree with Simon about possibly renaming the
John> data to be more specific to gdbarch (e.g. gdbarch-components.py is
John> what Simon suggested I think?).

That's what I used.

John> I did not look in detail (and did not review the actual python code at
John> all).  One thing I did find a bit odd is that the type of "variable"
John> members (Value and Info?) is "return_type".  Using "return_type" for
John> the return type of Methods makes sense, but I think for Value and
John> Info just using "type" might be more intuitive?  Not sure though it
John> that is a pain to deal with in gdbarch.py.

I changed it to "type" everywhere.  Initially I didn't do this because
"type" is a Python built-in, but as a member name I guess it doesn't
matter.  It's convenient to use the same name for all classes, though if
we really need to, we could probably use different names in the
constructors and then rename before assigning to members.

Tom

  reply	other threads:[~2021-12-16 19:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 22:45 Tom Tromey
2021-12-15 22:45 ` [PATCH 1/8] Move ordinary gdbarch code to arch-utils Tom Tromey
2021-12-15 22:45 ` [PATCH 2/8] Split gdbarch.h into two files Tom Tromey
2021-12-15 22:45 ` [PATCH 3/8] Do not generate gdbarch.h Tom Tromey
2021-12-15 22:45 ` [PATCH 4/8] Do not sort the fields in gdbarch_dump Tom Tromey
2021-12-15 22:45 ` [PATCH 5/8] Generate new components.py from gdbarch.sh Tom Tromey
2021-12-16  1:31   ` Simon Marchi
2021-12-16 18:46     ` Tom Tromey
2021-12-17 16:41       ` Simon Marchi
2021-12-15 22:45 ` [PATCH 6/8] Add new gdbarch generator Tom Tromey
2021-12-16  2:01   ` Simon Marchi
2021-12-16 18:56     ` Tom Tromey
2021-12-16 18:57       ` Tom Tromey
2021-12-16 19:03         ` Tom Tromey
2021-12-15 22:45 ` [PATCH 7/8] Remove gdbarch.sh Tom Tromey
2021-12-15 22:45 ` [PATCH 8/8] Document components.py Tom Tromey
2021-12-16  1:46   ` Simon Marchi
2021-12-16 20:19     ` Tom Tromey
2021-12-16 18:02 ` [PATCH 0/8] Rewrite gdbarch.sh in Python John Baldwin
2021-12-16 19:13   ` Tom Tromey [this message]
2021-12-17 19:23     ` John Baldwin

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=87wnk4wefs.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@FreeBSD.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).