These result from something like
@racket[(x y)]
being treated by Scribble as multiple RktXXX items rather than one. As
a result the Markdown emitted was:
`(``x`` ``y``)`
But obviously instead we want:
`(x y)`
Kludgosity alert: Although it would probably be more-correct to
consolidate the RktXXX items at the Scribble structure level, I don't
easily see how. `@racket` is baking in the concept of Racket
lexing (classifying text as various kinds of Racket elements). This is
handy when the render will be HTML or Latek, and is benignly N/A when
it will be plain text. But it's a bit square-peg/round-hole when the
render will be Markdown. Rather than attempt to "un-lex" the Scribble
structures (I'm having trouble seeing how), I'm handling it
"after-the-fact" -- adjusting the generated Markdown text.
If anyone thinks the preceding is an elaborate rationalization for an
ugly kludge, I wouldn't argue, but I would need some help
understanding the preferable way to go about it.
Unlike plain `racketblock`, `examples` and `interaction` are
"nested". As a result we emitted bad Markdown like:
```racket
Examples:
```racket
some-code
```
```
Markdown code blocks can't nest, so this needs to be:
```racket
Examples:
some-code
```
Also: Updated the unit test with examples of `examples` and
`interaction`.
This simplifies the implementation, and also generalizes it so that it finds
documentation from installed packages, linked collections, and other sources.
Because of a limitation in our GC tech (and because I have not
sorted out how to program around it (which should be possible))
when the "is it safe to rename this variable" check may silently
just say "yes" when it really doesn't know the correct answer.
It turns out that this was happening on every attempt to rename
after the first one (in a given online check syntax run) due to
a bug, now fixed in this commit (the "loop" didn't actually loop...)
Also, moved the creation of the thread to its own function to
make the things it closes over more syntactically apparent.
Noted by ozzloy on IRC. The search page appears to fail when
searching for the term 'string<?'; in truth, the search succeeds, but
the search link-printing code doesn't escape the '<?' part of the
identifier.
Allow a thread to be GCed when it is blocked on a place
channel for reading and the place channel's write end
is inaccessible.
GC is limited to threads that do not participate in cycles
of such threads, where the otherwise unerachable threads
are blocked on place channels that are reachable among the
set of threads. In other words, the GC finds the greatest
fix point (as measured by the threads to retain) instead of
least fix point --- which isn't what you want, but finding
the least fix point seems to require significant extra GC
machinery across places.
This improvement was intended to solve the same problem as
commit 7b0608c, but that case seems to run into the limitation
on cycles.
A tail call with certain kinds of primitives would fail to
clear local bindings in a detectable way. For example, a
tail call to `sync' that blocks could retain references
to unreachable data in the context of the `sync' call.
Primitives that can cause problems in the run-time system
are already identified as "imemdiate" primitives. The
safe-for-space pass now inserts clearing actions before a tail
call, unless the call it to a known immediate primitive or a
Racket-implemented function.
Clearing operations are now omitted before non-tail calls
to immediate operations like structure predicates.
The newly added clearing operations could affect performance,
but they probably won't, since the clear operations are still
avoided in tail-call cases that are otherwise fast. The newly
omitted clearing operations may improve performance.
The shortcut could be triggered in a bad case (first
argument as `#f' in non-timeout mode) and returned the
wrong result (void instead of the semaphore).
It's possible to go from a state where one scroll bar is needed
(vertical or horizontal) to a state where each scrollbar is
needed iff the other scrollbar is needed. In that case, the
auto-scrollbar algorithm couldn't find either fixpoint and
would loop forever.
- handle parameters correctly when simplifying disequations
- rework term generation/disequation checking for parameters
- fix define-extended-metafunction w/r/t the above
Enable extflonums in a MSVC build by relying on a MinGW-built DLL,
"longdouble.dll". The DLL is loaded on startup. If the DLL isn't
available, then `extflonum-available?' reports #f.
Instead of setting the floating-point mode globally to extended
precision, the mode is changed only just before (and restored right
after) extflonum arithmetic operations.
when it compiles required files
Now that this is fixed, the compilation manager will be (once again)
active when doing online compilation, so if the "Populate compiled
directories" checkbox is check (which it is by default) in the details
section of the language dialog, then online compilation will, as it
compiles your file, write out .zo files that will also be used by the
Run button.
The actual fix to this bug is the change in expanding-place.rkt (and
all it really does is move the setting of the
current-load/use-compiled and current-load parameters earlier so that
CM sees only the modified parameter settings and so doesn't give up on
compilation.
The rest of the changes are a test case (and change to drracket to
support the test case)
