/[guile]/guile/workbook/use/debugging.text
ViewVC logotype

Diff of /guile/workbook/use/debugging.text

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1 by ossau, Thu Aug 28 22:35:30 2003 UTC revision 1.2 by ossau, Sun Aug 31 10:57:28 2003 UTC
# Line 166  Lots of complexity here.  Many interesti Line 166  Lots of complexity here.  Many interesti
166  Djurfeldt's guileint interface, but the end result will look quite  Djurfeldt's guileint interface, but the end result will look quite
167  different from that, I think.  different from that, I think.
168    
169    The following subsections describe some of the ideas that I have in
170    mind.
171    
172    4.3.1. Tracking the relationship between Scheme source buffers and the
173           application they are relevant to
174    
175    [This idea comes from guileint.]
176    
177    Suppose a debugged application hits an error, and Emacs pops up a
178    buffer displaying the source code for the error location.  If the user
179    edits and then wants to reevaluate part of that source code, the
180    frontend should know that the application to send the evaluation to is
181    the one that just hit the error.
182    
183    Then there is the case where the edit is in a file not yet known by
184    the frontend to be associated with the application ...
185    
186    Getting the associated application is ultimately a heuristic effort.
187    Therefore the goal is not to implement something provably correct, but
188    to guess helpfully what the user wants 90% of the time, provide useful
189    cues as to what the frontend is guessing, and make it equally easy for
190    the user to go with the guess and to override it.
191    
192    4.3.2. Enhanced Scheme buffer editing
193    
194    [This idea comes from guileint.]
195    
196    Enhanced editing helps the user by keeping track of which top level
197    forms have been edited since they were last evaluated by the
198    associated application, and provides a convenient `reevaluate all
199    edited forms' command.
200    
201    It also remembers, for each top level form, what the result of the
202    last evaluation was.
203    
204    It also detects when a top level form is syntactically broken -
205    i.e. its parentheses don't balance.  Broken forms are excluded from
206    the `reevaluate all edited forms' command.
207    
208    Finally, it visually indicates the current state of each top level
209    form, which is one of `up to date', `edited' or `broken'.
210    
211    4.3.3. Application and module browsing
212    
213    This is a tree-like display of:
214    
215    Applications
216      Modules (used by each application)
217        Bindings (of each module)
218    
219    It can be used to:
220    - set and configure breakpoints
221    - see the current value of a binding
222    - see the documentation for a binding.
223    
224    There are several possible methods for getting the list of modules for
225    an application, and the list of bindings for a module, from static
226    scanning to actually loading or running the code and seeing what
227    results.  The desirability and safety of each method depends on the
228    code itself and is difficult to determine heuristically, so the
229    frontend simply provides all the available options and leaves the
230    choice up to the user.  (Perhaps defaulting to a safe static scan.)
231    
232    I think it would be good to implement this as a specialized kind of
233    Speedbar, to avoid completely reinventing the wheel.
234    
235    4.3.4. Error location and stack display
236    
237    [This idea comes from guileint.]
238    
239    When an error or breakpoint is hit, the frontend displays, in 3
240    windows:
241    - the relevant source code
242    - the stack
243    - the error or breakpoint details.
244    
245    At such times, the frontend provides convenience commands for
246    exploring the stack, evaluating variables, single stepping, continuing
247    execution and whatever else is useful.
248    
249    4.3.5. Debug session recording and replay
250    
251    One disadvantage of a graphical interface is that it can be difficult
252    to keep a log of actions performed and to repeat actions if necessary.
253    The Emacs frontend remedies this by keeping a record of actions
254    performed, on a per-application basis, and making it possible to
255    replay them.
256    
257  4.4. Debugging channel protocol  4.4. Debugging channel protocol
258    
259  (name NAME)  (name NAME)

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26