Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Siva Chandra <sivachandra@google.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
Subject: Re: [RFC - Python Scripting] New method gdb.Symtab.blocks_iterator - docs included
Date: Tue, 10 Apr 2012 22:21:00 -0000	[thread overview]
Message-ID: <87398b4582.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAGyQ6gyhM5UP9uoAGzuY2mTYp4K4XjO0FPPuq_G5Pu=wA57xEQ@mail.gmail.com>	(Siva Chandra's message of "Tue, 10 Apr 2012 13:14:28 +0530")

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> I have picked Symtab.blocks.  I personally don't like making Symtab
Siva> iterable as blocks are just one of them.

Doug's note made me start wondering why iterating over all the blocks
made sense here -- and now I tend to think it doesn't.

I think it would be a bit more future-proof to just let the user access
the symtab's global and static blocks, then rely on iteration over
symbols within a block.  This would mean also adding a way to fetch a
block's subblocks.

The reason I see this as more future-proof is that I think the block
structure, including global and static blocks, is a feature of the
underlying problem.  So, it is much less likely to change if we need to
refactor symtabs or blocks.  (And, in fact, my lazy block-reading code
would have mild problems with your iterator, but no troubles at all in
this approach.)

Sorry about this change of mind...

Siva> +   block_object = block_to_block_object (block, symtab->objfile);
Siva> +   if (! block_object)
Siva> +     {
Siva> +       PyErr_SetString (PyExc_RuntimeError,
Siva> +                        _("Unable to get the next gdb.Block object."));

Tom> If block_to_block_object fails, then the error will already be set.
Tom> I think it is generally better to propagate the original exception in
Tom> cases like this.  Otherwise, the new exception may obscure some more
Tom> fundamental error.

Siva> block_to_block_object just returns NULL on failure.  Am I missing
Siva> something?

If it returns NULL then it has already set the Python exception.  This
is a Python coding convention that we follow in many places.  E.g., in
block_to_block_object, the NULL return can only happen if PyObject_New
fails; but if that fails and returns NULL, then it is guaranteed to have
set the exception; and therefore the same is true for
block_to_block_object.

Siva> +   (iter->iter_index)++;

Tom> Also I'm curious if an error should invalidate the iterator in some way.

Siva> Since the iterator exists only in Python environment, my opinion is
Siva> that if the iterator gets invalidated, the execution should never
Siva> reach this place.   Do you see something else?

Can't the caller ignore the error and call iter.next again?
But I think it probably doesn't matter.
The best thing would be to see if there is some Python standard here;
if so, follow it; if not, do whatever is convenient.

Tom


  parent reply	other threads:[~2012-04-10 22:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-09 18:34 Siva Chandra
2012-04-09 20:47 ` Eli Zaretskii
2012-04-10  1:38 ` Tom Tromey
2012-04-10  7:45   ` Siva Chandra
2012-04-10 17:16     ` Doug Evans
2012-04-10 22:21     ` Tom Tromey [this message]
2012-04-11  4:59       ` Siva Chandra
2012-04-11  5:44         ` Doug Evans
2012-04-12 15:20         ` Tom Tromey

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=87398b4582.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=sivachandra@google.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