The 'start-menu? aux key for launcher creation changed to 'start-menu,
with a real-number value indicating a request and precedence for
auto-launching (where a precedence is needed because only one application
can be auto-launched).
The "repo-time-stamp" collection used to be omitted from a
release, but to keep things simpler, it's staying in the
"drracket" (and therefore "main-distribution") package. The
build process installs an empty `build-stamp' value (by default)
into a release build, or it installs a useful stamp for
a non-release build.
This looks like a good use case for submodules, because the
native-library packages change infrequently, and no one cares
about the history of changes relative to the rest of the
project (except to be able to get a set of packages that is
consistent with the rest of the repository).
The change avoids the problem that `make' on Mac OS X would
try a `git update', which is no good if you happen to be
offline (and have your "buidl.native-pkgs" repo pull from the
obvious place).
Finally, it's easier for Windows users, since `git submodule init'
and `git submodule update' is easier to use and remember than
`git clone <some-repository-URL>'. The makefile more helpfully
complains if "native-pkgs" doesn't seem to have been initialized
as a submodule.
Also add "gui-pkg-manager" packages, including a "Racket Package Manager"
GUI application (that needs a better icon).
The package that supplies "Racket Package Manager" is not in the main
distribution, since DrRacket already includes the GUI package manager.
An installation has a name (via the configuration file "config.rktd")
that defaults to the version string. The name, instead of the
Racket version, is used for forming the path to the user "collects"
directory, user packages, and so on. The `user' package scope is
thus user- and installation-name-specific (instead of user- and
version-specific).
Remove `shared' package and link scope, since the notion of
installation names generalizes the concept (a set of installations
can be given the same name) and fits it into `user' scope.
Added four macros to racket/generic:
- chaperone-generics
- impersonate-generics
- redirect-generics (dynamically chooses between the above two)
- generic-instance/c
All take pairs of method names and wrappers (procedures or contracts),
and turn those into appropriate chaperone, impersonator, or contract wrappers
on the method tables of the given structs.
Used this to rewrite set/c to give better error messages.
Added documentation gen:set and reorganized documentation to set aside functions
that are methods of gen:set. Documented new mutable, weak, and custom set
types. Documented new methods for mutating sets.
Reorganized the documentation with a separate subsection for gen:dict methods,
split into primitive and derived depending on whether they have fallback
implementations. Added the new methods dict-empty?, dict-copy, dict-clear, and
dict-clear!. Documented dict-supports?, dict-support/c, make-custom-hash-types,
and define-custom-hash-types.
Added documentation for #:fast-defaults, #:fallbacks, and #:defined-predicate.
Also documented #:defined-table as deprecated in favor of #:defined-predicate,
and touched up other parts of the documentation, mostly by reordering.
Sets are now implemented as a generic interface, and lists count as sets. Most
of the set functions have been added as methods, including mutable versions of
imperative update methods.
The definition form and function consume an equality predicate and optional hash
code functions and key predicate, and produce predicates and constructor
functions for hash table-based dictionaries using the given equality and hash
functions. Immutable, mutable, and weak dictionaries are defined.
- Added hash-empty?, hash-clear, and hash-clear! for hash tables.
- Added dict-empty?, dict-clear, and dict-clear! for dictionaries.
- Made all dict functions exported by racket/dict into generic methods; turned
the existing implementations into fallbacks.
The #:dispatch option specifies a second, less strict predicate for a #:defaults
or #:fast-defaults clause. The main predicate is still used for the generics
group's type predicate, but the dispatch predicate is used in choosing which
method implementation to use. The #:dispatch option is useful when the dispatch
predicate is disjoint from all other instances, is significantly cheaper to run
than the main predicate, and the full checks can be meaningfully deferred in
method implementations.
Specifically, this is useful in the implementation of iteration for
association-list dictionaries. The dict-iterate-{next,key,value} functions do
not need to test (andmap pair? dict) if the given dict is eq? to the one stored
in the given iterator. The dispatch predicate, list?, is much cheaper.
The #:defined-predicate option is like #:defined-table, but it defines a
two-argument predicate that only processes the requested method name and doesn't
allocate a hash table each time it is called.
Method implementations provided via #:fallbacks, #:defaults, and #:fast-defaults
are now called directly by method procedures rather than stored in a vector and
extracted by index. This should hopefully improve inlining for methods.
For datatypes that are disjoint with structs that might implement the generic,
this adds a "fast path" implementation that doesn't need to test for struct
properties.
This work is in preparation for widening the interface of gen:dict with
operations like dict-for-each, dict-update, etc., each with a fallback
implementation. The property prop:dict, with its documented, fixed-length
vector representation, cannot be extended, whereas a generic with optional
methods can be.
The define-generics form can now derive existing struct properties, so that any
instance of the new generics group is also an instance of the struct property.
