In particular, a #f argument can make sense if the length is 0.
Technically, a byte string's byte array is supposed to be nul-terminated,
but many uses of byte strings get away without that terminator. I've
adjust the documentation to note that `bytes-copy` will work with a
non-terminated byte string.
Merge to v6.1.1
The fixup is not allowed to changed the virtual
address of a SHT_PROGBITS section, so a expanded
".dynstr" section might have to be moved to a
virtual address after everything else.
This bug could result in weird "cannot re-define a constant: lifted.0.2"
errors, or probably even worse collsisions of definitions, but I think
only in a namespace created from `module->namespace`.
So far, I haven't been able to create a reasonably small test,
because so many things have to line up in just the right way.
Merge to v6.1.1
If you set the locale to something like "us_EN.1252", then
"1252" was returned as the encoding, but "CP1252" is more likely
to be recognized by `bytes-open-converter`.
Also, document representation information on paths. In particular,
explain that Unix and Mac OS X paths are natively byte strings, while
Windows paths are natively UTF-16 code-unit sequences. The byte-string
representation of a Windows path is a UTF-8-like encoding of the UTF-16
code-unit sequence, which is why it makes no sense to convert it using
the current locale's encoding.
Sounds like a bad name, but I don't have anything better. It's not some
"current-...-print" thing since it works on the sexpr that is intended
to be pretty-printed. So I went with the above.
This uses a technique discovered by Ryan and Dan that
allows the typed class macro to function without invasively
local-expanding the entire class macro (using its private
context information).
Instead, it expands into many helper macros inside the
normal class body and communicates among them using
`syntax-local-value` and compile-time state within the
class body.
This rewrite didn't save that many lines, but it did
reduce the amount of magic that's used.
The `--enable-natipkg` configuration option adds "-natipkg" to the
platform library subpath. The suffix is intended to trigger the
installation of packages that supply native libraries for supported
platforms (where 64-bit Linux is the supported platform, for now, for
main-distribution packages), instead of relying on libraries installed
via the OS's package manager.
The intended client for "-natipkg" is the package-build service, where
installing packages via the OS package manager would require network
access and either trust or constrained installations. The build
machine is intentionally disconnected from the network and can only
access Racket packages, so repackaging native libraries as Racket
packages makes those libraries accessible.
A disadvantage of this approach to installing native libraries is that
it creates work for implementers of packages that access native
libraries. Those implementers will have to supply packages for 64-bit
Linux versions of native libraries to the degree needed to build and
(eventually) test the package. An advantage of the approach is that it
requires no changes to the package system; it will be cheap to replace
this approach if we find a better way to deal with native libraries
and/or OS packages in the package-build service.
