From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4063 invoked by alias); 8 Jan 2007 22:20:14 -0000 Received: (qmail 4049 invoked by uid 22791); 8 Jan 2007 22:20:13 -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; Mon, 08 Jan 2007 22:20:07 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H42qb-0007NL-GS for gdb@sourceware.org; Mon, 08 Jan 2007 17:20:05 -0500 Date: Mon, 08 Jan 2007 22:20:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: GDB and scripting languages - which Message-ID: <20070108222005.GA27451@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2007-01/txt/msg00126.txt.bz2 First, disclaimer: this particular topic is a classic source of bikeshedding. I'd like to avoid a prolonged discussion of scripting language pros and cons on this list. So, please, limit on-list followups to the question of single versus multiple bindings and the use of guile, OK? If you want to rant at me about my heretic selection of languages, feel free, but please don't reply to the list in that case. Basically, my question is whether we should support one language or many, and if only one, which. The GNU coding standards have this to say: The standard extensibility interpreter for GNU software is GUILE (http://www.gnu.org/software/guile/), which implements the language Scheme (an especially clean and simple dialect of Lisp). We don't reject programs written in other scripting languages such as Perl and Python, but using GUILE is very important for the overall consistency of the GNU system. So the obvious thing to do would be to have just one and have it be guile. I'm not sure how much consistency that really adds - I could only find a handful of GNU programs embedding guile. And it presents another problem for me: I'm a pretty much incompetent Scheme programmer. I'm a lot more inspired to add a scripting language that I can really use. Python would be my first choice, today. Mostly this is because I know it. However (comparing to guile only here), my impression is that the user community and library of supporting modules is much stronger than guile's. For instance, while this isn't the most meaningful statistic, there are eighteen times as many python-related packages in Debian as guile-related. A whole lot of those are reusable modules. The advantage of adding multiple language bindings is that users will have the choice of whichever is more familiar for them; I know that various people have locally added guile, python, and perl in the past. The disadvantage, of course, is the required amount of code (maintenance, testing). And if GDB comes with a library of useful routines to load from user scripts, they'll be different for each language. And if programs ship their own handy scripts for developers of those programs to use, they'll be in an assortment of different languages. So the short version is that if I were making the decision, for my own benefit and independent of the GNU project and GDB's users, I'd add only Python support. For GDB's place in the GNU project, we should probably have guile. And I feel like the user convenience of a selection of languages will outweigh the extra work of multiple language bindings. Accordingly, I am inclined to use multiple bindings, to include at least Python and GUILE. My current design relies on GDB/MI for most control of GDB; I might put the MI parser on the C side of the interface to allow MI results to be easily converted to lists / tuples / et cetera in each supported language, but other than that it would be a fairly thin interface on top of MI. (MI isn't the most convenient interface for scripting - I'm still trying to figure out how it will interact with GDB's value objects, but it will probably build on top of varobj to do so. The symmetry is nice; what you can do in scripts you ought to be able to do in a GUI front end to GDB too so any MI extensions useful for one are likely useful to the other. However, this is the subject of a later discussion, not this one.) I'd really appreciate hearing what others think. -- Daniel Jacobowitz CodeSourcery