{Begin SubSec Garbage Collection}
{Title Garbage Collection}
{Text



{index garbage collection}


Interlisp-D has a reference-counting garbage collector (Interlisp-10 uses the more familiar mark-and-sweep algorithm).  A reference-counting garbage collector uses time proportional to the garbage being collected and not to the size of the address space.  This is a crucial advantage for a large address space system such as Interlisp-D.  It does have a disadvantage in that circular lists are never reclaimed, as their reference count never goes to zero.  In addition, atoms are currently not garbage collected; and non-atomic hash array keys are not collected (in Interlisp-10, when a non-atomic hash key is no longer referenced except by the hash array itself, the hashlink goes away and both the key and the value, if it is nowhere else referenced, are reclaimed).

{note above description is WRONG.  Reference-counting garbage collector has to sweep through hash table, which grows linearly with working set.  Anyways, the only real advantage to I-D scheme is that Mark phase is done incrementally, rather than all at once.   ---jonl}


Garbage collection in Interlisp-D is controlled by the following functions and variables:


{index *PRIMARY* RECLAIM Fn}

{FnDef {Name RECLAIM} {Args}
{Text
Initiates a garbage collection.  {fn RECLAIM} always returns 0, independent of the actual number of cells collected.
}}


{FnDef {Name RECLAIMMIN} {Args N}
{Text
The frequency of garbage collection is user settable via the function {fn RECLAIMMIN} (which plays a role similar to Interlisp-10's {fn MINFS},{index MINFS Fn} which is a no-op in Interlisp-D).  Lisp keeps track of the number of cells of any type that have been allocated; when it reaches the {fn RECLAIMMIN} number, a garbage collection occurs.  
{lisp (RECLAIMMIN {arg N})} returns the current setting of the parameter, and, if {arg N} is non-{lisp NIL}, sets it to {arg N}.

As there is no motivation for the Interlisp-10 {lisp CTRL-S} interrupt, it is not enabled.
}}


{VarDef {Name RECLAIMWAIT}
{Text
Interlisp-D will invoke a {fn RECLAIM} if the system is idle and waiting for user input for {var RECLAIMWAIT} seconds (currently set for 4 seconds).
}}


{index *PRIMARY* GCGAG Fn}

{FnDef {Name GCGAG} {Args MESSAGE}
{Text
{fn GCGAG} sets the message that appears on the display screen while a garbage collection is taking place.
If {arg MESSAGE} is non-{lisp NIL}, the cursor is complemented during a {fn RECLAIM}; if {arg MESSAGE}={lisp NIL}, nothing happens.
This limited choice exists because it was found that printing a message took a significant fraction of the time of small {fn RECLAIM}s.
The value of {fn GCGAG} is its previous setting.
}}
 

{index *PRIMARY* GCTRP Fn}

{FnDef {Name GCTRP} {Args}
{Text
The function {fn GCTRP} returns the number of cells (of any type, not just {lisp LISTP}) until the next garbage collection, according to the {fn RECLAIMMIN} number, although this number is not very meaningful.
}}



}{End SubSec Garbage Collection}




{Begin SubSec Variable Bindings}
{Title Variable Bindings}
{Text

Interlisp-D uses deep binding of variables, whereas Interlisp-10 currently uses shallow binding (prior to 1975, Interlisp-10 used deep binding).
Although this makes little difference for most programs, it can make a difference in efficiency of execution.  For example, it is better to pass parameters as arguments than to let subfunctions reference them freely.  In addition, declaring variables that are never bound (i.e., whose top level value only is used) to be {lisp GLOBALVARS} is important.  Sloppy Interlisp-10 code that rebinds variables that have been declared as {lisp GLOBALVARS} will not run correctly in Interlisp-D.  Be careful to use {fn RESETVARS} to "rebind" variables that are declared {lisp GLOBALVARS}.  {fn RESETVARS} works in both systems; in a shallow system, {fn RESETVARS} just binds its arguments as {fn PROG} variables (and makes sure they are declared {lisp SPECVARS}), while in a deep system such as Interlisp-D, entries are made on {var RESETVARSLST}.{index RESETVARSLST Var}
If the compiler sees an attempt to bind a global variable, it will print out an error message.{note what message??}

For performance reasons, it is important to declare global variables as such in Interlisp-D.  This can be done with the {filecom GLOBALVARS} file package command ({PageRef FileCom GLOBALVARS}), which causes variables to be declared as global to the compiler.  For more information on variable bindings and performance, see {PageRef Tag GlobalvarsPerformance}.

}{End SubSec Variable Bindings}


{Begin SubSec Stack Format}
{Title Stack Format}
{Text

Both the interpreter and compiler generate different intermediate frames than are found in Interlisp-10, so if the user has code that assumes a particular number of frames will exist at some point (e.g., using {fn STKNTH}), it will probably be wrong.  {fn STKPOS} and {fn STKSCAN} are still available, however, and {fn REALSTKNTH} and {fn REALFRAMEP} are useful for ignoring those intermediate frames.

{note document  *PROG*LAM  ---lmm}

}{End SubSec Stack Format}


{Begin SubSec Saving Virtual Memory State}
{Title Saving Virtual Memory State}
{Text

The Interlisp-D virtual memory is kept in the file Lisp.virtualmem.{index Lisp.virtualmem (File)}  As virtual memory pages are accessed, they are loaded from this file into real memory.  To exit from Interlisp-D to the Alto Executive so that it is possible to return to the current Interlisp-D environment, it is necessary to save the state of the virtual memory.  The simplest way is to use the function {fn LOGOUT} ({PageRef Fn LOGOUT}).  This will write out all altered pages from real memory to Lisp.virtualmem.



If you are the sole user of Interlisp-D on a disk partition, then you will probably want to use {fn LOGOUT}.  However, if other Interlisp-D users may be using that partition, and you wish to save your state, then it may be more appropriate to use {fn SYSOUT} ({PageRef Fn SYSOUT}).  Note that {fn SYSOUT} in Interlisp-D saves the {it entire} state of the virtual memory, instead of just the saved pages, so Interlisp-D sysout file are very large.


{FnDef {Name VMEMSIZE} {Args}
{Text
Returns the number of pages in use in the virtual memory.  This is the roughly the same as the number of pages required to make a sysout file on the local disk.
}}




Interlisp-D contains a routine that writes out dirty pages of the virtual memory during I/O wait, assuming that swapping has caused at least one dirty page to be written back into Lisp.virtualmem (making it non-continuable).  The frequency with which this routine runs is determined (inversely) by:


{VarDef {Name BACKGROUNDPAGEFREQ}
{Text
This global variable determines how often the routine that writes out dirty pages is run.  Initially it is set to 4, so the dirty page routine is run once every 4 times around the idle loop.  (The lower {lisp BACKGROUNDPAGEFREQ} is set, the less responsiveness you get at typein, so it may not be desirable to set it all the way down to 1.)
}}


{Begin Note}
Date:  6-Oct-82 16:12:16 PDT (Wednesday)
From: vanMelle.PA
(16) The idle loop referred to is currently the i/o wait before the user types something, i.e., the period when PERIODICALLYRECLAIM is running.  This may not be true forevermore, however, so I'd rather not rigorously define it.


The background RECLAIM and SAVEVM are no longer handled by PERIODICALLYRECLAIM on PROMPTCHARFORMS, but run in the background process, and now pay attention to mouse actions as well as typein.
{End Note}


The following function is used to write all of the dirty pages out, to make sure that the current state is not lost if there is a system crash.

{note RELEASEFLG actually 'flushes' pages not in use, for diagnostics --lmm}

{FnDef {Name SAVEVM} {Args {anonarg}}
{Text
This function is similar to logging out and continuing, but faster.  It takes about as long as a logout, which can be as brief as 10 seconds or so if you have already written out most of your dirty pages by virtue of being idle a while.  After the {fn SAVEVM}, and until the pagefault handler is next forced to write out a dirty page, your virtual memory image will be continuable (as of the {fn SAVEVM}) should there be a system crash or other disaster.

{note the arg RELEASEFLG is only of interest to system people}
}}


If the system has been idle long enough, dirty pages have been written, and there are few enough dirty pages left to write that a {fn SAVEVM} would be quick, {fn SAVEVM} will be automatically called.  While {fn SAVEVM} is being executed, the cursor is changed to a special "{lisp SAV/ING}" cursor.{index SAV/ING cursor}  You can control how often {fn SAVEVM} is automatically called by setting the following two global variables:


{VarDef {Name SAVEVMWAIT}}
{VarDef {Name SAVEVMMAX}
{Text
The system will call {fn SAVEVM} after being idle for {var SAVEVMWAIT} seconds (initially 60) if there are fewer than {var SAVEVMMAX} pages dirty (initially 600).  These values are fairly conservative.  If you want to be extremely wary, you can set {var SAVEVMWAIT}=0 and {var SAVEVMMAX}=10000, in which case {fn SAVEVM} will be called the first chance available after the first dirty page has been written.
}}



}{End SubSec Saving Virtual Memory State}



{Begin SubSec Error Types}
{Title Error Types}
{Text

The following additional error types occur in Interlisp-D:

{Begin Table}

{COLUMN 10percent} {COLUMN}

{First 5}
{Next {lisp FILE SYSTEM ERROR}}

{First 48}
{Next {lisp FLOATING UNDERFLOW}}

{First 49}
{Next {lisp FLOATING OVERFLOW}}

{First 50}
{Next {lisp OVERFLOW}}

{First 51}
{Next {lisp ARG NOT HARRAY}}

{First 52}
{Next {lisp TOO MANY ARGUMENTS}}

{End Table}


Interlisp-D allows the user to trap arithmetic exceptions.  The action taken when overflow occurs may be set with the function {fn OVERFLOW} ({PageRef Fn OVERFLOW}).


{lisp READ-MACRO CONTEXT} errors are not generated in Interlisp-D.  In the situation where Interlisp-10 would generate the error, the call to {fn READ} within the macro will simply return {lisp NIL}.



{Begin Note}
Date:  6-Oct-82 16:12:16 PDT (Wednesday)
From: vanMelle.PA
As far as I can tell, nobody generates error #5.  I scanned all the low-level file code.  Has this ever been used?  Perhaps it is a place-holder for hard disk error or some such?
{End Note}


{Begin Note}
Error messages:

"ARG NOT typename" Now generated when attempting to fetch or replace a user datatype field in the wrong type of object, e.g. ARG NOT FONTDESCRIPTOR, ARG NOT WINDOW, etc.

"ARG NOT HARRAY" (error 51) signaled by GETHASH/PUTHASH/REHASH (instead of "ARG NOT ARRAY" as formerly).

"STORAGE FULL" (rather than a RAID call) is now signaled whenever one of a number of system resources are "about to be" exhausted. The user should still have a chance to clean up to save changes after this error. The error handler will FORCE a break on STORAGE FULL.

"STACK OVERFLOW" is now signaled (rather than a RAID call) on stack overflow. 

Note: STORAGE FULL and STACK OVERFLOW are one-shot "warning" errors: after the first STORAGE FULL, even if resources are freed, running out of space will be fatal. After the first STACK OVERFLOW, and until the next intervening (HARDRESET) (also invoked via control-D from RAID), the next stack overflow will call RAID.

"TOO MANY ARGUMENTS", generated by calling a function with too many arguments (rather than "UNUSUAL CDR ARGLIST" as before).

"HARD DISK ERROR" is now a Lisp error which identifies file (rather than a RAID call as before.)
{End Note}

}{End SubSec Error Types}




{Begin SubSec Compiler}
{Title Compiler}
{Text


Interlisp-D runs a different instruction set than Interlisp-10, so source files from Interlisp-10 must be recompiled.  The default extension (value of {index COMPILE.EXT Var}{var COMPILE.EXT}) for Interlisp-D compiled files is "{lisp DCOM}" rather than "{lisp COM}" as in Interlisp-10.

The Interlisp-10 compiler translates Lisp source programs into 36-bit PDP-10 instructions.  The Interlisp-D compiler compiles Lisp source programs into an 8-bit Lisp instruction set executed by the Xerox 1100 family machines. 

{note explain compiler output differences: (FOO(args) (Calls:...) (Uses: ...))}


In Interlisp-D, block compiling is handled somewhat differently than in Interlisp-10; block compiling provides a mechanism for hiding function names internal to a block, but it does not provide a performance advantage.  Block compiling in Interlisp-D works by automatically renaming the block functions with special names, and calling these functions with the normal function-calling mechanisms.  Specifically, a function {arg FN} is renamed to {lisp \{arg BLOCK-NAME}/{arg FN}}.  For example, function {lisp FOO} in block {lisp BAR} is renamed to "{lisp \BAR/FOO}".  Note that it is possible with this scheme to break functions internal to a block.

Interlisp-D has an optimizing compiler.  Among other optimizations, it performs constant folding.  Variables can be declared by the user to be compiler constants using the file package command {filecom CONSTANTS} ({PageRef FileCom CONSTANTS}), which is syntactically the same as {filecom VARS}, but additionally informs the compiler that the "variables" are constants.

}{End SubSec Compiler}




{Begin SubSec Linked Function Calls}
{Title Linked Function Calls}
{Text 


Linked function calls are not implemented in Interlisp-D.  One noticeable result of this is that if you break a function that is used by the system, for example in the {lisp READ-EVAL-PRINT} loop, you will get unexpected breaks within system code.  These extra breaks can be safely exited with {lisp OK}.  To avoid this inconvenience, {lisp BREAK} the function inside another function, e.g., {lisp (BREAK (PRIN1 IN FOO))}.  (Note:  Functions that begin with a backslash ({lisp \}) are system internal functions and should not be broken or advised.)

}{End SubSec Linked Function Calls}





{Begin SubSec HELPSYS}
{Title HELPSYS}
{Text

{index HELPSYS Fn}

There is currently no {lisp HELPSYS} facility in Interlisp-D.  There are plans to reimplement a {lisp HELPSYS} facility eventually.

}{End SubSec HELPSYS}




{Begin SubSec Operating System Dependent Functions}
{Title Operating System Dependent Functions}
{Text

Many Interlisp-10 functions are missing from Interlisp-D.  An attempt has been made to provide an appropriate implementation for the more useful of these functions, but some simply do not make sense on the Xerox 1100 family machines.  For example, there is no such thing as a {lisp JSYS}.  Any function containing a call on {lisp JSYS} or {lisp ASSEMBLE} will fail to compile.

The following Interlisp-10 functions are not implemented in Interlisp-D: {lisp LISPXSTATS}, {lisp SUBSYS}, {lisp GETBLK}, {lisp RELBLK}, {lisp ERSTR}, {lisp GTJFN}, {lisp OPNJFN}, {lisp RLJFN}, {lisp OPENF}, {lisp JFNS}.{index LISPXSTATS Fn}{index SUBSYS Fn}{index GETBLK Fn}{index RELBLK Fn}{index ERSTR Fn}{index GTJFN Fn}{index OPNJFN Fn}{index RLJFN Fn}{index OPENF Fn}{index JFNS Fn}


The following Interlisp-10 functions are implemented as dummies in Interlisp-D: {fn LISPXWATCH}, {fn ADDSTATS}, {fn HOSTNAME}, {fn USERNUMBER}, {fn HOSTNUMBER}, {fn LOADAV}.  There are communication network analogs of {fn HOSTNAME} and {fn HOSTNUMBER} called {fn ETHERHOSTNAME} and {fn ETHERHOSTNUMBER} ({PageRef Fn ETHERHOSTNAME}).

{index LISPXWATCH Fn}
{index ADDSTATS Fn}
{index HOSTNAME Fn}
{index USERNUMBER Fn}
{index HOSTNUMBER Fn}
{index LOADAV Fn}

Additional Functions:

{FnDef {Name HOSTNAMEP} {Args NAME}
{Text
Returns {lisp T} if {arg NAME} is recognized as a valid device or remote file server name at the moment {fn HOSTNAMEP} is called.
}}


{FnDef {Name MACHINETYPE} {Args }
{Text
Returns the type of machine that Interlisp-D is running on:  either {lisp DORADO} (for the Xerox 1132), {lisp DOLPHIN} (for the Xerox 1100), or {lisp DANDELION} (for the Xerox 1108).
}}


{FnDef {Name RINGBELLS} {Args }
{Text
On the Xerox 1100, this flashes (reverse-videos) the screen several times.  On the Xerox 1108, this also beeps through the keyboard speaker.
}}


}{End SubSec Operating System Dependent Functions}




{Begin SubSec Time/Date Functions}
{Title Time/Date Functions}
{Text

{FnDef {Name SETTIME} {Args DATE&TIME}
{Text
Sets the internal time-of-day clock.  If {arg DATE&TIME} = {lisp NIL}, {fn SETTIME} attempts to get the time from the communications net;  if it fails, the user is prompted for the time.  If {arg DATE&TIME} is a string in a form that {fn IDATE} recognizes, it is used to set the time.
}}



{VarDef {Name \TimeZoneComp}
{Text
This variable should be initialized (in {lisp {bracket DSK}INIT.LISP}) to the time-zone compensation, i.e., the number of hours west of GMT.  For the U.S. west coast it is 8.  For the east coast it is 5.
}}


{Begin Note}
I've merged this text with the main manual -- LMM

{index IDATE FN}

Interlisp-D uses a different time standard than Tenex does.  {fn IDATE} still has the essential property that {lisp (IDATE {arg X})} is less than {lisp (IDATE} {arg Y}) if {arg X} is before {arg Y}, and {lisp (IDATE (GDATE {arg N}))} equals {arg N}.  If the particular internal format of the integer date is being used to do arithmetic on dates, the user's programs must be fixed.  But in that case the user is already in trouble with Interlisp-10, where the date standard is subtly different between Tenex and Tops20.  The most useful property that the three formats have in common is that an internal date can be incremented by an integral number of days by computing as the "1 day" constant (which can be evaluated at compile time) the difference between two convenient {lisp IDATE's}, e.g. {lisp (IDIFFERENCE (IDATE " 2-JAN-80 12:00") (IDATE " 1-JAN-80 12:00"))}.

Currently, the format argument of {fn DATE} and {fn GDATE} is not supported (an error will occur if the user tries to give one).  {fn IDATE} now parses most of the date forms allowed in Interlisp-10; e.g., the month can be given numerically, slashes can be used as separators, extra spaces are ignored.
{End Note}

}{End SubSec Time/Date Functions}



{Begin SubSec Character Set}
{Title Character Set}
{Text

Interlisp-D uses an 8-bit character set whereas Interlisp-10 uses standard 7-bit ASCII.  The values returned by {fn CHCON1} range from 0 to 255, and codes in this range are acceptable arguments to {fn CHARACTER} and {fn FCHARACTER}.  Characters 0-127 have their standard ASCII interpretations; characters 128-255 are called "meta" characters.  Some of the meta characters have printed representations in some fonts (for accents, ligatures, etc.), but most of them will be invisible if printed directly to the screen.  Accordingly, the echoing conventions normally defined for control characters have been extended to apply also to meta characters.  The echomode of any character may be set by the new function {fn ECHOCHAR} ({PageRef Fn ECHOCHAR}).  In the original terminal table, the {lisp INDICATE} character mode is specified for all meta characters, so all meta characters are echoed as a cross-hatch ({lisp #}) followed by the printed representation corresponding to the 7 rightmost bits of the character.  For example, character 129 is echoed as {lisp #^A}.  There is currently no type-in syntax for meta characters.

{note what is status of meta-shift?  (not yet finalized --BVM)}

The {fn CHARCODE} function ({PageRef Fn CHARCODE}), defined in both Interlisp-D and Interlisp-10, can be useful when dealing with the Interlisp-D character set.


}{End SubSec Character Set}




{Begin SubSec Read Tables}
{Title Read Tables}
{Text

In Interlisp-D, all control characters are defined as separator characters in {var FILERDTBL},{index FILERDTBL Var} so that the font information in files is ignored when files are loaded.  Users who run in both Interlisp-10 and Interlisp-D with the same files will want to make the same setting in Interlisp-10's {var FILERDTBL}, in order that files created in one system can be read in the other.  The appropriate expression to evaluate, which may be in your Interlisp-10 {lisp INIT.LISP} file, is:

{lispcode
(SETSEPR '(1 2 3 4 5 6 7 9 10 11 12 13 14 15
            16 17 18 19 20 21 22 23 24 25 26)
         1 FILERDTBL)}

}{End SubSec Read Tables}





{Begin SubSec Keyboard Interpretation}
{Title Keyboard Interpretation}
{Text

{note where should this go?  it seems like it should be near the mouse stuff in the window package section.  Perhaps that stuff should be moved here??}

In Interlisp-D, keyboard and mouse interpretation is now done entirely by Lisp code, and certain lower level keyboard facilities are therefore available.  For
each key on the keyboard/mouse there is a corresponding bit in memory that the hardware/microcode turn on and off as the key moves up and down.  System-level routines decode the meaning of key transitions according to a table of "key actions", which may be to put particular Ascii codes in the sysbuffer, cause interrupts, change the internal shift/control status, or create events to be placed in the mouse buffer.


{FnDef {Name KEYDOWNP} {Args KEYNAME}
{Text
Used to read the instantaneous state of any key, independent of any buffering or pre-assigned key action.  Returns {lisp T} if the key named {arg KEYNAME} is down at the moment the function is executed.  Most keys are named by any of the characters on the key-top.  The shift keys are named separately as {lisp RSHIFT} and {lisp LSHIFT}, space is {lisp SPACE}, the unmarked keys are {lisp BLANK-TOP}, {lisp BLANK-MIDDLE}, and {lisp BLANK-BOTTOM}, and the mouse buttons are {lisp LEFT}, {lisp MIDDLE}, and {lisp RIGHT}.  Paddles on the keyset (not generally available) are named {lisp PAD1} through {lisp PAD5}.   Thus {lisp (KEYDOWNP 'a)} returns {lisp T} if the "{lisp a}" key is down, {lisp (KEYDOWNP 'TAB)} returns the state of the {lisp TAB} key, etc.
}}


{FnDef {Name KEYACTION} {Args KEYNAME ACTIONS}
{Text
Changes the internal tables that define the action to be taken when a key transition is detected by the system keyboard handler.  {arg KEYNAME} is specified as for {fn KEYDOWNP}.  {arg ACTIONS} is a dotted pair of the form {lisp ({arg DOWN-ACTION} . {arg UP-ACTION})}, where the acceptable transition actions and their interpretations are:

{Begin LabeledList KEYACTION transition actions}

{Indent 15percent}

{Name {lisp NIL}}
{Text
Take no action on this transition (the default for up-transitions on all ordinary characters).
}

{Name a list {lisp ({arg CHAR} {arg SHIFTEDCHAR} {arg LOCKFLAG})}}
{Text
{arg CHAR} and {arg SHIFTEDCHAR} are either ascii codes or non-digit
characters standing for their ascii codes.  When the transition occurs, {arg CHAR} or {arg SHIFTEDCHAR} is transmitted to the system buffer, depending on whether either of the 2 shift keys are down.  {arg LOCKFLAG} is optional, and may be {lisp LOCKSHIFT} or {lisp NOLOCKSHIFT}.  If {arg LOCKFLAG} is {lisp LOCKSHIFT}, then {arg SHIFTEDCHAR} will also be transmitted when the {lisp LOCK} shift is down (the alphabetic keys initially specify {lisp LOCKSHIFT}, but the digit keys specify {lisp NOLOCKSHIFT}).  

Examples: {lisp (a A LOCKSHIFT)} and {lisp (61Q ! NOLOCKSHIFT)} are the initial settings for the down transitions of the "{lisp a}" and "{lisp 1}" keys respectively.
}

{Name {lisp 1SHIFTUP}, {lisp 2SHIFTUP}, {lisp LOCKUP}, {lisp CTRLUP}, {lisp METAUP}}
{Name {lisp 1SHIFTDOWN}, {lisp 2SHIFTDOWN}, {lisp LOCKDOWN}, {lisp CTRLDOWN}, {lisp METADOWN}}
{Text
Change the status of the internal "shift" flags for the left shift, right shift, shift lock, ctrl, and meta keys, respectively. These shifts affect the interpretation of ordinary key actions.  If either of the shifts is down, then {arg SHIFTEDCHAR}s are transmitted.  If the lock flag is down, then {arg SHIFTEDCHAR}s are transmitted if the key action specified {lisp LOCKSHIFT}.  If the control flag is on, then the low-order five bits are masked out of the code that would otherwise be transmitted to the system buffer.  If the meta flag is down, the high order (8th bit) is turned on as characters are transmitted.

Example: the initial {arg ACTIONS} for the left shift key is {lisp (1SHIFTUP . 1SHIFTDOWN)}.
}


{Name {lisp EVENT}}
{Text
An encoding of the current state of the mouse and selected keys
is placed in the mouse-event buffer when this transition is
detected.
}

{End LabeledList KEYACTION transition actions}



{fn KEYACTION} returns the previous setting for {arg KEYNAME}.  If {arg ACTIONS} is {lisp NIL}, returns the previous setting without changing the tables.
}}



{FnDef {Name MODIFY.KEYACTIONS} {Args KEYACTIONS SAVECURRENT?}
{Text
{arg KEYACTIONS} is a list of key actions to be set, each of the form {lisp ({arg KEYNAME} .  {arg ACTIONS})}.  The effect of {fn MODIFY.KEYACTIONS} is as if {lisp (KEYACTION {arg KEYNAME} {arg ACTIONS})} were performed for each item on {arg KEYACTIONS}.

If {arg SAVECURRENT?} is non-{lisp NIL}, then {fn MODIFY.KEYACTIONS} returns a list of all the results from {fn KEYACTION}, otherwise it returns {lisp NIL}.  This can be used with a {fn MODIFY.KEYACTIONS} that appears in a {fn RESETFORM}, so that the list is built at "entry", but not upon "exit".
}}



{FnDef {Name METASHIFT} {Args FLG}
{Type NOSPREAD}
{Text
If {arg FLG} is non-{lisp NIL}, changes the keyboard handler (via {fn KEYACTION}) so as to interpret the bottom blank key ("swat") as a metashift: if a key is struck while meta is down, it is read with the 200Q bit set.  For CHAT users this is a way of getting an "Edit" key on your simulated Datamedia.  Returns previous setting.

{note actually, is NOSPREAD that changes nothing if given no args.  Unfortunately, returns ((195 195 NOLOCKSHIFT) . IGNORE) if current state is NIL.}

}}


{note New RAID interrupt for emergency use: Holding down control-shift-delete will usually get you into RAID (under the 'keyboard' context) as long as the mouse is tracking.}


}{End SubSec Keyboard Interpretation}




{Begin SubSec Lispusers Packages}
{Title Lispusers Packages}
{Text

Most of the {lisp LISPUSERS} packages (see {PageRef Tag LISPUSERS}) are available with the Interlisp-D system as separate loadable packages.  The major exception is the {lisp HASH} package, which is highly machine dependent, and the {lisp WHEREIS} package which depends on it.  {lisp EDITA}, {lisp CJSYS}, and many parts of the {lisp EXEC} package are system-dependent by their very nature, and also are not included.  The various network packages are not provided because many of these facilities are integrated into Interlisp-D at a more fundamental level.

Several packages not documented in the Interlisp Reference Manual are available.  The list currently includes the following:



{Begin LabeledList LISPUSERS PACKAGES}


{Name {lisp GRAPHER}}
{Item A collection of functions for laying out, displaying, and editing graphs on the Interlisp-D screen.}

{Name {lisp BROWSER}}
{Item {Tag Browser}Modifies the {lisp SHOW PATHS} command of Masterscope so that the command's output is displayed as an undirected graph.  Uses the {lisp GRAPHER} package.}

{Name {Lisp EVALSERVER}}
{Item Provides a set of routines to facilitate communication, over an Ethernet, between two or more Xerox 1100s running Interlisp-D.}

{Name {Lisp HISTMENU}}
{Item Provides a simple way to access the Interlisp history list using a menu.}

{Name {lisp SAMEDIR}}
{Item This package advises {fn MAKEFILE} to notify the user if it appears that a file is being written onto a directory other than the one it came from, allowing the user to halt the process.}

{End LabeledList LISPUSERS PACKAGES}



}{End SubSec Lispusers Packages}





{Begin Note}
Date: 12 Feb. 1983 9:01 pm PST (Saturday)
From: burton.pa
Subject: Providing a way to look at system sources
To: Sannella

I am sending this to you so you can keep it as a reminder that the user's guide needs to tell users how to look at and load system sources.  This is the current very awful procedure which I sincerely hope will change before we get to press again but it is at least a beginning.

---------------------------

Date: 8 Nov. 1982 4:49 pm PST (Monday)
From: burton.pa
Subject: Re: Bitmap values
In-reply-to: Your message of 8 Nov. 1982 1:21 pm EST (Monday)
To: Denber.WBST
cc: burton

All system sources are kept on [phylum]<lisp>sources.  Only the compiled code is loaded in the sysout and that is not printable (except with PRINTCODE which will only give the opcodes anyway - not useful).  The sources might be on your local file server though I think most user sites have opted not to use up their local disk space on it.

The next problem you have is finding which of the 50 or so system files the function is on.  If you have an account on MAXC, you can login there and run a program called ABC which is an Interlisp-D cross compilation environment that has a database about the entire system.  Once in ABC you can say PF DESIREDFN and it will print the file it is coming from and print the code for it.  From your dolphin you can load the masterscope database for the entire system which is on [phylum]<lispcore>sources>database.system.  This has the disadvantage that it takes a long time (order of an hour I think) and uses up a lot of space.  If you go this route you can ask Masterscope

. WHERE IS DESIREDFN

Alternatively you can ask someone who might know.  I think printbitmap is on LLDISPLAY but it might also be on ADISPLAY.  Once you have some idea where it might be you can look at the file using the SEE command eg:

SEE {bracket phylum}<lisp>sources>LLDISPLAY

and see if the fn you want is on the coms.  Actually you can have the system search for you by giving a file argument to PF eg:

PF* PRINTBITMAP {bracket phylum}<lisp>sources>LLDISPLAY

Once you know where the fn is, you will have to get the system to "notice" that file before it will automatically load it for you.  This is done with LOADFROM eg:

LOADFROM({bracket phylum}<lisp>sources>LLDISPLAY)

At this point you should be able to edit the function or copy it to another function and edit that eg:

COPYDEF(MYPRINTBITMAP PRINTBITMAP)

and the system will automatically load it.

There may be some macros or record declarations that appear in system code that are not in the system.  If this happens it is an indication that you are getting into pretty low level stuff.  Let one of us know and we will try to help you out.
{End Note}