From: Khoo Yit Phang <khooyp@cs.umd.edu>
To: Tom Tromey <tromey@redhat.com>
Cc: Khoo Yit Phang <khooyp@cs.umd.edu>, gdb-patches@sourceware.org
Subject: Re: Make the "python" command resemble the standard Python interpreter
Date: Wed, 11 Jan 2012 21:30:00 -0000 [thread overview]
Message-ID: <0B6537F9-CB85-4BA1-8838-DAA84A86FF5B@cs.umd.edu> (raw)
In-Reply-To: <m3d3aq55ew.fsf@fleche.redhat.com>
Hi,
On Jan 11, 2012, at 3:51 PM, Tom Tromey wrote:
> Yit> For "python" with arguments, this prints the results of expressions,
> Yit> e.g., "python 1 + 2" will print "3" (previously, it will not print
> Yit> anything).
>
> Did you run the test suite? I'm curious if this caused any failures.
>
> On balance, I'm ok with this idea, since I don't think we make many
> promises about CLI output remaining the same across versions.
I'm still trying to figure out how to run the testsuite and understand the output. Is it possible to just run the Python ones, to not take so long?
> Yit> It also hooks GDB's readline wrappers
> Yit> (command_line_input) to Python so that line editing and history
> Yit> editing works. Additionally, Python's standard readline module is
> Yit> stubbed out because it conflicts with GDB's use of readline.
>
> Can you expand more on how it conflicts?
>
> I think it would be better to make it not conflict somehow.
Both GDB and Python's readline module and methods attempt to configure libreadline, clobbering each others configuration. There doesn't seem to be any support in libreadline for reentrancy. It may be possible to implement a wrapper around readline for Python, but that's another patch, I think.
> Yit> + TRY_CATCH (except, RETURN_MASK_ALL)
> Yit> + {
> Yit> + struct cleanup *cleanup = gdbpy_suspend_sigint_handler ();
> Yit> + p = command_line_input (prompt, 0, "python");
> Yit> + do_cleanups (cleanup);
> Yit> + }
> Yit> +
> Yit> + /* Detect Ctrl-C and treat as KeyboardInterrupt. */
> Yit> + if (except.reason == RETURN_QUIT)
> Yit> + return NULL;
>
> Does this case need the Python exception to be set? If not, I think it
> would be good to expand this comment to explain the situation.
In this case, no, since PyOS_ReadlineFunctionPointer is supposed to return NULL upon Ctrl-C, from what I can gather. That comment is misleading, I'll change it.
> Yit> + m = PyImport_AddModule ("__main__");
> Yit> + if (m == NULL)
> Yit> + error (_("Error while executing Python code."));
>
> You have to do something with the Python exception here.
> Usually we use gdbpy_print_stack, but sometimes other things are
> appropriate.
Okay.
> Yit> + d = PyModule_GetDict (m);
>
> Do we need error checking?
> I didn't look at the API docs.
Nope, "this function never fails".
> Yit> + v = PyRun_StringFlags (command,
> Yit> + from_tty ? Py_single_input : Py_file_input,
> Yit> + d, d, NULL);
> Yit> + if (v == NULL)
> Yit> + {
> Yit> + int interrupt = PyErr_ExceptionMatches (PyExc_KeyboardInterrupt);
> Yit> + PyErr_Print ();
>
> gdbpy_print_stack.
>
> Yit> + if (! interrupt)
> Yit> + error (_("Error while executing Python code."));
>
> Why the special case for interrupts here?
This is because PyErr_Print clears the error, annoyingly enough, so I can't check whether it's a KeyboardInterrupt after PyErr_Print.
Yit
January 11, 2012
next prev parent reply other threads:[~2012-01-11 21:28 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 0:31 Khoo Yit Phang
2012-01-11 4:06 ` Joel Brobecker
2012-01-11 10:43 ` Kevin Pouget
2012-01-11 10:59 ` Joel Brobecker
2012-01-11 16:04 ` Khoo Yit Phang
2012-01-11 17:48 ` Khoo Yit Phang
2012-01-11 18:48 ` Kevin Pouget
2012-01-11 19:04 ` Khoo Yit Phang
2012-01-11 19:11 ` Kevin Pouget
2012-01-11 21:06 ` Khoo Yit Phang
2012-01-11 21:33 ` Tom Tromey
2012-01-11 22:22 ` Khoo Yit Phang
2012-01-20 21:25 ` Tom Tromey
2012-01-20 21:31 ` Tom Tromey
2012-01-22 16:42 ` Khoo Yit Phang
2012-01-11 20:56 ` Tom Tromey
2012-01-11 21:30 ` Khoo Yit Phang [this message]
2012-01-11 21:41 ` Tom Tromey
2012-01-12 3:07 ` Khoo Yit Phang
2012-01-13 14:09 ` Phil Muldoon
2012-01-13 21:39 ` Khoo Yit Phang
2012-01-12 16:48 ` Doug Evans
2012-01-12 16:52 ` Khoo Yit Phang
2012-01-12 16:55 ` Paul_Koning
2012-01-12 17:24 ` Joel Brobecker
2012-01-12 17:30 ` Doug Evans
2012-01-12 17:38 ` Paul_Koning
2012-01-12 17:46 ` Doug Evans
2012-01-12 17:48 ` Doug Evans
2012-01-12 17:51 ` Paul_Koning
2012-01-12 18:06 ` Doug Evans
[not found] ` <CADPb22T1ZmfiGeF9g-QZN6pCTBHwT5ByD9ddX_Dhxe4URvTAhw@mail.gmail.com>
2012-01-12 18:21 ` Khoo Yit Phang
2012-01-12 18:36 ` Doug Evans
2012-01-12 18:48 ` Khoo Yit Phang
2012-01-12 21:22 ` Doug Evans
2012-01-12 18:30 ` Doug Evans
2012-01-21 1:56 ` Tom Tromey
2012-01-22 16:57 ` Khoo Yit Phang
2012-01-23 22:17 ` Doug Evans
2012-01-24 17:36 ` Tom Tromey
2012-01-26 18:28 ` Doug Evans
2012-01-30 6:50 ` Khoo Yit Phang
2012-01-30 17:25 ` Doug Evans
2012-01-30 19:57 ` Doug Evans
2012-02-06 20:08 ` Doug Evans
2012-02-06 20:13 ` Paul_Koning
2012-02-06 20:30 ` Khoo Yit Phang
2012-02-06 20:34 ` Doug Evans
2012-02-06 20:59 ` Paul_Koning
2012-02-06 21:54 ` 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=0B6537F9-CB85-4BA1-8838-DAA84A86FF5B@cs.umd.edu \
--to=khooyp@cs.umd.edu \
--cc=gdb-patches@sourceware.org \
--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