Mercurial > hg > xemacs-beta
view src/README.kkcc @ 4539:061e030e3270
Fix some bugs in load-history construction, built-in symbol file names.
lib-src/ChangeLog addition:
2008-12-27 Aidan Kehoe <kehoea@parhasard.net>
* make-docfile.c (main): Allow more than one -d argument, followed
by a directory to change to.
(put_filename): Don't strip directory information; with previous
change, allows retrieval of Lisp function and variable origin
files from #'built-in-symbol-file relative to lisp-directory.
(scan_lisp_file): Don't add an extraneous newline after the file
name, put_filename has added the newline already.
lisp/ChangeLog addition:
2008-12-27 Aidan Kehoe <kehoea@parhasard.net>
* loadup.el (load-history):
Add the contents of current-load-list to load-history before
clearing it. Move the variable declarations earlier in the file to
a format understood by make-docfile.c.
* custom.el (custom-declare-variable): Add the variable's symbol
to the current file's load history entry correctly, don't use a
cons. Eliminate a comment that we don't need to worry about, we
don't need to check the `initialized' C variable in Lisp.
* bytecomp.el (byte-compile-output-file-form):
Merge Andreas Schwab's pre-GPLv3 GNU change of 19970831 here;
treat #'custom-declare-variable correctly, generating the
docstrings in a format understood by make-docfile.c.
* loadhist.el (symbol-file): Correct behaviour for checking
autoloaded macros and functions when supplied with a TYPE
argument. Accept fully-qualified paths from
#'built-in-symbol-file; if a path is not fully-qualified, return
it relative to lisp-directory if the filename corresponds to a
Lisp file, and relative to (concat source-directory "/src/")
otherwise.
* make-docfile.el (preloaded-file-list):
Rationalise some let bindings a little. Use the "-d" argument to
make-docfile.c to supply Lisp paths relative to lisp-directory,
not absolutely. Add in loadup.el explicitly to the list of files
to be processed by make-docfile.c--it doesn't make sense to add it
to preloaded-file-list, since that is used for purposes of
byte-compilation too.
src/ChangeLog addition:
2008-12-27 Aidan Kehoe <kehoea@parhasard.net>
* doc.c (Fbuilt_in_symbol_file):
Return a subr's filename immediately if we've found it. Check for
compiled function and compiled macro docstrings in DOC too, and
return them if they exist.
The branch of the if statement focused on functions may have
executed, but we may still want to check variable bindings; an
else clause isn't appropriate.
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Sat, 27 Dec 2008 14:05:50 +0000 |
| parents | ac1be85b4a5f |
| children | 3889ef128488 |
line wrap: on
line source
2002-07-17 Marcus Crestani <crestani@informatik.uni-tuebingen.de> Markus Kaltenbach <makalten@informatik.uni-tuebingen.de> Mike Sperber <mike@xemacs.org> updated 2003-07-29 New KKCC-GC mark algorithm: configure flag : --use-kkcc For better understanding, first a few words about the mark algorithm up to now: Every Lisp_Object has its own mark method, which calls mark_object with the stuff to be marked. Also, many Lisp_Objects have pdump descriptions memory_descriptions, which are used by the portable dumper. The dumper gets all the information it needs about the Lisp_Object from the descriptions. Also the garbage collector can use the information in the pdump descriptions, so we can get rid of the mark methods. That is what we have been doing. DUMPABLE FLAG ------------- First we added a dumpable flag to lrecord_implementation. It shows, if the object is dumpable and should be processed by the dumper. The dumpable flag is the third argument of a lrecord_implementation definition (DEFINE_LRECORD_IMPLEMENTATION). If it is set to 1, the dumper processes the descriptions and dumps the Object, if it is set to 0, the dumper does not care about it. KKCC MARKING ------------ All Lisp_Objects have memory_descriptions now, so we could get rid of the mark_object calls. The KKCC algorithm manages its own stack. Instead of calling mark_object, all the alive Lisp_Objects are pushed on the kkcc_gc_stack. Then these elements on the stack are processed according to their descriptions. TODO ---- - For weakness use weak datatypes instead of XD_FLAG_NO_KKCC. XD_FLAG_NO_KKCC occurs in: * elhash.c: htentry * extents.c: lispobject_gap_array, extent_list, extent_info * marker.c: marker Not everything has to be rewritten. See Ben's comment in lrecord.h. - Clean up special case marking (weak_hash_tables, weak_lists, ephemerons). - Stack optimization (have one stack during runtime instead of malloc/free it for every garbage collect) There are a few Lisp_Objects, where there occured differences and inexactness between the mark-method and the pdump description. All these Lisp_Objects get dumped (except image instances), so their descriptions have been written, before we started our work: * alloc.c: string description: size_, data_, and plist is described mark: only plist is marked, but flush_cached_extent_info is called. flush_cached_extent_info -> free_soe -> free_extent_list -> free_gap_array -> gap_array_delete_all_markers -> Add gap_array to the gap_array_marker_freelist * glyphs.c: image_instance description: device is not set to nil mark: mark method sets device to nil if dead See comment above the description.