You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(7) |
Nov
|
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: R. B. <ro...@pa...> - 2008-05-30 13:37:03
|
Some miscellaneous comments regarding the release... The ability to shell to python (or ipython) is a little bit experimental. Much more work could be done with regards to even better Emacs interaction by culling from more recent work done in ruby-debug. Thanks to all that have helped for the release. >From the NEWS file: * Show parameters on call * Some doc fixes. * add ipython and python commands to go into an ipython or a python shell * add "save" command to save the current breakpoints and/or most settings to a file. (Suggested at a NYC Python group meeting.) * add set/show "deftrace" to allow stopping at a def (method creation) statement. * pseudo gdb-like "annotate" set/show commands and option. * Better emacs interactivion via above annotate * bug when "info local" is run inside a "with" statement Fixes for last three items based patches by Alberto Griggio |
From: R. B. <ro...@pa...> - 2008-05-21 11:13:09
|
I'm planning on the 1.23 release around May 30th. If you can please try out what's in CVS. I've put an interim tar at http://bashdb.sf.net/pydb-1.23cvs.tar.gz * Show parameters on call * Some doc fixes. * add ipython and python command to go into an ipython or python shell * add "save" command to save the current breakpoints and/or most settings to a file. (Suggested at a NYC Python group meeting) * add set/show "deftrace" to allow stopping at a def (method creation) statement. * pseudo gdb-like "annotate" set/show commands and option. * Better emacs interactivion via above annotate * bug when "info local" is run inside a "with" statement Fixes for last three items based patches by Alberto Griggio |
From: R. B. <ro...@pa...> - 2007-12-11 12:20:03
|
Anders Lindgren and I (but mostly Anders) has been revamping debugging support via GNU Emacs along the lines of the newer gdb debugging in Emacs 22 (gdb-ui.el). For each debug session there are several internal buffers which are constantly updated and contain information about the current state. For example a buffer contains stack information, another the breakpoint information, another display expressions, and so on. These are called "secondary buffers". Because screen real-estate is limited, some of these buffers may be visable in a frame and some not. There are commands to switch to these buffers moving to the visible frame if the buffer is visable, or replacing the secondary buffer that the command was issued from with the desired secondary buffer. The question has come up regarding key bindings and this is where I'd like to solicit comments. In various IDE's like Eclipse, netbeans or Visual Studio, the function key (e.g F5) issue debugger commands. There can be variable to indicate which flavor of keybindings one wants. Some secondary buffers may have specific commands applicable. Right now however there are very few of these, and many of these could be construed applicable even if you aren't in that buffer. For example, one might want frame-moving commands like "up" to be conveniently available even outside the stack buffer. One proposal is to have the capital letter move between secondary buffers as mentioned above (jump to if visible or replace a secondary if not). SPACE step (edebug compatible) < up (Gud uses this and Emacs uses M-< for beginning of buffer) > down (Gud uses this and Emacs uses M-> for beginning of buffer) ? help B goto/display breakpoints buffer C goto/display command buffer D goto/display display O goto/display program output S goto/display source window T goto/display stack-buffer (Perl uses T for stack trace) V goto/display variables buffer b set breakpoint (edebug compatible) c continue (edebug compatible) d remove break f finish n next (edebug compatible) p print q quit (edebug compatible) r restart s step u unset breakpoint (edebug compatible) x temporary breakpoint (edebug compatible) Buffer specific commands Stack buffer return: set frame at this position variables buffer return: edit the variable's value breakpoints: return toggle breakpoint (enable/disable it) |
From: R. B. <ro...@pa...> - 2007-11-29 11:26:40
|
Recently an annotation mode was added in pydb and other similar debuggers - in particular the one for Ruby called ruby-debug. One of the pieces of information that is "annotated" is the local variables. In GNU Emacs, each piece of annotated information is put in its own buffer. It was felt by a ruby-debug user that it would be more helpful if in addition to showing local variables, instance variables (of @self) were also shown. In Ruby, instance variables start with @ while local variables don't; so they are visually distinct. Likewise class variables start with @@ and constants start with a capital letter. Currently the way this is handled is that an "info variables" debugger command was added; this shows a combination of locals/instance_variables. A "variables" buffer then shows this in a separate window/frame. (Note that in gdb and pydb there is buffer is called a "locals" buffer. In Ruby when the contents of that buffer changed from "locals" to "locals + instance variables" the name of that buffer changed to "variables".) At any rate I wonder if this observation might also applicable for Python as well. However in Python, class, constant and and instance variables are not distinct from local variables. So there are a couple parts to this question. First what should be annotated? And second, what should be shown in an Emacs buffer. For example, it is possible for example to annotate separately class, and local variables, but show these combined in a single buffer. Since each variable is not visually distinct there might be a separator line in the buffer or maybe some mechanism to make them visually distinct. Or there could be more windows/frames. Or there might be a setting to indicate what variables get shown in a "variable" windows. Thoughts? |
From: R. B. <ro...@pa...> - 2007-11-17 15:27:37
|
What things do people find most helpful in debugging from emacs? What things in general are lacking? (Of course, I'm mostly interested in the languages cited above and improving debugging interaction with those, but other information could be helpful as well.) One thing I notice regarding edebug which seems different than gud debugging is that it sets up (I guess) a recursive edit on the program begin debugged so that it can bind keys to debug functions like step, next, and so on. Do people generally find it useful when debugging to set the program read only so that it can't be modified while debugging? Or is this an annoyance? For Emacs Lisp code, I find C-x C-e helpful and use that a lot. For these other programming languages that could be bound to eval using the debugger. (And if not debugging, it might fall back to running the expression in a comint shell buffer). |
From: R. B. <ro...@pa...> - 2007-04-15 22:48:15
|
Releasing 1.22. However afterwards I realized that I could easily do a little better in showing call information. Instead of: $ pydb --basename --fntrace gcd.py 4 6 --Call level 0 (gcd.py:13): check_args + 13 def check_args(): --Return from level 0 (<type 'NoneType'>) --Call level 0 (gcd.py:24): gcd + 24 def gcd(a,b): ----Call level 1 (gcd.py:24): gcd + 24 def gcd(a,b): We now have: $ pydb --basename --fntrace gcd.py 3 5 --Call level 0 check_args() (gcd.py:13): check_args + 13 def check_args(): --Return from level 0 (<type 'NoneType'>) --Call level 0 gcd(a=3, b=5) (gcd.py:24): gcd + 24 def gcd(a,b): ----Call level 1 gcd(a=2, b=3) + 24 def gcd(a,b): So it will go into the next release. I may retrofit some of this into the bash debugger. |
From: R. B. <ro...@pa...> - 2007-04-13 01:33:41
|
I'm planning a release soon. As always if you can test out that would be appreciated. Here's what's in NEWS for this release: * Add function tracing and option -F. * Call and return trace lines show nesting level. Return will show the value if it is a scalar or string type or return type otherwise. * Make pydb.el work on Emacs 22 and 23. (was previously just 21). Better emacs toleratoin on MS Windows. * fix bug in "info thread" when threadframe is not installed (and python < 2.5). * Better ipython interaction. * pm distinquishes now where an exception rolled back to versus where the exception occurred. |
From: R. B. <ro...@pa...> - 2007-03-14 04:16:09
|
DaveS writes: > According to the docs for 'break', when called with a function name it > should set the breakpoint at the first executable line of the function. > Right now "break sub1" will set the breakpoint at the definition of the > function, not the execution of it (like when setting a breakpoint by line > number). Okay, will investigate when I get chance but I'm not sure when that will be. Doing lots of Ruby/Rails nowadays. > It looks like the function name is not being set when the breakpoint is > parsed in get_brkpt_lineno (fns.py). I've attached a patch that does the > right thing. > > --- fns.py 2007-03-13 19:25:03.087000000 -0700 > +++ fns.py.orig 2007-03-13 19:23:37.321375000 -0700 > @@ -356,7 +356,6 @@ > code = func.func_code > # use co_name to identify the bkpt (function names > #could be aliased, but co_name is invariant) > - funcname = arg > lineno = code.co_firstlineno > filename = code.co_filename > except: Although I agree there seems to be a bug, I'm not convinced this is the right thing. The comment seems to indicate that code.co_name should be used. So what are the merits/demerits of using that co_name versus arg? Could you make up a little test case that shows the bug, and maybe why arg is better than co_name or vice versa? Thanks. |
From: DaveS <da...@te...> - 2007-03-14 03:23:06
|
-- DS |
From: R. B. <ro...@pa...> - 2007-03-02 18:46:25
|
I was alerted to a nicer gdb interface that is available in Emacs 23 (and possibly Emacs 22). The Emacs Lisp routines are in file gdb-ui.el and the name of the top-level Emacs command is "gdba" -- however if everything is set right, running "gdb" will run "gdba". I mention in case someone is interested in working on extending either bashdb.el, pydb.el, or mdb.el to make use of the better UI. But beware -- it looks like the underlying mechanism, a gdb "annotation level" setting is going to be changed and phased out with something else. Lament: there are about 6 different and incompatible GUI-to-debugger interfaces. |
From: R. B. <ro...@pa...> - 2007-02-19 10:00:15
|
DaveS writes: > Ah, didn't realize that. I guess the only issue with that is if pydb is not > running through gud (say in ipython) you get a double tracer - the first > (source:line) output that gdb would hide if it was running plus this second > tracer. I'll get use to it. Actually, it is *more* helpful when not run under Emacs and in ipython in particular. Try running %pydb and stepping lines. It is helpful to see the text of source shown. Furthermore, in pydb's CVS I've broken out and the exposed the method that prints that source line. This was done for ipython in particular, but it could be helpful for other things of that ilk, e.g. remote execution or Eclipse which may want results tagged in XML. In ipython, I've patched Debugger.py to wrap a PyColorize call to that source line. Recall that ipython creates a customized Pdb object suited for its particular way of doing things. The patch hasn't been submitted because there are already a number of patches in ipython that I've sent in that haven't been applied -- and some of those need to get in for this to work. However it's also possible for ipython or some other such front-end to customize an enclosing method, like "print_location". And there it could choose not to show that line. (But again for ipython in particular, I don't think it advisable when run outside of Emacs.) > > p.stdout seems better than stderr; we allow all debugger output to get > > redirected to wherever was specified. If it's not doing that it's a > > bug. I've just put this change also in CVS. > > > > Does this mean that all output should make it's way to the debugger stdout > member? If so I'll keep my eye open for any other cases. Yes - thanks. For example in version 1.21 a change was made so that disassembly output no longer goes to stdout unconditionally. > > Yes, this has changed. On an exception in Python 2.5 you are now at > > the point at which the exception was fielded rather than at the point > > it was raised. Previously there was no way to know, and personally I > > think this is a little more accurate. However in the future I may > > consider adding some option to allow the old behavior. For now if you > > always want to be at the the place the exception was raised issue > > "frame 0". > > I guess this is more accurate, but if I'm working on a script I don't > normally need to see all the stack frames from the debugging framework. I > like to think that my script is the only thing running. I vote +1 for being > able to hide, or at least easily ignore, the pydb frames. Yes, this has crossed my mind on a number of occasions. And in fact we do some of this already on the most-recent side of the stack when you use the "--threading" option. What you are suggesting is hiding frames at the other end. (pdb has this problem too which is where we inherited the bad behavior.) I'll also note that the mechanism for doing this is a little cumbersome and error prone. Either you look for certain source file names like "bdb.py" (error prone), or you create a variable in the call stack that you introspect on and identify like "breadcrumb" which has a value of the method it is in that you can compare against (cumbersome). And this latter alternative isn't available if the code comes from outside of pydb as bdb.py does. > > Lastly, expect alas more breakage with pydb, ipython, emacs. Recently I've > >been changing the first two so that colorized output appears. (See the > >ipython forum on that. There are some patches I haven't sent in yet > >though.) However the recent changes seems to have cause the line-tracking > >regexp to now fail. > > I've previously seen some issues related to coloured text. If the > ansi-codes aren't processed before the tracking filters scan the text the > regexps can fail - and some filters work with the passed text while others > directly scan the buffer contents, so it's a bit of a hair puller at times. Yes, so help here would be appreciated. Although my preferred interaction of pydb is via Emacs, I don't really use ipython inside emacs. I'll often just use a the Emacs pydb debugger, or a regular shell with pydb line tracking, or a python shell. But tolerance for other modes is good. I've noticed that many of the fixes needed for such things are generally useful to make pydb better or more general. There is another gdb-like debugger for Ruby (called ruby-debug). It's overall design is a bit cleaner. In particular, the entire "printing" mechanism is its own class. Such a structure like this might be of help here. > Looking forward to more goodness. I can only go so far and have limited time I can spend on this. So really a lot depends on everyone or others. |
From: DaveS <da...@te...> - 2007-02-19 05:03:42
|
On Sun, Feb 18 2007, R. Bernstein wrote: > Thanks for the patches but I'm having trouble using some of them. > > DaveS writes: > > > > Some tweaks to pydb.el for better windows support (c: and spaces in > > filenames). BTW is pydb-pydbtrack-stack-entry-regexp currently used for > > anything? > > Perhaps not. I've removed for now. We'll see what breaks if anything. > > > > > --8<---------------cut here---------------start------------->8--- > > (setq gud-pydb-marker-regexp > > "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]+\\):\\([0-9]+\\))") > > (setq pydb-position-re > > "\\(^\\|\n\\)(\\(\\(?:[A-Za-z]:\\)?[^:]+\\):\\([0-9]*\\)).*\n") > > (setq pydb-pydbtrack-stack-entry-regexp > > "^(\\((?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)"))) > > --8<---------------cut here---------------end--------------->8--- > > Please give a diff against the current emacs/pydb.el for this. And > also please add a test in emacs/pydb-test.el.in for the a sample > string this now matches. I'm not sure I could reliably make a change > from what you have above. > I'll take a crack at this tomorrow. > > > > A couple of small python changes: > > > > * raw_input() needs a strip() because when running pydb with ipython and > > emacs, I keep getting a trailing CR, which breaks things. > > This change has been applied in CVS. > > > * pydbcmd.py: 419 > > looks like an indentation error. The line trace was *always* being printed. > > > No, this is intentional. Look at gdb output and you'll see a similar > output format. > Ah, didn't realize that. I guess the only issue with that is if pydb is not running through gud (say in ipython) you get a double tracer - the first (source:line) output that gdb would hide if it was running plus this second tracer. I'll get use to it. > > > > Index: C:/Python25/Lib/site-packages/pydb/gdb.py > > =================================================================== --- > > C:/Python25/Lib/site-packages/pydb/gdb.py (revision 1) > > +++ C:/Python25/Lib/site-packages/pydb/gdb.py (revision 5) > > As mentioned above, I've applied this change. It doesn't break the > regression tests. Presumably if it breaks things for someone else > we'll find out down the line. > > But in the future place patch against the source (which in this case > the basename of the file is gdb.py.in) > Sorry about that, I've never really worked with configure before and I just kind of forgot about those .in files. I'll need to adjust my work patterns a bit. > > > One last change I didn't include in the patch (because it's so ugly). > > traceback.print_exc() prints to stderr by default, but when I'm running in > > emacs that seems to get buffered so I don't see the traceback until I exit > > pydb. For now I'm just calling as traceback.print_exc(file=p.stdout) to > > make it work. Still looking for a better alternative. > > p.stdout seems better than stderr; we allow all debugger output to get > redirected to wherever was specified. If it's not doing that it's a > bug. I've just put this change also in CVS. > Does this mean that all output should make it's way to the debugger stdout member? If so I'll keep my eye open for any other cases. > > > > Somethings changed with the tracebacks. When execution stops because > > of an exception, I'm getting dropped deep into pydb code rather then at > > the point of failure. Example: > > Yes, this has changed. On an exception in Python 2.5 you are now at > the point at which the exception was fielded rather than at the point > it was raised. Previously there was no way to know, and personally I > think this is a little more accurate. However in the future I may > consider adding some option to allow the old behavior. For now if you > always want to be at the the place the exception was raised issue > "frame 0". I guess this is more accurate, but if I'm working on a script I don't normally need to see all the stack frames from the debugging framework. I like to think that my script is the only thing running. I vote +1 for being able to hide, or at least easily ignore, the pydb frames. > > Lastly, expect alas more breakage with pydb, ipython, emacs. Recently I've >been changing the first two so that colorized output appears. (See the >ipython forum on that. There are some patches I haven't sent in yet >though.) However the recent changes seems to have cause the line-tracking >regexp to now fail. > I've previously seen some issues related to coloured text. If the ansi-codes aren't processed before the tracking filters scan the text the regexps can fail - and some filters work with the passed text while others directly scan the buffer contents, so it's a bit of a hair puller at times. Looking forward to more goodness. -- DS |
From: R. B. <ro...@pa...> - 2007-02-19 02:55:46
|
Thanks for the patches but I'm having trouble using some of them. DaveS writes: > > Some tweaks to pydb.el for better windows support (c: and spaces in > filenames). BTW is pydb-pydbtrack-stack-entry-regexp currently used for > anything? Perhaps not. I've removed for now. We'll see what breaks if anything. > > --8<---------------cut here---------------start------------->8--- > (setq gud-pydb-marker-regexp > "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]+\\):\\([0-9]+\\))") > (setq pydb-position-re > "\\(^\\|\n\\)(\\(\\(?:[A-Za-z]:\\)?[^:]+\\):\\([0-9]*\\)).*\n") > (setq pydb-pydbtrack-stack-entry-regexp > "^(\\((?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)"))) > --8<---------------cut here---------------end--------------->8--- Please give a diff against the current emacs/pydb.el for this. And also please add a test in emacs/pydb-test.el.in for the a sample string this now matches. I'm not sure I could reliably make a change from what you have above. > > A couple of small python changes: > > * raw_input() needs a strip() because when running pydb with ipython and > emacs, I keep getting a trailing CR, which breaks things. This change has been applied in CVS. > * pydbcmd.py: 419 > looks like an indentation error. The line trace was *always* being printed. No, this is intentional. Look at gdb output and you'll see a similar output format. > > Index: C:/Python25/Lib/site-packages/pydb/gdb.py > =================================================================== > --- C:/Python25/Lib/site-packages/pydb/gdb.py (revision 1) > +++ C:/Python25/Lib/site-packages/pydb/gdb.py (revision 5) As mentioned above, I've applied this change. It doesn't break the regression tests. Presumably if it breaks things for someone else we'll find out down the line. But in the future place patch against the source (which in this case the basename of the file is gdb.py.in) > One last change I didn't include in the patch (because it's so ugly). > traceback.print_exc() prints to stderr by default, but when I'm running in > emacs that seems to get buffered so I don't see the traceback until I exit > pydb. For now I'm just calling as traceback.print_exc(file=p.stdout) to > make it work. Still looking for a better alternative. p.stdout seems better than stderr; we allow all debugger output to get redirected to wherever was specified. If it's not doing that it's a bug. I've just put this change also in CVS. > > Somethings changed with the tracebacks. When execution stops because of an > exception, I'm getting dropped deep into pydb code rather then at the point > of failure. Example: Yes, this has changed. On an exception in Python 2.5 you are now at the point at which the exception was fielded rather than at the point it was raised. Previously there was no way to know, and personally I think this is a little more accurate. However in the future I may consider adding some option to allow the old behavior. For now if you always want to be at the the place the exception was raised issue "frame 0". Lastly, expect alas more breakage with pydb, ipython, emacs. Recently I've been changing the first two so that colorized output appears. (See the ipython forum on that. There are some patches I haven't sent in yet though.) However the recent changes seems to have cause the line-tracking regexp to now fail. |
From: DaveS <da...@te...> - 2007-02-19 01:42:05
|
Some tweaks to pydb.el for better windows support (c: and spaces in filenames). BTW is pydb-pydbtrack-stack-entry-regexp currently used for anything? --8<---------------cut here---------------start------------->8--- (setq gud-pydb-marker-regexp "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]+\\):\\([0-9]+\\))") (setq pydb-position-re "\\(^\\|\n\\)(\\(\\(?:[A-Za-z]:\\)?[^:]+\\):\\([0-9]*\\)).*\n") (setq pydb-pydbtrack-stack-entry-regexp "^(\\((?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)"))) --8<---------------cut here---------------end--------------->8--- A couple of small python changes: * raw_input() needs a strip() because when running pydb with ipython and emacs, I keep getting a trailing CR, which breaks things. * pydbcmd.py: 419 looks like an indentation error. The line trace was *always* being printed. |
From: R. B. <ro...@pa...> - 2007-02-09 06:51:44
|
I'm trying for another release of pydb on Feb 13th. Here's what's in NEWS. * pydb script will do a path search to find a script, same as gdb. If compiled Python script is given, we try to find the non-compiled equivalent. * 'help' command now allows an expression and runs Python's builtin help command (pydoc). Add pydoc command to call pydoc externally. * Make prompt string detection in Emacs pydb-track more MS-friendly. Add a unit test for the Emacs interface. * Allow lowercase signal names, e.g. "int" or "sigint" for "SIGINT". * disassemble command allows for a start line and end line to limit disassembly, same as gdb. * Allow limited expressions many places an int parameter is used in a debugger command * Allow "info thread" always. That is we don't need --threading for this * signal command's output more like gdb's. * Add pydoc's help (i.e. python's built-in help) to debugger "help" command * Add "set"/"show" option to force debugger output to be flushed on write. * set/show "cmdtrace" is now "trace-commands" to match gdb 6.6. * work-around a possible Python 2.5 bug manifested in pm/post_mortem where t.tb_frame.f_lineno != t.tb_lineno * Experimental command completion. "complete" command now adds in local and global names on the first word * Handle a quit when called via pydb.debugger(). Also experimental. |
From: R. B. <ro...@pa...> - 2007-02-03 21:00:33
|
Last month I gave a short talk at the local Python Users group. In working up a demo for that I added hooking into pydoc when running "help". So "help sys" now runs pydoc on "sys". Stephen Emslie in python-Patches-1641544 offered a patch for command completion: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1641544&group_id=5470 I've modified this and have incorporated into the current CVS. Finally there looks like a bug in Python 2.5 that I've worked around: http://groups.google.com/group/comp.lang.python/browse_thread/thread/3b56478927ca2cd9/dbab330ade89cc82?lnk=st&rnum=5#dbab330ade89cc82 |
From: kammerla <kam...@gm...> - 2006-12-30 07:43:39
|
Synchronization with source works fine, even when source is located on some other drive. I have tried out your proposal and source display jumped to the script on drive c: and back. (I had to use either /sys.path.insert(0, "c:/")/ or /sys.path.insert(0, "c:\\")/ both are working. The committed version of pydb.el is also correct on DOS style pathnames. Thanks a lot for your help. R. Bernstein schrieb: > Thanks for the info. When you write "Syncronization is perfect" did > you try the situation where you have some Python scripts running from > e: and some running from c:? > > Here's a little test for example: > In file e:/Sources/CapFilterScanner/t1.py > > import os, sys > sys.path.insert(0, "c:") # or c:\\ or c:/ - you'll have to see what works here > import t2 > > > In file c:/t2.py: > > print "t2 here" > > > First, when you run t1.py you should see "t2 here". You may have to > change that sys.path.insert to get this right. > > After that works, then inside pydb try stepping through this program > to make sure you switch from t1 to t2. > > Thanks. > > I've committed the regular expression change, but not the one listed > you quoted, because I have feeling the above might not work. Instead > the regular expression commited was the *second* one I listed: > > "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > The ?: is need to make sure the numbering of patterns matched is > correct. It works on Unixy path names if it doesn't on DOSy path names > I'll go to the version you quote below. > > > > kammerla writes: > > Okay, here is what i found: > > > > "(e:\\sources\\capfilterscanner\\capanalyzer.py:3): <module> > > (Pydb) " > > > > in the emacs gud-buffer appears > > > > "Current directory is e:/Sources/CapFilterScanner/ > > <module> > > (Pydb) step > > <module> > > (Pydb) " > > > > Synchronization with the source buffer is perfect and your suggestion > > > > "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > also works fine. (though i do not understand the '?' and the ':' in > > front of the first opening squared bracket...) > > > > I would have expected that the module name and the current line number > > appear in the gud-buffer, but the > > (defun gud-pydb-marker-filter (string) ...) seems to filter it out and i > > can't figure out how it should be. > > > > Anyway pydb within emacs is what i was looking for to help me learning > > python. > > > > > > > > R. Bernstein schrieb: > > > My guess is that a drive letter and backslashes are shown in the > > > location pydb is printing and this is what is not getting > > > recognized. That is, pydb prints something like: > > > > > > (c:\mydirectory\myprog.py:10): > > > > > > If you could copy what appears as a location, e.g. the part that I > > > think will sort of look like what's above -- the line that has the > > > parenthesis -- that would help out. > > > > > > I had been running under cygwin which doesn't show drive letters or > > > use backslashes. > > > > > > A couple comments though about the regular expression used. The > > > pattern you give will match an all sorts of non-drive things, for example: > > > > > > (::a:bbbb:c:\mydirectory\myprog.py:10): > > > > > > So try using this instead: > > > > > > "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > > > > > > There may be another thing in the regular expression you suggests that > > > may be cause problems. I guess that so far the drive printed also > > > happens to be your "current" drive. If you have another drive around > > > try putting a script on that while your current drive is not that. > > > > > > If that doesn't work and the above change did not break things too, > > > then try: > > > > > > "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > > > and see if this works. > > > > > > If you get back with the results, I'll look into updating that nasty > > > regular expression. And yes, regular expressions in GNU Emacs Lisp > > > are a pain in the ass to get right. > > > > > > > > > ralph.kammerlander writes: > > > > Hi, > > > > I'm an absolute beginner with python (and emacs ...) and trying to learn something new. > > > > I am using python 2.5 under WinXP (okay, I could use an other os ...) > > > > I just wanted to use pydb with emacs, but i could only get it to work with the source buffer, when i changed > > > > > > > > (defconst gud-pydb-marker-regexp > > > > "^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?" > > > > to > > > > (defconst gud-pydb-marker-regexp > > > > "^([a-zA-Z:]*\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > > > > > I assume that's not the right way to do it ... > > > > Could somebody help me? > > > > > > > > Ralph > > > > > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Bashdb-pydb mailing list > > Bas...@li... > > https://lists.sourceforge.net/lists/listinfo/bashdb-pydb > > > > |
From: R. B. <ro...@pa...> - 2006-12-29 19:09:26
|
Thanks for the info. When you write "Syncronization is perfect" did you try the situation where you have some Python scripts running from e: and some running from c:? Here's a little test for example: In file e:/Sources/CapFilterScanner/t1.py import os, sys sys.path.insert(0, "c:") # or c:\\ or c:/ - you'll have to see what works here import t2 In file c:/t2.py: print "t2 here" First, when you run t1.py you should see "t2 here". You may have to change that sys.path.insert to get this right. After that works, then inside pydb try stepping through this program to make sure you switch from t1 to t2. Thanks. I've committed the regular expression change, but not the one listed you quoted, because I have feeling the above might not work. Instead the regular expression commited was the *second* one I listed: "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" The ?: is need to make sure the numbering of patterns matched is correct. It works on Unixy path names if it doesn't on DOSy path names I'll go to the version you quote below. kammerla writes: > Okay, here is what i found: > > "(e:\\sources\\capfilterscanner\\capanalyzer.py:3): <module> > (Pydb) " > > in the emacs gud-buffer appears > > "Current directory is e:/Sources/CapFilterScanner/ > <module> > (Pydb) step > <module> > (Pydb) " > > Synchronization with the source buffer is perfect and your suggestion > > "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > also works fine. (though i do not understand the '?' and the ':' in > front of the first opening squared bracket...) > > I would have expected that the module name and the current line number > appear in the gud-buffer, but the > (defun gud-pydb-marker-filter (string) ...) seems to filter it out and i > can't figure out how it should be. > > Anyway pydb within emacs is what i was looking for to help me learning > python. > > > > R. Bernstein schrieb: > > My guess is that a drive letter and backslashes are shown in the > > location pydb is printing and this is what is not getting > > recognized. That is, pydb prints something like: > > > > (c:\mydirectory\myprog.py:10): > > > > If you could copy what appears as a location, e.g. the part that I > > think will sort of look like what's above -- the line that has the > > parenthesis -- that would help out. > > > > I had been running under cygwin which doesn't show drive letters or > > use backslashes. > > > > A couple comments though about the regular expression used. The > > pattern you give will match an all sorts of non-drive things, for example: > > > > (::a:bbbb:c:\mydirectory\myprog.py:10): > > > > So try using this instead: > > > > "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > > > There may be another thing in the regular expression you suggests that > > may be cause problems. I guess that so far the drive printed also > > happens to be your "current" drive. If you have another drive around > > try putting a script on that while your current drive is not that. > > > > If that doesn't work and the above change did not break things too, > > then try: > > > > "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > and see if this works. > > > > If you get back with the results, I'll look into updating that nasty > > regular expression. And yes, regular expressions in GNU Emacs Lisp > > are a pain in the ass to get right. > > > > > > ralph.kammerlander writes: > > > Hi, > > > I'm an absolute beginner with python (and emacs ...) and trying to learn something new. > > > I am using python 2.5 under WinXP (okay, I could use an other os ...) > > > I just wanted to use pydb with emacs, but i could only get it to work with the source buffer, when i changed > > > > > > (defconst gud-pydb-marker-regexp > > > "^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?" > > > to > > > (defconst gud-pydb-marker-regexp > > > "^([a-zA-Z:]*\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > > > I assume that's not the right way to do it ... > > > Could somebody help me? > > > > > > Ralph > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bashdb-pydb mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-pydb > |
From: kammerla <kam...@gm...> - 2006-12-29 16:37:28
|
Okay, here is what i found: "(e:\\sources\\capfilterscanner\\capanalyzer.py:3): <module> (Pydb) " in the emacs gud-buffer appears "Current directory is e:/Sources/CapFilterScanner/ <module> (Pydb) step <module> (Pydb) " Synchronization with the source buffer is perfect and your suggestion "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" also works fine. (though i do not understand the '?' and the ':' in front of the first opening squared bracket...) I would have expected that the module name and the current line number appear in the gud-buffer, but the (defun gud-pydb-marker-filter (string) ...) seems to filter it out and i can't figure out how it should be. Anyway pydb within emacs is what i was looking for to help me learning python. R. Bernstein schrieb: > My guess is that a drive letter and backslashes are shown in the > location pydb is printing and this is what is not getting > recognized. That is, pydb prints something like: > > (c:\mydirectory\myprog.py:10): > > If you could copy what appears as a location, e.g. the part that I > think will sort of look like what's above -- the line that has the > parenthesis -- that would help out. > > I had been running under cygwin which doesn't show drive letters or > use backslashes. > > A couple comments though about the regular expression used. The > pattern you give will match an all sorts of non-drive things, for example: > > (::a:bbbb:c:\mydirectory\myprog.py:10): > > So try using this instead: > > "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > There may be another thing in the regular expression you suggests that > may be cause problems. I guess that so far the drive printed also > happens to be your "current" drive. If you have another drive around > try putting a script on that while your current drive is not that. > > If that doesn't work and the above change did not break things too, > then try: > > "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > and see if this works. > > If you get back with the results, I'll look into updating that nasty > regular expression. And yes, regular expressions in GNU Emacs Lisp > are a pain in the ass to get right. > > > ralph.kammerlander writes: > > Hi, > > I'm an absolute beginner with python (and emacs ...) and trying to learn something new. > > I am using python 2.5 under WinXP (okay, I could use an other os ...) > > I just wanted to use pydb with emacs, but i could only get it to work with the source buffer, when i changed > > > > (defconst gud-pydb-marker-regexp > > "^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?" > > to > > (defconst gud-pydb-marker-regexp > > "^([a-zA-Z:]*\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > > > I assume that's not the right way to do it ... > > Could somebody help me? > > > > Ralph > > |
From: R. B. <ro...@pa...> - 2006-12-28 13:07:02
|
My guess is that a drive letter and backslashes are shown in the location pydb is printing and this is what is not getting recognized. That is, pydb prints something like: (c:\mydirectory\myprog.py:10): If you could copy what appears as a location, e.g. the part that I think will sort of look like what's above -- the line that has the parenthesis -- that would help out. I had been running under cygwin which doesn't show drive letters or use backslashes. A couple comments though about the regular expression used. The pattern you give will match an all sorts of non-drive things, for example: (::a:bbbb:c:\mydirectory\myprog.py:10): So try using this instead: "^(\\(?:[a-zA-Z]:\\)?\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" There may be another thing in the regular expression you suggests that may be cause problems. I guess that so far the drive printed also happens to be your "current" drive. If you have another drive around try putting a script on that while your current drive is not that. If that doesn't work and the above change did not break things too, then try: "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" and see if this works. If you get back with the results, I'll look into updating that nasty regular expression. And yes, regular expressions in GNU Emacs Lisp are a pain in the ass to get right. ralph.kammerlander writes: > Hi, > I'm an absolute beginner with python (and emacs ...) and trying to learn something new. > I am using python 2.5 under WinXP (okay, I could use an other os ...) > I just wanted to use pydb with emacs, but i could only get it to work with the source buffer, when i changed > > (defconst gud-pydb-marker-regexp > "^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?" > to > (defconst gud-pydb-marker-regexp > "^([a-zA-Z:]*\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" > > I assume that's not the right way to do it ... > Could somebody help me? > > Ralph > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> > <META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD> > <BODY> > <DIV>Hi,</DIV> > <DIV>I'm an absolute beginner with python (and emacs ...) and trying to learn > something new.</DIV> > <DIV>I am using python 2.5 under WinXP (okay, I could use an other os ...)</DIV> > <DIV>I just wanted to use pydb with emacs, but i could only get it to work with > the source buffer, when i changed</DIV> > <DIV> </DIV> > <DIV>(defconst gud-pydb-marker-regexp<BR> "^(<A > href="file://([-a-za-z0-9_/.]*//)://([0-9]+//">\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\</A>)):[ > \t]?"<BR>to</DIV> > <DIV>(defconst gud-pydb-marker-regexp<BR> > "^([a-zA-Z:]*\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?"<BR></DIV> > <DIV>I assume that's not the right way to do it ...</DIV> > <DIV>Could somebody help me?</DIV> > <DIV> </DIV> > <DIV>Ralph</DIV></BODY></HTML> > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ > Bashdb-pydb mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-pydb |
From: ralph.kammerlander <kam...@gm...> - 2006-12-28 12:04:16
|
Hi, I'm an absolute beginner with python (and emacs ...) and trying to learn something new. I am using python 2.5 under WinXP (okay, I could use an other os ...) I just wanted to use pydb with emacs, but i could only get it to work with the source buffer, when i changed (defconst gud-pydb-marker-regexp "^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?" to (defconst gud-pydb-marker-regexp "^([a-zA-Z:]*\\([-a-zA-Z0-9_/\\\\.]*\\):\\([0-9]+\\)):[ \t]?" I assume that's not the right way to do it ... Could somebody help me? Ralph |
From: R. B. <ro...@pa...> - 2006-12-10 23:34:19
|
Thanks to everyone who helped with the release. Changes to pydb-1.20: Several bugs have been fixed. There are additional features to make it play nice with the upcoming release of ipython. There are some small improvements in thread debugging commands. |
From: R. B. <ro...@pa...> - 2006-12-06 02:48:23
|
Another release of ipython will probably happen pretty soon, and there has been a feature added and a bug fixed for that. So I'm planning on another pydb release around December 10th. As is the custom, a candidate tarball is at http://bashdb.sf.net/pydb-1.20cvs.tar.gz If folks could test that out, it would be great. Thanks. P.S. Here is what's new for the release: 1.20 2006-12-10 * Turning on signal checking may slow things down too much. So off by default. Fix bug in "set sigcheck". Add --sigcheck option. * Allow a thread number in "info thread" and "frame" commands if Python 2.5 or threadframe. * Show all threads even if we don't know their names. * Allow Pdb object to get passed in runv(). Allows for better ipython invocation (%pydb) and may be useful in other shells as well * Provide a clue when debugger "run" command given but no "file" has been set. * Better shell-like argument parsing in the "run" command via shlex. |
From: R. B. <ro...@pa...> - 2006-10-30 19:39:00
|
That's odd. What are the values of signum and signame? Also What OS are you running under? Thanks. David Geller writes: > Hi, > > I just installed pydb 1.19 (python 2.4.2). > I get the following error upon invocation: > > [ab@host1 pydb-1.19]$ pydb > Traceback (most recent call last): > File "/usr/local/bin/pydb", line 650, in ? > main() > File "/usr/local/bin/pydb", line 554, in main > p = Pdb() > File "/usr/local/bin/pydb", line 203, in __init__ > Gdb.__init__(self, completekey, stdin, stdout) > File "/usr/local/lib/python2.4/site-packages/pydb/gdb.py", line 45, > in __init__ > self.sigmgr = sighandler.SignalManager(self) > File "/usr/local/lib/python2.4/site-packages/pydb/sighandler.py", > line 72, in > __init__ > False, False) > File "/usr/local/lib/python2.4/site-packages/pydb/sighandler.py", > line 249, in __init__ > self.old_handler = signal.getsignal(self.signum) > ValueError: signal number out of range > > > Any ideas? > > Thanks! > > David > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Bashdb-pydb mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-pydb > |
From: David G. <dg...@gm...> - 2006-10-30 19:18:09
|
Hi, I just installed pydb 1.19 (python 2.4.2). I get the following error upon invocation: [ab@host1 pydb-1.19]$ pydb Traceback (most recent call last): File "/usr/local/bin/pydb", line 650, in ? main() File "/usr/local/bin/pydb", line 554, in main p = Pdb() File "/usr/local/bin/pydb", line 203, in __init__ Gdb.__init__(self, completekey, stdin, stdout) File "/usr/local/lib/python2.4/site-packages/pydb/gdb.py", line 45, in __init__ self.sigmgr = sighandler.SignalManager(self) File "/usr/local/lib/python2.4/site-packages/pydb/sighandler.py", line 72, in __init__ False, False) File "/usr/local/lib/python2.4/site-packages/pydb/sighandler.py", line 249, in __init__ self.old_handler = signal.getsignal(self.signum) ValueError: signal number out of range Any ideas? Thanks! David |