Normalize logging output to a Lisp comment prefix (#\;) with a single tag
that identifies the "subsystem" emitting the diagnostic.
ABCL-ASDF:*MAVEN-VERBOSE* SYS:*ABCL-CONTRIB-VERBOSE* have been removed; use
CL:*LOAD-VERBOSE* to control them.
ASDF::*VERBOSE-OUT* and QUICKLISP-CLIENT::*QUICKLOAD-VERBOSE* cannot
be easily modified while keeping in-sync with upstream, but they both
seem to respect setting CL:*LOAD-VERBOSE* to nil to muffle output.
EXT::*WARN-ON-REDEFINITION* signals conditions rather than just
emitting error messages, so it has not been touched as theoretically
some compiler tooling may be somehow be depending on its SIGNAL
behavior. As such, once an implementation that signals the same
warnings as EXT::*WARN-ON-REDEFINITION* based on CL:*COMPILE-VERBOSE*
setting should be maintained during a deprecation phase.
------------------------------------------------------------------------
# From <https://github.com/armedbear/abcl/commit/6cc94a54cf9256b2a0f13857d4c448d3b5c044fc>
## Alan Ruttenberg
Really this should just respect load-verbose. If you really want to
fix this properly, do that. There are a proliferation of settings one
has to know about if one wants ABCL to shut up while starting up, and
any beginner will have a hell of a time accomplishing this. There
ought to be a single variable that indicates you don't want these
messages.
- *load-verbose*
- system::*verbose*
- asdf::*verbose-out*
- abcl-asdf::*maven-verbose
- quicklisp-client::*quickload-verbose*
- ext::*warn-on-redefinition*
## Mark Evenson
Using CL:LOAD-VERBOSE to unify the control of all this logging
behavior for ABCL is an excellent way forward here.
This wouldn't help with quicklisp-client::quickload-verbose (not our code).
An alternative would be to have some sort of "categorical logging
system" (ala log4j) which would allow one to selectively enable
classes of logging output ("show me all diagnostic from loading
ABCL-CONTRIB"), but a basic boolean predicate here, unified into the
standardized mechanism would go a long ways.
------------------------------------------------------------------------
Originated with <https://github.com/armedbear/abcl/pull/37>.

In QUICKLISP-ABCL, the parent of the Quicklisp directory was
defaulting to (USER-HOMEDIR-PATHNAME). We make this customizable by
declaring a special variable QUICKLISP-ASDF:*QUICKLISP-PARENT-DIR*.
Originally part of <https://github.com/armedbear/abcl/pull/37>.

We introduce an ASDF component JDK-JAR, a jar file where the pathname
and name are relative to the 'java.home' property of the executing
JVM.
Note that the use of JDK-JAR consistutes an experimental interface
with a lot of potential problems going forward. We note some of those
issues for further consideration:
1) Java9 does away with the packaging of system tools in jar files,
using the Java module system to provide "optimized" access to system
resources. Therefore, a better abstraction would be to somehow
describe the artifacts that need to be loaded to satisfy the
dependencies, and then provide mappings to strategies that locate and
load them within the JDK filesystem. c.f. <http://abcl.org/trac/ticket/423>.
2) The structure of the 'java.home' directory varies in unknown ways
between JDK versions and across platforms, making the use of JDK-JAR
relative pathnames need special casing for various situations.
3) ABCL may be run on a JRE runtimes which have a different directory
structure than a JDK, most notably missing the 'tools.jar' artifact.
4) Given the problems arising from points 3 and 4, meaningful
conditions and appropiate restarts should be emitted by ABCL-ASDF when
it cannot satisfy JDK-JAR dependencies. This machinery should also be
extended to the other major current deficiency in ABCL-ASDF lack of
intellible errors/meaningful restarts when Maven cannot be located.
Despite these problems, it is more useful to experiment with being
able to reference JDK artifacts in ABCL-ASDF definitions than not, so
we include JDK-JAR as an experimental feature.
We need some way to mark the JDK-JAR feature as experimental. The
easiest way forward would be to split it off into a separate file
compilation unit with appropiate comments.
Merges <https://github.com/armedbear/abcl/pull/35/files>.

Fix printing of MacroObjects. Also bit of customization for function
printing. (setting *function-print-object-prefix* to "" should make
print-object for functions agree with #"printObject" at least for
top-level functions)

<https://github.com/armedbear/abcl/pull/27>
Figured out how to let arglist get saved during build. Record source
etc. for top-level closures. Once #'delete is available, don't allow
duplicate source entries

The ANSI-TEST DESCRIBE.* tests were failing because they tried to
describe 'cl:lambda, and there was an error printing the
symbol-function <http://abcl.org/trac/ticket/438>.
In the process of tracking this down I found other cases that might be
problematic and so revised any-function-name, maybe-jss-function, and
print-object to avoid those problems.

<thing> is either {<lisp expression>} or a class name or abbreviation that find-java-class can use
If <thing> is a lisp expression, then it is evaluated (in the lexical environment) and used as an instance
If <thing> is a class name the result of find-java-class is used and a static field access is done.
<field> is either {<lisp expression} or string
If <field> is a lisp expression it should evaluate to a string that names a field
If <field> is a string (no quotes) it is used as the field name
eg. #"foo.bar.baz" -> (get-java-field (find-java-class 'foo.bar) "baz" t)
#"{foo}.baz" -> (get-java-field (find-java-class foo) "baz" t)
From <https://github.com/armedbear/abcl/pull/25/commits/b94639b21843c439a5bf437661446c0b65a67791>.