OpenMCL has traditionally been released with settings that make it convenient to do development of OpenMCL itself; sometimes, those settings make it less convenient to use OpenMCL for development or deployment of other software.
Specifically, OpenMCL has been released with (IN-PACKAGE "CCL")
in
effect, and with no protection against inadvertent redefinition of builtin,
predefined functions and methods. The former behavior isn't correct (though
it's often expedient); the latter behavior (and especially the two in
conjunction) can be dangerous.
Beginning with release 0.11, OpenMCL comes up in the
CL-USER
package and protects all functions and
methods in the initial image from accidental redefinition.
(Attempts to redefine a predefined function or method result in
a continuable error.)
These settings may make using OpenMCL to develop OpenMCL a bit
more awkward, since much of that process assumes that the CCL
package is current (and a primary purpose of that process is to
redefine some "predefined, builtin functions".) The standard,
"routine" ways of building OpenMCL from
sources - COMPILE-CCL
,
XCOMPILE-CCL
, and XLOAD-LEVEL-0
- bind
*PACKAGE*
to the "CCL" package and enable the
redefinition of predefined functions; the symbols
COMPILE-CCL
, XCOMPILE-CCL
, and
XLOAD-LEVEL-0
are additionally now exported from
the "CCL" package.
Some other (more ad-hoc) ways of doing development on OpenMCL -
compiling and/or loading individual files, incrementally
redefining individual functions - may be awkward unless one
reverts to the mode of operation which was traditionally offered
in OpenMCL. (Some OpenMCL source files - especially those that
comprise the bootstrapping image sources and the first few files
in the "cold load" sequence - are compiled and loaded in the
"CCL" package but don't contain (IN-PACKAGE "CCL")
forms, since IN-PACKAGE
doesn't work until later
in the cold load sequence.)
Description |
When true, attempts to redefine (via
Note that these are |
Syntax | set-development-environment &optional unmark-builtin-functions |
Description |
Arranges that the outermost special bindings of *PACKAGE*
and *WARN-IF-REDEFINE-KERNEL* restore values of the "CCL"
package and NIL to these variables, respectively. If
the optional argument is true, marks all globally defined functions
and methods as being "not predefined" (this is a fairly expensive
operation.)
|
Syntax | set-user-environment &optional mark-builtin-functions |
Description |
Arranges that the outermost special bindings of *PACKAGE*
and *WARN-IF-REDEFINE-KERNEL* restore values of the "CL-USER"
package and T to these variables, respectively. If
the optional argument is true, marks all globally defined functions
and methods as being "predefined" (this is a fairly expensive
operation.)
|
The somewhat bizarre behavior of both SET-USER-ENVIRONMENT
and
SET-DEVELOPMENT-ENVIRONMENT
with respect to the special variables
they affect is intended to allow those constructs to take effect when the
read-eval-print loop next returns to a top-level '? ' prompt; the constructs
can meaningfully be used inside LOAD
, for instance (recall that
LOAD
binds *PACKAGE*
), though using both constructs
within the same LOAD
call would likely be pretty confusing.
"user" and "development" are otherwise very generic terms; here they're intended to enforce the distinction between "using" OpenMCL and "developing" it.
The initial environment from which OpenMCL images are saved is one where
(SET-USER-ENVIRONMENT T)
has just been called; in previous
versions, it was effectively as if (SET-DEVELOPMENT-ENVIRONMENT T)
had just been called.
Hopefully, most users of OpenMCL can safely ignore these issues
most of the time. Note that doing (SET-USER-ENVIRONMENT
T)
after loading one's own code (or 3rd-party code) into
OpenMCL would protect that code (as well as OpenMCL's) from
accidental redefinition; that may be useful in some cases.