| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some names I missed in 55b609458fd .
How one might know when one is done:
mkdir scratch && cd scratch
mkdir annotation beans collection compat concurrent io \
math parallel ref reflect runtime scala sys testing \
text tools util xml
scalac $(find ../src/library -name '*.scala')
Until recently that would fail with about a billion errors. When it
compiles, that's when you're done. And that's where this commit
takes us, for src/library at least.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move `MurmurHash3` to `util.hashing`.
Make the `class` private and retain a public companion
`object`, and put the `MurmurHash3.Hashing` implementations
for various types in the companion.
Add a method which composes `ByteswapHashing` with some other hashing.
Rename `hashOf` to `hash`.
Fix chi-square test in a test-case.
Review by @jsuereth.
Moved a failing test that seems to use some other library version to pending.
|
| |
|
|
| |
Now that nothing uses it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to make hashcodes faster. Didn't achieve much on that front, so
redirected into structural/consistency issues. The latter was lacking
in terms of how/where "def seq" was defined. The documentation I can
find doesn't give me much hint that the sequential form of my sequential
collection might be a single-use iterator! (As in StringOps, ArrayOps.)
If that's intentional it should be in huge letters. I'm assuming for now
that it wasn't.
Also, there was this:
GenMapLike: def seq: Map[A, B]
GenSetLike: def seq: Set[A]
GenSeqLike: // nothing, returns Traversable
So I added some def seqs where I needed the more specific types for
my hashcode work. Hashcodewise, I broke the MurmurHash3 object into
a reusable class and a collections-specific object, and I deprecated
the methods which took GenTraversableOnce in favor of ones taking
TraversableOnce, because there's no reason the hashcode library should
have to know about things like "make sure to call seq before you
traverse or you'll be sorry." Exclude things by their type and you can
never make a mistake. End transmission.
|
| |
|
|
|
|
| |
Integrates recent speed improvements to algorithm.
Contributed by Ruediger Keller, no review.
|
| |
|
|
|
|
|
| |
Removing the package-private modifiers on Gen*Like traits.
No review.
|
| |
|
|
|
|
| |
Added a bunch of bridges to make ameliorate binary compatibility of new
collections. Review by prokopec. Review by extempore.
|
| |
|
|
|
|
|
| |
Also, added some docs variables to Gen* traits that were missing.
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Doing a little polishing on the parallel collections refactor (which
overall looks like a big improvement.) I went for some simpler wording
and moved a number of scaladoc tags around because the rug had been
pulled out from under their feet.
This leaves a lot undone, but since many of the docs need to be reworded
before they can move from e.g. SeqLike to GenSeqLike, and I'm not well
informed on exactly how these abstractions are being presented, I stayed
in the safe zone. Review by prokopec.
|
|
|
Refactoring the collections api to support differentiation between
referring to a sequential collection and a parallel collection, and to
support referring to both types of collections.
New set of traits Gen* are now superclasses of both their * and Par* subclasses. For example, GenIterable is a superclass of both Iterable and ParIterable. Iterable and ParIterable are not in a subclassing relation. The new class hierarchy is illustrated below (simplified, not all relations and classes are shown):
TraversableOnce --> GenTraversableOnce
^ ^
| |
Traversable --> GenTraversable
^ ^
| |
Iterable --> GenIterable <-- ParIterable
^ ^ ^
| | |
Seq --> GenSeq <-- ParSeq
(the *Like, *View and *ViewLike traits have a similar hierarchy)
General views extract common view functionality from parallel and
sequential collections.
This design also allows for more flexible extensions to the collections
framework. It also allows slowly factoring out common functionality up
into Gen* traits.
From now on, it is possible to write this:
import collection._
val p = parallel.ParSeq(1, 2, 3)
val g: GenSeq[Int] = p // meaning a General Sequence
val s = g.seq // type of s is Seq[Int]
for (elem <- g) {
// do something without guarantees on sequentiality of foreach
// this foreach may be executed in parallel
}
for (elem <- s) {
// do something with a guarantee that foreach is executed in order, sequentially
}
for (elem <- p) {
// do something concurrently, in parallel
}
This also means that some signatures had to be changed. For example,
method `flatMap` now takes `A => GenTraversableOnce[B]`, and `zip` takes
a `GenIterable[B]`.
Also, there are mutable & immutable Gen* trait variants. They have
generic companion functionality.
|
