Mercurial > emacs
view admin/notes/iftc @ 92060:fd85a7810d53
Revise pdbtrack functionality to incorporate advances in python-mode.el.
(I'm doing this python.el checkin with some byte-compiler warnings. These
warnings existed before Nick Roberts or I applied any of the pdbtrack
changes, and look very clearly like preexisting, incomplete adoption of
code from python-mode.el. I'm going to next look at settling those
warnings, though I don't have time for a major reconciliation of the two
python-mode implementations.)
(python-pdbtrack-toggle-stack-tracking): Clarify docstring.
(python-pdbtrack-minor-mode-string): A sign indicating that pdb
tracking is happening.
(python-pdbtrack-stack-entry-regexp): Better recognize stack traces.
(python-pdbtrack-input-prompt): Better recognize PDB prompts.
(add python-pdbtrack-track-stack-file to comint-output-filter-functions):
Tracking is plugged in to all comint buffers once python.el is loaded.
(python-pdbtrack-overlay-arrow): Toggle activation of
`python-pdbtrack-minor-mode-string' in addition to the overlay arrow.
(python-pdbtrack-track-stack-file): Use new
`python-pdbtrack-get-source-buffer' for more flexible access to
debugging source files.
(python-pdbtrack-get-source-buffer): Identify debugging target
buffer according to pdb stack trace, optionally using new
`python-pdbtrack-grub-for-buffer' if file is not locally
available.
(python-pdbtrack-grub-for-buffer): Find most recent python-mode
named buffer, or having function with indicated name.
(python-shell): Remove comint-output-filter-functions hook
addition, it's being done elsewhere. Wrap long line.
author | Ken Manheimer <ken.manheimer@gmail.com> |
---|---|
date | Thu, 21 Feb 2008 22:28:13 +0000 |
parents | 695cf19ef79e |
children | 375f2633d815 ef719132ddfa |
line wrap: on
line source
Iso-Functional Type Contour This is a term coined to describe "column int->float" change approach, and can be used whenever low-level types need to change (hopefully not often!) but the meanings of the values (whose type has changed) do not. The premise is that changing a low-level type potentially means lots of code needs to be changed as well, and the question is how to do this incrementally, which is the preferred way to change things. Say LOW and HIGH are C functions: int LOW (void) { return 1; } void HIGH (void) { int value = LOW (); } We want to convert LOW to return float, so we cast HIGH usage: float LOW (void) { return 1.0; } void HIGH (void) { int value = (int) LOW (); } /* iftc */ The comment /* iftc */ is used to mark this type of casting to differentiate it from other casting. We commit the changes and can now go about modifying LOW and HIGH separately. When HIGH is ready to handle the type change, the cast can be removed. ;;; arch-tag: 3309cc41-5d59-421b-b7be-c94b04083bb5