The types are tweaked to match the contracts and to support passing a
list of headers to the connect procedure.
The FIXME for polymorphism has also been removed as it is now
parameterized to support "...The result of the handle procedure is the
result of call/input-url..."
This avoids mysterious errors later in the build process related to
TR and static-contracts. I don't see how the pattern-expander code
could possibly cause the errors that occur, but this commit fixes them.
Similar to the server-side problem, but on the client side. In a
game where the server drives the clients with frequent messages
through `on-tick`, per-message growth in the continuation can
matter a lot.
DrRacket's interactions window tried to treat numpad Enter the same
as ctl-Return: send input to the reader, even if an S-expression is
incomplete. Since numpad Enter events were not reported as
'numpad-enter, however, the special treatment didn't take effect.
Meanwhile, it appears that some keyboard configurations report a
numpad Enter event when NumLock is on and the regular Enter key
is pressed, and that's probably not what a user wants. And
numpad Enter has never been reported differently from regular
Enter on Windows.
So, it's simpler and more consistent to just treat numpad Enter
and regular Enter the same.
On Unix and Mac OS X, the key has long been reported as #\u3,
even though the documentation says 'numpad-enter.
A more compatible change would be to adjust the documentation and
also change DrRacket and the framework to recognize #\u3 instead
of 'numpad-enter. But there doesn't seem to be a good reason to
treat #\u3 as "numpad Enter" --- particularly as opposed to treating
it as "Ctl-C" --- other than ancient Mac history.
On Windows, numpad Enter continues to be reported as #\return,
since Windows event handling doesn't naturally or easily distinguish
the two keys.
On Windows, a "soft link" or "junction" is different from a
"symbolic link". The current Windows documentation is
incomplete in that it describes the behavior of GetFileAttributesEx
for a symbolic link, but not for a junction, and I guessed wrong.
For consistency, junctions need to be treated like symbolic links.
