pixel of space in between lines in DrRacket.
This change is based on Matthew's experience having a look
at the font setup on the three platforms.
He writes:
> * Mac OS X: the convention seems to be to add space between lines.
> TextEdit, for example, looks like DrRacket: the maze has spaces.
>
> (I can't find a font that makes the maze look right, actually, even
> if I adjust the line spacing.)
>
> * Windows: the convention seems to be that space is built into the
> font. DrRacket (and SirMail) draw lines more sparsely than Notepad.
>
> Perhaps consistent with the differing conventions, the height of
> "Courier New" at 11-pixel size is 14 on Windows, 13 on Mac OS X.
>
> * Unix: the convention seems to be to add space. DrRacket looks like
> the default Terminal and Text Editor programs on Ubuntu.
>
> The maze nevertheless looks right everywhere, because the glyphs
> extend an extra pixel above the declared bounding box!
Began scribble docs
Added `compiled-bitmap' and `compiled-bitmap-list', which embed bitmaps
computed at expansion time into compiled files (safe 3D values)
Please merge into release
This removes all the SVG sources, parsing, and marked-layer colorizing, the PNG binaries in the distribution, and the dependence of DrRacket on `slideshow/pict'.
Icons are now produced by drawing on a bitmap-dc%, inferring or building a z map, choosing a material, and sending these to a two-pass ray tracer. This is for the most part hidden behind an API consisting of functions from colors and optional sizes and materials to `bitmap%'s.
Contracts and documentation forthcoming.
for syntax errors (i.e., exn:fail:syntax? exceptions)
Overall, it seems important to (in most cases) not show the stack that
leads to the point where raise-syntax-error is called, so as not to
confuse users who might think that that stack is useful information
in understanding how to fix the syntax error.
I've resisted this technique for avoiding those stacks for a long
time, mostly because common syntax errors in the standard settings
don't usually get the stacktrace button because they usually have
empty stacks (partly thanks to the with-stack-checkpoint dance).
But now that the underlying racket-generated stack is shown too, and
not just the errortrace-generated stack, it is harder to make those go
away. More precisely, DrRacket used to be able to rely on the fact
that files that were compiled to .zo files would not have the
instrumentation in them and thus stackframes from that code would not
show up in the stacktrace. No longer.
So, it seems time to try this alternative.
being edited in DrRacket (via places)
Added an API to let tools have access to that
information (and compute more stuff)
Used that to make an online version of Check Syntax
which led to a separately callable Check Syntax API.
`test-covered' to use just the expression -- looks like there's no
reason to use an additional key.
Also, change its uses to map each syntax to an mcons where its mcar is
used to track coverage. This is done everywhere, since it turns out to
be much faster to insert a `set-mcar!' with a 3d mpair, rather than a
call to a thunk.
Note that it still uses mpairs as a hack. It "works" in the same way
that this simplified example does:
(define-syntax m
(let ([b (mcons 0 0)])
(lambda (stx)
(with-syntax ([b b])
#'(case-lambda [() (mcar b)]
[(x) (set-mcar! b x)])))))
I think that it's fragile, and likely to stop working at some point, but
I don't see anything better for now.
