summaryrefslogtreecommitdiff
path: root/src/library
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3266 from soc/SI-7546Adriaan Moors2013-12-131-6/+10
|\ | | | | SI-7546 Use likely monotonic clock source for durations
| * SI-7546 Use likely monotonic clock source for durationsSimon Ochsenreither2013-12-131-6/+10
| | | | | | | | | | | | | | | | | | | | System.currentTimeMillis is affected by wall-clock time, which means things can appear to jump back in time. Use System.nanoTime which is more likely¹ to be monotonic instead. ¹ See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458294 "nanoTime affected by system clock change on Linux (RH9) or in general lacks monotonicity".
* | Merge pull request #3233 from scottcarey/SI-8042Adriaan Moors2013-12-131-24/+34
|\ \ | | | | | | Use Serialization Proxy Pattern in List
| * | SI-8042 Use Serialization Proxy Pattern in ListScott Carey2013-12-121-24/+34
| |/ | | | | | | | | | | | | | | | | | | | | Modify List to use the Serialization Proxy Pattern instead of directly mutating its state during deserialization. Use the proxy at the List level for both Nil and :: for simplicity. Change one member variable (hd) to val from var as a result. The other member variable (tl) cannot yet be changed to val because it is mutated by ListBuffer in the library and Types in reflection.
* | Merge pull request #3250 from soc/SI-8059Adriaan Moors2013-12-131-1/+11
|\ \ | | | | | | SI-8059 Override immutable.Queue#{+:,:+} for performance
| * | SI-8059 Override immutable.Queue#{+:,:+} for performanceSimon Ochsenreither2013-12-111-1/+11
| |/ | | | | | | Without those overrides, all elements are unnecessarily copied.
* | Merge commit '9cdbe28' into merge/2.10.x-to-masterJason Zaugg2013-12-111-2/+8
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: build.examples.xml build.xml docs/examples/actors/pingpong.scala docs/examples/fors.scala docs/examples/iterators.scala docs/examples/jolib/Ref.scala docs/examples/jolib/parallelOr.scala docs/examples/monads/callccInterpreter.scala docs/examples/monads/directInterpreter.scala docs/examples/monads/errorInterpreter.scala docs/examples/monads/simpleInterpreter.scala docs/examples/monads/stateInterpreter.scala docs/examples/parsing/ArithmeticParser.scala docs/examples/patterns.scala docs/examples/pilib/elasticBuffer.scala docs/examples/pilib/handover.scala docs/examples/pilib/piNat.scala docs/examples/typeinf.scala src/build/pack.xml
| * SI-7912 Be defensive calling `toString` in `MatchError#getMessage`Jason Zaugg2013-12-101-2/+8
| | | | | | | | | | Otherwise, objects with exception-throwing `toString` lead to a cascading error far removed from the originally failed match.
* | Merge pull request #3226 from ziggystar/patch-1Adriaan Moors2013-12-081-0/+7
|\ \ | | | | | | add method dequeueOption to immutable.Queue
| * | add method dequeueOption to immutable.QueueThomas Geier2013-12-051-0/+7
| | | | | | | | | | | | | | | | | | This allows immutable.Queue to be used conveniently in functional code. Method is in the spirit of `headOption` on seqs or `get` on maps. Also adds a unit test for immutable.Queue.
* | | Merge pull request #3228 from retronym/merge/2.10.x-and-pr-3209-to-masterJason Zaugg2013-12-061-1/+4
|\ \ \ | | | | | | | | Merge #3209 and 2.10.x to master
| * \ \ Merge commit '7d74884' into merge-2.10.x-to-masterJason Zaugg2013-12-061-1/+4
| |\ \ \ | | | |/ | | |/| | | | | | | | | Conflicts: test/files/jvm/scala-concurrent-tck.scala
| | * | SI-6913 Fixing semantics of Future fallbackTo to be according to docsHeather Miller2013-12-051-1/+4
| | | | | | | | | | | | | | | | Origin: viktorklang@1bbe854
* | | | Merge pull request #3191 from retronym/ticket/deprecate-par-viewJason Zaugg2013-12-0618-961/+277
|\ \ \ \ | |_|_|/ |/| | | Remove parallel collection views and, with them, Gen*View
| * | | Removes Gen*View and Par*ViewJason Zaugg2013-11-2618-973/+277
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - code that used to be inherited in *View is now inlined - the `view` methods on `ParIteratoa` and `ParSeq` now convert to sequential collections, and are deprecated asking the user to do this explicitly in the future. Should be largely source compatible with 2.10.x, on the assumption that the removed classes, while being public, were internal implementation details. A few tests used now-removed classes to demonstrate compiler crashes. I managed to confirm that after my decoupling, t4365 still exercises the bug: % qbin/scalac test/files/pos/t4365/*.scala warning: there were 2 deprecation warning(s); re-run with -deprecation for details one warning found % scalac-hash 7b4e450 test/files/pos/t4365/*.scala warning: there were 2 deprecation warning(s); re-run with -deprecation for details one warning found % scalac-hash 7b4e450~1 test/files/pos/t4365/*.scala 2<&1 | grep -i wrong error: something is wrong: cannot make sense of type application something is wrong: cannot make sense of type application something is wrong: cannot make sense of type application I didn't manage to do the same for specializes-sym-crash.scala, and instead just made it compile.
| * | | Deprecates Par*View and Gen*ViewJason Zaugg2013-11-2412-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 2.12, this gives us the option to move the code from Gen*View down into *View. If we don't do something more drastic with views, which inertia and history suggests is a real possibility, we can at least shed a little of the implementation. These abstractions are *only* used to share implementation; there is no `view` method available on, for instance, `GenSeq` that lets one abstract over parallel/sequential collections while spawning views. scala> (List(1): collection.GenSeq[Int]).view <console>:8: error: value view is not a member of scala.collection.GenSeq[Int] (List(1): collection.GenSeq[Int]).view ^ Let's keep it that way. I suspect that views over parallel collections exist not because they were the most sought after feature, but rather because the initial incarnatin of parallel collections used to live undernead TraversableOnce, and hence were obligated to implement `def view`. This change will give us deprecation warnings in the non deprecated places that extend `Gen*View` (three, by my count) in the interim. There are ways to avoid this, but they aren't particularly appealing.
* | | | Merge pull request #3213 from Ichoran/issue/8014Adriaan Moors2013-12-031-1/+1
|\ \ \ \ | | | | | | | | | | Fixes SI-8014, regression in Vector ++ TraversableOnce.
| * | | | Fixes SI-8014, regression in Vector ++ TraversableOnce.Rex Kerr2013-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Now uses the cached copy instead of the exhausted iterator. Adds a JUnit test for ++.
* | | | | SI-7373 Make the constructor of Vector non-publicJason Zaugg2013-12-031-1/+1
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The danger of: new Vector(1, 2, 3).toString java.lang.NullPointerException and the "should have been private all along" argument call for a break in the source compatibility policy here.
* | / / SI-8022 Backwards compatibility for Regex#unapplySeqJason Zaugg2013-12-011-6/+6
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change in ce1bbfe / SI-6406 introduced overloads of `unapplySeq` with wider static and dynmaic result types than the now-deprecated alternative that accepted `Any`. This is subtly source incompatible and the change was noticed in Specs2. This commit uses `List` as the static and runtime type for the new overloads. For consistency, the same is done for the new method added in SI-7737 / 93e9623.
* | | SI-4332 Plugs the gaps in viewsJason Zaugg2013-11-264-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These currently result in runtime errors: scala> List(1).view.distinct.force java.lang.UnsupportedOperationException: SeqView(...).newBuilder scala> List(1).view.inits.toList java.lang.UnsupportedOperationException: SeqView(...).newBuilder Two tests are enclosed: 1. reflect on the views to make any method that returns `Repr` is overriden in `*ViewLike`. This guards against new additions to the collections API. 2. exercise the newly added overrides Some care is needed with `tail`, we must re-override it in `mutable.IndexedSeqView` to be explicit about the end point of the slice, because the `IndexedSeqView#Sliced` defines length in terms of that. (Higher up the chain, it is just `iterator.size`, that's why `SeqView#tail` just sets up a slice from `1 to Int.MaxValue`.) Parallel collections views are not touched, as these are likely to be deprecated or removed shortly. Before this change, the test reported the following. Not all of these methods were buggy. For instance, `sortBy`, `sortWith` are implemented in terms of `sorted` which was implemented in `SeqViewLike`. Even in those cases, I have opted to override the methods in the `ViewLike` to guard against changes in the base class implementation and to simplify the rules in the test. ====================================================================== Checking scala.collection.TraversableView ====================================================================== trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr ====================================================================== Checking scala.collection.IterableView ====================================================================== trait IterableLike ---------------------------------------------------------------------- def dropRight(n: Int): Repr def sliding(size: Int): Iterator[Repr] def takeRight(n: Int): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr ====================================================================== Checking scala.collection.SeqView ====================================================================== trait IterableLike ---------------------------------------------------------------------- def dropRight(n: Int): Repr def sliding(size: Int): Iterator[Repr] def takeRight(n: Int): Repr trait SeqLike ---------------------------------------------------------------------- def combinations(n: Int): Iterator[Repr] def distinct: Repr def permutations: Iterator[Repr] def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr def sortWith(lt: (A, A) => Boolean): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr ====================================================================== Checking scala.collection.mutable.IndexedSeqView ====================================================================== trait IndexedSeqOptimized ---------------------------------------------------------------------- override def dropRight(n: Int): Repr override def tail: Repr override def takeRight(n: Int): Repr trait IterableLike ---------------------------------------------------------------------- def sliding(size: Int): Iterator[Repr] trait SeqLike ---------------------------------------------------------------------- def combinations(n: Int): Iterator[Repr] def distinct: Repr def permutations: Iterator[Repr] def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr def sortWith(lt: (A, A) => Boolean): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] ====================================================================== Checking scala.collection.immutable.StreamView ====================================================================== trait IterableLike ---------------------------------------------------------------------- def dropRight(n: Int): Repr def sliding(size: Int): Iterator[Repr] def takeRight(n: Int): Repr trait SeqLike ---------------------------------------------------------------------- def combinations(n: Int): Iterator[Repr] def distinct: Repr def permutations: Iterator[Repr] def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr def sortWith(lt: (A, A) => Boolean): Repr trait TraversableLike ---------------------------------------------------------------------- def filterNot(p: A => Boolean): Repr def inits: Iterator[Repr] def tails: Iterator[Repr] override def tail: Repr
* | | Merge pull request #3186 from Blaisorblade/patch-1Adriaan Moors2013-11-221-3/+3
|\ \ \ | | | | | | | | Revise paragraph (a revised #3164)
| * | | Revise paragraph (a revised #3164)Paolo G. Giarrusso2013-11-231-3/+3
| |/ / | | | | | | Revise text further, following suggestions in #3164 and part of the suggestions by @som-snytt. But I've kept "appear", since this paragraph documents the external behavior, not the implementation.
* | | SI-7999 s.u.c.NonFatal: StackOverflowError is fatalSimon Ochsenreither2013-11-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | As demonstrated in https://groups.google.com/d/topic/scala-language/eC9dqTTBYHg, SOEs should be considered fatal, because all popular JVM implementations seem to run into inconsistent state (ignoring finally blocks leading to not running monitorExit, leading to locks not being unlocked, ...) if one just pushes them enough.
* | | Merge pull request #3156 from JamesIry/remove_deprecated_migration_constructorJason Zaugg2013-11-221-4/+1
|\ \ \ | | | | | | | | Remove deprecated constructor from the migration annotation
| * | | Remove deprecated constructor from the migration annotationJames Iry2013-11-181-4/+1
| |/ / | | | | | | | | | | | | | | | | | | The migration annotation had a deprecated 2 arg constructor that was deprecated in 2.10.0. This commit removes that constructor. Because migration is private to the scala package this change shouldn’t affect the rest of the community.
* | | Merge pull request #3152 from paulp/pr/deprecationsJason Zaugg2013-11-227-138/+20
|\ \ \ | | | | | | | | Removing deprecated code.
| * | | Removing deprecated code.Paul Phillips2013-11-187-138/+20
| |/ / | | | | | | | | | | | | Code which has been deprecated since 2.10.0 and which allowed for straightforward removal.
* | | Merge pull request #3131 from densh/pr/deprecate-pair-and-tripleJason Zaugg2013-11-221-2/+4
|\ \ \ | | | | | | | | Deprecate Pair and Triple
| * | | deprecate Pair and TripleDen Shabalin2013-11-201-2/+4
| |/ /
* / / deprecate scala.ResponderDen Shabalin2013-11-211-0/+2
|/ / | | | | | | As discussed earlier it doesn’t really belong to the scala package.
* | Merge pull request #3119 from Ichoran/issue/5263James Iry2013-11-182-0/+1009
|\ \ | | | | | | New mutable hash map with Long keys: partially solves SI-5263 and is relevant to SI-6825.
| * | New AnyRefMap fixes SI-5263 to the extent practical.Rex Kerr2013-11-181-0/+451
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An open addressing hash map based on a similar scheme to mutable.LongMap. It delivers performance equivalent to Java's HashMap for pretty much all AnyRefs, plus it works nicely with Scala's collections. Revisions made sure that all return types in the public API are specified. Also switched to a leading-zeros method of calculating the initial mask (to save a few ns). Also edited out java.util comparison numbers and moved constants to companion.
| * | New mutable hash map with Long keys: partially solves SI-5263 and is relevantRex Kerr2013-11-181-0/+558
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to SI-6825. The hash map is based on an open addressing scheme that provides dramatically faster (mostly due to specialization) get and contains operations than either the standard Java HashMap or any of the existing Scala hash maps. It doesn't work well above 500,000,000 elements as the arrays cannot scale past 2^30 elements. Maps are not faster in general due to the lack of specialization of Function1[Long, V]. Revisions made sure that all return types in the public API are specified. Also switched to a leading-zeros method of calculating the initial mask (to save a few ns), and used an occasionally-more-efficient version of seekEntryOrOpen. Also edited out specific performance numbers and moved constants to companion.
* | | Merge pull request #3144 from xuwei-k/foreachValues-scaladocJames Iry2013-11-182-2/+2
|\ \ \ | | | | | | | | fix IntMap#foreachValue and LongMap#foreachValue scaladoc
| * | | fix IntMap#foreachValue and LongMap#foreachValue scaladocxuwei-k2013-11-152-2/+2
| | | |
* | | | fix typoxuwei-k2013-11-181-1/+1
|/ / /
* | | Merge pull request #3127 from ↵Adriaan Moors2013-11-131-3/+2
|\ \ \ | | | | | | | | | | | | | | | | RajivKurian/OpenHashMap-nextPowerOfTwo-implementation Use an intrinsic for the next power of two calculation.
| * | | Use an intrinsic for the next power of two calculation and also return the ↵Rajiv2013-11-111-3/+2
| |/ / | | | | | | | | | input as is if it is already a power of two
* | | Merge pull request #3113 from adriaanm/pr-rebase-3046Adriaan Moors2013-11-123-20/+20
|\ \ \ | | | | | | | | Make parameters to implicit value classes private
| * | | Make parameters to implicit value classes privateJason Zaugg2013-11-123-20/+20
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that they aren't offered as an autocomplete suggestion: implicit class Shouty(string: String) extends AnyVal { def SHOUT_! = string.toUpperCase + "!" } "". // autocompletion offers `.string` here The original incarnation of value classes didn't allow this sort of encapsulation, so we either invented goofy names like `__thingToAdd` or just picked `x` or `self`. But SI-7859 has delivered us the freedom to keep the accessor private. Should we keep any of these accessors around in a deprecated form? The implicit classes in Predef were added in 2.11.0-M2 (c26a8db067e4f), so they are okay. I think we can make reason that these APIs were both accidental and unlikely to be interpreted as public, so we can break them immediately. scala> Left(1).x res0: scala.util.Either[Int,Int] = Left(1) scala> import concurrent.duration._ import concurrent.duration._ scala> 1.n res1: Int = 1
* | | Merge pull request #3121 from rjfwhite/SI-7568James Iry2013-11-121-1/+1
|\ \ \ | | | | | | | | SI-7568 Adding Serializable to ResizableArrayAccess inner class
| * | | SI-7568 Adding Serializable to ResizableArrayAccess inner class of PriorityQueuerjfwhite2013-11-111-1/+1
| |/ /
* / / SI-7958 Deprecate methods `future` and `promise` in the `scala.concurrent` ↵Philipp Haller2013-11-122-14/+18
|/ / | | | | | | | | | | | | | | | | | | | | | | | | package object - The corresponding `apply` methods in the `Future` and `Promise` objects should be used instead. - Adjusted tests to use non-deprecated versions - Fixed doc comments not to use deprecated methods - Added comment about planned removal in 2.13.0
* | Collections library tidying and deprecation. Separate parts are listed below.Rex Kerr2013-11-0770-17/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Collections library tidying, part one: scripting. Everything in scala.collection.scripting is deprecated now, along with the << method that is implemented in a few other classes. Scripting does not seem used at all, and anyone who did can easily write a wrapper that does the same thing. Deprecated *Proxy collections. The only place proxies were used in the library was in swing.ListView, and that was easy to change to a lazy val. Proxy itself is used in ScalaNumberProxy and such, so it was left undeprecated. Deprecated Synchronized* traits from collections. Synchronizability does not compose well, and it requires careful examination of every method (which has not actually been done). Places where the Scala codebase needs to be fixed (eventually) include: scala.reflect.internal.util.Statistics$QuantMap scala.tools.nsc.interactive.Global (several places) Deprecated LinkedList (including Double- and -Like variants). Interface is idiosyncratic and dangerously low-level. Although some low-level functionality of this sort would be useful, this doesn't seem to be the ideal implementation. Also deprecated the extractFirst method in Queue as it exposes LinkedList. Cannot shift internal representations away from LinkedList at this time because of that method. Deprecated non-finality of several toX collection methods. Improved documentation of most toX collection methods to describe what the expectation is for their behavior. Additionally deprecated overriding of - toIterator in IterableLike (should always forward to iterator) - toTraversable in TraversableLike (should always return self) - toIndexedSeq in immutable.IndexedSeq (should always return self) - toMap in immutable.Map (should always return self) - toSet in immutable.Set (should always return self) Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since for some odd reason immutable.Range overrides those. Deprecated Forwarders from collections. Forwarding, without an automatic mechanism to keep up to date with changes in the forwarded class, is inherently unreliable. Absent a mechanism to keep current, they're deprecated. ListBuffer is the only class in the collections library that uses forwarders, and that functionality can be rolled into ListBuffer itself. Deprecating immutable set/map adaptors. They're a bad idea (barring compiler support) for the same reason that all the other adaptors are a bad idea: they get out of date and probably have a variety of performance bugs. Deprecated inheritance from leaf classes in immutable collections. Inheriting from leaf-classes in immutable collections is rarely a good idea since whenever you use any interesting collections method you'll revert to the original class. Also, the methods are often designed to work with only particular behavior, and an override would be difficult (at best) to make work. Fortunately, people seem to have realized this and there are few to no cases of people extending PagedSeq and TreeSet and the like. Note that in many cases the classes will become sealed not final. Deprecated overriding of methods and inheritance from various mutable collections. Some mutable collections seem unsuited for overriding since to override anything interesting you would need vast knowledge of internal data structures and/or access to private methods. These include - ArrayBuilder.ofX classes. - ArrayOps - Some methods of BitSet (moved others from private to protected final) - Some methods of HashTable and FlatHashTable - Some methods of HashMap and HashSet (esp += and -= which just forward) - Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet) - PriorityQueue - UnrolledBuffer This is a somewhat aggressive deprecation, the theory being better to try it out now and back off if it's too much than not attempt the change and be stuck with collections that can neither be safely inherited nor have implementation details changed. Note that I have made no changes--in this commit--which would cause deprecation warnings in any of the Scala projects available on Maven (at least as gathered by Adriaan). There are deprecation warnings induced within the library (esp. for classes/traits that should become static) and the compiler. I have not attempted to fix all the deprecations in the compiler as some of them touch the IDE API (but these mostly involved Synchronized which is inherently unsafe, so this should be fixed eventually in coordination with the IDE code base(s)). Updated test checks to include new deprecations. Used a higher level implementation for messages in JavapClass.
* | Merge pull request #3086 from axel22/topic/pc-execution-contextAdriaan Moors2013-11-052-10/+87
|\ \ | | | | | | - parallel collections should use default ExecutionContext
| * | SI-7938 - parallel collections should use default ExecutionContextAleksandar Prokopec2013-10-292-10/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parallel collections now use `scala.concurrent.ExecutionContext` by default. The `ExecutionContextTaskSupport` is optimized to use the `ForkJoinPool` underlying the `ExecutionContext` if possible. Otherwise, a fallback `TaskSupport` that creates a reduction tree and execute an operation through `Future`s is used.
* | | from Issue #3098Xusen Yin2013-11-051-2/+2
| | | | | | | | | from Issue #3098, some typos.
* | | Collections: remove redundant calls to .seqJason Zaugg2013-10-319-13/+13
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Students of Scala's history might recall that at introduction of parallel collections, GenIterable et al were *not* added; instead the parallel collections inherited from the existing interfaces. This of course was an invitation to widespread disaster as any existing code that foreach-ed over a collection might now experience unwanted concurrency. The first attempt to fix this was to add the `.seq` method to convert a parallel colleciton to a sequential one. This was added in e579152f732, and call sites in the standard library with side-effecting foreach calls were changed to use that. But this was (rightly) deemed inadequate, as we could hardly expect people to change existing code or remember to do this in new code. So later, in 3de96153e5b, GenIterable was sprouted, and parallel collections were re-parented. This commit removes residual needless calls to .seq when the static type of the receiver is already a plain Iterable, which are no-ops.
* | Merge pull request #3079 from jamesward/fix/ec-implicit-errorJames Iry2013-10-251-1/+1
|\ \ | | | | | | More clear implicitNotFound error for ExecutionContext
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 12:27:59 +0000