If "p" is available as a source package, which is typical, then `raco
pkg install --binary p` would strip away the build dependencies of "p",
so that "p" would not install properly.
This commit changes `raco pkg install` to look for an annotation on
the package and complain if the annotation is inconsistent with the
requested conversion: a binary package cannot be used as a source
package or vice versa. (A built package, as provided by a snapshot
site, can be used as any kind of package.)
The `--binary-lib` mode is like `--binary`, but it also omits
documentation to form a "binary library package".
The `--binary-lib` flag and "X-lib" vs. "X-doc" approaches solve the
same problem with different trade-offs:
* When a package is split into "-lib" and "-doc" packages, then it's
easier install non-documentation parts, and it's possible to
install them from source. A programmer has to work more to split
the packages, however, and the library and its implementation must
have separate sources (i.e., no or restricted in-source
documentation).
* When a package is just "X", then users can install a no-source,
no-documentation version by specifying `--binary-lib`, but only
when the package is available from some catalog and provider in
built form (such as from a distribution site or a package-build
service).
In the long run, I think that relying on `--binary-lib will be best
and typical for most packages. The "X-lib" plus "X-doc" approach
that's common in the current distribution's packages, meanwhile, will
likely stick around for basic packages that are commonly useful in
constrained settings (including the setting of a package-build
service).
The `update-implies` declaration is half of `implies` (even though the
name is bigger): update of the package implies an update of another,
but a dependency on the package is no license to access the content
of the other.
This declaration is intended as an alternative to keeping version and
dependency declarations in sync for a pair of packages that are always
updated together, normally because the packages are in the same
repository. For example, a "-test" or "-doc" package might have an
`update-implies` declartion on the corresponding "-lib" package.
Adjust dependency tracking and makefile rules to that when
`--enable-racket=...` is provided to `configure`, intermediate
CGC objects are not compiled.
The new approach uses dependency tracking that was already supported
by xform, previously used only for Windows.
Although newer versions of Visual Studio can open 2010 projects, the
meaning of the project turns out to be: use 2010 tools. So, I've added
a step in the build script to automatically upgrade the solutions and
projects based on the version of Visual Studio that is being run.
Meanwhile, since my previous tests for VS 2012 and VS 2013 were using
VS 2010 projects, I wasn't actually testing with the 2012 and 2013
compilers. Additional changes are needed to make those work, notably a
fresh implementation of setjmp() and longjmp() for Win64.
This was all very painful, but the projects are now in much better
shape, so maybe it won't be so bad from here.
The manifest was intended to enable XP-style controls, but at this
point it doesn't seem to do anything except interefere with some
variants of the build tools.
This new default for Unix and Mac OS X trades performance for
portability (hopefully), but for most users the switch affects only
for the build process, where `racketcgc` is used to build `racket`.
To continue using Boehm GC, configure with `--disable-sgc`.
For now, Boehm GC continues to be the default for Windows.
Allocation of executable memory is intended to make SELinux
happier by mmapping with PROT_EXEC instead of using mprotect()
to allow execution after the fact.
Performance improvements bring SGC within 30% of the Boehm GC on
`racketcgc -cl racket`, which makes SGC an even more plausible
substitute.
When a module is loaded with submodules intact, it should not be
cached and used for a later load that is intended to obtain the
module without submodules. Avoid mismatches by constraining the
cache to modules without submodules.
Error reports used the "source" field of a module, which
doesn't have submodule information, or the "name" field of
a module, which might not match an actual filename (".ss"
vs. ".rkt"). Create the right combination.
Adjust the compiler pass to insert checks for #<unsafe-undefined>.
The chanegs amount to throwing out the old attempt to follow the
implementation sketched in "Fixing Letrec", and instead use a
simpler abstract interpretation.
Bindings in `let` and `let*` need to be tracked much the same
way as for `letrec`, so that
(letrec ([b (let ([d (lambda () c)])
(d))]
[c 1])
b)
raises an exception.
A thread can be swapped out while it's in transition between a
mandling of the mark-stack position and recovering from C-stack
overflow. Fix up that case.
Previoulsy, `expand` mode explicitly disallowed cross-phase declaration
in commit 2e652fc2b3. I'm not sure why, and that commit has no test
case that fails when the restriction is removed, so my best guess is
that it was a debugging strategy that I forgot to undo.
The mz-gdbinit script (generated by mk-gdbinit.rkt) gives the type when using
pso, even when the default template did not include the type.
It defaults to printing out only the name of the type without additional
information.
Use call-as-atomic that can handle exceptions instead of dynamic-winding
start-atomic and end-atomic. Exceptions can be found in the functions's
result wrapper such as:
(define-lib find-some-object
(_fun (name : _string/utf-8)
(object : (_ptr o _some-object-pointer))
--> (result : _int)
--> (begin
(when (negative? result)
(error 'find-some-object "unknown name"))
object))
#:wrap (allocator free-some-object))
Signed-off-by: Jan Dvořák <mordae@anilinux.org>
Allows conversion of negative "seconds" to reach dates before
1970, and fixes year-varying DST tracking for versions of
Windows that know about those details.
As far as I can tell, we have to compute ourselves whether a
date is in daylight-saving time based on specifications of
when daylight and standard times start. That part seems tricky
and could use extra review.
Problem, example, and solution from Sam; see the dev mailing-list post
on 24-JUL-2014.
When a chaperoned accessor, mutator, or property accessor is used to
chaperone a struct, the chaproning procedure must not be able to
see things that the chaproned accessor, mutator, or property accessor
would not allow.
required that the identifier wrapped by `#%top` not have a local
binding. Change the documentation to match the implementation in that
way. (Since local binding in an identifier's lexical information
contributes to its identity as a top-level binding, that specification
of `#%top` would make sense everywhere, but I've left the top level
alone for backward compatibility.)
Also, change `local-expand` to never introduct `#%top`
wrappers. That's a little more consistent with what `#%top` has
evolved to mean, and it specifically works better with
`local-expand/capture-lifts`.
Closes PR 14635 and PR 14654
