From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23077 invoked by alias); 15 Mar 2009 23:46:59 -0000 Received: (qmail 23069 invoked by uid 22791); 15 Mar 2009 23:46:58 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e24smtp04.br.ibm.com (HELO e24smtp04.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Mar 2009 23:46:52 +0000 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by e24smtp04.br.ibm.com (8.13.1/8.13.1) with ESMTP id n2FNhqPO028787 for ; Sun, 15 Mar 2009 20:43:52 -0300 Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2G0kAFZ3039300 for ; Sun, 15 Mar 2009 21:46:11 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2FNknpw012736 for ; Sun, 15 Mar 2009 20:46:49 -0300 Received: from [9.8.10.213] ([9.8.10.213]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2FNkmNI012730; Sun, 15 Mar 2009 20:46:48 -0300 Subject: Re: [rfc] python API exposing inferior's frame stack. From: Thiago Jung Bauermann To: Eli Zaretskii Cc: gdb-patches@sourceware.org In-Reply-To: References: <1236706351.11106.17.camel@localhost.localdomain> <1237133466.316.16.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Date: Mon, 16 Mar 2009 03:36:00 -0000 Message-Id: <1237160806.8098.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: 2009-03/txt/msg00247.txt.bz2 El dom, 15-03-2009 a las 21:21 +0200, Eli Zaretskii escribió: > > From: Thiago Jung Bauermann > > El mar, 10-03-2009 a las 21:35 +0200, Eli Zaretskii escribió: > > > Is "older" widespread enough to be self-explanatory? > > > > "older" is the name of the Frame method used to get the previous frame > > (where "previous" is the convention used in the GDB source code), so it > > has a good chance of being clear to the user of the Python API. In any > > case, I reworded it to: > > > > "Return an integer representing the reason why it's not possible to find > > frames older (outer) than this." > > I prefer "frames previous to this one". We already use similar > wording in frame_stop_reason_string. I don't like "previous" and "next". They are not clear enough. I think you prefer this only because you're used to its meaning in the GDB source code. If they were clear enough, the following clarification wouldn't be necessary in frame.h: /* Given a FRAME, return the next (more inner, younger) or previous (more outer, older) frame. */ extern struct frame_info *get_prev_frame (struct frame_info *); extern struct frame_info *get_next_frame (struct frame_info *); I explicitly avoided such wording in the Python Frame API, preferring to use "older" and "newer". In the doc strings and documentation, I also use "outer" and "inner", which I still think conforms to be stack chapter in the GDB manual. > > > > +@defmethod Frame older > > > > +Return the frame immediately older (outer) to this frame. > > > > +@end defmethod > > > > + > > > > +@defmethod Frame newer > > > > +Return the frame immetidaely newer (inner) to this frame. > > > > +@end defmethod > > > > > > Suggest to use "higher" or "above" or "towards the outermost frame". > > > Generally, try to use the terminology from the "Examining the Stack" > > > chapter of the manual. > > > > IMHO, "inner" and "outer" are already conforming to the terminology from > > the "Examining the Stack" chapter. It is a bit awkward to use "towards > > the outermost frame" to describe these methods, e.g.: > > > > "Return the next frame in the direction towards the outermost frame." > > > > and > > > > "Return the next frame in the direction towards the innermost frame." > > > > Mmm... Now that I tried, doesn't sound too bad. But still I find my > > original wording more direct and simpler to understand. What do you > > think? > > We use "innermost" in the manual much more than "inner". You can also > use "previous" and "next" if you like that better. Why "innermost" is acceptable but "inner" is not? I don't see why the different treatment. If one can be used, the other should be allowed too, no? > Also note that there's a typo in the quoted fragment ("immetidaely"). Fixed, thanks. -- []'s Thiago Jung Bauermann IBM Linux Technology Center