This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type


On Mon, Sep 26, 2011 at 9:00 AM, Paul Koning <paulkoning@comcast.net> wrote:
>
> On Sep 23, 2011, at 12:33 PM, Doug Evans wrote:
>
> > On Fri, Sep 16, 2011 at 8:27 AM, Paul Koning <paulkoning@comcast.net> wrote:
> >>
> >> Below is an update with the various comments addressed.
> >
> > Hi. ?This email is for just a couple of formatting nits.
> >
> >> 2011-09-15 ?Paul Koning ?<paul_koning@dell.com>
> >>
> >> ? ? ? ?* python/py-type.c (make_fielditem, typy_field_names, typy_items,
> >> ? ? ? ?typy_length, typy_get, typy_has_key, typy_make_iter,
> >> ? ? ? ?typy_iterkeys, typy_iteritems, typy_itervalues, typy_iter,
> >> ? ? ? ?typy_iterator_iter, typy_iterator_iternext,
> >> ? ? ? ?typy_iterator_dealloc): : New functions to implement standard
> >> ? ? ? ?Python mapping methods on gdb.Type object.
> >> ? ? ? ?(gdb.TypeIterator): New Python type.
> >> ? ? ? ?* python/python-internal.h (gdbpy_iter_kind): New enum.
> >> ? ? ? ?* doc/gdb.texinfo (gdb.Type): Document field access by dictionary
> >> ? ? ? ?key syntax.
> >
> > Technically speaking, the rule is you can't extend a parenthesized name list
> > over multiple lines. ?At least that's the rule I've been asked to follow.
> > I'd like to see some flexibility here, and I'm not asking you change this here.
> > Just pointing it out.
> >
> >> +/* Helper function for Type standard mapping methods. ?Returns a
> >> + ? Python object for field i of the type. ?"kind" specifies what to
> >> + ? return: the name of the field, a gdb.Field object corresponding to
> >> + ? the field, or a tuple consisting of field name and gdb.Field
> >> + ? object. ?*/
> >> +static PyObject *
> >> +make_fielditem (struct type *type, int i, enum gdbpy_iter_kind kind)
> >
> > For functions the coding standards say to have a blank line between
> > its comment and definition.
> > I realize parts of gdb don't follow this rule, but this rule I like :-),
> > it is documented, and I'd like to not make things worse.
> >
> > This needs to be fixed in several places.
>
> I've fixed both -- the ChangeLog is now formatted according to an earlier example I see in ChangeLog.
>
> Ok to commit?
>
> ? ? ? ?paul
>
> 2011-09-26 ?Paul Koning ?<paul_koning@dell.com>
>
> ? ? ? ?* python/py-type.c (make_fielditem, typy_field_names, typy_items)
> ? ? ? ?(typy_length, typy_get, typy_has_key, typy_make_iter)
> ? ? ? ?(typy_iterkeys, typy_iteritems, typy_itervalues, typy_iter)
> ? ? ? ?(typy_iterator_iter, typy_iterator_iternext)
> ? ? ? ?(typy_iterator_dealloc): : New functions to implement standard
> ? ? ? ?Python mapping methods on gdb.Type object.
> ? ? ? ?(gdb.TypeIterator): New Python type.
> ? ? ? ?* python/python-internal.h (gdbpy_iter_kind): New enum.
> ? ? ? ?* doc/gdb.texinfo (gdb.Type): Document field access by dictionary
> ? ? ? ?key syntax.
>
> 2011-09-26 ?Paul Koning ?<paul_koning@dell.com>
>
> ? ? ? ?* gdb.python/py-type.c (enum E): New.
> ? ? ? ?* gdb.python/py-type.exp (test_fields): Add tests for Python
> ? ? ? ?mapping access to fields.
> ? ? ? ?(test_enums): New test for field access on enums.

Blech, sorry for the dup.

One changelog entry has two colons (::), but other than that
it's ok by me.  Thanks!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]