The code duplication was there only to support
constructing the name for the optimized contract;
instead we actually just built the name as we go
(the old version actually built the old contract
and then used that to get the name)
also:
- racket/contract/base now requires basic-opters.rkt
so all of the opters are registered when racket/contract/base
is loaded, not just the non-basic ones
- fix the ordering of the names of subcontracts in or/c
- make opt-contracts print a more meaningful name
for online expansion errors
This avoids drawing the margin highlight when it isn't inside the
region being repainted and it avoids even figuring anything out about it
when there is currently no error range
NOT for the release branch
Specifically, allow a name to be specified with an
extension such that subsequent uses of those extensions
will replace mixins instead of adding new ones
This commit extends make-base-eval, make-base-eval-factory, and
make-eval-factory with an #:eval and input-program inputs so that
these functions are more like racket/sandbox make-evaluator.
This change revisits commit eb7fa6f066. I think the problem
is not in the rendering of index entries but on the generation
side. The generator was converting Xexprs to strings, except
that strings were left as-is, which is inconsistent. So,
I've reverted commit eb7fa6f066 and fixed the generator.
The mrlib/terminal library fits in the mrlib collection in that it is
a random library that uses our GUI system that doesn't belong in
racket/gui somewhere.
It also doesn't really fit into the framework as the framework is
supposed to be a colleciton of useful mixins for our racket/gui
classes.
It does, however, benefit from using the framework (and the string
constants library) so the best option seems to be to think of mrlib as
consisting of separate libraries that fit into two different layers
of the dependency hierarchy. So that's what this commit does.
drracket's "install package" menu item
It will infer whether to use 'raco pkg update' or
'raco pkg install' based on the currently installed
set of packages (but, of course, the details
section of the dialog lets you override this inference
if necessary)
