Commit 58968bce authored by Robert Goldman's avatar Robert Goldman
Browse files

Merge branch 'documentation-tweaks' into 'master'

Documentation tweaks

See merge request !54
parents 73583e56 9b47bc18
...@@ -2124,20 +2124,21 @@ Operations are invoked on systems via @code{operate}. ...@@ -2124,20 +2124,21 @@ Operations are invoked on systems via @code{operate}.
@code{operate} invokes @var{operation} on @var{system}. @code{operate} invokes @var{operation} on @var{system}.
@code{oos} is a synonym for @code{operate} (it stands for operate-on-system). @code{oos} is a synonym for @code{operate} (it stands for operate-on-system).
along with the supplied @var{initargs}, @var{operation} is an operation designator:
to @code{make-operation} (which will call @code{make-instance}) it can be an operation object itself, or, typically,
a symbol that is passed to @code{make-operation} (which will call @code{make-instance}),
to create the operation object. to create the operation object.
@var{component} is a component designator, @var{component} is a component designator:
usually a string or symbol that designates a system, it can be a component object itself, or, typically,
sometimes a list of strings or symbols that designate a subcomponent of a system. a string or symbol (to be @code{string-downcase}d) that names a system,
@var{operation} is a symbol that is passed, more rarely a list of strings or symbols that designate a subcomponent of a system.
@var{initargs} for operations are now deprecated, and will be removed. The ability to pass @var{initargs} to @code{make-operation} is now deprecated, and will be removed.
For more details, @pxref{make-operation}. For more details, @pxref{make-operation}.
Note that dependencies may cause the operation Note that dependencies may cause the operation
to invoke other operations on the system or its components: to invoke other operations on the system or its components:
the new operations will be created the new operations may or may not be created
with the same @var{initargs} as the original one. with the same @var{initargs} as the original one (for the moment).
If @var{force} is @code{:all}, then all systems If @var{force} is @code{:all}, then all systems
are forced to be recompiled even if not modified since last compilation. are forced to be recompiled even if not modified since last compilation.
...@@ -5620,14 +5621,14 @@ and lose configuration as they do. ...@@ -5620,14 +5621,14 @@ and lose configuration as they do.
@code{asdf-ecl} and its short-lived successor @code{asdf-bundle} are no more, @code{asdf-ecl} and its short-lived successor @code{asdf-bundle} are no more,
having been replaced by code now built into ASDF 3. having been replaced by code now built into ASDF 3.
Moreover, the name of the bundle operations has changed since ASDF 3.1.3. Moreover, the name of the bundle operations has changed since ASDF 3.1.3.
Starting with ASDF 3.2.0, @code{load-system}
And yet, the feature is not enabled to be used by @code{load-system} by default on ECL as originally intended, will once again use @code{load-bundle-op} instead of @code{load-op} on ECL,
because of a bug in ECL itself found during testing. as originally intended by @code{asdf-ecl} authors, but disabled for a long time
due to bugs in both ECL and ASDF.
Some of the bundle operations were renamed after ASDF 3.1.3, and the old Note that some of the bundle operations were renamed after ASDF 3.1.3,
names have been removed. Old bundle operations, and their modern and the old names have been removed.
equivalents are: Old bundle operations, and their modern equivalents are:
@itemize @itemize
@item @item
......
...@@ -200,10 +200,10 @@ ...@@ -200,10 +200,10 @@
<h3>Supported Implementations</h3> <h3>Supported Implementations</h3>
<p> <p>
ASDF 3 now supports all CL implementations ASDF 3 now supports all CL implementations
that seem to have any current user base, and then some. The one that seem to have any current user base, and then some.
exception is ECL on Windows, which appears to have bugs that preclude But ASDF does not magically turn broken implementations into working ones,
full functioning of ASDF and UIOP. ASDF will run on Windows ECL, but and some ASDF or UIOP features may not work
we cannot provide support for this platform. on less-maintained implementations that do not support them (see below).
</p><p> </p><p>
Most implementations provide ASDF as a module, Most implementations provide ASDF as a module,
and you can simply <tt>(require "asdf")</tt>. and you can simply <tt>(require "asdf")</tt>.
...@@ -218,15 +218,37 @@ ...@@ -218,15 +218,37 @@
but some hacking is probably required to make the latest ASDF work well but some hacking is probably required to make the latest ASDF work well
with the latest release of these implementations: with the latest release of these implementations:
<ul><li> <ul><li>
CLISP is generally well-tested with ASDF, though it has a few minor bugs.
The implementation has received only minimal maintenance since 2010,
and the last official release ships with an antique version of ASDF;
however ASDF has been recently updated in its source control system,
and there is hope of a new release some day soon.
If needs be, you can replace CLISP's provided ASDF with a newer one,
or use an upgrade on top of that.
</li><li>
CormanLisp was recently open-sourced.
Its bundled ASDF has not yet been updated from 1.x;
ASDF 3.1 should work fine with it, but several features were disabled
because CormanLisp was insufficiently compliant with the CLHS,
and requires some work in this regard.
Ask the new CormanLisp maintainers for updates.
</li><li>
ECL is generally well-tested with ASDF, but
its bytecode compiler doesn't support the bundle operations, and
support for Windows seems to be less stable.
For instance, as of November 2016,
<code>cl:require</code> and <code>ext:system</code> (and thus <code>uiop:run-program</code>)
seem not to be working correctly on Windows.
</li><li>
GCL is somewhat maintained but its maintainer doesn't seem to care about ASDF, GCL is somewhat maintained but its maintainer doesn't seem to care about ASDF,
and hasn't replied for years to requests for bug fixes and and hasn't replied for years to requests for bug fixes or
for providing ASDF via <tt>(require "asdf")</tt> for providing ASDF via <tt>(require "asdf")</tt>
</li><li> </li><li>
CormanLisp was recently open-sourced; Genera was never open-source and never bundled ASDF,
its bundled ASDF has not yet been updated from 1.x; but should otherwise just work with a recent ASDF 3.1,
ASDF 3.1 should work fine with it, but a few features were disabled if you somehow have a license and a working version.
because CormanLisp is insufficiently compliant with the CLHS, There are rumors of people doing active development with it
and requires some work in this regard. and having minor patches to improve ASDF on it.
</li><li> </li><li>
MCL similarly was open-sourced, but never bundled ASDF; MCL similarly was open-sourced, but never bundled ASDF;
ASDF 3.1 should work just fine with it, ASDF 3.1 should work just fine with it,
...@@ -234,17 +256,18 @@ ...@@ -234,17 +256,18 @@
so a lot of work is required to make something out of it so a lot of work is required to make something out of it
— at which point, you might just use CCL. — at which point, you might just use CCL.
</li><li> </li><li>
XCL is now an abandoned experiment. It provides some old ASDF 2; Mocl has its own heavily modified variant of ASDF2, and
but you can replace it with ASDF 3.1, which works well with it, is the only implementation not currently supported by ASDF3.
inasmuch as anything works at all with XCL. To make it work with ASDF 3 would require ASDF to be taught about
natively supporting cross-compilation.
</li><li> </li><li>
Genera and SCL were never open-source and never bundled ASDF, SCL was seemingly abandoned and never open-sourced.
but should otherwise just work with a recent ASDF 3.1, It never bundled ASDF, but should otherwise just work with a recent ASDF 3.1,
if you somehow have a license and a working version. if you somehow have a license and a working version.
</li><li> </li><li>
Mocl has its own heavily modified variant of ASDF2, and XCL is now an abandoned experiment. It provides some old ASDF 2;
to make it work with unmodified ASDF 3.x would require but you can replace it with ASDF 3.1, which works well with it,
ASDF to be taught about natively supporting cross-compilation. inasmuch as anything works at all with XCL.
</li></ul> </li></ul>
</p> </p>
<table border="1"> <table border="1">
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment