|
Allegro CL version 11.0 | ||||||||
Variable, system package
The value of this variable is a list of all processes that have ever been created and have never completed or been killed. The scheduler does not use this list; it is for debugging.
In an SMP Lisp, the value of *all-processes* represents a list of processes at some moment in the past. This list is never modified destructively. If an application must be certain that the list did not change while it was examined, it can do something like the following
(let ((old *all-processes*))
(do-something old)
(if* (eq old *all-processes*)
then
;; The list did not change
...
else
;; The list changed, try again or
;; compare the lists to see what changed...
...
))See multiprocessing.html for general information on the multiprocessing facility in Allegro CL.
Variable, system package
The value of this variable is a search list used when an autoload is triggered. Autoloads are triggered by actions such as calling certain Allegro CL functions whose functionality is not yet loaded into the system. The fasl file containing the functionality is loaded (usually with require and usually from the bundle) and computation continues, for the most part invisibly to the user.
See Search lists in loading.html for a description of the search list algorithm and structure.
See loading.html for general information on loading and search lists in Allegro CL.
Variable, system package
The variable (which is essentialed a renamed version of the now-deprecated *compile-file-environment*) holds the current compile-file environment. It should only ever be set to either nil or to an environment created by make-compile-file-environment or returned by ensure-portable-walking-environment.
This environment has a lexical part and a global part; the lexical part is managed by augment-environment and the *-information functions, and the global part is managed by ce-putprop and ce-get. Whenever *compile-file-environment* is set to a compile-file-environment, ce-putprop will store to properties within this environment, rather than in some global manner, for example using (setf get). Also, ce-get will consult this environment and if succesful will return the property stored therein, before then trying to get the property globally.
See environments.html for more information on environments.
Variable, system package
Use of this variable is deprecated. Use *compilation-unit-environment* instead. This variable does not have a value (boundp applied to it returns nil) but it is defined as a symbol-macro so any reference to it in code (except by symbol name) is automatically transformed into a reference to *compilation-unit-environment*. (Thus (symbol-value 'sys:*compile-file-environment*) signals an error but just evaluating sys:*compile-file-environment* returns the value of *compilation-unit-environment*.) Users are advised to change their references to sys:*compile-file-environment* to references to sys:*compilation-unit-environment*.
Holds the current compile-file environment. It should only ever be set to either nil or to an environment created by make-compile-file-environment.
This environment has a lexical part and a global part; the lexical part is managed by augment-environment and the *-information functions, and the global part is managed by ce-putprop and ce-get. Whenever *compile-file-environment* is set to a compile-file-environment, ce-putprop will store to properties within this environment, rather than in some global manner, for example using (setf get). Also, ce-get will consult this environment and if succesful will return the property stored therein, before then trying to get the property globally.
See environments.html for more information on environments.
Variable, system package
The value of this variable is the process which is currently running. After the process module is loaded (either automatically, or because (require :process) is evaluated), the value will be non-nil. This should be treated as a read-only variable.
See also *current-thread*. See multiprocessing.html for general information on the multiprocessing facility in Allegro CL.
Variable, system package
Use of this variable is deprecated. Call current-thread instead. If used, a warning will be signaled. the old description of this variable follows.
The symbol sys:*current-thread* names a symbol-macro which when executed returns the current thread. Note, despite being called a "variable", this symbol does not have a value. Evaluating the symbol results in the current thread as a return value, but applying boundp to this symbol returns nil and applying symbol-value to it results in an error. (We call it a "variable" because we do not really have a documentation category that fits it otherwise.)
sys:*current-thread* is implemented as a symbol-macro because doing so is much more efficient, getting the value in just several instructions without even needing, on some platforms, a memory reference.
The distinction between thread and process is arcane, but the most important thing is this:
Thread objects are simple static structures that contain the information used to schedule.
Process objects are clos instances, allowing the application to define subclasses for whatever purpose.
See also *current-process*. See multiprocessing.html for more information on multiprocessing.
Variable, system package
This special variable is bound to t whenever multiprocessing scheduling is disabled. For example, the system binds this variable to t during the execution of the forms within a without-scheduling form.
This variable is read-only and should never be set or bound by user code. Examining the value of this variable is most useful when executing code that may operate in an asynchronous manner relative to multiprocessing.
See multiprocessing.html for general information on multiprocessing in Allegro CL.
Variable, system package
This variable holds the returned value of the last evaluation by emacs when using the emacs-lisp interface (just as * holds the returned value of the last evaluation in Lisp).
See eli.html for information on the emacs-lisp interface.
Variable, system package
Holds the current evaluation environment, defined by ANSI as being the environment which compile-file sets up when it does compile-time evaluation.
If the compiler does compile-time-eval (not compile-time-too) processing, then the environment may be an evaluation environment, established by the compiler. All operations on a compilation environment held by *evaluation-environment* are the same as an evaluation environment, with the exception that the environment is consulted for ce-get operations before trying the global running environment. This gives the compile-time-eval environment a "read-only" feel, and ensures that definitions created while in this mode are persistent after the environment is disestablished.
See environments.html for more information on environments.
Variable, system package
Forms can be pushed onto this variable to ensure that they are eval'd before exit actually exits the lisp. During the processing time this variable is set to nil, so that if any of the forms cause an error the exit operation can finish anyway. The usual way to exit Lisp is to call exit although there are many actions which cause that function to be called (e.g. calling the top-level comand :exit or, on Windows, clicking on the Console or Project Window close buttons.) In the example, we show what a list of forms might look like and have one of the forms cause a break (aborting the exit). Note that the value of the variable is nil after the failed exit.
USER(38): sys:*exit-cleanup-forms*
NIL
USER(39): (setq sys:*exit-cleanup-forms*
(list '(format t "Exiting!!!~%")
'(break)))
((FORMAT T "Exiting!!!~%") (BREAK))
USER(40): :exit
Exiting!!!
Break: call to the `break' function.
Restart actions (select using :continue):
0: return from break.
1: Really exit (:no-unwind t)
[1c] USER(41): :res
USER(42): sys:*exit-cleanup-forms*
NIL
USER(43):Variable, system package
The function get-entry-points takes a vector of names (strings) of foreign entry points and a vector of element type (unsigned-byte 32) or (unsigned-byte 64) as arguments and fills the unsigned-byte vector with addresses. If a name provided does not correspond to an entry point, the unsigned-byte vector element corresponding to the name is filled with the value of this variable.
Use of get-entry-points is deprecated. Only get-entry-point should be used. (The latter function returns nil if the single name passed as its argument does not correspond to an entry point. Therefore it makes no use of this variable or its value.)
See foreign-functions.html for information on the foreign function interface.
Variable, system package
Holds the current interpreted environment. During interpreter operation, this variable is lambda bound to new augmented environments (each stemming from the same base) and, when a new interpreted lexical closure is entered, an environment with a new base.
Usually, this variable holds an evaluation environment. All lexical actions are with respect to this environment object, and all global operations (ce-get and ce-putprop) are global. No properties are stored into an evaluation environment.
See environments.html for more information on environments.
Variable, system package
This variable and *language-suffixes* are used in foreign-function name conversion. The value of each is a (possibly empty) alist of a language and a string to prepend (*language-prefixes*) or postpend (*language-suffixes*) to the basic name in order to produce the equivalent name in the language. Some earlier operating systems had linkers which prepended an underscore ("_") to C names (language :c) and some linkers still postpend an underscore to Fortran (language :fortran) names.
See foreign-functions.html for more information on the foreign functions facility.
Variable, system package
This variable and *language-prefixes* are used in foreign-function name conversion. The value of each is a (possibly empty) alist of a language and a string to prepend (*language-prefixes*) or postpend (*language-suffixes*) to the basic name in order to produce the equivalent name in the language. Some earlier operating systems had linkers which prepended an underscore ("_") to C names (language :c) and some linkers still postpend an underscore to Fortran (language :fortran) names.
See foreign-functions.html for more information on the foreign functions facility.
Variable, system package
The value of this variable is a search list used by load (and equivalents like the :ld top-level command) to find a file to load when incomplete pathname information is supplied.
See Search lists in loading.html for a description of the search list algorithm and structure.
While the value may vary from platform to platform, the initial load search list is typically quite simple, with a value like
(#p"" #p(:type "fasl") #p(:type "cl") #p(:type
"lisp"))That tells what file type to look for when no type is provided.
See loading.html for general information on loading and search lists in Allegro CL.
Variable, system package
The value of this variable is alist witch the keys being keywords that describe the patch category and the values being lists describing the individual patches loaded into the image. For a patch file to be noticed, it must contain a defpatch form. All official Allegro CL patches contain such a form.
The values in the alist are (as said above) themselves lists, with four elements:
A string providing the name of the patch that an attempt was made to load.
The version of the patch (an integer).
A string providing a short description of the patch.
nil if the patch was loaded sucessfully or a string explaining why it was not loaded.
Most patch names are encoded with the first letter indicating the release, the second the area in Lisp affected, and so on. Here is an example of several entries (you may not see these exact patches and the first letter, m, for example, means release 10.1), first some :compiler patches and then a few :lisp patches:
((:compiler ("mb015" 1 "Fix tail funcall for large-stack functions." nil)
("mb014" 1 "Fix esoteric compilation failure of gc-info." nil)
("mb013" 1 "Fix array creation with fixnum-returning dimension function."
nil)
("mb012" 1 "Add source-debug-info for defmethod forms." nil)
("mb011" 1 "Fix source-level-debug generation for (setf values)." nil)
("mb010" 1 "Fix source-level-debug block placement." nil)
("mb009" 1 "Fixes a bug in source-level-debugging related to handler-case."
nil)
("mb008" 1 "Fix two source debug info compile bugs." nil)
("mb007" 1
"bitwise `and' operations compile into more efficient code on intel chips."
nil)
...)
(:lisp ("ma041" 1 "Speed up and enhance vector sorts." nil)
("ma040" 1 "Fix declarations return from sys:function-information." nil)
("ma039" 1 "Add excl::without-syncsig-trap to support test suites." nil)
("ma038" 1 "Fix count and count-if when looking from-end an lists." nil)
("ma037" 1 "Fix a timing window for asegv when changing class in smp lisps."
nil)
...)Note particularly the last value of the four in the individual patch lists: nil if the patch was loaded sucessfully. All these patches were loaded. If the load was unsuccessful, there would be a string explaining why it was not loaded. If the last value is not nil, the patch was not loaded and whatever it is designed to fix/change is unfixed/unchanged.
Variable, system package
The value of this variable is a search list used when require is called.
See Search lists in loading.html for a description of the search list algorithm and structure. Also see loading.html for general information on loading and search lists in Allegro CL.
The initial value of *require-search-list* does not include . (meaning look in the current directory). Users can add that if desired. If added, it should be placed at the end to avoid mistakenly loading files that happen to have the same name as system files (which are in directories such as [Allegro directory]/code/)
Variable, system package
If true, the value of this variable should be a list of functions that will be called by the internal functions that do comparisons that generate redefinition warnings and determine the name of a file to which an Emacs buffer is open. The functions will also be called by eq so the input-filename (required) argument to compile-file will be frobbed and it is the frobbed file (rather than the actual argument) that will be compiled.
The functions in the list should take one argument, a pathname, and return one value, also a pathname.
A pathname passes if each function in the list, when passed that pathname, returns it exactly (that is, the returned pathname is eq to the argument pathname). If a pathname does not pass, one of the functions in the list returns a pathname which is not eq to its argument pathname. When that happens, the non-eq pathname becomes the new candidate pathname, passed to functions in the list in order, starting with the first. The process stops when a pathname that results from the process passes, with each function returning it exactly without any modification.
The first function, for example, might check to see whether the directory-namestring of the pathname starts with either "/tmp_mnt" or "/TMP_MNT". If it does, the pathname is modified so the "/tmp_mnt" or "/TMP_MNT" is stripped off and the modified pathname is returned. If it does not, the pathname is returned unchanged. Thus a pathname with namestring "/tmp_mnt/mymachine/usr/me/foo.cl" is first modified to a pathname with namestring "/mymachine/usr/me/foo.cl". When this pathname is passed to the first function, it is returned unchanged.
The second function might check that all alphabetic characters in the namestring are upcased, modifying the pathname so that it is true if it is not. So the second function, passed the result of the first changes it to a pathname with namestring "/MYMACHINE/USR/ME/FOO.CL". Since this would not be eq to the argument, that pathname is passed once again to the first function. But since the namestring does not start with "/tmp_mnt" or "/TMP_MNT", the first function returns it unchanged, as does the second function, since the namestring has only uppercase letters. If there are only two functions, the process is now done.
It is important that the function return a pathname eq to the argument (i.e. return the argument unchanged) if no frobbing is required. If a function creates a new pathname, equal, or equalp but not eq to the argument, frobbing will never stop.
The initial value of this variable is a list containing as its only element the symbol naming the function tmp-mnt-frobber.
See source-file-recording.html for general information on source file recording.
Variable, system package
The value of this variable is a list of strings denoting file types. The types are merged with the file-name arguments to the function compile-file, the top-level commands :cf and :cload, and the function compile-file-if-needed. nil is accepted as a member of the list. It means no type.
See compiling.html for general information on the compiler in Allegro CL. See Compile-file in that document for information on the implementation of compile-file.
Variable, system package
The value of this variable should be a pathname object naming a directory. This directory will be used as the temporary directory by temporary-directory.
The value of this variable can also be nil. If it is nil, when temporary-directory is called, it will determine a suitable value and make it the value of this variable.
temporary-directory should be used to access the value of this variable. It tests (using probe-file) whether the value of this variable is nil or an invalid directory pathname, resetting the value to a suitable directory pathname if probe-file returns nil and returning this variable's value if probe-file returns true. See temporary-directory for details on how a new directory is chosen if necessary.
The initial value of this variable is nil. In images created by dumplisp, build-lisp-image, or generate-application, it may happen that the initial value in an image is a valid directory pathname set in some fashion during image creation. In that case, that directory will be used (even if this is not the intention of the user).
Variable, system package
Initially t, which means on Unix systems that the pathname, directory, and parse-namestring functions will expand the tilde (#~) character into the user's home directory. Setting this variable to nil causes no such expansion to occur. Windows systems ignore this variable.
Variable, system package
The value of this variable is the name of the shared system library (e.g. .so, .dylib, .dll) file that will be passed to load when the deflate module is loaded. If it is a list then we attempt to load each element until one succeeds or the end of the list is reached in which case and error is signaled. See Support for gzip compression and decompression in miscellaneous.html.
Copyright (c) Franz Inc. Lafayette, CA., USA. All rights reserved.
|
Allegro CL version 11.0 | ||||||||