To strip a signature, the old implementation effectively guessed
at the padding that was added to the original linkedit segment
to acommodate 16-byte alignment of the signature. The repaired
stripping works out the actual end of the linkedit segment based
on the various load commands that refer to it.
Add guard, if first argument to `find-relative-path` is not a path,
then don't call `path-convention-type` on it.
Thanks to Jack Firth for reporting:
https://github.com/racket/rackunit/pull/46
The cause is any extra space after a terminating semi-colon in a SQL string passed to sqlite3_prepare_v2 procedure in the prepare1* method of `db` Sqlite3 connection% implementation will result in non-false tail and zero prep-status values being returned. The checking code sees the non-false tail value and raises the "multiple statements given" exception.
The easy fix is to trim any trailing whitespace by calling string-trim on the buffer string before its converted to a byte string in the copy-buffer procedure used by sqlite3_prepare_v2 to initialize the sql-buffer.
See Issue #1702
The same problem is encountered when executing a DDL statement such as "Create Table" more than once after the table had already been created by the first execution.
The cause is when sqlite3_prepare_v2 encounters a bad statement, it aborts the preparation, sets prep-status flag to non-zero and also sets tail? to be non-false.
The previous code ignored the prep-status flag and only checked tail? and raises "multiple statements given" exception when tail? is non-false.
The new code takes prep-status into account and extracts the actual Sqlite3 error message by evaluating get-error-message and raising it as an exception.
See Issue #1702
Also, add a script to extract the "rktio.h" header information to an
S-expression form suitable for FFI use, and refine the "rktio.h"
information to improve that output.
Avoid printing `(unquote @d)` or `(unsyntax @d)` as `,@d` or `#,@d`,
which would mean `(unquote-splicing @d)` or `(unsyntax-splicing @d)`
to the reader, by adding an extra space before the `@`.
When a package to be installed has a module that conflicts with an
existing installed module, but the existing module isn't in a package,
then say so explicitly in the error message. Also report the current
collection and links paths.
Error reporting could do even more work to figure out which path is
relevant, but reporting a list of paths is relatively easy. Listing
paths also seems likely to give a user enough hints for this rare
case, especially if the user just needs to be reminded that collection
links exist.
Additionally this adds macros that distinguish between the chaperone redirects of prop-only vector
chaperones, function chaperones, and structure chaperones since each of these may store a vector
in the redirects field.
Auto fields were incorrectly recorded as immutable in a structure type
that is first generated from the prefab struct key instead of
`make-struct-type`.
Thanks to Deren Dohoda for the report.
When `--update-deps` (which is implied by `--all`) was used on
user-scope packages that depend on installation-scope packages, the
installation-scope dependencies were treated as missing, which forced
an update of the user-scope packages. Check both scopes for
dependencies.
Closes#1730
The `file/cache` relies on matching the text of a message, and the
text had changed to have less information on Unix, including whether
the problem was with the source or destination file. Add a notion of
error step to rktio and use it to improve the `copy-file` message.
Report a proper error when path decoding fails, instead of
synthesizing a path hat shouldn't exist. The rktio conversion
made it much easier to report the error at the Racket level
like other filesystem errors.
In the process of extracting minimal Windows path encoding for rktio,
I noticed a decoding issue with a path that ends with an unpaired
high-surrogate value. Add a suitable tests and fix the old decoder
(although it will probably go away).
Closes#1721, which points out that the `for/list` expansion
introduced in commit 5e94a906cd interacts badly with a body
that captures a continuation plus Racket's current implemenation
of continuations.
When Racket one day gets a better implementation of continuations,
this change could be considered again, but the general question is
whether programs can detect or be affected by the size of the
continuation (when the programs don't directly control the
continuation creation --- otherwise continuation marks obviously
expose the size).
Provide a compatibility layer to bridge the old (not completely
documented) `scheme_fd` interface and rktio. The old interface is
used by the Gtk implementation of `racket/gui`, for example.
