From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19935 invoked by alias); 16 Dec 2006 18:45:21 -0000 Received: (qmail 19927 invoked by uid 22791); 16 Dec 2006 18:45:21 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 16 Dec 2006 18:45:14 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1GveWy-0004W0-HX; Sat, 16 Dec 2006 13:45:08 -0500 Date: Sat, 16 Dec 2006 18:45:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: steverod@netapp.com, gdb-patches@sources.redhat.com Subject: Re: [patch] Indirect access to GDB history variables Message-ID: <20061216184508.GA17120@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , steverod@netapp.com, gdb-patches@sources.redhat.com References: <20061215024050.GA8750@linden.netapp.com> <20061216171025.GB14012@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2006-12/txt/msg00211.txt.bz2 On Sat, Dec 16, 2006 at 08:40:02PM +0200, Eli Zaretskii wrote: > > Changing the CLI is touchy because of how weakly specified it is. > > Do we have a substantial body of test cases for CLI in the test suite? > If we do, and if this change doesn't break anything there, I think we > can reasonably expect it to be safe. I'm worried primarily about interactions with the expression parser, which changes for every language we support. I don't know if the test coverage is adequate or not. > > I think that we should take the long-postponed jump to embedding > > scripting languages, rather than adding more complexity to the existing > > CLI. > > If we leave the current CLI available in non-interactive sessions, and Definitely. I don't suggest removing anything here. > if the embedded language will satisfy Steve's needs, I'm for it. But > I fear that agreeing on the language will take time, in which case > postponing this change will be just that. It may be so. My tentative plan was to offer a selection, probably Perl and Python and Guile; once the common infrastructure is in place, it's really not hard to add languages and enable them at configure time. The alternative would be to add only Guile, since that's the language the FSF officially recommends for such things - I don't want to take that alternative, though, since I'm practically useless in Guile. I have implemented Guile embedding, by the way, though never finished it up. Just musing, for the moment. -- Daniel Jacobowitz CodeSourcery