A package's "info.rkt" file should define `collection' as a
string to name a single-collection package's collection, or as
the symbol 'multi to declare the package as multi-collection.
If `collection' is 'same-as-pkg, then the package name is used
as the collection name.
The default for `collection' is 'multi for now, but the intent
is to change the default to 'same-as-pkg after a conversion
period. Also, support for a `single-collection' definition remains
in place, but it wil be removed.
original commit: c738a6aa3eee89a82d577dd35c70eca8ed32f5b4
The "racket" directory contains a pared-back version of the
repository, roughly.
The "pkgs" directory everything else in the repository, but
organized into packages.
original commit: b2ebb0a28bf8136e75cd98316c22fe54c30eacb2
Adds `--from-dir' and `--from-install' flags to select the interpretation
of the argument as a directory or as the name of an installed package.
Relevant to PR 13669
Adds `--as-is' (the default), `--source', and `--binary' flags to
select a pruning mode.
The `raco setup' tool recognizes a `rendered-scribblings' specification
in "info.rkt" to trigger moving rendered documentation into place,
registering its tags in the cross-reference database, and fixing up
references to "local-redirect.js"; the presence of a "synced.rktd"
indicates when those fixups have been performed (since, if the package
is installed in a user-specific scope, the documentation doesn't actually
move anywhere). Finally, "out<n>.sxref" needs to report paths relative to
the documentation's directory, and then the relative-directory references
need to be suitably resolved at derserialization; some support for such
relative paths was in place, but it wasn't quite general enough before.
original commit: 198a65a5fc79649ec167d2407c35815768a119ba
The libraries moved were:
- mzlib/control => racket/control
- mzlib/date => racket/date
- mzlib/deflate => file/gzip
- mzlib/inflate => file/gunzip
- mzlib/port => racket/port
- mzlib/process => racket/system
- mzlib/runtime-path => racket/runtime-path
- mzlib/shared => racket/shared
- mzlib/unit => racket/unit
- mzlib/unit-exptime => racket/unit-exptime
- mzlib/zip => file/zip
The old modules in mzlib are now pointers to the
new modules. These are all modules that were already
redirected in the documentation.
original commit: 403aaac7d4c32132223f06e059df439cceda7a2e
See PR 12860; some of problem related to the PR were "fixed" by
adjusting the guarantees that are specified in the documentation.
Another problem was that non-consecutive bytes could be returned.
original commit: c11527494ed3a08d1ea6caf8e7ec6661f2505ef7
As the documentation says, it's supposed to be ok to use the
same evt multiple times or in multiple threads, but an internal
buffer was allocated incorrectly, so that multiple/concurrent
uses could go wrong.
Closes PR 12860
original commit: d253b89ba87b4bb295fd652708642046f4b90676
Add extra intitial-message lines, use "..." on a field name
to indicate that it could reasonably be hidden by default,
and refine some existing messages.
original commit: 1dc0072d036892e1fbc39891a8c3aaeadd451f80
Added alises for call-with-continuation-prompt,
abort-current-continuation, and call-with-composable-continuation.
Also allow % and fcontrol to take an optional prompt tag argument.
original commit: 5d232f374884f31e0306d99b7b103da1c0381630
Add `raise-argument-error', `raise-result-error', `raise-arguments-error',
and `raise-range-error'.
The old convention was designed for reporting on a single (sometimes very
long line). The new convention is
<name>: <short message>
<field>: <detail>
...
If <detail> is long or itself spans multiple lines, then it may
also use the form
<field>:
<detail>
where each line of <detail> is indented by 3 spaces.
Backtrace information is shown as a multi-line "context" field.
original commit: 9e7548de615610a5be2adb33c4cf6ee10f9e7589
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).
original commit: 084278fabcb3416250d7155faef674a31dac60b6
There is a big comment in thread.rkt that explains the problem and the
"fix". I think something better could and should be done, but I don't
know what it is.
original commit: 022ce2d8d7de60d63d21eb67119466283d9e8be3
* Move the `X-Mailer' header to the top, so that the interesting headers
are all together at the bottom (the top gets littered by server
headers anyway).
* Use `subprocess' directly (`process*' wasn't really doing anything
more than that).
* Allow the sender to be `#f', leaving the header out. This makes all
sendmails that I've used use the username that is running the process.
* Just search for a sendmail program: don't barf on windows, so it can
be used in case there is a sendmail.exe executable there.
* Remove `no-mail-recipients' to make it in-line with other racket code
that doesn't raise super-specific exceptions.
* Use port counting instead of doing the counts manually, much simpler
code.
original commit: f9d07d84009e69a0202390fd828c00d330c19611
