When a client sends a query to a package catalog, it includes a
version number in the query, and a package catalog can customize its
response to the version. That approach allows evoluation of the way
that versions are mapped to results, but it does not allow a
directory-implemented catalog to offer version-specific information.
Allowing both the server and the client to filter on the version is
even more flexible, and in particular allows a directory-implemented
catalog to include version-specific mappings.
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))))
