From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-36369-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 27269 invoked by alias); 30 Nov 2009 18:57:32 -0000
Received: (qmail 27260 invoked by uid 22791); 30 Nov 2009 18:57:31 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Nov 2009 18:57:28 +0000
Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) 	by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 0655213C9C; 	Mon, 30 Nov 2009 10:57:27 -0800 (PST)
Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) 	by jupiter.vmware.com (Postfix) with ESMTP id EDD1DDC054; 	Mon, 30 Nov 2009 10:57:26 -0800 (PST)
Message-ID: <4B141469.5030402@vmware.com>
Date: Mon, 30 Nov 2009 20:25:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20090624)
MIME-Version: 1.0
To: Joel Brobecker <brobecker@adacore.com>
CC: Hui Zhu <teawater@gmail.com>,   "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: [RFC] Let "gcore" command accept a suffix argument
References: <4B11DA3C.3000203@vmware.com> <daef60380911300437o4c616eb2v5ad7bfe99bd3c5e9@mail.gmail.com> <20091130162246.GE4034@adacore.com> <4B141157.3070709@vmware.com> <20091130185341.GI4034@adacore.com>
In-Reply-To: <20091130185341.GI4034@adacore.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2009-11/txt/msg00225.txt.bz2

Joel Brobecker wrote:
>> I don't like the above suggestion, but I assume you are
>> talking about the original idea.
> 
> Personally, I think that we should look at python. As far as I could
> tell, I was already able to do everything with the current python
> support, even if a little convoluted. We can also start working on
> a python layer for process record too.  That would be my prefered
> approach.
> 
> Otherwise, what do you think of Tom's suggestion (new "eval" command)?

Well I wouldn't want to be stuck implementing it...
I don't know python!   ;-)

Would it be able to include the incr? "eval gcore foo.$a++"?