| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
SI-10086 NumericRange.min|max with custom Integral
|
| |
|
|
|
|
|
|
|
|
| |
terminalElement (the element _after_ the last one!) was used to terminate foreach loops and sums of non-standard instances of Numeric. Unfortunately, this could result in the end wrapping around and hitting the beginning again, making the first element bad.
This patch fixes the behavior by altering the loop to end after the last element is encountered. The particular flavor was chosen out of a few possibilities because it gave the best microbenchmarks on both large and small ranges.
Test written. While testing, a bug was also uncovered in NumericRange, and was also fixed. In brief, the logic around sum is rather complex since division is not unique when you have overflow. Floating point has its own complexities, too.
Also updated incorrect test t4658 that insisted on incorrect answers (?!) and added logic to make sure it at least stays self-consistent, and fixed the range.scala test which used the same wrong (overflow-prone) formula that the Range collection did.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Int.MaxValue
Fixed by rewriting the entire logic for the count method. This is necessary because the old code was making all kinds of assumptions about what numbers were, but the interface is completely generic.
Those assumptions still made have been explicitly specified. Note that you have to make some or you end up doing a binary search, which is not exactly fast.
The existing routine is 10-20% slower than the old (broken) one in the worst cases. This seems close enough to me to not bother special-casing Long and BigInt, though I note that this could be done for improved performance.
Note that ranges that end up in Int ranges defer to Range for count. We can't assume that one is the smallest increment, so both endpoints and the step need to be Int.
A new JUnit test has been added to verify that the test works. It secretly contains an alternate BigInt implementation, but that is a lot slower (>5x) than Long.
|
| |
|
|
|
|
|
|
| |
Previously both Range and NumeriRange used formula for sum of elements
of arithmetic series and thus always assumed that provided Numeric is
regular one.
Bug is now fixed by conservatively checking if Numeric is one of
default ones and the formula still holds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
unmoored doc comment" warning when building distribution for
scala itself.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'refs/pull/1574/head': (24 commits)
Fixing issue where OSGi bundles weren't getting used for distribution.
Fixes example in Type.asSeenFrom
Fix for SI-6600, regression with ScalaNumber.
SI-6562 Fix crash with class nested in @inline method
Brings copyrights in Scaladoc footer and manpage up-to-date, from 2011/12 to 2013
Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013
SI-6606 Drops new icons in, replaces abstract types placeholder icons
SI-6132 Revisited, cleaned-up, links fixed, spelling errors fixed, rewordings
Labeling scala.reflect and scala.reflect.macros experimental in the API docs
Typo-fix in scala.concurrent.Future, thanks to @pavelpavlov
Remove implementation details from Position (they are still under reflection.internal). It probably needs more cleanup of the api wrt to ranges etc but let's leave it for later
SI-6399 Adds API docs for Any and AnyVal
Removing actors-migration from main repository so it can live on elsewhere.
Fix for SI-6597, implicit case class crasher.
SI-6578 Harden against synthetics being added more than once.
SI-6556 no assert for surprising ctor result type
Removing actors-migration from main repository so it can live on elsewhere.
Fixes SI-6500 by making erasure more regular.
Modification to SI-6534 patch.
Fixes SI-6559 - StringContext not using passed in escape function.
...
Conflicts:
src/actors-migration/scala/actors/migration/StashingActor.scala
src/compiler/scala/tools/nsc/backend/jvm/GenASM.scala
src/compiler/scala/tools/nsc/settings/AestheticSettings.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/library/scala/Application.scala
src/library/scala/collection/immutable/GenIterable.scala.disabled
src/library/scala/collection/immutable/GenMap.scala.disabled
src/library/scala/collection/immutable/GenSeq.scala.disabled
src/library/scala/collection/immutable/GenSet.scala.disabled
src/library/scala/collection/immutable/GenTraversable.scala.disabled
src/library/scala/collection/mutable/GenIterable.scala.disabled
src/library/scala/collection/mutable/GenMap.scala.disabled
src/library/scala/collection/mutable/GenSeq.scala.disabled
src/library/scala/collection/mutable/GenSet.scala.disabled
src/library/scala/collection/mutable/GenTraversable.scala.disabled
src/library/scala/collection/parallel/immutable/ParNumericRange.scala.disabled
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
That's a lot of unused code. Most of this is pure cruft; a small
amount is debugging code which somebody might want to keep around,
but we should not be using trunk as a repository of our personal
snippets of undocumented, unused, unintegrated debugging code. So
let's make the easy decision to err in the removing direction.
If it isn't built to last, it shouldn't be checked into master.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the very small price of annotating types as Any/AnyVal in those
cases where we wish to use them, we can obtain useful warnings.
I made trunk clean against this warning and found several bugs
or at least suboptimalities in the process.
I put the warning behind -Xlint for the moment, but I think this
belongs on by default, even for this alone:
scala> List(1, 2, 3) contains "a"
<console>:8: warning: a type was inferred to be `Any`; this may indicate a programming error.
List(1, 2, 3) contains "a"
^
res0: Boolean = false
Or this punishment meted out by SI-4042:
scala> 1l to 5l contains 5
<console>:8: warning: a type was inferred to be `AnyVal`; this may indicate a programming error.
1l to 5l contains 5
^
res0: Boolean = false
A different situation where this arises, which I have seen variations
of many times:
scala> class A[T](default: T) {
def get(x: => Option[T]) = x getOrElse Some(default)
}
<console>:7: warning: a type was inferred to be `Any`; this may indicate a programming error.
class A[T](default: T) { def get(x: => Option[T]) = x getOrElse Some(default) }
^
// Oops, this was what I meant
scala> class A[T](default: T) {
def get(x: => Option[T]) = x getOrElse default
}
defined class A
Harder to avoid spurious warnings when "Object" is inferred.
|
| |
|
|
|
|
|
|
| |
Override `min` and `max` in `Range` and `NumericRange`
to check if a default `Ordering` for the numeric type
in question is used.
If so, bypass traversal and compute the minimum or
maximum element.
|
| |
|
|
|
|
|
|
|
|
| |
- Replaced/simplified usages of "wrt".
- Added backticks to $Coll definitions, so stuff like "immutable.Stack"
hopefully stops being interpreted as the end of a sentence and shown
like that in the summary line of ScalaDoc's method description.
See collection.immutable.Stack's sortBy.
Additionally, it looks nicer this way.
- Fixes the typo mentioned in SI-5666.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It makes me a bit nervous that NumericRange[Int] will
get different wrong values in overflow situations compared
to Range due to the missing toLong though.
It could probably need some investigation if reordering the
operations can rule out wrong values, e. g. only fail when
the fold also fails.
Apart from that, it might make sense to just throw an exception
if an overflow happens instead of silent overflow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit and the two subsequent commits were contributed by:
Todd Vierling <tv@duh.org>.
I combined some commits and mangled his commit messages, but all the
credit is his. This pursues the same approach to classfile reduction
seen in r19989 when AbstractFunctionN was introduced, but applies it to
the collections. Thanks to -Xlint it's easy to verify that the private
types don't escape.
Design considerations as articulated by Todd:
* Don't necessarily create concrete types for _everything_. Where a
subtrait only provides a few additional methods, don't bother; instead,
use the supertrait's concrete class and retain the "with". For example,
"extends AbstractSeq[A] with LinearSeq[A]".
* Examine all classes with .class file size greater than 10k. Named
classes and class names ending in $$anon$<num> are candidates for
analysis.
* If a return type is currently inferred where an anon subclass would be
returned, make the return type explicit. Don't allow the library-private
abstract classes to leak into the public namespace [and scaladoc].
|
| |
|
|
|
| |
Contributed by Thomas Switzer. Closes SI-4985, no review.
|
| | |
|
| |
|
|
|
|
|
| |
infix implicits to Integral and Fractional. As a bonus this patch
knocked 10,000 long boxings off a specialized test. Who knew. Closes
#4308, #4321, review by community.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
| |
Adding special take and drop for numeric ranges, and a test. Parallel
numeric ranges are added, but currently disabled.
Review by extempore.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deprecated the @serializable annotation, introduce a new trait
"scala.Serializable" which has to be extended instead (cross-platform).
Known issues:
- Companion objects of serializable classes (including case classes) are automatically made serializable. However, they don't extend "Serializable" statically because of the known difficulty (should be done before typing, but hard).
- Writing "case class C() extends Serializable" gives "error: trait Serializable is inherited twice"
- Functions are serializable, but don't extend Serializable dynamically (could be fixed by making FunctionN Serializable - shouldn't we?)
Note that @SerialVersionUID continues to be an annotation; it generates
a static field, which is not possible otherwise in scala.
Review by dragos, extempore.
Question to dragos: in JavaPlatform.isMaybeBoxed, why is there a test
for "JavaSerializableClass"? Is that correct?
|
| |
|
|
|
|
|
|
|
|
| |
Achieved similar simplicity gains in NumericRange to those now in Range.
Obvious remaining task is to specialize NumericRange and after verifying
the performance, eliminate one or the other. For now, both soldier
onward despite near-convergence of implementation.
Closes #3232, no review.
|
| |
|
|
|
|
|
| |
ran across some tortured logic trying to accomodate the long abandoned
idea of having 5 != 5L, so simplified the contains method. Closes #3518,
no review.
|
| |
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| | |
|
| |
|
|
|
|
| |
Changes to docs of collections in the `immutable` package. Review by
odersky.
|
| | |
|
| |
|
|
|
| |
lost of documentation and some small adjustments to collection classes.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
object, updating some @deprecated messages to give realistic
alternatives, properly resolving the semantic mismatch between List.--
and diff, its once-recommended but inequivalent alternative.
|
| |
|
|
|
| |
Some @experimental cleanups/removals I missed on the last pass.
|
|
|
- Renames GenericRange to NumericRange
- Removes most @experimental annotations
|
