From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13457 invoked by alias); 15 Jan 2007 18:29:41 -0000 Received: (qmail 13448 invoked by uid 22791); 15 Jan 2007 18:29:40 -0000 X-Spam-Check-By: sourceware.org Received: from mail.zeugmasystems.com (HELO zeugmasystems.com) (192.139.122.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Jan 2007 18:29:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GDB and scripting languages - which Date: Mon, 15 Jan 2007 18:29:00 -0000 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D58107B@exchange.ZeugmaSystems.local> From: "Kaz Kylheku" To: "Jim Blandy" , 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/msg00249.txt.bz2 Jim Blandy wrote: > I would prefer that GDB use a single extension language, and that that > language be Python.=20 I think it would be best to have a libgdb.so shared library with a well-defined API. Then people can write their own bindings to call it from whatever programming environment suits them. I think Python is a retarded pile of crap and won't use it; moreover, I don't care to discuss the reasons why. But I don't want to get in your way of using it if you want, because that would be bad engineering. > talents in Guile. But Guile has had more than enough time to attract > uses and users on its own merits, and compared to Python, it hasn't > worked out. It's time to cut our losses.) Guile is not even particularly attractive people who are already Scheme programmers. For serious Scheme work, there are better implementations out there.=20 > Maintaining such libraries for multiple extension languages would be > wasted work, and python is good enough. It would be fine if a binding library for a just a single language were maintained, but if there was a separation between that and a clean API, rather than too much reliance on the internals. For instance, it would not be very nice if the API relied some internal data structures of a particular interpreter, and used that representation for passing values back and forth.