It looks like run-teaching-program hasn't been touched in quite a while.
To begin with, the "rewrite-module" function used to add code to print
out values of non-define exprs, but this is no longer necessary. In fact,
the only thing that it does now is to discard "provide" statements, and
even this may be unnecessary. I rewrote big chunks of this (short) file
to introduce defines, eliminate unnecessary functions, and add stepper-
skip-completely annotations to the requires associated with teachpacks.
Also, it appears that the 'rep' argument to expand-teaching-program
was entirely superfluous; I removed it from the argument list, and also
from the three places in the main tree (deinprogramm, lang, and the stepper)
that call this function.
Let me know of any problems seen with teachpack requires....
* Modernize, improve, reformat, reorganize, etc.
* Use 'null as the default translation for json `null'. Add keyword
`#:null' arguments to control it, and a `json-null' parameter to
change the default. (Note that there is no ambiguity: symbols are
used in hash keys, and JSON restricts them to always be strings, so
`null' can never be a hash key.)
* Properly decode double \u-escape sequences (as UTF-16 surrogate
pairs).
* Add a keyword option to do more string encoding of all non-ASCII
characters.
* Rename `json->jsexpr' (and other way) to `string->jsexpr'. This is
because (a) after using it for a while I still can't remember which
side is which and a `string' in the name makes it clear, (b) it
follows the similar `xexpr' functions.
`port-success-k' is used in a single place, and instead of a simple
`lambda' expression it was used with (and ... (lambda ...)), which lead
to duplication of code. Instead, move the question into the
`regexp-loop' macro. (The compiled zo file is indeed smaller after this
change.)
Although th eoriginal idea was to distinguish "text" paths
from derived filesystem paths, practically everythign that accepts
a module path also accepts a path. Building the generalization into
`module-path?' makes it easier to support `submod' wrappers on paths,
and it seems to fix things rather than break them.
Before this commit, opening collects/drracket/private/unit.rkt required
about 17.5 megabytes of memory and after this commit, it is down to
about 15 megabytes.
The precise measurement I did was to create a frame and a scheme:text%
object in it, record the result of current-memory-use, open the file,
and record current-memory-use again.
For comparison, using a text:standard-style-list% object instead of
the scheme:text% requires only about 4.1 megabytes. One difference
being that there are about 3x more snips (10,204 vs 33,901 (after the
commit)), since we have one snip for each region that has a different
color in the scheme:text version, and the text:standard-style-list has
no colors and thus about two per line (there are 5006 lines in the
file).
