428
|
1 @c -*-texinfo-*-
|
|
2 @c This is part of the XEmacs Lisp Reference Manual.
|
444
|
3 @c Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
|
428
|
4 @c See the file lispref.texi for copying conditions.
|
|
5 @setfilename ../../info/building.info
|
|
6 @node Building XEmacs and Object Allocation, Standard Errors, Tips, Top
|
|
7 @appendix Building XEmacs; Allocation of Objects
|
|
8
|
|
9 This chapter describes how the runnable XEmacs executable is dumped
|
|
10 with the preloaded Lisp libraries in it and how storage is allocated.
|
|
11
|
|
12 There is an entire separate document, the @cite{XEmacs Internals
|
|
13 Manual}, devoted to the internals of XEmacs from the perspective of the
|
|
14 C programmer. It contains much more detailed information about the
|
|
15 build process, the allocation and garbage-collection process, and other
|
|
16 aspects related to the internals of XEmacs.
|
|
17
|
|
18 @menu
|
|
19 * Building XEmacs:: How to preload Lisp libraries into XEmacs.
|
|
20 * Pure Storage:: A kludge to make preloaded Lisp functions sharable.
|
|
21 * Garbage Collection:: Reclaiming space for Lisp objects no longer used.
|
|
22 @end menu
|
|
23
|
|
24 @node Building XEmacs
|
|
25 @appendixsec Building XEmacs
|
|
26 @cindex building XEmacs
|
|
27 @pindex temacs
|
|
28
|
|
29 This section explains the steps involved in building the XEmacs
|
|
30 executable. You don't have to know this material to build and install
|
|
31 XEmacs, since the makefiles do all these things automatically. This
|
|
32 information is pertinent to XEmacs maintenance.
|
|
33
|
|
34 The @cite{XEmacs Internals Manual} contains more information about this.
|
|
35
|
|
36 Compilation of the C source files in the @file{src} directory
|
|
37 produces an executable file called @file{temacs}, also called a
|
|
38 @dfn{bare impure XEmacs}. It contains the XEmacs Lisp interpreter and I/O
|
|
39 routines, but not the editing commands.
|
|
40
|
|
41 @cindex @file{loadup.el}
|
|
42 Before XEmacs is actually usable, a number of Lisp files need to be
|
|
43 loaded. These define all the editing commands, plus most of the startup
|
|
44 code and many very basic Lisp primitives. This is accomplished by
|
|
45 loading the file @file{loadup.el}, which in turn loads all of the other
|
|
46 standardly-loaded Lisp files.
|
|
47
|
|
48 It takes a substantial time to load the standard Lisp files. Luckily,
|
|
49 you don't have to do this each time you run XEmacs; @file{temacs} can
|
|
50 dump out an executable program called @file{xemacs} that has these files
|
|
51 preloaded. @file{xemacs} starts more quickly because it does not need to
|
|
52 load the files. This is the XEmacs executable that is normally
|
|
53 installed.
|
|
54
|
|
55 To create @file{xemacs}, use the command @samp{temacs -batch -l loadup
|
|
56 dump}. The purpose of @samp{-batch} here is to tell @file{temacs} to run
|
|
57 in non-interactive, command-line mode. (@file{temacs} can @emph{only} run
|
|
58 in this fashion. Part of the code required to initialize frames and faces
|
|
59 is in Lisp, and must be loaded before XEmacs is able to create any frames.)
|
|
60 The argument @samp{dump} tells @file{loadup.el} to dump a new executable
|
|
61 named @file{xemacs}.
|
|
62
|
|
63 The dumping process is highly system-specific, and some operating
|
|
64 systems don't support dumping. On those systems, you must start XEmacs
|
|
65 with the @samp{temacs -batch -l loadup run-temacs} command each time you
|
|
66 use it. This takes a substantial time, but since you need to start
|
|
67 Emacs once a day at most---or once a week if you never log out---the
|
|
68 extra time is not too severe a problem. (In older versions of Emacs,
|
|
69 you started Emacs from @file{temacs} using @samp{temacs -l loadup}.)
|
|
70
|
|
71 @cindex runnable @file{temacs}
|
|
72 @cindex bootstrapping XEmacs from @file{temacs}
|
|
73 You are free to start XEmacs directly from @file{temacs} if you want,
|
|
74 even if there is already a dumped @file{xemacs}. Normally you wouldn't
|
|
75 want to do that; but the Makefiles do this when you rebuild XEmacs using
|
|
76 @samp{make all-elc}, which builds XEmacs and simultaneously compiles any
|
|
77 out-of-date Lisp files. (You need @file{xemacs} in order to compile Lisp
|
|
78 files. However, you also need the compiled Lisp files in order to dump
|
|
79 out @file{xemacs}. If both of these are missing or corrupted, you are
|
|
80 out of luck unless you're able to bootstrap @file{xemacs} from
|
|
81 @file{temacs}. Note that @samp{make all-elc} actually loads the
|
|
82 alternative loadup file @file{loadup-el.el}, which works like
|
|
83 @file{loadup.el} but disables the pure-copying process and forces
|
|
84 XEmacs to ignore any compiled Lisp files even if they exist.)
|
|
85
|
|
86 @cindex @file{site-load.el}
|
|
87 You can specify additional files to preload by writing a library named
|
|
88 @file{site-load.el} that loads them. You may need to increase the value
|
|
89 of @code{PURESIZE}, in @file{src/puresize.h}, to make room for the
|
|
90 additional files. You should @emph{not} modify this file directly,
|
|
91 however; instead, use the @samp{--puresize} configuration option. (If
|
|
92 you run out of pure space while dumping @file{xemacs}, you will be told
|
|
93 how much pure space you actually will need.) However, the advantage of
|
|
94 preloading additional files decreases as machines get faster. On modern
|
|
95 machines, it is often not advisable, especially if the Lisp code is
|
|
96 on a file system local to the machine running XEmacs.
|
|
97
|
|
98 @cindex @file{site-init.el}
|
|
99 You can specify other Lisp expressions to execute just before dumping
|
|
100 by putting them in a library named @file{site-init.el}. However, if
|
|
101 they might alter the behavior that users expect from an ordinary
|
|
102 unmodified XEmacs, it is better to put them in @file{default.el}, so that
|
|
103 users can override them if they wish. @xref{Start-up Summary}.
|
|
104
|
|
105 Before @file{loadup.el} dumps the new executable, it finds the
|
|
106 documentation strings for primitive and preloaded functions (and
|
|
107 variables) in the file where they are stored, by calling
|
|
108 @code{Snarf-documentation} (@pxref{Accessing Documentation}). These
|
|
109 strings were moved out of the @file{xemacs} executable to make it
|
|
110 smaller. @xref{Documentation Basics}.
|
|
111
|
|
112 @defun dump-emacs to-file from-file
|
|
113 @cindex unexec
|
|
114 This function dumps the current state of XEmacs into an executable file
|
|
115 @var{to-file}. It takes symbols from @var{from-file} (this is normally
|
|
116 the executable file @file{temacs}).
|
|
117
|
|
118 If you use this function in an XEmacs that was already dumped, you must
|
|
119 set @code{command-line-processed} to @code{nil} first for good results.
|
|
120 @xref{Command Line Arguments}.
|
|
121 @end defun
|
|
122
|
|
123 @defun run-emacs-from-temacs &rest args
|
|
124 This is the function that implements the @file{run-temacs} command-line
|
|
125 argument. It is called from @file{loadup.el} as appropriate. You should
|
|
126 most emphatically @emph{not} call this yourself; it will reinitialize
|
|
127 your XEmacs process and you'll be sorry.
|
|
128 @end defun
|
|
129
|
444
|
130 @deffn Command emacs-version &optional arg
|
428
|
131 This function returns a string describing the version of XEmacs that is
|
|
132 running. It is useful to include this string in bug reports.
|
|
133
|
444
|
134 When called interactively with a prefix argument, insert string at point.
|
|
135 Don't use this function in programs to choose actions according
|
|
136 to the system configuration; look at @code{system-configuration} instead.
|
|
137
|
428
|
138 @example
|
|
139 @group
|
|
140 (emacs-version)
|
|
141 @result{} "XEmacs 20.1 [Lucid] (i586-unknown-linux2.0.29)
|
|
142 of Mon Apr 7 1997 on altair.xemacs.org"
|
|
143 @end group
|
|
144 @end example
|
|
145
|
|
146 Called interactively, the function prints the same information in the
|
|
147 echo area.
|
|
148 @end deffn
|
|
149
|
|
150 @defvar emacs-build-time
|
|
151 The value of this variable is the time at which XEmacs was built at the
|
|
152 local site.
|
|
153
|
|
154 @example
|
|
155 @group
|
|
156 emacs-build-time "Mon Apr 7 20:28:52 1997"
|
444
|
157 @result{}
|
428
|
158 @end group
|
|
159 @end example
|
|
160 @end defvar
|
|
161
|
|
162 @defvar emacs-version
|
|
163 The value of this variable is the version of Emacs being run. It is a
|
|
164 string, e.g. @code{"20.1 XEmacs Lucid"}.
|
|
165 @end defvar
|
|
166
|
|
167 The following two variables did not exist before FSF GNU Emacs version
|
|
168 19.23 and XEmacs version 19.10, which reduces their usefulness at
|
|
169 present, but we hope they will be convenient in the future.
|
|
170
|
|
171 @defvar emacs-major-version
|
|
172 The major version number of Emacs, as an integer. For XEmacs version
|
|
173 20.1, the value is 20.
|
|
174 @end defvar
|
|
175
|
|
176 @defvar emacs-minor-version
|
|
177 The minor version number of Emacs, as an integer. For XEmacs version
|
|
178 20.1, the value is 1.
|
|
179 @end defvar
|
|
180
|
|
181 @node Pure Storage
|
|
182 @appendixsec Pure Storage
|
|
183 @cindex pure storage
|
|
184
|
|
185 XEmacs Lisp uses two kinds of storage for user-created Lisp objects:
|
|
186 @dfn{normal storage} and @dfn{pure storage}. Normal storage is where
|
|
187 all the new data created during an XEmacs session is kept; see the
|
|
188 following section for information on normal storage. Pure storage is
|
|
189 used for certain data in the preloaded standard Lisp files---data that
|
|
190 should never change during actual use of XEmacs.
|
|
191
|
|
192 Pure storage is allocated only while @file{temacs} is loading the
|
|
193 standard preloaded Lisp libraries. In the file @file{xemacs}, it is
|
|
194 marked as read-only (on operating systems that permit this), so that the
|
|
195 memory space can be shared by all the XEmacs jobs running on the machine
|
|
196 at once. Pure storage is not expandable; a fixed amount is allocated
|
|
197 when XEmacs is compiled, and if that is not sufficient for the preloaded
|
|
198 libraries, @file{temacs} aborts with an error message. If that happens,
|
|
199 you must increase the compilation parameter @code{PURESIZE} using the
|
|
200 @samp{--puresize} option to @file{configure}. This normally won't
|
|
201 happen unless you try to preload additional libraries or add features to
|
|
202 the standard ones.
|
|
203
|
|
204 @defun purecopy object
|
|
205 This function makes a copy of @var{object} in pure storage and returns
|
|
206 it. It copies strings by simply making a new string with the same
|
|
207 characters in pure storage. It recursively copies the contents of
|
|
208 vectors and cons cells. It does not make copies of other objects such
|
|
209 as symbols, but just returns them unchanged. It signals an error if
|
|
210 asked to copy markers.
|
|
211
|
959
|
212 This function is a no-op in XEmacs, and its use is deprecated.
|
428
|
213 @end defun
|
|
214
|
|
215 @defvar pure-bytes-used
|
|
216 The value of this variable is the number of bytes of pure storage
|
|
217 allocated so far. Typically, in a dumped XEmacs, this number is very
|
|
218 close to the total amount of pure storage available---if it were not,
|
|
219 we would preallocate less.
|
|
220 @end defvar
|
|
221
|
|
222 @defvar purify-flag
|
|
223 This variable determines whether @code{defun} should make a copy of the
|
|
224 function definition in pure storage. If it is non-@code{nil}, then the
|
|
225 function definition is copied into pure storage.
|
|
226
|
|
227 This flag is @code{t} while loading all of the basic functions for
|
|
228 building XEmacs initially (allowing those functions to be sharable and
|
|
229 non-collectible). Dumping XEmacs as an executable always writes
|
|
230 @code{nil} in this variable, regardless of the value it actually has
|
|
231 before and after dumping.
|
|
232
|
|
233 You should not change this flag in a running XEmacs.
|
|
234 @end defvar
|
|
235
|
|
236 @node Garbage Collection
|
|
237 @appendixsec Garbage Collection
|
|
238 @cindex garbage collector
|
|
239
|
|
240 @cindex memory allocation
|
|
241 When a program creates a list or the user defines a new function (such
|
|
242 as by loading a library), that data is placed in normal storage. If
|
|
243 normal storage runs low, then XEmacs asks the operating system to
|
|
244 allocate more memory in blocks of 2k bytes. Each block is used for one
|
|
245 type of Lisp object, so symbols, cons cells, markers, etc., are
|
|
246 segregated in distinct blocks in memory. (Vectors, long strings,
|
|
247 buffers and certain other editing types, which are fairly large, are
|
|
248 allocated in individual blocks, one per object, while small strings are
|
|
249 packed into blocks of 8k bytes. [More correctly, a string is allocated
|
|
250 in two sections: a fixed size chunk containing the length, list of
|
|
251 extents, etc.; and a chunk containing the actual characters in the
|
|
252 string. It is this latter chunk that is either allocated individually
|
|
253 or packed into 8k blocks. The fixed size chunk is packed into 2k
|
|
254 blocks, as for conses, markers, etc.])
|
|
255
|
|
256 It is quite common to use some storage for a while, then release it by
|
|
257 (for example) killing a buffer or deleting the last pointer to an
|
|
258 object. XEmacs provides a @dfn{garbage collector} to reclaim this
|
|
259 abandoned storage. (This name is traditional, but ``garbage recycler''
|
|
260 might be a more intuitive metaphor for this facility.)
|
|
261
|
|
262 The garbage collector operates by finding and marking all Lisp objects
|
|
263 that are still accessible to Lisp programs. To begin with, it assumes
|
|
264 all the symbols, their values and associated function definitions, and
|
|
265 any data presently on the stack, are accessible. Any objects that can
|
|
266 be reached indirectly through other accessible objects are also
|
|
267 accessible.
|
|
268
|
|
269 When marking is finished, all objects still unmarked are garbage. No
|
|
270 matter what the Lisp program or the user does, it is impossible to refer
|
|
271 to them, since there is no longer a way to reach them. Their space
|
|
272 might as well be reused, since no one will miss them. The second
|
|
273 (``sweep'') phase of the garbage collector arranges to reuse them.
|
|
274
|
|
275 @cindex free list
|
|
276 The sweep phase puts unused cons cells onto a @dfn{free list} for
|
|
277 future allocation; likewise for symbols, markers, extents, events,
|
|
278 floats, compiled-function objects, and the fixed-size portion of
|
|
279 strings. It compacts the accessible small string-chars chunks so they
|
|
280 occupy fewer 8k blocks; then it frees the other 8k blocks. Vectors,
|
|
281 buffers, windows, and other large objects are individually allocated and
|
|
282 freed using @code{malloc} and @code{free}.
|
|
283
|
|
284 @cindex CL note---allocate more storage
|
|
285 @quotation
|
|
286 @b{Common Lisp note:} unlike other Lisps, XEmacs Lisp does not
|
|
287 call the garbage collector when the free list is empty. Instead, it
|
|
288 simply requests the operating system to allocate more storage, and
|
|
289 processing continues until @code{gc-cons-threshold} bytes have been
|
|
290 used.
|
|
291
|
|
292 This means that you can make sure that the garbage collector will not
|
|
293 run during a certain portion of a Lisp program by calling the garbage
|
|
294 collector explicitly just before it (provided that portion of the
|
|
295 program does not use so much space as to force a second garbage
|
|
296 collection).
|
|
297 @end quotation
|
|
298
|
|
299 @deffn Command garbage-collect
|
|
300 This command runs a garbage collection, and returns information on
|
|
301 the amount of space in use. (Garbage collection can also occur
|
|
302 spontaneously if you use more than @code{gc-cons-threshold} bytes of
|
|
303 Lisp data since the previous garbage collection.)
|
|
304
|
|
305 @code{garbage-collect} returns a list containing the following
|
|
306 information:
|
|
307
|
|
308 @example
|
|
309 @group
|
|
310 ((@var{used-conses} . @var{free-conses})
|
|
311 (@var{used-syms} . @var{free-syms})
|
|
312 @end group
|
|
313 (@var{used-markers} . @var{free-markers})
|
444
|
314 @var{used-string-chars}
|
428
|
315 @var{used-vector-slots}
|
|
316 (@var{plist}))
|
|
317
|
|
318 @group
|
|
319 @result{} ((73362 . 8325) (13718 . 164)
|
|
320 (5089 . 5098) 949121 118677
|
|
321 (conses-used 73362 conses-free 8329 cons-storage 658168
|
|
322 symbols-used 13718 symbols-free 164 symbol-storage 335216
|
|
323 bit-vectors-used 0 bit-vectors-total-length 0
|
|
324 bit-vector-storage 0 vectors-used 7882
|
|
325 vectors-total-length 118677 vector-storage 537764
|
|
326 compiled-functions-used 1336 compiled-functions-free 37
|
|
327 compiled-function-storage 44440 short-strings-used 28829
|
|
328 long-strings-used 2 strings-free 7722
|
|
329 short-strings-total-length 916657 short-string-storage 1179648
|
|
330 long-strings-total-length 32464 string-header-storage 441504
|
|
331 floats-used 3 floats-free 43 float-storage 2044 markers-used 5089
|
|
332 markers-free 5098 marker-storage 245280 events-used 103
|
|
333 events-free 835 event-storage 110656 extents-used 10519
|
|
334 extents-free 2718 extent-storage 372736
|
|
335 extent-auxiliarys-used 111 extent-auxiliarys-freed 3
|
|
336 extent-auxiliary-storage 4440 window-configurations-used 39
|
|
337 window-configurations-on-free-list 5
|
|
338 window-configurations-freed 10 window-configuration-storage 9492
|
|
339 popup-datas-used 3 popup-data-storage 72 toolbar-buttons-used 62
|
|
340 toolbar-button-storage 4960 toolbar-datas-used 12
|
|
341 toolbar-data-storage 240 symbol-value-buffer-locals-used 182
|
|
342 symbol-value-buffer-local-storage 5824
|
|
343 symbol-value-lisp-magics-used 22
|
|
344 symbol-value-lisp-magic-storage 1496
|
|
345 symbol-value-varaliases-used 43
|
|
346 symbol-value-varalias-storage 1032 opaque-lists-used 2
|
|
347 opaque-list-storage 48 color-instances-used 12
|
|
348 color-instance-storage 288 font-instances-used 5
|
|
349 font-instance-storage 180 opaques-used 11 opaque-storage 312
|
|
350 range-tables-used 1 range-table-storage 16 faces-used 34
|
|
351 face-storage 2584 glyphs-used 124 glyph-storage 4464
|
|
352 specifiers-used 775 specifier-storage 43869 weak-lists-used 786
|
|
353 weak-list-storage 18864 char-tables-used 40
|
|
354 char-table-storage 41920 buffers-used 25 buffer-storage 7000
|
|
355 extent-infos-used 457 extent-infos-freed 73
|
|
356 extent-info-storage 9140 keymaps-used 275 keymap-storage 12100
|
|
357 consoles-used 4 console-storage 384 command-builders-used 2
|
|
358 command-builder-storage 120 devices-used 2 device-storage 344
|
|
359 frames-used 3 frame-storage 624 image-instances-used 47
|
|
360 image-instance-storage 3008 windows-used 27 windows-freed 2
|
|
361 window-storage 9180 lcrecord-lists-used 15
|
|
362 lcrecord-list-storage 360 hash-tables-used 631
|
|
363 hash-table-storage 25240 streams-used 1 streams-on-free-list 3
|
|
364 streams-freed 12 stream-storage 91))
|
|
365 @end group
|
|
366 @end example
|
|
367
|
|
368 Here is a table explaining each element:
|
|
369
|
|
370 @table @var
|
|
371 @item used-conses
|
|
372 The number of cons cells in use.
|
|
373
|
|
374 @item free-conses
|
|
375 The number of cons cells for which space has been obtained from the
|
|
376 operating system, but that are not currently being used.
|
|
377
|
|
378 @item used-syms
|
|
379 The number of symbols in use.
|
|
380
|
|
381 @item free-syms
|
|
382 The number of symbols for which space has been obtained from the
|
|
383 operating system, but that are not currently being used.
|
|
384
|
|
385 @item used-markers
|
|
386 The number of markers in use.
|
|
387
|
|
388 @item free-markers
|
|
389 The number of markers for which space has been obtained from the
|
|
390 operating system, but that are not currently being used.
|
|
391
|
|
392 @item used-string-chars
|
|
393 The total size of all strings, in characters.
|
|
394
|
|
395 @item used-vector-slots
|
|
396 The total number of elements of existing vectors.
|
|
397
|
|
398 @item plist
|
|
399 A list of alternating keyword/value pairs providing more detailed
|
|
400 information. (As you can see above, quite a lot of information is
|
|
401 provided.)
|
|
402 @ignore @c Different in XEmacs
|
|
403
|
|
404 @item used-floats
|
|
405 @c Emacs 19 feature
|
|
406 The number of floats in use.
|
|
407
|
|
408 @item free-floats
|
|
409 @c Emacs 19 feature
|
|
410 The number of floats for which space has been obtained from the
|
|
411 operating system, but that are not currently being used.
|
|
412 @end ignore
|
|
413 @end table
|
|
414 @end deffn
|
|
415
|
|
416 @defopt gc-cons-threshold
|
|
417 The value of this variable is the number of bytes of storage that must
|
|
418 be allocated for Lisp objects after one garbage collection in order to
|
|
419 trigger another garbage collection. A cons cell counts as eight bytes,
|
|
420 a string as one byte per character plus a few bytes of overhead, and so
|
|
421 on; space allocated to the contents of buffers does not count. Note
|
|
422 that the subsequent garbage collection does not happen immediately when
|
|
423 the threshold is exhausted, but only the next time the Lisp evaluator is
|
|
424 called.
|
|
425
|
|
426 The initial threshold value is 500,000. If you specify a larger
|
|
427 value, garbage collection will happen less often. This reduces the
|
|
428 amount of time spent garbage collecting, but increases total memory use.
|
|
429 You may want to do this when running a program that creates lots of
|
|
430 Lisp data.
|
|
431
|
|
432 You can make collections more frequent by specifying a smaller value,
|
|
433 down to 10,000. A value less than 10,000 will remain in effect only
|
|
434 until the subsequent garbage collection, at which time
|
|
435 @code{garbage-collect} will set the threshold back to 10,000. (This does
|
|
436 not apply if XEmacs was configured with @samp{--debug}. Therefore, be
|
|
437 careful when setting @code{gc-cons-threshold} in that case!)
|
|
438 @end defopt
|
|
439
|
444
|
440 @ignore
|
428
|
441 @c Emacs 19 feature
|
|
442 @defun memory-limit
|
|
443 This function returns the address of the last byte XEmacs has allocated,
|
|
444 divided by 1024. We divide the value by 1024 to make sure it fits in a
|
|
445 Lisp integer.
|
|
446
|
|
447 You can use this to get a general idea of how your actions affect the
|
|
448 memory usage.
|
|
449 @end defun
|
444
|
450 @end ignore
|
428
|
451
|
|
452 @defvar pre-gc-hook
|
|
453 This is a normal hook to be run just before each garbage collection.
|
|
454 Interrupts, garbage collection, and errors are inhibited while this hook
|
|
455 runs, so be extremely careful in what you add here. In particular,
|
|
456 avoid consing, and do not interact with the user.
|
|
457 @end defvar
|
|
458
|
|
459 @defvar post-gc-hook
|
|
460 This is a normal hook to be run just after each garbage collection.
|
|
461 Interrupts, garbage collection, and errors are inhibited while this hook
|
|
462 runs, so be extremely careful in what you add here. In particular,
|
|
463 avoid consing, and do not interact with the user.
|
|
464 @end defvar
|
|
465
|
|
466 @defvar gc-message
|
|
467 This is a string to print to indicate that a garbage collection is in
|
|
468 progress. This is printed in the echo area. If the selected frame is
|
|
469 on a window system and @code{gc-pointer-glyph} specifies a value (i.e. a
|
|
470 pointer image instance) in the domain of the selected frame, the mouse
|
|
471 cursor will change instead of this message being printed.
|
|
472 @end defvar
|
|
473
|
|
474 @defvr Glyph gc-pointer-glyph
|
|
475 This holds the pointer glyph used to indicate that a garbage collection
|
|
476 is in progress. If the selected window is on a window system and this
|
|
477 glyph specifies a value (i.e. a pointer image instance) in the domain of
|
|
478 the selected window, the cursor will be changed as specified during
|
|
479 garbage collection. Otherwise, a message will be printed in the echo
|
|
480 area, as controlled by @code{gc-message}. @xref{Glyphs}.
|
|
481 @end defvr
|
|
482
|
|
483 If XEmacs was configured with @samp{--debug}, you can set the following
|
|
484 two variables to get direct information about all the allocation that
|
|
485 is happening in a segment of Lisp code.
|
|
486
|
|
487 @defvar debug-allocation
|
|
488 If non-zero, print out information to stderr about all objects
|
|
489 allocated.
|
|
490 @end defvar
|
|
491
|
|
492 @defvar debug-allocation-backtrace
|
|
493 Length (in stack frames) of short backtrace printed out by
|
|
494 @code{debug-allocation}.
|
|
495 @end defvar
|