Terry J. Reedy added the comment:
Thank you for testing this. I am hoping that you left the patch applied for
testing in routine use. I an now reviewing the code so I can understand it
well enough to apply, and to see what non-debug functions might possibly be
affected, and need testing
sanad added the comment:
I have reviewed the patch(http://bugs.python.org/msg172439) submitted in issue
#15348 and works very well for solving this particular issue too. Although I
have checked it only on Linux but it works arguably fine.
--
nosy: +sanad
Changes by irdb electro@gmail.com:
--
nosy: +irdb
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
___
Python-bugs-list mailing list
Terry J. Reedy added the comment:
#24455 is probably related.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
___
Python-bugs-list
Terry J. Reedy added the comment:
This seems like an extension of #15348, but I will leave it open for now. The
additional details may be useful.
--
nosy: +terry.reedy
versions: +Python 2.7, Python 3.5, Python 3.6
___
Python tracker
New submission from irdb:
# Open a module using IDLE
# Run the module (Press F5)
# Activate the debugger ([DEBUG ON])
# Set a breakpoint in the module
# Run the module again
# Run the module for the third time
# Hit the Quit button in Debug Control window (twice, as the first click
appears
Changes by irdb electro@gmail.com:
--
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24455
___
___
Python-bugs-list mailing list
Terry J. Reedy added the comment:
Previous issue has a patch that needs independent review.
--
resolution: - duplicate
stage: - resolved
status: open - closed
superseder: - IDLE - shell becomes unresponsive if debugger windows is closed
while active
New submission from ppperry:
[DEBUG ON]
some_code
(debugger closed before pressing any buttons)
[DEBUG OFF]
more_code
(no response)
--
components: IDLE
messages: 244707
nosy: kbk, ppperry, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Idle hangs when
Xavier de Gaye added the comment:
I can reproduce the problem on python 3.5 with test3.py as:
def foo():
foo = 7789
bar = 7788
$ python
Python 3.5.0a4+ (default:8bac00eadfda, May 6 2015, 17:40:12)
[GCC 4.9.2 20150304 (prerelease)] on linux
Type help, copyright, credits or license for
self._prune_breaks(bp.file, bp.line)
File C:\Python27\lib\bdb.py, line 268, in _prune_breaks
self.breaks[filename].remove(lineno)
ValueError: list.remove(x): x not in list
Running the same code without first defining a breakpoint (in the second
debugger instance) raises KeyError: [path
be generally useful. The selected block
could then be copied. Deletion is not currently possible, but I might like to
change that too.
The debugger is an exception to Idle's normal ignorance of user code global and
local namespaces. The debugger window (which needs upgrading) can display
names
Changes by Terry J. Reedy tjre...@udel.edu:
--
title: Add a copy vale to clipboard option to the debugger - Add a copy
value to clipboard option to the debugger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24090
New submission from Boris:
When attempting to save a file containing an Aring; character with the
debugger open, IDLE freezes with/or without partially opening the warning
window. (Mac OS X 10.9.5, IDLE running python 2.7.5). Reproducible steps:
- Create and save file with one line:
1+1
add 3b) Close the debugger,
there is still a problem. So 'activating' the debugger does something that is
not undone by closing the debugger and that obstructs closing.
--
nosy: +sahutd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Terry J. Reedy added the comment:
#21339, closed as a duplicate of this, has a traceback might be helpful.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15347
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
___
On Thursday, September 11, 2014 10:15:57 PM UTC-7, Viet Nguyen wrote:
Can anyone give me hint or reason why same command behaves differently in
debugger mode from interactive mode:
From interactive mode:
import os
p = os.popen('date')
p.read()
'Thu Sep 11 11:18:07 PDT
Can anyone give me hint or reason why same command behaves differently in
debugger mode from interactive mode:
From interactive mode:
import os
p = os.popen('date')
p.read()
'Thu Sep 11 11:18:07 PDT 2014\n'
But from debugger mode in a script:
import os
(Pdb) p = os.popen('date
On Fri, Sep 12, 2014 at 3:15 PM, Viet Nguyen
vhnguy...@yahoo.com.dmarc.invalid wrote:
But from debugger mode in a script:
import os
(Pdb) p = os.popen('date')
*** SyntaxError: SyntaxError('invalid syntax', ('string', 1, 1, =
os.popen('date')))
Can anyone help me why there is syntax here
desirable and
would not mind if the class were moved from PyShell.py to rpc.py. I think it
fits there better anyway.
I wrote a 'rpc.py', not in idlelib, and tried to debug it. Debugger silently
ran the whole module and quit, as if I had hit [run] with no breakpoints. This,
I think, *is* a bug
Terry J. Reedy added the comment:
FWIW: stepping into an import statement now steps into frozen
importlib._bootstrap and for many more statements than the three for
print/write. I am already aware that the debugger 'doc' needs to be expanded
from
Debugger (toggle)
This feature
Terry J. Reedy added the comment:
With more debugger use experience, I decided that there are many possible small
improvements that would make it easier to use for beginners.
0. The window strikes me as overall 'blah', if not ugly. The difference between
inactive and active could be brighter
Terry J. Reedy added the comment:
6. The offset with my current screen is two pixels, as determined by
___='__' and not as bad as I remember it. Probably due to padding
differences.
7. The font and fontsize of Debug Control are fixed, as with dialogs.
--
Changes by Mark Lawrence breamore...@yahoo.co.uk:
--
versions: +Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14111
___
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17942
___
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15335
___
___
Mark Lawrence added the comment:
A pythonw.exe process is left running if I try this with 3.4.1 on Windows 7.
--
nosy: +BreamoreBoy, terry.reedy
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
Changes by Terry J. Reedy tjre...@udel.edu:
--
stage: - test needed
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20119
___
Changes by Ned Deily n...@acm.org:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20119
___
___
Python-bugs-list mailing
New submission from nlev...@gmail.com:
The continue command in perl's debugger (perl -d) supports setting a
one-time-only breakpoint. IMHO this is incredibly useful. For instance when
stepping through a program, if you get stuck in a loop, you can move past it
with a simple one line command c
Hi
Is any one aware of free ipython debugger tool.How good is this tool for a
beginner to use like ,placing breakpoints,checking variables ,call stack
(function flow) etc.I don't like to use python PDB .
I have heard about wingware ,pycharm which are licensed versions.Used
wingware trail
El 06/09/2013, a las 08:14, chandan kumar chandan_...@yahoo.co.in escribió:
Hi
Is any one aware of free ipython debugger tool.How good is this tool for a
beginner to use like ,placing breakpoints,checking variables ,call stack
(function flow) etc.I don't like to use python PDB .
I
On Fri, Sep 6, 2013 at 3:14 AM, chandan kumar chandan_...@yahoo.co.inwrote:
Hi
Is any one aware of free ipython debugger tool.How good is this tool for
a beginner to use like ,placing breakpoints,checking variables ,call stack
(function flow) etc.I don't like to use python PDB .
I have
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14111
___
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15335
___
___
Ronald Oussoren added the comment:
The problem appears to be gone in current releases (at least on OSX 10.8 with
Tk 8.5) and I therefore propose to close the issue.
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
Ned Deily added the comment:
Undoubtedly, it was a bug in an earlier version of Aqua Tk; it doesn't appear
to occur with current Tk's.
--
resolution: accepted - out of date
stage: test needed - committed/rejected
status: open - closed
___
Python
Eric Promislow added the comment:
I found a workaround in our debugger code, so you can lower the priority on
this, or even mark it Wontfix, although I still
think the frame stack is getting messed up.
One thing about our debugger, it essentially runs all the Python code in a big
exec
Benjamin Peterson added the comment:
If you ever find a Python bug, feel free to reopen.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
New submission from Eric Promislow:
While much of Komodo's source code has been released under MIT/GPL/LGPL, the
Python debugger hasn't, so I can't post it here. We can work out an
arrangement later, although it might not be necessary once I describe
the problem:
Komodo's Python debugger
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +georg.brandl, ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
___
___
Benjamin Peterson added the comment:
Since this seems to be some sort of interaction between Komodo's code and
Python (it works for me with vanilla Python 3), it's going to be hard to debug
without seeing what this other thing is doing.
--
nosy: +benjamin.peterson
Eric Promislow added the comment:
I'm running it inside gdb to see if I can figure it out.
I don't see a way of isolating this from the whole product.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
New submission from Terry J. Reedy:
The IDLE debugger has subwindows to display name-object bindings for locals and
(optionally) globals. They have a gray background. Text is black, object
strings get a white background box. The issue is that the white box and text
for each name is slightly
Changes by Roger Serwy roger.se...@gmail.com:
--
assignee: - roger.serwy
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
anatoly techtonik added the comment:
A minimal example of debugger is needed, with the explanation how frame.f_trace
is used by debuggers.
--
versions: +Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: -serhiy.storchaka
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15335
___
pydbgr is a somewhat large Python debugger modelled on the gdb command set.
(Yes, I know this name is really horrible).
I am pleased (or is it relieved?) to release a version of pydbr that has a
couple of features I have in other debuggers I've written, namely:
1. Terminal output is now syntax
What's a good debugger for CPython 3.2? I'd prefer to use it on Linux Mint
13, and I'd be happy with something based on X11 or curses.
I tried winpdb, but it was cranky that Linux didn't have a spawn callable.
Why they didn't use the portable subprocess module escapes me.
I also tried ddd
On Fri, Oct 19, 2012 at 9:26 AM, Dan Stromberg drsali...@gmail.com wrote:
What's a good debugger for CPython 3.2? I'd prefer to use it on Linux
Mint 13, and I'd be happy with something based on X11 or curses.
I tried winpdb, but it was cranky that Linux didn't have a spawn
callable. Why
Roger Serwy added the comment:
Attached is a patch against 3.4 to solve the issue.
The debugger was originally written for running IDLE without a subprocess. As a
result, calls to idb.run() from Debugger.py would block until completed. If
.interacting == 1 then clicking X would not close
Roger Serwy added the comment:
While trying to address #15347, I discovered one too many corner cases where
the debugger breaks IDLE. The stable_idle_debugger.diff against 3.4 contains
necessary changes to make IDLE more reliable while debugging. Since the IDLE
debugger is not documented
jimbo1qaz added the comment:
Is it possible to make the X button quit the debugger if enabled?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
Roger Serwy added the comment:
Clicking X while the debugger is enabled, but not actively debugging a
program, will close the debugger window.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
jimbo1qaz added the comment:
What's the intended behavior? stop debugging and quit the program? stop
debugging and continue freerunning? I'm using 3.3, can you make the patch stop
debugging the active running program when you click the X?
--
___
Roger Serwy added the comment:
If the debugger is active, then clicking X will flash the Quit button. You
must click the quit button first before closing the debugger window.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
jimbo1qaz added the comment:
Then frigging change it!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
___
Python-bugs-list mailing list
Roger Serwy added the comment:
Closing the active debugger with X creates a problem with references and
callbacks. I encountered too many corner cases where I could not implement that
behavior simply.
--
___
Python tracker rep...@bugs.python.org
Roger Serwy added the comment:
But of course, you are more than welcomed to try to submit a patch yourself.
Just make sure that those corner cases I described earlier are handled
reasonable when running IDLE with and without a subprocess.
--
___
Terry J. Reedy added the comment:
I have never used the debugger, but I verified the bug. While something was
'hung', the debugger would not restart because something was 'busy'. I also
verified that clicking [quit] first and then [x] works. I will try to test the
second patch sometime
New submission from jimbo1qaz:
Open a Python file with IDLE and F5 it. Turn on debugger ([DEBUG ON]), F5 again
([DEBUG ON]), and close the debugger ([DEBUG OFF]). The shell is now completely
locked and must be closed (with a 'The program is still running, want to kill
it?' message
jimbo1qaz added the comment:
I have confirmed that this happens on both 3.2 and .3, and it also happens when
you close any active debug window.
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16159
.
--
nosy: +serwy
resolution: - duplicate
status: open - closed
superseder: - IDLE - shell becomes unresponsive if debugger windows is closed
while active.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16159
Changes by jimbo1qaz jimmyli1...@gmail.com:
--
nosy: +jimbo1qaz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
___
Python-bugs-list
Roger Serwy roger.se...@gmail.com added the comment:
I suggest to add a decorator @Debugger.internal for all methods that the
debugger should not step into. It should set a function attribute that the
debugger then checks for.
The decorator idea may work. I'll need to see how to make
New submission from Roger Serwy roger.se...@gmail.com:
IDLE fails to close if the debugger was active.
Steps to reproduce:
1) Start IDLE with only a shell.
2) Enable debugger.
3) Press enter in the shell. (Causes debugger to activate)
4) Close the shell window. (File-Exit or click X)
5) Click
New submission from Roger Serwy roger.se...@gmail.com:
The IDLE shell does not respond to commands if the debugger window is closed by
clicking X. This is due to PyShell's executing flag not being reset.
Steps to reproduce:
1) Start IDLE with a shell.
2) Enable debugger.
3) Press enter
Changes by Roger Serwy roger.se...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15348
___
___
Python-bugs-list
New submission from Roger Serwy roger.se...@gmail.com:
The IDLE debugger steps through the internals of _RPCFile.
To reproduce this bug, create a new .py file with a few print statements,
enable the debugger, and then run the file. Stepping through the print
statement enters into _RPCFile
Roger Serwy roger.se...@gmail.com added the comment:
Debugger.py has a method in_rpc_code which ultimately prevents stepping
though code from rpc.py. (Presently an external file named rpc.py can not be
debugged using IDLE.)
Adding run.py to the check would prevent run.py from being stepped,
Martin v. Löwis mar...@v.loewis.de added the comment:
I suggest to add a decorator @Debugger.internal for all methods that the
debugger should not step into. It should set a function attribute that the
debugger then checks for.
OTOH, I fail to see the problem. Stepping through the standard
of `python -m trace --trace filename.py`, but with PDB
and play/pause buttons controlled from external script.
--
title: pdb doc: Add link to source - pdb doc: Explain how to extend debugger
instead of sending readers to the source
___
Python tracker
From: MRAB pyt...@mrabarnett.plus.com
To: python-list@python.org
Cc:
Date: Sun, 25 Mar 2012 22:14:28 +0100
Subject: Re: bdb.Bdb (Debugger Base Class) / unittest Interaction
On 25/03/2012 21:42, Ami Tavory wrote:
Hello,
I'm having some difficulties with the interaction between bdb.Bdb
Hello,
I'm having some difficulties with the interaction between bdb.Bdb and
scripts which contain unittest. Following are two simplified scenarios of a
GUI debugger Gedit plugin I'm writing based on bdb.Bdb, and a script that
is being debugged by it.
--Scenario A--
The script being
On 25/03/2012 21:42, Ami Tavory wrote:
Hello,
I'm having some difficulties with the interaction between bdb.Bdb and
scripts which contain unittest. Following are two simplified scenarios
of a GUI debugger Gedit plugin I'm writing based on bdb.Bdb, and a
script that is being debugged
29.02.2012 12:43, schrieb Shambhu Rajak:
I want building GNU debugger for mingw.
Doesn't mingw come with GDB or at least have a GDB package? However,
this has nothing to do with Python.
Need the GDB to support python How should I go about it?
You don't need GDB in order to support python, which has
Roger Serwy roger.se...@gmail.com added the comment:
I can confirm the issue Larry's raises. Attached is a patch against 2.7 to
enable Ctrl+C interrupts for the debugger. The patch opens up the possibility
of making Go a toggle button, but that would require some more plumbing (not
included
New submission from Larry A. Taylor larry.tay...@bankofamerica.com:
The attached script runs a long processing loop.
Start it in IDLE. Open the script and run it.
Press control-C. Result: message, KeyboardInterrupt with traceback message.
In shell window, turn on Debugger. Run the script
Vinay Sajip wrote:
On Jan 24, 2:52 pm, Rob Richardson rdrichard...@rad-con.com wrote:
I use PythonWin to debug the Python scripts we write. Our scripts often use
the log2pyloggingpackage. When running the scripts inside the debugger, we
seem to get oneloggingobject for every time we run
On 7/02/2012 9:48 PM, Jean-Michel Pichavant wrote:
Vinay Sajip wrote:
On Jan 24, 2:52 pm, Rob Richardson rdrichard...@rad-con.com wrote:
I use PythonWin to debug the Python scripts we write. Our scripts
often use the log2pyloggingpackage. When running the scripts inside
the debugger, we seem
On Jan 24, 2:52 pm, Rob Richardson rdrichard...@rad-con.com wrote:
I use PythonWin to debug the Python scripts we write. Our scripts often use
the log2pyloggingpackage. When running the scripts inside the debugger, we
seem to get oneloggingobject for every time we run the script
I use PythonWin to debug the Python scripts we write. Our scripts often use
the log2py logging package. When running the scripts inside the debugger, we
seem to get one logging object for every time we run the script. The result is
that after running the script five times, the log file
FYI
Just released Qdb, a small simple remote client/server debugger
based on Bdb (Pdb style), wich could be used from a remote terminal to
any server (and in the near future, with a nice visual IDE):
http://code.google.com/p/rad2py/wiki/QdbRemotePythonDebugger
It uses
Roundup Robot devnull@devnull added the comment:
New changeset 3d9800fcce7f by Brian Curtin in branch 'default':
Implement #11832. Add an option to start regrtest and wait for input
http://hg.python.org/cpython/rev/3d9800fcce7f
--
nosy: +python-dev
Changes by Brian Curtin br...@python.org:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11832
___
Georg Brandl ge...@python.org added the comment:
I can't judge if the functionality is needed, but I don't think the option
should be called attach if all it does is input() somewhere...
--
nosy: +georg.brandl
___
Python tracker
Brian Curtin br...@python.org added the comment:
True. In the end all it does is wait for input not specific to attaching
debuggers. How about ``--wait``?
I'm used to this functionality being `-x` in another app, so we're iteratively
getting better :)
--
New submission from Brian Curtin br...@python.org:
Patch to add -a/--attach option to Lib/test/regrtest.py to pause before
beginning test runs. This would allow a user to attach Visual Studio or some
other debugger. Very simply, this option just blocks waiting for a keystroke
during argument
In article
f710b476-ca92-414b-865b-feac70120...@r31g2000prg.googlegroups.com,
Roger Davis r...@hawaii.edu wrote:
Thanks for that info, Ned, I can now get the sys.argv[] list I need,
that's a big help! However, is there any other way to set a breakpoint
in idle that will work on Mac OS X,
On Oct 23, 7:29 am, Roger Davis r...@hawaii.edu wrote:
snip
Are there any Python debuggers with a decent GUI out there at all that
will work on a Mac with the following features: (i) ability to pass in
a sys.srgv[] list that the program would otherwise see without the
debugger, (ii) display
OK. You can set a
breakpoint, meaning that you can click on the source line and the
little stop sign icon pops up right there as expected, but when you
run the code the debugger just blows right by it like it's not even
there. Does anyone out there have a fix for this? It sounds like ddd
Python
Hi, I have some questions about the IDLE debugger. I am using the
2.6.6 bundle downloaded from python.org.
First, how do I debug a Python program that requires command-line
args? I usually run it with a command like
% test.py arg1 arg2 arg3
There seems to be practically no detailed IDLE
In article
04a3c943-5aee-4248-9cb3-60ea42410...@j4g2000prm.googlegroups.com,
Roger Davis r...@hawaii.edu wrote:
Hi, I have some questions about the IDLE debugger. I am using the
2.6.6 bundle downloaded from python.org.
First, how do I debug a Python program that requires command-line
args
Does this describe the problem you are having?
http://bugs.python.org/issue5294
--
http://mail.python.org/mailman/listinfo/python-list
On 09/16/10 03:38, Ed Greenberg wrote:
I'm pretty new to Python, but I am really enjoying it as an alternative
to Perl and PHP.
When I run the debugger [import pdb; pdb.set_trace()] and then do next
and step, and evaluate variables, etc, when I hit 'c' for continue, we
go to the end, just
I'm pretty new to Python, but I am really enjoying it as an alternative
to Perl and PHP.
When I run the debugger [import pdb; pdb.set_trace()] and then do next
and step, and evaluate variables, etc, when I hit 'c' for continue, we
go to the end, just fine.
As soon as I set a breakpoint down
On Wednesday 15 September 2010, it occurred to Ed Greenberg to exclaim:
I'm pretty new to Python, but I am really enjoying it as an alternative
to Perl and PHP.
When I run the debugger [import pdb; pdb.set_trace()] and then do next
and step, and evaluate variables, etc, when I hit 'c
On 09/15/2010 02:04 PM, Thomas Jollans wrote:
On Wednesday 15 September 2010, it occurred to Ed Greenberg to exclaim:
I'm pretty new to Python, but I am really enjoying it as an alternative
to Perl and PHP.
When I run the debugger [import pdb; pdb.set_trace()] and then do next
and step
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Is this still an issue with later versions of Python and/or OSX?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1512124
201 - 300 of 485 matches
Mail list logo
