Commit | Line | Data |
---|---|---|
46f7666d NJ |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Guile Reference Manual. | |
749c2532 | 3 | @c Copyright (C) 2006, 2010 |
46f7666d NJ |
4 | @c Free Software Foundation, Inc. |
5 | @c See the file guile.texi for copying conditions. | |
6 | ||
7 | @node Using Guile Interactively | |
8 | @section Using Guile Interactively | |
9 | ||
10 | When you start up Guile by typing just @code{guile}, without a | |
11 | @code{-c} argument or the name of a script to execute, you get an | |
12 | interactive interpreter where you can enter Scheme expressions, and | |
13 | Guile will evaluate them and print the results for you. Here are some | |
14 | simple examples. | |
15 | ||
16 | @lisp | |
749c2532 | 17 | scheme@@(guile-user)> (+ 3 4 5) |
dc3b2661 | 18 | $1 = 12 |
749c2532 | 19 | scheme@@(guile-user)> (display "Hello world!\n") |
46f7666d | 20 | Hello world! |
749c2532 | 21 | scheme@@(guile-user)> (values 'a 'b) |
dc3b2661 AW |
22 | $2 = a |
23 | $3 = b | |
46f7666d NJ |
24 | @end lisp |
25 | ||
26 | @noindent | |
27 | This mode of use is called a @dfn{REPL}, which is short for | |
28 | ``Read-Eval-Print Loop'', because the Guile interpreter first reads the | |
29 | expression that you have typed, then evaluates it, and then prints the | |
30 | result. | |
31 | ||
749c2532 AW |
32 | The prompt shows you what language and module you are in. In this case, the |
33 | current language is @code{scheme}, and the current module is | |
34 | @code{(guile-user)}. @xref{Other Languages}, for more information on Guile's | |
35 | support for languages other than Scheme. | |
36 | ||
46f7666d | 37 | @menu |
3c0b7725 | 38 | * Readline:: |
ca290a89 | 39 | * Value History:: |
3c0b7725 AW |
40 | * REPL Commands:: |
41 | * Error Handling:: | |
42 | * Interactive Debugging:: | |
46f7666d NJ |
43 | @end menu |
44 | ||
45 | ||
46 | @node Readline | |
47 | @subsection Readline | |
48 | ||
49 | To make it easier for you to repeat and vary previously entered | |
50 | expressions, or to edit the expression that you're typing in, Guile | |
51 | can use the GNU Readline library. This is not enabled by default | |
52 | because of licensing reasons, but all you need to activate Readline is | |
53 | the following pair of lines. | |
54 | ||
55 | @lisp | |
749c2532 AW |
56 | scheme@@(guile-user)> (use-modules (ice-9 readline)) |
57 | scheme@@(guile-user)> (activate-readline) | |
46f7666d NJ |
58 | @end lisp |
59 | ||
749c2532 | 60 | It's a good idea to put these two lines (without the ``scheme@@(guile-user)>'' |
46f7666d NJ |
61 | prompts) in your @file{.guile} file. Guile reads this file when it |
62 | starts up interactively, so anything in this file has the same effect | |
749c2532 | 63 | as if you type it in by hand at the ``scheme@@(guile-user)>'' prompt. |
46f7666d NJ |
64 | |
65 | ||
ca290a89 | 66 | @node Value History |
46f7666d NJ |
67 | @subsection Value History |
68 | ||
69 | Just as Readline helps you to reuse a previous input line, @dfn{value | |
70 | history} allows you to use the @emph{result} of a previous evaluation | |
71 | in a new expression. When value history is enabled, each evaluation | |
72 | result is automatically assigned to the next in the sequence of | |
73 | variables @code{$1}, @code{$2}, @dots{}, and you can then use these | |
74 | variables in subsequent expressions. | |
75 | ||
76 | @lisp | |
749c2532 | 77 | scheme@@(guile-user)> (iota 10) |
46f7666d | 78 | $1 = (0 1 2 3 4 5 6 7 8 9) |
749c2532 | 79 | scheme@@(guile-user)> (apply * (cdr $1)) |
46f7666d | 80 | $2 = 362880 |
749c2532 | 81 | scheme@@(guile-user)> (sqrt $2) |
46f7666d | 82 | $3 = 602.3952191045344 |
749c2532 | 83 | scheme@@(guile-user)> (cons $2 $1) |
46f7666d NJ |
84 | $4 = (362880 0 1 2 3 4 5 6 7 8 9) |
85 | @end lisp | |
86 | ||
dc3b2661 AW |
87 | Value history is enabled by default, because Guile's REPL imports the |
88 | @code{(ice-9 history)} module. Value history may be turned off or on within the | |
89 | repl, using the options interface: | |
90 | ||
91 | @lisp | |
92 | scheme@@(guile-user)> ,option value-history #f | |
93 | scheme@@(guile-user)> 'foo | |
94 | foo | |
95 | scheme@@(guile-user)> ,option value-history #t | |
96 | scheme@@(guile-user)> 'bar | |
97 | $5 = bar | |
98 | @end lisp | |
99 | ||
100 | Note that previously recorded values are still accessible, even if value history | |
101 | is off. In rare cases, these references to past computations can cause Guile to | |
102 | use too much memory. One may clear these values, possibly enabling garbage | |
103 | collection, via the @code{clear-value-history!} procedure, described below. | |
104 | ||
105 | The programmatic interface to value history is in a module: | |
106 | ||
107 | @lisp | |
108 | (use-modules (ice-9 history)) | |
109 | @end lisp | |
110 | ||
111 | @deffn {Scheme Procedure} value-history-enabled? | |
112 | Return true iff value history is enabled. | |
113 | @end deffn | |
114 | ||
115 | @deffn {Scheme Procedure} enable-value-history! | |
116 | Turn on value history, if it was off. | |
117 | @end deffn | |
118 | ||
119 | @deffn {Scheme Procedure} disable-value-history! | |
120 | Turn off value history, if it was on. | |
121 | @end deffn | |
122 | ||
123 | @deffn {Scheme Procedure} clear-value-history! | |
124 | Clear the value history. If the stored values are not captured by some other | |
125 | data structure or closure, they may then be reclaimed by the garbage collector. | |
126 | @end deffn | |
46f7666d NJ |
127 | |
128 | ||
3c0b7725 AW |
129 | @node REPL Commands |
130 | @subsection REPL Commands | |
46f7666d | 131 | |
3c0b7725 AW |
132 | @cindex commands |
133 | The REPL exists to read expressions, evaluate them, and then print their | |
134 | results. But sometimes one wants to tell the REPL to evaluate an | |
135 | expression in a different way, or to do something else altogether. A | |
136 | user can affect the way the REPL works with a @dfn{REPL command}. | |
46f7666d | 137 | |
3c0b7725 AW |
138 | The previous section had an example of a command, in the form of |
139 | @code{,option}. | |
46f7666d NJ |
140 | |
141 | @lisp | |
3c0b7725 | 142 | scheme@@(guile-user)> ,option value-history #t |
46f7666d NJ |
143 | @end lisp |
144 | ||
145 | @noindent | |
3c0b7725 AW |
146 | Commands are distinguished from expressions by their initial comma |
147 | (@samp{,}). Since a comma cannot begin an expression in most languages, | |
148 | it is an effective indicator to the REPL that the following text forms a | |
149 | command, not an expression. | |
46f7666d | 150 | |
3c0b7725 AW |
151 | REPL commands are convenient because they are always there. Even if the |
152 | current module doesn't have a binding for @code{pretty-print}, one can | |
153 | always @code{,pretty-print}. | |
46f7666d | 154 | |
3c0b7725 AW |
155 | The following sections document the various commands, grouped together |
156 | by functionality. Many of the commands have abbreviations; see the | |
157 | online help (@code{,help}) for more information. | |
46f7666d | 158 | |
3c0b7725 AW |
159 | @menu |
160 | * Help Commands:: | |
161 | * Module Commands:: | |
162 | * Language Commands:: | |
163 | * Compile Commands:: | |
164 | * Profile Commands:: | |
165 | * Debug Commands:: | |
166 | * Inspect Commands:: | |
167 | * System Commands:: | |
168 | @end menu | |
46f7666d | 169 | |
3c0b7725 AW |
170 | @node Help Commands |
171 | @subsubsection Help Commands | |
46f7666d | 172 | |
3c0b7725 AW |
173 | When Guile starts interactively, it notifies the user that help can be |
174 | had by typing @samp{,help}. Indeed, @code{help} is a command, and a | |
175 | particularly useful one, as it allows the user to discover the rest of | |
176 | the commands. | |
46f7666d | 177 | |
3c0b7725 AW |
178 | @deffn {REPL Command} help [@samp{all} | group | @samp{[-c]} command] |
179 | Show help. | |
46f7666d | 180 | |
3c0b7725 AW |
181 | With one argument, tries to look up the argument as a group name, giving |
182 | help on that group if successful. Otherwise tries to look up the | |
183 | argument as a command, giving help on the command. | |
46f7666d | 184 | |
3c0b7725 AW |
185 | If there is a command whose name is also a group name, use the @samp{-c |
186 | @var{command}} form to give help on the command instead of the group. | |
46f7666d | 187 | |
3c0b7725 AW |
188 | Without any argument, a list of help commands and command groups |
189 | are displayed. | |
190 | @end deffn | |
46f7666d | 191 | |
3c0b7725 AW |
192 | @deffn {REPL Command} show [topic] |
193 | Gives information about Guile. | |
46f7666d | 194 | |
3c0b7725 AW |
195 | With one argument, tries to show a particular piece of information; |
196 | currently supported topics are `warranty' (or `w'), `copying' (or `c'), | |
197 | and `version' (or `v'). | |
46f7666d | 198 | |
3c0b7725 AW |
199 | Without any argument, a list of topics is displayed. |
200 | @end deffn | |
46f7666d | 201 | |
3c0b7725 AW |
202 | @deffn {REPL Command} apropos regexp |
203 | Find bindings/modules/packages. | |
204 | @end deffn | |
46f7666d | 205 | |
3c0b7725 AW |
206 | @deffn {REPL Command} describe obj |
207 | Show description/documentation. | |
208 | @end deffn | |
46f7666d | 209 | |
3c0b7725 AW |
210 | @node Module Commands |
211 | @subsubsection Module Commands | |
ee6be719 | 212 | |
3c0b7725 AW |
213 | @deffn {REPL Command} module [module] |
214 | Change modules / Show current module. | |
ee6be719 NJ |
215 | @end deffn |
216 | ||
3c0b7725 AW |
217 | @deffn {REPL Command} import [module ...] |
218 | Import modules / List those imported. | |
219 | @end deffn | |
46f7666d | 220 | |
3c0b7725 AW |
221 | @deffn {REPL Command} load file |
222 | Load a file in the current module. | |
223 | @end deffn | |
46f7666d | 224 | |
3c0b7725 AW |
225 | @deffn {REPL Command} binding |
226 | List current bindings. | |
227 | @end deffn | |
46f7666d | 228 | |
3c0b7725 AW |
229 | @node Language Commands |
230 | @subsubsection Language Commands | |
46f7666d | 231 | |
3c0b7725 AW |
232 | @deffn {REPL Command} language language |
233 | Change languages. | |
46f7666d NJ |
234 | @end deffn |
235 | ||
3c0b7725 AW |
236 | @node Compile Commands |
237 | @subsubsection Compile Commands | |
46f7666d | 238 | |
3c0b7725 AW |
239 | @deffn {REPL Command} compile exp |
240 | Generate compiled code. | |
241 | @end deffn | |
46f7666d | 242 | |
3c0b7725 AW |
243 | @deffn {REPL Command} compile-file file |
244 | Compile a file. | |
245 | @end deffn | |
46f7666d | 246 | |
3c0b7725 AW |
247 | @deffn {REPL Command} disassemble exp |
248 | Disassemble a compiled procedure. | |
249 | @end deffn | |
46f7666d | 250 | |
3c0b7725 AW |
251 | @deffn {REPL Command} disassemble-file file |
252 | Disassemble a file. | |
253 | @end deffn | |
46f7666d | 254 | |
3c0b7725 AW |
255 | @node Profile Commands |
256 | @subsubsection Profile Commands | |
46f7666d | 257 | |
3c0b7725 AW |
258 | @deffn {REPL Command} time exp |
259 | Time execution. | |
46f7666d NJ |
260 | @end deffn |
261 | ||
3c0b7725 AW |
262 | @deffn {REPL Command} profile exp |
263 | Profile execution. | |
46f7666d NJ |
264 | @end deffn |
265 | ||
3c0b7725 AW |
266 | @deffn {REPL Command} trace exp |
267 | Trace execution. | |
46f7666d NJ |
268 | @end deffn |
269 | ||
3c0b7725 AW |
270 | @node Debug Commands |
271 | @subsubsection Debug Commands | |
46f7666d | 272 | |
3c0b7725 AW |
273 | These debugging commands are only available within a recursive REPL; |
274 | they do not work at the top level. | |
46f7666d | 275 | |
3c0b7725 AW |
276 | @deffn {REPL Command} backtrace [count] [#:width w] [#:full? f] |
277 | Print a backtrace. | |
46f7666d | 278 | |
3c0b7725 AW |
279 | Print a backtrace of all stack frames, or innermost @var{COUNT} frames. |
280 | If @var{count} is negative, the last @var{count} frames will be shown. | |
46f7666d NJ |
281 | @end deffn |
282 | ||
3c0b7725 AW |
283 | @deffn {REPL Command} up [count] |
284 | Select a calling stack frame. | |
285 | ||
286 | Select and print stack frames that called this one. | |
287 | An argument says how many frames up to go. | |
46f7666d NJ |
288 | @end deffn |
289 | ||
3c0b7725 AW |
290 | @deffn {REPL Command} down [count] |
291 | Select a called stack frame. | |
292 | ||
293 | Select and print stack frames called by this one. | |
294 | An argument says how many frames down to go. | |
46f7666d NJ |
295 | @end deffn |
296 | ||
3c0b7725 AW |
297 | @deffn {REPL Command} frame [idx] |
298 | Show a frame. | |
299 | ||
300 | Show the selected frame. With an argument, select a frame by index, | |
301 | then show it. | |
302 | @end deffn | |
46f7666d | 303 | |
3c0b7725 AW |
304 | @deffn {REPL Command} procedure |
305 | Print the procedure for the selected frame. | |
306 | @end deffn | |
46f7666d | 307 | |
3c0b7725 AW |
308 | @deffn {REPL Command} locals |
309 | Show local variables. | |
46f7666d | 310 | |
3c0b7725 | 311 | Show locally-bound variables in the selected frame. |
46f7666d NJ |
312 | @end deffn |
313 | ||
3c0b7725 AW |
314 | @c FIXME: whenever we regain support for stepping, here are the docs.. |
315 | ||
316 | @c The commands in this subsection all apply only when the stack is | |
317 | @c @dfn{continuable} --- in other words when it makes sense for the program | |
318 | @c that the stack comes from to continue running. Usually this means that | |
319 | @c the program stopped because of a trap or a breakpoint. | |
320 | ||
321 | @c @deffn {Debugger Command} step [n] | |
322 | @c Tell the debugged program to do @var{n} more steps from its current | |
323 | @c position. One @dfn{step} means executing until the next frame entry or | |
324 | @c exit of any kind. @var{n} defaults to 1. | |
325 | @c @end deffn | |
326 | ||
327 | @c @deffn {Debugger Command} next [n] | |
328 | @c Tell the debugged program to do @var{n} more steps from its current | |
329 | @c position, but only counting frame entries and exits where the | |
330 | @c corresponding source code comes from the same file as the current stack | |
331 | @c frame. (See @ref{Step Traps} for the details of how this works.) If | |
332 | @c the current stack frame has no source code, the effect of this command | |
333 | @c is the same as of @code{step}. @var{n} defaults to 1. | |
334 | @c @end deffn | |
335 | ||
336 | @c @deffn {Debugger Command} finish | |
337 | @c Tell the program being debugged to continue running until the completion | |
338 | @c of the current stack frame, and at that time to print the result and | |
339 | @c reenter the command line debugger. | |
340 | @c @end deffn | |
341 | ||
342 | @c @deffn {Debugger Command} continue | |
343 | @c Tell the program being debugged to continue running. (In fact this is | |
344 | @c the same as the @code{quit} command, because it exits the debugger | |
345 | @c command loop and so allows whatever code it was that invoked the | |
346 | @c debugger to continue.) | |
347 | @c @end deffn | |
348 | ||
349 | @c The @code{evaluate} command is most useful for querying the value of a | |
350 | @c variable, either global or local, in the environment of the selected | |
351 | @c stack frame, but it can be used more generally to evaluate any | |
352 | @c expression. | |
353 | ||
354 | @c @deffn {Debugger Command} evaluate expression | |
355 | @c Evaluate an expression in the environment of the selected stack frame. | |
356 | @c The expression must appear on the same line as the command, however it | |
357 | @c may be continued over multiple lines. | |
358 | @c @end deffn | |
359 | ||
360 | @node Inspect Commands | |
361 | @subsubsection Inspect Commands | |
362 | ||
363 | @deffn {REPL Command} inspect EXP | |
364 | Inspect the result(s) of evaluating @var{exp}. | |
365 | @end deffn | |
46f7666d | 366 | |
3c0b7725 AW |
367 | @deffn {REPL Command} pretty-print EXP |
368 | Pretty-print the result(s) of evaluating @var{exp}. | |
369 | @end deffn | |
46f7666d | 370 | |
3c0b7725 AW |
371 | @node System Commands |
372 | @subsubsection System Commands | |
46f7666d | 373 | |
3c0b7725 AW |
374 | @deffn {REPL Command} gc |
375 | Garbage collection. | |
46f7666d NJ |
376 | @end deffn |
377 | ||
3c0b7725 AW |
378 | @deffn {REPL Command} statistics |
379 | Display statistics. | |
46f7666d NJ |
380 | @end deffn |
381 | ||
3c0b7725 AW |
382 | @deffn {REPL Command} option [key value] |
383 | List/show/set options. | |
46f7666d NJ |
384 | @end deffn |
385 | ||
3c0b7725 AW |
386 | @deffn {REPL Command} quit |
387 | Quit this session. | |
46f7666d NJ |
388 | @end deffn |
389 | ||
390 | ||
3c0b7725 AW |
391 | @node Error Handling |
392 | @subsection Error Handling | |
393 | ||
394 | When code being evaluated from the REPL hits an error, Guile enters a | |
395 | new prompt, allowing you to inspect the context of the error. | |
396 | ||
397 | @lisp | |
398 | scheme@@(guile-user)> (map string-append '("a" "b") '("c" #\d)) | |
399 | ERROR: In procedure string-append: | |
400 | ERROR: Wrong type (expecting string): #\d | |
401 | Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. | |
402 | scheme@@(guile-user) [1]> | |
403 | @end lisp | |
404 | ||
405 | The new prompt runs inside the old one, in the dynamic context of the | |
406 | error. It is a recursive REPL, augmented with a reified representation | |
407 | of the stack, ready for debugging. | |
408 | ||
409 | @code{,backtrace} (abbreviated @code{,bt}) displays the Scheme call | |
410 | stack at the point where the error occurred: | |
411 | ||
412 | @lisp | |
413 | scheme@@(guile-user) [1]> ,bt | |
414 | 1 (map #<procedure string-append _> ("a" "b") ("c" #\d)) | |
415 | 0 (string-append "b" #\d) | |
416 | @end lisp | |
417 | ||
418 | In the above example, the backtrace doesn't have much source | |
419 | information, as @code{map} and @code{string-append} are both | |
420 | primitives. But in the general case, the space on the left of the | |
421 | backtrace indicates the line and column in which a given procedure calls | |
422 | another. | |
423 | ||
424 | You can exit a recursive REPL in the same way that you exit any REPL: | |
425 | via @samp{(quit)}, @samp{,quit} (abbreviated @samp{,q}), or | |
426 | @kbd{C-d}, among other options. | |
427 | ||
428 | ||
429 | @node Interactive Debugging | |
430 | @subsection Interactive Debugging | |
431 | ||
432 | A recursive debugging REPL exposes a number of other meta-commands that | |
433 | inspect the state of the computation at the time of the error. These | |
434 | commands allow you to | |
435 | ||
436 | @itemize @bullet | |
437 | @item | |
438 | display the Scheme call stack at the point where the error occurred; | |
439 | ||
440 | @item | |
441 | move up and down the call stack, to see in detail the expression being | |
442 | evaluated, or the procedure being applied, in each @dfn{frame}; and | |
443 | ||
444 | @item | |
445 | examine the values of variables and expressions in the context of each | |
446 | frame. | |
447 | @end itemize | |
448 | ||
449 | @noindent | |
450 | @xref{Debug Commands}, for documentation of the individual | |
451 | commands. This section aims to give more of a walkthrough of a typical | |
452 | debugging session. | |
453 | ||
454 | First, we're going to need a good error. Let's try to macroexpand the | |
455 | expression @code{(unquote foo)}, outside of a @code{quasiquote} form, | |
456 | and see how the macroexpander reports this error. | |
457 | ||
458 | @lisp | |
459 | scheme@@(guile-user)> (macroexpand '(unquote foo)) | |
460 | ERROR: In procedure macroexpand: | |
461 | ERROR: unquote: expression not valid outside of quasiquote in (unquote foo) | |
462 | Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. | |
463 | scheme@@(guile-user) [1]> | |
464 | @end lisp | |
465 | ||
466 | The @code{backtrace} command, which can also be invoked as @code{bt}, | |
467 | displays the call stack (aka backtrace) at the point where the debugger | |
468 | was entered: | |
469 | ||
470 | @lisp | |
471 | scheme@@(guile-user) [1]> ,bt | |
472 | In ice-9/psyntax.scm: | |
473 | 1130:21 3 (chi-top (unquote foo) () ((top)) e (eval) (hygiene #)) | |
474 | 1071:30 2 (syntax-type (unquote foo) () ((top)) #f #f (# #) #f) | |
475 | 1368:28 1 (chi-macro #<procedure de9360 at ice-9/psyntax.scm...> ...) | |
476 | In unknown file: | |
477 | 0 (scm-error syntax-error macroexpand "~a: ~a in ~a" # #f) | |
478 | @end lisp | |
479 | ||
480 | A call stack consists of a sequence of stack @dfn{frames}, with each | |
481 | frame describing one procedure which is waiting to do something with the | |
482 | values returned by another. Here we see that there are four frames on | |
483 | the stack. | |
484 | ||
485 | Note that @code{macroexpand} is not on the stack -- it must have made a | |
486 | tail call to @code{chi-top}, as indeed we would find if we searched | |
487 | @code{ice-9/psyntax.scm} for its definition. | |
488 | ||
489 | When you enter the debugger, the innermost frame is selected, which | |
490 | means that the commands for getting information about the ``current'' | |
491 | frame, or for evaluating expressions in the context of the current | |
492 | frame, will do so by default with respect to the innermost frame. To | |
493 | select a different frame, so that these operations will apply to it | |
494 | instead, use the @code{up}, @code{down} and @code{frame} commands like | |
495 | this: | |
496 | ||
497 | @lisp | |
498 | scheme@@(guile-user) [1]> ,up | |
499 | In ice-9/psyntax.scm: | |
500 | 1368:28 1 (chi-macro #<procedure de9360 at ice-9/psyntax.scm...> ...) | |
501 | scheme@@(guile-user) [1]> ,frame 3 | |
502 | In ice-9/psyntax.scm: | |
503 | 1130:21 3 (chi-top (unquote foo) () ((top)) e (eval) (hygiene #)) | |
504 | scheme@@(guile-user) [1]> ,down | |
505 | In ice-9/psyntax.scm: | |
506 | 1071:30 2 (syntax-type (unquote foo) () ((top)) #f #f (# #) #f) | |
507 | @end lisp | |
508 | ||
509 | Perhaps we're interested in what's going on in frame 2, so we take a | |
510 | look at its local variables: | |
511 | ||
512 | @lisp | |
513 | scheme@@(guile-user) [1]> ,locals | |
514 | Local variables: | |
515 | $1 = e = (unquote foo) | |
516 | $2 = r = () | |
517 | $3 = w = ((top)) | |
518 | $4 = s = #f | |
519 | $5 = rib = #f | |
520 | $6 = mod = (hygiene guile-user) | |
521 | $7 = for-car? = #f | |
522 | $8 = first = unquote | |
523 | $9 = ftype = macro | |
524 | $10 = fval = #<procedure de9360 at ice-9/psyntax.scm:2817:2 (x)> | |
525 | $11 = fe = unquote | |
526 | $12 = fw = ((top)) | |
527 | $13 = fs = #f | |
528 | $14 = fmod = (hygiene guile-user) | |
529 | @end lisp | |
530 | ||
531 | All of the values are accessible by their value-history names | |
532 | (@code{$@var{n}}): | |
533 | ||
534 | @lisp | |
535 | scheme@@(guile-user) [1]> $10 | |
536 | $15 = #<procedure de9360 at ice-9/psyntax.scm:2817:2 (x)> | |
537 | @end lisp | |
538 | ||
539 | We can even invoke the procedure at the REPL directly: | |
540 | ||
541 | @lisp | |
542 | scheme@@(guile-user) [1]> ($10 'not-going-to-work) | |
543 | ERROR: In procedure macroexpand: | |
544 | ERROR: source expression failed to match any pattern in not-going-to-work | |
545 | Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. | |
546 | @end lisp | |
547 | ||
548 | Well at this point we've caused an error within an error. Let's just | |
549 | quit back to the top level: | |
550 | ||
551 | @lisp | |
552 | scheme@@(guile-user) [2]> ,q | |
553 | scheme@@(guile-user) [1]> ,q | |
554 | scheme@@(guile-user)> | |
555 | @end lisp | |
556 | ||
557 | Finally, as a word to the wise: hackers close their REPL prompts with | |
558 | @kbd{C-d}. | |
559 | ||
560 | ||
46f7666d NJ |
561 | @node Using Guile in Emacs |
562 | @section Using Guile in Emacs | |
563 | ||
b20ef3a6 NJ |
564 | @cindex GDS |
565 | @cindex Emacs | |
24dbb5ed NJ |
566 | There are several options for working on Guile Scheme code in Emacs. |
567 | The simplest are to use Emacs's standard @code{scheme-mode} for | |
568 | editing code, and to run the interpreter when you need it by typing | |
569 | ``guile'' at the prompt of a @code{*shell*} buffer, but there are | |
570 | Emacs libraries available which add various bells and whistles to | |
571 | this. The following diagram shows these libraries and how they relate | |
572 | to each other, with the arrows indicating ``builds on'' or | |
573 | ``extends''. For example, the Quack library builds on cmuscheme, | |
574 | which in turn builds on the standard scheme mode. | |
01d2ee15 | 575 | |
e163dd34 BG |
576 | @iftex |
577 | @center @image{scheme,5in} | |
578 | @end iftex | |
579 | @ifnottex | |
01d2ee15 | 580 | @example |
e163dd34 | 581 | @verbatiminclude scheme.txt |
01d2ee15 | 582 | @end example |
e163dd34 | 583 | @end ifnottex |
01d2ee15 NJ |
584 | |
585 | @dfn{scheme}, written by Bill Rozas and Dave Love, is Emacs's standard | |
586 | mode for Scheme code files. It provides Scheme-sensitive syntax | |
587 | highlighting, parenthesis matching, indentation and so on. | |
588 | ||
589 | @dfn{cmuscheme}, written by Olin Shivers, provides a comint-based Scheme | |
590 | interaction buffer, so that you can run an interpreter more directly | |
94a2c24a | 591 | than with the @code{*shell*} buffer approach by typing @kbd{M-x |
01d2ee15 NJ |
592 | run-scheme}. It also extends @code{scheme-mode} so that there are key |
593 | presses for sending selected bits of code from a Scheme buffer to this | |
594 | interpreter. This means that when you are writing some code and want to | |
595 | check what an expression evaluates to, you can easily select that code | |
596 | and send it to the interpreter for evaluation, then switch to the | |
597 | interpreter to see what the result is. cmuscheme is included in the | |
598 | standard Emacs distribution. | |
599 | ||
600 | @dfn{Quack}, written by Neil Van Dyke, adds a number of incremental | |
601 | improvements to the scheme/cmuscheme combination: convenient menu | |
602 | entries for looking up Scheme-related references (such as the SRFIs); | |
603 | enhanced indentation rules that are customized for particular Scheme | |
604 | interpreters, including Guile; an enhanced version of the | |
605 | @code{run-scheme} command that knows the names of the common Scheme | |
606 | interpreters and remembers which one you used last time; and so on. | |
607 | Quack is available from @uref{http://www.neilvandyke.org/quack}. | |
608 | ||
609 | @dfn{GDS}, written by Neil Jerram, also builds on the scheme/cmuscheme | |
24dbb5ed NJ |
610 | combination, but with a change to the way that Scheme code fragments |
611 | are sent to the interpreter for evaluation. cmuscheme and Quack send | |
612 | code fragments to the interpreter's standard input, on the assumption | |
613 | that the interpreter is expecting to read Scheme expressions there, | |
614 | and then monitor the interpreter's standard output to infer what the | |
615 | result of the evaluation is. GDS doesn't use standard input and | |
01d2ee15 NJ |
616 | output like this. Instead, it sets up a socket connection between the |
617 | Scheme interpreter and Emacs, and sends and receives messages using a | |
618 | simple protocol through this socket. The messages include requests to | |
619 | evaluate Scheme code, and responses conveying the results of an | |
24dbb5ed NJ |
620 | evaluation, thus providing similar function to cmuscheme or Quack. |
621 | They also include requests for stack exploration and debugging, which | |
622 | go beyond what cmuscheme or Quack can do. The price of this extra | |
623 | power, however, is that GDS is Guile-specific. GDS requires the | |
624 | Scheme interpreter to run some GDS-specific library code; currently | |
625 | this code is written as a Guile module and uses features that are | |
01d2ee15 | 626 | specific to Guile. GDS is now included in the Guile distribution; for |
24dbb5ed | 627 | previous Guile releases (1.8.4 and earlier) it can be obtained as part |
01d2ee15 NJ |
628 | of the @code{guile-debugging} package from |
629 | @uref{http://www.ossau.uklinux.net/guile}. | |
630 | ||
94a2c24a NJ |
631 | Finally, @dfn{xscheme} is similar to cmuscheme --- in that it starts up |
632 | a Scheme interaction process and sends commands to that process's | |
633 | standard input --- and to GDS --- in that it has support beyond | |
634 | cmuscheme or Quack for exploring the Scheme stack when an error has | |
635 | occurred --- but is implemented specifically for MIT/GNU Scheme. Hence | |
636 | it isn't really relevant to Guile work in Emacs, except as a reference | |
637 | for useful features that could be implemented in one of the other | |
638 | libraries mentioned here. | |
639 | ||
640 | In summary, the best current choice for working on Guile code in Emacs | |
641 | is either Quack or GDS, depending on which of these libraries' features | |
642 | you find most important. For more information on Quack, please see the | |
643 | website referenced above. GDS is documented further in the rest of this | |
644 | section. | |
01d2ee15 NJ |
645 | |
646 | @menu | |
647 | * GDS Introduction:: | |
94a2c24a | 648 | * GDS Architecture:: |
01d2ee15 | 649 | * GDS Getting Started:: |
72bcfa04 | 650 | * Working with GDS in Scheme Buffers:: |
01d2ee15 NJ |
651 | * Displaying the Scheme Stack:: |
652 | * Continuing Execution:: | |
01d2ee15 NJ |
653 | * Associating Buffers with Clients:: |
654 | * An Example GDS Session:: | |
01d2ee15 NJ |
655 | @end menu |
656 | ||
657 | ||
658 | @node GDS Introduction | |
659 | @subsection GDS Introduction | |
660 | ||
661 | GDS aims to allow you to work on Guile Scheme code in the same kind of | |
662 | way that Emacs allows you to work on Emacs Lisp code: providing easy | |
663 | access to help, evaluating arbitrary fragments of code, a nice debugging | |
94a2c24a | 664 | interface, and so on. The thinking behind the GDS library is that you |
01d2ee15 | 665 | will usually be doing one of two things. |
46f7666d NJ |
666 | |
667 | @enumerate | |
668 | @item | |
01d2ee15 NJ |
669 | Writing or editing code. The code will be in a normal Emacs Scheme mode |
670 | buffer, and GDS extends Scheme mode to add keystrokes and menu items for | |
671 | the things that are likely to be useful to you when working on code: | |
46f7666d NJ |
672 | |
673 | @itemize | |
674 | @item | |
94a2c24a NJ |
675 | completing the identifier at point, with respect to the set of variable |
676 | names that are known to the associated Guile process | |
46f7666d | 677 | @item |
94a2c24a | 678 | accessing Guile's built in ``help'' and ``apropos'' commands |
46f7666d | 679 | @item |
94a2c24a NJ |
680 | evaluating fragments of code to check what they do, with the results |
681 | popping up in a temporary Emacs window. | |
46f7666d NJ |
682 | @end itemize |
683 | ||
684 | @item | |
69986e21 NJ |
685 | Debugging a Guile Scheme program. When your program hits an error or |
686 | stops at a trap, GDS shows you the relevant code and the Scheme stack, | |
687 | and makes it easy to | |
46f7666d NJ |
688 | |
689 | @itemize | |
690 | @item | |
691 | look at the values of local variables | |
692 | @item | |
693 | see what is happening at all levels of the Scheme stack | |
694 | @item | |
695 | continue execution, either normally or step by step. | |
696 | @end itemize | |
46f7666d | 697 | |
94a2c24a NJ |
698 | The presentation makes it very easy to move up and down the stack, |
699 | showing whenever possible the source code for each frame in another | |
700 | Emacs buffer. It also provides convenient keystrokes for telling Guile | |
701 | what to do next; for example, you can select a stack frame and tell | |
702 | Guile to run until that frame completes, at which point GDS will display | |
703 | the frame's return value. | |
4f6e3015 | 704 | @end enumerate |
94a2c24a | 705 | |
94a2c24a NJ |
706 | GDS can provide these facilities for any number of Guile Scheme programs |
707 | (which we often refer to as ``clients'') at once, and these programs can | |
708 | be started either independently of GDS, including outside Emacs, or | |
709 | specifically @emph{by} GDS. | |
62ae9557 | 710 | |
94a2c24a NJ |
711 | Communication between each Guile client program and GDS uses a TCP |
712 | socket, which means that it is orthogonal to any other interfaces that | |
713 | the client program has. In particular GDS does not interfere with a | |
714 | program's standard input and output. | |
62ae9557 | 715 | |
94a2c24a NJ |
716 | |
717 | @node GDS Architecture | |
718 | @subsection GDS Architecture | |
719 | ||
720 | In order to understand the following documentation fully it will help to | |
721 | have a picture in mind of how GDS works, so we briefly describe that | |
722 | here. GDS consists of three components. | |
46f7666d | 723 | |
62ae9557 NJ |
724 | @itemize |
725 | @item | |
94a2c24a NJ |
726 | The GDS @dfn{interface} code is written in Emacs Lisp and runs inside |
727 | Emacs. This code, consisting of the installed files @file{gds.el} and | |
728 | @file{gds-server.el}, is responsible for displaying information from | |
729 | Guile in Emacs windows, and for responding to Emacs commands and | |
730 | keystrokes by sending instructions back to the Guile program being | |
24dbb5ed | 731 | worked on. |
94a2c24a NJ |
732 | |
733 | @item | |
734 | The GDS @dfn{server} code is written in Scheme and runs as an Emacs | |
735 | inferior process. It acts as a multiplexer between the (possibly | |
736 | multiple) Guile programs being debugged and the interface code running | |
737 | in Emacs. The server code is the installed file | |
738 | @file{gds-server.scm}. | |
62ae9557 NJ |
739 | |
740 | @item | |
94a2c24a NJ |
741 | The GDS @dfn{client} code is written in Scheme (installed file |
742 | @file{gds-client.scm}), and must be loaded as a module by each Guile | |
743 | program that wants to use GDS in any way. | |
62ae9557 NJ |
744 | @end itemize |
745 | ||
746 | @noindent | |
94a2c24a NJ |
747 | The following diagram shows how these components are connected to each |
748 | other. | |
62ae9557 | 749 | |
e163dd34 BG |
750 | @iftex |
751 | @center @image{gds,5in} | |
752 | @end iftex | |
753 | @ifnottex | |
94a2c24a | 754 | @example |
e163dd34 | 755 | @verbatiminclude gds.txt |
94a2c24a | 756 | @end example |
e163dd34 | 757 | @end ifnottex |
62ae9557 | 758 | |
94a2c24a NJ |
759 | @cindex TCP, use of |
760 | The data exchanged between client and server components, and between | |
761 | server and interface, is a sequence of sexps (parenthesised expressions) | |
762 | that are designed so as to be directly readable by both Scheme and Emacs | |
763 | Lisp. The use of a TCP connection means that the server and Emacs | |
24dbb5ed NJ |
764 | interface can theoretically be on a different computer from the client |
765 | programs, but in practice there are currently two problems with | |
94a2c24a NJ |
766 | this. Firstly the GDS API doesn't provide any way of specifying a |
767 | non-local server to connect to, and secondly there is no security or | |
768 | authentication mechanism in the GDS protocol. These are issues that | |
24dbb5ed | 769 | should be addressed in the future. |
62ae9557 | 770 | |
94a2c24a | 771 | |
01d2ee15 NJ |
772 | @node GDS Getting Started |
773 | @subsection Getting Started with GDS | |
62ae9557 | 774 | |
94a2c24a | 775 | To enable the use of GDS in your own Emacs sessions, simply add |
62ae9557 NJ |
776 | |
777 | @lisp | |
778 | (require 'gds) | |
779 | @end lisp | |
780 | ||
781 | @noindent | |
94a2c24a NJ |
782 | somewhere in your @file{.emacs} file. This will cause Emacs to load the |
783 | GDS Emacs Lisp code when starting up, and to start the inferior GDS | |
784 | server process so that it is ready and waiting for any Guile programs | |
785 | that want to use GDS. | |
62ae9557 | 786 | |
94a2c24a NJ |
787 | (If GDS's Scheme code is not installed in one of the locations in |
788 | Guile's load path, you may find that the server process fails to start. | |
789 | When this happens you will see an error message from Emacs: | |
62ae9557 | 790 | |
94a2c24a NJ |
791 | @lisp |
792 | error in process filter: Wrong type argument: listp, Backtrace: | |
793 | @end lisp | |
62ae9557 | 794 | |
94a2c24a NJ |
795 | @noindent |
796 | and the @code{gds-debug} buffer will contain a Scheme backtrace ending | |
797 | with the message: | |
62ae9557 | 798 | |
94a2c24a | 799 | @lisp |
24dbb5ed | 800 | no code for module (ice-9 gds-server) |
94a2c24a | 801 | @end lisp |
62ae9557 | 802 | |
94a2c24a NJ |
803 | @noindent |
804 | The solution for this is to customize the Emacs variable | |
805 | @code{gds-scheme-directory} so that it specifies where the GDS Scheme | |
806 | code is installed. Then either restart Emacs or type @kbd{M-x | |
807 | gds-run-debug-server} to try starting the GDS server process again.) | |
808 | ||
809 | For evaluations, help and completion from Scheme code buffers that you | |
810 | are working on, this is all you need. The first time you do any of | |
811 | these things, GDS will automatically start a new Guile client program as | |
812 | an Emacs subprocess. This Guile program does nothing but wait for and | |
813 | act on instructions from GDS, and we refer to it as a @dfn{utility} | |
814 | Guile client. Over time this utility client will accumulate the code | |
815 | that you ask it to evaluate, and you can also tell it to load complete | |
816 | files or modules by sending it @code{load} or @code{use-modules} | |
69986e21 | 817 | expressions. |
94a2c24a | 818 | |
24dbb5ed | 819 | When you want to use GDS to work on an independent Guile |
94a2c24a NJ |
820 | application, you need to add something to that application's Scheme code |
821 | to cause it to connect to and interact with GDS at the right times. The | |
24dbb5ed | 822 | following subsections describe the ways of doing this. |
62ae9557 | 823 | |
94a2c24a | 824 | @subsubsection Invoking GDS when an Exception Occurs |
62ae9557 | 825 | |
69986e21 | 826 | One option is to use GDS to catch and display any exceptions that |
1e1387ca NJ |
827 | are thrown by the application's code. If you already have a |
828 | @code{lazy-catch} or @code{with-throw-handler} around the area of code | |
829 | that you want to monitor, you just need to add the following to the | |
830 | handler code: | |
831 | ||
832 | @lisp | |
833 | (gds-debug-trap (throw->trap-context key args)) | |
834 | @end lisp | |
835 | ||
836 | @noindent | |
837 | where @code{key} and @code{args} are the first and rest arguments that | |
838 | Guile passes to the handler. (In other words, they assume the handler | |
839 | signature @code{(lambda (key . args) @dots{})}.) With Guile 1.8 or | |
840 | later, you can also do this with a @code{catch}, by adding this same | |
aeb9d8e0 | 841 | code to the catch's pre-unwind handler. |
1e1387ca NJ |
842 | |
843 | If you don't already have any of these, insert a whole | |
aeb9d8e0 NJ |
844 | @code{with-throw-handler} expression (or @code{lazy-catch} if your Guile |
845 | is pre-1.8) around the code of interest like this: | |
1e1387ca NJ |
846 | |
847 | @lisp | |
848 | (with-throw-handler #t | |
849 | (lambda () | |
850 | ;; Protected code here. | |
851 | ) | |
852 | (lambda (key . args) | |
853 | (gds-debug-trap (throw->trap-context key args)))) | |
854 | @end lisp | |
855 | ||
24dbb5ed | 856 | Either way, you will need to use the @code{(ice-9 gds-client)} and |
1e1387ca NJ |
857 | @code{(ice-9 debugging traps)} modules. |
858 | ||
859 | Two special cases of this are the lazy-catch that the Guile REPL code | |
860 | uses to catch exceptions in user code, and the lazy-catch inside the | |
861 | @code{stack-catch} utility procedure that is provided by the | |
862 | @code{(ice-9 stack-catch)} module. Both of these use a handler called | |
aeb9d8e0 NJ |
863 | @code{lazy-handler-dispatch} (defined in @file{boot-9.scm}), which you |
864 | can hook into such that it calls GDS to display the stack when an | |
865 | exception occurs. To do this, use the @code{on-lazy-handler-dispatch} | |
866 | procedure as follows. | |
1e1387ca | 867 | |
62ae9557 | 868 | @lisp |
94a2c24a NJ |
869 | (use-modules (ice-9 gds-client) |
870 | (ice-9 debugging traps)) | |
94a2c24a | 871 | (on-lazy-handler-dispatch gds-debug-trap) |
62ae9557 NJ |
872 | @end lisp |
873 | ||
1e1387ca NJ |
874 | @noindent |
875 | After this the program will use GDS to display the stack whenever it | |
876 | hits an exception that is protected by a @code{lazy-catch} using | |
aeb9d8e0 | 877 | @code{lazy-handler-dispatch}. |
62ae9557 NJ |
878 | |
879 | @subsubsection Accepting GDS Instructions at Any Time | |
880 | ||
69986e21 NJ |
881 | In addition to setting an exception handler as described above, a |
882 | Guile program can in principle set itself up to accept new | |
883 | instructions from GDS at any time, not just when it has stopped at an | |
884 | exception. This would allow the GDS user to evaluate code in the | |
885 | context of the running program, without having to wait for the program | |
886 | to stop first. | |
62ae9557 NJ |
887 | |
888 | @lisp | |
889 | (use-modules (ice-9 gds-client)) | |
890 | (gds-accept-input #t) | |
891 | @end lisp | |
892 | ||
893 | @code{gds-accept-input} causes the calling program to loop processing | |
894 | instructions from GDS, until GDS sends the @code{continue} instruction. | |
895 | This blocks the thread that calls it, however, so it will normally be | |
896 | more practical for the program to set up a dedicated GDS thread and call | |
897 | @code{gds-accept-input} from that thread. | |
898 | ||
899 | For @code{select}-driven applications, an alternative approach would be | |
900 | for the GDS client code to provide an API which allowed the application | |
901 | to | |
902 | ||
903 | @itemize | |
904 | @item | |
905 | discover the file descriptors (or Scheme ports) that are used for | |
906 | receiving instruction from the GDS front end, so that it could include | |
907 | these in its @code{select} call | |
908 | ||
909 | @item | |
910 | call the GDS instruction handler when @code{select} indicated data | |
911 | available for reading on those descriptors/ports. | |
912 | @end itemize | |
913 | ||
914 | @noindent | |
915 | This approach is not yet implemented, though. | |
916 | ||
917 | @subsubsection Utility Guile Implementation | |
918 | ||
24dbb5ed NJ |
919 | The ``utility'' Guile client mentioned above is a simple combination |
920 | of the mechanisms that we have just described. In fact the code for | |
921 | the utility Guile client is essentially just this: | |
62ae9557 NJ |
922 | |
923 | @lisp | |
924 | (use-modules (ice-9 gds-client)) | |
62ae9557 NJ |
925 | (named-module-use! '(guile-user) '(ice-9 session)) |
926 | (gds-accept-input #f)) | |
927 | @end lisp | |
928 | ||
69986e21 | 929 | The @code{named-module-use!} line ensures that the client can process |
1e1387ca | 930 | @code{help} and @code{apropos} expressions, to implement lookups in |
24dbb5ed NJ |
931 | Guile's online help. The @code{#f} parameter to |
932 | @code{gds-accept-input} means that the @code{continue} instruction | |
933 | will not cause the instruction loop to exit, which makes sense here | |
934 | because the utility client has nothing to do except to process GDS | |
935 | instructions. | |
936 | ||
937 | The utility client does not use @code{on-lazy-handler-dispatch} at its | |
938 | top level, because it has its own mechanism for catching and reporting | |
939 | exceptions in the code that it is asked to evaluate. This mechanism | |
940 | summarizes the exception and gives the user a button they can click to | |
941 | see the full stack, so the end result is very similar to what | |
942 | @code{on-lazy-handler-dispatch} provides. Deep inside | |
943 | @code{gds-accept-input}, in the part that handles evaluating | |
944 | expressions from Emacs, the GDS client code uses | |
945 | @code{throw->trap-context} and @code{gds-debug-trap} to implement | |
946 | this. | |
62ae9557 NJ |
947 | |
948 | ||
72bcfa04 NJ |
949 | @node Working with GDS in Scheme Buffers |
950 | @subsection Working with GDS in Scheme Buffers | |
951 | ||
952 | The following subsections describe the facilities and key sequences that | |
953 | GDS provides for working on code in @code{scheme-mode} buffers. | |
954 | ||
955 | @menu | |
956 | * Access to Guile Help and Completion:: | |
72bcfa04 NJ |
957 | * Evaluating Scheme Code:: |
958 | @end menu | |
959 | ||
960 | ||
7e5a256c | 961 | @node Access to Guile Help and Completion |
72bcfa04 | 962 | @subsubsection Access to Guile Help and Completion |
7e5a256c NJ |
963 | |
964 | The following keystrokes provide fast and convenient access to Guile's | |
965 | built in help, and to completion with respect to the set of defined and | |
72bcfa04 | 966 | accessible symbols. |
7e5a256c NJ |
967 | |
968 | @table @kbd | |
969 | @item C-h g | |
970 | @findex gds-help-symbol | |
971 | Get Guile help for a particular symbol, with the same results as if | |
972 | you had typed @code{(help SYMBOL)} into the Guile REPL | |
973 | (@code{gds-help-symbol}). The symbol to query defaults to the word at | |
974 | or before the cursor but can also be entered or edited in the | |
975 | minibuffer. The available help is popped up in a temporary Emacs | |
976 | window. | |
977 | ||
24dbb5ed | 978 | @item C-h G |
7e5a256c NJ |
979 | @findex gds-apropos |
980 | List all accessible Guile symbols matching a given regular expression, | |
981 | with the same results as if you had typed @code{(apropos REGEXP)} into | |
982 | the Guile REPL (@code{gds-apropos}). The regexp to query defaults to | |
983 | the word at or before the cursor but can also be entered or edited in | |
984 | the minibuffer. The list of matching symbols is popped up in a | |
985 | temporary Emacs window. | |
986 | ||
987 | @item M-@key{TAB} | |
988 | @findex gds-complete-symbol | |
989 | Try to complete the symbol at the cursor by matching it against the | |
990 | set of all defined and accessible bindings in the associated Guile | |
991 | process (@code{gds-complete-symbol}). If there are any extra | |
992 | characters that can be definitively added to the symbol at point, they | |
993 | are inserted. Otherwise, if there are any completions available, they | |
994 | are popped up in a temporary Emacs window, where one of them can be | |
995 | selected using either @kbd{@key{RET}} or the mouse. | |
996 | @end table | |
997 | ||
998 | ||
7e5a256c | 999 | @node Evaluating Scheme Code |
72bcfa04 | 1000 | @subsubsection Evaluating Scheme Code |
7e5a256c NJ |
1001 | |
1002 | The following keystrokes and commands provide various ways of sending | |
1003 | code to a Guile client process for evaluation. | |
1004 | ||
1005 | @table @kbd | |
1006 | @item M-C-x | |
1007 | @findex gds-eval-defun | |
1008 | Evaluate the ``top level defun'' that the cursor is in, in other words | |
1009 | the smallest balanced expression which includes the cursor and whose | |
1010 | opening parenthesis is in column 0 (@code{gds-eval-defun}). | |
1011 | ||
1012 | @item C-x C-e | |
1013 | @findex gds-eval-last-sexp | |
1014 | Evaluate the expression that ends just before the cursor | |
1015 | (@code{gds-eval-last-sexp}). This is designed so that it is easy to | |
1016 | evaluate an expression that you have just finished typing. | |
1017 | ||
1018 | @item C-c C-e | |
1019 | @findex gds-eval-expression | |
1020 | Read a Scheme expression using the minibuffer, and evaluate that | |
1021 | expression (@code{gds-eval-expression}). | |
1022 | ||
1023 | @item C-c C-r | |
1024 | @findex gds-eval-region | |
1025 | Evaluate the Scheme code in the marked region of the current buffer | |
1026 | (@code{gds-eval-region}). Note that GDS does not check whether the | |
1027 | region contains a balanced expression, or try to expand the region so | |
1028 | that it does; it uses the region exactly as it is. | |
1029 | @end table | |
1030 | ||
091baf9e NJ |
1031 | If you type @kbd{C-u} before one of these commands, GDS will |
1032 | immediately pop up a Scheme stack buffer, showing the requested | |
1033 | evaluation, so that you can single step through it. (This is achieved | |
1034 | by setting a @code{<source-trap>} trap at the start of the requested | |
1035 | evaluation; see @ref{Source Traps} for more on how those work.) The | |
1036 | Scheme stack display, and the options for continuing through the code, | |
1037 | are described in the next two sections. | |
1038 | ||
7e5a256c | 1039 | |
62ae9557 NJ |
1040 | @node Displaying the Scheme Stack |
1041 | @subsection Displaying the Scheme Stack | |
1042 | ||
69986e21 NJ |
1043 | When you specify @code{gds-debug-trap} as the behaviour for a trap and |
1044 | the Guile program concerned hits that trap, GDS displays the stack and | |
1045 | the relevant Scheme source code in Emacs, allowing you to explore the | |
1046 | state of the program and then decide what to do next. The same | |
1047 | applies if the program calls @code{(on-lazy-handler-dispatch | |
1048 | gds-debug-trap)} and then throws an exception that passes through | |
1049 | @code{lazy-handler-dispatch}, except that in this case you can only | |
1050 | explore; it isn't possible to continue normal execution after an | |
1051 | exception. | |
62ae9557 NJ |
1052 | |
1053 | The following commands are available in the stack buffer for exploring | |
1054 | the state of the program. | |
1055 | ||
1056 | @table @asis | |
1057 | @item @kbd{u}, @kbd{C-p}, @kbd{@key{up}} | |
1058 | @findex gds-up | |
1059 | Select the stack frame one up from the currently selected frame | |
1060 | (@code{gds-up}). GDS displays stack frames with the innermost at the | |
1061 | top, so moving ``up'' means selecting a more ``inner'' frame. | |
1062 | ||
1063 | @item @kbd{d}, @kbd{C-n}, @kbd{@key{down}} | |
1064 | @findex gds-down | |
1065 | Select the stack frame one down from the currently selected frame | |
1066 | (@code{gds-down}). GDS displays stack frames with the innermost at the | |
1067 | top, so moving ``down'' means selecting a more ``outer'' frame. | |
1068 | ||
1069 | @item @kbd{@key{RET}} | |
1070 | @findex gds-select-stack-frame | |
1071 | Select the stack frame at point (@code{gds-select-stack-frame}). This | |
1072 | is useful after clicking somewhere in the stack trace with the mouse. | |
1073 | @end table | |
1074 | ||
1075 | Selecting a frame means that GDS will display the source code | |
1076 | corresponding to that frame in the adjacent window, and that | |
1077 | subsequent frame-sensitive commands, such as @code{gds-evaluate} (see | |
1078 | below) and @code{gds-step-over} (@pxref{Continuing Execution}), will | |
1079 | refer to that frame. | |
1080 | ||
1081 | @table @kbd | |
1082 | @item e | |
1083 | @findex gds-evaluate | |
1084 | Evaluate a variable or expression in the local environment of the | |
1085 | selected stack frame (@code{gds-evaluate}). The result is displayed in | |
1086 | the echo area. | |
1087 | ||
1088 | @item I | |
1089 | @findex gds-frame-info | |
1090 | Show summary information about the selected stack frame | |
1091 | (@code{gds-frame-info}). This includes what type of frame it is, the | |
1092 | associated expression, and the frame's source location, if any. | |
1093 | ||
1094 | @item A | |
1095 | @findex gds-frame-args | |
1096 | For an application frame, display the frame's arguments | |
1097 | (@code{gds-frame-args}). | |
1098 | ||
1099 | @item S | |
1100 | @findex gds-proc-source | |
1101 | For an application frame, show the Scheme source code of the procedure | |
1102 | being called (@code{gds-proc-source}). The source code (where | |
1103 | available) is displayed in the echo area. | |
1104 | @end table | |
1105 | ||
1106 | @kbd{S} (@code{gds-proc-source}) is useful when the procedure being | |
1107 | called was created by an anonymous @code{(lambda @dots{})} expression. | |
1108 | Such procedures appear in the stack trace as @code{<procedure #f | |
1109 | (@dots{})>}, which doesn't give you much clue as to what will happen | |
1110 | next. @kbd{S} will show you the procedure's code, which is usually | |
1111 | enough for you to identify it. | |
1112 | ||
1113 | ||
1114 | @node Continuing Execution | |
1115 | @subsection Continuing Execution | |
1116 | ||
1117 | If it makes sense to continue execution from the stack which is being | |
1118 | displayed, GDS provides the following further commands in the stack | |
1119 | buffer. | |
1120 | ||
1121 | @table @asis | |
1122 | @item @kbd{g}, @kbd{c}, @kbd{q} | |
1123 | @findex gds-go | |
1124 | Tell the program to continue running (@code{gds-go}). It may of course | |
1125 | stop again if it hits another trap, or another occurrence of the same | |
1126 | trap. | |
1127 | ||
1128 | The multiple keystrokes reflect that you can think of this as ``going'', | |
1129 | ``continuing'' or ``quitting'' (in the sense of quitting the GDS | |
1130 | display). | |
1131 | ||
1132 | @item @kbd{@key{SPC}} | |
1133 | @findex gds-step-file | |
1134 | Tell the program to do a single-step to the next entry or exit of a | |
1135 | frame whose code comes from the same source file as the selected stack | |
1136 | frame (@code{gds-step-file}). | |
1137 | ||
1138 | In other words, you can hit @kbd{@key{SPC}} repeatedly to step through | |
1139 | the code in a given file, automatically stepping @emph{over} any | |
1140 | evaluations or procedure calls that use code from other files (or from | |
1141 | no file). | |
1142 | ||
1143 | If the selected stack frame has no source, the effect of this command is | |
1144 | the same as that of @kbd{i}, described next. | |
1145 | ||
1146 | @item @kbd{i} | |
1147 | @findex gds-step-into | |
1148 | Tell the debugged program to do a single-step to the next frame entry or | |
1149 | exit of any kind (@code{gds-step-into}). @kbd{i} therefore steps | |
1150 | through code at the most detailed level possible. | |
1151 | ||
1152 | @item @kbd{o} | |
1153 | @findex gds-step-over | |
1154 | Tell the debugged program to continue running until the selected stack | |
1155 | frame completes, and then to display its result (@code{gds-step-over}). | |
1156 | Note that the program may stop before then if it hits another trap; in | |
1157 | this case the trap telling it to stop when the marked frame completes | |
1158 | remains in place and so will still fire at the appropriate point. | |
1159 | @end table | |
1160 | ||
1161 | ||
62ae9557 NJ |
1162 | @node Associating Buffers with Clients |
1163 | @subsection Associating Buffers with Clients | |
1164 | ||
1165 | The first time that you use one of GDS's evaluation, help or completion | |
1166 | commands from a given Scheme mode buffer, GDS will ask which Guile | |
1167 | client program you want to use for the operation, or if you want to | |
1168 | start up a new ``utility'' client. After that GDS considers the buffer | |
1169 | to be ``associated'' with the selected client, and so sends all further | |
1170 | requests to that client, but you can override this by explicitly | |
1171 | associating the buffer with a different client, or by removing the | |
1172 | default association. | |
1173 | ||
1174 | @table @kbd | |
1175 | @item M-x gds-associate-buffer | |
1176 | Associate (or re-associate) the current buffer with a particular Guile | |
1177 | client program. The available clients are listed, and you can also | |
1178 | choose to start up a new ``utility'' client for this buffer to associate | |
1179 | with. | |
1180 | ||
1181 | @item M-x gds-dissociate-buffer | |
1182 | Dissociate the current buffer from its client, if any. This means that | |
1183 | the next time you use an evaluation, help or completion command, GDS | |
1184 | will ask you again which client to send the request to. | |
1185 | @end table | |
1186 | ||
1187 | When a buffer is associated with a client program, the buffer's modeline | |
1188 | shows whether the client is currently able to accept instruction from | |
1189 | GDS. This is done by adding one of the following suffixes to the | |
1190 | ``Scheme'' major mode indicator: | |
1191 | ||
1192 | @table @asis | |
1193 | @item :ready | |
1194 | The client program (or one of its threads, if multithreaded) is | |
1195 | currently ready to accept instruction from GDS. In other words, if you | |
1196 | send it a help or evaluation request, you should see the result pretty | |
1197 | much immediately. | |
1198 | ||
1199 | @item :running | |
1200 | The client program is not currently able to accept instruction from | |
1201 | GDS. This means that it (or all of its threads, if multithreaded) is | |
1202 | busy, or waiting for input other than from GDS. | |
1203 | ||
1204 | @item :debug | |
1205 | The client program (or one of its threads, if multithreaded) is stopped | |
1206 | in ``debugging mode'' with GDS displaying the stack for a trap or | |
1207 | exception. It is waiting for instruction from GDS on what to do next. | |
1208 | @end table | |
1209 | ||
1210 | ||
1211 | @node An Example GDS Session | |
1212 | @subsection An Example GDS Session | |
1213 | ||
1214 | Create a file, @file{testgds.scm} say, for experimenting with GDS and | |
1215 | Scheme code, and type this into it: | |
1216 | ||
1217 | @lisp | |
1218 | (use-modules (ice-9 debugging traps) | |
1219 | (ice-9 gds-client) | |
1220 | (ice-9 debugging example-fns)) | |
1221 | (install-trap (make <procedure-trap> | |
1222 | #:behaviour gds-debug-trap | |
1223 | #:procedure fact1)) | |
1224 | @end lisp | |
1225 | ||
1226 | @noindent | |
1227 | Now select all of this code and type @kbd{C-c C-r} to send the selected | |
1228 | region to Guile for evaluation. GDS will ask you which Guile process to | |
1229 | use; unless you know that you already have another Guile application | |
1230 | running and connected to GDS, choose the ``Start a new Guile'' option, | |
94a2c24a NJ |
1231 | which starts one of the ``utility'' processes described in @ref{GDS |
1232 | Getting Started}. | |
62ae9557 NJ |
1233 | |
1234 | The results of the evaluation pop up in a window like this: | |
1235 | ||
1236 | @lisp | |
1237 | (use-modules (ice-9 debugging traps)\n @dots{} | |
1238 | ||
1239 | ;;; Evaluating subexpression 1 in current module (guile-user) | |
1240 | @result{} no (or unspecified) value | |
1241 | ||
1242 | ;;; Evaluating subexpression 2 in current module (guile-user) | |
1243 | @result{} no (or unspecified) value | |
1244 | ||
1245 | --:** *Guile Evaluation* (Scheme:ready)--All------------ | |
1246 | @end lisp | |
1247 | ||
1248 | @noindent | |
1249 | this tells you that the evaluation was successful but that the return | |
1250 | values were unspecified. Its effect was to load a module of example | |
1251 | functions and set a trap on one of these functions, @code{fact1}, that | |
1252 | calculates the factorial of its argument. | |
1253 | ||
1254 | If you now call @code{fact1}, you can see the trap and GDS's stack | |
1255 | display in action. To do this add | |
1256 | ||
1257 | @lisp | |
1258 | (fact1 4) | |
1259 | @end lisp | |
1260 | ||
1261 | @noindent | |
1262 | to your @file{testgds.scm} buffer and type @kbd{C-x C-e} (which | |
24dbb5ed NJ |
1263 | evaluates the expression that the cursor is just after the end of). |
1264 | The result should be that a GDS stack window like the following | |
1265 | appears: | |
62ae9557 NJ |
1266 | |
1267 | @lisp | |
1268 | Calling procedure: | |
1269 | => s [fact1 4] | |
1270 | s [primitive-eval (fact1 4)] | |
1271 | ||
1272 | ||
1273 | --:** PID 28729 (Guile-Debug)--All------------ | |
1274 | @end lisp | |
1275 | ||
24dbb5ed NJ |
1276 | This stack tells you that Guile is about to call the @code{fact1} |
1277 | procedure, with argument 4, and you can step through this call in | |
1278 | detail by pressing @kbd{i} once and then @kbd{@key{SPC}} | |
1279 | (@pxref{Continuing Execution}). | |
62ae9557 NJ |
1280 | |
1281 | (@kbd{i} is needed as the first keystroke rather than @kbd{@key{SPC}}, | |
1282 | because the aim here is to step through code in the @code{(ice-9 | |
1283 | debugging example-fns)} module, whose source file is | |
1284 | @file{@dots{}/ice-9/debugging/example-fns.scm}, but the initial | |
1285 | @code{(fact1 4)} call comes from the Guile session, whose ``source | |
1286 | file'' Guile presents as @file{standard input}. If the user starts by | |
1287 | pressing @kbd{@key{SPC}} instead of @kbd{i}, the effect is that the | |
1288 | program runs until it hits the first recursive call @code{(fact1 (- n | |
1289 | 1))}, where it stops because of the trap on @code{fact1} firing again. | |
1290 | At this point, the source file @emph{is} | |
1291 | @file{@dots{}/ice-9/debugging/example-fns.scm}, because the recursive | |
1292 | @code{(fact1 (- n 1))} call comes from code in that file, so further | |
1293 | pressing of @kbd{@key{SPC}} successfully single-steps through this | |
1294 | file.) | |
1295 | ||
1296 | ||
46f7666d NJ |
1297 | @c Local Variables: |
1298 | @c TeX-master: "guile.texi" | |
1299 | @c End: |