specifically add support for using a racket other than
the one that drracket is currently using to find the
current-library-collection-paths and current-library-collection-links
also, split up the code in a better way and some bug fixes
more precisely, fix the way that the drracket test utilities
deal with the test suite so that when certain prefs are
initialized (as part of a test suite startup of drracket),
they actually get initialized properly (this was broken for
preferences whose value gets read particularly early)
Then use that to disable autosaving in the no-write-and-frame-leak.rkt
test
Fallback checked original module only if `deserialize-info` was
missing, but it's possible to have a mixture of `deserialize-info`
and original-module exports.
This change is slightly incompatible, because `serializable-struct`,
`define-serializable-struct`, and `define-serializable-class` no
longer `provide` and identifier that they used to. Instead, the identifier
is provided by a `deserialize-info` submodule.
The deserializer looks for a `deserialize-info` submodule, and then
falls back to using a module if the submodule is not available.
Depth 0 is the same as `--html`, depth 1 is the same as `--htmls`,
and higher depths cause sections and subsections to be rendered
into separate directories when they have their own pages.
Previously, (check-exn exn? 'foo) would pass even though 'foo is not a
thunk. Now it raises an exn:fail:contract? exception.
Previously, (check-not-exn 'foo) would produce a check failure. Now it
raises an exn:fail:contract? exception.
Downloaded files are keyed on the source URL and checksum, and the
cache is used only when a checksum is known.
The cache addresses two situations:
* when installing many packages over an unreliable connection,
the cache effectively lets a retry pick up where a previous
attempt failed
* when creating clean builds frequently, the downloads from a
previous build can be reused (as long as the package's checksum
does not change)
The cache location and limits are configurable, and they default to
a subdirectory in the user's add-ons directory (not version-specific),
1024 files, and 64 MB.
If a failure happens during staging (checksum and unpackaging) of a
package that has an entry in the cache, the entry is removed. The
file-cache library, meanwhile, implements a limit on the cache size
and defends against uncooperative filesystems.
