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.
and change the tests so they all run with port line
counting enabled (or else the unicode test fails)
adjust module-lexer.rkt tests so they can run in either
port-counting mode or not (but currently run them all in
port-counting mode because scheme-lexer doesn't work without it)
also make a first stab at what needs to change in the module
lexer to make it work in non port line-counting mode
Applies in the case of simple ports without line counting, etc.
Also, `read-line' keeps track of whether all bytes are ASCII
(which is easy) to shortcut general UTF-8 decoding.
It now creates an inspector based on the original code inspector instead
of the (implicit) wrong default used by `make-inspector'. Change
`sandbox-make-inspector' too, to make it explicit.
* The installer is a command-line argument.
* Make it work in xterm too, by unsetting TERM.
* Works with version-less directories, from release installers.
(by expanding into a call to a 30 or so line procedure, instead of putting
that code directly into the result of the macro).
This produces about a 6x speedup on this reduction-relation
(reduction-relation L (--> 0 1) (--> 1 2) ... (--> 99 100))
where L is
(define-language L)
The time it takes to run "racket r6rs.rkt" in the shell from the
directory collects/redex/examples/r6rs speeds up by about 10% (15%
with errortrace enabled), in the case where all .zo files are built,
except the ones in the r6rs directory. (Also worth noting that "racket
-l redex" takes more than 50% of that time.) And the change has no
noticeable effect on the time it takes to run r6rs-test.rkt.
