From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8618 invoked by alias); 26 Aug 2011 14:06:57 -0000 Received: (qmail 8608 invoked by uid 22791); 26 Aug 2011 14:06:55 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gw0-f41.google.com (HELO mail-gw0-f41.google.com) (74.125.83.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Aug 2011 14:06:41 +0000 Received: by gwaa20 with SMTP id a20so3097822gwa.0 for ; Fri, 26 Aug 2011 07:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.116.33 with SMTP id f21mr6979274yhh.45.1314367600639; Fri, 26 Aug 2011 07:06:40 -0700 (PDT) Received: by 10.236.34.193 with HTTP; Fri, 26 Aug 2011 07:06:40 -0700 (PDT) In-Reply-To: <83r548fka3.fsf@gnu.org> References: <1314198654-9008-1-git-send-email-ratmice@gmail.com> <1314198654-9008-7-git-send-email-ratmice@gmail.com> <83k4a2h8qr.fsf@gnu.org> <831uw9gzro.fsf@gnu.org> <83sjoofo80.fsf@gnu.org> <83r548fka3.fsf@gnu.org> Date: Fri, 26 Aug 2011 14:06:00 -0000 Message-ID: Subject: Re: [PATCH 6/7] [python] API for macros: Add docs. From: Matt Rice To: Eli Zaretskii Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00493.txt.bz2 On Fri, Aug 26, 2011 at 5:07 AM, Eli Zaretskii wrote: >> Date: Fri, 26 Aug 2011 04:17:24 -0700 >> From: Matt Rice >> 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. =A0Are you > talking about some specific ambiguity, or in general? =A0If 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. =A0I 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?). =A0Again, 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 define= d. 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 (, ), >> > >> > 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) py print macro_objs[0] (gdb) py print repr(macro_objs[0]) (gdb) py print str(macro_objs[0]) (gdb) py help(repr) repr(...) repr(object) -> string Return the canonical string representation of the object. For most object types, eval(repr(object)) =3D=3D 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. |