The switch to rktio swapped the sense of "signal" and "sigset"
incompletely, and "signal" on Solaris is the one that resets
the signal handler to SIG_DFL.
Make `raco setup` propagate the original value of
`use-compiled-file-paths` in case it's reset to avoid loading bytecode
files. Then, `--clean` mode can remove bytecode relevant to that
setting, instead of always clearing "compiled" subdirectories.
There's no external way to initialize `use-compiled-file-paths` right
now, other than forcing it to `null` with the `-c` flag at the
`racket` level, but the current "racket7" implementation uses
different `use-compiled-file-paths` settings for different build
modes, and it seems to make sense in general.
Also, make `--clean` sensitive to `-D` and `-d`, so that it's easy to
clean just bytecode.
The copy was made in c1c427a281 to help get "racket7" started, but
it's no longer needed. Using the copy had an unintended consequence of
duplicating the collection-search cache for phases other than phase 0,
so this change repairs that consequence.
The `racket/private/check` module is dead code in this repo, but
having it simplifies the "racket7" bootstrap when "racket7" goes so
wrong that it can't rebuild itself.
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
