From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8207 invoked by alias); 2 Dec 2009 17:46:49 -0000 Received: (qmail 8199 invoked by uid 22791); 2 Dec 2009 17:46:48 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Dec 2009 17:46:44 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 854F126EF01; Wed, 2 Dec 2009 18:46:42 +0100 (CET) Received: from polhem (95.209.141.243.bredband.tre.se [95.209.141.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 4B57526EEE3; Wed, 2 Dec 2009 18:46:41 +0100 (CET) From: "Jakob Engblom" To: Cc: "'Joel Brobecker'" , "'Michael Snyder'" , , "'Hui Zhu'" References: <4B0EF39A.10802@vmware.com> <20091127013738.GL18141@adacore.com> <00b601ca7285$a3ff39f0$ebfdadd0$@com> In-Reply-To: Subject: RE: [RFC] syntax change for "record save" Date: Wed, 02 Dec 2009 17:46:00 -0000 Message-ID: <003a01ca7377$681a58a0$384f09e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-12/txt/msg00016.txt.bz2 > Jakob> So we would do something like this: > simics> save ("file." + $a) > Jakob> (when the first argument to + is a string, the next argument is > Jakob> forced to a string) >=20 > Jakob> I think supporting string generation would solve many more > Jakob> problems easily. >=20 > The problem is that it is not obvious how to integrate this into the > existing gdb CLI. The CLI is not like a normal programming language, > with a regular syntax and a parser. Any regularity is just by > convention; each command is just passed a char* that it parses itself. >=20 > Of course, we could invent something. We could even turn the CLI into a > much more expressive language. I'd rather not, though -- we have Python > for that, and I think it is generally better to just reuse an existing > language than to try to invent a new one. I see. I had believed that the gdb command-line was more general than that. Sorry for my lack of insight. That's why I did not say "we should do this",= just asking if this would work.=20 > Jakob> The save name INDEX to me seems silly, if you are doing this > Jakob> manually, why don't you just type a different name each time? >=20 > Yeah, presumably this is only done via scripting. That's why I think it > is ok if the spelling of the commands is a bit verbose. On the other hand, in a script, can't you do this in two steps? Add a command to build strings into variables, and then use that variable i= n teh command? Gdb> concat $n "foo" $a Gdb> save $n ? Best regards, /jakob _______________________________________________________ Jakob Engblom, PhD, Technical Marketing Manager Virtutech=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Direct: +46= 8 690 07 47=A0=A0=A0 Drottningholmsv=E4gen 22=A0=A0=A0=A0=A0 Mobile: +46 709 242 646=A0=A0 11243 Stockholm=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Web:=A0=A0=A0 www.virtu= tech.com=A0 Sweden ________________________________________________________ =A0=20