From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26454 invoked by alias); 17 Feb 2009 00:07:58 -0000 Received: (qmail 26443 invoked by uid 22791); 17 Feb 2009 00:07:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Feb 2009 00:07:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 739C32A965B; Mon, 16 Feb 2009 19:07:51 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eXqYotmRMyGI; Mon, 16 Feb 2009 19:07:51 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C61E62A9632; Mon, 16 Feb 2009 19:07:50 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 0B5F3E7ACD; Mon, 16 Feb 2009 16:07:46 -0800 (PST) Date: Tue, 17 Feb 2009 00:58:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: tromey@redhat.com, bauerman@br.ibm.com, drow@false.org, pedro@codesourcery.com, gdb-patches@sourceware.org Subject: Re: RFC: add ability to "source" Python code Message-ID: <20090217000746.GA3812@adacore.com> References: <20090211203921.GC13021@adacore.com> <20090211220118.GE13021@adacore.com> <20090212062654.GG13021@adacore.com> <20090213022246.GA5401@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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: 2009-02/txt/msg00338.txt.bz2 > > Add a -p switch to the "source" command that signifies that we're sourcing > > a python script instead of a GDB script. We drop the part where we're > > using the filename extension to guess the file language, thus preserving > > the current behavior. > > Yes. I would even agree to retaining the language guesswork by > file-name extension, provided that (a) there's a user option to turn > that on and off, and (b) that option is off and stays off when Python > is not compiled in. OK, I think I see now why we could not agree in the past, and I feel that it will help in finding an agreeable solution. > Ideally, it should work as it does today, but if that's too hard to > implement, how about simply ignoring -p in that case? That is, let > "source -p foo" behave like "source foo". I personally think it's a mistake to have a different behavior based on how GDB was built, and that causing an error is less confusing. But I'd be OK with the behavior you propose (no error, just the original behavior). Let's see what everyone thinks. I have several issues that I'd like to discuss before we can finalize a proposal: 1. If we have filename-extension detection (controlled by a setting), do we need the "-p" switch at all? If we agreed that it's an acceptable limitation that python scripts in GDB should have a .py extension, then we don't really need the .py switch, do we? This in turn would side-step the question of what to do with -p when python wasn't compiled in. 2. Are others OK with interpreting all files as GDB scripts when python wasn't compiled in, even files with a .py extension? Or maybe, how about changing the semantics of that setting to apply to files that are detected as python (regardless of how the detection is performed): In one case these files are sourced as python script, but on the other, these files are still treated as GDB scripts. When GDB was built with python, then this switch can be used to turn the new feature off, whereas if no python was available, the setting would be stuck to the value where files are sourced as GDB scripts. Now that I've written all this and that it has given me a chance to think this over a little more, I like the idea of falling back to GDB scripts less and less. So much so that I'm wondering whether using a different command than "source" might be better? "pysource" for instance? -- Joel