Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
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
Date: Tue, 17 Feb 2009 00:58:00 -0000	[thread overview]
Message-ID: <20090217000746.GA3812@adacore.com> (raw)
In-Reply-To: <utz6ywq8y.fsf@gnu.org>

> > 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


  reply	other threads:[~2009-02-17  0:07 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-08  1:16 Tom Tromey
2009-02-08  1:34 ` Tom Tromey
2009-02-08  4:10   ` Eli Zaretskii
2009-02-08  4:08 ` Eli Zaretskii
2009-02-09  1:53   ` Doug Evans
2009-02-09  4:09     ` Eli Zaretskii
2009-02-10  1:37       ` Tom Tromey
2009-02-10  1:30     ` Tom Tromey
2009-02-09  1:35 ` Doug Evans
2009-02-10  0:00 ` Pedro Alves
2009-02-10  1:29   ` Tom Tromey
2009-02-10  2:36     ` Pedro Alves
2009-02-10  3:48       ` Daniel Jacobowitz
2009-02-10  9:34         ` Eli Zaretskii
2009-02-10 11:58           ` Thiago Jung Bauermann
2009-02-10 17:04             ` Tom Tromey
2009-02-11  2:25               ` Paul Pluzhnikov
2009-02-11  6:09               ` Joel Brobecker
2009-02-11 19:51                 ` Tom Tromey
2009-02-11 20:21                   ` Eli Zaretskii
2009-02-11 20:39                     ` Joel Brobecker
2009-02-11 21:06                       ` Eli Zaretskii
2009-02-11 21:26                         ` Matt Rice
2009-02-11 21:49                           ` Eli Zaretskii
2009-02-11 21:55                             ` Eli Zaretskii
2009-02-11 22:01                         ` Joel Brobecker
2009-02-12  3:59                           ` Eli Zaretskii
2009-02-12  6:27                             ` Joel Brobecker
2009-02-12 20:32                               ` Thiago Jung Bauermann
2009-02-12 22:38                               ` Eli Zaretskii
2009-02-13  8:42                                 ` Joel Brobecker
2009-02-13 15:23                                   ` Eli Zaretskii
2009-02-17  0:58                                     ` Joel Brobecker [this message]
2009-02-17  5:54                                       ` Eli Zaretskii
2009-02-17 20:37                                         ` Tom Tromey
2009-02-19 21:45                                           ` Joel Brobecker
2009-06-01  3:57                                             ` Thiago Jung Bauermann
2009-06-01  5:05                                               ` Paul Pluzhnikov
2009-06-01 15:33                                                 ` Eli Zaretskii
2009-06-01 15:46                                               ` Eli Zaretskii
2009-06-01 17:54                                                 ` Thiago Jung Bauermann
2009-06-10 23:10                                               ` Tom Tromey
2009-06-11 14:19                                                 ` Joel Brobecker
2009-07-03  7:21                                                 ` Paul Pluzhnikov
2010-01-15  7:21                                               ` Joel Brobecker
2010-01-15  9:13                                                 ` Joel Brobecker
2010-01-15 18:03                                                   ` Tom Tromey
2010-01-18  6:33                                                     ` Joel Brobecker
2010-01-18 17:48                                                       ` Eli Zaretskii
2010-01-19 10:32                                                         ` Joel Brobecker
2009-02-11 20:43                     ` Daniel Jacobowitz
2009-02-11 21:08                       ` Eli Zaretskii
2009-02-11 21:16                         ` Daniel Jacobowitz
2009-02-11 21:46                           ` Eli Zaretskii
2009-02-11 20:54                     ` Tom Tromey
2009-02-11 21:11                       ` Eli Zaretskii
2009-02-11 20:46                   ` Joel Brobecker
2009-02-11 20:58                     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090217000746.GA3812@adacore.com \
    --to=brobecker@adacore.com \
    --cc=bauerman@br.ibm.com \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox