| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
In a threads-disabled build, typing Ctrl-C into a raw_input() crashed,
because (essentially) I didn't realise that PY_BEGIN/END_ALLOW_THREADS
actually expanded to nothing under a no-threads build, so if you somehow
NULLed out the threadstate (e.g. by calling PyThread_SaveThread) it would
stay NULLed when you return to Python. Argh!
|
|
|
|
| |
[ 987287 ] Python 2.4a1, interpreter hanging on Keyboard Interrupt
|
|
|
|
| |
isn't always set to an integer value when it's defined.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ 960406 ] unblock signals in threads
although the changes do not correspond exactly to any patch attached to
that report.
Non-main threads no longer have all signals masked.
A different interface to readline is used.
The handling of signals inside calls to PyOS_Readline is now rather
different.
These changes are all a bit scary! Review and cross-platform testing
much appreciated.
|
| |
|
| |
|
| |
|
|
|
|
| |
This gets us closer to consistent Ctrl+C behaviour on NT and Win9x. NT now reliably generates KeyboardInterrupt exceptions for NT when a file IO operation was aborted. Bugfix candidate
|
| |
|
|
|
|
|
|
|
|
| |
Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.
This closes SourceForge patch #101659 and bug #115323.
|
|
|
|
| |
This should match the situation in the 1.6b1 tree.
|
|
|
|
|
|
| |
Work around intrcheck.c's desire to pass 'PyErr_CheckSignals' to
'Py_AddPendingCall' by providing a (static) wrapper function that has the
right number of arguments.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
|
|
|
|
| |
never executed because of a return statement. Sigh.
|
|
|
|
|
| |
held. It releases the lock around the call to the function pointed to by
PyOS_ReadlineFunctionPointer (default PyOS_StdioReadline()).
|
|
|
|
| |
Also cleaned out some CR's left by the VC++ editor.
|
|
|
|
| |
Add Py_input_hook (used by _tkinter and perhaps Gist).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also grandly renamed.
Here's the new interface:
When WITH_READLINE is defined, two functions are defined:
- PyOS_GnuReadline (what used to be my_readline() with WITH_READLINE)
- PyOS_ReadlineInit (for Dave Ascher)
Always, these functions are defined:
- PyOS_StdioReadline (what used to be my_readline() without WITH_READLINE)
- PyOS_Readline (the interface used by tokenizer.c and [raw_]input().
There's a global function pointer PyOS_ReadlineFunctionPointer,
initialized to NULL. When PyOS_Readline finds this to be NULL, it
sets it to either PyOS_GnuReadline or PyOS_StdioReadline depending on
which one makes more sense (i.e. it uses GNU only if it is defined
*and* stdin is indeed a tty device).
An embedding program that has its own wishes can set the function
pointer to a function of its own design. It should take a char*
prompt argument (which may be NULL) and return a string *ending in a
\n character* -- or "" for EOF or NULL for a user interrupt.
--Guido van Rossum (home page: http://www.python.org/~guido/)
|
| |
|
| |
|
|
|
|
|
| |
Set rl_readline_name to python.
Move extern decls to more logical point.
|
| |
|
| |
|
|
|
|
| |
For Dave Ascher's readline extensions.
|
| |
|
| |
|
| |
|
|
|