When a test run by `--place` mode doesn't increment any rackunit
counts, treat the count as 0 instead of 1 for consistency with
`--direct` and `--process` modes.
Closes#1358
The current output for `--help` is quite messy and hard to
navigate.
I added some indentation and spacing to make the document
easier to read. For example,
File and expression options:
-e <exprs>, --eval <exprs>
Evaluate <exprs>, print results
-f <file>, --load <file>
Like -e '(load "<file>")' without printing
The new layout is longer, but at least it is readable. It
might be better if we could move all the options to a man
page and only select a few common ones to put in `--help`.
Really, `raco demod` is adapted here to work with any linklet-based VM
by compiling modules to machine-independent form, which is essentially
a wrapper around linklet S-expressions. The BC-specific implementation
remains in place, and it has the advantage of being able to work with
existing module compilations, while the implementation based on
machine-independent form must recompile all modules before attempting
to combine them (but that recompilation is easily cached).
Use `--work <dir>` to use `<dir>` as a cache for multiple
demodularizations.
Getting `raco demod` to work involved several incidental improvements:
* make `racket/linklet` work with machine-independent forms;
* add `linklet-body-reserved-symbol?`;
* fix schemify for linklets that have unexported definitions (which
the expander never generates, but the demodularizer does);
* add `current-multi-compile-any` to expose CM's multi-target
compilation mode programmatically; and
* repair a bug in CS JIT mode.
The demodularizer could be a lot smarter to prune demodularized code
before sending it off to the compiler. Of course, the compiler should
be able to figure out improvements itself, but sending a smaller chunk
of code to the compiler can avoid the hybrid interpreter--compiler
mode that is used for large linklets and that prevents optimizers like
cp0 from doing much to prune definitions.
The demodularizer has a lot in common with the expander's flattener
that is used for bootstrapping, and a smarter demodularizer would have
even more in common. It would be nice to have one implementation
instead of two.
New `#%app/no-return` and `#%app/value` functions at the Chez Scheme
level allow schemify to communicate that function calls will not
return or will return a single value. The schmeify pass may have this
information because a Racket-level primitive is declared that way
(such as `error` or `raise-argument-error` for no-return, or most
functions for single-valued) or because single-valuedness is inferred.
There's currently no inference for no-return functions, because those
are relatively rare. An `#%app/value` is used by schemify only for
imported, non-inlined functions, since cp0 can already deal with local
functions and primitives.
There's a start here at adapting the "optimize.rktl" test suite for CS
--- and that effort triggered these improvements plus some other
low-hanging fruit. But a lot more is needed to adapt "optimize.rktl"
and to make some additional optimizations happen.
Use data instead of code to shrink ".zo" sizes by 10-30%.
When Racket code contains a literal that cannot be serialized directly
by Chez Scheme (such as a keyword or an immutable string that should
be datum-interned), the old approach was to generate Scheme code to
construct the literal through a lifted `let` binding. To handle paths
associated with procedures, however, Chez Scheme's `fasl-write` had
been extended to allow arbitrary values to be intercepted during fasl
and passed back in to `fasl-read`. Using that strategy for all Racket
literals simplifies the implementation and reduces compiled code. It
also makes closures smaller, while increases the number of
relocations. DrRacket's foorprint shrinks by about 1%, but the main
affect is on disk space for a Racket installation.
Show the machine code that constructs lifted constants for a linket.
Also, add a `--partial-fasl` option that shows fasl content in a rawer
form, which is useful for checking how content is presented and that
nothing is getting lost in other reconstructed views.
This fixes at least one "potential" bug in the file
`collects/pkg/private/create.rkt`, where `else` in the
`cond` is bound to `else` from `match` instead of `racket/base`.
(though it turns out that the format will always be
truthy, making the program happen to be correct.)
Change the ".zo" format to convert a linklet bundle hash table to a
list, which avoids probblems with stencil-vector encodings and cross
cimpilation between 32-bit and 64-bit platforms. Avoiding records,
stencil values, and hash code should make the fasled form simpler.
Update the Guide's performance section with current information for
Racket CS, and also document the Racket CS compilation mode and
inspection environment variables. Make a couple of environment
variables work more consistently: PLTDISABLEGC for CS and PLT_ZO_PATH
for BC.
The new flags can be used to make an embedded module's name
predicatable, which is useful for making a deserialization format
stable (i.e., `serializable-struct` creates a serializer that uses the
embedded module name). This functionality was already available from
`create-embedding-executable`, but there was no way to reach it via
`raco exe`.
Move different handling of serialized syntax data to the schemify
layer instead of te expander, so that the result of compiling in
machine-independent form is the same for traditional Racket and Racket
CS.
Although `raco dec` cannot yet usefully decompile Racket CS compiled
code, the underlying `zo-parse` and `zo-marshal` functions can now at
least read and re-write that format by just keeping the bytes for the
CS-specific part, and it can also now rouind-trip the machine- and
VM-independent format.
Lots of plumbling was in place to preserve the source name (instead of
the symbol generated to avoid collisions for macro-introduced
definitions), but some small pieces were missing.
Closes#2288
When a stand-alone executable created by `raco exe` needs to load
modules that start with a `#lang` line, there have been various
obstacles to adding the right run-time support via `++lib`. The
`++lang` flag addresses those problems and makes it easy to indicate
that enough should be embedded to support loading modules with a
specified language.
There are problems in the way that various handlers interact for the
"lang/reader.rkt" versus `(submod "." reader)` search path that
converts a language name to a reader. To accomodate the search in a
standalone executable (that does not provide access to collections in
general), the module name resolver must refrain from raising an
exception for a non-existent submodule path that refers to a
non-existent collection.
Creating an executable with embedded DLLs means that the executable
can be truly stand-alone, instead of needing to be kept with its
DLLs in a relative subdirectory.
DLL embedding works by bypassing the OS's LoadLibrary and
GetProcAddress functions, and instead maps the DLL into memory
and performs relocations explicitly. Joachim Bauch's MemoryModule
(Mozilla license) implements those steps.
This commit merges changes that were developed in the "racket7" repo.
See that repo (which is no longer modified) for a more fine-grained
change history.
The commit includes experimental support for running Racket on Chez
Scheme, but that "CS" variant is not built by default.
Although "macOS" is the correct name for Apple's current desktop OS,
we've decided to go with "Mac OS" to cover all of Apple's Unix-like
desktop OS versions. The label "Mac OS" is more readable, clear in
context (i.e., unlikely to be confused with the Mac OSes that
proceeded Mac OS X), and as likely to match Apple's future OS names
as anything.
`cext-lib` contains much of the contents of `dynext`, which
is no longer very widely used.
Also moved the implementation of the `mzc` executable
to a more appropriate package.
Also, used `lazy-require` consistently for dynamically
loading implementations.
