are shown in the corner of the window
This was an attempt to avoid opening up a whole status line in the
bottom of the window much of the time. But it doesn't really work
since as soon as you have a syntax error (which are relatively common)
you get that whole line opened up. That it, this attempted GUI interaction
depended on the bogus premise that read errors are somehow happening
in a transient way between error-free states.
closes PR 13267
getter/setters instead of overriding a method
this has the benefit that the delegate does not have to be
rebuilt when switching tabs in drracket; we just leave the
old delegate on the old definitions text, and the swap it
back into the editor-canvas when we swap the text% object
itself back in.
coloring in the contour window to make only a single call to
invalidate-bitmap-cache
It was making two before, which could have pretty similar regions,
leading to two repaints instead of just one. When pushing the down
arrow near the bottom of the visible regions of the definitions text
was causing those two calls to take about 30 milliseconds and after
this change the one call seems to be about half that (but there is
lots of variance so I'm only sure that it helped some, not how much)
A long time ago, I tried to improve the interactiveness
of DrRacket when the contour window was open with the
code that is removed in this commit. Looking at it today,
it seems clear that this code was buggy (and, now that
we've had lots of experience with it, it didn't actually
help with interactivity either)
The problem is that the code didn't record enough
information about the change to the editor in the thunk put
into the 'todo' field. It would remember that a particular
range was out of date, but it woudln't remember which
characters were in that range, so when it would go to copy
the characters, it may be getting the wrong characters
(since another edit may have happened since the thunk was
stored in the todo field)
This change also has the side benefit that the time it takes
to change the contour window is now being tracked by the
colorer, which means that it'll give up a bit sooner
coloring less in each go, but hopefully maintaining the
interactivity
in the original GitHub fork:
https://github.com/ntoronto/racket
Some things about this are known to be broken (most egregious is that the
array tests DO NOT RUN because of a problem in typed/rackunit), about half
has no coverage in the tests, and half has no documentation. Fixes and
docs are coming. This is committed now to allow others to find errors and
inconsistency in the things that appear to be working, and to give the
author a (rather incomplete) sense of closure.
inside the same collection so this file can (when other
things aren't too different) be used in a version of racket
that doesn't generally have the tests
Track fixnum results in the same way as flonum results to enable
unboxing, if that turns out to be useful. The intent of the change,
though, is to support other types in the future, such as "extnums".
The output `raco decompile' no longer includes `#%in', `#%flonum',
etc., annotations, which are mostly obvious and difficult to
keep in sync with the implementation. A local-binding name now
reflects a known type, however.
The change includes a bug repair for he bytecode compiler that
is independent of the generalization (i.e., the new test case
triggered the old problem using flonums).
The `lazy-require' form expands to `define-runtime-module-path-index',
whch doesn't work right at phase levels other than 0. Work around the
problem by generating a submodule to hold the
`define-runtime-module-path-index' form.
This repair fixes `raco exe' on certain uses of `match', which in turn
uses `lazy-require' at compile time.
Also, use `register-external-module' to generate appropriate
dependencies on lazily loaded modules.
The new function allows declaration of a module dependency, as
opposed to a mere file dependency. Misuse of this function opens
the door to cyclic compilation dependencies, so we have to check
for that in `compiler/cm'.
Also, log a warning when it is used in a position where it
doesn't work rght with the executable creator. I didn't make
this case an error, because `define-runtime-path' can still
work in that case as long as no standalone executable needs
to be created.
The JIT was pessimistically using 64-bit jumps for long branches
or any jump between code that is allocated at different times.
Normally, though, code allocation stays within the same 32-bit
range of the heap, so stick to 32-bit jumps until forced by
allocation addresses to use 64-bit jump targets.
is no bluebox information, then we can just bypass updating
it on insertions (especially important when loading a big
file into drracket, as there is a lot of insertion but no
blue boxes (yet))
