|
Allegro CL version 11.0 | ||||||||
variable, excl package
Initially nil but can be set before loading the :ssl module to specify the name of the Allegro CL SSL shared library. The standard names for the library are:
aclssl: for OpenSSL 1.0 and 8-bit character Lisps (such as alisp8 and mlisp8).aclissl: for OpenSSL 1.0 and 16-bit character Lisps (such as alisp and mlisp).aclssl11: for OpenSSL 1.1 and 8-bit character Lisps (such as alisp8 and mlisp8).aclissl11: for OpenSSL 1.1 and 16-bit character Lisps (such as alisp and mlisp).aclssl3: for OpenSSL 3.x and 8-bit character Lisps (such as alisp8 and mlisp8).aclissl3: for OpenSSL 3.x and 16-bit character Lisps (such as alisp and mlisp).NOTE: the initial release of ACL 11.0 had different names for OpenSSL 3.0 and 3.1 libraries. Because the OpenSSL libraries for all 3.x versions are the same, there was no need for different ACL SSL shared libraries. A patch in early Feb 2024 unified the 3.x library names on all platforms as specified above.
If the value of *ssl-library-names* is set prior to evaluating (require :ssl), the value of this variable must be set to the appropriate library name (a string). If the value of *ssl-library-names* is not set but the environment variable ACL_SSL_LIBRARY_NAMES is set prior to starting Allegro CL, the appropriate one of the environment variable ACL_ACLSSL_NAME (for 8-bit Lisps) and ACL_ACLISSL_NAME (for 16-bit Lisps) must also be set and its value is used to set the value of this variable. After the :ssl module is loaded, the value of this variable is the name of the library actually loaded.
variable, excl package
If the value of this variable is true when SSL libraries are loaded (typically by evaluating (require :ssl)), information on the loading process is printed. That information may be useful if loading the SSL libraries fails for any reason.
The value of this variable is initially nil. If it is nil when (require :ssl) is evaluated, the environment variable ACLSSL_VERBOSE will be queried and if set, the variable will be set to true.
If the value is :quiet, then in a generated application all SSL progress messaged will be suppressed when the application is started.
OpenSLL is described in Secure Socket Layer (SSL) in socket.html.
variable, excl package
Initially nil. If nil when the :ssl module is loaded, the environment variable ACL_OPENSSL_VERSION is checked. Its legal values are "10" and "11", meaning OpenSSL 1.0 and OpenSSL 1.1 respectively. If it is set, its value becomes the value of this variable. If both this variable is nil and the environment variable is unset, the system tries to determine the OpenSSL version in other ways as described below.
If the value is set, it must be to one of the following values prior to evaluating (require :ssl):
(1 0): indicating OpenSSL version 1.0.(1 1): indicating OpenSSL version 1.1.(3 0): indicating OpenSSL version 3.0.(3 1): indicating OpenSSL version 3.1.As described in the section Secure Socket Layer (SSL) in socket.html, this variable is ignored if either the environment variable ACL_SSL_LIBRARY_NAMES is set or the variable *ssl-library-names* is non-nil. If neither has a value, this variable is looked at when OpenSSL functionality is being loaded to determine the version of OpenSSL that is required. (If this variable is also nil, the Lisp calls out to the operating system to determine the OpenSSL version, as described in the Secure Socket Layer (SSL) section in socket.html.)
The value of this variable is not modified when the :ssl module is loaded, so it remains nil if it was nil when (require :ssl) was evaluated. To determine the version of OpenSSL actually loaded, call the function openssl-version
variable, excl package
The value of this variable should be a (possibly empty) list of character objects. Any character on this list will be allowed in a word of a logical pathname even if the ANSI spec does not permit such characters to be used. (As specified by the ANSI spec, words in logical pathnames must consist of alphabetic characters, decimal digits, and the minus sign. Not allowed are characters such as underscore (#\_).)
For example, consider the namestring "expert:;engine;steam_power.lisp". Because it contains an underscore, it cannot (per the ANSI spec) be parsed as a logical pathname. Instead, it is parsed as a physical pathname (with a very odd but not, on UNIX, illegal name):
cl-user(102): *additional-logical-pathname-name-chars*
nil
cl-user(103): (describe (pathname "expert:;engine;steam_power.lisp"))
#p"expert:;engine;steam_power.lisp" is a structure of type pathname. It has
these slots:
host nil
device :unspecific
directory nil
name "expert:;engine;steam_power"
[...]But if #\_ is added to the list bound to \*additional-logical-pathname-name-chars\*, "expert:;engine;steam_power" does parse as a logical pathname:
cl-user(104): (push #\_ *additional-logical-pathname-name-chars*)
(#\_)
cl-user(105): (describe (pathname "expert:;engine;steam_power.lisp"))
#p"expert:;engine;steam_power.lisp" is a structure of type logical-pathname.
It has these slots:
host "expert"
device nil
directory (:relative "engine")
name "steam_power"
[...]The initial value of this variable is nil, which is the value necessary for ANSI compliance. Note that logical pathname operations will not be portable if the value of this variable is non-nil.
See Logical pathnames: general implementation details in pathnames.html for more information on this aspect of logical pathnames in Allegro CL.
variable, excl package
This variable stores the value set by in-case-mode. Initially, its value is :common when the case mode is :case-insensitive-upper (ANSI mode) and :local when the case mode is :case-sensitive-lower. This value should not be set directly. See in-case-mode for further details.
variable, excl package
The name of the variable has been changed to *required-top-level-bindings*. This variable still exists with the name *cl-default-special-bindings* for backward-compatibility but its value is a symbol macro which expands to signal a warning and then use the value of *required-top-level-bindings*. See that variable for further information.
variable, excl package
If true,
(cl:clear-input *terminal-io*)is evaluated when an error is encountered, causing any pending input to be flushed. The initial value is t in standard images.
See the example in Break levels in top-level.html.
variable, excl package
If the value of this variable is true, in-package will work as it was specified in CLtL-1 rather than as it is specified in ANSI. That is, it will evaluate its required argument, it will accept the nicknames and use keyword arguments, and it will create a package if its required argument does not denote an already defined package. (ANSI calls for cl:defpackage to do what was done by in-package in CLtL-1.)
We provide this variable to allow you to use existing source files which depend on CLtL-1 in-package behavior but we recommend that you modify the files to use ANSI behavior as soon as possible. The initial value of this variable is nil.
variable, excl package
Starting in Allegro CL release 6.0, the new fwrapper facility, described in fwrappers-and-advice.html, replaces the advice facility, and continued use of the advice facility is deprecated.
If true, all advice will be automatically compiled when defined. (compile-advice can be used to compile advice added when the value of this variable is nil.)
See also fwrappers-and-advice.html for general information on the new fwrapper facility and the older, now deprecated, advice facility in Allegro CL.
variable, excl package
The effect of this variable depends on whether or not the image being run is a standard runtime image (with :runtime-standard on the *features* list).
If the value of this variable is true and the running Lisp image does not include the compiler, a warning will be printed whenever compile is called stating that the compiler is not available. If the value of this variable is nil, no warning will be printed.
A standard runtime image is built by generate-application or build-lisp-image with the runtime keyword argument specified :standard. (That is the default value for the argument when generate-application is called.) Such images have :runtime-standard on the *features* list. See runtime.html.
In standard runtime images, it is an error to call compile or compile-file directly or indirectly. The value of this variable is ignored and thus does not affect whether or not an error is signaled. The condition signaled is runtime-restriction.
See compiling.html for information on the compiler.
variable, excl package
When true, this variable dictates the behavior of slot-makunbound as to whether it conforms to the MOP in calling slot-makunbound-using-class with a symbol as its last argument (non-conforming) or with an effective-slot-definition (which is conforming). Its initial value is t which indicates a conforming behavior. Setting the variable to nil causes pre-11.0 non-conforming behavior by passing the name of the effective-slot-definition rather than the effective-slot-definition as its last argument.
Note: This variable is temporary for the purpose of aiding programs into a transition from non-conforming to conforming code. There is no guarantee that it will remain available. It may be removed in future versions of Allegro CL.
See CLOS slot manipulators in implementation.html for more information about the use of this variable and examples of its use.
variable, excl package
The value of this variable is the keyword denoting the current case mode. The value of this variable is changed by set-case-mode and should not be set in any other way (modifying the value of this variable directly does not change the case mode and has undefined consequences, most of them bad). Its initial value depends on how Lisp was installed. Some pre-built images (mlisp and mlisp8) use :case-sensitive-lower and others (alisp and alisp8) use :case-insensitive-upper. The value may also be specified when an image is built using build-lisp-image or generate-application.
See case.html for general information on case in Allegro CL.
See also the descriptions of the related functions and variables *ignore-package-name-case*, set-case-mode, and convert-mixed-case-symbols.
variable, excl package
This variable is no longer used. Instead, Daylight Saving Time information is taken from the operating system. The value of this variable is ignored. It is maintained for backward compatibility only but setting it has no effect on the behavior of Allegro CL.
variable, excl package
This constant has value 4, which is the universal time value for Friday (see decode-universal-time). See also *decoded-time-monday*, *decoded-time-tuesday*, *decoded-time-wednesday*, *decoded-time-thursday*, *decoded-time-saturday*, and *decoded-time-sunday*.
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This constant has value 0, which is the universal time value for Monday (see decode-universal-time). See also *decoded-time-tuesday*, *decoded-time-wednesday*, *decoded-time-thursday*, *decoded-time-friday*, *decoded-time-saturday*, and *decoded-time-sunday*,
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This constant has value 5, which is the universal time value for Saturday (see decode-universal-time). See also *decoded-time-monday*, *decoded-time-tuesday*, *decoded-time-wednesday*, *decoded-time-thursday*, *decoded-time-friday*, and *decoded-time-sunday*.
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This constant has value 6, which is the universal time value for Sunday (see decode-universal-time). See also *decoded-time-monday*, *decoded-time-tuesday*, *decoded-time-wednesday*, *decoded-time-thursday*, *decoded-time-friday*, and *decoded-time-saturday*.
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This constant has value 3, which is the universal time value for Thursday (see decode-universal-time). See also *decoded-time-monday*, *decoded-time-tuesday*, *decoded-time-wednesday*, *decoded-time-friday*, *decoded-time-saturday*, and *decoded-time-sunday*.
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This constant has value 1, which is the universal time value for Tuesday (see decode-universal-time). See also *decoded-time-monday*, *decoded-time-wednesday*, *decoded-time-thursday*, *decoded-time-friday*, *decoded-time-saturday*, and *decoded-time-sunday*,
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This constant has value 2, which is the universal time value for Wednesday (see decode-universal-time). See also *decoded-time-monday*, *decoded-time-tuesday*, *decoded-time-thursday*, *decoded-time-friday*, *decoded-time-saturday*, and *decoded-time-sunday*,
*decoded-time-monday* -> 0
*decoded-time-tuesday* -> 1
*decoded-time-wednesday* -> 2
*decoded-time-thursday* -> 3
*decoded-time-friday* -> 4
*decoded-time-saturday* -> 5
*decoded-time-sunday* -> 6See Day and date calculation functions and their relation to time zones in miscellaneous.html for more information on this and related functions.
variable, excl package
This variable is not supported. Setting it has no effect. The default for the external-format argument of functions like open where no specific value is specified as the default is the value of (locale-external-format *locale*) (see *locale* and locale-external-format).
General information on international character set support in Allegro CL is in iacl.html.
variable, excl package
This variable determines whether delete uses the in-place style of modification to change a simple vector, or if it makes a copy of the old vector after the matching slots have been compressed out of it. It serves as the default value to a new keyword argument to delete.
To set this variable to nil causes the contents of the vector to change as usual, but the size of the original vector is never modified. Instead, a copy is made and given the correct new size, and is returned from delete.
To set this variable to true in an SMP Lisp is very dangerous; it could result in the Lisp's heap becoming corrupted if any two threads are working on the same object at the same time. (Though unlikely, this can happen in a non-SMP multiprocessing Lisp as well.) An in-place modification of the size of a vector could remove the protections in code which is unsafe but correct by causing the second thread to see a different size than the underlying storage actually contains. If (setf aref) is used in this manner and stores beyond the current end of the array, codewalkers and especially the garbage-collector could then see an inconsistent heap and the lisp could die with a gc-error. The code could be as innocuous as
(declare (optimize speed))
(dotimes (i (length vec))
(setf (aref vec i) t)))If, in an SMP Lisp, another thread has called delete and the in-place option is set, then the vector may change out from under this thread's loop, and the (setf aref) clauses may write off the end of the array, causing death.
While heap corruption will not happen when the sequence argument is a list, other unspecified and unexpected behavior can result.
Deleting in place is safe when only one thread traverses a sequence.
This variable is set globally, and is not bound on any threads, but is not declared non-bindable; it may be bound and the value used based on user needs.
The initial value is t in non-SMP Lisps and nil in SMP Lisps.
See cl:delete, cl:delete-if, cl:delete-if-not, cl:delete-duplicates: multiprocessing issues in implementation.html for details.
variable, excl package
The value of this variable should be a list of functions of one argument (the character stream open to the file specified to dribble-bug) which will be called when dribble-bug is called. The items on the list will be passed to funcall. Use push (or some equivalent) to add items to the list. See dribble-bug.
variable, excl package
The value of this variable should be a function that accepts one argument. (It should be acceptable as the first argument to funcall.) The argument will be a port for a socket connection. The function is called to initialize the socket that is used to communicate with Emacs when the Emacs-Lisp interface is started.
The initial value is effectively
(lambda (port)
(acl-socket:make-socket :connect :passive :local-port port))which merely creates a local, passive socket on port. (The actual value is a compiled function object.)
To limit connection to the local machine, use a value similar to this:
(lambda (port)
(acl-socket:make-socket :connect :passive :local-port port
:local-host "127.0.0.1"))For more information see the documentation on make-socket.
variable, excl package
If true, executing code that violates package-locking (see package-lock) or package-definition-locking (see package-definition-lock) will signal errors and compiling a file containing such code will signal warnings. If nil, such code will execute without package-locked-errors or compile-time warnings.
See also without-package-locks.
See also packages.html for general information on packages in Allegro CL.
variable, excl package
This variable controls how to handle errors which occur during printing. When this variable is true, errors in printing cause informative output to be printed, but do not cause the debugger to be invoked.
Printing follows all of the rules of condition-system handling. If an unhandled condition results in a call to the debugger, a new break level is established, and the user is expected to deal with the low-level printer error (which usually results from a bad print-method or a trashed object).
Users typically do not want to debug a bad object or print method, because it is usually part of a larger problem which is either more important or is the cause of the bad printing. So, when this variable is true, those errors result in the printing of an enclosed object that describes the problem. The description includes information about the condition signaled. For example,
user(1): (format nil "~{abc~:}")
"#<Printer Error, obj=#x30000bc5: Insufficient format args>"
user(2): It is probably desirable to have *enclose-printer-errors* bound to true when printing objects to display windows as errors may cause the system to appear to hang (since the error will be signaled in the listener or the console, which may not be visible).
*enclose-printer-errors* has a default binding of t. This is a controversial decision, because it could be interpreted as a non-conformance to the ANSI condition handling rules. However, it is set to true by default to protect against unwanted break-level processing in user code, especially when non Allegro CL printing tools are used. If this default is not desired, the value of this variable can be set to nil.
variable, excl package
Starting in release 11.0, defstruct accessors are implemented in a type-safe way as described in cl:defstruct implementation in implementation.html. This variable, if true, continues to cause the 10.1 and earlier, not type-safe behavior to be used. Note a 10.1 patch defines this variable (for compatibility) but make no use of it in that release.
This variable is normally nil and should remain nil for most situations. When true, old non type-safe defstruct accessors are installed when a defstruct form is macroexpanded, rather than the new type-safe defstruct accessors.
Note: If this variable is true when either a dribble-bug or a print-system-state is run, they will note that expansions and compilations of defstruct accessors will be unsafe and you may be asked to recompile and rerun code with this variable set to nil.
Example:
This example demonstrates the type-safety of the default defstruct slot readers and compares it with the 10.1 defstruct slot-readers, along with the effect of using them in error.
;;; We start with normal operation, demonstrating safe defstruct accessors:
;;;
cl-user(1): (defstruct foo1 a b)
foo1
cl-user(2): (defstruct bar1 a b)
bar1
;;; Note that the accessors are "safe":
;;;
cl-user(3): #'foo1-a
#<Closure safe-defstruct-accessor [foo1] @ #x2108a332>
cl-user(4): #'bar1-a
#<Closure safe-defstruct-accessor [bar1] @ #x2108bd62>
cl-user(5): (setq foo1 (make-foo1 :a 10 :b 20))
#S(foo1 :a 10 :b 20)
cl-user(6): (setq bar1 (make-bar1 :a 30 :b 40))
#S(bar1 :a 30 :b 40)
;;; Note also that a foo1 accessor can't access a bar1 struct, and vice versa:
cl-user(7): (foo1-a bar1)
Error: Attempt to reference #S(bar1 :a 30 :b 40) which is not of type
foo1.
[condition type: type-error]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this (lisp) process.
[1] cl-user(8): (bar1-a foo1)
Error: Attempt to reference #S(foo1 :a 10 :b 20) which is not of type
bar1.
[condition type: type-error]
Restart actions (select using :continue):
0: Return to Debug Level 1 (an "abort" restart).
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this (lisp) process.
[2] cl-user(9): :res
;;; Now let's start over and define some unsafe struct accessors:
;;;
cl-user(10): (let ((excl:*expand-defstruct-accessors-unsafely* t))
(defstruct foo2 a b)
(defstruct bar2 a b))
bar2
;;; Note that the accessors look like the 10.1 versions:
cl-user(11): #'foo2-a
#<Closure defstruct-accessor @ #x210930ba>
cl-user(12): #'bar2-a
#<Closure defstruct-accessor @ #x210930ba>
;;; ... and, like 10.1, cross-accessing poses no problem for these accessors.
;;;
cl-user(13): (setq foo2 (make-foo2 :a 10 :b 20))
#S(foo2 :a 10 :b 20)
cl-user(14): (setq bar2 (make-bar2 :a 30 :b 40))
#S(bar2 :a 30 :b 40)
cl-user(15): (foo2-a bar2)
30
cl-user(16): (bar2-a foo2)
10
cl-user(17): variable, excl package
The initial value of this variable is t. This variable provides the default value for the fasl-circle argument to compile-file. Note that when that argument is nil, compilations may be faster but are technically outside the Common Lisp standard.
For general information on compiling in Allegro CL, see compiling.html. See Compile-file in that document for more discussion of compile-file in Allegro CL.
variable, excl package
This variable specifies the file type of files containing compiled Lisp code. Its initial value is fasl. The function compile-file, and the top-level commands :cf and :cload will generate files of this type.
See the description of compile-file in Compile-file in compiling.html.
See also compiling.html for general information on compiling in Allegro CL.
variable, excl package
The initial value of this variable is a list of six 0's. The value should always be a list of six fixnums. When statistics on compilation of format forms is being kept (see verify-format-argument-count-switch), the various values in the list are incremented as format forms are seen and analysed by the compiler. The function format-arg-count-stats prints the collected values. Calling that function with the value :reset as the first argument causes the value of this variable to be set to a list of six 0's.
See Checking format forms during compilation
in miscellaneous.html for more information.
variable, excl package
The value of this variable determines how the :gb18030 external-format deals with transcoding errors. It is one of the following values:
nil: Ignore transcoding errors silently.
:warn: Signal a warning of class gb-18030-transcoding-warning.
:count: Replace the value of this variable with a count of transcoding errors.
an integer: Same as :count but continue counting from the given integer value.
:collect: Replace the value of this variable with a list of error markers. For each error signalled while converting characters to octets, push the offending character onto the list.
For each input error, push a list of the offending octets onto the list.
a cons: Same as :collect but continue pushing onto the given list.
:error (or any other value not above): Signal an error of class gb-18030-transcoding-warning.
In all cases insert the gb-18030-transcoding-warning character to replace the offending character or octets in the transcoded stream.
See Strict external formats which do not allow improper characters in iacl.html for more information on the :utf-8s external format, international characters and external formats in general.
variable, excl package
If the gsgc switch :hook-after-gc is true, then the value of this symbol, if true, will be funcall'ed immediately after a scavenge. Thus the value should be a function that takes five arguments:
a boolean which will be true if the gc just completed was a global gc,
a fixnum equal to the number of bytes copied to newspace,
a fixnum equal to the number of bytes copied to oldspace,
a fixnum which is the efficiency as a percentage (see Note 1 just below),
and a fixnum which is the number of bytes that still must be allocated (see Note 2 just below).
Note 1: Efficiency is the ratio of non-gc cpu time to total cpu time.
Note 2: Garbage collections usually happen because an object must be allocated but there is not enough free space to do so. The fifth argument gives the size of not-yet-allocated objects.
Because the amount of free space needed (as specified by the last returned value) must be available, modifying the amount of free space in newspace as a side effect of executing *gc-after-hook* code is dangerous. Lisp can fail if there is in fact inadequate free space to allocate the object whose allocation triggered the gc. This means the code should not cons (or should minimally cons) and should not reduce the size of newspace with, for example, a call to resize-areas. While there may be cases where a carefully coded call to resize-areas in a gc after hook is appropriate, the rule of thumb is do not call that function.
The initial value of this variable is a function that implements the global gc behavior described in Global garbage collection in gc.html and in the description of *global-gc-behavior*. The function is named by the internal symbol excl::default-gc-after-hook. If you wish to change the value of this variable and preserve the global gc behavior described below, set the value of this switch to something like the following (note the use of a feature to prevent recursion if this code is run twice):
;; This form should be placed in a location (such as a file)
;; where it can be compiled.
;; The inital value of excl:*gc-after-hook* is a function named by
;; the symbol excl::default-gc-after-hook but we bind the value
;; to allow for an already modified function whose behavior
;; is being preserved.
(let ((continuation excl:*gc-after-hook*))
(if (null (excl:featurep :my-gc-after-hook-added))
(progn
(push :my-gc-after-hook-added *features*)
(setq excl:*gc-after-hook*
#'(lambda (global new old efficiency to-be-allocated)
; ... code to do what you want after a gc ....
(when continuation
(funcall continuation global
new old efficiency to-be-allocated))
; ... more of your code if desired
)
))))See also gc.html for general information on garbage collection Allegro CL, including information on gsgc switches and parameters. See section Global garbage collection
in that document for information on global garbage collection.
variable, excl package
When a package is defined with defpackage or make-package while the variable *regard-package-names-as-flat* is true and no value was specified for the :flat option/argument, then the primary package name will be added to the list which is the value of this variable. This allows packages which may unexpectedly not have hierarchical nicknames to be identified. (When *regard-package-names-as-flat*, it affects all package definitions, perhaps including those which were not intended to have flat nicknames. But an explicit value for the :flat option/argument implies intention on the part of the user and so such packages are not added to this list.
Users should not modify the value of this variable.
cl-user(1): (setq excl:*regard-package-names-as-flat* t)
t
cl-user(2): excl:*global-flat-package-option-used*
nil
cl-user(3): (defpackage :foo)
Warning: Defining :foo with :flat attribute because
*regard-package-names-as-flat* is non-nil. See documentation
on cl:defpackage in implementation.htm.
#<The foo package>
cl-user(4): excl:*global-flat-package-option-used*
("foo")
cl-user(5): (defpackage :bar (:flat t)) ;; when :flat is specified, no warning
#<The bar package>
cl-user(6): excl:*global-flat-package-option-used*
("foo") ;; and the package is not added to this list.See cl:defpackage and cl:in-package, both in implementation.html, for more information on extensions to defpackage and make-package. Flat if hierarchical packages are discusses in Hierarchical Packages
in packages.html.
variable, excl package
This global variable controls the global garbage collection behavior. Depending on its value, global garbage collections do or do not occur automatically and the user is or is not warned about global gc's.
Note: this variable works as described only if the value of the variable *gc-after-hook* is its initial value or a function that preserves the initial behavior (of recording bytes tenured correctly). See the description of *gc-after-hook* for information on modifying its value in a way that preserves its initial behavior.
The possible values for global-gc-behavior are given in the following table:
:auto: Whenever the number of bytes tenured since the last global gc exceeds the value of the variable *tenured-bytes-limit*, a global gc will be triggered automatically. After the global gc, the tenured byte count is set to 0.
:warn: Whenever the number of bytes tenured since the last global gc or warning exceeds the value of the variable *tenured-bytes-limit*, a warning will be printed to terminal-io saying:
Warning: [xxx] bytes have been tenured; (gc t) is recommended
No global gc will be triggered; users have to cause a global gc themselves. A global gc can be triggered immediately by evaluating the form (see the description of gc)
(excl:gc t)A global gc will occur after the next scavenge if you evaluate the following form:
(setf (sys:gsgc-switch :next-gc-is-global) t) (The switch will be reset to nil after the global gc.) Note that you do not have to act on the warning. Lisp will run perfectly well with no global gc's except that the process size may grow larger than necessary (unless, of course, the process grows so large that the paging overhead becomes prohibitive or you run out of swap space).
:auto-and-warn: The behavior combines that of :auto and :warn. A global gc is triggered when the number of bytes tenured exceeds the value of *tenured-bytes-limit* and a warning message, explaining that a global gc is occurring, is also printed. The warning message is designed to tell the user why Lisp seems to have stopped for a while (global gc's can take several minutes to complete).
A list of 2 or 3 elements: The contents of the list are, in order:
timeout -- a positive integer, specifying a number of seconds
factor -- a real <= 1.0
verbose -- (optional) t or nil
This value should not be used in SMP Lisps (determining when the system is idle is ill-definied in an SMP Lisp). If the *global-gc-behavior* has a value of this type, when more than *tenured-bytes-limit* bytes have been tenured since the last global gc, a global gc will be triggered automatically the next time the system has been completely idle for timeout seconds. But if *tenured-bytes-limit* is exceeded by factor, a global gc will happen anyway. If the boolean is present and true, the mechanism will print its actions to *initial-terminal-io*.
nil: No warning will be printed and no global gc will be triggered automatically regardless of the number of bytes tenured.
Note that binding this variable will likely not have the desired effect. Lisp usually runs with multiprocessing enabled (since that is required by the Emacs-Lisp interface). If you bind this variable in one process, the binding will not be seen by another process which could swap in and cause a global gc.
See gc.html for more information on garbage collection and gsgc parameters. See particularly section Global garbage collection in that document for information on global garbage collection.
variable, excl package
If the value of this variable is true, then the case of characters in single-case package names and nicknames is ignored by the reader when looking up qualified symbols. This variable is initially nil, but you may find it useful to give this variable a true value if you choose to operate in one of the case-sensitive modes.
See also case.html for general information on case in Allegro CL. And see *current-case-mode*, set-case-mode, convert-mixed-case-symbols.
variable, excl package
This constant has the value of IEEE double-float infinity. It is a legal floating-point value. In arithmetic operations, it produces double-float infinities of appropriate sign or NaNs, but a finite number (in fact zero) only when divided into a finite number. See the linked discussion for more details.
Infinities like this one can result from normal arithmetic operations, such as a division by zero in a function with types declared and compiled so trust-declarations-switch is true, but that same call run interpreted may instead signal an error.
See Floating-point infinities and NaNs, and floating-point underflow and overflow in implementation.html. Also see *negative-infinity-single*, *infinity-single*, *negative-infinity-double*, *nan-double*, and *nan-single*
variable, excl package
This constant has the value of IEEE single-float infinity. It is a legal floating-point value. In arithmetic operations, it produces infinities of appropriate sign and format (following standard floating-point coercion rules) or NaNs, but a finite number (in fact zero) only when divided into a finite number. See the linked discussion for more details.
Infinities like this one can result from normal arithmetic operations, such as a division by zero in a function with types declared and compiled so trust-declarations-switch is true, but that same call run interpreted may instead signal an error.
See Floating-point infinities and NaNs, and floating-point underflow and overflow in implementation.html. Also see *negative-infinity-single*, *infinity-double*, *negative-infinity-double*, *nan-double*, and *nan-single*
variable, excl package
The value of this variable should be a list of strings naming files. These files will be looked for in the users home directory on Unix and C:\ on Windows and in the current directory (the current directory on Windows is typically the directory containing the executable but see the discussion in Initialization and the sys:siteinit.cl and [.]clinit.cl files in startup.html for precise information. The initial value of this variable is the list:
(".clinit.cl" "clinit.cl")Only one initialization file in each location is loaded. Thus for example, if there is a file .clinit.cl in the home directory, it will be loaded (assuming init files in the home directory are loaded at all) and the clinit.cl file, if it exists, will be ignored. If there is no .clinit.cl, clinit.cl will be loaded if it is present.
If the value is nil, no initialization files will be loaded except sys:;siteinit.cl (whose loading and name are not affected by this variable).
See Initialization and the sys:siteinit.cl and [.]clinit.cl files in startup.html for information on reading init files. Also see *read-init-files*.
variable, excl package
When Lisp starts up, this symbol is bound to a bidirectional stream with input and output corresponding to the normal Unix streams stdin and stdout or their equivalents on Windows. This symbol is never bound to any other value by Allegro CL and is thus available for application programs which need to guarantee access to the original stdin and stdout.
Users are strongly discouraged from changing the value of this symbol.
variable, excl package
If true, the Common Lisp function intern will accept a symbol as its first (required) argument as well as a string. If that argument is a symbol, intern extracts its print name and uses that string to look up an existing symbol or create a new one. The initial value is t. When the value of this variable is nil, intern signals an error when passed a symbol as its first argument.
variable, excl package
In previous releases, this variable provided the default value for the libfasl keyword argument to load. When that argument was true, fasl files would be loaded in libfasl (Allegro Presto) mode. The Allegro Presto facility has been removed. This variable is kept for backward compatibility only. Its value is ignored.
variable, excl package
This variable controls whether documentation strings associated with symbols naming Lisp objects (operators, constants, etc.) will in fact be stored in Allegro CL, and thus available using the documentation generic function, or will be ignored, and thus not be available at all.
Documentation strings are useful, but they take up space in the Lisp heap, resulting in larger images. This variable gives programmers control over the handling of documentation strings. Consider the following example, showing the different behavior when this variable is true and nil:
cl-user(75): (setq *load-documentation* t)
t
cl-user(76): (defun foo (x) "Doc string for FOO"
(+ x 1))
foo
cl-user(77): (documentation 'foo 'function)
"Doc string for FOO"
cl-user(78): (setq *load-documentation* nil)
nil
cl-user(79): (defun foo (x) "Doc string for FOO"
(+ x 1))
foo
cl-user(80): (documentation 'foo 'function)
nil
cl-user(81): The value of this variable also affects loading files containing definitions with doc strings. If the value of this variable is true, the doc strings are loaded and stored. If the value is nil, they are not.
The initial value of this variable is determined when the image is built. Its initial value is true in images included with the distribution. For images created with build-lisp-image and generate-application, the value in the newly created image is the value of the preserve-documentation-strings keyword argument. That argument defaults to t in calls to build-lisp-image and defaults to nil in calls to generate-application. (The theory is that generate-application is used to produce application distributions and documentation strings are less useful in applications.)
variable, excl package
The value of this variable is a list of strings which are the suitable file types (or extensions) for files suitable for foreign loading into Allegro CL. The value is different on different platforms. To see the value of a platform you are using, evaluate this variable in a running Allegro CL image.
Because load is used to load Lisp source and compiled files and files containing compiled foreign code (typically libraries of such), it is useful to determine what the file to be loaded contains prior to actually loading it. This is done (as described in Load foreign code with cl:load in foreign-functions.html) by checking the file type against the list which is the value of this variable.
Even though this is a variable, its value should not be changed without instructions from Franz Inc. You can, however, force a foreign load of a file with an extension not included in *load-foreign-types* by specifying a true value for the new (and non-standard) foreign keyword argument to load. See Using the load function in loading.html for details of the Allegro CL implementation to load.
This variable existed but was not exported in earlier Allegro CL releases.
variable, excl package
This variable is similar to *load-xref-info* and *load-source-file-info* in that it controls whether information stored in a fasl file should be loaded into Lisp when the fasl file is loaded. The information is local name and scope information which is very useful for debugging.
That information is written to fasl files when the values of the optimization qualities safety, space, speed, and debug are such that either or both of the compiler switches save-local-names-switch and save-local-scopes-switch are true. See Declarations and optimizations
in compiling.html for information on switches.
When developing code, the value of this variable should be non-nil because the usefulness to debugging outweighs the cost of the additional space used. (See the :local top-level debugging command.) But when preparing an application for delivery which will not be interactively debugged, the value nil is appropriate.
This example shows how debugger output might differ when local names are and are not loaded. Suppose the function foo (with lots of locals) is defined in the file
(in-package :user)
(defun foo (a b c)
(let ((c (* a a)) (d (+ c b)) e)
(setq e (- c d))
(break)
(* e a d)))We compile the file with speed 1 and safety 1 (so local names are saved to the fasl file) and then load the file with *load-local-names-info* set to t and then nil:
cl-user(31): (setq *load-local-names-info* t)
t
cl-user(32): :ld lln.fasl
; Fast loading /user/lln.fasl
cl-user(33): (foo 1 2 3)
Break: call to the `break' function.
Restart actions (select using :continue):
0: return from break.
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this (lisp) process.
[1c] cl-user(34): :local
Compiled lexical environment:
0(required): a: 1
1(required): b: 2
2(required): c: 3
3(local): d: 5
4(local): c: 1
5(local): e: -4
[1c] cl-user(35): :cont 0
-20
cl-user(36): (setq *load-local-names-info* nil)
nil
cl-user(37): :ld lln.fasl
; Fast loading /user/lln.fasl
cl-user(39): (foo 1 2 3)
Break: call to the `break' function.
Restart actions (select using :continue):
0: return from break.
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this (lisp) process.
[1c] cl-user(40): :loc
Compiled lexical environment:
0(required): a: 1
1(required): b: 2
2(required): c: 3
3(local): excl::local-0: 5
4(local): excl::local-1: 1
5(local): excl::local-2: -4
6(local): excl::local-3: nil
7(local): excl::local-4: 352323842
8(local): excl::local-5: #<Function eval>
9(local): excl::local-6: 16825334
10(local): excl::local-7: 0
[1c] cl-user(41): The argument names and initial values are remembered in this example, but the local names (d and e) are not and c, an argument, is modified in the code, but the value (1) is no longer associated with c. Further, the system does not distinguish between variables in the function definition and others (dealing with the interpreter, for example) that happen to be around.
variable, excl package
Fasl files compiled with the compiler switch save-source-level-debug-info-switch contain source debug information. If the value of the variable is true when such a fasl file is loaded into Lisp, then the source debug information will be loaded at that time.
The initial value of this variable is nil and that is its usual value. Source debug information is often voluminous and users may not want to load the information into Lisp unless it is needed. If source file recording is in effect when the source file is compiled and loaded (as it will be when *record-source-file-info* is true when the file was compiled and *load-source-file-info* was true when the file was loaded) then the source debug information will be laoded automatically when needed. However, if source file recording is not enabled or for some reason source debug information is not found, setting or binding this variable to true and reloading the fasl file will ensure source debug infomation is loaded.
Source level debugging is discussed in The source stepper
in debugging.html.
variable, excl package
This variable controls whether source file information recorded in a fasl file is loaded into Lisp when the fasl file is loaded. Such information is only recorded in a fasl file if *record-source-file-info* is true at the time the file is compiled. The information recorded in the fasl file will be loaded into Lisp if the value of this variable is true and will not be loaded if the value of this variable is nil.
Note that loading a fasl file that was compiled with *record-source-file-info* nil will never cause source file information to be loaded into Lisp regardless of the value of this variable.
The value of this variable has no effect on recording source file information for source (rather than compiled) files loaded into Lisp or for definitions typed to the Lisp top-level.
The initial value of this variable depends on how Allegro CL was installed.
See also source-file-recording.html for general information on source file recording in Allegro CL.
variable, excl package
This variable is a boolean which determines whether cross-reference information in a fasl file is loaded and stored into the cross-reference database (recall that compiling a file only puts cross-reference information in the fasl file). When *load-xref-info* is true, the cross-reference database will be updated with any cross-reference information stored in fasl files that are loaded. The value of this variable controls loading done by any method (by load, :ld, :cload, require, etc.) and none of those functions or commands have arguments that can override the value of this variable.
The initial value of this variable is dependent on how Lisp was installed. Users who want cross reference information recorded should set this value and that of *record-xref-info* variable to t. Be warned that compilation time, image size and fasl file size are all increased by the generation and loading of cross reference information.
See also cross-reference.html for general information on the cross-reference facility in Allegro CL, and see *record-xref-info*
constant, excl package
The Allegro CL distribution may contain locale definition files suitable for loading with load-localedef. The location of these files is the pathname which is the value of this constant.
See Localization support in Allegro CL in iacl.html.
variable, excl package
The value of this variable must be a locale object. Its initial value is the default locale based on the Lisp process' external locale setting (see The initial locale when Allegro CL starts up in iacl.html). The locale object which is the value of excl:*locale* is referred to as the current locale. *locale* is similar (in usage) to *package*. It can be bound while evaluating code for a different locale.
The current locale is used to determine the default external-format. In addition, the value of *locale* affects Allegro CL localization functions, which are listed below.
Examples:
The Polish locale, "pl", uses the Latin-2 character set; and the US English locale, "en_US", uses the Latin-1 character set. The octet value #xa3 represents a different external-format character in each character set. Rebinding excl:*locale* as shown below alters the default external-format conversion behavior.
user(22): (let ((excl:*locale* (find-locale "pl")))
(schar (octets-to-string (coerce
'(#xa3)
'(vector (unsigned-byte 8))))
0))
#\latin_capital_letter_l_with_stroke
user(23): (let ((excl:*locale* (find-locale "en_US")))
(schar (octets-to-string (coerce
'(#xa3)
'(vector (unsigned-byte 8))))
0))
#\pound_signSee the localization functions locale-print-monetary, locale-format-monetary, locale-print-number, locale-format-number, locale-parse-number, locale-print-time, locale-format-time, locale-attribute. And see find-locale, locale-name, and locale-external-format.
General information on international character set support in Allegro CL is in iacl.html. See particularly External formats and locales in that document.
variable, excl package
This variable is no longer used. It was related to the GTK version of CG, which is no longer supported.
variable, excl package
This constant has the value of IEEE double-float NaN (Not-a-Number). It is a legal floating-point value. In arithmetic operations, it produces itself in all cases. See the linked discussion for more details.
NaNs like this one can result from normal arithmetic operations, such zero divided by zero in a function with types declared and compiled so trust-declarations-switch is true, but that same call run interpreted may instead signal an error.
See Floating-point infinities and NaNs, and floating-point underflow and overflow in implementation.html. Also see *negative-infinity-single*, *infinity-double*, *infinity-single*, *negative-infinity-double*, and *nan-single*
variable, excl package
This constant has the value of IEEE single-float NaN (Not-a-Number). It is a legal floating-point value. In arithmetic operations, it produces NaNs of appropriate format (following standard floating-point coercion rules) in all cases. See the linked discussion for more details.
NaNs like this one can result from normal arithmetic operations, such zero divided by zero in a function with types declared and compiled so trust-declarations-switch is true, but that same call run interpreted may instead signal an error.
See Floating-point infinities and NaNs, and floating-point underflow and overflow in implementation.html. Also see *negative-infinity-single*, *infinity-double*, *infinity-single*, *negative-infinity-double*, and *nan-double*.
variable, excl package
This constant has the value of IEEE negative double-float infinity. It is a legal floating-point value. In arithmetic operations, it produces double-float infinities of appropriate sign or NaNs, but a finite number (in fact zero) only when divided into a finite number. See the linked discussion for more details.
Infinities like this one can result from normal arithmetic operations, such as a division by zero in a function with types declared and compiled so trust-declarations-switch is true, but that same call run interpreted may instead signal an error.
See Floating-point infinities and NaNs, and floating-point underflow and overflow in implementation.html. Also see
*negative-infinity-single*, *infinity-double*, *infinity-single*, *nan-double*, and *nan-single*
variable, excl package
This constant has the value of IEEE negative single-float infinity. It is a legal floating-point value. In arithmetic operations, it produces infinities of appropriate sign and format (following standard floating-point coercion rules) or NaNs, but a finite number (in fact zero) only when divided into a finite number. See the linked discussion for more details.
Infinities like this one can result from normal arithmetic operations, such as a division by zero in a function with types declared and compiled so trust-declarations-switch is true, but that same call run interpreted may instead signal an error.
See Floating-point infinities and NaNs, and floating-point underflow and overflow in implementation.html. Also see
*negative-infinity-single* *infinity-double* *infinity-single* *negative-infinity-double* *nan-double* *nan-single*
variable, excl package
Bound to a function taking a pathname as an argument and returning a new pathname. Normally the new pathname will differ only in the filename and type slots, with both being some reasonable modification of the original filename and type. This function is run when the value of the if-exists keyword argument to open is :rename or :rename-and-delete (and the direction argument is :io or :output, so the if-exists argument is not ignored).
The function that is the initial value of this variable prepends the value of *open-rename-prefix* to the file name and appends the value of *open-rename-suffix* as the new file type (the old type, if present, becomes part of the file name). Thus, using the initial values for the three variables, a file named foo.bar will be renamed foo.bar.bak: the file name is foo.bar and the type is bak. A file named foo will be renamed foo.bak.
The renamed file will be written to the directory that is the result of merging the pathname of the opened file with *default-pathname-defaults*. This means that the renamed file will typically be in the same directory as the file being opened.
In releases prior to 8.0, the renamed file was written to the directory that is the result of merging the pathname of the opened file with the current directory (as returned by current-directory) rather than merging it with *default-pathname-defaults*. When the current directory was different from the directory component of *default-pathname-defaults*, the renamed file was typically located in a different directory than the file which was opened.
See open in implementation.html for information on the implementation of open.
variable, excl package
This variable and the variables *open-rename-suffix* and *open-rename-function* work together in renaming a file opened with open with the direction keyword argument either :output or :io and the if-exists keyword argument either :rename or :rename-and-delete. The function that is the initial value of *open-rename-function* renames the existing file by prepending the value of this variable, moving the current file type into the filename, and making the value of *open-rename-suffix* the new type.
The initial value of this variable is the empty string "" and that of *open-rename-suffix* is the string "bak". If all three variables have their initial values, the file foo.txt will be renamed foo.txt.bak (with filename foo.txt and file type bak).
See open in implementation.html for information on the implementation of open.
variable, excl package
This variable and the variables *open-rename-prefix* and *open-rename-function* work together in renaming a file opened with open with the direction keyword argument either :output or :io and the if-exists keyword argument either :rename or :rename-and-delete. The function that is the initial value of *open-rename-function* renames the existing file by prepending the value of *open-rename-prefix*, moving the current file type into the filename, and making the value of this variable the new file type.
The initial value of this variable is the string "bak" and that of *open-rename-prefix* is the empty string "". If all three variables have their initial values, the file foo.txt will be renamed foo.txt.bak (with filename foo.txt and file type bak).
See open in implementation.html for information on the implementation of open.
variable, excl package
This variable determines what is the customary case when the :case keyword argument to various pathname functions (listed next) is specified :common. The Common Lisp pathname functions that accept a :case keyword argument are make-pathname, pathname-host, pathname-device, pathname-directory, pathname-name, and pathname-type. (In earlier releases, the :case keyword argument to those functions was simply ignored.)
The initial value of this variable is :lower on all platforms, even Windows. The other allowable value is :upper.
We do not recommend using the :case keyword argument to any of the named pathname functions. If you do not specify a value for the :case keyword argument in the listed functions, Allegro CL behavior is unchanged from previous versions.
variable, excl package
This variable was added in release 6.0. Performance testing has indicated that the overhead associated with pretty printing can be high. In order to better control this cost, no Allegro CL code sets the value of *print-pretty*. Instead, when it needs a value for *print-pretty*, Allegro CL code binds it to the value of this variable, and this variable is only set in two places: initially to nil and in the :pprint module to t.
See Speed and pretty printing in implementation.html for more information on the pretty-printing issue.
variable, excl package
If true, then the alternate package name, if any, will be used when a package qualifier is printed, rather than the actual package name (though the alternate name may also be the package name). The alternate name is returned by package-alternate-name and can be set when a package is defined by make-package or defpackage. (See defpackage and in-package, both in implementation.html, for more information on extensions to defpackage and make-package.)
If the alternate name is not set, the the first nickname in the package-nicknames list is used. The package-name is used if there are no nicknames defined. (The alternate name must be either the package name or one of its nicknames.)
If a package has a local nickname in the current package, that local nickname is used, rather than the global alternate name, when this variable is true. If there are more than one local nicknames, the first returned by package-local-nicknames will be used. Package-local nicknames are described in Package-local Nicknames in packages.html.
If a package does not have a local nickname in the current package and all of its nicknames are shadowed by local nicknames of other packages, then the printer will use the package name regardless of whether it is also shadowed. This can lead to loss of print/read consistency. See Package-local Nicknames in packages.html for an example.
See packages.html for more information.
variable, excl package
This variable was added in release 6.2. This variable is analagous to the variable *pprint-gravity*. As with *pprint-gravity*/*print-pretty*, no Allegro CL code sets the value of *print-circle*. Instead, Allegro CL code binds it where necessary to the value of this variable, and this variable is only set in two places: initially to nil and in the :pprint module to t.
variable, excl package
Somewhat analogous to both *print-length* and *print-array*, this variable controls what is actually printed by print functions when a long string is printed. (Long strings do not have a formal definition, but conceptually they are strings of many characters, the number of which is designated by this variable, which may cause output to be hard to read and also may cause screens or buffers to overflow or malfunction, or which may detract from the readability of the rest of the output.)
The value of this variable should be nil or a positive integer. It is bound to itself every time a new break level is started, so its value is not global and instead will be inherited from the prior break level. If this variable is nil (its initial value), no restriction is placed on printing long strings. If a positive integer, strings of greater length are printed as #<Long string(XXXX): "[start of string]..." @ [address of string]>. The portion of the string included in [start of string] is 20 characters regardless of the numeric value of this variable (this is how this variable resembles *print-array*). The numeric value simply triggers using the abbreviated format. Here is an example:
cl-user(1): (setq long-string (make-array 200 :element-type 'character :initial-element #\y))
"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
cl-user(2): (setq *print-long-string-length* 30)
30
cl-user(3): (print long-string)
#<Long string(200): "yyyyyyyyyyyyyyyyyyyy..." @ #x210a1b72>
"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
cl-user(4): (setq tpl:*print-long-string-length* :follow)
:follow
cl-user(5): (print long-string)
#<Long string(200): "yyyyyyyyyyyyyyyyyyyy..." @ #x210a1b72>
#<Long string(200): "yyyyyyyyyyyyyyyyyyyy..." @ #x210a1b72>
cl-user(6): (setq tpl:*zoom-print-long-string-length* :follow)
:follow
cl-user(7): (1+ long-string)
Error: `#<Long string(200): "yyyyyyyyyyyyyyyyyyyy..." @ #x210a1b72>' is
not of the expected type `number'
[condition type: type-error]
Some global variables had problematic values and were reset as follows:
*print-long-string-length* was 30 and has been set to 70 for the
current break level.
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this (lisp) process.
[1] cl-user(8): :zo :all t
Evaluation stack:
... 1 more newer frame ...
(excl::internal-invoke-debugger "Error" #<type-error @ #x210a384a> ...)
(error type-error :datum ...)
(excl::.type-error #<Long string(200): "yyyyyyyyyyyyyyyyyyyy..." @ #x210a1b72> number)
(excl::.type-error_2op #<Long string(200): "yyyyyyyyyyyyyyyyyyyy..." @ #x210a1b72> number)
[... excl::%eval ]
->(eval (1+ long-string))
(tpl::read-eval-print-one-command nil nil)
(excl::read-eval-print-loop :level 0)
(tpl::top-level-read-eval-print-loop1)
(tpl:top-level-read-eval-print-loop)
... more older frames ...
[1] cl-user(9): Note that in the example above, when the debugger is entered it considers 30 to be too small a value for this variable in order for it (the debugger) to do its job, and so it sets it to the minimum value it needs.
See Printing long strings in top-level.html for more information and links to variables that control printing of long strings at the top-level and in various debugging contexts. See also Allegro CL print variables can follow the CL print variable value in implementation.html.
variable, excl package
The new variable *print-alternate-package-name* replaces *print-nickname*. The nickname printed was formerly the first nickname of a package (or the package-name if there was no nickname). Now an alternate name can be specified from any of the nicknames or the package name. This more flexible approach allows nicknames to be used for some packages and the package name for others. For packages without defined alternate names, the alternate name defaults to the first nickname or, if there are no nickname, the package name. (Therefore, the previous behavior for choosing what to print when *print-nickname* was true is preserved when *print-alternate-package-name* is true.)
All references to *print-nickname* should be changed to *print-alternate-package-name*.
Both defpackage and make-package have an :alternate-name option/argument, as described in cl:defpackage and cl:in-package, both in implementation.html. Packages are described in packages.html.
variable, excl package
This variable is nil by default, and it governs the behavior of the printing of arrays. If the value is nil, then the printer prints the array in standard #NAdata format (the standard Common Lisp fashion). If the value of this variable is true, and the array being printed is an unsigned byte array where the byte size is 4, 8, 16, 32, or 64, or a signed byte arrays where the byte size is 8, 16, 32, or 64, then the printer extends the format to #{N}A{T}data format. This extension of the #A reader macro format is described in The #A reader macro in implementation.html.
Here we show arrays printed in both cases:
cl-user(12): (setq arr (make-array 10 :element-type '(signed-byte 16)
:initial-element 1))
#(1 1 1 1 1 1 1 1 1 1)
cl-user(13): *print-simple-array-specialized*
nil
cl-user(14): (setq *print-simple-array-specialized* t)
t
cl-user(15): arr
#1As16(1 1 1 1 1 1 1 1 1 1)
cl-user(16): The s16 indicates signed-byte 16. Other array types that are encoded are:
f32 - single-floatf64 - double-floatfix - fixnumc32 - (complex single-float)c64 - (complex double-float)Some more examples:
cl-user(1): #af32(1.0 2.0 3.0)
#(1.0 2.0 3.0)
cl-user(2): (setq *print-simple-array-specialized* t)
t
cl-user(3): **
#1Af32(1.0 2.0 3.0)
cl-user(4): (type-of *)
(simple-array single-float (3))
cl-user(5): #afix(1 2 3)
#1Afix(1 2 3)
cl-user(6): (type-of *)
(simple-array fixnum (3))
cl-user(7): This variable is presented in the :printer-variables toplevel command, and can be queried or set there.
This variable has a required top-level binding to nil, so a listener thread will bind this variable to nil, thus not disturbing its value in other threads. (See *required-top-level-bindings*.)
variable, excl package
The value of this variable should be a (possibly empty) alist with elements of the form (<em>type</em> . <em>brief</em>). type should be one of the choices given in the description of print-startup-info or t (indicating all information should be printed). brief should be a boolean specifying whether long (value nil) or short (value t) information should be printed on a particular topic.
Among the values for type given in the description of print-startup-info are :compiler-optimization, :compiler-switches, and :case-mode. So if the value of this variable is the list
((:compiler-optimization . t) (:compiler-switches . nil)
(:case-mode t))brief (t means brief) information on compiler optimization will be printed along with long (nil means not brief) information on compiler switches and brief information on the current case mode. (See Allegro CL Executables in startup.html for discussion of the various case modes in pre-built images.)
Again, if type is t, information is printed on all topics. So if the value of this variable is ((t . t)), brief information will be printed on all available topics and if it is ((t . nil)), long information will be printed on all topics.
If the value of this variable is nil, no start-up information is printed.
The system examines this variable when Lisp starts up and prints the requested information just after the banner (i.e. copyright notice, etc.) is printed. You may wish to change the information printed. The change to the value of this variable can be made in the custom.cl file and the change will be seen in newly-built images. You can also set this variable with a command-line argument or in an init file, as both are processed in the startup sequence before startup messages are printed.
See also startup.html for general information on starting Allegro CL, including information on command-line arguments and init files. The start-up messsage is described in the section The start-up message in that document.
variable, excl package
If true, structures will be printed using the
#s(struct-name slots ...) ```format instead of the
#<struct-name @ hex-address>format. Print functions for structures are unaffected by the value of this variable. The initial value of this variable is t.
variable, excl package
Bound to nil for each thread that starts a top-level, this variable controls whether a backtrace associated with a condition's source-contexts context will be printed fully or one-form-per-line. If true, the normal pretty printer will be used to print forms that might be printed in a compiler backtrace, but if nil, concise-printing will be used to ensure that each form is printed on one line only.
See the example of this variable in action.
variable, excl package
This variable is used when Lisp is starting up to determine whether the initialization files ~/.clinit.cl, ~/clinit.cl, [current-directory]/.clinit.cl, [current-directory]/clinit.cl, and sys:siteinit.cl should be read. The command-line arguments -q and -qq can suppress reading of these files when this variable is true as described in Command line arguments in startup.html.
The following bulleted list shows the possible values of this variable and their effects:
t: Read all initialization files.nil: Do not read any initialization file.:no-home: Read [current-directory]/[.]clinit.cl and sys:siteinit.cl only.Because command-line arguments are processed before initialization files are read, and -e arguments are processed before -q or -qq, this variable can be reset with a -e argument (see the discussion of command-line arguments in Command line arguments in startup.html.
See Initialization and the sys:siteinit.cl and [.]clinit.cl files in startup.html for information on reading init files. Also see *init-file-names* whose value is a list of strings naming the files to be looked for in the home and current directories.
variable, excl package
This parameter gives a better estimation than char-code-limit as to the upper bound of characters. char-code-limit is chosen to be an upper bound of all implementations of Allegro CL, 16-bit character or 8-bit character. The value of real-char-code-limit is the actual limit for the Lisp being run (and so its value in an 8-bit character Lisp is smaller than on a 16-bit character Lisp).
variable, excl package
This variable affects (1) files being compiled; (2) source files being loaded; and (3) definitions typed to the top-level.
If the value of this variable is true, the fasl file produced when a file is compiled will be annotated to contain source file information for definitions in the file. That information will be loaded into Lisp along with the fasl file if *load-source-file-info* is true when the fasl file is loaded. Annotating fasl files with source file information increases the size of the fasl file (typically by 10 to 15%).
If the value of this variable is true, source file information will be recorded for definitions in a Lisp source file loaded into Lisp, for definitions dispatched to Lisp via the Emacs-Lisp interface from an Emacs buffer open to a file, and for definitions typed to the Lisp top-level. (The source file for definitions typed to the top-level is :top-level.)
If the value of this variable is nil, source file information will not be included in fasl files that are compiled nor will such information be recorded for source files that are loaded into Lisp or for definitions typed to the top-level.
Note that a definition form in an Emacs buffer that is not open to a file and is evaluated via the Emacs-Lisp interface will have bogus source file information recorded. You should have Emacs buffers open to files for source file recording to work properly.
The initial value of this variable is set when the Allegro CL image is built.
See also source-file-recording.html for general information on source file recording in Allegro CL.
variable, excl package
This variable is a boolean which determines whether cross-reference information is recorded by the compiler. When \*record-xref-info\* is true, the compiler will generate cross-reference information and when it is false, the compiler will not generate such information. For most methods of compilation, such as calling compile or the top-level commands :cf and :cload, the value of this variable controls the behavior.
compile-file has an xref keyword argument whose default is supplied by this variable but explicitly specifying a value for the xref keyword argument to compile-file will override the value of this variable.
The initial value of this variable is dependent on how the Lisp image was built (see build-lisp-image). Users who want cross reference information recorded should set this value and that of *load-xref-info* to t. Be warned that compilation time, image size and fasl file size are all increased by the generation and loading of cross reference information.
See also *load-xref-info*.
See also cross-reference.html for general information on the cross-reference facility in Allegro CL.
variable, excl package
If true, the value of this variable should be a list of functions to call when comparing two pathnames to determine if a defining form has changed from one file to another. If any of the functions returns a true value, then the pathnames are considered to be the same and no redefinition warning will be issued.
Any function named in the list that is the value of this variable will be passed four arguments:
the old pathname (recorded in the source file information database),
the new pathname,
the name of the object being defined (typically a symbol but can be a list for a function spec), and
the type of the definition.
The initial value of this variable is nil.
See also source-file-recording.html for general information on source file recording in Allegro CL.
variable, excl package
This variable controls most redefinition warnings. There are four kinds of such warnings:
Defining something in two different files (or in a file and at the listener).
Defining something twice in a single file.
Defining a macro as a function.
Defining a function as a macro.
This variable controls the first three types. It does not affect the fourth type (a warning in that case is signaled unconditionally). See below for more information on this case.
If the value of this variable is nil, redefinitions of the first three listed types will not signal warnings under any circumstances.
If the value of this variable is true, redefinition of the third listed type will signal a warning that a macro is being redefined as a function.
If true, the value should be either t or a list of keywords identifying the objects for which redefinition warnings should be printed. If it is t, warnings are signaled for the first three types of redefinition. If it is a list of keywords, warnings are signaled for type 1 and 2 redefinitions only if the relevant keyword is present. The following table shows many of the the keywords supported.
Redefinition keywords and their effect |
|
Keyword |
Definitions for which warnings will be printed |
:operator |
defun clos:generic-function defmacro |
:variable |
defconstant defparameter defvar |
:special-declaration |
defconstant defparameter defvar |
:compiler-macro |
code>define-compiler-macro |
:setf-method |
defsetf |
:type |
defclass defstruct deftype |
The initial value of this variable is a list containing all six keywords. Note that the initial value when using the Integrated Development Environment also contains certain symbols and keywords specific to the IDE (and not further documented).
The function load and its associates like the top-level command :ld lambda binds this variable to itself when loading a file so the value of this variable cannot be changed by a form in a file being loaded. The following form in a file will change the value outside the binding:
(setf (mp:global-symbol-value 'excl:*redefinition-warnings
<new-value>)More on redefining a function as a macro. If a function is redefined as a macro, calls to the operator in code compiled before the redefinition will signal an error. That is because the call is to the function previously defined, and the system is unable to convert the call into an appropriate macro expansion. (See Attempt to call -name- which is defined as a macro in errors.html.) Because the change can result in an error, it is considered best that the warning not be controlled by a global variable. If you want to suppress the warning, wrap the defmacro call in a handler-bind like this:
(handler-bind
((warning #'(lambda (c) (declare (ignore c)) (muffle-warning))))
(defmacro foo ....))See Redefinition warnings in source-file-recording.html. See also without-redefinition-warnings.
variable, excl package
When this variable is true, the :flat option to defpackage and the flat keyword argument to make-package will be set to true when packages are defined. That option/argument specifies that names and nicknames are not hierarchical, despite possibly having dots (periods) in their names.
This variable is designed for systems which have package names containing dots which are not intended to be hierarchical. Those could be created with the :flat option/argument specified as true explicitly, but in large and complex systems, that might be inconvenient and error-prone.
While this variable is true, a warning is signaled whenever a package is defined without the :flat option/agument being specified. Further, the primary name of any package defined while *regard-package-names-as-flat* and no value is specified for :flat is pushed onto the value of *global-flat-package-option-used*.
When *regard-package-names-as-flat* is non-nil but (:flat nil) is specified to defpackage/:flat nil to make-package, a hierarchical package is created as usual (i.e. the variable is overridden).
cl-user(1): (setq excl:*regard-package-names-as-flat* t)
t
cl-user(2): excl:*global-flat-package-option-used*
nil
cl-user(3): (defpackage :foo)
Warning: Defining :foo with :flat attribute because
*regard-package-names-as-flat* is non-nil. See documentation
on cl:defpackage in implementation.htm.
#<The foo package>
cl-user(4): excl:*global-flat-package-option-used*
("foo")
cl-user(5): (defpackage :bar (:flat t)) ;; when :flat is specified, no warning
#<The bar package>
cl-user(6): excl:*global-flat-package-option-used*
("foo") ;; and the package is not added to this list.See cl:defpackage and cl:in-package, both in implementation.html, for more information on extensions to defpackage and make-package. Flat and hierarchical packages are discussed in Hierarchical Packages in packages.html.
variable, excl package
This variable holds bindings for all threads (including interactive threads). The variables in this list are always bound when a new thread starts or restarts. The binding when a process (i.e. thread) is created is automatic. There is no argument to the various process-creating functions. You can only change these bindings by modifying this list (not recommended) or binding it around process-creation code.
The only exported variable on this list is readtable, which is bound to its current value when a thread starts. All other elements of the list are unexported variables.
Please note that it is possible that the initial value of this variable may be changed by patches made available after the initial release.
This variable can be set but not bound (see defvar-nonbindable).
A variable should appear as the key (i.e. car) of an entry only once in this list. If a variable is the key of two or more elements, only the first is used and all subsequent elements are ignored.
See Processes and their dynamic environments (both models) in multiprocessing.html and Setting global variables in initialization files in startup.html for a discussion of this variable. See also *required-top-level-bindings*, and tpl:*default-lisp-listener-bindings*.
variable, excl package
In releases prior to version 9.0, this variable was named \*cl-default-special-bindings\*. Use of that variable signals a warning (and then does the right things). Code using the old name should be updated to use the new name.
This variable holds an alist associating special variable symbols with forms to evaluate for binding values. When a process first starts execution, the required-thread-bindings are established and then the initial-bindings slot is examined for additional bindings to establish for the process. *required-top-level-bindings* contains a reasonable default list which establishes a default environment with standard Common Lisp values. The contents of this list may be examined, but if you want to modify it for a particular call to make-process, it is strongly suggested you either modify a copy made with copy-alist, or just cons replacement entries onto the front of the list.
This variable can be set but not bound (see defvar-nonbindable).
A variable should appear as the key (i.e. car) of an entry only once in this list. If a variable is the key of two or more elements, only the first is used and all subsequent elements are ignored.
Samples of the contents of \*required-top-level-bindings\* are shown next. Note that the contents of this list may be changed by patches.
((*print-pprint-dispatch* . #<excl::pprint-dispatch-struct @ #x2014a9c2>)
(excl::*break-on-warnings* . excl::*break-on-warnings*)
(*break-on-signals* . *break-on-signals*)
(*random-state* make-random-state nil)
(*package* find-package :user)
(*print-simple-array-specialized*)
(*print-lines*)
(*print-miser-width* . 40)
(*print-right-margin*)
(*print-readably*)
(*print-gensym* . t)
(*print-array* . t)
(*print-case* quote :upcase)
(*print-circle*)
(*print-length*)
(*print-level*)
(*print-radix*)
(*print-base* . 10)
(*print-pretty* system:global-symbol-value '*print-pretty*)
(*print-escape* . t)
(*enclose-printer-errors* . *enclose-printer-errors*)
(*print-nickname* . *print-nickname*)
(*read-base* . 10)
(*read-default-float-format* quote single-float)
(*readtable* copy-readtable nil))The binding established in this variable are those (typically) needed for an interactive thread. A list of binding (such as this list) should be specified as the initial-bindings ketword argument to tpl:start-interactive-top-level.
A variable should appear as the key (i.e. car) of an entry only once in this list. If a variable is the key of two or more elements, only the first is used and all subsequent elements are ignored.
See Processes and their dynamic environments (both models) in multiprocessing.html and Setting global variables in initialization files in startup.html for a discussion of this variable. See also required-top-level-binding, tpl:start-interactive-top-level, tpl:*default-lisp-listener-bindings*, and *required-thread-bindings*.
variable, excl package
The value of this variable should be a list of function names or function objects. The functions should take no arguments. As part of the startup procedure, the functions on this list are called (with funcall) in order. Note that Allegro CL facilities (including CLIM and Allegro Composer) push items onto this list and those items should not be removed or otherwise modified. The restart actions are performed after command-line arguments are processed and after initialization files are read. However, use of this variable for restart initializations is discouraged. Programmer initializations are better bundled into a single function and made the value of *restart-init-function*. (That variable is never used by any Allegro CL facility.)
See startup.html for information on startup.
variable, excl package
The value of this variable should be a function name or function object (suitable as the first argument to funcall or nil. The function should take no arguments. It is called at the end of the startup procedure instead of a standard Lisp listener being started. This function is designed to provide its own top-level (in place of a Lisp listener). If a top-level is not needed for the application, this function should perform whatever is required by the application and then exit. The function should not return. The behavior if it does return is undefined.
When this variable is nil, a standard Lisp listener is started using tpl:start-interactive-top-level.
Warning: the functions build-lisp-image and generate-application both accept a :restart-app-function keyword argument whose value defaults to the value of this variable. However, the only valid values for that argument are a symbol or a list (typically a lambda expression defining an anonymous function). If the value of this variable is a function object, and the :restart-app-function argument is not specified, the call to build-lisp-image or generate-application will fail. Thus, this will fail:
(setq *restart-app-function* #'(lambda () (do-my-startup))
(build-lisp-image "myimage.dxl")and this will succeed:
(setq *restart-app-function* '(lambda () (do-my-startup))
(build-lisp-image "myimage.dxl")If the Lisp uses a minimal top level (i.e. the image was built with the include-tpl keyword argument to build-lisp-image specified nil) and this variable is nil, tpl:start-interactive-top-level is still called but has a different definition than in a standard image with a standard top level. See Minimal top levels in building-images.html.
The variable is designed for applications. Users and programmers wanting to dump Lisp images for later use will not typically set this variable (instead, *restart-init-function*, allows for initializations prior to the Lisp listener starting). Programmers who want to start a Lisp listener themselves (perhaps providing a choice between the application top-level and a standard listener) from within *restart-app-function* should see the description of tpl:start-interactive-top-level.
See also startup.html for general information on starting Allegro CL, including information on command-line arguments and init files. See particularly the section What Lisp does when it starts up in that document.
variable, excl package
The value of this variable should be a function name or function object (suitable as the first argument to funcall) or nil. The function should take no arguments. It is called as the last startup action before either a standard Lisp listener is started or *restart-app-function* is called. This variable is never modified or set by any Allegro CL facility. Since the value of this variable is passed to funcall, if the value is nil, no action is taken.
As an example of its use, consider the following code, suitable for placement in a user's .clinit.cl file. It defines the function start-composer-from-clinit-file, which, if called in the .clinit.cl file, causes Allegro Composer to be started. It is reprinted here to illustrate how *restart-init-function* might be modified in a .clinit.cl file in a way that preserves any functionality expressed by the current value of the variable and is further careful to reset the variable appropriately after Allegro Composer is started -- thus preventing a dumped image from trying to start Allegro Composer twice. (Evaluating (composer:start-composer) in .clinit.cl works but causes annoying bogus warnings to be printed.)
;; Description: Facilitate Composer startup from .clinit.cl file
;;
(defun start-composer-from-clinit-file ()
(let ((initial-restart-init-function *restart-init-function*))
(cond (initial-restart-init-function
(setf *restart-init-function*
#'(lambda ()
(composer:start-composer)
(setf *restart-init-function* initial-restart-init-function)
(funcall initial-restart-init-function))))
(t (setf *restart-init-function*
#'(lambda ()
(composer:start-composer)
(setf *restart-init-function* nil)))))))This note applies to users of the Integrated Development Environment (IDE) with Allegro CL on Windows.
*restart-init-function* is set in IDE images to the function that starts the IDE. It is also used by an application developed using the project system. In such an application, the value of *restart-init-function* is set to do-default-restart. That function initializes Common Graphics, and calls the project on-initialization function (displayed in the Project manager Options tab as the Init Function). The on-initialization function should do whatever application initializations are necessary and should return the main window of the application. The main window is the one that the user closes in order to exit the application.
When the window returned by the on-initialization function is closed, the application will exit. If something other than a window is returned by the on-initialization function, the application exits immediately.
So, programmers using the project system should not set a value for *restart-init-function* and they should do all initializations associated with the application in the on-initialization function. Note that Common Graphics-related code cannot be evaluated earlier in the startup procedure because Common Graphics will not yet be initialized.
Warning: the functions build-lisp-image and generate-application both accept a :restart-init-function keyword argument whose value defaults to the value of this variable. However, the only valid values for that argument are a symbol or a list (typically a lambda expression defining an anonymous function). If the value of this variable is a function object, and the :restart-init-function argument is not specified, the call to build-lisp-image or generate-application will fail. Thus, this will fail:
(setq *restart-init-function* #'(lambda () (do-my-startup))
(build-lisp-image "myimage.dxl")and this will succeed:
(setq *restart-init-function* '(lambda () (do-my-startup))
(build-lisp-image "myimage.dxl")If you are building an image with build-lisp-image or generate-application which will not include Common Graphics from a Lisp which is using Common Graphics or the IDE, the value of this variable is likely not appropriate as the value of the :restart-init-function argument. In that case, be sure to supply the :restart-init-function argument and specify it as nil or as some symbol or list of your own creation. Otherwise, the argument will inherit the current value which may cause the build to fail or startup to fail or to be different than what is desired.
See startup.html, particularly sections What Lisp does when it starts up and Initialization and the sys:siteinit.cl and [.]clinit.cl files
variable, excl package
When true, cl:compile saves information for later use by uncompile. Also, cl:function-lambda-expression will use it for better output. When nil, space is saved during such compiles, at a cost of less useful cl:function-lambda-expression output and not being able to uncompile.
The initial value for this variable is nil.
The Allegro CL implementation of function-lambda-expression is discussed in cl:function-lambda-expression in implementation.html.
See also arglist.
variable, excl package
This variable is bound to the name of the script file being run when Allegro CL is being executed by the #! mechanism.
For example, consider this script file test.cl:
#! /fi/cl/bin/mlisp -#T
(format t "-#T ~a~%" *script-name*)Here is that script being run:
% ./test.cl
-#T ./test.cl
% See Starting on UNIX using a shell script in startup.html for more information on running Lisp using a script on Unix.
variable, excl package
When true (the initial value is t), the inner conditionals of nested conditionals are resolved to produce the form which the outer conditional applies to. Thus we have the following behavior:
(list #+allegro :allegro #-allegro #+foo :foo #-foo :default) evaluates to (:allegro).
(list #+allegro :allegro #-allegro #+foo :foo) signals an error.
When the value of this variable is nil, the inner conditionals of nested conditionals are not resolved before the outer is applied, producing the following behavior on the forms from above: evaluate as follows:
(list #+allegro :allegro #-allegro #+foo :foo #-foo :default) evaluates to (:allegro :default).(list #+allegro :allegro #-allegro #+foo :foo) evaluates to (:allegro).The section The issue of nested conditionals in Allegro CL in implementation.html discusses the issue assocated with this variable in detail, with examples. See also *warn-on-nested-reader-conditionals*.
If the purpose of this form is to produce the following results:
:allegro and :foo are features: (:allegro):allegro is a feature and :foo is not: (:allegro):allegro is not a feature and :foo is: (:foo):allegro nor :foo are features: nilthen this form
#+allegro (list :allegro) #-allegro (list #+foo :foo)will do that whatever the value of this variable. If users have forms similar to (list #+allegro :allegro #-allegro #+foo :foo), we recommend that they modify them to ones similar to #+allegro (list :allegro) #-allegro (list #+foo :foo) rather than setting this variable to nil.
constant, excl package
The maximum number of dimensions of a short array. The value is (expt 2 24) in a 32-bit lisp, and (expt 2 56) in a 64-bit lisp. (In releases prior to 7.0, this value was the maximum number of dimensions of arrays in general.) See Arrays and short arrays in implementation.html for a definition of short arrays and a discussion of the array implementation in Allegro CL.
constant, excl package
The maximum total size of a short array. The value is (expt 2 24) in a 32-bit lisp, and (expt 2 56) in a 64-bit lisp. See Arrays and short arrays in implementation.html for a definition of short arrays and a discussion of the array implementation in Allegro CL.
variable, excl package
The value of this variable is an alist of signal numbers and handlers.
The handling of operating system dependent signals generated during program execution is not part of Common Lisp. A signal is a small integer. The list of valid signals is given in a system dependent file, usually on UNIX something like /usr/include/signals.h. Signals are either synchronous or asynchronous, but there is no distinction made in this interface--the handling of both types of signals is the same. A handler for a signal is a function of two arguments, signal number and t. If there is no handler for a particular signal, then some default action is invoked, which is usually to signal an error. Signal handlers should return a true value if they handle the signal, so that other, nested handlers are are not invoked to handle the signal. A signal that is posted during a gc is processed immediately after the gc finishes.
See also set-signal-handler, add-signal-handler, remove-signal-handler, and with-signal-handler.
variable, excl package
This variable provides the default value for the strategy keyword argument to the sort function as implemented in Allegro CL. The strategy argument is an Allegro CL extension. It is not necessary to supply a value for that argument when calling sort and the initial value of this variable suffices in all cases. See sort in implementation.html for more information.
The value of this variable must be one of the following:
:stack (the initial value): if possible, when sorting a vector, allocate the needed scratch vector, used during sorting, on the stack. If allocating on the stack is not possible, allocate it in the Lisp heap.
:alloc: when sorting a vector, allocate the needed scratch vector in the Lisp heap.
A vector: This value is not recommended as the value of this variable because the vector will be used by every call to sort where the strategy keyword argument is not explicitly specified, and this can lead to errors because competing calls to sort (perhaps in different threads) will operate on the same vector. If you want to specify your own vector, create one for use in a specific thread and pass it as the strategy argument in your calls to sort. (sort is often called by system functions and the values of the strategy argument used by system functions is such calls is not specified.)
variable, excl package
When a function, defstruct accessor, flavor method, or macro is defined, and when symbol-function is setf'ed, the value of this variable is recorded as the place of definition. During a load of a source file or during a compile-file this variable is bound to the name of the file being loaded or compiled. Programs, such as editors running Lisp as a subprocess, or users typing to the top-level may themselves bind this variable to any pathname designator (a string or a pathname object) they wish, and the information will be recorded except when load is used to transmit the definition to Lisp.
This variable is not bound when a
See also source-file-recording.html for general information on source file recording in Allegro CL.
variable, excl package
Initially :unset. The purpose of this variable is to tell Allegro CL the names of the SSL system libraries. (These names are not fully standardized.) If the value of this variable is :unset and the associated environment variable ACL_SSL_LIBRARY_NAMES does not have a value, when the :ssl module is loaded, Allegro CL will determine the version of SSL on the host machine and make reasonable guesses about the associated system library names. You need set this variable (or the associated environment variable) only if loading the :ssl module with them unset does not work.
If you do need to specify library names because the defaults do not work or because Allegro CL is not loading the version of SSL that you want, you can, as we describe, set this variable or the ACL_SSL_LIBRARY_NAMES environment variable to specify the desired system libraries to load. You should also set the variable *aclssl-version* or its associated environment variable, as we also describe below.
This variable tells the system exactly which system libraries should be loaded and it allows you to specify several possible values in case different machines use different library names. You can set the value of the variable or you can set the environment variable ACL_SSL_LIBRARY_NAMES. If the variable has value :unset and the environment variable is set, the variable value will be set from the environment variable value.
If you set the value of the variable directly, the value must be a list of two entries, each a string or a list of strings (on Windows, each should be just a string). When both are strings, the entries are the names of the two OpenSSL shared libraries that must be loaded in order to enable the :ssl module. Each string is a file name with a full type suffix but no directory pathname.
When an entry is a list (UNIX only), the entries in the sublist should again be filenames with full type suffixes but no directory pathnames. When the :ssl module is loaded, the names in the list are tried in order until one denotes a library that loads without error.
Here is an example from Linux using two lists (note: these library names are examples only and are not recommended values):
cl-user(4): *ssl-library-names*
(("libcrypto.so.1.0.0" "libcrypto.so.10" "libcrypto.so")
("libssl.so.1.0.0" "libssl.so.10" "libssl.so"))
cl-user(5): If the value of *ssl-library-names* is :unset when the :ssl module is loaded and the environment variable ACL_SSL_LIBRARY_NAMES has a value, that value is read and the value of *ssl-library-names* is set to it. Here is an example setting ACL_SSL_LIBRARY_NAMES (again, the values are examples and not suggestions):
% setenv ACL_SSL_LIBRARY_NAMES "libcrypto.so.10 libssl.so.10"That value causes the value of *ssl-library-names* to become
cl-user(6): *ssl-library-names*
("libcrypto.so.10" "libssl.so.10")
cl-user(7): Thus *ssl-library-names* becomes a list of two strings. It is not possible to set ACL_SSL_LIBRARY_NAMES to a value which causes *ssl-library-names* to have sublists as elements so there are no choices of system libraries to load. We presume if you are setting the environment variable, you know which two libraries to specify.
If *ssl-library-names* has a value other than :unset or ACL_SSL_LIBRARY_NAMES has a value, then either variable *aclssl-name* should also be given a non-nil value or the appropriate environment variable, ACL_ACLSSL_NAME (for 8-bit Lisps) or ACL_ACLISSL_NAME (for 16-bit Lisps), should be given a value. See *aclssl-name* for a list of suitable values. That tells Allegro CL which Allegro CL shared library to load. (It cannot be reliably determined which release of SSL is being loaded just from the library names.) If *aclssl-name* is nil and the associated environment variables are unset, Allegro CL assumes SSL 1.0 is being loaded and loads the appropriate Allegro CL SSL 1.0 library for its character size (8 bit or 16 bit). Warning: a mismatch between the version of OpenSSL installed and the ACL SSL shared library loaded will result in errors, often well after loading.
If *ssl-library-names* is :unset and the ACL_SSL_LIBRARY_NAMES environment variable is unset, the OpenSSL version is determined by other means (see *aclssl-version*) and that information is sufficient to determing the correct Allegro CL library to load (since Lisp konws the OpenSSL version and its own character size) and for reasonable guesses to be made as to system library names. The system sets *ssl-library-names* to these reasonable guesses. As said at the beginning, this often works.
When the :ssl module is loaded, the filenames specified by *ssl-library-names* (whether set by the user, set from the ACL_SSL_LIBRARY_NAMES environment variable, or set by the system) will be looked for as the names of the OpenSSL libraries. If they are not found (searching directories specified by LD_LIBRARY_PATH on UNIX machines, PATH on Windows, and DYLD_LIBRARY_PATH on Macs) loading of the :ssl module will fail. If that happens, you must determine the SSL version and the names of the relevant system libraries and set *ssl-library-names* or ACL_SSL_LIBRARY_NAMES, and *aclssl-version* and try again.
OpenSLL is described in Secure Socket Layer (SSL) section in socket.html.
variable, excl package
The value of this variable, which must not by modified, is a control-table which contains std-newline-out-handler and std-tab-out-handler in their appropriate locations.
See Control-character Processing in streams.html.
variable, excl package
The variable *stderr* is initialized to a stream which corresponds to the C "FILE *" variable "stderr". In Common Lisp, there is a special called *error-output*, but that is defined to be the same as *terminal-io*. *stderr* can be used to communicate, in the same way it is with system programs on *NIX systems, for writing diagnostic output. NOTE: on Windows, *stderr* output goes to the Allegro CL console (rather than the IDE Listener window). There is no notion of "stderr" for Windows programs.
The *stderr* stream is unbuffered, so you must use force-output to ensure output sent to it is completed.
variable, excl package
*print-length* is bound to the value of this variable when step output is being printed.
The value of this variable may be, in addition to the values usually allowed for similar printer control variables, the symbol :follow. That value means use the current value of *print-length*. See Allegro CL print variables can follow the CL print variable value
in implementation.html. Also see *step-print-long-string-length*.
See also debugging.html for general information on stepping in Allegro CL.
variable, excl package
*print-level* is bound to the value of this variable when step output is being printed.
The value of this variable may be, in addition to the values usually allowed for similar printer control variables, the symbol :follow. That value means use the current value of *print-level*. See Allegro CL print variables can follow the CL print variable value
See also debugging.html for general information on stepping in Allegro CL.
variable, excl package
*print-long-string-length* is bound to the value of this variable when stepper output is being printed.
The value of this variable may be, in addition to the values usually allowed for similar printer control variables (nil and a positive integer), the symbol :follow. That value means use the current value of *print-long-string-length*. See Allegro CL print variables can follow the CL print variable value in implementation.html.
in top-level.html for more information and links to variables that control printing of long strings at the top-level and in various debugging contexts. See also debugging.html for general information on stepping in Allegro CL.
variable, excl package
When given a pathname in a directory that is not readable by the user running the Lisp process (because, for example, the user does not have read permission in that directory), probe-file should signal an error. (The ANS says "An error of type file-error is signaled if the file system cannot perform the requested operation.") However, Allegro CL (in common with other implementations of Common Lisp) has returned nil rather than signaling an error. Therefore, there is no programmatic way to distinguish between a file not existing and a file possibly existing, but in a directory that cannot be read by the user running Lisp.
This variable, *strict-probe-file*, controls the behavior of probe-file in this case. When nil (its initial value), probe-file returns nil when the argument path designates a file in an unreadable directory, preserving the behavior of earlier releases. When \*strict-probe-file\* is non-nil, probe-file signals an error in that case. (It also reports on what the access problems are.)
variable, excl package
This variable controls where output generated by autoloading and by load is sent. The value of this variable should be an output stream, t or nil. If the value is a stream, autoloading output and load messages are sent to that stream. If the value is t, such messages are sent to *terminal-io*. If the value is nil, load messages are sent to *standard-output* and autoloading messages are sent to *error-output*. The initial value is nil.
Autoloading and load messages are sent only if *load-verbose* is non-nil. If *load-verbose* is nil, the value of this variable is effectively ignored.
Autoloading is described in Autoloading in implementation.html. In order to keep the image size as small as possible, certain functionality is not loaded into the image until needed. Certain operations, such as calling functions or referencing certain packages causes modules defining the needed functionality to be loaded. A message noting the autoload is sent to a location specified by this variable, assuming *load-verbose* is non-nil.
variable, excl package
The value of this variable should be a positive integer or nil. We will discuss the value nil below. If the value is a positive integer, it specifies the number of bytes that must be tenured before a global gc warning or an automatic global gc (depending on the value of *global-gc-behavior*) occurs. The default value depends on the specific architecture but is generally 20 megabytes for 32 bit Lisps and 50 megabytes for 64 bit lisps. We strongly advise against values less than 5000000 (i.e. approximately five megabytes).
An internal counter keeps track of the number of bytes tenured. If the value of *global-gc-behavior* is not nil and the value of *tenured-bytes-limit* is also not nil, this counter is updated and then checked after each scavenge. If its value exceeds the value of *tenured-bytes-limit*, action depending on the value of *global-gc-behavior* is taken (a warning or a global gc). The counter is reset to 0 after a global gc (however triggered). If the value of *global-gc-behavior* is nil, the value of *tenured-bytes-limit* has no user visible effect.
Note that binding this variable will likely not have the desired effect because in the presence of multiprocessing (always enabled when the Emacs-Lisp interface is used), a garbage collection can be triggered by another process, in which case the bound value will be ignored.
If the value of *tenured-bytes-limit* is nil, the counter which keeps track of the number of bytes tenured since the last global gc is not updated after a scavenge. Thus, you have more control over global gc automation since you can switch off information gathering as well as control the action. Setting the value of *tenured-bytes-limit* to nil essentially suspends the automatic global gc behavior. For example, suppose you have a large application named foo, which uses the foo package. Then you might load it with the following code. Note that we bind the value of excl:*tenured-bytes-limit* to nil, suspending the collection of information about bytes tenured and explicitly handle gc's ourselves. Automatic gc's are re-enabled when the code has finished.
(defpackage :foo)
(let ((old-spread (sys:gsgc-parameter :generation-spread))
(excl:*record-source-file-info* nil)
(excl:*tenured-bytes-limit* nil))
(setf (sys:gsgc-parameter :generation-spread) 0)
(require :foo)
(princ "; Finished loading FOO. Global GC...")
(terpri) (force-output)
(gc :tenure) (gc :tenure) (gc t)
(setf (sys:gsgc-parameter :generation-spread) old-spread))See also gc.html for general information on garbage collection in Allegro CL, including information on gsgc switches and parameters.
variable, excl package
The value of this variable, which must not be modified, is a control-table which contains std-dc-newline-in-handler in its appropriate locations.
See Control-character Processing in streams.html.
variable, excl package
*print-array* is bound to the value of this variable when trace output is being printed.
The value of this variable may be, in addition to the values usually allowed for *print-array*, the symbol :follow. That value means use the current value of *print-array*. See Allegro CL print variables can follow the CL print variable value in implementation.html.
See also debugging.html for general information on tracing in Allegro CL.
variable, excl package
*print-circle* is bound to the value of this variable when trace output is being printed.
The value of this variable may be, in addition to the values usually allowed for *print-circle*, the symbol :follow. That value means use the current value of *print-circle*. See Allegro CL print variables can follow the CL print variable value in implementation.html.
See also debugging.html for general information on tracing in Allegro CL.
variable, excl package
*print-length* is bound to the value of this variable when trace output is being printed.
The value of this variable may be, in addition to the values usually allowed for similar printer control variables, the symbol :follow. That value means use the current value of *print-length*. See Allegro CL print variables can follow the CL print variable value in implementation.html. Also see *trace-print-long-string-length*.
See also debugging.html for general information on debugging in Allegro CL. See section The tracer in that document for information on tracing.
variable, excl package
*print-level* is bound to the value of this variable when trace output is being printed.
The value of this variable may be, in addition to the values usually allowed for similar printer control variables, the symbol :follow. That value means use the current value of *print-level*. See Allegro CL print variables can follow the CL print variable value in implementation.html.
See also debugging.html for general information on tracing in Allegro CL.
variable, excl package
*print-long-string-length* is bound to the value of this variable when trace output is being printed.
The value of this variable may be, in addition to the values usually allowed for similar printer control variables (nil and a positive integer), the symbol :follow. That value means use the current value of *print-long-string-length*. See Allegro CL print variables can follow the CL print variable value in implementation.html.
See Printing long strings in top-level.html for more information and links to variables that control printing of long strings at the top-level and in various other debugging contexts. See also debugging.html for general information on tracing in Allegro CL.
variable, excl package
The value of this variable is a string containing the version number of the Unicode Character Database used to build the Allegro CL character name table and collation rules. Unicode usage by Allegro CL is described in the Unicode section of iacl.html.
variable, excl package
This variable has an effect only on the Windows platform.
When the value of this variable is true, any Common Graphics window or widget that is created will be created using the Unicode (16-bit character) version of the Windows API rather than the ANSI (8-bit character) version, and the Unicode version will be used for those windows and widgets thereafter. Otherwise the ANSI version is used.
The initial value of this variable is true, meaning that all Common Graphics applications and the IDE will use the Unicode version of the Windows API at all times. Prior to release 9.0, Common Graphics and the IDE always used the ANSI version. That had been done in order to support the Windows 95 line, which required it, whereas we no longer support the Windows 95 line.
The Unicode version of the Windows API is needed for proper internationalization support, including the ability to use a variety of international character sets in the same application, and the ability to use Asian and other multibyte character sets without booting Windows with a particular default locale to support a particular character set.
We expect that there will be no reason for anyone to set this variable to nil, but the capability is provided in case an application needs to revert to ANSI mode for backward compatibility reasons. The variable is in the excl package so that its value could be set to nil in a clinit.cl file so that it's value is initialized before the IDE starts up, in case there is any need to run the IDE using the ANSI version as in earlier releases.
An alternative to this variable is to pass a use-unicode-winapi initarg to make-window, or to make-instance when creating a widget, to make a particular window or widget use a different mode than Common Graphics is generally using. (It is not known whether that actually works in all cases.)
variable, excl package
The value of this variable determines how the :utf-8s external-format deals with transcoding errors. Unless an error is signaled, all improper (non-utf-8) character or octets are replaced with the value returned by utf-8s-transcoding-error-char (for characters) or its char-int (for octets). It is one of the following values:
nil: Ignore transcoding errors silently.
:warn: Signal a warning of class utf-8s-transcoding-error.
:count: Replace the value of this variable with a count of transcoding errors.
an integer: Same as :count but continue counting from the given integer value.
:collect: Replace the value of this variable with a list of error markers. For each error signalled while converting characters to octets, push the offending character onto the list.
For each input error, push a list of the offending octets onto the list.
a cons: Same as :collect but continue pushing onto the given list.
:error (or any other value not above): Signal an error of class utf-8s-transcoding-error.
In all cases insert the utf-8s-transcoding-error-char character to replace the offending character or octets in the transcoded stream.
See Strict external formats which do not allow improper characters in iacl.html for more information on the :utf-8s external format, international characters and external formats in general.
variable, excl package
The handling of nested #+/#- conditionals in Allegro CL changed in release 8.0 in a non-backward-compatible way. When this variable is true (its initial value is t), a warning is signaled when a nested conditional is encountered, noting that the behavior has changed and that the conditionalized code may therefore work differently. the warning is suppressed when this variable is nil.
The following two forms are examples of nested conditionals whose behavior has changed (the old and new behavior are shown in the section of implementation.html linked to below):
(list #+allegro :allegro #-allegro #+foo :foo #-foo :default)
(list #+allegro :allegro #-allegro #+foo :foo)The section The issue of nested conditionals in Allegro CL in implementation.html discusses the issue assocated with this variable in detail, with examples. See also *sharp-plus-de-facto-standard-compatible*.
Copyright (c) 2023, Franz Inc. Lafayette, CA., USA. All rights reserved.
|
Allegro CL version 11.0 | ||||||||