[IPython-user] Getting IPython working with NTEmacs

DaveS davls@telus....
Mon Feb 12 22:44:08 CST 2007

I'll try to clarify my original comments a bit to make the review easier.

> * add trailing space to prompts so emacs sees it. (python 2.5 case)
the Python2.4 branch of the Pdb constructor explicitly sets the prompt to
'ipdb> '.  The Python2.5 branch used the global prompt var, which I appended
the space to.

> * pydb writes output to it's out stream in a least one spot (list command...
pydb looks to be consistently using self.stdout for output.  The problem is
the derived Pdb object from IPython which writes output to Term.cout.  Some
content is written out by the pydb base class and some by the IPython
derived class.  In the case of the list command, part of the content is
generated by the IPython half (with colours) but written out by the pydb
half.  So we get line noise instead of coloured text.  Initializing the pydb
base class with Term.cout seemed to be the easiest way to solve the problem.

> * format_stack_entry was placing the '>' carrot on every frame...
IPython wasn't distinguishing the current stack frame from the other frames.
Stand-alone Pdb uses ' ' and '> ' for the normal and current stack frames
respectively.  Stand-alone pydb uses '##' and '->'.  I believe GDB uses the
presence or absence of the program counter.  I followed Pdb format so the
pdbtrack regexp from python-mode.el would work as is.  pydb.el uses a
completely different comint hook to track the current source line (a
consequence of this being that 'where' in pydb will not redraw the source
arrow).  A further complication arises with IPython+pydb, because we get a
double carrot on the stack frames: pydb writes '##/->' then IPython writes
the full frame, including '>'.  pydb.el doesn't look for stack frames so
it's not breaking anything, just looks a little odd.  It doesn't seem to be
that easy to fix though.

> * pydb-pydbtrack-input-prompt
ipython.el resets 'py-pydbtrack-input-prompt' to match the modified prompt
in Debugger.py, but the var defined in pydb.el is actually
'pydb-pydbtrack-input-prompt'.  It's just a typo in the variable name.

I'll give pydb 1.21 a try when it's released.  Oh, I did find a problem with
pydb.el.  Tried posting to the SF list but I'm not a member so I think it
got nuked:

;; get pydb-position-re to recognize windows paths.
(setq pydb-position-re        
;; ditto for pydb-pydbtrack-stack-entry-regexp
;; (but doesn't look like it's actually used anywhere)
(setq pydb-pydbtrack-stack-entry-regexp 
      "^(\\((?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)")

Hope I haven't been too long winded.

"R. Bernstein" <rocky@panix.com> wrote:

> I'd like a couple days to look over. 
> I've long thought the lack of a space at the end of the prompt a
> little odd since it's different from the way pdb works, if not prompts
> in general.
> As for the changes to pydb-pydbtrack-input-prompt, I should double
> check with what is in pydb.el. I know with Bash debugger GNU Emacs
> interface, bashdb.el, there's this problem right now where there are 3
> versions: one that comes with bashdb, one that comes with Bash and one
> that comes with (or will come with) GNU Emacs. We are working on
> removing two out of those 3. I hope we don't have a similar problem
> here with pydb-pydbtrack-input-prompt. Also, recently in the pydb
> space I've started adding a little unit test for that code. In
> particular checking over the regular expressions. Probably a little
> unit test should be added here as well.
> As for the "run -d" with pydb, originally we were trying to make that
> work and gave up as a result of reworking all of the extra hackery in
> ipython that should probably be in pdb, but isn't because pdb doesn't
> change all that often. So instead %pydb is the preferred way to run
> pydb. Personally I'd be fine with having "run -d" just invoke pdb (and
> perhaps give a warning if pydb is around that there is a %pydb magic.)
> Pydb should be consistent in its use of the output stream. (If not
> it's a bug, but I don't think is the case for "list".) There are these
> common routines errmsg and msg which are used for that. This is
> because you don't know where the output may go, it could go to a
> socket to a remote process or to a file or over a serial port. I
> couldn't figure out what the right thing on the ipython side was to
> get the colors right. So thanks for this.
> As for pydb's frame output, I generally try to follow gdb, not pdb. In
> fact it generally *helps* front ends that support multiple
> languages/debuggers because there is less variation in handling
> them. That certainly was the case with ddd. It's been helpful also say
> in Emacs since the same or very similar regular expressions can be
> used. (However I don't know if the issue here is an ipython formatting
> issue rather than a pdb versus gdb issue.)
> Finally I should say that in another day there will be another release
> of pydb (1.21) it has lots of little usability changes (which I hope
> will make things much better). Things like better command completion
> and help using pydoc and automatic Python script resolution for
> executables. I haven't specifically tested the ipython interaction
> (yet).
> Ville M. Vainio writes:
>  > Can any other ntemacs user give this a spin before I (blindly) commit
>  > it? Yet again, I don't have access to my win32 machine during
>  > february.
>  > 
>  > On 2/11/07, DaveS <davls@telus.net> wrote:
>  > > I had a few issues getting IPython working smoothly with NTEmacs so I
>  > > thought I would share my findings.
>  > >
>  > > First of all, my setup:
>  > > NTEmacs 21.3.1
>  > > Python 2.5
>  > > IPython 0.7.3
>  > > pydb 1.20
>  > >
>  > > I made some changes to Debugger.py for both pdb and pydb
>  > > compatibility. (diff attached)
>  > >  * add trailing space to prompts so emacs sees it. (python 2.5 case)
>  > >  * set self.prompt for pydb
>  > >  * pydb writes output to it's out stream in a least one spot (list command)
>  > >  which causes problems with colours, so I initialized stdout to Term.cout.
>  > >  This doesn't seems to cause any new problems.
>  > >  * format_stack_entry was placing the '>' carrot on every frame, which
>  > >  confused emacs, so I changed it to only place it on the current frame. (I
>  > >  think plain pdb works this way)
>  > >  * I tweaked the frame line colours to make things clearer. (this is
>  > >  subjective but I like it better)
>  > >
>  > > A couple of minor items in ipython.el
>  > >  * (setq py-pydbtrack-input-prompt...  should be
>  > >  (setq pydb-pydbtrack-input-prompt
>  > >  * I modified py-traceback-line-re to ignore '>' marked stack frames.
>  > > (setq py-traceback-line-re
>  > >            "\\(^[^\t >].+?\\.py\\).*\n   +[0-9]+[^\00]*?\n-+> \\([0-9]+\\)+")
>  > >
>  > > Also one minor item.  When using 'run -d' with pydb, no initial breakpoint
>  > > gets set, so the instruction about using 'c' to start things gives a
>  > > different result then when using pdb.
>  > >
>  > > After making these changes IPython and Emacs are working great together.
>  > >
>  > >
>  > >
>  > > --
>  > > DS
>  > >
>  > > _______________________________________________
>  > > IPython-user mailing list
>  > > IPython-user@scipy.org
>  > > http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>  > >
>  > >
>  > >
>  > 
>  > 
>  > -- 
>  > Ville M. Vainio - vivainio.googlepages.com
>  > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
>  > 


More information about the IPython-user mailing list