Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Siva Chandra <sivachandra@google.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Tom Tromey <tromey@redhat.com>, Doug Evans <dje@google.com>,
	gdb-patches@sourceware.org
Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks
Date: Fri, 27 Apr 2012 13:15:00 -0000	[thread overview]
Message-ID: <CAGyQ6gzqGh=ABfs9a5nnjAw0SyyONx+OGdEKGMcEmcOFom=yEA@mail.gmail.com> (raw)
In-Reply-To: <83fwbqinsw.fsf@gnu.org>

On Thu, Apr 26, 2012 at 7:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Maybe I simply miss something important here.  The text in question
> says this:
>
>   A @code{gdb.Block} is iterable.  The iterator returns the symbols
>   (@pxref{Symbols In Python}) local to the block.  Users using this
>   feature should keep in mind that future improvements to the internal
>   representation, of symbols and symbol tables, can move symbols across
>   blocks within a symbol table.
>
> Are you saying that future changes will prevent the possibility to
> get the symbols local to the block by iterating it?  That's not what
> the last sentence above seems to say.  It says that the symbols might
> be found in a different block, or something to that effect.  At least
> that's what I understand from reading it.  If my understanding is
> correct, how would my Python program that works today break with
> future versions of GDB?

This is my thought:  Take Tom's example of current 'globals' ending up
in a namespace block due to a future change.  Now, this is just an
example.  Meaning, a future existence of a namespace block is a
speculation now.  Since it is a speculation, it could eventually so
happen that we will not have a namespace block but something else or
nothing at all.  Hence, how things would change are unknown now, but
there is a chance that things will change.  What Doug and Tom are
trying to say is that, "It is OK to use the API now and for some time
in future, but keep an eye out for changes and change accordingly."
Also, since how things would change in future is unknown now, it is
probably not possible to specify now as to how exactly would a Python
program break in future.

AFAICT, if there is a change in future which can break an existing
Python program, or change the API behavior, then we mention this in
the docs and NEWS then. (?)

Thanks,
Siva Chandra
PS: I used the namespace block as an example and called it a
speculation.  It probably is not a speculation but a real plan!


  reply	other threads:[~2012-04-27 11:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  8:13 Siva Chandra
2012-04-25  9:02 ` Eli Zaretskii
2012-04-25 20:02   ` Tom Tromey
2012-04-25 21:02     ` Eli Zaretskii
2012-04-26 14:04       ` Tom Tromey
2012-04-26 14:17         ` Eli Zaretskii
2012-04-27 13:15           ` Siva Chandra [this message]
2012-04-27 15:38             ` Eli Zaretskii
2012-04-27 16:59               ` Doug Evans
2012-04-27 17:33                 ` Eli Zaretskii
2012-04-27 17:46                   ` Doug Evans
2012-04-27 19:42               ` Siva Chandra
2012-04-28  7:15                 ` Eli Zaretskii
2012-04-30 19:20                   ` Siva Chandra
2012-05-02 17:32                     ` Siva Chandra

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='CAGyQ6gzqGh=ABfs9a5nnjAw0SyyONx+OGdEKGMcEmcOFom=yEA@mail.gmail.com' \
    --to=sivachandra@google.com \
    --cc=dje@google.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.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