These terms are now documented with define-generics rather than gen:set, and the
terms are "implemented generic method" and "supported generic method" rather
than the over-general "implements" and "supports".
The exn:fail:support exception is used to signal "unsupported" values for
generic methods, e.g. a vector as argument to dict-remove. Right interface,
just the wrong kind of instance. The exception type helps define the notion of
a "supported" method, since a method might have a fallback implementation yet
some values are not considered "supported".
- classify methods into 3 categories:
- no fallbacks
- fallbacks that require an "implementation" of another method,
ie not another fallback
- fallbacks that require "support" of another method
--- can be another fallback
that are in the same directory as the image teachpack (for
htdp and htdp/2e)
closes PR 13967
This isn't the best solution: it would be better if I could
get the directory containing any collection whose name is
teachpack/htdp, but that doesn't seem easy with the current
set of functions
also, bring down below 102 columns
The only error that I see now is due to "collects" which doesn't exist.
I've left it in since it looks like it was added explicitly for some
reason in 5504627.
They need to be encoded in the same way that strings are
encoded. (Report and fixed by Phil Roberts.)
Also added a FIXME about leftover occurrences of \U in the output.
Closes PR 13966.
but this also means that multi-column cells can
refer to variables in the column header (ditto
for multi-row cells)
the code duplication can be fixed with a little
more smarts at the match level, I believe
(see comment in source)
Loading "info.rkt" files always from source turns out to be
expensive (adding 1 second or so on my machine to the startup
time for `raco setup'). Change bootstrap mode to try the compiled
form and fall back to source if its doesn't work.
Separate state and functions, and convert a key loop to functional
style. As it turns out, this has no significant effect on performance,
but it looks a lot better to me.
Make the stack-safety margin twice as big for 64-bit platforms
as 32-bit platforms. That was already done for Windows, but it's
also needed for Mac OS X. Also, double-check that there's a
good amount of space on the stack before calling a foreign
function.
There was an off-by-one error in trimming overflow
records in a captured continuation.
I provoked the crash by running the program below on Mac OS X;
resizing the frame caused a crash. It has something to do with the
`try-atomic' implementation, I think. I wasn't able to make a test
case in a half-hour of trying, however, and I'm giving up for now.
(define f (new frame% [label "deep"]))
(define b (new button%
[parent f]
[label "0"]))
(send f show #t)
(let loop ([n 0] [m 0])
(if (= n 10000)
(begin
(send b set-label (format "~a" m))
(for ([i 10]) (yield))
(loop 0 (add1 m)))
(cons 1 (loop (add1 n) m))))
Bootstrap mode disables the use of a compiled form of "info.rkt",
in case the compiled form is broken. It also attaches `info'-language
modules from the `setup/getinfo' namespace to the "info.rkt"-loading
namespace.
Formerly, `raco setup' relied on capturing the bytecode-compilation
bootstrap context used for `raco setup' itself when loading info
files. But when `raco pkg install' used `raco setup', it didn't have
the same bootstrapping context in place, so it could get confused
(e.g., if you unlink a package from one Racket version and install it
as a link in a different Racket version). Now, both `raco setup' and
`raco pkg' use `#:bootstrap?' mode for `get-info/full'.
