Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Matt Rice <ratmice@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 6/7] [python] API for macros: Add docs.
Date: Fri, 26 Aug 2011 14:06:00 -0000	[thread overview]
Message-ID: <CACTLOFpELPUdFzNNzhxe8xiaibaU-P+tUgARSFC5yKxfGdjcSA@mail.gmail.com> (raw)
In-Reply-To: <83r548fka3.fsf@gnu.org>

On Fri, Aug 26, 2011 at 5:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 26 Aug 2011 04:17:24 -0700
>> From: Matt Rice <ratmice@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>> That Symtab_and_line represents that single source line, and if we use
>> 'in effect',
>> without explicitly qualifying the scope under consideration,
>> we leave the user to decide under what scope macros are considered to
>> be in effect.
>> and the user's idea of that scope may or may not match the actual
>> scope that the function uses.
>
> I expect the users to know the definition of a macro scope.  Are you
> talking about some specific ambiguity, or in general?  If the former,
> what is the ambiguity?
>
>> e.g. it could be from `0 - line' as it is, or it could be 'macros used
>> from line - line end'
>> (which is a function we do not even implement.)
>
> "In effect" means that a macro _can_ be used in this line.  I don't
> see any ambiguity here, and it surely isn't the job of the GDB manual
> to teach the rules of defining and using macros.
>
>> >> how about the following.
>> >>
>> >> Returns all of the macros defined before the source line given by the
>> >> @code{gdb.Symtab_and_line}'s @code{line} attribute which are in still
>> >> effect.
>> >
>> > How is this different from my suggestion above?
>>
>> It explicitly specifies a scope as 'defined before the source line given...'
>
> Which is inaccurate (e.g., what about definitions in other files that
> are included by this one?).  Again, it is not our job to document how
> macros are defined and used, the reader should already know that,
> especially if she is writing a Python script ;-)

at least now I see why you are against adding it...
I think that it's beneath mention that #include causes a macro to be defined.
Anyhow, i don't care enough to argue about it anymore... i'll go with
your original suggestion.

>> >> >> >> +@defmethod Symtab macros
>> >> >> >> +Return all of the macros contained in the symbol table.
>> >> >> >> +@end defmethod
>> >> >> >
>> >> >> > Return what, exactly? only their names? something else?
>> >> >>
>> >> >> i'll try 'Return a list of macro objects for all of the macros
>> >> >> contained in the symbol table.'
>> >> >
>> >> > Based on the example above (which I highly recommend to have in the
>> >> > manual), I'd say "a list of macro objects with their values and
>> >> > include trail".
>> >>
>> >> hrm, except what is above is the output of the string function,
>> >> if you actually print the return value without converting to a string
>> >> it prints something like (<gdb.Macro 0x.......>, <gdb.Macro 0x.....>),
>> >
>> > What are the 0x.... numbers here?
>>
>> The addresses of the python objects.
>
> Then it should be a "list of macro objects specified by their
> addresses".

I don't like this though.... what you're seeing is just a side-effect
of the python print method.
the implementation of a list's str() method to convert to a string
using python's repr()
on it's contents, these are just basic things every python object has,
and will inherit if it doesn't provide a custom implementation.  the
address, and the descriptive string  are things that happen well after
the macros function returns.


(gdb) py print macro_objs
[<gdb.Macro object at 0x7f2c67fc9340>, <gdb.Macro object at 0x7f2c67fc93e8>]
(gdb) py print macro_objs[0]
<gdb.Macro A include_trail=[('/home/ratmice/tests/macro1.c', 7)]>

(gdb) py print repr(macro_objs[0])
<gdb.Macro object at 0x7f2c67fc9340>
(gdb) py print str(macro_objs[0])
<gdb.Macro A include_trail=[('/home/ratmice/tests/macro1.c', 7)]>

(gdb) py help(repr)
repr(...)
    repr(object) -> string

    Return the canonical string representation of the object.
    For most object types, eval(repr(object)) == object.

(gdb) py print help(str)
Help on class str in module __builtin__:

class str(basestring)
 |  str(object) -> string
 |
 |  Return a nice string representation of the object.
 |  If the argument is a string, the return value is the same object.
 |


  reply	other threads:[~2011-08-26 14:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-24 15:11 [PATCH 0/7] [python] API for macros matt rice
2011-08-24 15:11 ` [PATCH 5/7] [python] API for macros: gdb.Objfile symtabs method matt rice
2011-08-30 13:08   ` Phil Muldoon
2011-09-01 23:18     ` Matt Rice
2011-09-02  1:07       ` Paul_Koning
2011-08-30 17:34   ` Tom Tromey
2011-09-02  0:56     ` Matt Rice
2011-08-24 15:11 ` [PATCH 2/7] [python] API for macros: memory management quirks matt rice
2011-08-26 20:40   ` Tom Tromey
2011-08-30 11:47   ` Phil Muldoon
2011-09-01 22:46     ` Matt Rice
2011-08-24 15:11 ` [PATCH 1/7] [python] API for macros: abort or continuing macro iterators matt rice
2011-08-26 20:23   ` Tom Tromey
2011-08-30 11:10   ` Phil Muldoon
2011-09-01 21:48     ` Matt Rice
2011-08-24 15:12 ` [PATCH 6/7] [python] API for macros: Add docs matt rice
2011-08-24 20:10   ` Eli Zaretskii
2011-08-25 12:33     ` Matt Rice
2011-08-25 17:36       ` Eli Zaretskii
2011-08-26  8:04         ` Matt Rice
2011-08-26 10:42           ` Eli Zaretskii
2011-08-26 11:17             ` Matt Rice
2011-08-26 12:08               ` Eli Zaretskii
2011-08-26 14:06                 ` Matt Rice [this message]
2011-08-26 15:05                   ` Eli Zaretskii
2011-08-24 15:12 ` [PATCH 4/7] [python] API for macros: Add methods to get a gdb.Macro matt rice
2011-08-30 13:04   ` Phil Muldoon
2011-08-30 17:41     ` Tom Tromey
2011-08-30 20:28       ` Phil Muldoon
2011-08-30 20:35         ` Phil Muldoon
2011-09-01 23:13           ` Matt Rice
2011-09-02  1:15             ` Paul_Koning
2011-09-02 10:04               ` Paul_Koning
2011-09-02 12:04             ` Phil Muldoon
2011-08-30 20:38         ` Tom Tromey
2011-08-30 20:58           ` Phil Muldoon
2011-08-24 15:12 ` [PATCH 3/7] [python] API for macros: Add gdb.Macro class matt rice
2011-08-30 12:45   ` Phil Muldoon
2011-09-01 22:57     ` Matt Rice
2011-08-24 15:12 ` [PATCH 7/7] [python] API for macros: Add tests matt rice
2011-08-30 13:12   ` Phil Muldoon
2011-08-30 15:54   ` Tom Tromey
2011-08-30  9:44 ` [PATCH 0/7] [python] API for macros Phil Muldoon
2011-09-01 21:33   ` Matt Rice

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=CACTLOFpELPUdFzNNzhxe8xiaibaU-P+tUgARSFC5yKxfGdjcSA@mail.gmail.com \
    --to=ratmice@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.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