Re: [RFC - Python Scripting] New method gdb.Symtab.blocks_iterator - docs included

[Siva Chandra <sivachandra at google dot com>]

Thanks Eli and Tom for taking a look.

Tom, I have addressed all your comments.  For some of them, I have my
own comments below.  The updated patch is attached.

Code -
2012-04-10  Siva Chandra Reddy  <sivachandra@google.com>

        Add a new method gdb.Symtab.blocks to iterate
        over the scope blocks of a symbol table.
        * NEWS (Python scripting): Add entry about the new method.
        * python/py-symtab.c (symtab_blocks_iterator_object): New
        iterator type to iterate over the scope blocks of a symtab.
        (stpy_blocks): New function which implements the new method.
        (symtab_blocks_iterator_dealloc): New function which serves
        as the tp_dealloc function for symtab_blocks_iterator_object.
        (symtab_blocks_iterator_iter): New function which serves as
        the tp_iter function for symtab_blocks_iterator_object.
        (symtab_blocks_iterator_iternext): New function which serves as
        the tp_iternext function for symtab_blocks_iterator_object.
        (gdbpy_initialize_symtabs): Add initializations for the new
        iterator type.

Docs -
2012-04-10  Siva Chandra Reddy  <sivachandra@google.com>

        * gdb.texinfo (Symbol Tables In Python): Add description about
        the new method gdb.Symtab.blocks.

Tests -
2012-04-10  Siva Chandra Reddy  <sivachandra@google.com>

        * gdb.python/py-symtab.exp: Add tests to test the new method
        gdb.Symtab.blocks.

Tom > It seems to me that the Symtab itself could provide the iterator so you
Tom > could just write:
Tom >
Tom > ? ?for block in symtab:
Tom > ? ? ?...
Tom >
Tom > The precedent here is that gdb.Block is also an iterator over symbols.
Tom >
Tom > Alternatively, 'Symtab.blocks'.
Tom > I find 'blocks_iterator' a bit too wordy somehow.
Tom >
Tom > What do you think of those?

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

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.

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

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

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

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

Tom> We were recently discussing that it is preferable to give each
Tom> executable its own name, so that if the test fails it is simpler to
Tom> reproduce the problem from outside dejagnu.
Tom>
Tom> So, please choose a new name for the executable here.

The source file py-symbol.c is used by py-symtab.exp as well as by
py-symbol.exp.  Hence, I have changed in py-symtab.exp to use
executables py-symbol-symtab and py-symbol-symtab-cc.

Thanks,
Siva Chandra

Attachment: blocks_iterator_patch_v2.txt
Description: Text document