| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
So that osgi version is set correctly by build.
|
|\
| |
| | |
Clean implementation of sorts for scala.util.Sorting.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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) }
}
```
|
|\
| |
| | |
Backport bintray migration fix
|
|/
|
|
|
|
|
|
| |
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 c75547f342e7795e9cd7d23d5d6c4c44c179d21b)
|
|\
| |
| | |
[backport] SI-8689 Make a Future test case determistic
|
|/
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\
| |
| | |
Publish to sonatype staging (the default).
|
|/
|
|
| |
Simplified while I was at it.
|
|\
| |
| | |
Port old 2.10 release script to new CI.
|
|/
|
|
|
| |
To fit in with the new flow, we upload to S3 instead of
using the copy artifact plugin.
|
|\
| |
| | |
SI-4339 Backpatch event errors and attr fix
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| | |
| | | |
Scaladoc js location synch more robust
|
|/ /
| |
| |
| |
| |
| | |
Tested on:
- Mac: FF35/Safari 8/Chrome 41
- Win: IE11
|
|\ \
| | |
| | | |
SI-8689 Avoid internal error in Promise after sequence of completions
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/| |
Backported fix for SI-7753 to 2.10.x.
|
|/ |
|
|\
| |
| | |
New CI validation scripts
|
|/
|
|
|
|
|
|
|
|
| |
Currently not validating the IDE, pending fix for
https://github.com/scala-ide/uber-build/issues/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)
|
|\
| |
| | |
SI-9027 Backport xml parser fix
|
|/
|
|
|
|
| |
Fingers crossed, I have no local java 6 here to test.
No test because no q"" on 2.10.
|
|\
| |
| | |
[backport] SI-7756 Uncripple refchecks in case bodies
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 65340ed4ad2e, 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 3df1d77fc984b976efa68098206e801cf3b83a9e
|
|\ \
| | |
| | | |
[backport] SI-7470 implements fundep materialization
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Backports 21a8c6c from the 2.11.x branch under -Xfundep-materialization
as per Miles Sabin's request. Thanks Miles!
|
|\ \ \
| | | |
| | | | |
[backport] SI-8787 Backport Regex doc
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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:
0e26910372d349c6ff7bbaa17fc8fe0bf568c5fe
f98c53cb03f800b3d790f3866ab90f827fd131f5
|
|\ \ \
| | | |
| | | | |
[backport] transformers no longer ignore UnApply.fun
|
| |/ /
| | |
| | |
| | | |
Backports 7122560063 and 4133eb8454 from the 2.11.x branch
|
|\ \ \
| | | |
| | | | |
[backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| | | |
| | | | |
Prevent SI-8314 by adding a test
|
|/ / /
| | |
| | |
| | | |
The original issue was fixed already. This test is just for make sure.
|
|\ \ \
| |/ /
|/| | |
SI-8589 Performance improvement for ArrayCharSequence.toString
|
|/ / |
|
|\ \
| | |
| | | |
SI-8596 Fix rangepos crasher with defaults, poly methods
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Regressed in SI-7915 / 3009a525b5
We should be deriving the position of the synthetic `Select`
from `basefun1`, rather than `basefun`. In the new, enclosed
test, the difference amounts to:
new Container().typeParamAndDefaultArg[Any]()
`------------ basefun1 --------------'
`----------------- basefun ---------------'
For monomorphic methods, these are one and the same, which is
why `presentation/t7915` was working. I've extended that test
to a polymorphic method to check that hyperlink resolution works.
|
|\ \
| | |
| | | |
SI-8479 Fix constructor default args under scaladoc
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `DocDef` node hid the `DefDef` constructor from the scrutinee
of the namer when determining if the class had constructor defaults
or not.
The current pattern for fixing these bugs is to delegate the check
to `TreeInfo`, and account for the wrapper `DocDef` node. I've
followed that pattern, but expressed my feelings about this approach
in a TODO comment.
Before this patch, the enclosed test failed with:
error: not enough arguments for constructor SparkContext: (master: String, appName: String)SparkContext
|
|\ \
| | |
| | | |
SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
And update the java `ClassFileParser` to create distinguished
`StubClassSymbol`s, rather that a regular `ClassSymbol`s, when
encountering a deficient classpath. This brings it into line
with `Unpickler`, which has done as much since a55788e275f.
This stops the enclosed test case from crashing when determining
if the absent symbol, `A_1`, is a subclass of `@deprecated`.
This is ostensibly fixes a regression, although it only worked in
`2.10.[0-3]` by a fluke: the class file parser's promiscious
exception handling caught and recovered from the NPE introduced
in SI-7439!
% javac -d /tmp test/files/run/t8442/{A,B}_1.java && qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala
warning: Class A_1 not found - continuing with a stub.
warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class
two warnings found
|
|\ \
| | |
| | | |
[nomaster] backports 609047ba37
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.
This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.
(cherry picked from commit 609047ba372ceaf06916d3361954bc949a6906ee)
|