From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-70494-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 2739 invoked by alias); 26 Feb 2010 14:56:30 -0000
Received: (qmail 2725 invoked by uid 22791); 26 Feb 2010 14:56:29 -0000
X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 	tests=AWL,BAYES_00,SPF_SOFTFAIL
X-Spam-Check-By: sourceware.org
Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Feb 2010 14:56:23 +0000
Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KYG00500EOY5V00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 26 Feb 2010 16:55:12 +0200 (IST)
Received: from HOME-C4E4A596F7 ([77.126.246.192]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KYG00K5ZERZKWH0@a-mtaout22.012.net.il>; Fri, 26 Feb 2010 16:55:12 +0200 (IST)
Date: Fri, 26 Feb 2010 14:56:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: [python][patch] Fix 11036
In-reply-to: <20100226123749.GA16942@localhost.localdomain>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: tromey@redhat.com, gdb-patches@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83mxywkpwq.fsf@gnu.org>
References: <20100225142823.GA10175@localhost.localdomain> <m31vg9rwqa.fsf@fleche.redhat.com> <20100226123749.GA16942@localhost.localdomain>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2010-02/txt/msg00653.txt.bz2

> Date: Fri, 26 Feb 2010 12:37:50 +0000
> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> I have also updated the comments and the documentation to reflect the
> new decisions.

Thanks.  I have a couple of comments:

> +@defmethod Frame read_var variable @r{[}block@r{]}
> +Return the value of the given variable in this frame.  If the optional
> +block argument is provided, search for the variable from that current
> +block; otherwise start at the frame's current block (which is

Please use @var for the arguments:

  Return the value of @var{variable} in this frame.  If the optional
  argument @var{block} is provided, search for the variable from that
  block; otherwise start at the frame's current block (which is

(note that I also slightly reworded your text).

Okay with these changes.