Commit | Line | Data |
---|---|---|
46f7666d NJ |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Guile Reference Manual. | |
3 | @c Copyright (C) 2006 | |
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 | |
17 | guile> (+ 3 4 5) | |
18 | 12 | |
19 | guile> (display "Hello world!\n") | |
20 | Hello world! | |
21 | guile> (values 'a 'b) | |
22 | a | |
23 | b | |
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 | ||
32 | @menu | |
33 | * Readline:: | |
34 | * Value Historyx:: | |
35 | * Error Handling:: | |
36 | * Interactive Debugger:: Using the interactive debugger. | |
37 | @end menu | |
38 | ||
39 | ||
40 | @node Readline | |
41 | @subsection Readline | |
42 | ||
43 | To make it easier for you to repeat and vary previously entered | |
44 | expressions, or to edit the expression that you're typing in, Guile | |
45 | can use the GNU Readline library. This is not enabled by default | |
46 | because of licensing reasons, but all you need to activate Readline is | |
47 | the following pair of lines. | |
48 | ||
49 | @lisp | |
50 | guile> (use-modules (ice-9 readline)) | |
51 | guile> (activate-readline) | |
52 | @end lisp | |
53 | ||
54 | It's a good idea to put these two lines (without the ``guile>'' | |
55 | prompts) in your @file{.guile} file. Guile reads this file when it | |
56 | starts up interactively, so anything in this file has the same effect | |
57 | as if you type it in by hand at the ``guile>'' prompt. | |
58 | ||
59 | ||
60 | @node Value Historyx | |
61 | @subsection Value History | |
62 | ||
63 | Just as Readline helps you to reuse a previous input line, @dfn{value | |
64 | history} allows you to use the @emph{result} of a previous evaluation | |
65 | in a new expression. When value history is enabled, each evaluation | |
66 | result is automatically assigned to the next in the sequence of | |
67 | variables @code{$1}, @code{$2}, @dots{}, and you can then use these | |
68 | variables in subsequent expressions. | |
69 | ||
70 | @lisp | |
71 | guile> (iota 10) | |
72 | $1 = (0 1 2 3 4 5 6 7 8 9) | |
73 | guile> (apply * (cdr $1)) | |
74 | $2 = 362880 | |
75 | guile> (sqrt $2) | |
76 | $3 = 602.3952191045344 | |
77 | guile> (cons $2 $1) | |
78 | $4 = (362880 0 1 2 3 4 5 6 7 8 9) | |
79 | @end lisp | |
80 | ||
81 | To enable value history, type @code{(use-modules (ice-9 history))} at | |
82 | the Guile prompt, or add this to your @file{.guile} file. (It is not | |
83 | enabled by default, to avoid the possibility of conflicting with some | |
84 | other use you may have for the variables @code{$1}, @code{$2}, | |
85 | @dots{}, and also because it prevents the stored evaluation results | |
86 | from being garbage collected, which some people may not want.) | |
87 | ||
88 | ||
89 | @node Error Handling | |
90 | @subsection Error Handling | |
91 | ||
92 | When code being evaluated from the REPL hits an error, Guile remembers | |
93 | the execution context where the error occurred and can give you three | |
94 | levels of information about what the error was and exactly where it | |
95 | occurred. | |
96 | ||
97 | By default, Guile then displays only the first level, which is the most | |
98 | immediate information about where and why the error occurred, for | |
99 | example: | |
100 | ||
101 | @lisp | |
102 | (make-string (* 4 (+ 3 #\s)) #\space) | |
103 | @print{} | |
104 | standard input:2:19: In procedure + in expression (+ 3 #\s): | |
105 | standard input:2:19: Wrong type argument: #\s | |
106 | ABORT: (wrong-type-arg) | |
107 | ||
108 | Type "(backtrace)" to get more information or "(debug)" to enter the debugger. | |
109 | @end lisp | |
110 | ||
111 | @noindent | |
112 | However, as the message above says, you can obtain more information | |
113 | about the context of the error by typing @code{(backtrace)} or | |
114 | @code{(debug)}. | |
115 | ||
116 | @code{(backtrace)} displays the Scheme call stack at the point where the | |
117 | error occurred: | |
118 | ||
119 | @lisp | |
120 | (backtrace) | |
121 | @print{} | |
122 | Backtrace: | |
123 | In standard input: | |
124 | 2: 0* [make-string ... | |
125 | 2: 1* [* 4 ... | |
126 | 2: 2* [+ 3 #\s] | |
127 | ||
128 | Type "(debug-enable 'backtrace)" if you would like a backtrace | |
129 | automatically if an error occurs in the future. | |
130 | @end lisp | |
131 | ||
132 | @noindent | |
133 | In a more complex scenario than this one, this can be extremely useful | |
134 | for understanding where and why the error occurred. You can make Guile | |
135 | show the backtrace automatically by adding @code{(debug-enable | |
136 | 'backtrace)} to your @file{.guile}. | |
137 | ||
138 | @code{(debug)} takes you into Guile's interactive debugger, which | |
139 | provides commands that allow you to | |
140 | ||
141 | @itemize @bullet | |
142 | @item | |
143 | display the Scheme call stack at the point where the error occurred | |
144 | (the @code{backtrace} command --- see @ref{Display Backtrace}) | |
145 | ||
146 | @item | |
147 | move up and down the call stack, to see in detail the expression being | |
148 | evaluated, or the procedure being applied, in each @dfn{frame} (the | |
149 | @code{up}, @code{down}, @code{frame}, @code{position}, @code{info args} | |
150 | and @code{info frame} commands --- see @ref{Frame Selection} and | |
151 | @ref{Frame Information}) | |
152 | ||
153 | @item | |
154 | examine the values of variables and expressions in the context of each | |
155 | frame (the @code{evaluate} command --- see @ref{Frame Evaluation}). | |
156 | @end itemize | |
157 | ||
158 | @noindent | |
159 | This is documented further in the following section. | |
160 | ||
161 | ||
162 | @node Interactive Debugger | |
163 | @subsection Using the Interactive Debugger | |
164 | ||
165 | Guile's interactive debugger is a command line application that accepts | |
166 | commands from you for examining the stack and, if at a breakpoint, for | |
167 | continuing program execution in various ways. Unlike in the normal | |
168 | Guile REPL, commands are typed mostly without parentheses. | |
169 | ||
170 | When you first enter the debugger, it introduces itself with a message | |
171 | like this: | |
172 | ||
173 | @lisp | |
174 | This is the Guile debugger -- for help, type `help'. | |
175 | There are 3 frames on the stack. | |
176 | ||
177 | Frame 2 at standard input:36:19 | |
178 | [+ 3 #\s] | |
179 | debug> | |
180 | @end lisp | |
181 | ||
182 | @noindent | |
183 | ``debug>'' is the debugger's prompt, and a reminder that you are not in | |
184 | the normal Guile REPL. The available commands are described in the | |
185 | following subsections. | |
186 | ||
187 | @menu | |
188 | * Display Backtrace:: backtrace. | |
189 | * Frame Selection:: up, down, frame. | |
190 | * Frame Information:: info args, info frame, position. | |
191 | * Frame Evaluation:: evaluate. | |
192 | * Single Stepping:: step, next. | |
193 | * Run To Frame Exit:: finish, trace-finish. | |
194 | * Continue Execution:: continue. | |
195 | * Leave Debugger:: quit. | |
196 | @end menu | |
197 | ||
198 | ||
199 | @node Display Backtrace | |
200 | @subsubsection Display Backtrace | |
201 | ||
202 | The @code{backtrace} command, which can also be invoked as @code{bt} or | |
203 | @code{where}, displays the call stack (aka backtrace) at the point where | |
204 | the debugger was entered: | |
205 | ||
206 | @lisp | |
207 | debug> bt | |
208 | In standard input: | |
209 | 36: 0* [make-string ... | |
210 | 36: 1* [* 4 ... | |
211 | 36: 2* [+ 3 #\s] | |
212 | @end lisp | |
213 | ||
214 | @deffn {Debugger Command} backtrace [count] | |
215 | @deffnx {Debugger Command} bt [count] | |
216 | @deffnx {Debugger Command} where [count] | |
217 | Print backtrace of all stack frames, or of the innermost @var{count} | |
218 | frames. With a negative argument, print the outermost -@var{count} | |
219 | frames. If the number of frames isn't explicitly given, the debug | |
220 | option @code{depth} determines the maximum number of frames printed. | |
221 | @end deffn | |
222 | ||
223 | The format of the displayed backtrace is the same as for the | |
224 | @code{backtrace} procedure. | |
225 | ||
226 | ||
227 | @node Frame Selection | |
228 | @subsubsection Frame Selection | |
229 | ||
230 | A call stack consists of a sequence of stack @dfn{frames}, with each | |
231 | frame describing one level of the nested evaluations and applications | |
232 | that the program was executing when it hit a breakpoint or an error. | |
233 | Frames are numbered such that frame 0 is the outermost --- i.e. the | |
234 | operation on the call stack that began least recently --- and frame N-1 | |
235 | the innermost (where N is the total number of frames on the stack). | |
236 | ||
237 | When you enter the debugger, the innermost frame is selected, which | |
238 | means that the commands for getting information about the ``current'' | |
239 | frame, or for evaluating expressions in the context of the current | |
240 | frame, will do so by default with respect to the innermost frame. To | |
241 | select a different frame, so that these operations will apply to it | |
242 | instead, use the @code{up}, @code{down} and @code{frame} commands like | |
243 | this: | |
244 | ||
245 | @lisp | |
246 | debug> up | |
247 | Frame 1 at standard input:36:14 | |
248 | [* 4 ... | |
249 | debug> frame 0 | |
250 | Frame 0 at standard input:36:1 | |
251 | [make-string ... | |
252 | debug> down | |
253 | Frame 1 at standard input:36:14 | |
254 | [* 4 ... | |
255 | @end lisp | |
256 | ||
257 | @deffn {Debugger Command} up [n] | |
258 | Move @var{n} frames up the stack. For positive @var{n}, this | |
259 | advances toward the outermost frame, to higher frame numbers, to | |
260 | frames that have existed longer. @var{n} defaults to one. | |
261 | @end deffn | |
262 | ||
263 | @deffn {Debugger Command} down [n] | |
264 | Move @var{n} frames down the stack. For positive @var{n}, this | |
265 | advances toward the innermost frame, to lower frame numbers, to frames | |
266 | that were created more recently. @var{n} defaults to one. | |
267 | @end deffn | |
268 | ||
269 | @deffn {Debugger Command} frame [n] | |
270 | Select and print a stack frame. With no argument, print the selected | |
271 | stack frame. (See also ``info frame''.) An argument specifies the | |
272 | frame to select; it must be a stack-frame number. | |
273 | @end deffn | |
274 | ||
275 | ||
276 | @node Frame Information | |
277 | @subsubsection Frame Information | |
278 | ||
279 | [to be completed] | |
280 | ||
281 | @deffn {Debugger Command} {info frame} | |
282 | All about selected stack frame. | |
283 | @end deffn | |
284 | ||
285 | @deffn {Debugger Command} {info args} | |
286 | Argument variables of current stack frame. | |
287 | @end deffn | |
288 | ||
289 | @deffn {Debugger Command} position | |
290 | Display the position of the current expression. | |
291 | @end deffn | |
292 | ||
293 | ||
294 | @node Frame Evaluation | |
295 | @subsubsection Frame Evaluation | |
296 | ||
297 | [to be completed] | |
298 | ||
299 | @deffn {Debugger Command} evaluate expression | |
300 | Evaluate an expression. | |
301 | The expression must appear on the same line as the command, | |
302 | however it may be continued over multiple lines. | |
303 | @end deffn | |
304 | ||
305 | ||
306 | @node Single Stepping | |
307 | @subsubsection Single Stepping | |
308 | ||
309 | [to be completed] | |
310 | ||
311 | @deffn {Debugger Command} step [n] | |
312 | Continue until entry to @var{n}th next frame. | |
313 | @end deffn | |
314 | ||
315 | @deffn {Debugger Command} next [n] | |
316 | Continue until entry to @var{n}th next frame in same file. | |
317 | @end deffn | |
318 | ||
319 | ||
320 | @node Run To Frame Exit | |
321 | @subsubsection Run To Frame Exit | |
322 | ||
323 | [to be completed] | |
324 | ||
325 | @deffn {Debugger Command} finish | |
326 | Continue until evaluation of the current frame is complete, and | |
327 | print the result obtained. | |
328 | @end deffn | |
329 | ||
330 | @deffn {Debugger Command} trace-finish | |
331 | Trace until evaluation of the current frame is complete. | |
332 | @end deffn | |
333 | ||
334 | ||
335 | @node Continue Execution | |
336 | @subsubsection Continue Execution | |
337 | ||
338 | [to be completed] | |
339 | ||
340 | @deffn {Debugger Command} continue | |
341 | Continue program execution. | |
342 | @end deffn | |
343 | ||
344 | ||
345 | @node Leave Debugger | |
346 | @subsubsection Leave Debugger | |
347 | ||
348 | [to be completed] | |
349 | ||
350 | @deffn {Debugger Command} quit | |
351 | Exit the debugger. | |
352 | @end deffn | |
353 | ||
354 | ||
355 | @node Using Guile in Emacs | |
356 | @section Using Guile in Emacs | |
357 | ||
358 | The Guile distribution includes a rich environment for working on Guile | |
359 | Scheme code within Emacs. The idea of this environment is to allow you | |
360 | to work on Guile Scheme code in the same kind of way that Emacs allows | |
361 | you to work on Emacs Lisp code: providing easy access to help, | |
362 | evaluating arbitrary fragments of code, a nice debugging interface, and | |
363 | so on.@footnote{You can also, of course, run a Guile session in Emacs | |
364 | simply by typing ``guile'' in a @code{*shell*} buffer. The environment | |
365 | described here provides a much better integration than that, though.} | |
366 | ||
367 | The thinking behind this environment is that you will usually be doing | |
368 | one of two things. | |
369 | ||
370 | @enumerate | |
371 | @item | |
372 | Writing or editing code. The code will be in a normal Emacs Scheme | |
373 | mode buffer, and the Guile/Emacs environment extends Scheme mode to | |
374 | add keystrokes and menu items for the things that are likely to be | |
375 | useful to you when working on code: | |
376 | ||
377 | @itemize | |
378 | @item | |
379 | completing the identifier at point | |
380 | @item | |
381 | accessing Guile's built in help | |
382 | @item | |
383 | evaluating fragments of code to check what they do. | |
384 | @end itemize | |
385 | ||
386 | @item | |
387 | Debugging a Guile Scheme program. When your program hits an error or | |
388 | a breakpoint, the Guile/Emacs environment shows you the relevant code | |
389 | and the Scheme stack, and makes it easy to | |
390 | ||
391 | @itemize | |
392 | @item | |
393 | look at the values of local variables | |
394 | @item | |
395 | see what is happening at all levels of the Scheme stack | |
396 | @item | |
397 | continue execution, either normally or step by step. | |
398 | @end itemize | |
399 | @end enumerate | |
400 | ||
401 | Combinations of these work well too. You can evaluate a fragment of | |
402 | code (in a Scheme buffer) that contains a breakpoint, then use the | |
403 | debugging interface to step through the code at the breakpoint. You | |
404 | can also run a program until it hits a breakpoint, then examine, | |
405 | modify and reevaluate some of the relevant code, and then tell the | |
406 | program to continue running. | |
407 | ||
408 | ||
409 | @c Local Variables: | |
410 | @c TeX-master: "guile.texi" | |
411 | @c End: |