| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Looks like another java5/java6 difference gets me on a test. At least
this time I was looking for that. No review.
|
| |
|
|
|
|
| |
Expanding the test which tries to use the collections from java. No
review.
|
| |
|
|
|
|
|
| |
Added some implicitNotFound annotations to commonly used classes, and
some documentation to Manifest. (Said documentation is invisible for the
moment due to #4404.) No review.
|
| |
|
|
|
|
|
|
| |
Learned an interesting lesson about having an implicit object with a
"def apply(x: Any): List[String]" method imported into power mode. Let's
just say this is not advised. This and other rough edges eliminated from
power mode, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for linked lists closes #4080 and proves my desire not to ship
obviously broken code is even greater than my will to hold out for any
help. I threw in a free fix for this which I noticed while in there.
scala> scala.collection.mutable.LinkedList[Int]().head
res0: Int = 0
Also was reminded how useless tests can be:
val ten = DoubleLinkedList(1 to 10: _*)
ten.insert(DoubleLinkedList(11))
// Post-insert position test
require(ten.last == 11)
Fortunately a test confirming buggy behavior still serves a purpose by
breaking when you fix the bug which allowed it to pass, thus letting you
fix the broken test too. Life's (very) little compensations. Linked list
code should still be presumed broken. No review.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I guess windows can show a < 500x difference and still give us
confidence there isn't a 100,000x difference. Testing situation
continues to confound and amaze. Trying to make 4279 not fail on
windows, one more time and I will delete it and burn the bodies. No
review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Added a temporary fix for #4351, but disabled it because the extend
specialized class with nonspecialized type-parameters is used in the
stdlib already.
Disabling scala.parallel package, adding the currently disabled
scala.concurrent package which will be implemented in some of the next
releases.
Review by phaller.
|
| |
|
|
|
|
|
|
| |
Moved failing tests to pending after having diagnosed that the only
problem is a difference in output between Java 1.5 and 1.6 reflection
libraries. Can we moved back once that's fixed. For now, it's more
important to ghet the build back.
|
| |
|
|
|
|
| |
Changed App-using tests to use main() to see if that's our trouble. No
review.
|
| |
|
|
|
| |
Looks like I accidentally committed a test log, no review.
|
| |
|
|
|
|
| |
Restoring my higher-kinded-Array signature check which martin callously
blew away while fixing all our other problems. Review by odersky.
|
| |
|
|
|
|
| |
Spiced up the signature test infrastructure a bunch, wrote some more
tests, restored the tests in pending. No review.
|
| |
|
|
|
|
| |
Moving signature tests to pending, because they operate under wrong
assumptions now that mixed in members are bridges. Review by extempore.
|
| |
|
|
|
|
| |
Simple test case to see whether Java understands mixed in signatures.
This should be extended with more cases. Review by extempore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
My early attempts to implement non-integral ranges in a way which was
useful without having lots of floating point traps were less than
successful. One of the bigger backfires is that the requirement not to
round (trying, and failing anyway, to avoid surprises with methods like
"contains") inflicts runtime errors.
The simple way to improve this, which seems a good idea anyway, is to
make the default math context something less inclined to exceptions.
Default BigDecimal mc is now DECIMAL128. References #1812, #4201 and
puts #4201 back to normal priority. Review by community.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Implementing foreach to work in parallel in ParIterableLike.
Doing a bunch of refactoring around in the collection framework to
ensure a parallel foreach is never called with a side-effecting method.
This still leaves other parts of the standard library and the compiler
unguarded.
No review.
|
| | |
|
| |
|
|
|
|
| |
closes #4205: quick&dirty fix to force loading of info's and thus avoid
order-dependency until we fix unsafeTypeParams for good. no review
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Not yet learned my lesson about partest and empty directories. Rather
than reapply that bandaid, went after partest. Attempts to make partest
ignore empty directories. Discover directory tests aren't run when the
command line tool is used, make them run like everyone else. Find more
tests which due to misplacement are silently ignored, move them into
tested locations. No review.
|
| |
|
|
|
|
|
| |
Oh the irony, disabling the failing test made the build fail, because
another test is hardcoded to use its paths. Disabled that test too.
We'll put humpty back together again. No review.
|
| |
|
|
|
|
| |
We need a successful build, not sure why this hasn't been disabled yet.
Disabled failing coder test, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[I'm laptop only so there's some chance this will incur temporary
breakage, but it needs committing.]
Heading off gratuitous complications which haven't yet shipped, I
eliminated the -jar startup option in favor of doing what we already do,
figuring it out. So now all these things work.
scala foo/bar.scala // if file is a script or has one main method
scala foo.Bar // if it has a legal main method scala foo.jar // if it
has a legal MainClass attribute
Also changed "-savecompiled" to "-save" and given scala source called
foo.scala, generate foo.jar rather than foo.scala.jar. Cleaned up a
bunch of related code and further polished the scala startup message.
And unbroke choice settings and improved that error too, which closes
#3849.
While trying to write a test for the choice setting, was reminded that
partest just discards invalid flags files. Made it fail instead, which
closes #3712. Fixed the new failures that revealed. No review.
|
| |
|
|
|
|
| |
One hundred! One hundred times slower on windows! Ah, ha, ha! Adjusted
test case, no review.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
[scaladoc] Add HtmlFactoryTest and reorganize directory structure.
Reviewed by pedrofurla.
|
| |
|
|
|
| |
no review.
|
| |
|
|
|
|
|
| |
Fix for a big bug in lastIndexOfSlice and some latent negative index
bugs in both that and indexOfSlice. This stuff is taxing. Closes #4348,
no review.
|
| | |
|
| |
|
|
|
|
|
| |
I'm going to assume the patch I dropped off five months ago for #3938
was merely overlooked. Fixes an issue with java types which extend inner
classes. Closes #3938, review by odersky.
|
| |
|
|
|
|
|
| |
Prevent a divergent implicit from terminating implicit search, so that
there can still be a winner, as endorsed by martin over a cheese plate.
Closes #3883, review by dmharrah.
|
| |
|
|
|
| |
extempore. References #4305, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Removed long deprecated and obscure CloneableCollection. Discovered
we have a scala.collection.mutable.Cloneable which does not extend
java.lang.Cloneable, which is why Array is not considered cloneable.
That seems wrong, but to be conservative I gave Array the Cloneable
interface without altering the scala trait.
Also, if @serializable is deprecated in favor of Serializable,
should not @cloneable be deprecated analogously? Closes #4307, and a
commit-question review by rytz.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removing toPar* methods, since we've agreed they're difficult to: -
underestand - maintain
Also, changed the docs and some tests appropriately.
Description:
1) Every collection is now parallelizable - switch to the parallel version of the collection is done via `par`.
- Traversable collections and iterators have `par` return a parallel
- collection of type `ParIterable[A]` with the implementation being the
- representative of `ParIterable`s (currently, `ParArray`). Iterable
- collections do the same thing. Sequences refine `par`'s returns type
- to `ParSeq[A]`. Maps and sets do a similar thing.
The above means that the contract for `par` changed - it is no longer guaranteed to be O(1), nor reflect the same underlying data, as was the case for mutable collections before. Method `par` is now at worst linear.
Furthermore, specific collection implementations override `par` to a more efficient alternative - instead of copying the dataset, the dataset is shared between the old and the new version. Implementation complexity may be sublinear or constant in these cases, and the underlying data structure may be shared. Currently, these data structures include parallel arrays, maps and sets, vectors, hash trie maps and sets, and ranges.
Finally, parallel collections implement `par` trivially.
2) Methods `toMap`, `toSet`, `toSeq` and `toIterable` have been refined
for parallel collections to switch between collection types, however,
they never switch an implementation from parallel to sequential. They
may or may not copy the elements, as is the case with sequential
variants of these methods.
3) The preferred way to switch between different collection types,
whether maps, sets and seqs, or parallel and sequential, is now via use
of methods `toIterable`, `toSeq`, `toSet` and `toMap` in combination
with `par` and `seq`.
Review by odersky.
|
| | |
|
| |
|
|
|
| |
Disabled test not actually doing anything anyway, no review.
|
| |
|
|
|
| |
Reenabled the commented out bits of the test for #1642. No review.
|
| |
|
|
|
|
|
|
|
| |
Always forget that checking system properties causes exceptions in
applets and such. Made the system property wrapper wrap its access
checks in some more wrapping. I spent a long time trying to write a
test for the security manager but it's hopeless without knowing all the
details of the test environment. Closes #4346, no review.
|
| |
|
|
|
|
|
|
|
|
|
| |
warnings due to my changing a map from mutable to immutable (which
ought to be the good direction) because "def update" still lingers on
immutable maps. I counted the days elapsed since it was marked for death
(before 2.8.0) and added in the bugliness of what I was looking at and
bid it farewell.
Now removed: def update on immutable maps. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Leveraged having a place to put some useful implicits which we sensibly
are reluctant to introduce in the default scope. The test case pretty
much sums it up.
import Ordering.Implicits._
import Numeric.Implicits._
def f1[T: Numeric](x: T, y: T, z: T) = x + y + z
def f2[T: Ordering](x: T, y: T, z: T) = if (x < y) (z > y) else (x < z)
No review.
|
| | |
|
| |
|
|
|
| |
Slight tweak to case class deprecation message, no review.
|
