Scala 2.13.0 support #42

julienrf · 2018-08-13T20:41:14Z

I’ve taken the existing code base, commented out everything but ParVector, ParIterable and ParIterableLike, and fixed compilation errors. In some places, I’ve left the previous code commented, for reference, because the changes I’ve made are temporary.

I’ve made a few decisions:

not use CanBuildFrom (or CanCombineFrom) for transformation operations (e.g. map), similarly to what we have in the new collections, but that requires introducing a new type parameter (CC[_]) to the template traits (ParIterableLike). I’d like to discuss this change with you. I made that change for symmetry with the new collections but it is not required: we could still use CanCombineFrom to drive the return type of transformation operations (we would drop the CanBuildFrom part, though),
flatMap takes a function f: A => IterableOnce[B] (instead of f: A => GenTraversableOnce[B], previously), although the parallel collections hierarchy does not extend IterableOnce (yet?),
ParIterable does not extend anything from the standard collections (not even IterableOnce).

Remaining design decisions to make:

Define how we should integrate parallel and sequential collections. For instance, the fact that flatMap takes a function producing an IterableOnce makes it currently impossible to use it with parallel collections. Relatedly: do we want to make it possible to zip together a parallel collection and a sequential collection? Should parallel collections extend IterableOnce? They could, they already have an iterator member (which is typed as Splitter, a specialization of Iterator). Or, should we completely decouple Splitter from Iterator?
- The decision is to make ParIterableLike extend IterableOnce
Depending on the first point, what operations should we have on parallel collections? I’m tempted to drop sequential operations (such as foldLeft) in favor of parallel-only operations (such as fold). But that will cause migration pain to users, and this is more work for us.
- The decision is to keep sequential operations on parallel collections

Remaining things to do:

This is a lot of work. Let’s try to parallelize it. Everybody is welcome! Send me a message on https://gitter.im/julienrf to tell me which bullet point you want to work on and I will update the PR description accordingly.

szeiger · 2018-08-14T16:17:20Z

not use CanBuildFrom (or CanCombineFrom) for transformation operations (e.g. map), similarly to what we have in the new collections, but that requires introducing a new type parameter (CC[_]) to the template traits (ParIterableLike). I’d like to discuss this change with you. I made that change for symmetry with the new collections but it is not required

Aligning this more with the new collections design is generally desirable. After all, we did make the changes there for a reason. My plan for the parallel collections was to keep CanBuildFrom (at least initially) in order to make it simpler to port. If that's not actually true we may as well change it.

flatMap takes a function f: A => IterableOnce[B] (instead of f: A => GenTraversableOnce[B], previously), although the parallel collections hierarchy does not extend IterableOnce (yet?)

It should extend IterableOnce. An Iterator is a natural way of traversing a parallel collection sequentially. This was not the case with TraversableOnce vs GenTraversableOnce because their internal iteration allowed parallel collections to perform it concurrently.

They could, they already have an iterator member (which is typed as Splitter, a specialization of Iterator). Or, should we completely decouple Splitter from Iterator?

I'd try to avoid unnecessary changes for now. Unless there's a compelling reason for Splitter not to extend Iterator anymore, keep it that way.

Depending on the first point, what operations should we have on parallel collections? I’m tempted to drop sequential operations (such as foldLeft) in favor of parallel-only operations (such as fold). But that will cause migration pain to users, and this is more work for us.

Sequential operation can still be useful for the same reason that sequential collections are allowed to override them instead of always using Iterator implementations: Better performance.

odersky · 2018-08-14T17:18:20Z

Hi Julien, Interesting that this approach was untilmately easier than keeping CanBuildFrom! But, as Stefan says that's even better; we should align parallel and sequential where possible. I also think that we should keep the API as close as possible to what we have, including sequential operations. Cheers - Martin

…

On Tue, Aug 14, 2018 at 6:17 PM, Stefan Zeiger ***@***.***> wrote: not use CanBuildFrom (or CanCombineFrom) for transformation operations (e.g. map), similarly to what we have in the new collections, but that requires introducing a new type parameter (CC[_]) to the template traits ( ParIterableLike). I’d like to discuss this change with you. I made that change for symmetry with the new collections but it is not required Aligning this more with the new collections design is generally desirable. After all, we did make the changes there for a reason. My plan for the parallel collections was to keep CanBuildFrom (at least initially) in order to make it simpler to port. If that's not actually true we may as well change it. flatMap takes a function f: A => IterableOnce[B] (instead of f: A => GenTraversableOnce[B], previously), although the parallel collections hierarchy does *not* extend IterableOnce (yet?) It should extend IterableOnce. An Iterator is a natural way of traversing a parallel collection sequentially. This was not the case with TraversableOnce vs GenTraversableOnce because their internal iteration allowed parallel collections to perform it concurrently. They could, they already have an iterator member (which is typed as Splitter, a specialization of Iterator). Or, should we completely decouple Splitter from Iterator? I'd try to avoid unnecessary changes for now. Unless there's a compelling reason for Splitter not to extend Iterator anymore, keep it that way. Depending on the first point, what operations should we have on parallel collections? I’m tempted to drop sequential operations (such as foldLeft) in favor of parallel-only operations (such as fold). But that will cause migration pain to users, and this is more work for us. Sequential operation can still be useful for the same reason that sequential collections are allowed to override them instead of always using Iterator implementations: Better performance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwlVhcPbOtOwtLvPvh2Ml-sW9UDyRdtks5uQvgQgaJpZM4V7Mh-> .

-- Martin Odersky EPFL and Lightbend

julienrf · 2018-08-16T16:18:38Z

Great, thanks for your feedback! So, let’s make parallel collections extend IterableOnce and let’s keep sequential operations on them.

julienrf · 2019-01-09T20:27:47Z

I’ve made some progress but I’ve been unable to make mutable and immutable hashmap combiners work. The model of the underlying data structure based on an Array[UnrolledBuffer] is not clear to me. It seems that all the updates on the same key are stored, instead of storing only the last one. I’d like to get some help on that side, maybe @axel22 can give me some insights? The symptom I see is the following:

scala> import scala.collection.parallel.mutable._
import scala.collection.parallel.mutable._

scala> val pmap = ParHashMap(1 -> 0, 2 -> 0, 3 -> 0)
pmap: scala.collection.parallel.mutable.ParHashMap[Int,Int] = ParHashMap(1 -> 0, 2 -> 0, 3 -> 0)

scala> pmap ++ List(1 -> 1)
res0: scala.collection.parallel.mutable.ParHashMap[Int,Int] = ParHashMap(1 -> 0, 2 -> 0, 3 -> 0)

scala> pmap += (1 -> 1)
res1: pmap.type = ParHashMap(1 -> 1, 2 -> 0, 3 -> 0)

As you can see, the result of the concatenation shows the 1 -> 0 binding instead of the expected 1 -> 1 binding. If I use the += operation, the map is correctly updated, though.

julienrf · 2019-01-12T18:26:37Z

core/src/main/scala/scala/collection/generic/GenericParCompanion.scala

+      b ++= elems
+      b.result()
+    }
+  }


These methods (empty and apply) were previously inherited from GenericCompanion, which has been removed from the standard library.

julienrf · 2019-01-12T18:28:37Z

core/src/main/scala/scala/collection/generic/GenericParCompanion.scala

+    extends Factory[A, CC[A]] with Serializable{
+      def fromSpecific(it: IterableOnce[A]): CC[A] = (parFactory.newBuilder[A] ++= it).result()
+      def newBuilder: mutable.Builder[A, CC[A]] = parFactory.newBuilder
+  }


These conversions towards scala.collection.Factory provide interoperability with the standard collections. It makes it possible to write List(1, 2, 3).to(ParArray).

julienrf · 2019-01-12T18:29:36Z

core/src/main/scala/scala/collection/generic/GenericParCompanion.scala

+  ) extends Factory[(K, V), CC[K, V]] with Serializable {
+    def fromSpecific(it: IterableOnce[(K, V)]): CC[K, V] = (parFactory.newCombiner[K, V] ++= it).result()
+    def newBuilder: mutable.Builder[(K, V), CC[K, V]] = parFactory.newCombiner
+  }


Same with maps, to support Map(1 -> 0, 2 -> 0).to(ParMap).

julienrf · 2019-01-12T18:31:04Z

core/src/main/scala/scala/collection/generic/ParFactory.scala

+      }
+    }
+    b.result()
+  }


All the above factory methods were previously inherited from GenTraversableFactory.

julienrf · 2019-01-12T18:33:34Z

core/src/main/scala/scala/collection/generic/ParMapFactory.scala

+extends GenericParMapCompanion[CC] {
+
+  type Coll = MapColl
+


The methods below were previously inherited from GenMapFactory.

julienrf · 2019-01-12T19:14:29Z

junit/src/test/scala/MiscTest.scala

@@ -77,7 +71,7 @@ class MiscTest {
        assert(ex.getSuppressed.size > 0)
        assert(ex.getSuppressed.forall(_.isInstanceOf[MultipleOf37Exception]))
        assert(ex.i == 37)
-        assert(ex.getSuppressed.map(_.asInstanceOf[MultipleOf37Exception].i).toList == List(74, 148, 259, 518))
+        assert(ex.getSuppressed.map(_.asInstanceOf[MultipleOf37Exception].i).toList == List(/*74,*/ 148, 259, 518))


Oddly, the value 74 is not part of the suppressed elements. I didn’t understand why. Maybe it’s a bug somewhere in ParSeq?

I think that this should depend on how the scheduler exactly divided the tasks.
It's possible that the task corresponding to 74 never got scheduled (e.g. because tryCancel was called on the ForkJoinTask in an attempt to piggy-back it on the same worker).

I'd say that this assertion should check that all i are a multiple of 37, but not make any specific assumptions about the exact exceptions.

julienrf · 2019-01-12T19:15:25Z

junit/src/test/scala/MiscTest.scala

@@ -92,7 +86,8 @@ class MiscTest {
    def check[T](i: Int, f: Int => T): Unit = {
      val gseq = seqarr(i).toSeq.groupBy(f)
      val gpar = pararr(i).groupBy(f)
-      assertEquals(gseq, gpar)
+      assertTrue(gseq.forall { case (k, vs) => gpar.get(k).exists(_.sameElements(vs)) })
+      assertTrue(gpar.forall { case (k, vs) => gseq.get(k).exists(_.sameElements(vs)) })


Since sequential and parallel collections are not anymore comparable with ==/equals, I’m using these expressions instead.

julienrf · 2019-01-12T19:16:46Z

junit/src/test/scala/scala/collection/immutable/ParallelConsistencyTest.scala

@@ -1,44 +0,0 @@
-package scala.collection.immutable


This test does not make sense anymore since we don’t support equality comparisons between sequential and parallel collections.

julienrf · 2019-01-12T19:18:00Z

junit/src/test/scala/scala/runtime/ScalaRunTimeTest.scala

-
-    val parIterable = ParIterable("a", "", " c", null)
-    assertEquals(s"""${parIterable.stringPrefix}(a, "", " c", null)""", stringOf(parIterable))
-    assertEquals(s"""${parIterable.stringPrefix}(a, "")""", stringOf(parIterable, 2))


This test doesn’t pass anymore. I guess we don’t want to support the fact that parallel collections used to be treated specially by ScalaRunTime?

julienrf · 2019-01-12T19:23:38Z

scalacheck/src/test/scala/ParallelMapCheck1.scala

+      case e: java.lang.Exception =>
+        throw e
+    }
+  }


The above properties test the overloads that return maps.

julienrf · 2019-01-12T19:30:50Z

scala/scala#7636 needs to be merged for these changes to compile.

axel22 · 2019-01-12T21:06:08Z

I’ve made some progress but I’ve been unable to make mutable and immutable hashmap combiners work. The model of the underlying data structure based on an Array[UnrolledBuffer] is not clear to me. It seems that all the updates on the same key are stored, instead of storing only the last one. I’d like to get some help on that side, maybe @axel22 can give me some insights?

The idea is that the combiner data structure separates the keys into a fixed number of buckets.
The Array is a fixed-size array with these buckets.
Each bucket holds all the keys that have a similar prefix of the hash-code.
The bucket could be any data structure, but an unrolled linked list is probably the most efficient choice.

There are some additional details about this here:

http://aleksandar-prokopec.com/resources/docs/techrep.pdf

http://aleksandar-prokopec.com/resources/docs/my_thesis.pdf (page 49, PDF-wise)

If you want, we can have a call, and I can explain in more detail.

The symptom I see is the following:

scala> import scala.collection.parallel.mutable._
import scala.collection.parallel.mutable._

scala> val pmap = ParHashMap(1 -> 0, 2 -> 0, 3 -> 0)
pmap: scala.collection.parallel.mutable.ParHashMap[Int,Int] = ParHashMap(1 -> 0, 2 -> 0, 3 -> 0)

scala> pmap ++ List(1 -> 1)
res0: scala.collection.parallel.mutable.ParHashMap[Int,Int] = ParHashMap(1 -> 0, 2 -> 0, 3 -> 0)

I don't 100% remember if what I will say is correct, but I think what happens is the following:

List(1 -> 1) is converted into a parallelizable collection, for example, array.
Both the ParHashMap and the converted list are added to the combiners in parallel.
When combiners are reduced (in a reduction tree), they are merged with the first-wins rule. Since the list of results with the key 1 from the left part of the reduction tree precedes the corresponding list from the right part of the reduction tree, the left-one is taken as the result.

Maybe this semantics should change, and right-hand-side-wins is correct.

scala> pmap += (1 -> 1)
res1: pmap.type = ParHashMap(1 -> 1, 2 -> 0, 3 -> 0)


As you can see, the result of the concatenation shows the `1 -> 0` binding instead of the expected `1 -> 1` binding. If I use the `+=` operation, the map is correctly updated, though.

The += operation is not parallel, it just updates the map in-place (because it's mutable).

axel22 · 2019-01-12T21:09:58Z

The model of the underlying data structure based on an Array[UnrolledBuffer] is not clear to me. It seems that all the updates on the same key are stored, instead of storing only the last one.

The reason why it stores all the updates is because it's more efficient to:

When appending an element, just append a result by looking-up the appropriate bucket in the Array, and append a pointer at the end of the list.
When combining two combiners, just link their unrolled linked lists together (O(1) operation).

You could alternatively have a Array[HashTable] as a combiner, but that would make the append more costly (hash-table lookup and an append), and it would make the combiner much more costly (you would need to traverse both buckets when merging them, instead of just appending at the end).

julienrf · 2019-01-12T21:49:53Z

3. When combiners are reduced (in a reduction tree), they are merged with the first-wins rule. Since the list of results with the key 1 from the left part of the reduction tree precedes the corresponding list from the right part of the reduction tree, the left-one is taken as the result.

Maybe this semantics should change, and right-hand-side-wins is correct.

Yes, this is what I observe. But why was that “left-hand-side-wins” semantics correct?

axel22 · 2019-01-12T22:20:27Z

I'm not sure if it was correct, in retrospect.

Maybe it was more appropriate from the viewpoint of some other transformation operations, but having just taken a look at the methods supported by Map (https://www.scala-lang.org/api/2.12.3/scala/collection/Map.html), I can't see which ones those would be.

I think right-hand wins semantics are actually the correct ones.

julienrf · 2019-01-12T22:22:19Z

It had to be correct because tests were passing :)

axel22 · 2019-01-13T00:34:25Z

Scala 2.12.4:

scala> Map(1 -> 2, 3 -> 2) ++ List(3 -> 3)
res0: scala.collection.immutable.Map[Int,Int] = Map(1 -> 2, 3 -> 3)

scala> Map(1 -> 2, 3 -> 2).par ++ List(3 -> 3)
res1: scala.collection.parallel.immutable.ParMap[Int,Int] = ParMap((1,2), (3,3))

Ok, so you're saying that it used to work correctly, but it's not working correctly in the new implementation?

julienrf · 2019-01-13T07:17:06Z

Yes.

julienrf · 2019-01-13T17:57:57Z

Actually the tests that used to pass still pass. I realized that there were no tests for the case where the combiner is a ParMap combiner (all tests use a ParIterable combiner). I’ve introduced new methods (overloads of map, flatMap, etc.) which specifically return a ParMap rather than a ParIterable (I’ve followed the new design of the collections where the return type of these methods is not computed by a CanBuildFrom instance). However, these methods do not yield correct results, although their implementation is exactly the same as the one returning a ParIterable (except that they use the combiner from their mapCompanion rather than their companion). All the failures are due to an ordering issue in the way combiners are reduced. If I try to fix the implementation of the combiner to pick another “winner”, it fixes the problem for one method but breaks another one.

axel22 · 2019-01-13T18:12:20Z

If I try to fix the implementation of the combiner to pick another “winner”, it fixes the problem for one method but breaks another one.

Which methods need opposite reduction rules?
Perhaps we could have two different factory methods that select the combiner's reduction strategy.

julienrf · 2019-01-13T18:40:34Z

Consider the following code:

val mConcat = parallel.mutable.ParMap(1 -> 0) ++ List(1 -> 1)
assertEquals(parallel.mutable.ParMap(1 -> 1), mConcat)

val mMap = parallel.mutable.ParMap(1 -> 0, 3 -> 1).map { case (k, v) => (k % 2, v) }
assertEquals(parallel.mutable.ParMap(1 -> 1), mMap)

I can either get the first assertion pass or the second but not both.

julienrf · 2019-01-13T19:09:12Z

How is the ordering of ParMap transformations supposed to be guaranteed? I expect the computations to happen in parallel but their results to be combined in order, to retain the same semantics as with sequential Maps. In the example I’ve given above, the buckets resulting from the map operation are:

Array(UnrolledBuffer(DefaultEntry(1 -> 1), DefaultEntry(1 -> 0)), null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null)

Which shows that the result of the second entry of the map is before the result of the first entry.

julienrf · 2019-01-17T14:59:57Z

Actually, I think the behavior I’m seeing was not specified. Here are some examples on Scala 2.12:

import collection.parallel._

mutable.ParMap(1 -> 0) ++ List(1 -> 1) // ParHashMap(1 -> 0)
immutable.ParMap(1 -> 0) ++ List(1 -> 1) // ParMap(1 -> 1)

It seems that when there is a clash in keys, the one that wins is unspecified.

Therefore, I estimate that there is no regression introduced in this PR.

julienrf · 2019-01-17T15:20:00Z

Before rebasing: I think I should also squash the commits into a single one to not pollute the git history. Indeed, at the beginning of the work I’ve commented out most of the files and then I’ve uncommented them one by one until everything compiled. As a consequence, a git blame on a file that I’ve commented and then uncommented will show the commit where the file was commented, although that’s not a relevant change. If I squash the commits into a single one, that “comment and then uncomment” manipulation will disappear. Does that make sense to you?

adriaanm · 2019-01-17T19:10:32Z

sounds good -- I'd still keep the WIP branch available too, as it can help with reviewing

- Old code from scala.collection.generic package has been imported from the 2.12.x branch. - Make ParIterableLike extend IterableOnce - Operations that used to take GenIterable collections as parameter now have two overloads, one taking a ParIterable and another taking an Iterable - VectorIterator has been deprecated, which is unfortunate because it is used for implementing ParVector. As a consequence, we now get a deprecation warning when we compile the project - Inline GenTraversableFactory and GenericCompanion from scala/scala - Move the contents that was previously in GenericCompanion into the GenericParCompanion trait - Remove ParallelConsistencyTest, which does not make sense anymore since sequential collection don’t take “generic” collections as parameter. - Move ExposedArraySeq logic to ParArray. - Parallel collections are not anymore comparable with sequential collections. Tests systematically replace `==` with `sameElements`. - Add support for the `to` conversion method in both directions (sequential to parallel and parallel to sequential). `toSeq`, `toIterable`, `toSet` and `toMap` used to be overridden to return parallel collections. I’ve kept that choice (although that makes it impossible to inherit from `IterableOnceOps`, then). - Restore usage of DoublingUnrolledBuffer - Restore FlatHashTable from scala/scala@9008c2f. Systematically use `areEqual` in tests with no strict order. - Implementation of the sequential Set returned by the `seq` member has been copied from scala/scala@056e1e9.

julienrf · 2019-01-18T14:57:53Z

I’ve squashed the commits. The full history is still available in the 2.13.x-unsquashed branch.

axel22 · 2019-01-22T18:35:30Z

Consider the following code:

val mConcat = parallel.mutable.ParMap(1 -> 0) ++ List(1 -> 1)
assertEquals(parallel.mutable.ParMap(1 -> 1), mConcat)

val mMap = parallel.mutable.ParMap(1 -> 0, 3 -> 1).map { case (k, v) => (k % 2, v) }
assertEquals(parallel.mutable.ParMap(1 -> 1), mMap)

I can either get the first assertion pass or the second but not both.

I think that, in order to provide different ordering semantics for different types of operations, the builder factories (e.g. CanBuildFrom objects) should support multiple creation methods for Combiner objects.
For example:

trait CombineFrom[-From, -A, +C] {
  def applyLeft(): Combiner[A, C]
  def applyRight(): Combiner[A, C]
}

The method implementation could then instantiate the correct combiner, depending on its semantics. As far as I remember, this was not done in the past, partly because the operation semantics were not explicitly specified, I think.

axel22 · 2019-01-22T18:36:21Z

Actually, I think the behavior I’m seeing was not specified. Here are some examples on Scala 2.12:
import collection.parallel._

mutable.ParMap(1 -> 0) ++ List(1 -> 1) // ParHashMap(1 -> 0)
immutable.ParMap(1 -> 0) ++ List(1 -> 1) // ParMap(1 -> 1)
It seems that when there is a clash in keys, the one that wins is unspecified.

Therefore, I estimate that there is no regression introduced in this PR.

I don't think it is a regression either, mainly because the behavior was not documented, as far as I remember.

julienrf · 2019-01-29T16:55:15Z

Now that the required changes have been merged to scala/scala, the next thing that prevents this PR to be endorsed by the CI is the fact that there is no (public) ScalaCheck release which is binary compatible with the last Scala nightly.

SethTisue · 2019-01-30T00:27:48Z

we can use dbuild here. trying it: https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1725/

SethTisue · 2019-01-30T00:28:48Z

fwiw, another possibility would have been to modify .travis.yml to check out the scalacheck repo and do publishLocal. but we might as well apply my dbuild knowledge here

SethTisue · 2019-01-30T03:03:38Z

https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1729/

[info] Project scala-parallel-collections--: SUCCESS (project rebuilt ok)

👍

SethTisue

@julienrf you added some comments here on GitHub that I think would be even better as code comments. and I see in the diffs, you commented out some things without explanation, could you either include a brief explanation for each of these, or just delete the code, as appropriate?

other than that, this looks good to go

SethTisue · 2019-02-05T01:03:06Z

I'd like to get this merged and roll a release. @julienrf up to you if you think it's worth it to do my comment suggestion in a separate PR

SethTisue · 2019-02-05T01:36:38Z

hmm, I guess there's no point in rolling a release until 2.13.0-RC1 is out. we can't roll it for M5

adriaanm · 2019-02-05T06:50:55Z

we need to re-starr anyway, so i was thinking we could consider that starr as RC0 and use it for trial running releases like this one

SethTisue · 2019-02-19T22:28:10Z

after scala/scala#7758, new STARR is 2.13.0-M5-1775dba which is on Maven Central

but, I don't see a real need to do a trial scala-parallel-collections release, I don't think it would be useful in isolation, and I don't anticipate it making sense to publish a bunch of other libraries for 1775dba, either

let's just continue using dbuild to test things. RC1 will be along soon enough

SethTisue · 2019-02-19T22:33:24Z

scala/community-build@96fd70a moves the 2.13 community build to 1775dba; as usual, I'll track down resulting regressions, if any

julienrf force-pushed the 2.13.x branch from 30d4dcd to ebfe7de Compare August 16, 2018 18:44

xuwei-k mentioned this pull request Aug 17, 2018

support Scala 2.13.0-RC1 #41

Closed

julienrf force-pushed the 2.13.x branch from de4836c to ee4b9e4 Compare December 27, 2018 14:29

julienrf commented Jan 12, 2019

View reviewed changes

julienrf changed the title ~~[WIP] Scala 2.13.0 support~~ Scala 2.13.0 support Jan 12, 2019

julienrf force-pushed the 2.13.x branch from 6715521 to c193570 Compare January 13, 2019 19:14

adriaanm requested a review from SethTisue January 16, 2019 16:52

julienrf force-pushed the 2.13.x branch from 12996fc to 6d097a1 Compare January 17, 2019 18:57

julienrf force-pushed the 2.13.x branch from 6d097a1 to 8da0743 Compare January 18, 2019 14:55

don't try to use 2.12 ScalaCheck

359e591

use newer Scala 2.13 snapshot that has needed collections changes

4af1d05

SethTisue requested changes Jan 31, 2019

View reviewed changes

adapt to scala/scala#7696

17647af

SethTisue merged commit e3d7ac6 into scala:master Feb 5, 2019

julienrf deleted the 2.13.x branch February 5, 2019 07:47

SethTisue mentioned this pull request Feb 19, 2019

use latest STARR for scalaVersion #56

Closed

SethTisue mentioned this pull request Feb 20, 2019

Adapt the parallel-collections module to the new design scala/collection-strawman#328

Closed

SethTisue mentioned this pull request May 12, 2020

Scala 2.13 woes: Parallelism silently lost #101

Closed

Scala 2.13.0 support #42

Scala 2.13.0 support #42

Conversation

julienrf commented Aug 13, 2018 • edited Loading

szeiger commented Aug 14, 2018

odersky commented Aug 14, 2018 via email

julienrf commented Aug 16, 2018

julienrf commented Jan 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

julienrf commented Jan 12, 2019

axel22 commented Jan 12, 2019

axel22 commented Jan 12, 2019

julienrf commented Jan 12, 2019

axel22 commented Jan 12, 2019

julienrf commented Jan 12, 2019

axel22 commented Jan 13, 2019 • edited Loading

julienrf commented Jan 13, 2019 via email

julienrf commented Jan 13, 2019

axel22 commented Jan 13, 2019

julienrf commented Jan 13, 2019 • edited Loading

julienrf commented Jan 13, 2019

julienrf commented Jan 17, 2019

julienrf commented Jan 17, 2019

adriaanm commented Jan 17, 2019

julienrf commented Jan 18, 2019

axel22 commented Jan 22, 2019

axel22 commented Jan 22, 2019

julienrf commented Jan 29, 2019

SethTisue commented Jan 30, 2019

SethTisue commented Jan 30, 2019

SethTisue commented Jan 30, 2019

SethTisue left a comment

Choose a reason for hiding this comment

SethTisue commented Feb 5, 2019 • edited Loading

SethTisue commented Feb 5, 2019

adriaanm commented Feb 5, 2019

SethTisue commented Feb 19, 2019 • edited Loading

SethTisue commented Feb 19, 2019 • edited Loading

julienrf commented Aug 13, 2018 •

edited

Loading

julienrf commented Jan 9, 2019 •

edited

Loading

axel22 commented Jan 13, 2019 •

edited

Loading

julienrf commented Jan 13, 2019 •

edited

Loading

SethTisue commented Feb 5, 2019 •

edited

Loading

SethTisue commented Feb 19, 2019 •

edited

Loading

SethTisue commented Feb 19, 2019 •

edited

Loading