When installing a package "P" and the usual directory already exists
and cannot be deleted, then use the path "P+1", etc., and record the
alternate path in the package database.
A pipe's limit is supposed to apply only to unpeeked bytes, but
there were problems related to triggering further writes after
a peek, and also triggering further reads after a partial
write.
This is useful for telling people how to install a new pkg, from
GitHub or elsewhere: just get the files, and then do
`raco pkg install` in the relevant directory.
Also, both cabal (the Haskell package manager) and npm (the node.js
package manager) behave this way.
To explicitly get the old behavior, specify the sources as
`--pkgs pkg-srcs ...`. This is useful in scripts, when `pkg-srcs`
might be empty.
exports and drracket:tool^ be in sync
This doesn't quite do the whole job
because something seems to get names
confused when structs and signatures
team up. This is a small example that, I
believe, demonstrates the problem:
(require racket/unit)
(struct p:s ())
(define p:struct:s struct:p:s)
(define-signature s1^
((struct s ())))
(define-signature s2^
((open (prefix p: s1^))))
(define-values/invoke-unit
(unit (import s2^) (export))
(import s2^)
(export))
teachpacks that were last selected by the user
This change is related to PR 14089 because that PR
made me realize that a similar problem happens with
this pref file. There is a simple fix, tho: just keep
the preferences for 5.3.6 and earlier using a different
key than the preferences for versions released after 5.3.6
Avoids including the bit thet indicates whether the object
is GCable in the eq hash code (in a configuration where
bits are available in the GC header for hashing).
Closes PR 14059
Symbols in the PR were mapped to coliding hashes in
groups of 4 because the low 2 bits of the `eq?` hash
code were begin dropped to generate an `equal?` hash
code. Those two bits got lost due to a refectoring
a while back that moved the dropping of two useless
bits to a more centralized place, but the 2-bit shift
did not get removed from the `equal` hash code comparision.
The PR's example program will still generate groups of 2
when hashing around 10k symbols (which used to be groups of 8).
That's because there's a bit in the hash-code counter that
turns out to be forced to 1.
