After some consultation with my class this quarter,
it seems clear that the previous defaults and nearby
variations are completely hopeless for colorblind people
(there are at least 3 in this class). So go with the
defaults used in the HtDP languages, which have been
vetted by saidsame 3 people.
binding site (with a green/yellow bubble) when the mouse moves over
any one of them
This change comes about because of the recent fixes to the
interactivity wrt to the rename menu. Basically, in order to fix the
bug (but still preserve the interactivity optimization), check syntax
changed from sending the information "here is a place to offer a
rename for these identifiers" to "here is a set of identifiers that
are all free-identifier=?" (the difference being that the latter does
not imply you got them all (which enables the optimization) and that
the information is slightly less rename-menu specific (which enables
the change in this commit))
An extflonum is like a flonum, but with 80-bit precision and
not a number in the sense of `number?': only operations such as
`extfl+' work on extflonums, and only on platforms where extflonums
can be implemented by hardware without interefering with flonums
(i.e., on platforms where SSE instructions are used for
double-precision floats).
[Patch provided by Michael Filonenko and revised by Matthew.]
The compiler tracks information about bindings that are known to
hold extflonums, but the JIT does not yet exploit this information
to unbox them (except as intermediate results).
The code used eq? to check to see if a given language was in
an list of allowed-to-create-executables languages. But the
language object was passing thru TR and so eq? didn't hold and
thus the check was buggy.
Before this commit, the files that are loaded during expansion
were discarded when an error during expansion occurs. This commit
saves them: unless the program is something like
(begin-for-syntax (kill-thread (current-thread)))
the handling that deals with that kind of situation (as opposed
to just an exception being raised) doesn't try to save them
Do not merge to 5.3.2: this bug isn't serious and the new code
is not as well tested as the old
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 ...)
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
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)
One drawback to the current situation (after this commit) is that all
log messages are sent into the user's logger, even messages that come
about as part of DrRacket's implementation. It isn't clear how to fix
this without enumerating all of the possible messages to share and
explicitly forwarding them (both of which are suboptimal things).
On the plus side, the GUI now uses the "debug@GC" notation in a text
field, and when the logger pane is not open, there is no extra work
going on. Plus other, minor GUI improvements.
This was there, I believe, to avoid latency when clicking
on the [docs] links in the language dialog. But now that
we're using a database anyways, loading the xrefs is fast.
- use the same font/size as the definitions/interactions window
- add a checkbox to control scrolling behavior and,
- when scrolling, scroll to the begining of the line, not the end
Things should now generally be set up to work better --
for example online check syntax is smarter now about
what happens when switching tabs/frames and this also
makes it easier to add new ways for a window to become
dirty (that is, for it to be known that it needs to
be recompiled)
For example, a new DrRacket window (with a file named tmp.rkt in the
and 356 afterwards. This is under mac os x with, I believe, the
default system font sizes. (The file is important because different
languages can have different buttons in the toolbar and the filename's
length itself can affect the minimum size.)
Mostly this change is the addition of a new kind of panel that
lets its children have multiple fixed sizes (as opposed to
just a single minimum size and (optionally arbitrarily large))
It also adjusts the various toolbar buttons to use this new code.
Also, there's a few tweaks to shrink other things that became the
limiting factor in shrinking the width of the DrRacket window.
Currently, at least for #lang racket programs, the toolbar buttons
along the top of the window are the limiting factor (including the
save button). With a bogus language (ie, #lang rackeeet), the bottom
bar is the limiting factor, since that will have only the Save, Run,
and Stop buttons.
related to PR 13281
