load-patches

Function

Package: system

ToC

DocOverview

CGDoc

RelNotes

Index

PermutedIndex

Allegro CL version 6.2
Object described on page has changed in 6.2

load-patches

Arguments: &key update-directory product patch-file-filter patch-file-sorter (libfasl *libfasl*)

This function loads patch files from update-directory and does useful checks on the consistency of the patch files, described below.

The arguments are:

update-directory	The directory in which to look for patch files. Defaults to the Allegro CL patch directory, sys:;update.
product	Value should be `nil`, meaning load all patch files regardless of the product code (the third letter of the filename), or a character or list of characters, meaning load only those files whose product code (third letter) match the single character or is in the list of characters.
patch-file-filter	A function of three arguments, a product code, a pathname, and a version (the [m] described in The Allegro CL patch naming scheme in delivery.htm). Returns true if the pathname names a valid patch file (based on parsing the name and location only).
patch-file-sorter	A function of three arguments, a product, a list of patch files (validated by the patch-file-filter), and a version ([m] described in The Allegro CL patch naming scheme in delivery.htm). Sorts the list into the order in which the files should be loaded (from highest to lowest).
libfasl	A boolean indicating whether the patch files should be loaded in libfasl mode. See The Allegro Presto algorithm in loading.htm for more information on libfasl loading.
version	Specifies the version ([m] described in The Allegro CL patch naming scheme in delivery.htm). Should be a character object naming a decimal digit (#\0 - #\9). This is for use with application patches only. Defaults to the value of `excl::cl-patch-version-char`.

There should be an update/ subdirectory to your application directory (or wherever sys: translates to in your application). Allegro CL patches will be loaded from that directory. You can make patches for your own applications if desired. See Patching your application after delivery in delivery.htm.

As patches are loaded, information on them is recorded in Lisp. This information includes the patch id, the version and the description (the three required arguments in the defpatch form at the top of the patch file). The loading of the body of the patch file (everything after the defpatch form) is aborted if the defpatch version specified in the defpatch form is out-of-date (this should be very rare) or if the patch is marked not-post-loadable (the post-loadable argument to defpatch is nil), or withdrawn (the withdrawn argument is true). Loading will also be aborted if featurep, applied to the value of the feature argument in the defpatch form, returns nil. If loading is aborted, no error is signaled (because the condition signaled is caught by the appropriate restart in sys:load-patches) and subsequent patch files are loaded (but information on why the loading was aborted is saved).

As each patch file is loaded, its id is compared to already loaded (and not aborted) patches. If any patch with the same id is seen to already be loaded, the conflicting patch is placed on a special list. After all patches are loaded, that list is checked, and if it is non-empty, sys:load-patches signals an error.

It is important to be clear on what we mean by two loaded patches with the same id because we have used the word load loosely up to this point. We describe just above how a patch file is `loaded' and its defpatch form is examined. Information in the defpatch form might cause the load to be aborted. Such patches are not loaded in the sense of this paragraph because everything after the defpatch form is ignored.

Patches for your application are described in Patching your application after delivery in delivery.htm. Patches for Allegro CL products are described in Patches in introduction.htm. See also update-allegro for information on automatically downloading Allegro CL patches.