view info/dir @ 4921:17362f371cc2

add more byte-code assertions and better failure output -------------------- ChangeLog entries follow: -------------------- src/ChangeLog addition: 2010-02-03 Ben Wing <ben@xemacs.org> * alloc.c (Fmake_byte_code): * bytecode.h: * lisp.h: * lread.c: * lread.c (readevalloop): * lread.c (Fread): * lread.c (Fread_from_string): * lread.c (read_list_conser): * lread.c (read_list): * lread.c (vars_of_lread): * symbols.c: * symbols.c (Fdefine_function): Turn on the "compiled-function annotation hack". Implement it properly by hooking into Fdefalias(). Note in the docstring to `defalias' that we do this. Remove some old broken code and change code that implemented the old kludgy way of hooking into the Lisp reader into bracketed by `#ifdef COMPILED_FUNCTION_ANNOTATION_HACK_OLD_WAY', which is not enabled. Also enable byte-code metering when DEBUG_XEMACS -- this is a form of profiling for computing histograms of which sequences of two bytecodes are used most often. * bytecode-ops.h: * bytecode-ops.h (OPCODE): New file. Extract out all the opcodes and declare them using OPCODE(), a bit like frame slots and such. This way the file can be included multiple times if necessary to iterate multiple times over the byte opcodes. * bytecode.c: * bytecode.c (NUM_REMEMBERED_BYTE_OPS): * bytecode.c (OPCODE): * bytecode.c (assert_failed_with_remembered_ops): * bytecode.c (READ_UINT_2): * bytecode.c (READ_INT_1): * bytecode.c (READ_INT_2): * bytecode.c (PEEK_INT_1): * bytecode.c (PEEK_INT_2): * bytecode.c (JUMP_RELATIVE): * bytecode.c (JUMP_NEXT): * bytecode.c (PUSH): * bytecode.c (POP_WITH_MULTIPLE_VALUES): * bytecode.c (DISCARD): * bytecode.c (UNUSED): * bytecode.c (optimize_byte_code): * bytecode.c (optimize_compiled_function): * bytecode.c (Fbyte_code): * bytecode.c (vars_of_bytecode): * bytecode.c (init_opcode_table_multi_op): * bytecode.c (reinit_vars_of_bytecode): * emacs.c (main_1): * eval.c (funcall_compiled_function): * symsinit.h: Any time we change either the instruction pointer or the stack pointer, assert that we're going to move it to a valid location. This should catch failures right when they occur rather than sometime later. This requires that we pass in another couple of parameters into some functions (only with error-checking enabled, see below). Also keep track, using a circular queue, of the last 100 byte opcodes seen, and when we hit an assert failure during byte-code execution, output the contents of the queue in a nice readable fashion. This requires that bytecode-ops.h be included a second time so that a table mapping opcodes to the name of their operation can be constructed. This table is constructed in new function reinit_vars_of_bytecode(). Everything in the last two paras happens only when ERROR_CHECK_BYTE_CODE. Add some longish comments describing how the arrays that hold the stack and instructions, and the pointers used to access them, work. * gc.c: Import some code from my `latest-fix' workspace to mark the staticpro's in order from lowest to highest, rather than highest to lowest, so it's easier to debug when something goes wrong. * lisp.h (abort_with_message): Renamed from abort_with_msg(). * symbols.c (defsymbol_massage_name_1): * symbols.c (defsymbol_nodump): * symbols.c (defsymbol): * symbols.c (defkeyword): * symeval.h (DEFVAR_SYMVAL_FWD_OBJECT): Make the various calls to staticpro() instead call staticpro_1(), passing in the name of the C var being staticpro'ed, so that it shows up in staticpro_names. Otherwise staticpro_names just has 1000+ copies of the word `location'.
author Ben Wing <ben@xemacs.org>
date Wed, 03 Feb 2010 08:01:55 -0600
parents c2580215c222
children
line wrap: on
line source

-*- Text -*-

This is the file .../info/dir, which contains the topmost node of the Info
hierarchy.  The first time you invoke Info you start off looking at that node,
which is (dir)Top.

Rather than adding new nodes to this directory (and this file) it is a better
idea to put them in a site-local directory, and then configure info to search
in that directory as well.  That way, you won't have to re-edit this file when
a new release of the editor comes out.

For example, you could add this code to .../lisp/site-start.el, which is
loaded before ~/.emacs each time the editor starts up:

  ;; find local info nodes
  (setq Info-directory-list
        (append Info-directory-list '("/private/info/")))

Then, when you enter info, a dir file like this one will be automatically
created and saved (provided you have write access to the directory).  The
contents of that file "/private/info/dir" will be appended to the contents of
this file.


File: dir	Node: Top	This is the top of the INFO tree

  This is Info, the online documentation browsing system.
  This page (the Directory node) gives a menu of major topics.

  button2 on a highlighted word follows that cross-reference.
  button3 anywhere brings up a menu of commands.
  ? lists additional keyboard commands.
  h invokes the Info tutorial.

* Menu:

XEmacs 21.5
===========
* XEmacs: (xemacs).          XEmacs Editor.
* Lispref: (lispref).        XEmacs Lisp Reference Manual.
* Intro: (new-users-guide).  Introduction to the XEmacs Editor.
* FAQ: (xemacs-faq).         XEmacs FAQ.
* Info: (info).              Documentation browsing system.
* Internals: (internals).    XEmacs Internals Manual.


Other Documentation:

* Common Lisp: (cl).                   XEmacs Common Lisp emulation package.
* Customizations: (custom).            Customization Library.
* Emodules: (emodules).                XEmacs dynamically loadable module support.
* External Widget: (external-widget).  External Client Widget.
* Standards: (standards).              GNU coding standards.
* Term mode: (term).                   XEmacs Terminal Emulator Mode.
* Termcap: (termcap).                  Termcap library of the GNU system.
* Texinfo: (texinfo).                  The GNU documentation format.
* Widgets: (widget).                   The Emacs Widget Library.