I belive this should only be noticeable at the human timescale level
when the tabs have been switched to already and, in that case, seems
to go from 3-400 msec to 50-60 msec on my machine
Essentially all of that time is in redrawing the buffer, so that 50-60
msec is proportional to the height of the DrRacket window, roughly.
(The commit just makes drracket do a single redraw instead of about 4
or so of them per switch ...)
With either
configure --enable-pkgscope=installation
or
raco pkg config -i --set default-scope installation
the default scope of `raco pkg' actions can be changed from
user-specific to installation-wide.
We considered trying to guess when someone building Racket would prefer
installation-wide package scope by default. In particular, someone
building from source for in-place use seems likely to want
installation-wide scope by default. Then again, we don't want to
discourage in-place builds for Unix installations that are intended
for multiple users. So, no guessing for now.
Also, add a `--scope' argument to `raco pkg' commands, which is more in
line with other options, but keep `-i', etc., as shorthands.
The intent is that the configuration module can be rewritten without
recompiling code that uses it, so don't let the compiler inline
configuration values.
The problems were with
* `sqrt' and `expt' on single-flonum complex numbers
* `asin' and `acos' on single-flonum arguments and complex results
* `atan' on mixtures of single-flonum and exact arguments
* `gcd' on mixtures of single-flonum and flonum arguments
guard more of the filesystem manipulations with
handlers and log errors instead of letting them
be raised and show up as internal errors
related to PR 13403
teachpack menu.
Instead DrRacket explicitly changes the menu items when
the language changes or when a teachpack is added/removed
Also, Rackety.
Closes PR 13395
* At least stubbed out all (or almost all) `math/matrix' exports; many
have complete documentation (e.g. types, predicates, accessors,
constructors, for loops, conversion, much of "Comparing Matrices")
* Moved `matrix-zero?' and fixed to use (matrix-error-norm) as its norm
* Added `matrix-basis-cos-angle' (currently a stub; should return smallest
singular value of a certain matrix multiplication)
There appears to be no way to make `on-demand' work right for the
Unity window manager's global menu bar, since there's no notificiation
when the menu bar is clicked. We approximate the correct behavior
by calling `on-demand' when a containing frame loses the keyboard
focus, which might be because the menu bar was clicked; that may be
too late (because the menu has already been shown), but it should
work most of the time.
Closes PR 13347.
Relevant to PR 13395, but DrRacket will have to change to work
around the remaining limitations of `on-demand'.
This will make switching back and forth between 5.1.3 and the latest
not lose the frame size and position preferences (since the format
of the data is different now that the current release remembers
the position on a per-monitor-configuration basis)
* Gram-Schmidt using vector type
* QR decomposition
* Operator 1-norm and maximum norm; stub for 2-norm and angle between
subspaces (`matrix-basis-angle')
* `matrix-absolute-error' and `matrix-relative-error'; also predicates
based on them, such as `matrix-identity?'
* Lots of shuffling code about
* Types that can have contracts, and an exhaustive test to make sure
every value exported by `math/matrix' has a contract when used in
untyped code
* Some more tests (still needs some)
The synchronization result of a log receiver is now a vector of four
values, instead of three, where the last one reports the name.
Also, an optional argument to `make-logger' provides a notification
callback for each event sent to the logger.
These changes enable more control over loggers and events. Suppose
that you have processes A and B, and you want all log events of A
to be visible to B, but not vice-versa. Furthermore, you want the
log events to appear at B in the right order: if A logs an event
before B, then A's event should arrive at a log receiver's before
B's. Now that a log receiver gets the name associated with the
original event, and now that the name can be re-sent in a
`log-receiver', it's possible to give A and B separate loggers and
send all of the events from A's logger to B's logger. Furthermore,
you can use the notification callback so that when an event is logged
in B, you can make sure that all available events from from A's
logger have been transferred to B's logger.
