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
This library is used by Redex, which wants a `syntax'-like template
language, but for datum values instead of syntax objects. Using
`datum-case' and `datum' generates much less code. Redex uses
only a small part of the general functionality, so adding
`syntax/datum' could be overkill. It's implemented by generalizing
the `syntax-case' and `syntax' pattern matching and template
constructing code, though; it's not a lot of extra code, and it's
easiest to generalize completely. We may find other uses for
datum templates, too.
original commit: 25dd8727cb8aca54dc7c5cbf1814f2049234ad1d
The `date*' structure type is an extension of `date' with
`nanosecond' and `time-zone-name' fields.
The `seconds->date' function now accepts a real and returns a
`date*'. The fractional part of its argument goes into the
`nanosecond' field.
original commit: ac8990d5195312fa7c71966bdfaa925905902ca8
Macros and other tools that need syntax privilege used
`(current-code-inspector)' at the module top-level to try to
capture the right code inspector at load time. It's more
consistent to instead use the enclosing module's declaration-time
inspector, and `var-ref->mod-decl-insp' provides that. The
new function works only on references to anonymous variables,
which limits access to the inspector.
The real function name is longer, of course.
original commit: 0197902309c5400d463393829a88282c627dafd2
This takes the advice from
http://files.stairways.com/other/ftp-list-specs-info.txt
further: search for the date by an explicit occurrence of a known month
name. This means that we won't see files with bad names (they'd be
filtered out of the result), but the filtered out entries are ones that
would not be usable with `ftp-make-file-seconds'.
When the month is found, and the entry is a file, look for a number
preceding the month, and if found, return it as the file size string.
This is a minor change in the API. (But it's probably better to either
revise it further, or eventually make it irrelevant by exposing the
interesting functionality via `net/url'.)
original commit: 6a1336e75edff75b7fc8a22a31d776acadc536eb
This function was using 2002 when there's no year... Updated it to use
the last occurrence of the guessed date, as described at
http://files.stairways.com/other/ftp-list-specs-info.txt
This function still looks pretty bogus -- the RFC does *not* say
anything about the format of response to `LIST', so it's whatever
semi-random thing the server does. (The above link looks like an
attempt to fix it, but I didn't see anything more official than that.)
From some looking around, it looks like ftp clients just try a bunch of
patterns against the text. Add also warnings in the documentation about
this.
original commit: 234015b34d43a602dfcabe9365de9027531c2f9f
RFC 2640 specifies that all transport strings are assumed UTF-8 if they
can be parsed as such. To make this complete it should really send a
FEAT and check that the result has "UTF8", but it's kind of redundant
since there's not much else to do if it isn't.
Also, switch to a more correct line endings of CRLF when sending
messages to the server.
original commit: ba48669ead349f3b9454ec12014f7e73d13c49c3
