-This is ../info/internals.info, produced by makeinfo version 4.0 from
+This is ../info/internals.info, produced by makeinfo version 4.0b from
internals/internals.texi.
INFO-DIR-SECTION XEmacs Editor
Our next candidates are the other objects that behave quite
differently than everything else: the strings. They consists of two
-parts, a fixed-size portion (`struct Lisp_string') holding the string's
+parts, a fixed-size portion (`struct Lisp_String') holding the string's
length, its property list and a pointer to the second part, and the
actual string data, which is stored in string-chars blocks comparable to
frob blocks. In this block, the data is not only freed, but also a
`FOOBARP()', etc. macros in a `.h' (or occasionally `.c') file. To
create one of these, copy an existing model and modify as necessary.
+ *Please note:* If you define an lrecord in an external
+dynamically-loaded module, you must use `DECLARE_EXTERNAL_LRECORD',
+`DEFINE_EXTERNAL_LRECORD_IMPLEMENTATION', and
+`DEFINE_EXTERNAL_LRECORD_SEQUENCE_IMPLEMENTATION' instead of the
+non-EXTERNAL forms. These macros will dynamically add new type numbers
+to the global enum that records them, whereas the non-EXTERNAL forms
+assume that the programmer has already inserted the correct type numbers
+into the enum's code at compile-time.
+
The various methods in the lrecord implementation structure are:
1. A "mark" method. This is called during the marking stage and
which is used to mark an object. All Lisp objects that are
contained within the object need to be marked by applying this
function to them. The mark method should also return a Lisp
- object, which should be either nil or an object to mark. (This can
- be used in lieu of calling `mark_object()' on the object, to
+ object, which should be either `nil' or an object to mark. (This
+ can be used in lieu of calling `mark_object()' on the object, to
reduce the recursion depth, and consequently should be the most
heavily nested sub-object, such as a long list.)
Dumping phase
=============
- Dumping is done by calling the function pdump() (in alloc.c) which is
-invoked from Fdump_emacs (in emacs.c). This function performs a number
-of tasks.
+ Dumping is done by calling the function pdump() (in dumper.c) which
+is invoked from Fdump_emacs (in emacs.c). This function performs a
+number of tasks.
* Menu:
differences though:
1. We do not use the mark bit (which does not exist for C structures
- anyway), we use a big hash table instead.
+ anyway); we use a big hash table instead.
2. We do not use the mark function of lrecords but instead rely on the
external descriptions. This happens essentially because we need to
allows us to look up a pdump_entry_list_elmt with the object it points
to). Entries are added with `pdump_add_entry()' and looked up with
`pdump_get_entry()'. There is no need for entry removal. The hash
-value is computed quite basically from the object pointer by
+value is computed quite simply from the object pointer by
`pdump_make_hash()'.
The roots for the marking are:
`staticpro_nodump()' call for protected variables we do not want
to dump).
- 2. the `pdump_wire''d variables (`staticpro' is equivalent to
+ 2. the `pdump_wire''d variables (`staticpro()' is equivalent to
`staticpro_nodump()' + `pdump_wire()').
3. the `dumpstruct''ed variables, which points to C structures.
2. the C compiler is required to adjust the size of a struct so that
you can have an array of them next to each other. This means you
- can have a upper bound of the alignment requirements of a given
+ can have an upper bound of the alignment requirements of a given
structure by looking at which power of two its size is a multiple.
3. the non-variant part of variable size lrecords has an alignment
The maximum alignment requirement we take into account is 2^8.
`pdump_allocate_offset()' only has to do a linear allocation,
-starting at offset 256 (this leaves room for the header and keep the
+starting at offset 256 (this leaves room for the header and keeps the
alignments happy).
\1f
----------
The next step creates the file and writes a header with a signature
-and some random informations in it (number of staticpro, number of
+and some random information in it (number of staticpro, number of
assigned lrecord types, etc...). The reloc_address field, which
indicates at which address the file should be loaded if we want to
avoid post-reload relocation, is set to 0. It then seeks to offset 256
4. a vector of all the offsets to the objects in the file that
include a description (for faster relocation at reload time)
- 5. the pdump_wired and pdump_wired_list arrays
+ 5. the pdump_wire and pdump_wire_list arrays
For each of the arrays we write both the pointer to the variables and
the relocated offset of the object they point to. Since these variables
are global, the pointers are still valid when restarting the program and
are used to regenerate the global pointers.
- The `pdump_wired_list' array is a special case. The variables it
+ The `pdump_wire_list' array is a special case. The variables it
points to are the head of weak linked lists of lisp objects of the same
type. Not all objects of this list are dumped so the relocated pointer
we associate with them points to the first dumped object of the list, or
The DOC file contents should probably end up in the dump file.
-\1f
-File: internals.info, Node: Events and the Event Loop, Next: Evaluation; Stack Frames; Bindings, Prev: Dumping, Up: Top
-
-Events and the Event Loop
-*************************
-
-* Menu:
-
-* Introduction to Events::
-* Main Loop::
-* Specifics of the Event Gathering Mechanism::
-* Specifics About the Emacs Event::
-* The Event Stream Callback Routines::
-* Other Event Loop Functions::
-* Converting Events::
-* Dispatching Events; The Command Builder::
-
projects / chise / xemacs-chise.git / blobdiff