summaryrefslogtreecommitdiff
path: root/src/library/scala/collection/parallel/Splitter.scala
Commit message (Collapse)AuthorAgeFilesLines
* Absolutized paths involving the scala package.Paul Phillips2013-05-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* More explicit empty paren lists in method calls.Jason Zaugg2013-02-241-1/+1
|
* Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013Heather Miller2012-11-021-1/+1
|
* Reducing the sbt launcher footprint by eliminat...Paul Phillips2011-05-011-7/+1
| | | | | | | | | | | | Reducing the sbt launcher footprint by eliminating val references which go through the scala package object, since they lead to otherwise unnecessary classes becoming required at startup. Mostly this means library files with constructors like "Iterator.empty" or "Stream.continually" receive a direct import of that companion. The one slightly less than cosmetic change was moving the strange xml value "$scope" back into Predef, because otherwise I have to touch the xml code generation. No review.
* Refactoring the collections api to support diff...Aleksandar Pokopec2011-04-131-51/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Updated docs. No review.Aleksandar Pokopec2011-02-101-22/+31
|
* Refactoring certain tasks to accept empty split...Aleksandar Pokopec2010-10-201-0/+11
| | | | | | Refactoring certain tasks to accept empty splitters. Adding parallel mutable hash maps. No review
* Adding immutable parallel hashsets.Aleksandar Pokopec2010-10-051-0/+9
| | | | | | | | | | Fixing an issue with hashset splitters where the splitting does not work if some elements have already been iterated. Added parallel collections exception handling. Added parallel collections break control. Renaming ParHashTrie -> ParHashMap. The part with immutable.{HashSet, HashMap} - review by rompf
* Renaming files and inserting dummies to please ...Paul Phillips2010-07-011-0/+86
Renaming files and inserting dummies to please ant. Note to committers: whenever there is a source file which does not generate a classfile whose name and path exactly match the name and path of the source file, then ant will recompile the file every time it compiles anything. In this batch there were 7 such files, so any 1-char change meant an 8-file recompile. Someday we'll be rid of ant, but until then... no review.