summaryrefslogtreecommitdiff
path: root/src/library
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Optimize slice and take in ArrayOps, WrappedArray"Adriaan Moors2017-04-032-113/+10
| | | | This reverts commit d540bf01fe4d9e5c56a68b0d3bada9d97af77e3f.
* Revert "Optimised implementation of List.filter/filterNot"Adriaan Moors2017-04-032-106/+0
| | | | This reverts commit eb5c51383a63c5c3420e53ef021607ff5fd20296.
* Revert "Handle WrappedArray the same way as ArrayOps for binary compatibility"Adriaan Moors2017-04-031-23/+21
| | | | This reverts commit f24c2603d0acee5bcb6d5d80bf1e1a4645fa74f0.
* bump copyright year to 2017Philippus Baalman2017-03-021-1/+1
|
* Handle WrappedArray the same way as ArrayOps for binary compatibilityStefan Zeiger2017-02-031-21/+23
| | | | | We introduce a package-private superclass with the overridden implementations. This is public at the bytecode level, so it needs to be whitelisted.
* Optimised implementation of List.filter/filterNotRory Graves2017-01-282-0/+106
|
* Optimize slice and take in ArrayOps, WrappedArrayMike Skells2017-01-282-10/+113
| | | | use Array block copy operations rather than builder/iterator
* Avoid creating ListBuffer in List.mapConserveRory Graves2017-01-281-20/+31
| | | | Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
* Fix the size of the stack used by RedBlackTree.iteratorFrom.Sébastien Doeraene2017-01-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | `s.c.i.RedBlackTree.TreeIterator` uses a stack of nodes that need to be processed later. This stack is implemented as an `Array`, which is allocated with the maximum size that can possibly be used, based on properties of red-black trees. This was added in 72ec0ac869a29fca9ea0d45a3f70f1e9e1babaaf. At the time, there was no `iteratorFrom` method, and as the comment in that commit says, the deepest nodes were never added to the stack, hence the final `- 1` in computing the maximum stack size. However, this changed with the introduction of `iteratorFrom` in 62bc99d3b20a7b37a977b19a6202cdac474eb5f6. The method `startFrom` used to initialize the iterator at the right `start` node does push the deepest nodes in some cases. This internal bug got unnoticed because `pushNext` (originally `pushPath`) has some error recovery in case the stack size got miscalculated. This has performance impacts, though, since an exception is thrown and caught. More importantly, this error recovery mechanism does not work in Scala.js, which considers `ArrayIndexOutOfBoundsException` to be undefined behavior. This commit fixes the stack size computation by simply removing the `- 1` term. To minimize risks on Scala/JVM, the error recovery mechanism is left untouched.
* Merge pull request #5615 from ↵Stefan Zeiger2017-01-092-11/+44
|\ | | | | | | | | monkey-mas/modify-ArrayBuilder-reusability-bug-2016-12-24 [Backport] Modify ArrayBuilder and WrappedArrayBuilder to be reusable
| * [Backport] Modify ArrayBuilder and WrappedArrayBuilder to be reusableMasaru Nomura2016-12-282-11/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As they're reusable in 2.12.x with this change[1], it'd be useful to make them reusable in 2.11.x. [1] https://github.com/scala/scala/commit/6eaae1b969b68ed3dc65a40613a8168b09246256 With this change, not only are they reusable but also we can avoid mutation of previously created arrays. Behaviour(Problem): Actual behaviour before this modification is as follows; <ArrayBuilder> ``` scala> import scala.collection.mutable.ArrayBuilder import scala.collection.mutable.ArrayBuilder scala> val builder = new ArrayBuilder.ofInt builder: scala.collection.mutable.ArrayBuilder.ofInt = ArrayBuilder.ofInt scala> builder ++= Vector.range(1, 17) res0: builder.type = ArrayBuilder.ofInt scala> val arr = builder.result() arr: Array[Int] = Array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) scala> builder.clear() scala> builder += 100 res2: builder.type = ArrayBuilder.ofInt scala> val arr2 = builder.result() arr2: Array[Int] = Array(100) scala> arr res3: Array[Int] = Array(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) // arr should be Array(1, .., 16) but was unexpectedly mutated by `+=` operation ``` `arr` was mutated as follows; 1. `result` & `clear` - `arr = elems` - `size = 0` 2. `+=(100)` - `ensureSize(0 + 1)` => `capacity < size || capacity == 0` is `false` as `capacity == 16` and `size == 1` - `elems(0) = 100` this is where `arr(0) = 100` was done because we did not reallocate a new array for `elems` when calling `ensureSize`, which should have happened. - `size = 1` 3. `result` - `mkArray(1)` gives us `arr2 = Array(100)` <WrappedArrayBuilder> We can observe almost the same mutation behaviour of ArrayBuilder. ``` scala> import scala.collection.mutable.WrappedArray import scala.collection.mutable.WrappedArray scala> import scala.collection.mutable.WrappedArrayBuilder import scala.collection.mutable.WrappedArrayBuilder scala> import scala.reflect.ClassTag import scala.reflect.ClassTag scala> val builder = new WrappedArrayBuilder(ClassTag.Int) builder: scala.collection.mutable.WrappedArrayBuilder[Int] = scala.collection.mutable.WrappedArrayBuilder@56cbfb61 scala> builder ++= Vector.range(1, 17) res0: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61 scala> builder.result() res1: scala.collection.mutable.WrappedArray[Int] = WrappedArray(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) scala> builder.clear() scala> builder += 100 res3: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61 scala> res1 res4: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) scala> builder.result() res5: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100) ``` Solution: We should reset `capacity` to `0` when calling `result` so that `ensureSize(1)` calls `resize(16)`, which satisfies the property of Builder reusability. Besides mutation of previously created arrays does not happen.
* | Simplify HashTable.index furtherPap Lőrinc2017-01-051-6/+2
| | | | | | | | (cherry picked from commit 26c87f1af4cac782911500d6b143681ecdcef8ad)
* | Changed HashMap.getOrElseUpdate to only calculate the index oncePap Lőrinc2017-01-051-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes https://issues.scala-lang.org/browse/SI-10049 Since `groupBy` uses this method extensively and suffered a measurable slowdown in `2.12.0`, this modification restores (and exceeds) its original speed. --- included benchmarks: (`ns/op` → smaller is better) `before (2.12.0):` ```java Benchmark (size) Mode Cnt Score Error Units s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 865.693 ± 7.869 ns/op s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 3095.657 ± 56.438 ns/op s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 28247.005 ± 470.513 ns/op s.c.mutable.HashMapBenchmark.get 10 avgt 20 679.448 ± 11.809 ns/op s.c.mutable.HashMapBenchmark.get 100 avgt 20 7240.178 ± 61.734 ns/op s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95725.127 ± 2373.458 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 836.561 ± 20.085 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 7891.368 ± 56.808 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 97478.629 ± 1782.497 ns/op s.c.mutable.HashMapBenchmark.put 10 avgt 20 243.422 ± 2.915 ns/op s.c.mutable.HashMapBenchmark.put 100 avgt 20 5810.927 ± 60.054 ns/op s.c.mutable.HashMapBenchmark.put 1000 avgt 20 82175.539 ± 1690.296 ns/op ``` `after:` ```java Benchmark (size) Mode Cnt Score Error Units s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 627.007 ± 9.718 ns/op s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2086.955 ± 19.042 ns/op s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 19515.234 ± 173.647 ns/op s.c.mutable.HashMapBenchmark.get 10 avgt 20 683.977 ± 11.843 ns/op s.c.mutable.HashMapBenchmark.get 100 avgt 20 7345.675 ± 41.092 ns/op s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95085.926 ± 1702.997 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 503.208 ± 2.643 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5526.483 ± 28.262 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 69265.900 ± 674.958 ns/op s.c.mutable.HashMapBenchmark.put 10 avgt 20 252.481 ± 7.597 ns/op s.c.mutable.HashMapBenchmark.put 100 avgt 20 5708.034 ± 110.360 ns/op s.c.mutable.HashMapBenchmark.put 1000 avgt 20 82051.378 ± 1432.009 ns/op ``` i.e. for the given benchmark conditions `~40%` faster `groupBy` and `getOrElseUpdate` (cherry picked from commit b67ca7dc6bb84758f9c9f64d68b0b11c20995aa0)
* | Changed hashing bit rotation to use Integer.rotateRightPap Lőrinc2017-01-052-19/+8
| | | | | | | | (cherry picked from commit bc912230129d68466474bcc6c99356b44f65c3c2)
* | Changed modulo to bitwise AND in hash calculationPap Lőrinc2017-01-051-52/+17
| | | | | | | | (cherry picked from commit 7952525e7119282ec8308a0076db54923f95dc21)
* | Optimized HashTable.indexPap Lőrinc2017-01-051-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (`ops/s`, smaller is better) `Before (9c5d3f8)`: ```scala [info] # Run complete. Total time: 00:08:15 [info] [info] Benchmark (size) Mode Cnt Score Error Units [info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 645.594 ± 9.435 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2084.216 ± 37.814 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 19878.481 ± 262.404 ns/op [info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 689.941 ± 5.850 ns/op [info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7357.330 ± 45.956 ns/op [info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95767.200 ± 1550.771 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 509.181 ± 2.683 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5563.301 ± 32.335 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 71965.365 ± 1809.738 ns/op [info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 247.270 ± 3.972 ns/op [info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5646.185 ± 106.172 ns/op [info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 81303.663 ± 954.938 ns/op ``` `Changed modulo to bitwise and in hash calculation (4c729fe)`: ```scala [info] Benchmark (size) Mode Cnt Score Error Units [info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 631.291 ± 9.269 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2077.885 ± 59.737 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 15458.278 ± 317.347 ns/op [info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 678.013 ± 4.453 ns/op [info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7258.522 ± 76.088 ns/op [info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 94748.845 ± 1226.120 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 498.042 ± 5.006 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5243.154 ± 110.372 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 68194.752 ± 655.436 ns/op [info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 257.275 ± 1.411 ns/op [info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5318.532 ± 152.923 ns/op [info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 79607.160 ± 651.779 ns/op ``` `Optimized HashTable.index (6cc1504)`: ```scala [info] Benchmark (size) Mode Cnt Score Error Units [info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 616.164 ± 4.712 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2034.447 ± 14.495 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 14712.164 ± 119.983 ns/op [info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 679.046 ± 6.872 ns/op [info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7242.097 ± 41.244 ns/op [info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95342.919 ± 1521.328 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 488.034 ± 4.554 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 4883.123 ± 59.268 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 65174.034 ± 496.759 ns/op [info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 267.983 ± 1.797 ns/op [info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5097.351 ± 104.538 ns/op [info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 78772.540 ± 543.935 ns/op ``` Summary, i.e. the effect of this PR, according to the benchmarks: * `groupBy` has a `~35%` speedup * `get` didn't change * `getOrElseUpdate` has a `~10%` speedup * `put` has a `~3%` speedup Note: caching the `exponent` to a local private field (`Byte` or `Int`) didn't have any performance advantage (only a minor slowdown was measured, possibly because it's accessed via an interface now) (cherry picked from commit a5014447861a5678c8b595e235019bb8fec098a7)
* | SI-8774 Null link fields in mutable hash maps on removal.Carsten Varming2017-01-053-1/+8
| | | | | | | | (cherry picked from commit 9a2486087a9739108265e7830ebaa96373605d02)
* | Fix documentation of immutable.QueueJasper-M2017-01-031-1/+1
|/ | | `enqueue` appends elements to the `Queue`, it doesn't prepend them.
* SI-10086 NumericRange.min|max with custom Integral (#5575)Tobias Schlatter2016-12-121-2/+7
| | | SI-10086 NumericRange.min|max with custom Integral
* Merge pull request #5378 from som-snytt/issue/9913Seth Tisue2016-10-261-13/+10
|\ | | | | SI-9913 Lead span iterator finishes at state -1
| * SI-9913 Tighten bolts on span iteratorSom Snytt2016-09-061-13/+10
| | | | | | | | | | Extra privacy, and the tricky state transition is made more tabular.
| * SI-9913 Lead span iterator finishes at state -1Som Snytt2016-09-051-1/+1
| | | | | | | | | | Even if no elements fail the predicate (so that the trailing iterator is empty).
* | Merge pull request #5239 from martijnhoekstra/doc_capitalizeAdriaan Moors2016-10-181-0/+1
|\ \ | | | | | | Doc: capitalize doesn't handle non-BMP characters
| * | doc: capitalize only works on BMP charactersMartijn Hoekstra2016-06-211-0/+1
| |/
* / In ProcessBuilder docs, replace .lines w/ .lineStreamPaul Kernfeld2016-09-162-9/+9
|/ | | | ProcessBuilder.lines is deprecated
* SI-9737 [no-merge] Backport stringOf ParIterableNicolas Stucki2016-06-031-2/+2
| | | | | | | | | | | | | | Cherry-picked c5f3d3f286ee5c26c8ddcf10f6878058e8f7e040 Edited comment: in stringOf, let GenIterable subsume both Iterable and ParIterable. This change is required for Scala.js compatibility as it does not support parallel collections. Conflicts: src/library/scala/runtime/ScalaRunTime.scala
* SI-9789 use quadratic probing in OpenHashMapPerformant Data LLC2016-05-261-12/+6
| | | | | | | | | | | | The original probe sequence, taken from Python's hash table code, is exponential, jumping around in the hash table with poor memory locality. This replaces the probe algorithm with the more conventional quadratic probing. This also adds tests to the benchmarking code using AnyRef keys, which have pseudorandom hash codes (unlike Ints, whose hash code is simply the Int itself). The intensity of the benchmarking is reduced to make the tests complete within 9 hours, by removing unnecessary sampling.
* Merge pull request #5167 from martijnhoekstra/SI-9766Lukas Rytz2016-05-231-1/+2
|\ | | | | SI 9766 - allow ++ on empty ConcatIterator
| * SI-9766 - allow ++ on empty ConcatIteratorMartijn Hoekstra2016-05-211-1/+2
| |
* | SI-9688 Make merge in immutable HashMap1 work with null kv.Łukasz Gieroń2016-05-231-1/+1
|/ | | | | | | | The kv field of scala.collection.immutable.HashMap.HashMap1 can be null. This commit corrects the behavior of updated0 (which is on call path for merged) to work in such cases, instead of throwing NPE. Commit contains regression test.
* SI-9488 - adds the same default toString format to Scala Futures as 2.12.xViktor Klang2016-03-221-0/+4
| | | | Includes tests to verify the toString representations.
* Merge pull request #4994 from dk14/patch-1Seth Tisue2016-03-041-1/+1
|\ | | | | explicitly specify insertion-order feature in docs
| * explicitly specify insertion-order feature in docsdk142016-02-231-1/+1
| |
* | fix smhasher urlxuwei-k2016-02-152-2/+2
| | | | | | | | | | google code is dead http://google-opensource.blogspot.jp/2015/03/farewell-to-google-code.html
* | Fix off-by-one documentation error in Product<N>Janek Bogucki2016-02-1122-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sanity check: scala> case class P2(i: Int, j: Int) defined class P2 val p2 = P2(1, 3) p2.productElement(0) res0: Any = 1 p2.productElement(1) res1: Any = 3 p2.productElement(2) java.lang.IndexOutOfBoundsException: 2 at P2.productElement(<console>:10)
* | Merge pull request #4939 from szeiger/issue/9624Lukas Rytz2016-02-103-15/+25
|\ \ | | | | | | SI-9624 Improve documentation for TraversableOnce
| * | SI-9624 Improve documentation for TraversableOnceStefan Zeiger2016-02-043-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | - Move the doc comment for `hasDefiniteSize` up from TraversableLike to GenTraversableOnce and improve it. - Add a note to `GenTraversableOnce.isEmpty` that implementations must not consume elements. - Clarify alternatives to subclassing TraversableOnce.
* | | Merge pull request #4937 from szeiger/issue/9623-2.11Seth Tisue2016-02-081-6/+45
|\ \ \ | | | | | | | | SI-9623 Avoid unnecessary hasNext calls in JoinIterator & ConcatIterator
| * | | SI-9623 Avoid unnecessary hasNext calls in JoinIterator & ConcatIteratorStefan Zeiger2016-02-011-6/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These iterator implementations are used to concatenate two (JoinIterator) or more (ConcatIterator) other iterators with `++`. They used to perform many unnecessary calls to the child iterators’ `hasNext` methods. This improved state machine-based implementation reduces that number to the bare minimum, i.e. iterating over concatenated iterators with `foreach` calls the children's `hasNext` methods a total of (number of children) + (number of elements) times, the same as when iterating over all children separately.
* | | | bump copyright year to 2016Seth Tisue2016-02-031-1/+1
| |/ / |/| |
* | | SI-9534 Use BoxedUnit in all cases for creating Array[Unit]Stefan Zeiger2016-01-271-0/+3
|/ / | | | | | | | | | | | | | | Calling `wrap` or one of the higher-dimension Array factory methods on the `Manifest` for `Unit` led to an exception because it tried to use `void` as a primitive type. Unlike all other primitive Scala types, `Unit` needs to be boxed. The basic `newArray` method was not affected by this bug because it was already special-cased. The fix is to also special-case `arrayClass`.
* | Link 'Future' scaladoc to 'Futures and Promises'Arnout Engelen2016-01-251-0/+2
| |
* | Merge pull request #4886 from janekdb/2.11.x-scaladoc-Duration-linksSeth Tisue2016-01-141-2/+2
|\ \ | | | | | | Fix Scaladoc overloaded method link to Duration companion object
| * | Fix Scaladoc overloaded method link to Duration companion objectJanek Bogucki2016-01-041-2/+2
| | | | | | | | | | | | | | | | | | The links were being skipped with a warning before this commit. The key change was to remove the result type and add an asterisk.
* | | Merge pull request #4902 from ruippeixotog/issue/9605Seth Tisue2016-01-131-6/+6
|\ \ \ | | | | | | | | SI-9605 Searching does not use binary search for Array
| * | | SI-9605 Searching does not use binary search for ArrayRui Gonçalves2016-01-121-6/+6
| |/ / | | | | | | | | | Binary search should be used for every `IndexedSeqLike` instance and not only for `IndexedSeq`. According the Scaladoc, it is `IndexedSeqLike` that guarantees "constant-time or near constant-time element access and length computation".
* / / SI-8641 Fix right shift docs for integer typesLinas Medziunas2016-01-035-20/+20
|/ / | | | | | | | | Docs for >> operation of integer types (from Byte to Long) had a wrong direction saying that it is bit-shift left.
* | Merge pull request #4882 from janekdb/2.11.x-scaladoc-tables-1Lukas Rytz2015-12-182-6/+11
|\ \ | | | | | | Document JavaConverters conversion from java.util.Properties to Map
| * | Document JavaConverters conversion from java.util.Properties to MapJanek Bogucki2015-12-122-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | Also - Fix grammar on duplicated DecorateAsJava comment by copying over from JavaConverters - Remove author tags
* | | Merge pull request #4831 from martijnhoekstra/patch-4Seth Tisue2015-12-171-0/+12
|\ \ \ | | | | | | | | add doc for log, sqrt
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-02 20:02:21 +0000