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.
|
next prev parent 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