summaryrefslogtreecommitdiff
path: root/emacs/gds-faq.txt
blob: b60a2c9aea49b4729287d088fd22b92ef9d3d0a7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225

* Installation

** How do I install guile-debugging?

After unpacking the .tar.gz file, run the usual sequence of commands:

$ ./configure
$ make
$ sudo make install

Then you need to make sure that the directory where guile-debugging's
Scheme files were installed is included in your Guile's load path.
(The sequence above will usually install guile-debugging under
/usr/local, and /usr/local is not in Guile's load path by default,
unless Guile itself was installed under /usr/local.)  You can discover
your Guile's default load path by typing

$ guile -q -c '(begin (write %load-path) (newline))'

There are two ways to add guile-debugging's installation directory to
Guile's load path, if it isn't already there.

1. Edit or create the `init.scm' file, which Guile reads on startup,
   so that it includes a line like this:

   (set! %load-path (cons "/usr/local/share/guile" %load-path))

   but with "/usr/local" replaced by the prefix that you installed
   guile-debugging under, if not /usr/local.

   The init.scm file must be installed (if it does not already exist
   there) in one of the directories in Guile's default load-path.

2. Add this line to your .emacs file:

   (setq gds-scheme-directory "/usr/local/share/guile")

   before the `require' or `load' line that loads GDS, but with
   "/usr/local" replaced by the prefix that you installed
   guile-debugging under, if not /usr/local.

Finally, if you want guile-debugging's GDS interface to be loaded
automatically whenever you run Emacs, add this line to your .emacs:

(require 'gds)

* Troubleshooting

** "error in process filter" when starting Emacs (or loading GDS)

This is caused by an internal error in GDS's Scheme code, for which a
backtrace will have appeared in the gds-debug buffer, so please switch
to the gds-debug buffer and see what it says there.

The most common cause is a load path problem: Guile cannot find GDS's
Scheme code because it is not in the known load path.  In this case
you should see the error message "no code for module" somewhere in the
backtrace.  If you see this, please try the remedies described in `How
do I install guile-debugging?' above, then restart Emacs and see if
the problem has been cured.

If you don't see "no code for module", or if the described remedies
don't fix the problem, please send the contents of the gds-debug
buffer to me at <neil@ossau.uklinux.net>, so I can debug the problem.

If you don't see a backtrace at all in the gds-debug buffer, try the
next item ...

** "error in process filter" at some other time

This is caused by an internal error somewhere in GDS's Emacs Lisp
code.  If possible, please

- switch on the `debug-on-error' option (M-x set-variable RET
  debug-on-error RET t RET)

- do whatever you were doing so that the same error happens again

- send the Emacs Lisp stack trace which pops up to me at
  <neil@ossau.uklinux.net>.

If that doesn't work, please just mail me with as much detail as
possible of what you were doing when the error occurred.

* GDS Features

** How do I inspect variable values?

Type `e' followed by the name of the variable, then <RET>.  This
works whenever GDS is displaying a stack for an error at at a
breakpoint.  (You can actually `e' to evaluate any expression in the
local environment of the selected stack frame; inspecting variables is
the special case of this where the expression is only a variable name.)

If GDS is displaying the associated source code in the window above or
below the stack, you can see the values of any variables in the
highlighted code just by hovering your mouse over them.

** How do I change a variable's value?

Type `e' and then `(set! VARNAME NEWVAL)', where VARNAME is the name
of the variable you want to set and NEWVAL is an expression which
Guile can evaluate to get the new value.  This works whenever GDS is
displaying a stack for an error at at a breakpoint.  The setting will
take effect in the local environment of the selected stack frame.

** How do I change the expression that Guile is about to evaluate?

Type `t' followed by the expression that you want Guile to evaluate
instead, then <RET>.

Then type one of the commands that tells Guile to continue execution.

(Tweaking expressions, as described here, is only supported by the
latest CVS version of Guile.  The GDS stack display tells you when
tweaking is possible by adding "(tweakable)" to the first line of the
stack window.)

** How do I return a value from the current stack frame different to what the evaluator has calculated?

You have to be at the normal exit of the relevant frame first, so if
GDS is not already showing you the normally calculated return value,
type `o' to finish the evaluation of the selected frame.

Then type `t' followed by the value you want to return, and <RET>.
The value that you type can be any expression, but note that it will
not be evaluated before being returned; for example if you type `(+ 2
3)', the return value will be a three-element list, not 5.

Finally type one of the commands that tells Guile to continue
execution.

(Tweaking return values, as described here, is only supported by the
latest CVS version of Guile.  The GDS stack display tells you when
tweaking is possible by adding "(tweakable)" to the first line of the
stack window.)

** How do I step over a line of code?

Scheme isn't organized by lines, so it doesn't really make sense to
think of stepping over lines.  Instead please see the next entry on
stepping over expressions.

** How do I step over an expression?

It depends what you mean by "step over".  If you mean that you want
Guile to evaluate that expression normally, but then show you its
return value, type `o', which does exactly that.

If you mean that you want to skip the evaluation of that expression
(for example because it has side effects that you don't want to
happen), use `t' to change the expression to something else which
Guile will evaluate instead.

There has to be a substitute expression so Guile can calculate a value
to return to the calling frame.  If you know at a particular point
that the return value is not important, you can type `t #f <RET>' or
`t 0 <RET>'.

See `How do I change the expression that Guile is about to evaluate?'
above for more on using `t'.

** How do I move up and down the call stack?

Type `u' to move up and `d' to move down.  "Up" in GDS means to a more
"inner" frame, and "down" means to a more "outer" frame.

** How do I run until the next breakpoint?

Type `g' (for "go").

** How do I run until the end of the selected stack frame?

Type `o'.

** How do I set a breakpoint?

First identify the code that you want to set the breakpoint in, and
what kind of breakpoint you want.  To set a breakpoint on entry to a
top level procedure, move the cursor to anywhere in the procedure
definition, and make sure that the region/mark is inactive.  To set a
breakpoint on a particular expression (or sequence of expressions) set
point and mark so that the region covers the opening parentheses of
all the target expressions.

Then type ...

  `C-c C-b d' for a `debug' breakpoint, which means that GDS will
  display the stack when the breakpoint is hit

  `C-c C-b t' for a `trace' breakpoint, which means that the start and
  end of the relevant procedure or expression(s) will be traced to the
  *GDS Trace* buffer

  `C-c C-b T' for a `trace-subtree' breakpoint, which means that every
  evaluation step involved in the evaluation of the relevant procedure
  or expression(s) will be traced to the *GDS Trace* buffer.

You can also type `C-x <SPC>', which does the same as one of the
above, depending on the value of `gds-default-breakpoint-type'.

** How do I clear a breakpoint?

Select a region containing the breakpoints that you want to clear, and
type `C-c C-b <DEL>'.

** How do I trace calls to a particular procedure or evaluations of a particular expression?

In GDS this means setting a breakpoint whose type is `trace' or
`trace-subtree'.  See `How do I set a breakpoint?' above.

* Development

** How can I follow or contribute to guile-debugging's development?

guile-debugging is hosted at http://gna.org, so please see the project
page there.  Feel free to raise bugs, tasks containing patches or
feature requests, and so on.  You can also write directly to me by
email: <neil@ossau.uklinux.net>.


Local Variables:
mode: outline
End: