From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28335 invoked by alias); 14 Feb 2007 18:33:56 -0000 Received: (qmail 28325 invoked by uid 22791); 14 Feb 2007 18:33:55 -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; Wed, 14 Feb 2007 18:33:47 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HHOwn-0002oV-Sr; Wed, 14 Feb 2007 13:33:41 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HHOwm-0003Uy-Ee; Wed, 14 Feb 2007 13:33:40 -0500 Date: Wed, 14 Feb 2007 18:45:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: jimb@codesourcery.com, gdb@sourceware.org Subject: Re: GDB and scripting languages - which Message-ID: <20070214183335.GA12606@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , jimb@codesourcery.com, gdb@sourceware.org References: <20070108222005.GA27451@nevyn.them.org> <20070210203307.GA27502@nevyn.them.org> <20070214155620.GA7098@caradoc.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-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-02/txt/msg00137.txt.bz2 On Wed, Feb 14, 2007 at 07:46:27PM +0200, Eli Zaretskii wrote: > > But in any case those aren't the > > ones I had in mind: I was thinking of things like XML, text > > processing, and high-performance numerics. > > More details would help make this discussion more constructive. How > ``high-performance'' should our numerics be, and why? Do you have any > quantitative criteria? > > As for text processing, what features do you think we need, > specifically? I don't know the answers to these questions. They are things which I think will be useful. We don't have the faintest idea what we will make possible by doing this work, or what users will come up with. That's my goal - enabling entirely new uses. > > Based on this discussion, I think we probably won't convince you that > > Python is the best choice. > > Why do you think so? Based solely on the tone of the discussion, and five years working with this group of people on this mailing list through past discussions with similar tone. I'm looking for something that won't make anyone furious; we rarely manage to make everyone happy, but we routinely manage to find conclusions that no one is too upset with. I apologize if that sounds overly cynical of me. I said at the very top of this thread that I thought bikeshedding over which programming language to use was the worst possible use of our time, and asked followups not to do so. I can't say that I'm surprised by the portion of the followups that were specifically about the choice of language. I think a suitable language that (conservatively) ten times as many people know is clearly more useful than a suitable language that far fewer people know. You mentioned in another message that you considered things like networking and graphics support to be excessive and wasted weight. They are modules completely separate from the interpreter, and would not be part of GDB's "footprint" unless someone wrote scripts which used them. And Lua has similar modules. I see both a socket library and GTK+ bindings for GUI use. Have you used either Lua or Python in other projects? Do you have impressions of them from the script writer's perspective? > I certainly didn't dismiss anyone's arguments as > easily as others dismiss mine. The only real argument in favor of > Python that I heard was that it's widely used and known. That's not a > lot to become convinced, since what I'm suggesting is not some unknown > language either, or something invented just now. Neither are any of the others we've considered. I don't think I can say this any differently than I already have: the order of magnitude more people that work in Python make it more useful, and the existing GDB contributors with Python experience make Python more feasible. I am not dismissing your arguments, but personally I have not found them compelling. I have seen no language features in Lua that make it a better choice than Python. For instance, you made a comment about "complete" programming languages requiring type declarations and memory allocation -- certainly that is not the case in Python, which is a typical scripting language in those respects. (I'm not sure what you meant by "initialization before use". You'll get a catchable exception in Python if you use something before you initialize it, instead of a default empty value as you would in shell scripting.) I do not have any evidence that the extra "weight" of a Python interpreter would be a problem, and I believe (as I said above) that it is a priceless feature. Here is the subset of the Python modules installed on my system which seem clearly useful from GDB. python-ctypes, for interaction with other C support libraries python-gdbm (and others), for managing program trace data stored in databases python-numeric, vector and matrix calculations, e.g. to record and analyze the results of computation in the debuggee. python-stats, similarly. python-xml, for translating data both to and from XML for interaction with other tools And that's just off the top of my head - if we enable some sort of threads or graphics, then custom data browsers might be an interesting option for people who otherwise want to use a text-only debugger. And so forth. -- Daniel Jacobowitz CodeSourcery