One problem with commit 299063d7c1
is that the new method for computing the lime green arrows no
longer has the information necessary to distinguish different
identifiers that come from the same require.
This means that, before this commit, mousing over an imported
identifier can be a real interactivity killer. So, instead of
adding more information to distinguish those ids, lets just
try not draw the lime green bubbles for imported identifiers
and see how that feels
that have overlapping ranges in the editor; also got rid of the
id-set stuff
Getting rid of the id-set information that was computed means that now
the mouse-over green bubbles, the "jump to next binding occurrence"/
"jump to bound occurrence" keybindings/menu items, and the renaming
are all being computed from the arrows information as needed, instead
of building up sets as check syntax collects information. This may
change the way Check Syntax behaves in some cases; so far the only
example I've found has been strange and are arguably for the
better. Specifically, this program
(define-syntax-rule (m x) (λ (x) x)) (m z)
no longer draws a green bubble when you mouse over the "z", since
there are no arrows (the only arrow that might have been drawn is
discarded since its start and end points are the same place).
This speeds up the "analyze the expanded code" phase of check syntax,
making it approximately 1.6x faster than before (going from about 31
seconds to about 19 seconds for this phase for the
drracket/private/unit.rkt file (on my machine)). Also, the replay
phase is probably a bit faster now, tho, too: there were 1.07x fewer
elements to process in the trace that comes back from online check
syntax now for that same file (33063 to 30842)
Note that this is only that one phase: this doesn't count the time to
actually expand the program (the dark blue bubble phase) nor the time
to send the results between places, nor the time to replay the
collected information (the light purple bubble phase).
the package installer
and make DrRacket have two separate menu items, one for installing a package
(which now looks simpler again) and one for doing all of the things you can
currently do with the package system in a GUI
A language can now introduce a `configure-runtime' submodule that
is `dynamic-require'd before the enclosing module.
This new submodule protocol provides a more general and
easier-to-understand way of configuring the run-time environment for
a module's language, as compared to the `module->language-info'
path (through a `get-info' function, via a 'configure-runtime value,
and finally loading the specified module).
The `module->language-info' path remains in place, and it is
checked after a `configure-runtime' submodule is run, since
that order is likely to be the most backward compatible.
Allow macro writers to put an 'original-for-check-syntax
property on identifiers and, if it is there, don't
insist on syntax-original? holding, just draw arrows anyway
passed to the error-display-handler during expansion
(not just the exn records that actually get raised)
the motivation is to do a better job with TR's way of signalling
mutiple error messages.
... for the purpose of "populate 'compiled' directories" --- but only if
the user has write permission for the package directory.
This change may or may not be a good idea. The idea is that installed
packages generally should be treated in the same way as the main
"collects" tree (e.g., avoiding debugging instrumentation), but if you
happen to be developing a package, then you want it treated like things
that are not in the main "collects" tree. So, how do you pick? Maybe
opening a file in the package is a good way to pick.
If DrRacket decides to skip a file for "populate compiled",
then there may exist a file in "compiled/drracket", anyway,
or there may be such a file for some depenency of the skipped
file. Before this patch, that situation was considered to be a
broken installation, and things would go bad in the likely
case that the "compiled/drracket" files were out of date.
To avoid that problem, parameterize `used-compiled-file-paths'
to drop the DrRacket "populate compiled" target while loading
the skipped file.
This change sets up a more selective "populate compiled" where
a package's modules might switch between eligible and
ineligible for compilation by DrRacket.
from when the file doesn't have an error
More precisely, keep two sets of depndencies for a given
open tab. If the file expanded without error then we consider
that authoratative and keep that set of dependencies around
even if a later expansion fails. So there are two sets of
dependencies for each tab. When expansion succeeds, we reset
both of them, but if expansion fails then we reset only one,
preserving the set we got from the last successful expansion
please include in the release
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
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)
Because of a limitation in our GC tech (and because I have not
sorted out how to program around it (which should be possible))
when the "is it safe to rename this variable" check may silently
just say "yes" when it really doesn't know the correct answer.
It turns out that this was happening on every attempt to rename
after the first one (in a given online check syntax run) due to
a bug, now fixed in this commit (the "loop" didn't actually loop...)
Also, moved the creation of the thread to its own function to
make the things it closes over more syntactically apparent.
