load-patches

Function

Package: system

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.
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 #\0.

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), superseded (the superseded argument is true) 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. Therefore, if p0a023.001 is present but marked superseded and p0a023.002 is present, there is no problem (indeed, this is the intended situation). But if both files exist and neither load aborts, the patch files are inconsistent and something might be seriously wrong. Again, all patch files are processed and all inconsistent ones are recorded but then an error is signaled. The user should exit Lisp and solve the inconsistency at this point. All patch files are processed so that all inconsistencies are discovered.

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.

The documentation is described in introduction.htm and the index is in index.htm.

Created 2000.10.5.