From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 618 invoked by alias); 14 Feb 2007 19:45:20 -0000 Received: (qmail 577 invoked by uid 22791); 14 Feb 2007 19:45:18 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Feb 2007 19:45:09 +0000 Received: (qmail 16545 invoked from network); 14 Feb 2007 19:45:07 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Feb 2007 19:45:07 -0000 To: Eli Zaretskii Cc: gdb@sourceware.org Subject: Re: GDB and scripting languages - which References: <20070108222005.GA27451@nevyn.them.org> <20070210203307.GA27502@nevyn.them.org> From: Jim Blandy Date: Wed, 14 Feb 2007 20:10:00 -0000 In-Reply-To: (Eli Zaretskii's message of "Wed, 14 Feb 2007 17:41:06 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00141.txt.bz2 Eli Zaretskii writes: >> When I search the manual at http://www.lua.org/manual/5.1/, I don't >> see any references to 'fallbacks'. The Lua HISTORY file mentions >> them, but they seem to be an operator overloading mechanism, not an >> exception-handling mechanism. Where can I find documentation on >> these? > > Here: > > http://www.lua.org/spe.html > > I don't know why this feature isn't mentioned in the current manual, > maybe it was renamed. The 'fallbacks' described in that paper aren't exceptions; they're a mechanism for customizing the built-in operations of Lua, to adapt it to new applications. I'm using the term "exception" as it's used in ML, Scheme, C++, Java, Python, Ruby, PHP, and probably others. In fact, in the introduction, after explaining that Lua is an extension language, they say: * extension languages are not for writing large pieces of software, with hundreds of thousands lines. Therefore, mechanisms for supporting programming-in-the large, like static type checking, information hiding, and exception handling, are not essential > Python is a full-fledged programming language, not a language created > for extending other programs. Do you really think we need networking, > graphics, and GUI in GDB scripts? That sounds like an awful overhead. As others have said, those are examples of the kind of facilities that are available off-the-shelf to Python users; but as loadable modules, they wouldn't be present in a Python-extended GDB unless a script author did use them. I think the quality of the body of libraries available for use off-the-shelf with an extension language is an important measure. For example, who would have thought XML would matter to a debugger until Daniel started using it to describe target registers? And at CSL we've got other stuff in the pipeline that would have been a pain without XML. In the broadest terms, debugging is about watching your programs run. There are so many possible things people might want to do with that. To address the three things I mentioned: - Some kind of remote monitoring would need network support. - Debugging performance problems would benefit from graphing. - GUI facilities could broaden the audience of almost anything. The lesson of GNU Emacs is that you just don't know what people are going to do with something. People were shocked to see news and mail readers, development environments, symbolic calculators, and the like implemented in Emacs. Choosing an extension language for GDB with a rich set of libraries would be a hugely wonderful thing. > As for familiarity with it, the GDB scripting language we have now is > even less widespread than Lua. Definitely true. Lua would be an improvement over what we have now. But is it the best choice we could make?