The prohbition against `handle-evt' on `handle-evt' is as
document and as originally intended. I'm not sure why it
was allowed.
Existing programs that use `handle-evt' incorrectly
can break. I found and fixed one incorrect use and one
questionable use in the Racket tree (which is a small
minority of the uses of `handle-evt' in the tree).
Extend `define-cstruct' to support #:property specs, which causes
the constructor and C->Racket coercsions to wrap the pointer in
a structure instance with the specified properties. Of course,
the wrapper structure has a `prop:cpointer' property so that the
wrapper can be used transparently as a C pointer.
Add missing tests and documentation for the id`->list', `list->'id,
id`->list*', and `list*->'id bindings created by `define-cstruct'.
When an eventspace is created, its thread implicitly calls
`yield'. It now effectively loops with `yield' and while
catching continuation aborts.
Closes PR 12566
This addition triggered several other changes:
* -k for a Mac OS X embedding is now relative to the __PLTSCHEME
segment (which means that executables won't break if you strip
them, for example)
* the command-line no longer has a limited size for Mac OS X
launchers and embedding executables
* Mac OS X GUI and Windows launchers record the creation-time
collection path, unless they are created as "relative" launchers
In particular, allow a pair of a relative-to directory and a base
directory. Paths that syntactically extend the base directory are
recorded as relative to the relative-to directory (which must
syntactically extend the base directory).
The compilation manager now sets the parameter to a pair with
the base directory as the main collection directory, if the source
file's path extends that directory's path.
This generalization solves problems created by cross-module inlining,
where the source location of a procedure in bytecode can now be in a
different file than the enclosing module's file.
Also add a test that checks whether the build directory shows up
in any ".zo", ".dep", or documentation ".html" files.
Closes PR 12549
To get the expected contents of the various environment variables, I
used a similar approach to what the build does in `grab_batch_vars':
* Start a cmd.exe shell (not a real shell)
* Dump the env into a buffer
* Run "... Studio/VC/vcvarsall.bat" (modifies envvars, which is why cmd
is needed)
* Dump new env into a new buffer
* Sort both buffers and compare
Hopefully it still works also on Matthew's setup.
Two other small things:
* Use ".obj" suffix on windows to avoid warning.
* Catch error when trying to delete the .so file, since on the x86_64
machine it throws an error. (I'm not sure how it *doesn't* do that
with the i386 machine.)
