OpenBSD provides pthread_stackseg_np(), which directly reports
the stack-bounds information that Racket needs, so we can use
that instead of the approach used on other Unix variants. The
approach used for other Unix variants seems not to work for OpenBSD
because the stack location at the point that main() is called
is already significantly far from the stack base (on the order
of 100k on a 32-bit system in my test using OpenBSD 5.2).
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.
