Permalink
Commits on Sep 18, 2015
  1. Bump version number one last time?

    adriaanm committed Sep 18, 2015
    So that osgi version is set correctly by build.
Commits on Jun 16, 2015
  1. Merge pull request #4557 from adriaanm/mcpasterton-2.10

    adriaanm committed Jun 16, 2015
    Clean implementation of sorts for scala.util.Sorting.
  2. Clean implementation of sorts for scala.util.Sorting.

    Ichoran committed with adriaanm May 30, 2015
    Removed code based on Sun JDK sorts and implemented new (basic) sorts from
    scratch.  Deferred to Java Arrays.sort whenever practical.  Behavior of
    `scala.util.Sorting` should be unchanged, but changed documentation to
    specify when the Java methods are being used (as they're typically very fast).
    
    A JUnit test is provided.
    
    Performance is important for sorts.  Everything is better with this patch,
    though it could be better yet, as described below.
    
    Below are sort times (in microseconds, SEM < 5%) for various 1024-element
    arrays of small case classes that compare on an int field (quickSort), or
    int arrays that use custom ordering (stableSort).  Note: "degenerate"
    means there are only 16 values possible, so there are lots of ties.
    Times are all with fresh data (no re-using cache from run to run).
    
    Results:
    
    ```
                            random  sorted  reverse  degenerate  big:64k  tiny:16
    Old Sorting.quickSort     234     181      178         103    25,700      1.4
    New Sorting.quickSort     170      27      115          74    18,600      0.8
    
    Old Sorting.stableSort    321     234      236         282    32,600      2.1
    New Sorting.stableSort    239      16      194         194    25,100      1.2
    
    java.util.Arrays.sort     124       4        8         105    13,500      0.8
    java.util.Arrays.sort|Box 126      15       13         112    13,200      0.9
    ```
    
    The new versions are uniformly faster, but uniformly slower than Java sorting.  scala.util.Sorting has use cases that don't map easily in to Java unless everything is pre-boxed, but the overhead of pre-boxing is minimal compared to the sort.
    
    A snapshot of some of my benchmarking code is below.
    
    (Yes, lots of repeating myself--it's dangerous not to when trying to get
    somewhat accurate benchmarks.)
    
    ```
    import java.util.Arrays
    import java.util.Comparator
    import math.Ordering
    import util.Sorting
    import reflect.ClassTag
    
    val th = ichi.bench.Thyme.warmed()
    
    case class N(i: Int, j: Int) {}
    val a = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt, i)) )
    var ai = 0
    val b = Array.fill(1024)( Array.tabulate(1024)(i => N(i, i)) )
    var bi = 0
    val c = Array.fill(1024)( Array.tabulate(1024)(i => N(1024-i, i)) )
    var ci = 0
    val d = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt(16), i)) )
    var di = 0
    val e = Array.fill(16)( Array.tabulate(65536)(i => N(util.Random.nextInt, i)) )
    var ei = 0
    val f = Array.fill(65535)( Array.tabulate(16)(i => N(util.Random.nextInt, i)) )
    var fi = 0
    
    val o = new Ordering[N]{ def compare(a: N, b: N) = if (a.i < b.i) -1 else if (a.i > b.i) 1 else 0 }
    for (s <- Seq("one", "two", "three")) {
      println(s)
      th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Sorting.quickSort(x)(o); x(x.length/3) }
      th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Sorting.quickSort(x)(o); x(x.length/3) }
      th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Sorting.quickSort(x)(o); x(x.length/3) }
      th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Sorting.quickSort(x)(o); x(x.length/3) }
      th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Sorting.quickSort(x)(o); x(x.length/3) }
      th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Sorting.quickSort(x)(o); x(x.length/3) }
    }
    
    def ix(ns: Array[N]) = {
      val is = new Array[Int](ns.length)
      var i = 0
      while (i < ns.length) {
        is(i) = ns(i).i
        i += 1
      }
      is
    }
    val p = new Ordering[Int]{ def compare(a: Int, b: Int) = if (a > b) 1 else if (a < b) -1 else 0 }
    for (s <- Seq("one", "two", "three")) {
      println(s)
      val tag: ClassTag[Int] = implicitly[ClassTag[Int]]
      th.pbench{ val x = ix(a(ai)); ai = (ai+1)%a.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
      th.pbench{ val x = ix(b(bi)); bi = (bi+1)%b.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
      th.pbench{ val x = ix(c(ci)); ci = (ci+1)%c.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
      th.pbench{ val x = ix(d(di)); di = (di+1)%d.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
      th.pbench{ val x = ix(e(ei)); ei = (ei+1)%e.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
      th.pbench{ val x = ix(f(fi)); fi = (fi+1)%f.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
    }
    
    for (s <- Seq("one", "two", "three")) {
      println(s)
      th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Arrays.sort(x, o); x(x.length/3) }
      th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Arrays.sort(x, o); x(x.length/3) }
      th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Arrays.sort(x, o); x(x.length/3) }
      th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Arrays.sort(x, o); x(x.length/3) }
      th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Arrays.sort(x, o); x(x.length/3) }
      th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Arrays.sort(x, o); x(x.length/3) }
    }
    
    def bx(is: Array[Int]): Array[java.lang.Integer] = {
      val Is = new Array[java.lang.Integer](is.length)
      var i = 0
      while (i < is.length) {
        Is(i) = java.lang.Integer.valueOf(is(i))
        i += 1
      }
      Is
    }
    def xb(Is: Array[java.lang.Integer]): Array[Int] = {
      val is = new Array[Int](Is.length)
      var i = 0
      while (i < is.length) {
        is(i) = Is(i).intValue
        i += 1
      }
      is
    }
    val q = new Comparator[java.lang.Integer]{
      def compare(a: java.lang.Integer, b: java.lang.Integer) = o.compare(a.intValue, b.intValue)
    }
    for (s <- Seq("one", "two", "three")) {
      println(s)
      val tag: ClassTag[Int] = implicitly[ClassTag[Int]]
      th.pbench{ val x = bx(ix(a(ai))); ai = (ai+1)%a.length; Arrays.sort(x, q); xb(x)(x.length/3) }
      th.pbench{ val x = bx(ix(b(bi))); bi = (bi+1)%b.length; Arrays.sort(x, q); xb(x)(x.length/3) }
      th.pbench{ val x = bx(ix(c(ci))); ci = (ci+1)%c.length; Arrays.sort(x, q); xb(x)(x.length/3) }
      th.pbench{ val x = bx(ix(d(di))); di = (di+1)%d.length; Arrays.sort(x, q); xb(x)(x.length/3) }
      th.pbench{ val x = bx(ix(e(ei))); ei = (ei+1)%e.length; Arrays.sort(x, q); xb(x)(x.length/3) }
      th.pbench{ val x = bx(ix(f(fi))); fi = (fi+1)%f.length; Arrays.sort(x, q); xb(x)(x.length/3) }
    }
    ```
Commits on May 7, 2015
  1. Merge pull request #4494 from retronym/backport/bintray

    retronym committed May 7, 2015
    Backport bintray migration fix
  2. [backport] Follow HTTP redirects when downloading bootstrap binaries

    retronym committed May 2, 2015
    After a recent change to the repository that hosts these JARs,
    we now get a HTTP redirect to the new destination. We need to
    explicitly instruct curl to follow this.
    
    (cherry picked from commit c75547f)
Commits on Mar 31, 2015
  1. Merge pull request #4417 from retronym/backport/flaky

    lrytz committed Mar 31, 2015
    [backport] SI-8689 Make a Future test case determistic
  2. [backport] SI-8689 Make a Future test case determistic

    retronym committed Mar 31, 2015
    As discussed:
    
      https://groups.google.com/forum/#!topic/scala-internals/m8I_3GQR4vQ
    
    We need to ensure a happens-before relationship between the callback
    that prints "success" and the end of the main method.
Commits on Mar 5, 2015
  1. Fix link...

    adriaanm committed Mar 5, 2015
  2. 2.10.5 is it for 2.10.x

    adriaanm committed Mar 5, 2015
Commits on Feb 27, 2015
  1. Merge pull request #4365 from adriaanm/2.10.x

    adriaanm committed Feb 27, 2015
    Publish to sonatype staging (the default).
  2. Publish to sonatype staging.

    adriaanm committed Feb 27, 2015
    Simplified while I was at it.
Commits on Feb 26, 2015
  1. Merge pull request #4359 from adriaanm/2.10.x

    gkossakowski committed Feb 26, 2015
    Port old 2.10 release script to new CI.
Commits on Feb 25, 2015
  1. Port old 2.10 release script to new CI.

    adriaanm committed Feb 24, 2015
    To fit in with the new flow, we upload to S3 instead of
    using the copy artifact plugin.
Commits on Feb 23, 2015
  1. Merge pull request #4307 from som-snytt/issue/4339-2.10-b

    gkossakowski committed Feb 23, 2015
    SI-4339 Backpatch event errors and attr fix
Commits on Feb 20, 2015
  1. Merge pull request #4351 from adriaanm/scaladoc-2.10

    adriaanm committed Feb 20, 2015
    Scaladoc js location synch more robust
  2. Scaladoc js location synch more robust

    adriaanm committed Feb 20, 2015
    Tested on:
      - Mac: FF35/Safari 8/Chrome 41
      - Win: IE11
Commits on Feb 16, 2015
  1. [backport] SI-9060 Backpatch fifth-edition names

    som-snytt committed Dec 25, 2014
    Because the compiler and library share some code in this
    version, compiler must exclude xml tags that look like
    Scala operators, such as `<:`.
    
    This is an upstream port of:
    scala-xml/commit/968f7bd94e934c781c19e25847ab09ac98cfbaf6
Commits on Feb 15, 2015
  1. Merge pull request #4289 from retronym/ticket/8689

    gkossakowski committed Feb 15, 2015
    SI-8689 Avoid internal error in Promise after sequence of completions
  2. Merge pull request #4303 from milessabin/topic/backport-7753

    gkossakowski committed Feb 15, 2015
    Backported fix for SI-7753 to 2.10.x.
Commits on Feb 13, 2015
  1. [backport] SI-4339 Event errors and attribute fix

    som-snytt committed Dec 24, 2014
    Improve attribute parsing and propagate errors
    across event thread. Otherwise tests just hang.
    This is tested, right?
    
    This is an upstream port of scala-xml
    5f2cfadeb9e8574ed66f37dc7a7a868eb129a8a9
Commits on Feb 9, 2015
  1. Backported fix for SI-7753 to 2.10.x.

    milessabin committed Feb 9, 2015
Commits on Feb 4, 2015
  1. SI-8689 Avoid internal error in Promise after sequence of completions

    viktorklang committed with retronym Dec 20, 2014
    Calling `completeWith` when the `DefaultPromise` is already completed,
    leads to callbacks not being properly executed.
    
    This happened because `Future.InternalCallbackExecutor` extends
    `BatchingExecutor`[1] which assumes `unbatchedExecute` to be async,
    when in this case it is sync, and if there is an exception thrown
    by executing the batch, it creates a new batch with the remaining
    items from the current batch and submits that to `unbatchedExecute`
    and then rethrows, but if you have a sync `unbatchedExecute`, it will
    fail since it is not reentrant, as witnessed by the failed `require`
    as reported in this issue.
    
    This commit avoids problem by delegating `completeWith` to
    `tryComplete`, which has the effect of using `onComplete` +
    `tryComplete` i.s.o. `complete`, which means that when it fails
    (because of a benign race condition between completers) it won't
    throw an exception.
    
    It has been tested by the minimized reproducer.
    
    [1] Actually, in the 2.10.x branch where this patch is starting out,
        "The BatchingExecutor trait had to be inlined into
        InternalCallbackExecutor for binary compatibility.". This comment
        will be more literally correct in the context of 2.11.x and beyond
  2. Merge pull request #4290 from adriaanm/2.10.x

    retronym committed Feb 4, 2015
    New CI validation scripts
Commits on Feb 3, 2015
  1. New CI validation scripts

    adriaanm committed Feb 3, 2015
    Currently not validating the IDE, pending fix for
    scala-ide/uber-build#48.
    
    The new infrastructure is documented over at:
      - https://github.com/scala/scabot
      - https://github.com/scala/scala-jenkins-infra
      - [jenkins jobs definitions](https://github.com/scala/scala-jenkins-infra/tree/master/templates/default/jobs/validate)
Commits on Dec 8, 2014
  1. Merge pull request #4186 from som-snytt/issue/9027-backport

    gkossakowski committed Dec 8, 2014
    SI-9027 Backport xml parser fix
Commits on Dec 4, 2014
  1. SI-9027 Backport xml parser fix

    som-snytt committed Dec 4, 2014
    Fingers crossed, I have no local java 6 here to test.
    
    No test because no q"" on 2.10.
Commits on Sep 23, 2014
  1. Merge pull request #3998 from retronym/backport/7756

    gkossakowski committed Sep 23, 2014
    [backport] SI-7756 Uncripple refchecks in case bodies
  2. [backport] SI-7756 Uncripple refchecks in case bodies

    retronym committed Aug 16, 2013
    In 65340ed, parts of RefChecks were disabled when
    we traversed into the results of the new pattern matcher.
    Similar logic existed for the old pattern matcher, but in
    that case the Match / CaseDef nodes still existed in the tree.
    
    The new approach was too broad: important checks no longer
    scrutinized the body of cases.
    
    This commit turns the checks back on when it finds the remnants
    of a case body, which appears as an application to a label def.
    
    Conflicts:
    	src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
    
    Cherry pick of 3df1d77
Commits on Sep 11, 2014
  1. Merge pull request #3859 from xeno-by/topic/fundep-materialization-210x

    gkossakowski committed Sep 11, 2014
    [backport] SI-7470 implements fundep materialization
Commits on Sep 9, 2014
  1. -Xfundep-materialization => -Yfundep-materialization

    xeno-by committed Sep 9, 2014
    To quote gkossakowski:
    
      Thinking about it more, could we hide this behind 'Y' flag instead?
      We have lesser obligation to keep around Y flags and this is something
      we should remove from 2.11/2.12.
Commits on Sep 2, 2014
  1. Merge pull request #3937 from som-snytt/issue/8787-doc-backport

    gkossakowski committed Sep 2, 2014
    [backport] SI-8787 Backport Regex doc
Commits on Aug 26, 2014
  1. [backport] SI-8787 Backport Regex doc

    som-snytt committed Aug 21, 2014
    Backport the doc with two material changes:
    
    1. need to use Groups to extract from Match,
    so say that in lieu of the 2.11 advice that
    the Regex instance can be used without
    recomputing the match;
    
    2. and relatedly, in 2.10 there is no secondary
    constructor, so the doc for group names is
    moved back up to the class doc.
    
    Original doc update on PR #3923 was:
    
    0e26910
    
    f98c53c
Commits on Aug 19, 2014
  1. Merge pull request #3865 from xeno-by/topic/extractor-macros-210x

    gkossakowski committed Aug 19, 2014
    [backport] transformers no longer ignore UnApply.fun
  2. Merge pull request #3860 from gourlaysama/wip/t7710-backport

    gkossakowski committed Aug 19, 2014
    [backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
Commits on Aug 12, 2014
  1. [backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+

    gourlaysama committed Apr 28, 2014
    Backport of scala/scala-parser-combinators@91584dc.
    
    ---
    
    Starting with 1.7.0_06 [1], String.substring no longer reuses the internal
    char array of the String but make a copy instead. Since we call
    subSequence twice for *every* input character, this results in horrible
    parse performance and GC.
    
    With the benchmark from the (duplicate) ticket SI-8542, I get:
    
    BEFORE:
        parseAll(new StringReader(String))
        For 100 items: 49 ms
        For 500 items: 97 ms
        For 1000 items: 155 ms
        For 5000 items: 113 ms
        For 10000 items: 188 ms
        For 50000 items: 1437 ms
        ===
        parseAll(String)
        For 100 items: 4 ms
        For 500 items: 67 ms
        For 1000 items: 372 ms
        For 5000 items: 5693 ms
        For 10000 items: 23126 ms
        For 50000 items: 657665 ms
    
    AFTER:
        parseAll(new StringReader(String))
        For 100 items: 43 ms
        For 500 items: 118 ms
        For 1000 items: 217 ms
        For 5000 items: 192 ms
        For 10000 items: 196 ms
        For 50000 items: 1424 ms
        ===
        parseAll(String)
        For 100 items: 2 ms
        For 500 items: 8 ms
        For 1000 items: 16 ms
        For 5000 items: 79 ms
        For 10000 items: 161 ms
        For 50000 items: 636 ms
    
    [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6924259