+
-
+
diff --git a/_online_courses/big-data-analysis-with-scala-and-spark.md b/_online_courses/big-data-analysis-with-scala-and-spark.md
index 15ed0cb8e..e09ab28e3 100644
--- a/_online_courses/big-data-analysis-with-scala-and-spark.md
+++ b/_online_courses/big-data-analysis-with-scala-and-spark.md
@@ -17,4 +17,4 @@ Learning Outcomes. By the end of this course you will be able to:
- express algorithms for data analysis in a functional style,
- recognize how to avoid shuffles and recomputation in Spark,
-Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, Javascript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Parallel Programming: https://www.coursera.org/learn/parprog1.
+Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, JavaScript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Parallel Programming: https://www.coursera.org/learn/parprog1.
diff --git a/_online_courses/functional_program_design_in_scala.md b/_online_courses/functional_program_design_in_scala.md
index e153931f7..49705f5d1 100644
--- a/_online_courses/functional_program_design_in_scala.md
+++ b/_online_courses/functional_program_design_in_scala.md
@@ -21,4 +21,4 @@ Learning Outcomes. By the end of this course you will be able to:
functions and state,
- write simple functional reactive applications.
-Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, Javascript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Functional Programming Principles in Scala: https://www.coursera.org/learn/scala-functional-programming.
+Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, JavaScript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Functional Programming Principles in Scala: https://www.coursera.org/learn/scala-functional-programming.
diff --git a/_online_courses/functional_programming_principles_scala.md b/_online_courses/functional_programming_principles_scala.md
index 44960110c..c6b0f2601 100644
--- a/_online_courses/functional_programming_principles_scala.md
+++ b/_online_courses/functional_programming_principles_scala.md
@@ -8,7 +8,7 @@ paid: false
showDate: false
---
-Functional programming is becoming increasingly widespread in industry. This trend is driven by the adoption of Scala as the main programming language for many applications. Scala fuses functional and object-oriented programming in a practical package. It interoperates seamlessly with both Java and Javascript. Scala is the implementation language of many important frameworks, including Apache Spark, Kafka, and Akka. It provides the core infrastructure for sites such as X, Tumblr and Coursera.
+Functional programming is becoming increasingly widespread in industry. This trend is driven by the adoption of Scala as the main programming language for many applications. Scala fuses functional and object-oriented programming in a practical package. It interoperates seamlessly with both Java and JavaScript. Scala is the implementation language of many important frameworks, including Apache Spark, Kafka, and Akka. It provides the core infrastructure for sites such as X, Tumblr and Coursera.
In this course you will discover the elements of the functional programming style and learn how to apply them usefully in your daily programming tasks. You will also develop a solid foundation for reasoning about functional programs, by touching upon proofs of invariants and the tracing of execution symbolically.
@@ -24,4 +24,4 @@ Learning Outcomes. By the end of this course you will be able to:
- reason about properties of functions,
- understand generic types for functional programs
-Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, Javascript or Ruby is also sufficient. You should have some familiarity using the command line.
+Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, JavaScript or Ruby is also sufficient. You should have some familiarity using the command line.
diff --git a/_online_courses/parallel_programming.md b/_online_courses/parallel_programming.md
index fa90a69fa..bd41addd7 100644
--- a/_online_courses/parallel_programming.md
+++ b/_online_courses/parallel_programming.md
@@ -17,4 +17,4 @@ Learning Outcomes. By the end of this course you will be able to:
- competently microbenchmark parallel code,
- write programs that effectively use parallel collections to achieve performance
-Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, Javascript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Functional Program Design in Scala: https://www.coursera.org/learn/scala-functional-program-design.
+Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, JavaScript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Functional Program Design in Scala: https://www.coursera.org/learn/scala-functional-program-design.
diff --git a/_plugins/jekyll-tabs-lib/README.md b/_plugins/jekyll-tabs-lib/README.md
index a94a51490..8b0b7da44 100644
--- a/_plugins/jekyll-tabs-lib/README.md
+++ b/_plugins/jekyll-tabs-lib/README.md
@@ -2,7 +2,7 @@ copied from https://github.com/scala/docs.scala-lang/tree/main/_plugins/jekyll-t
originally sourced from https://github.com/Ovski4/jekyll-tabs.
changes:
-- template.erb adapted to match the pre-existing tab html structure for docs.scala-lang.org
+- template.erb adapted to match the preexisting tab html structure for docs.scala-lang.org
- `tabs` do not use secure random uuid as the id, the `tabs` name parameter is used instead.
- for the `tabs` block, add an optional second `class='foo bar'` parameter to allow custom classes for the tabs.
- for the `tab` block, reorder the parameters: the tab label comes first, followed by the name of the parent `tabs`.
diff --git a/_posts/2013-02-28-release-notes-v2.10.1-RC2.md b/_posts/2013-02-28-release-notes-v2.10.1-RC2.md
index 44aee8677..c3cedcb14 100644
--- a/_posts/2013-02-28-release-notes-v2.10.1-RC2.md
+++ b/_posts/2013-02-28-release-notes-v2.10.1-RC2.md
@@ -342,7 +342,7 @@ Issue(s) | Commit | Message
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [286dced](https://github.com/scala/scala/commit/286dced) |
SI-6288 Remedy ill-positioned extractor binding.
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [f69b846](https://github.com/scala/scala/commit/f69b846) |
SI-6288 Fix positioning of label jumps
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [79a43d7](https://github.com/scala/scala/commit/79a43d7) |
SI-6288 Position argument of unapply
-[SI-6758](https://issues.scala-lang.org/browse/SI-6758) | [089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnnotationInfo for DefDef and TypeDef
+[SI-6758](https://issues.scala-lang.org/browse/SI-6758) | [089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnotationInfo for DefDef and TypeDef
[SI-6555](https://issues.scala-lang.org/browse/SI-6555) | [818a2e6](https://github.com/scala/scala/commit/818a2e6) |
SI-6555 Better parameter name retention
[SI-5841](https://issues.scala-lang.org/browse/SI-5841) | [286abfc](https://github.com/scala/scala/commit/286abfc) |
SI-5841 reification of renamed imports
[SI-5877](https://issues.scala-lang.org/browse/SI-5877) | [0b1ae9c](https://github.com/scala/scala/commit/0b1ae9c) |
SI-5877 Tweak the check for package object owner.
@@ -358,7 +358,7 @@ Issue(s) | Commit | Message
[SI-5789](https://issues.scala-lang.org/browse/SI-5789) | [850128d](https://github.com/scala/scala/commit/850128d) |
SI-5789 Checks in the right version of the test
[SI-6782](https://issues.scala-lang.org/browse/SI-6782), [SI-5789](https://issues.scala-lang.org/browse/SI-5789) | [d699122](https://github.com/scala/scala/commit/d699122) |
SI-5789 Removes assertion about implclass flag in Mixin.scala
[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [a23cc20](https://github.com/scala/scala/commit/a23cc20) |
SI-5894 Don't emit static forwarders for macros.
-[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication beween GenJVM / GenASM.
+[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication between GenJVM / GenASM.
[SI-1672](https://issues.scala-lang.org/browse/SI-1672) | [31a0aa7](https://github.com/scala/scala/commit/31a0aa7) |
SI-1672 Catches are in tail position without finally.
[SI-6535](https://issues.scala-lang.org/browse/SI-6535) | [8a1f85d](https://github.com/scala/scala/commit/8a1f85d) |
SI-6535 Step back from the precipice of a cycle
[SI-6549](https://issues.scala-lang.org/browse/SI-6549) | [90c87fc](https://github.com/scala/scala/commit/90c87fc) |
SI-6549 Improve escaping in REPL codegen.
@@ -667,7 +667,7 @@ sha | Title
[dfa4e23](https://github.com/scala/scala/commit/dfa4e23) |
simplifies checkBounds
[a0cd0f8](https://github.com/scala/scala/commit/a0cd0f81be) |
prevents spurious kind bound errors
[24455e2](https://github.com/scala/scala/commit/24455e2) |
Recurse into instantiations when stripping type vars.
-[089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnnotationInfo for DefDef and TypeDef
+[089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnotationInfo for DefDef and TypeDef
[e5e6d67](https://github.com/scala/scala/commit/e5e6d67) |
Extract base scaladoc functionality for the IDE.
[69f4e93](https://github.com/scala/scala/commit/69f4e93) |
DRYer crash reports.
[818a2e6](https://github.com/scala/scala/commit/818a2e6) |
SI-6555 Better parameter name retention
@@ -687,8 +687,8 @@ sha | Title
[850128d](https://github.com/scala/scala/commit/850128d) |
SI-5789 Checks in the right version of the test
[d699122](https://github.com/scala/scala/commit/d699122) |
SI-5789 Removes assertion about implclass flag in Mixin.scala
[a23cc20](https://github.com/scala/scala/commit/a23cc20) |
SI-5894 Don't emit static forwarders for macros.
-[b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication beween GenJVM / GenASM.
-[8434922](https://github.com/scala/scala/commit/8434922) |
Addtional test cases for tail calls in catches.
+[b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication between GenJVM / GenASM.
+[8434922](https://github.com/scala/scala/commit/8434922) |
Additional test cases for tail calls in catches.
[31a0aa7](https://github.com/scala/scala/commit/31a0aa7) |
SI-1672 Catches are in tail position without finally.
[e4d1d93](https://github.com/scala/scala/commit/e4d1d93) |
Warn when generated classfiles differ only in case.
[8a1f85d](https://github.com/scala/scala/commit/8a1f85d) |
SI-6535 Step back from the precipice of a cycle
@@ -740,7 +740,7 @@ sha | Title
[74ca558](https://github.com/scala/scala/commit/74ca558) |
SI-6551: don't insert apply call in polymorphic expression.
[c656920](https://github.com/scala/scala/commit/c656920) |
SI-6663: don't ignore type parameter on selectDynamic invocation
[af8b45f](https://github.com/scala/scala/commit/af8b45f) |
Scaladoc update for collection.mutable.MultiMap
-[db0bf8f](https://github.com/scala/scala/commit/db0bf8f) |
Restore the opimization apparently lost after merge.
+[db0bf8f](https://github.com/scala/scala/commit/db0bf8f) |
Restore the optimization apparently lost after merge.
[1f0e488](https://github.com/scala/scala/commit/1f0e488) |
Fixes SI-6150 - backport to 2.10.x branch.
[65778d7](https://github.com/scala/scala/commit/65778d7) |
SI-5330, SI-6014 deal with existential self-type
[f8647ee](https://github.com/scala/scala/commit/f8647ee) |
show developer guidelines on opening pull request
diff --git a/_posts/2013-03-06-release-notes-v2.10.1-RC3.md b/_posts/2013-03-06-release-notes-v2.10.1-RC3.md
index daef9be12..c199cc2d2 100644
--- a/_posts/2013-03-06-release-notes-v2.10.1-RC3.md
+++ b/_posts/2013-03-06-release-notes-v2.10.1-RC3.md
@@ -347,7 +347,7 @@ Issue(s) | Commit | Message
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [286dced](https://github.com/scala/scala/commit/286dced) |
SI-6288 Remedy ill-positioned extractor binding.
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [f69b846](https://github.com/scala/scala/commit/f69b846) |
SI-6288 Fix positioning of label jumps
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [79a43d7](https://github.com/scala/scala/commit/79a43d7) |
SI-6288 Position argument of unapply
-[SI-6758](https://issues.scala-lang.org/browse/SI-6758) | [089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnnotationInfo for DefDef and TypeDef
+[SI-6758](https://issues.scala-lang.org/browse/SI-6758) | [089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnotationInfo for DefDef and TypeDef
[SI-6555](https://issues.scala-lang.org/browse/SI-6555) | [818a2e6](https://github.com/scala/scala/commit/818a2e6) |
SI-6555 Better parameter name retention
[SI-5841](https://issues.scala-lang.org/browse/SI-5841) | [286abfc](https://github.com/scala/scala/commit/286abfc) |
SI-5841 reification of renamed imports
[SI-5877](https://issues.scala-lang.org/browse/SI-5877) | [0b1ae9c](https://github.com/scala/scala/commit/0b1ae9c) |
SI-5877 Tweak the check for package object owner.
@@ -363,7 +363,7 @@ Issue(s) | Commit | Message
[SI-5789](https://issues.scala-lang.org/browse/SI-5789) | [850128d](https://github.com/scala/scala/commit/850128d) |
SI-5789 Checks in the right version of the test
[SI-6782](https://issues.scala-lang.org/browse/SI-6782), [SI-5789](https://issues.scala-lang.org/browse/SI-5789) | [d699122](https://github.com/scala/scala/commit/d699122) |
SI-5789 Removes assertion about implclass flag in Mixin.scala
[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [a23cc20](https://github.com/scala/scala/commit/a23cc20) |
SI-5894 Don't emit static forwarders for macros.
-[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication beween GenJVM / GenASM.
+[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication between GenJVM / GenASM.
[SI-1672](https://issues.scala-lang.org/browse/SI-1672) | [31a0aa7](https://github.com/scala/scala/commit/31a0aa7) |
SI-1672 Catches are in tail position without finally.
[SI-6535](https://issues.scala-lang.org/browse/SI-6535) | [8a1f85d](https://github.com/scala/scala/commit/8a1f85d) |
SI-6535 Step back from the precipice of a cycle
[SI-6549](https://issues.scala-lang.org/browse/SI-6549) | [90c87fc](https://github.com/scala/scala/commit/90c87fc) |
SI-6549 Improve escaping in REPL codegen.
@@ -677,7 +677,7 @@ sha | Title
[dfa4e23](https://github.com/scala/scala/commit/dfa4e23) |
simplifies checkBounds
[a0cd0f8](https://github.com/scala/scala/commit/a0cd0f81be) |
prevents spurious kind bound errors
[24455e2](https://github.com/scala/scala/commit/24455e2) |
Recurse into instantiations when stripping type vars.
-[089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnnotationInfo for DefDef and TypeDef
+[089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnotationInfo for DefDef and TypeDef
[e5e6d67](https://github.com/scala/scala/commit/e5e6d67) |
Extract base scaladoc functionality for the IDE.
[69f4e93](https://github.com/scala/scala/commit/69f4e93) |
DRYer crash reports.
[818a2e6](https://github.com/scala/scala/commit/818a2e6) |
SI-6555 Better parameter name retention
@@ -697,8 +697,8 @@ sha | Title
[850128d](https://github.com/scala/scala/commit/850128d) |
SI-5789 Checks in the right version of the test
[d699122](https://github.com/scala/scala/commit/d699122) |
SI-5789 Removes assertion about implclass flag in Mixin.scala
[a23cc20](https://github.com/scala/scala/commit/a23cc20) |
SI-5894 Don't emit static forwarders for macros.
-[b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication beween GenJVM / GenASM.
-[8434922](https://github.com/scala/scala/commit/8434922) |
Addtional test cases for tail calls in catches.
+[b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication between GenJVM / GenASM.
+[8434922](https://github.com/scala/scala/commit/8434922) |
Additional test cases for tail calls in catches.
[31a0aa7](https://github.com/scala/scala/commit/31a0aa7) |
SI-1672 Catches are in tail position without finally.
[e4d1d93](https://github.com/scala/scala/commit/e4d1d93) |
Warn when generated classfiles differ only in case.
[8a1f85d](https://github.com/scala/scala/commit/8a1f85d) |
SI-6535 Step back from the precipice of a cycle
@@ -750,7 +750,7 @@ sha | Title
[74ca558](https://github.com/scala/scala/commit/74ca558) |
SI-6551: don't insert apply call in polymorphic expression.
[c656920](https://github.com/scala/scala/commit/c656920) |
SI-6663: don't ignore type parameter on selectDynamic invocation
[af8b45f](https://github.com/scala/scala/commit/af8b45f) |
Scaladoc update for collection.mutable.MultiMap
-[db0bf8f](https://github.com/scala/scala/commit/db0bf8f) |
Restore the opimization apparently lost after merge.
+[db0bf8f](https://github.com/scala/scala/commit/db0bf8f) |
Restore the optimization apparently lost after merge.
[1f0e488](https://github.com/scala/scala/commit/1f0e488) |
Fixes SI-6150 - backport to 2.10.x branch.
[65778d7](https://github.com/scala/scala/commit/65778d7) |
SI-5330, SI-6014 deal with existential self-type
[f8647ee](https://github.com/scala/scala/commit/f8647ee) |
show developer guidelines on opening pull request
diff --git a/_posts/2013-03-13-release-notes-v2.10.1.md b/_posts/2013-03-13-release-notes-v2.10.1.md
index ae73a6fa6..509f20875 100644
--- a/_posts/2013-03-13-release-notes-v2.10.1.md
+++ b/_posts/2013-03-13-release-notes-v2.10.1.md
@@ -343,7 +343,7 @@ Issue(s) | Commit | Message
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [286dced](https://github.com/scala/scala/commit/286dced) |
SI-6288 Remedy ill-positioned extractor binding.
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [f69b846](https://github.com/scala/scala/commit/f69b846) |
SI-6288 Fix positioning of label jumps
[SI-6288](https://issues.scala-lang.org/browse/SI-6288) | [79a43d7](https://github.com/scala/scala/commit/79a43d7) |
SI-6288 Position argument of unapply
-[SI-6758](https://issues.scala-lang.org/browse/SI-6758) | [089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnnotationInfo for DefDef and TypeDef
+[SI-6758](https://issues.scala-lang.org/browse/SI-6758) | [089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnotationInfo for DefDef and TypeDef
[SI-6555](https://issues.scala-lang.org/browse/SI-6555) | [818a2e6](https://github.com/scala/scala/commit/818a2e6) |
SI-6555 Better parameter name retention
[SI-5841](https://issues.scala-lang.org/browse/SI-5841) | [286abfc](https://github.com/scala/scala/commit/286abfc) |
SI-5841 reification of renamed imports
[SI-5877](https://issues.scala-lang.org/browse/SI-5877) | [0b1ae9c](https://github.com/scala/scala/commit/0b1ae9c) |
SI-5877 Tweak the check for package object owner.
@@ -359,7 +359,7 @@ Issue(s) | Commit | Message
[SI-5789](https://issues.scala-lang.org/browse/SI-5789) | [850128d](https://github.com/scala/scala/commit/850128d) |
SI-5789 Checks in the right version of the test
[SI-6782](https://issues.scala-lang.org/browse/SI-6782), [SI-5789](https://issues.scala-lang.org/browse/SI-5789) | [d699122](https://github.com/scala/scala/commit/d699122) |
SI-5789 Removes assertion about implclass flag in Mixin.scala
[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [a23cc20](https://github.com/scala/scala/commit/a23cc20) |
SI-5894 Don't emit static forwarders for macros.
-[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication beween GenJVM / GenASM.
+[SI-5894](https://issues.scala-lang.org/browse/SI-5894) | [b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication between GenJVM / GenASM.
[SI-1672](https://issues.scala-lang.org/browse/SI-1672) | [31a0aa7](https://github.com/scala/scala/commit/31a0aa7) |
SI-1672 Catches are in tail position without finally.
[SI-6535](https://issues.scala-lang.org/browse/SI-6535) | [8a1f85d](https://github.com/scala/scala/commit/8a1f85d) |
SI-6535 Step back from the precipice of a cycle
[SI-6549](https://issues.scala-lang.org/browse/SI-6549) | [90c87fc](https://github.com/scala/scala/commit/90c87fc) |
SI-6549 Improve escaping in REPL codegen.
@@ -673,7 +673,7 @@ sha | Title
[dfa4e23](https://github.com/scala/scala/commit/dfa4e23) |
simplifies checkBounds
[a0cd0f8](https://github.com/scala/scala/commit/a0cd0f81be) |
prevents spurious kind bound errors
[24455e2](https://github.com/scala/scala/commit/24455e2) |
Recurse into instantiations when stripping type vars.
-[089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnnotationInfo for DefDef and TypeDef
+[089173d](https://github.com/scala/scala/commit/089173d) |
Fixes SI-6758: force LazyAnnotationInfo for DefDef and TypeDef
[e5e6d67](https://github.com/scala/scala/commit/e5e6d67) |
Extract base scaladoc functionality for the IDE.
[69f4e93](https://github.com/scala/scala/commit/69f4e93) |
DRYer crash reports.
[818a2e6](https://github.com/scala/scala/commit/818a2e6) |
SI-6555 Better parameter name retention
@@ -693,8 +693,8 @@ sha | Title
[850128d](https://github.com/scala/scala/commit/850128d) |
SI-5789 Checks in the right version of the test
[d699122](https://github.com/scala/scala/commit/d699122) |
SI-5789 Removes assertion about implclass flag in Mixin.scala
[a23cc20](https://github.com/scala/scala/commit/a23cc20) |
SI-5894 Don't emit static forwarders for macros.
-[b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication beween GenJVM / GenASM.
-[8434922](https://github.com/scala/scala/commit/8434922) |
Addtional test cases for tail calls in catches.
+[b828e32](https://github.com/scala/scala/commit/b828e32) |
Remove some low-hanging duplication between GenJVM / GenASM.
+[8434922](https://github.com/scala/scala/commit/8434922) |
Additional test cases for tail calls in catches.
[31a0aa7](https://github.com/scala/scala/commit/31a0aa7) |
SI-1672 Catches are in tail position without finally.
[e4d1d93](https://github.com/scala/scala/commit/e4d1d93) |
Warn when generated classfiles differ only in case.
[8a1f85d](https://github.com/scala/scala/commit/8a1f85d) |
SI-6535 Step back from the precipice of a cycle
@@ -746,7 +746,7 @@ sha | Title
[74ca558](https://github.com/scala/scala/commit/74ca558) |
SI-6551: don't insert apply call in polymorphic expression.
[c656920](https://github.com/scala/scala/commit/c656920) |
SI-6663: don't ignore type parameter on selectDynamic invocation
[af8b45f](https://github.com/scala/scala/commit/af8b45f) |
Scaladoc update for collection.mutable.MultiMap
-[db0bf8f](https://github.com/scala/scala/commit/db0bf8f) |
Restore the opimization apparently lost after merge.
+[db0bf8f](https://github.com/scala/scala/commit/db0bf8f) |
Restore the optimization apparently lost after merge.
[1f0e488](https://github.com/scala/scala/commit/1f0e488) |
Fixes SI-6150 - backport to 2.10.x branch.
[65778d7](https://github.com/scala/scala/commit/65778d7) |
SI-5330, SI-6014 deal with existential self-type
[f8647ee](https://github.com/scala/scala/commit/f8647ee) |
show developer guidelines on opening pull request
diff --git a/_posts/2013-03-20-gsoc13.md b/_posts/2013-03-20-gsoc13.md
index 77cf83562..2d81a2c54 100644
--- a/_posts/2013-03-20-gsoc13.md
+++ b/_posts/2013-03-20-gsoc13.md
@@ -76,7 +76,7 @@ The goal of this project is to extend Slick to support database schema manipulat
### Data migration tool
-The goal of this project is creating a tool for managing data migration scripts based on Slick. We have a rough proof of concept implementation you can base work on at [https://github.com/cvogt/migrations](https://github.com/cvogt/migrations "https://github.com/cvogt/migrations") . The idea is roughly similar to migrations/evolutions in Ruby on Rails or Scala Play 2. You will need to significantly improve (or re-write) the code of the proof of concept implementation to make it production ready, extend it by futher features and explore some exciting ideas like reliable migrations in a development scenario with branches (like git branches). Your ideas are important to this project. Here is how we see it right now:
+The goal of this project is creating a tool for managing data migration scripts based on Slick. We have a rough proof of concept implementation you can base work on at [https://github.com/cvogt/migrations](https://github.com/cvogt/migrations "https://github.com/cvogt/migrations") . The idea is roughly similar to migrations/evolutions in Ruby on Rails or Scala Play 2. You will need to significantly improve (or re-write) the code of the proof of concept implementation to make it production ready, extend it by further features and explore some exciting ideas like reliable migrations in a development scenario with branches (like git branches). Your ideas are important to this project. Here is how we see it right now:
Existing features (which all require revision)
@@ -113,7 +113,7 @@ With this project the deep DSL embedding would be greatly simplified. The DSL au
The deep embedding of run-time compiled DSLs can further improve performance by utilizing the run-time collected data for optimizations. However, when this data changes the costly recompilation must be performed greatly increasing delay. Another goal of this project would be to investigate the DSL author guided JIT compilation of DSLs. With JIT compilation the run-time compiled DSLs could be utilized in latency critical programs that operate on smaller data (e.g. web servers, compilers, GUI applications).
-The grand vision for the project is to generate the DSL modules from the whole Scala Library and provide DSL optimizations for them. These modules could then be used in critical paths of all Scala projects. Due to the magnitude of the project the GSoC candidate would focus on one well defined part.
+The grand vision for the project is to generate the DSL modules from the whole Scala Library and provide DSL optimizations for them. These modules could then be used in critical paths of all Scala projects. Due to the magnitude of the project, the GSoC candidate would focus on one well defined part.
Skills required for this project are:
@@ -269,7 +269,7 @@ The project would involve some of the following tasks:
* develop use cases, both for client-side and server-side applications
* create a translator for SubScript into JavaScript
* extend an existing JavaScript interpreter to understand SubScript
-* define a strategy to send over SubScript in HTML pagesand have it translated
+* define a strategy to send over SubScript in HTML pages and have it translated
* provide a translator for the SubScript VM source code into JavaScript
* JavaScript does not support explicit multithreading; develop an alternative
@@ -321,7 +321,7 @@ The student would learn about efficient numerical computing on the JVM, as wel
## Ensime Plugin for Sublime Text
-The [Sublime-Ensime](https://github.com/sublimescala/sublime-ensime) plugin enhances the [Sublime Text 2](https://www.sublimetext.com/2) editor with Scala-specific error highlighting, autocompletion and many other features. With about 1.5K downloads, and many users sucessfully using it, we are keen on introducing additional features to provide comprehensive integrated experience. We also expect that users will demand the plugin for [Sublime Text 3](https://www.sublimetext.com/3), but this requires refactoring the plugin, preparing it for running in Python 3.3 and possibly integrating with more recent features such as symbol indexing.
+The [Sublime-Ensime](https://github.com/sublimescala/sublime-ensime) plugin enhances the [Sublime Text 2](https://www.sublimetext.com/2) editor with Scala-specific error highlighting, autocompletion and many other features. With about 1.5K downloads, and many users successfully using it, we are keen on introducing additional features to provide comprehensive integrated experience. We also expect that users will demand the plugin for [Sublime Text 3](https://www.sublimetext.com/3), but this requires refactoring the plugin, preparing it for running in Python 3.3 and possibly integrating with more recent features such as symbol indexing.
The ideal candidate is fluent in both Python and Scala and currently uses the Sublime Text editor frequently. We also welcome candidates who are active and engage the community via issue reports, mailing lists and forums.
diff --git a/_posts/2013-05-29-release-notes-v2.11.0-M3.md b/_posts/2013-05-29-release-notes-v2.11.0-M3.md
index ef0e2c6e0..5c5368f9f 100644
--- a/_posts/2013-05-29-release-notes-v2.11.0-M3.md
+++ b/_posts/2013-05-29-release-notes-v2.11.0-M3.md
@@ -12,7 +12,7 @@ The Scala team and contributors [fixed 108 issues](https://issues.scala-lang.org
Please give 2.11.0-M3 a spin! This release is *not* binary compatible with the 2.10.x series, so you will need to obtain builds of your dependencies. Once we start the release candidates, we will coordinate with the open source community to release these simultaneously, but for these milestones we are not asking library authors to go to that trouble.
-We'd love to hear about any regressions since 2.10.1. You can file bugs in [JIRA](https://issues.scala-lang.org/secure/CreateIssue.jspa?pid=10005&issuetype=1). Before doing so, please search for existing bugs and/or consult with the [scala-user](https://groups.google.com/forum/?fromgroups#!forum/scala-user) mailing list to be sure it is a geniune problem. Please set the 'Affects Version' field to 2.11.0-M3 and add the tag `regression`.
+We'd love to hear about any regressions since 2.10.1. You can file bugs in [Jira](https://issues.scala-lang.org/secure/CreateIssue.jspa?pid=10005&issuetype=1). Before doing so, please search for existing bugs and/or consult with the [scala-user](https://groups.google.com/forum/?fromgroups#!forum/scala-user) mailing list to be sure it is a genuine problem. Please set the 'Affects Version' field to 2.11.0-M3 and add the tag `regression`.
In particular, be aware that the complete fix for [SI-7486](https://issues.scala-lang.org/browse/SI-7486)
is not included in this milestone. If you encounter this, the workaround is to annotate the return type
diff --git a/_posts/2013-09-18-release-notes-v2.10.3-RC2.md b/_posts/2013-09-18-release-notes-v2.10.3-RC2.md
index cca6eaf08..8d0a8fb17 100644
--- a/_posts/2013-09-18-release-notes-v2.10.3-RC2.md
+++ b/_posts/2013-09-18-release-notes-v2.10.3-RC2.md
@@ -198,7 +198,7 @@ Issue(s) | Commit | Message
[SI-6138](https://issues.scala-lang.org/browse/SI-6138) | [b941551](https://github.com/scala/scala/commit/b941551) |
SI-6138 Centralize and refine detection of `getClass` calls
[SI-7236](https://issues.scala-lang.org/browse/SI-7236), [SI-7237](https://issues.scala-lang.org/browse/SI-7237), [SI-7391](https://issues.scala-lang.org/browse/SI-7391) | [f92ef91](https://github.com/scala/scala/commit/f92ef91) |
SI-7391 Always use ForkJoin in Scala actors on ... ... Java 6 and above (except
[SI-7473](https://issues.scala-lang.org/browse/SI-7473) | [5b54681](https://github.com/scala/scala/commit/5b54681) |
SI-7473 Bad for expr crashes postfix
-[SI-7421](https://issues.scala-lang.org/browse/SI-7421) | [e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachement in maven deploy
+[SI-7421](https://issues.scala-lang.org/browse/SI-7421) | [e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachment in maven deploy
[SI-7497](https://issues.scala-lang.org/browse/SI-7497) | [d38e8ae](https://github.com/scala/scala/commit/d38e8ae) |
SI-7497 Fix scala.util.Properties.isMac
@@ -285,7 +285,7 @@ sha | Title
[f92ef91](https://github.com/scala/scala/commit/f92ef91) |
SI-7391 Always use ForkJoin in Scala actors on ... ... Java 6 and above (except
[5b54681](https://github.com/scala/scala/commit/5b54681) |
SI-7473 Bad for expr crashes postfix
[bae4196](https://github.com/scala/scala/commit/bae4196) |
A test case for a recent LUB progression.
-[e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachement in maven deploy
+[e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachment in maven deploy
[d38e8ae](https://github.com/scala/scala/commit/d38e8ae) |
SI-7497 Fix scala.util.Properties.isMac
[b89dc03](https://github.com/scala/scala/commit/b89dc03) |
Increase build.number to 2.10.3
[658d90a](https://github.com/scala/scala/commit/658d90a) |
c.typeCheck(silent = true) now suppresses ambiguous errors
diff --git a/_posts/2013-09-28-release-notes-v2.11.0-M5.md b/_posts/2013-09-28-release-notes-v2.11.0-M5.md
index 585dffc15..b0806edc5 100644
--- a/_posts/2013-09-28-release-notes-v2.11.0-M5.md
+++ b/_posts/2013-09-28-release-notes-v2.11.0-M5.md
@@ -21,7 +21,7 @@ Scala was released with slightly modified variant of 3-clause BSD license. The f
We've clarified the situation but switching to standard wording of 3-clause BSD license. The intent and meaning of the license hasn't change because previous version was just reworded version of 3-clause BSD license.
## Known issues
-Scala compiler artifact (due to scaladoc) depends on previous version (2.11.0-M4) of `scala-xml` and `scala-parser-combinators` modules. If you depend on `scala-compiler` (e.g. your are a macro writer) then you need to use extra care when upgrading to M5. See [scala-partest#3](https://github.com/scala/scala-partest/pull/3) which discusses the problem in depth and offers a work-around for sbt-based builds.
+Scala compiler artifact (due to scaladoc) depends on previous version (2.11.0-M4) of `scala-xml` and `scala-parser-combinators` modules. If you depend on `scala-compiler` (e.g. your are a macro writer) then you need to use extra care when upgrading to M5. See [scala-partest#3](https://github.com/scala/scala-partest/pull/3) which discusses the problem in depth and offers a workaround for sbt-based builds.
## Regressions
We'd [love to hear](https://issues.scala-lang.org/) about any regressions since 2.10.3 or 2.11.0-M4. Before doing so, please search for existing bugs and/or consult with the [scala-user](https://groups.google.com/forum/#!forum/scala-user) mailing list to be sure it is a genuine problem.
diff --git a/_posts/2013-10-01-release-notes-v2.10.3.md b/_posts/2013-10-01-release-notes-v2.10.3.md
index 7313aa818..a2b38c91d 100644
--- a/_posts/2013-10-01-release-notes-v2.10.3.md
+++ b/_posts/2013-10-01-release-notes-v2.10.3.md
@@ -207,7 +207,7 @@ Issue(s) | Commit | Message
[SI-6138](https://issues.scala-lang.org/browse/SI-6138) | [b941551](https://github.com/scala/scala/commit/b941551) |
SI-6138 Centralize and refine detection of `getClass` calls
[SI-7236](https://issues.scala-lang.org/browse/SI-7236), [SI-7237](https://issues.scala-lang.org/browse/SI-7237), [SI-7391](https://issues.scala-lang.org/browse/SI-7391) | [f92ef91](https://github.com/scala/scala/commit/f92ef91) |
SI-7391 Always use ForkJoin in Scala actors on ... ... Java 6 and above (except
[SI-7473](https://issues.scala-lang.org/browse/SI-7473) | [5b54681](https://github.com/scala/scala/commit/5b54681) |
SI-7473 Bad for expr crashes postfix
-[SI-7421](https://issues.scala-lang.org/browse/SI-7421) | [e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachement in maven deploy
+[SI-7421](https://issues.scala-lang.org/browse/SI-7421) | [e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachment in maven deploy
[SI-7497](https://issues.scala-lang.org/browse/SI-7497) | [d38e8ae](https://github.com/scala/scala/commit/d38e8ae) |
SI-7497 Fix scala.util.Properties.isMac
@@ -296,7 +296,7 @@ sha | Title
[f92ef91](https://github.com/scala/scala/commit/f92ef91) |
SI-7391 Always use ForkJoin in Scala actors on ... ... Java 6 and above (except
[5b54681](https://github.com/scala/scala/commit/5b54681) |
SI-7473 Bad for expr crashes postfix
[bae4196](https://github.com/scala/scala/commit/bae4196) |
A test case for a recent LUB progression.
-[e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachement in maven deploy
+[e18e48d](https://github.com/scala/scala/commit/e18e48d) |
SI-7421 remove unneeded extra-attachment in maven deploy
[d38e8ae](https://github.com/scala/scala/commit/d38e8ae) |
SI-7497 Fix scala.util.Properties.isMac
[b89dc03](https://github.com/scala/scala/commit/b89dc03) |
Increase build.number to 2.10.3
[658d90a](https://github.com/scala/scala/commit/658d90a) |
c.typeCheck(silent = true) now suppresses ambiguous errors
diff --git a/_posts/2014-03-06-release-notes-2.11.0-RC1.md b/_posts/2014-03-06-release-notes-2.11.0-RC1.md
index 384cb7968..2972be4ff 100644
--- a/_posts/2014-03-06-release-notes-2.11.0-RC1.md
+++ b/_posts/2014-03-06-release-notes-2.11.0-RC1.md
@@ -127,7 +127,7 @@ We'd like to emphasize the following library deprecations:
Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: "assuming there are no deprecation warnings". This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!
### Binary Compatibility
-When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
+When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatible. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with [MiMa](https://github.com/typesafehub/migration-manager). We strive to maintain a similar invariant for the `behavior` (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).
@@ -136,7 +136,7 @@ We distinguish forwards and backwards compatibility (think of these as propertie
Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
-These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/browse/SI-8168?filter=12405&jql=project%20%3D%20SI%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20%3E%20%22Scala%202.10.0%22%20and%20fixVersion%20%3C%3D%20%22scala%202.10.4-RC3%22) in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.
+These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/browse/SI-8168?filter=12405&jql=project%20%3D%20SI%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20%3E%20%22Scala%202.10.0%22%20and%20fixVersion%20%3C%3D%20%22scala%202.10.4-RC3%22) in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet committing!) to extend it to include major versions in the future.
#### Concretely
Just like the 2.10.x series, we guarantee forwards and backwards compatibility of the `"org.scala-lang" % "scala-library" % "2.11.x"` and `"org.scala-lang" % "scala-reflect" % "2.11.x"` artifacts, except for anything under the `scala.reflect.internal` package, as scala-reflect is still experimental. We also strongly discourage relying on the stability of `scala.concurrent.impl` and `scala.reflect.runtime`, though we will only break compatibility for severe bugs here.
diff --git a/_posts/2014-03-20-release-notes-2.11.0-RC3.md b/_posts/2014-03-20-release-notes-2.11.0-RC3.md
index 3a6e78e41..c235785f1 100644
--- a/_posts/2014-03-20-release-notes-2.11.0-RC3.md
+++ b/_posts/2014-03-20-release-notes-2.11.0-RC3.md
@@ -136,7 +136,7 @@ We'd like to emphasize the following library deprecations:
Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: "assuming there are no deprecation warnings". This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!
### Binary Compatibility
-When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
+When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatible. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with [MiMa](https://github.com/typesafehub/migration-manager). We strive to maintain a similar invariant for the `behavior` (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).
@@ -145,7 +145,7 @@ We distinguish forwards and backwards compatibility (think of these as propertie
Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
-These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.
+These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet committing!) to extend it to include major versions in the future.
#### Concretely
Just like the 2.10.x series, we guarantee forwards and backwards compatibility of the `"org.scala-lang" % "scala-library" % "2.11.x"` and `"org.scala-lang" % "scala-reflect" % "2.11.x"` artifacts, except for anything under the `scala.reflect.internal` package, as scala-reflect is still experimental. We also strongly discourage relying on the stability of `scala.concurrent.impl` and `scala.reflect.runtime`, though we will only break compatibility for severe bugs here.
diff --git a/_posts/2014-04-08-release-notes-2.11.0-RC4.md b/_posts/2014-04-08-release-notes-2.11.0-RC4.md
index b92f93b8d..637ac8eb1 100644
--- a/_posts/2014-04-08-release-notes-2.11.0-RC4.md
+++ b/_posts/2014-04-08-release-notes-2.11.0-RC4.md
@@ -140,7 +140,7 @@ We'd like to emphasize the following library deprecations:
Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: "assuming there are no deprecation warnings". This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!
### Binary Compatibility
-When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
+When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatible. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with [MiMa](https://github.com/typesafehub/migration-manager). We strive to maintain a similar invariant for the `behavior` (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).
@@ -149,7 +149,7 @@ We distinguish forwards and backwards compatibility (think of these as propertie
Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
-These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.
+These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet committing!) to extend it to include major versions in the future.
#### Meta
Note that so far we've only talked about the jars generated by scalac for the standard library and reflection.
diff --git a/_posts/2014-04-21-release-notes-2.11.0.md b/_posts/2014-04-21-release-notes-2.11.0.md
index f1b8d194a..9eb66f191 100644
--- a/_posts/2014-04-21-release-notes-2.11.0.md
+++ b/_posts/2014-04-21-release-notes-2.11.0.md
@@ -201,7 +201,7 @@ We'd like to emphasize the following library deprecations:
Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: "assuming there are no deprecation warnings". This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!
### Binary Compatibility
-When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
+When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatible. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with [MiMa](https://github.com/typesafehub/migration-manager). We strive to maintain a similar invariant for the `behavior` (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).
@@ -210,7 +210,7 @@ We distinguish forwards and backwards compatibility (think of these as propertie
Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
-These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.
+These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet committing!) to extend it to include major versions in the future.
#### Meta
Note that so far we've only talked about the jars generated by scalac for the standard library and reflection.
diff --git a/_posts/2014-05-21-release-notes-2.11.1.md b/_posts/2014-05-21-release-notes-2.11.1.md
index 19119d493..32c30a516 100644
--- a/_posts/2014-05-21-release-notes-2.11.1.md
+++ b/_posts/2014-05-21-release-notes-2.11.1.md
@@ -226,7 +226,7 @@ We'd like to emphasize the following library deprecations:
Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: "assuming there are no deprecation warnings". This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!
### Binary Compatibility
-When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
+When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatible. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with [MiMa](https://github.com/typesafehub/migration-manager). We strive to maintain a similar invariant for the `behavior` (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).
@@ -235,7 +235,7 @@ We distinguish forwards and backwards compatibility (think of these as propertie
Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
-These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.
+These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing [372 issues](https://issues.scala-lang.org/issues/?jql=project%20%3D%20"SI"%20AND%20resolution%3D"fixed"%20and%20fixVersion%20>%20"Scala%202.10.0"%20and%20fixVersion%20<%3D%20"Scala%202.10.4") in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet committing!) to extend it to include major versions in the future.
#### Meta
Note that so far we've only talked about the jars generated by scalac for the standard library and reflection.
diff --git a/_posts/2015-05-05-release-notes-2.12.0-M1.md b/_posts/2015-05-05-release-notes-2.12.0-M1.md
index 9ae3cf79e..2b697f568 100644
--- a/_posts/2015-05-05-release-notes-2.12.0-M1.md
+++ b/_posts/2015-05-05-release-notes-2.12.0-M1.md
@@ -33,7 +33,7 @@ The following changes are planned for Scala 2.12:
The design notes for this feature are available in [this gist](https://gist.github.com/retronym/0178c212e4bacffed568).
* Lambda syntax for SAM types.
Similar to Java 8, Scala 2.12 allows instantiating any type with one single abstract method by passing a lambda.
- This feature is already avalable in Scala 2.11 using the `-Xexperimental` compiler option.
+ This feature is already available in Scala 2.11 using the `-Xexperimental` compiler option.
It improves the experience of using libraries written for Java 8 in Scala.
* New backend and optimizer.
The "GenBCode" backend, which is already available in Scala 2.11 using the `-Ybackend:GenBCode` compiler option, will be enabled by default.
@@ -84,7 +84,7 @@ The following modules have been removed from the Scala 2.12 distribution:
* The Scala actors library is no longer released with Scala 2.12.
We recommend that you use the [Akka actors library](https://akka.io/) instead.
-* The Scala distribution archives and the `scala-library-all` maven dependency no longer inlcude Akka actors.
+* The Scala distribution archives and the `scala-library-all` maven dependency no longer include Akka actors.
To use the Akka actors library, add it to your project as a dependency.
* The continuations plugin is no longer shipped with the Scala 2.12 distribution.
@@ -106,7 +106,7 @@ You are kindly invited to contribute!
Please file any bugs you encounter on [our issue tracker](https://issues.scala-lang.org).
If you're unsure whether something is a bug, please contact the [scala-user](https://groups.google.com/forum/?fromgroups#!forum/scala-user) mailing list.
-Before creating a new issue, search search the issue tracker to see if your bug has already been reported.
+Before creating a new issue, search the issue tracker to see if your bug has already been reported.
### Scala IDE for Eclipse
@@ -135,7 +135,7 @@ Note that milestone releases and release candidates are **not** binary compatibl
When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time.
Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) [`LinkageError`](https://docs.oracle.com/javase/7/docs/api/java/lang/LinkageError.html) when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala.
-Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile.
+Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatible.
In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with [MiMa](https://github.com/typesafehub/migration-manager).
diff --git a/_posts/2015-10-06-release-notes-2.12.0-M3.md b/_posts/2015-10-06-release-notes-2.12.0-M3.md
index 5bcbcdcf9..07ea3951a 100644
--- a/_posts/2015-10-06-release-notes-2.12.0-M3.md
+++ b/_posts/2015-10-06-release-notes-2.12.0-M3.md
@@ -67,7 +67,7 @@ This feature was also available in Scala 2.11, also via `-Xexperimental`.
#### New tab-completion in the Scala REPL
-The implementation of tab-completion in the Scala REPL has been rewritten and now uses the same infrastruture as for example the Scala IDE or Ensime. Note that this feature will also be available in 2.11.8.
+The implementation of tab-completion in the Scala REPL has been rewritten and now uses the same infrastructure as for example the Scala IDE or Ensime. Note that this feature will also be available in 2.11.8.
There are a number of improvements:
* Reliable completion, also in partial expressions and syntactically incorrect programs: try `class C { def f(l: List[Int]) = l.
`
diff --git a/_posts/2015-11-16-minutes-from-nov-2015.md b/_posts/2015-11-16-minutes-from-nov-2015.md
index ba18dde48..ea173e8dc 100644
--- a/_posts/2015-11-16-minutes-from-nov-2015.md
+++ b/_posts/2015-11-16-minutes-from-nov-2015.md
@@ -184,7 +184,7 @@ Link to issue and document: [https://github.com/scala/slip/issues/31](https://gi
The document proposes a solution similar to Haskell:
- a "core": which consists only what the compiler needs and not more ([@odersky](https://github.com/odersky) thinks for Scala this should be explained slightly)
-- a "platform": can vary and be much bigger. The platform would be maintained by a different set of people from the core (and have it's own committee), it would be handled by the people who contribute modules to the platform
+- a "platform": can vary and be much bigger. The platform would be maintained by a different set of people from the core (and have its own committee), it would be handled by the people who contribute modules to the platform
[@odersky](https://github.com/odersky) thinks this would be a good model for us as well - the SLIP/SIP committee would look after the core and language, leave the platform to those who work on the platform. The SLIP committee would probably need to jumpstart the platform process in the beginning, but would like to hand over it's running to the community as soon as possible
@@ -225,7 +225,7 @@ Conversation over the proposal:
Splitting out core:
-- [@odersky](https://github.com/odersky) thinks we should appeal to the community to help, since even Typesafe can't do all of this on it's own
+- [@odersky](https://github.com/odersky) thinks we should appeal to the community to help, since even Typesafe can't do all of this on its own
- [@SethTisue](https://github.com/SethTisue) splitting the library up was already on Typesafe's plate for Scala 2.13. Could use help from the community, since disentangling the compiler from everything else involves a lot of work
- [@dickwall](https://github.com/dickwall) thinks this should be tracked through the SIP/SLIP site - SIP/SLIPs are much more than adding new things to the language
@@ -269,7 +269,7 @@ a discussion needs to happen around that
Also, should this go into the Scala namespace?
-[@SethTisue](https://github.com/SethTisue) points out that part the reason the reaction of this was hard to gauge was it wasn't clear if people realized this wasn't for core (it's not).
+[@SethTisue](https://github.com/SethTisue) points out that part the reason that the reaction of this was hard to gauge was it wasn't clear if people realized this wasn't for core (it's not).
[@heathermiller](https://github.com/heathermiller) even we are confused about what is and isn't core
diff --git a/_posts/2016-04-11-release-notes-2.12.0-M4.md b/_posts/2016-04-11-release-notes-2.12.0-M4.md
index b635be856..f49ca1270 100644
--- a/_posts/2016-04-11-release-notes-2.12.0-M4.md
+++ b/_posts/2016-04-11-release-notes-2.12.0-M4.md
@@ -10,7 +10,7 @@ Scala 2.12 is all about making optimal use of Java 8's new features. Traits ([#5
For more details about what's new in this milestone, including some breaking changes, please take a look at [these 14 noteworthy PRs](https://github.com/scala/scala/pulls?q=is%3Apr+label%3Arelease-notes+milestone%3A2.12.0-M4+is%3Amerged).
-In total, we merged [135 pull requests](https://github.com/scala/scala/pulls?q=is%3Apr+is%3Amerged+milestone%3A2.12.0-M4), of which [16 are by new contributors](https://github.com/scala/scala/pulls?q=is%3Apr+milestone%3A2.12.0-M4+label%3Awelcome) -- welcome! This milestone resolves [49 JIRA tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-M4%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC).
+In total, we merged [135 pull requests](https://github.com/scala/scala/pulls?q=is%3Apr+is%3Amerged+milestone%3A2.12.0-M4), of which [16 are by new contributors](https://github.com/scala/scala/pulls?q=is%3Apr+milestone%3A2.12.0-M4+label%3Awelcome) -- welcome! This milestone resolves [49 Jira tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-M4%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC).
We'd especially like to thank Felix Mulder for his [excellent work on the new Scaladoc interface](https://github.com/scala/scala/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged+author%3Afelixmulder++milestone%3A2.12.0-M4)! Check it out!
@@ -73,7 +73,7 @@ As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstrac
(new C[Int]) sort ((a: Int, b: Int) => a - b) // ok
The first attempt fails because the type checker cannot infer the types for `_ - _`'s arguments anymore.
-Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments the methods are applied to. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
+Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments to which methods are applied. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
Finally, implicit conversion of SAM types to Function types won't kick in anymore, since the compiler does this conversion itself first:
diff --git a/_posts/2016-05-30-scala-center-advisory-board.md b/_posts/2016-05-30-scala-center-advisory-board.md
index cc1eb9c63..d892f68d0 100644
--- a/_posts/2016-05-30-scala-center-advisory-board.md
+++ b/_posts/2016-05-30-scala-center-advisory-board.md
@@ -11,7 +11,7 @@ Scala Center and how it influences the Scala community and ecosystem.
It was never intentional, but it's become a bit of a joke at EPFL that the
"Scala Center Advisory Board" was born with an unfortunate acronym! So, when I
-chaired our inaugral meeting in New York two weeks ago, one of the first points
+chaired our inaugural meeting in New York two weeks ago, one of the first points
I made to the attendees was that we have to exceed our acronym and earn the
community's trust and respect, ensuring we provide a worthwhile and beneficial
service to all users of Scala.
@@ -101,7 +101,7 @@ As the process was new for all of the members and less time was available for
preparing proposals, we made the concession to allow proposals to be presented
*at* the meeting (without prior submission), but in future, we will require
that proposals be submitted to the repository at least a week before the
-meeting to give all the members an opportunity to consider them before meeting.
+meeting to give all members an opportunity to consider them before meeting.
During the first meeting, we also elected Seth Tisue as the secretary, and his
minutes ~~will be published in the next few days~~ have been published
diff --git a/_posts/2016-06-29-release-notes-2.12.0-M5.md b/_posts/2016-06-29-release-notes-2.12.0-M5.md
index 1cb3931f6..9ccd62243 100644
--- a/_posts/2016-06-29-release-notes-2.12.0-M5.md
+++ b/_posts/2016-06-29-release-notes-2.12.0-M5.md
@@ -31,7 +31,7 @@ the issue, but we are still investigating the details. The 2.12 release notes wi
impact of changes to traits on binary compatibility.
In total, we merged [96 pull requests](https://github.com/scala/scala/pulls?q=is%3Apr+is%3Amerged+milestone%3A2.12.0-M5), of which [9 are by new contributors](https://github.com/scala/scala/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Amerged%20milestone%3A2.12.0-M5%20label%3Awelcome) -- welcome!
-This milestone resolves [49 JIRA tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-M5%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC).
+This milestone resolves [49 Jira tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-M5%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC).
As usual for milestones, 2.12.0-M5 is not binary compatible with any other Scala release, including other 2.12 milestones. Scala 2.12 requires a Java 8 runtime.
@@ -96,7 +96,7 @@ As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstrac
(new C[Int]) sort ((a: Int, b: Int) => a - b) // ok
The first attempt fails because the type checker cannot infer the types for `_ - _`'s arguments anymore.
-Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments the methods are applied to. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
+Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments to which methods are applied. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
Finally, implicit conversion of SAM types to Function types won't kick in anymore, since the compiler does this conversion itself first:
diff --git a/_posts/2016-07-08-trait-method-performance.md b/_posts/2016-07-08-trait-method-performance.md
index 084eea49b..4ca996f7d 100644
--- a/_posts/2016-07-08-trait-method-performance.md
+++ b/_posts/2016-07-08-trait-method-performance.md
@@ -13,7 +13,7 @@ discourse: true
Since the writing of this post, we have made a lot of progress in narrowing down the performance
issue described. The most important new insights:
-- Jason has written a JMH-based test harness for measuring cold and hot perfromance of the Scala
+- Jason has written a JMH-based test harness for measuring cold and hot performance of the Scala
compiler ([scala/compiler-benchmark](https://github.com/scala/compiler-benchmark)). He used this
to show that the performance difference discussed in this post only affects cold performance,
i.e., startup time.
@@ -52,7 +52,7 @@ interface classfile. In short, we have the following bytecode formats for concre
extending a trait get a virtual method that implements the abstract method in the interface and
forwards to the static implementation method.
- 2.12.0-M4: trait method bodies are in (non-static) interface default methods, subclasses get an
- virtual method (overridding the default method) that forwards to that default method using
+ virtual method (overriding the default method) that forwards to that default method using
`invokespecial` (a `super` call).
- [33e7106](https://github.com/scala/scala/commit/33e7106): in most cases, no more forwarders are
generated in subclasses as they are not needed: the JVM will resolve the correct method.
@@ -63,7 +63,7 @@ interface classfile. In short, we have the following bytecode formats for concre
## Performance measurements
-Scala is unfortunately still lacking a proper infrastructure for montioring performance of the
+Scala is unfortunately still lacking a proper infrastructure for monitoring performance of the
compiler and the bytecode it generates. Improving this situation will be one of the main tasks once
Scala 2.12.0 out the door. But for now we are left with measuring performance and identifying
regressions by hand.
@@ -397,7 +397,7 @@ The benchmark basically measures the following loop:
int r = 0;
for (int x = 0; x < N; x++) {
c.v = x;
- r += c.v // field acces either through a default or a virtual method
+ r += c.v // field access either through a default or a virtual method
}
Comparing the assembly code of the loop when using the default method or the virtual method, Paolo
@@ -469,7 +469,7 @@ This code does the following:
- The loop counter is increased by the constant `0x10` (decimal 16), corresponding to the 16
unfolded iterations.
- The loop counter is compared against `0x3d9` (decimal 985): if it is smaller, another round of
- the unfolded loop can be executed (the loop ends at 1000). Otherwise execution continues in
+ the unfolded loop can be executed (the loop ends at 1000). Otherwise, execution continues in
a different location that performs single loop iterations.
The interesting observation here is that the field `c.v` is only written once per 16 iterations.
diff --git a/_posts/2016-07-20-sip-summary-minutes.md b/_posts/2016-07-20-sip-summary-minutes.md
index e9f7a5d5c..5e3cb5f8d 100644
--- a/_posts/2016-07-20-sip-summary-minutes.md
+++ b/_posts/2016-07-20-sip-summary-minutes.md
@@ -20,7 +20,7 @@ discussed.
The SIP committee went through five SIPs in the queue. Two new SIPs received a
number, meaning they passed the first phase of acceptance – that is, the change
-to Scala is accepted in theory, so long as the the committee's design and
+to Scala is accepted in theory, so long as the committee's design and
implementation concerns can be adequately addressed in subsequent discussions on
the SIP. The two SIPs which received numbers (first-round accepted) include:
diff --git a/_posts/2016-09-06-release-notes-2.12.0-RC1.md b/_posts/2016-09-06-release-notes-2.12.0-RC1.md
index b80f9e4f2..45574724a 100644
--- a/_posts/2016-09-06-release-notes-2.12.0-RC1.md
+++ b/_posts/2016-09-06-release-notes-2.12.0-RC1.md
@@ -27,7 +27,7 @@ The most notable changes since M5 are:
sbt instead of Ant (affects only contributors, not users)
In total, we merged [82 pull requests](https://github.com/scala/scala/pulls?q=is%3Apr+is%3Amerged+milestone%3A2.12.0-RC1), of which [6 are by new contributors](https://github.com/scala/scala/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Amerged%20milestone%3A2.12.0-RC1%20label%3Awelcome) -- welcome!
-This milestone resolves [25 JIRA tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-RC1%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC).
+This milestone resolves [25 Jira tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-RC1%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC).
As usual for Scala pre-releases, 2.12.0-RC1 is not binary compatible with any other Scala version, including any 2.12 milestones.
@@ -153,7 +153,7 @@ As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstrac
(new C[Int]) sort ((a: Int, b: Int) => a - b) // ok
The first attempt fails because the type checker cannot infer the types for `_ - _`'s arguments anymore.
-Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments the methods are applied to. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
+Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments to which methods are applied. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
Finally, implicit conversion of SAM types to Function types won't kick in anymore, since the compiler does this conversion itself first:
diff --git a/_posts/2016-10-18-release-notes-2.12.0-RC2.md b/_posts/2016-10-18-release-notes-2.12.0-RC2.md
index 76094b703..2e1963cf2 100644
--- a/_posts/2016-10-18-release-notes-2.12.0-RC2.md
+++ b/_posts/2016-10-18-release-notes-2.12.0-RC2.md
@@ -25,7 +25,7 @@ The [RC1 release notes](https://scala-lang.org/news/2.12.0-RC1) have a list of i
In total, we merged [29 pull requests](https://github.com/scala/scala/pulls?q=is%3Apr+is%3Amerged+milestone%3A2.12.0-RC2).
-This milestone resolves [6 JIRA tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-RC2%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC) and [9 scala-dev issues](https://github.com/scala/scala-dev/milestone/9?closed=1).
+This milestone resolves [6 Jira tickets](https://issues.scala-lang.org/issues/?jql=project%20%3D%20SI%20AND%20status%20%3D%20CLOSED%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%22Scala%202.12.0-RC2%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC) and [9 scala-dev issues](https://github.com/scala/scala-dev/milestone/9?closed=1).
As usual for Scala pre-releases, 2.12.0-RC2 is not guaranteed to be binary compatible with any other Scala version, including any 2.12 milestones and release candidates.
diff --git a/_posts/2016-11-30-spores-release.md b/_posts/2016-11-30-spores-release.md
index 95404af5a..991c3c683 100644
--- a/_posts/2016-11-30-spores-release.md
+++ b/_posts/2016-11-30-spores-release.md
@@ -21,7 +21,7 @@ this problem.
Spores provide a way to control what a closures captures, and thus
hopes to make it easier to operate with them in concurrent and distributed
-enviornments. The key idea is to capture more type information than a standard
+environments. The key idea is to capture more type information than a standard
closure, and to use this type information to have more fine-grained control over
the closures's environment.
@@ -49,7 +49,7 @@ spores use type information to figure out whether or not something can be
serialized at compile time, how can this work with Java Serialization?
To achieve this, previously, spores required Scala Pickling to transitively
-check the entire enviornment was able to be serialized, statically, at
+check the entire environment was able to be serialized, statically, at
compile-time. However, we now wish to perform this check instead for Java
Serialization, as Java Serialization is most often used by developers.
diff --git a/_posts/2017-09-11-scalafix-v0.5.md b/_posts/2017-09-11-scalafix-v0.5.md
index 62210d575..043189f93 100644
--- a/_posts/2017-09-11-scalafix-v0.5.md
+++ b/_posts/2017-09-11-scalafix-v0.5.md
@@ -179,7 +179,7 @@ Next steps for Scalafix include:
* more linting rules. I would love to unite efforts with Scalastyle and
Wartremover to offer an extensive set of linting rules in a single tool.
Scalafix can definitely benefit from their experience in this space.
-* more complete `Sbt1` rewrite to accellerate sbt 1.0 migration, see
+* more complete `Sbt1` rewrite to accelerate sbt 1.0 migration, see
[sbtfix issues][].
* more polished integrations. Currently, running Scalafix in a large project
typically results in many spurious errors and warnings.
diff --git a/_posts/2017-11-13-security-update.md b/_posts/2017-11-13-security-update.md
index eb12f81e3..184355958 100644
--- a/_posts/2017-11-13-security-update.md
+++ b/_posts/2017-11-13-security-update.md
@@ -12,7 +12,7 @@ We recommend upgrading to the latest versions of Scala ([Scala 2.12.4](https://g
The compile daemon is started explicitly by the `fsc` command, or implicitly by executing
-a Scala source file as a script (e.g `scala MyScript.scala`). The Scala REPL, started by `scala` is not affected as it does not use the compilation daemon, nor is running a pre-compiled class using the `scala` command.
+a Scala source file as a script (e.g `scala MyScript.scala`). The Scala REPL, started by `scala` is not affected as it neither uses the compilation daemon nor runs a pre-compiled classes using the `scala` command.
# Impact
diff --git a/_posts/2017-12-01-fifth-dotty-milestone-release.md b/_posts/2017-12-01-fifth-dotty-milestone-release.md
index fd09b1632..a760cb166 100644
--- a/_posts/2017-12-01-fifth-dotty-milestone-release.md
+++ b/_posts/2017-12-01-fifth-dotty-milestone-release.md
@@ -45,7 +45,7 @@ This query would now be classified as ambiguous. This makes sense, after all
there are two possible solutions, `b(a1)` and `b(a2)`, neither of which is better
than the other and both of which are better than the third solution, `c`.
By contrast, Scala 2 would have rejected the search for `A` as
-ambiguous, and subsequently have classified the query `b(implictly[A])` as a normal fail,
+ambiguous, and subsequently have classified the query `b(implicitly[A])` as a normal fail,
which means that the alternative `c` would be chosen as solution!
Scala 2's somewhat puzzling behavior with respect to ambiguity has been exploited to implement
@@ -130,7 +130,7 @@ Using sbt 0.13.13 or newer, do:
sbt new lampepfl/dotty.g8
```
-This will setup a new sbt project with Dotty as compiler. For more details on
+This will set up a new sbt project with Dotty as compiler. For more details on
using Dotty with sbt, see the
[example project](https://github.com/lampepfl/dotty-example-project).
diff --git a/_posts/2018-06-05-collections-feature-freeze.md b/_posts/2018-06-05-collections-feature-freeze.md
index 578164237..225b69c70 100644
--- a/_posts/2018-06-05-collections-feature-freeze.md
+++ b/_posts/2018-06-05-collections-feature-freeze.md
@@ -24,4 +24,4 @@ Note that [binary compatibility](https://docs.scala-lang.org/overviews/core/bina
## Ecosystem update
-Adoption of Scala 2.13.0-M4 so far has been slower than for most milestones because the number of source incompatibilities is higher than usual. We hope that an early feature freeze and further compatibility improvements will make it easier for core projects to upgrade to M5 (whether they are already on M4 or not) in order to bootstrap the Scala ecosystem in preparation for the 2.13.0 release.
+Adoption of Scala 2.13.0-M4 so far has been slower than for most milestones because the number of source incompatibilities is greater than usual. We hope that an early feature freeze and further compatibility improvements will make it easier for core projects to upgrade to M5 (whether they are already on M4 or not) in order to bootstrap the Scala ecosystem in preparation for the 2.13.0 release.
diff --git a/_posts/2019-01-18-community-build.md b/_posts/2019-01-18-community-build.md
index d0b773bc3..3175dc9c2 100644
--- a/_posts/2019-01-18-community-build.md
+++ b/_posts/2019-01-18-community-build.md
@@ -15,7 +15,7 @@ The community build is used to test changes to the Scala compiler,
enabling Scala the language and Scala the ecosystem of libraries to
evolve in tandem with each other.
-This post highlights the progress the community build has made in the
+This post highlights the progress that the community build has made in the
last year.
## Overall growth
@@ -99,7 +99,7 @@ See [last year's blog
post](https://github.com/scala/community-build/issues/796). The
links it contains are still valid.
-And what about about Scala 3? As the Dotty team [tells us](https://dotty.epfl.ch/blog/2018/11/30/11th-dotty-milestone-release.html), "Dotty now has
+And what about Scala 3? As the Dotty team [tells us](https://dotty.epfl.ch/blog/2018/11/30/11th-dotty-milestone-release.html), "Dotty now has
a set of widely-used community libraries that are built against every
nightly Dotty snapshot. Currently this includes ScalaPB, algebra,
scalatest, scopt and squants. Join our community build to make sure
diff --git a/_posts/2020-02-20-community-build.md b/_posts/2020-02-20-community-build.md
index c0163591d..fa2680b42 100644
--- a/_posts/2020-02-20-community-build.md
+++ b/_posts/2020-02-20-community-build.md
@@ -16,7 +16,7 @@ from January 2018, still applies.
A year ago, we [updated
you](https://www.scala-lang.org/2019/01/18/community-build.html) on
improvements made up through January 2019. The post you are reading
-highlights the progress the community build has made since then.
+highlights the progress that the community build has made since then.
In short, we believe **the Scala 2 community build is now essentially
complete**. Still, we will continue to run and maintain it throughout
diff --git a/_posts/2020-11-03-scalajs-for-scala-3.md b/_posts/2020-11-03-scalajs-for-scala-3.md
index ea3d99b90..3cd7bb754 100644
--- a/_posts/2020-11-03-scalajs-for-scala-3.md
+++ b/_posts/2020-11-03-scalajs-for-scala-3.md
@@ -6,7 +6,7 @@ title: "Implementing Scala.js Support for Scala 3"
---
These days, the JS platform has become an integral part of the language.
-Yet, until last August, support for Scala.js in Scala 3 was close to non-existent.
+Yet, until last August, support for Scala.js in Scala 3 was close to nonexistent.
A first preview was shipped in Dotty 0.27.0-RC1, with support for the portable subset of Scala and native JS types.
Since then, support for non-native JS types was added and will ship as part of Scala 3.0.0-M1.
The only missing feature left is JS exports, which we will implement by the next milestone.
@@ -95,7 +95,7 @@ TASTy has a very different level of abstraction than the Scala.js IR.
During the compilation pipeline, the compiler first type-checks and elaborates Scala source code into a TASTy-level representation (even in Scala 2, although it is not TASTy itself).
Then, a few dozens of phases successively transform that representation to eliminate Scala features and erase the type system.
-It is only at the end of that process that Scala/JVM produces `.class` files while Scala.js procudes `.sjsir` files.
+It is only at the end of that process that Scala/JVM produces `.class` files while Scala.js produces `.sjsir` files.
We *can* compile from TASTy to JavaScript, but that does not take away the fact that we have to perform all those phases again.
There is no shortcut.
diff --git a/_posts/2020-11-06-explicit-term-inference-in-scala-3.md b/_posts/2020-11-06-explicit-term-inference-in-scala-3.md
index 49fad2e37..90f2d321d 100644
--- a/_posts/2020-11-06-explicit-term-inference-in-scala-3.md
+++ b/_posts/2020-11-06-explicit-term-inference-in-scala-3.md
@@ -35,7 +35,7 @@ Scala 3 allows you to define an *extension method*.
Assume that you are working with `List[Try[String]]` and that you often need to retrieve
the elements for which the computation succeeded.
-Then you can extend this type to have a `collectSucceded` method:
+Then you can extend this type to have a `collectSucceeded` method:
```scala
// ListTryOps.scala
@@ -426,7 +426,7 @@ they would look like in Scala 3. While the final result is almost the same, code
explicit and readable so that you can focus on solving your business problems rather than on
syntax.
-This is part of a larger set of usability and ergonomy improvements for Scala 3 that we believe
+This is part of a larger set of usability and ergonomic improvements for Scala 3 that we believe
will make the language easier and more fun to use and we are very excited to see what the
community will create with them.
diff --git a/_posts/2021-01-12-configuring-and-suppressing-warnings.md b/_posts/2021-01-12-configuring-and-suppressing-warnings.md
index 4c992b4f6..60c1bdc40 100644
--- a/_posts/2021-01-12-configuring-and-suppressing-warnings.md
+++ b/_posts/2021-01-12-configuring-and-suppressing-warnings.md
@@ -146,7 +146,7 @@ Test.scala:4: error: method → in class ArrowAssoc is deprecated [...]
Note that the `-Wconf:...` compiler argument is between quotes (`'`) in the command line, which prevents the shell from interpreting characters like `&` or `*`.
-For some of the filters the syntax is not trivial, so we look at them in more detail.
+The syntax is not trivial for some of the filters so we look at them in more detail.
* **Message category**: Every message has a category that is displayed in verbose mode (`-Wconf:any:wv`). The `-Wconf:help` option displays the full list of available categories. For example, every `-Xlint` warning has its own category (`lint-infer-any`), the super-category `lint` matches all lint warnings.
* **Source file**: By default, the source file filter is a regex that must match the file path relative to any path segment. For example, `b/.*Test.scala` matches `/a/b/XTest.scala` but not `/ab/Test.scala`. If the `-rootdir` compiler option is specified, the regex must match the file path relative to that root directory.
diff --git a/_posts/2021-02-26-tuples-bring-generic-programming-to-scala-3.md b/_posts/2021-02-26-tuples-bring-generic-programming-to-scala-3.md
index f3b034cf8..47cc5577b 100644
--- a/_posts/2021-02-26-tuples-bring-generic-programming-to-scala-3.md
+++ b/_posts/2021-02-26-tuples-bring-generic-programming-to-scala-3.md
@@ -302,8 +302,8 @@ type Concat[L <: Tup, R <: Tup] <: Tup = L match
You can see that the implementation closely follows the one above for the
method. The syntax can be read in the following way: the `Concat` type is a
subtype of `Tup` and is obtained by combining types `L` and `R` which are both
-subtypes of `Tup`. To use it we need to massage a bit the method
-implementation and to change its return type:
+subtypes of `Tup`. To use it we need to massage the method implementation a
+bit and to change its return type:
```scala
def concat[L <: Tup, R <: Tup](left: L, right: R): Concat[L, R] =
diff --git a/_posts/2021-03-08-scala-3-developers-preview-survey-results.md b/_posts/2021-03-08-scala-3-developers-preview-survey-results.md
index b41d78e47..68bdb5045 100644
--- a/_posts/2021-03-08-scala-3-developers-preview-survey-results.md
+++ b/_posts/2021-03-08-scala-3-developers-preview-survey-results.md
@@ -79,7 +79,7 @@ With all that said, our approach to analyse the results is as follows:
- Presenting the quantifiable data
- Categorizing comments to provide further insight into the topics discussed;
the purpose of the comment, such as: ‘advice’, ‘concern’, ‘request’;
- overall tone: either positive or negative; to prioritise what needs addressing/fixing
+ overall tone: either positive or negative; to prioritize what needs addressing/fixing
before RC1 or at later time, e.g. ‘critical’ or ‘good to have’.
- Cross-referencing comments with other sources on the same topic.
- Finally, creating a list of important topics that need to be addressed.
@@ -104,7 +104,7 @@ with 28.2% Neutral responses being the smallest proportion of answered responses
#### Potential issues with the poll
In hindsight, we should have requested feedback directly about generic tuples in Scala 3.
-Otherwise, their excitement can not be judged separately from the utility they bring
+Otherwise, their excitement cannot be judged separately from the utility they bring
to features such as Typeclass Derivation, Match Types, and Inline.
#### Comments From Participants
@@ -216,8 +216,7 @@ compiler options. However we received 7 requests for the `-Xlint` options,
### Communication

-We asked participants the question “How frequently do you use the following c
-ommunication channels to stay up-to-date on the latest changes in Scala?”,
+We asked participants the question “How frequently do you use the following communication channels to stay up-to-date on the latest changes in Scala?”,
the results of which are displayed in the above chart. It is sorted in descending
order based on the total counts for the Very Often and Often responses.
diff --git a/_posts/2021-03-11-gsoc-2021-here-we-come.md b/_posts/2021-03-11-gsoc-2021-here-we-come.md
index a66c498d2..2ef3c6b44 100644
--- a/_posts/2021-03-11-gsoc-2021-here-we-come.md
+++ b/_posts/2021-03-11-gsoc-2021-here-we-come.md
@@ -32,7 +32,7 @@ These are especially exciting times: Scala 3-RC1 has been released mid-February
enjoy the fresh new approach!
-If you are an eligible student and are interested in participing in Scala's
+If you are an eligible student and are interested in participating in Scala's
Google Summer of Code 2021, you can begin discussing project ideas with our
mentors. Then you have from March 29 to April 13 to submit your draft
proposals through [the program website](https://summerofcode.withgoogle.com/organizations/5449337515016192/).
diff --git a/_posts/2021-09-27-gsoc-conclusion.md b/_posts/2021-09-27-gsoc-conclusion.md
index b86fb78c9..c44696589 100644
--- a/_posts/2021-09-27-gsoc-conclusion.md
+++ b/_posts/2021-09-27-gsoc-conclusion.md
@@ -78,7 +78,7 @@ powerful and well known Python libraries. You can read more
cit. Shadaj
-A special thanks goes to **Zhendong Ang** who co-menthored Mykola and
+A special thanks goes to **Zhendong Ang** who co-mentored Mykola and
collaborated on the project for his semester project at EPFL.
### A Python - Scala integrated environment with Almond, Ammonite and ScalaPy
diff --git a/_posts/2023-02-28-acceptd-to-gsoc-2023.md b/_posts/2023-02-28-accepted-to-gsoc-2023.md
similarity index 100%
rename from _posts/2023-02-28-acceptd-to-gsoc-2023.md
rename to _posts/2023-02-28-accepted-to-gsoc-2023.md
diff --git a/_posts/2023-07-17-signature-polymorphic-methods.md b/_posts/2023-07-17-signature-polymorphic-methods.md
index 652546d7b..c5c556ab7 100644
--- a/_posts/2023-07-17-signature-polymorphic-methods.md
+++ b/_posts/2023-07-17-signature-polymorphic-methods.md
@@ -171,7 +171,7 @@ writeup on Stack Overflow].)
Jason Zaugg describes his initial JDK 7 implementation in [PR 4139]
and shows how the resulting bytecode looks.
-See also these well-documented followups: [PR 5594] for JDK 9,
+See also these well-documented follow ups: [PR 5594] for JDK 9,
[PR 9530] for JDK 11, and [PR 9930] for JDK 17.
[PR 4139]: https://github.com/scala/scala/pull/4139
diff --git a/_posts/2024-10-16-announcing-governance.md b/_posts/2024-10-16-announcing-governance.md
index 4ff73f53d..a724cac6e 100644
--- a/_posts/2024-10-16-announcing-governance.md
+++ b/_posts/2024-10-16-announcing-governance.md
@@ -34,7 +34,7 @@ If you are wondering how these matters impact your daily life as a Scala program
### Product-driven decision making process
-One of the most significant updates was the paradigm shift from treating Scala 3 as an open-source project to approaching it as an open-source product. Scala 3 is developed with predictable release cycles, issue reports are consistently prioritised and added to a milestone, and the roadmap for new features and improvements is well-defined. This focus on product success is fully reflected in the governance model and structure, led by the Product Manager, Piotr Chabelski from the Scala team at VirtusLab. This approach was inspired by the Scala 2 era and its ongoing success.
+One of the most significant updates was the paradigm shift from treating Scala 3 as an open-source project to approaching it as an open-source product. Scala 3 is developed with predictable release cycles, issue reports are consistently prioritized and added to a milestone, and the roadmap for new features and improvements is well-defined. This focus on product success is fully reflected in the governance model and structure, led by the Product Manager, Piotr Chabelski from the Scala team at VirtusLab. This approach was inspired by the Scala 2 era and its ongoing success.
### Well defined Scala distributions
diff --git a/_posts/2024-10-24-post-mortem-3.6.0.md b/_posts/2024-10-24-post-mortem-3.6.0.md
index 30181f54f..2659a4639 100644
--- a/_posts/2024-10-24-post-mortem-3.6.0.md
+++ b/_posts/2024-10-24-post-mortem-3.6.0.md
@@ -113,7 +113,7 @@ of multiple factors:
will be implemented as an improvement. The change was added in
[scala3\#21011](https://github.com/scala/scala3/pull/21011).
- The change introducing the issue was merged on the 11th of July. Now, three
- months later, at the time of the release the side effects were not properly
+ months later, at the time of the release, the side effects were not properly
considered as in the meantime there was a change in staff coupled with
insufficient documentation.
- We experienced unrelated downtime on the side of our infrastructure, which
diff --git a/_posts/2024-12-10-release-notes-3.6.2.md b/_posts/2024-12-10-release-notes-3.6.2.md
index b5790778d..92d2baf1b 100644
--- a/_posts/2024-12-10-release-notes-3.6.2.md
+++ b/_posts/2024-12-10-release-notes-3.6.2.md
@@ -20,7 +20,7 @@ We apologize to the Scala users for any inconvenience it might have caused.
# What’s new in Scala 3.6?
-Besides multiple bugfixes, this release stabilises multiple experimental features introduced to the Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new possibilities in writing concise, typesafe as well as easier, and easier to maintain code.
+Besides multiple bugfixes, this release stabilises multiple experimental features introduced to the Scala language after careful review and acceptance by the [Scala Improvement Proposal's Committee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new possibilities in writing concise, typesafe as well as easier, and easier to maintain code.
## SIP-47 - Clause Interleaving
@@ -142,7 +142,7 @@ It also introduces changes to how your code is desugared by the compiler, leadin
## Experimental SIP-57 - Replace non-sensical `@unchecked` annotations
-One of the new, experimental, features is the implementation of [SIP-57](https://docs.scala-lang.org/sips/replace-nonsensical-unchecked-annotation.html) introducing a `runtimeChecked` extension method replacing some usages of `@unchecked` annotation using a more convenient syntax. A common use case for `runtimeChecked` is to assert that a pattern will always match, either for convenience or because there is a known invariant that the types can not express.
+One of the new, experimental, features is the implementation of [SIP-57](https://docs.scala-lang.org/sips/replace-nonsensical-unchecked-annotation.html) introducing a `runtimeChecked` extension method replacing some usages of `@unchecked` annotation using a more convenient syntax. A common use case for `runtimeChecked` is to assert that a pattern will always match, either for convenience or because there is a known invariant that the types cannot express.
Some typical use cases might be looking up an expected entry in a dynamically loaded dictionary-like structure:
diff --git a/_posts/2025-05-07-release-notes-3.7.0.md b/_posts/2025-05-07-release-notes-3.7.0.md
index d0573cc33..3ba1d79d9 100644
--- a/_posts/2025-05-07-release-notes-3.7.0.md
+++ b/_posts/2025-05-07-release-notes-3.7.0.md
@@ -22,7 +22,7 @@ Named Tuples, introduced as experimental in Scala 3.5, are now a stable feature.
Named tuples are a convenient lightweight way to return multiple results from a function or to model the data using tuples while allowing you to use meaningful names for its fields.
```scala
-@main def meaningfullReturnTypes =
+@main def meaningfulReturnTypes =
extension [T](seq: Seq[T])
inline def partitionBy(predicate: PartialFunction[T, Boolean]): (matching: Seq[T], unmatched: Seq[T]) =
seq.partition(predicate.unapply(_).getOrElse(false))
@@ -153,7 +153,7 @@ The code above previously required `a` to be defined outside the for-comprehensi
}.map { case (b, c) => c }
```
-With SIP-52 the same snippet would be desugared to simpler and more efficent code:
+With SIP-52 the same snippet would be desugared to simpler and more efficient code:
```Scala
Some(2).map { b =>
@@ -246,7 +246,7 @@ Starting with Scala 3.7 the expression compiler has been migrated to the main [s
### Presentation Compiler: Show inferred type on holes in hover ([#21423](https://github.com/scala/scala3/pull/21423))
The presentation compiler is a special mode of the Scala compiler that runs interactively and is used by IDEs and language servers such as Metals. It provides immediate feedback about code correctness, type checking, symbol resolution, autocompletion, error highlighting, and other editing support functionalities.
-Some of the latest improvements to the presentation compiler focus on the ability to infer more information about expected types of expressions provided by the users. As a result, presentation compiler can now show the users the expected type of expression when hovering over so called `type holes`.
+Some of the latest improvements to the presentation compiler focus on the ability to infer more information about expected types of expressions provided by the users. As a result, presentation compiler can now show users the expected type of expression when hovering over so called `type holes`.
```scala
def someMethod(count: Int, label: String): Unit = ???
diff --git a/_sass/components/tab.scss b/_sass/components/tab.scss
index 8207f3eb5..779139c4c 100755
--- a/_sass/components/tab.scss
+++ b/_sass/components/tab.scss
@@ -2,7 +2,7 @@
//------------------------------------------------
//------------------------------------------------
-// dynamic tab switching based on https: //levelup.gitconnected.com/tabbed-interfaces-without-javascript-661bab1eaec8
+// dynamic tab switching based on https://levelup.gitconnected.com/tabbed-interfaces-without-javascript-661bab1eaec8
.nav-tab {
border-bottom: $base-border-gray;
diff --git a/_sass/layout/navigation.scss b/_sass/layout/navigation.scss
index 582b282ad..72d59f82a 100755
--- a/_sass/layout/navigation.scss
+++ b/_sass/layout/navigation.scss
@@ -8,13 +8,13 @@
@include flex-direction(row);
@include align-items(center);
@include justify-content(space-between);
- .navigation-bdand {
+ .navigation-band {
img {
width: 104px;
height: 43px;
}
}
- .navigation-bdand-vfill-lg {
+ .navigation-band-vfill-lg {
height: 49px;
}
.navigation-panel-button {
diff --git a/_sass/layout/scala-ecosystem.scss b/_sass/layout/scala-ecosystem.scss
index 3956773ce..b8da86536 100755
--- a/_sass/layout/scala-ecosystem.scss
+++ b/_sass/layout/scala-ecosystem.scss
@@ -1,4 +1,4 @@
-// SCALA ECOSISTEM
+// SCALA ECOSYSTEM
//------------------------------------------------
//------------------------------------------------
diff --git a/_sass/vendors/bourbon/css3/_linear-gradient.scss b/_sass/vendors/bourbon/css3/_linear-gradient.scss
index 9e8163335..8f3d1f7b5 100755
--- a/_sass/vendors/bourbon/css3/_linear-gradient.scss
+++ b/_sass/vendors/bourbon/css3/_linear-gradient.scss
@@ -24,7 +24,7 @@
$full: $g1, $g2, $g3, $g4, $g5, $g6, $g7, $g8, $g9, $g10;
- // Set $g1 as the default fallback color
+ // Set $g1 as the fallback color
$fallback-color: nth($g1, 1);
// If $fallback is a color use that color as the fallback color
diff --git a/_sass/vendors/bourbon/css3/_radial-gradient.scss b/_sass/vendors/bourbon/css3/_radial-gradient.scss
index 18f7b5b58..44b80d06e 100755
--- a/_sass/vendors/bourbon/css3/_radial-gradient.scss
+++ b/_sass/vendors/bourbon/css3/_radial-gradient.scss
@@ -19,7 +19,7 @@
// Strip deprecated cover/contain for spec
$shape-size-spec: _shape-size-stripper($shape-size);
- // Set $g1 as the default fallback color
+ // Set $g1 as the fallback color
$first-color: nth($full, 1);
$fallback-color: nth($first-color, 1);
diff --git a/_sass/vendors/bourbon/css3/_transition.scss b/_sass/vendors/bourbon/css3/_transition.scss
index 3c785ed52..ddfbebfb3 100755
--- a/_sass/vendors/bourbon/css3/_transition.scss
+++ b/_sass/vendors/bourbon/css3/_transition.scss
@@ -1,4 +1,4 @@
-// Shorthand mixin. Supports multiple parentheses-deliminated values for each variable.
+// Shorthand mixin. Supports multiple parentheses-delimited values for each variable.
// Example: @include transition (all 2s ease-in-out);
// @include transition (opacity 1s ease-in 2s, width 2s ease-out);
// @include transition-property (transform, opacity);
diff --git a/_sass/vendors/bourbon/functions/_is-light.scss b/_sass/vendors/bourbon/functions/_is-light.scss
index 92d90ac3c..588910031 100755
--- a/_sass/vendors/bourbon/functions/_is-light.scss
+++ b/_sass/vendors/bourbon/functions/_is-light.scss
@@ -1,6 +1,6 @@
@charset "UTF-8";
-/// Programatically determines whether a color is light or dark.
+/// Programmatically determines whether a color is light or dark.
///
/// @link http://robots.thoughtbot.com/closer-look-color-lightness
///
diff --git a/_sass/vendors/neat/grid/_outer-container.scss b/_sass/vendors/neat/grid/_outer-container.scss
index d3f626743..c84842df8 100755
--- a/_sass/vendors/neat/grid/_outer-container.scss
+++ b/_sass/vendors/neat/grid/_outer-container.scss
@@ -1,6 +1,6 @@
@charset "UTF-8";
-/// Makes an element a outer container by centering it in the viewport, clearing its floats, and setting its `max-width`.
+/// Makes an element into an outer container by centering it in the viewport, clearing its floats, and setting its `max-width`.
/// Although optional, using `outer-container` is recommended. The mixin can be called on more than one element per page, as long as they are not nested.
///
/// @param {Number [unit]} $local-max-width [$max-width]
diff --git a/_sass/vendors/neat/grid/_span-columns.scss b/_sass/vendors/neat/grid/_span-columns.scss
index a7f9b0031..74c120ae7 100755
--- a/_sass/vendors/neat/grid/_span-columns.scss
+++ b/_sass/vendors/neat/grid/_span-columns.scss
@@ -5,7 +5,7 @@
/// @param {List} $span
/// A list containing `$columns`, the unitless number of columns the element spans (required), and `$container-columns`, the number of columns the parent element spans (optional).
///
-/// If only one value is passed, it is assumed that it's `$columns` and that that `$container-columns` is equal to `$grid-columns`, the total number of columns in the grid.
+/// If only one value is passed, it is assumed that it's `$columns` and that `$container-columns` is equal to `$grid-columns`, the total number of columns in the grid.
///
/// The values can be separated with any string such as `of`, `/`, etc.
///
diff --git a/_sass/vendors/neat/grid/_to-deprecate.scss b/_sass/vendors/neat/grid/_to-deprecate.scss
index aeea0795b..45bd22580 100755
--- a/_sass/vendors/neat/grid/_to-deprecate.scss
+++ b/_sass/vendors/neat/grid/_to-deprecate.scss
@@ -85,7 +85,7 @@
/// @example scss - Usage
/// .element {
/// @include row(table, RTL);
-/// // Context changed to table table and right-to-left
+/// // Context changed to table and right-to-left
/// }
///
/// @include reset-all;
diff --git a/_scala_use_case_items/1-backend.md b/_scala_use_case_items/1-backend.md
index 7798d6d98..6fee4b8f9 100644
--- a/_scala_use_case_items/1-backend.md
+++ b/_scala_use_case_items/1-backend.md
@@ -46,7 +46,7 @@ def fetch2 = fetchWeather(server2) // expensive Network IO
-
Compute accross distributed nodes with Akka actors
+
Compute across distributed nodes with Akka actors
def Device(lastTemp: Option[Double]): Behavior[Message] =
Behaviors.receiveMessage:
case RecordTemperature(id, value, replyTo) =>
diff --git a/_trainings/2015-03-15-essential-essential-scala.md b/_trainings/2015-03-15-essential-essential-scala.md
index 6f803c57e..471c502b5 100644
--- a/_trainings/2015-03-15-essential-essential-scala.md
+++ b/_trainings/2015-03-15-essential-essential-scala.md
@@ -1,7 +1,7 @@
---
-title: Essential Essential Scala
+title: Creative Scala
description: A free and fun taste of Scala. Places available for students and teaching assistants.
-link-out: http://underscore.io/events/2015-03-15-essential-essential-scala.html
+link-out: http://underscore.io/events/2015-03-15-creative-scala.html
location: San Francisco
when: 15 March 2015
trainers: Noel Welsh
diff --git a/_trainings/2015-03-28-essential-essential-scala.html b/_trainings/2015-03-28-essential-essential-scala.html
index cb2f79522..d7fc0f685 100644
--- a/_trainings/2015-03-28-essential-essential-scala.html
+++ b/_trainings/2015-03-28-essential-essential-scala.html
@@ -1,7 +1,7 @@
---
-title: Essential Essential Scala
+title: Creative Scala
description: A free and fun taste of Scala.
-link-out: http://underscore.io/events/2015-03-28-essential-essential-scala.html
+link-out: http://underscore.io/events/2015-03-28-creative-scala.html
location: Edinburgh
when: 28 March 2015
trainers: Noel Welsh
diff --git a/_why_scala_items/2-versatile.md b/_why_scala_items/2-versatile.md
index 6a3fa29a5..3655307c7 100644
--- a/_why_scala_items/2-versatile.md
+++ b/_why_scala_items/2-versatile.md
@@ -1,4 +1,4 @@
---
shortTitle: "Scalable"
-shortDescription: "Scala is well suited to building fast, concurrent, and distributed systems with its JVM, JavaScript and Native runtimes. Scala prioritises interoperability, giving easy access to many ecosystems of industry-proven libraries."
+shortDescription: "Scala is well suited to building fast, concurrent, and distributed systems with its JVM, JavaScript and Native runtimes. Scala prioritizes interoperability, giving easy access to many ecosystems of industry-proven libraries."
---
diff --git a/blog/_posts/2017-03-13-spark-mooc-capstone-live-on-coursera.md b/blog/_posts/2017-03-13-spark-mooc-capstone-live-on-coursera.md
index 01114267b..a7ba7417d 100644
--- a/blog/_posts/2017-03-13-spark-mooc-capstone-live-on-coursera.md
+++ b/blog/_posts/2017-03-13-spark-mooc-capstone-live-on-coursera.md
@@ -15,7 +15,7 @@ Coursera!
The [Big Data Analysis with Scala and
Spark](https://www.coursera.org/learn/scala-spark-big-data) course is 4 weeks
long, and aims to teach those coming from Scala the basics of distributed
-computation using Apache Spark. It's more than whirlwhind tour of Spark's basic
+computation using Apache Spark. It's more than whirlwind tour of Spark's basic
APIs – this course aims to teach you fundamentally what is going on when you're
doing a distributed job, and it goes all the way from the basics of RDDs to
intermediate/advanced topics such as tweaking for data locality or writing your
diff --git a/blog/_posts/2017-05-19-scastie.md b/blog/_posts/2017-05-19-scastie.md
index 2aa34c617..78dd8163d 100644
--- a/blog/_posts/2017-05-19-scastie.md
+++ b/blog/_posts/2017-05-19-scastie.md
@@ -80,7 +80,7 @@ ones.
### Scala.js
-Since the intial release of our beta, we also added support for Scala.js! In Scala.js mode, once your code is compiled, your snippet is run in your browser.
+Since the initial release of our beta, we also added support for Scala.js! In Scala.js mode, once your code is compiled, your snippet is run in your browser.
HTML DOM elements referred in your code such as images appears in the editor for convenience. This feature is illustrated in this example: [such doge!](https://scastie.scala-lang.org/MasseGuillaume/KuKtYXx1SpW7gu5HUTmPSA/1).
@@ -103,7 +103,7 @@ Dmitrii Petukhov was accepted as a Google Summer of Code student to work on
information](https://summerofcode.withgoogle.com/organizations/4568241046290432/#5494264097144832).
Rory Graves, an ENSIME contributor, is the mentor for this project. ENSIME is an
IDE server. It can power text editors such as vim an eclipse with IDE
-functionnalities such as autocompletion.
+functionalities such as autocompletion.
### Scala Center's Plan
diff --git a/blog/_posts/2017-05-26-whats-new-scala-native.md b/blog/_posts/2017-05-26-whats-new-scala-native.md
index f28f54238..75f6164b7 100644
--- a/blog/_posts/2017-05-26-whats-new-scala-native.md
+++ b/blog/_posts/2017-05-26-whats-new-scala-native.md
@@ -163,7 +163,7 @@ a better integration with sbt and more additions to the standard library.
The first releases of Scala Native use Boehm GC. A new and improved garbage
collector has been under development by [@LukasKellenberger][@LukasKellenberger]
and will be presented at [Scala Days during Denys' talk][denys-talk]. Stay
-tuned for more more details to come soon!
+tuned; more details to come soon!
The pull request introducing the new garbage collector can be found in
[#726][#726].
diff --git a/blog/_posts/2017-05-30-tribulations-canbuildfrom.md b/blog/_posts/2017-05-30-tribulations-canbuildfrom.md
index 5c5d343a7..359a89475 100644
--- a/blog/_posts/2017-05-30-tribulations-canbuildfrom.md
+++ b/blog/_posts/2017-05-30-tribulations-canbuildfrom.md
@@ -50,7 +50,7 @@ def map[B, That](f: Char => B)(implicit bf: CanBuildFrom[String, B, That]): That
When the implicit `CanBuildFrom` parameter is resolved it fixes the return type `That`.
The resolution is driven by the actual `B` type: if `B` is `Char` then `That` is fixed
-to `String`, otherwise it is `immutable.IndexedSeq`.
+to `String`; otherwise, it is `immutable.IndexedSeq`.
The drawback of this solution is that the type signature of the `map` method looks cryptic.
@@ -157,7 +157,7 @@ trait SortedIterableOps[A, CC[_]] {
}
~~~
-However, as mentioned in the previous section, we need to also abstract over the kind of the
+However, as mentioned in the previous section, we also need to abstract over the kind of the
type constructor of the concrete collections. Consequently we have in total four branches:
kind | not sorted | sorted
diff --git a/blog/_posts/2017-05-31-first-dotty-milestone-release.md b/blog/_posts/2017-05-31-first-dotty-milestone-release.md
index 03e9f21d4..1ae566c68 100644
--- a/blog/_posts/2017-05-31-first-dotty-milestone-release.md
+++ b/blog/_posts/2017-05-31-first-dotty-milestone-release.md
@@ -39,7 +39,7 @@ Using sbt 0.13.13 or newer, do:
sbt new lampepfl/dotty.g8
```
-This will setup a new sbt project with Dotty as compiler. For more details on
+This will set up a new sbt project with Dotty as compiler. For more details on
using Dotty with sbt, see the
[example project](https://github.com/lampepfl/dotty-example-project).
diff --git a/blog/_posts/2017-07-12-second-dotty-milestone-release.md b/blog/_posts/2017-07-12-second-dotty-milestone-release.md
index 3bc494f1c..2261151e3 100644
--- a/blog/_posts/2017-07-12-second-dotty-milestone-release.md
+++ b/blog/_posts/2017-07-12-second-dotty-milestone-release.md
@@ -306,7 +306,7 @@ Using sbt 0.13.13 or newer, do:
sbt new lampepfl/dotty.g8
```
-This will setup a new sbt project with Dotty as compiler. For more details on
+This will set up a new sbt project with Dotty as compiler. For more details on
using Dotty with sbt, see the
[example project](https://github.com/lampepfl/dotty-example-project).
diff --git a/blog/_posts/2017-09-07-third-dotty-milestone-release.md b/blog/_posts/2017-09-07-third-dotty-milestone-release.md
index f9f383a72..5669b7bda 100644
--- a/blog/_posts/2017-09-07-third-dotty-milestone-release.md
+++ b/blog/_posts/2017-09-07-third-dotty-milestone-release.md
@@ -55,7 +55,7 @@ Using sbt 0.13.13 or newer, do:
sbt new lampepfl/dotty.g8
```
-This will setup a new sbt project with Dotty as compiler. For more details on
+This will set up a new sbt project with Dotty as compiler. For more details on
using Dotty with sbt, see the
[example project](https://github.com/lampepfl/dotty-example-project).
diff --git a/blog/_posts/2017-10-16-fourth-dotty-milestone-release.md b/blog/_posts/2017-10-16-fourth-dotty-milestone-release.md
index 86cce0f73..76d798800 100644
--- a/blog/_posts/2017-10-16-fourth-dotty-milestone-release.md
+++ b/blog/_posts/2017-10-16-fourth-dotty-milestone-release.md
@@ -70,7 +70,7 @@ Using sbt 0.13.13 or newer, do:
sbt new lampepfl/dotty.g8
```
-This will setup a new sbt project with Dotty as compiler. For more details on
+This will set up a new sbt project with Dotty as compiler. For more details on
using Dotty with sbt, see the
[example project](https://github.com/lampepfl/dotty-example-project).
diff --git a/blog/_posts/2017-11-03-zinc-blog-1.0.md b/blog/_posts/2017-11-03-zinc-blog-1.0.md
index 18cca4eef..1b7c22aea 100644
--- a/blog/_posts/2017-11-03-zinc-blog-1.0.md
+++ b/blog/_posts/2017-11-03-zinc-blog-1.0.md
@@ -159,7 +159,7 @@ All in all, this is a high-level summary of our contributions to Zinc 1.0:
* Improve infrastructure to attract contributors:
* Speed up CI by 7x to have a fast turnaround time,
* Add more tests to the project,
- * Add more documentation to the APIs, a README and a CONTRIBUTING guide; and,
+ * Add more documentation to the APIs, a README, and a CONTRIBUTING guide; and,
* Add similar high-quality improvements to the build and scripted tests.
Find the [list of PRs here](https://github.com/sbt/zinc/pulls?utf8=%E2%9C%93&q=author%3Ajvican%20is%3Ap://github.com/sbt/zinc/pulls?utf8=%E2%9C%93&q=author%3Ajvican%20is%3Apr).
diff --git a/blog/_posts/2018-03-19-accessible-scala.md b/blog/_posts/2018-03-19-accessible-scala.md
index 37bc7dca2..c102f6dee 100644
--- a/blog/_posts/2018-03-19-accessible-scala.md
+++ b/blog/_posts/2018-03-19-accessible-scala.md
@@ -79,7 +79,7 @@ partially-sighted users, which is by no means a "solved problem", and offers
much room for improvement.
-Most of the work the Scala Center does contributes small differences to the
+Most of the work that the Scala Center does contributes small differences to the
lives of many developers in the Scala community. This proposal is different in
that it provides a potentially enormous difference to the experience of
programming in Scala to a small number of users.
diff --git a/blog/_posts/2018-04-30-in-a-nutshell.md b/blog/_posts/2018-04-30-in-a-nutshell.md
index 6ce507f26..d801b9d54 100644
--- a/blog/_posts/2018-04-30-in-a-nutshell.md
+++ b/blog/_posts/2018-04-30-in-a-nutshell.md
@@ -138,7 +138,7 @@ principled macro system based on quotes and splices. This looks not very difficu
need to define a pair of mappings between high level trees of type
`scala.quoted.Expr[T]` and lower-level Tasty trees of type
`tasty.Term`. Mapping a high-level tree to a low-level one simply
-means exposing its structure. Mapping a a low-level tree to a
+means exposing its structure. Mapping a low-level tree to a
high-level tree of type `scala.quoted.Expr[T]` means checking that the
low-level tree has indeed the given type `T`. That should be all.
diff --git a/blog/_posts/2018-06-04-scalac-profiling.md b/blog/_posts/2018-06-04-scalac-profiling.md
index 8337d9031..bd133f08f 100644
--- a/blog/_posts/2018-06-04-scalac-profiling.md
+++ b/blog/_posts/2018-06-04-scalac-profiling.md
@@ -394,8 +394,8 @@ directory of the cloned bloop repository.
The first two flags set up the compiler plugin.
The flag `-P:scalac-profiling:no-profiledb` disables the generation of
-`profiledb`s and `-P:scalac-profiling:sourceroot` tells the plugin the base
-directory of the project. The profiledb is only required when we process the
+`profiledb`s and `-P:scalac-profiling:sourceroot` gives the base directory of
+the project to the plugin. The profiledb is only required when we process the
data with other tools, so by disabling it we keep the overhead of the plugin
to the bare minimum.
@@ -704,7 +704,7 @@ shapeless.Strict[caseapp.core.Parser[bloop.cli.Commands.Run]] (id 12121) (expand
On every stack trace, you have also the information about the timing. The
unit of time is microseconds. So one million μs is one second. We use
microseconds because flamegraphs cannot display decimal values and we want
-to lose as litle time precision as possible.
+to lose as little time precision as possible.
Beware that an implicit search may not appear in the flamegraph even if it's
performed by `scalac`. There could be implicit searches that are so fast to
@@ -826,7 +826,7 @@ and
[`materializeCoproduct`](Xhttps://github.com/milessabin/shapeless/blob/a42cd4c1c99e4a7be36e0239d3ee944a6355e321/core/src/main/scala/shapeless/generic.scala#L232-L245).
The problem of incorrect instantiated type arguments we saw before seems
-specific to the way the compiler carries out the implicit search. Fixing it
+specific to the way that the compiler carries out the implicit search. Fixing it
requires most likely changes to the implicit search algorithm, as [a similar
Scala compiler issue](https://github.com/scala/bug/issues/10528) did. I tried porting
these changes to 2.12.x and use `-Xsource:2.13` but the failed macro
@@ -1059,7 +1059,7 @@ happening in every branch, so let's have a look at the data emitted by
The "Macro expansions by type" and "Implicit searches by type" tells us
how many repeated macros and implicit searches we have per type.
-For example, let's look at the most important entries from from the "Implicit
+For example, let's look at the most important entries from the "Implicit
searches by type" section.
```
diff --git a/blog/_posts/2018-06-13-scala-213-collections.md b/blog/_posts/2018-06-13-scala-213-collections.md
index 99ffa0925..8c109dabc 100644
--- a/blog/_posts/2018-06-13-scala-213-collections.md
+++ b/blog/_posts/2018-06-13-scala-213-collections.md
@@ -68,7 +68,7 @@ confusion to the users. Especially when you look at the

-This type signature makes no sense: the result type can not be `TreeMap[B]` since
+This type signature makes no sense: the result type cannot be `TreeMap[B]` since
`TreeMap` takes *two* type parameters (the type of keys and the type
of values). Also, the function `f` actually takes a *key-value pair* as parameter,
not just a key (as incorrectly indicated by the type `A`).
diff --git a/blog/_posts/2019-05-02-community.md b/blog/_posts/2019-05-02-community.md
index 034a57458..73edacfce 100644
--- a/blog/_posts/2019-05-02-community.md
+++ b/blog/_posts/2019-05-02-community.md
@@ -9,7 +9,7 @@ The Scala language is a big tent. It supports object-oriented and
functional code working together. The point of Scala was always to
show that these paradigms can be combined in a compact set of unified
language features. But while the language design stresses unification,
-the same can not (yet?) be said about the community of Scala
+the same cannot (yet?) be said about the community of Scala
programmers.
In fact, Scala is used in many different ways. There are the people who
diff --git a/blog/_posts/2019-09-25-scala-contributors-summit.md b/blog/_posts/2019-09-25-scala-contributors-summit.md
index c42d679ee..348d217f9 100644
--- a/blog/_posts/2019-09-25-scala-contributors-summit.md
+++ b/blog/_posts/2019-09-25-scala-contributors-summit.md
@@ -35,13 +35,13 @@ If you are interested more about broader context: check out most recent podcast
### Scala Days Berlin, 18th May 2018, all day, hosted and sponsored by Zalando
-
+
Around 50 Scala library contributors, authors, and maintainers gathered and discussed various topics, such as the upcoming changes in Scala 3, improvements to the documentation and the website, the future of Scala tooling for both OSS developers and big companies, proposals to better collaborate online and welcome more contributors, etc. Participants shared with us that they learned a lot from each other, how helpful it was to be present in person and meet many of their colleagues, and exchange experience.
No specific program was proposed. Instead, topics and groups were formed on the spot: anyone could propose a topic and interested participants would join for discussion.
-Significant result: Scala Improvement Process took place during the Contributors Summit, and public was for the first time present during the meeting in person. In this particular meeting the SIP committee agreed on approaching Scala 3 changes, dividing worklad in batches as well as giving a month per batch to collect community's input. For more on this, please read the [SIP minutes](https://docs.scala-lang.org/sips/minutes/2018-05-18-sip-minutes.html).
+Significant result: Scala Improvement Process took place during the Contributors Summit, and public was for the first time present during the meeting in person. In this particular meeting the SIP committee agreed on approaching Scala 3 changes, dividing workload into batches as well as giving a month per batch to collect community's input. For more on this, please read the [SIP minutes](https://docs.scala-lang.org/sips/minutes/2018-05-18-sip-minutes.html).
Otherwise in this edition, even though some were taking notes, not all were collected, therefore will not be published here. (If you have notes, please share them with us scala.center@epfl.ch)
diff --git a/blog/_posts/2020-10-27-bsp-in-sbt.md b/blog/_posts/2020-10-27-bsp-in-sbt.md
index 8b2ed4a27..d4e263db9 100644
--- a/blog/_posts/2020-10-27-bsp-in-sbt.md
+++ b/blog/_posts/2020-10-27-bsp-in-sbt.md
@@ -20,7 +20,7 @@ Today we are proud to announce that support of BSP has been shipped into [sbt 1.
As we will see in more details, BSP in sbt improves the integration of sbt inside IDEs and code editors. It provides the user with a unified working environment that is:
- Optimal in terms of compilation speed and reliability
- Centralized around the sbt build definition
-- Highly customizable, by benefitting from the sbt task graph
+- Highly customizable, by benefiting from the sbt task graph
You can already try using sbt as the build server in IntelliJ Idea or Metals by following the instructions in this [Scala contributors post][instructions] or in the [sbt 1.4.0 release note][release-note]. _(Metals integration will soon become much smoother thanks to [this PR](https://github.com/scalameta/metals/pull/2154) by [Chris Kipp](https://github.com/ckipp01))_
@@ -97,7 +97,7 @@ You can have additional configurations, such as the [IntegrationTest](https://ww
It may sometimes be convenient to disable the BSP support on a particular project or configuration. For instance, some projects cannot be compiled incrementally. Or you can have a configuration that is similar to another one in terms of its compiler inputs.
-To this purpose you can use the `bspEnabled` key: the `bspEnabled := false` setting disables BSP on an entire project, whereas `Test / bspEnabled := false` setting disbales BSP on the `Test` configuration only.
+To this purpose you can use the `bspEnabled` key: the `bspEnabled := false` setting disables BSP on an entire project, whereas `Test / bspEnabled := false` setting disables BSP on the `Test` configuration only.
The BSP structure of an sbt project mirrors the exact structure of the build definition. It is the same across all the environments of the developers working on this project.
diff --git a/blog/_posts/2020-11-19-scala-3-forward-compat.md b/blog/_posts/2020-11-19-scala-3-forward-compat.md
index 89e625b3f..2e3580aa0 100644
--- a/blog/_posts/2020-11-19-scala-3-forward-compat.md
+++ b/blog/_posts/2020-11-19-scala-3-forward-compat.md
@@ -33,7 +33,7 @@ to build and run.
and use it from Scala 2 to validate data structures in the `shared` module.
A reader applying the steps in the tutorial to their own project should note that not
-all features of Scala 3 are forward compatibile with Scala 2, such as `inline` methods.
+all features of Scala 3 are forward compatible with Scala 2, such as `inline` methods.
Consequently, we recommend that the user limits their usage of Scala 3 exclusive
features when migrating incrementally. More information is provided in the
[forward compatibility](#forward-compatibility) section.
diff --git a/blog/_posts/2021-01-19-scala-native-0.4-release.md b/blog/_posts/2021-01-19-scala-native-0.4-release.md
index f06e45784..b70f8fff8 100644
--- a/blog/_posts/2021-01-19-scala-native-0.4-release.md
+++ b/blog/_posts/2021-01-19-scala-native-0.4-release.md
@@ -151,7 +151,7 @@ By default, Scala Native has always compiled and optimized the resulting assembl
Although it worked well when you were running a program on the same machine, it caused many problems when trying to run it anywhere else.
With the latest release you're able to define a custom build target for the compiler by providing an [LLVM-style TargetTriple](https://clang.llvm.org/docs/CrossCompilation.html) in your config.
-For example, if you're working on Linux and would like to create an executable suitable for MacOS without changing your whole build,
+For example, if you're working on Linux and would like to create an executable suitable for macOS without changing your whole build,
you can use the following sbt setting:
```bash
sbt 'set nativeConfig ~= {_.withTargetTriple("x86_64-apple-darwin")}' myApp/nativeLink
diff --git a/blog/_posts/2021-02-16-preventing-version-conflicts-with-versionscheme.md b/blog/_posts/2021-02-16-preventing-version-conflicts-with-versionscheme.md
index c52d75359..1840a417d 100644
--- a/blog/_posts/2021-02-16-preventing-version-conflicts-with-versionscheme.md
+++ b/blog/_posts/2021-02-16-preventing-version-conflicts-with-versionscheme.md
@@ -107,7 +107,7 @@ ThisBuild / versionScheme := Some("early-semver")
sbt 1.4.0 includes this information into `pom.xml` and `ivy.xml` as a property. In addition, sbt uses the information to take the guessing out of eviction warning when this information is available.
-In sbt 1.5.0, eviction warnings will be replaced with [eviction errors][8]. Since it can now reliably detect whether two dependencies with different versions are compatible, or if they conflict, the build will fail if an incompatibility is detected in your dependencies. This is of course possible only if the libraries provide their `versionScheme`, otherwise sbt will keep issuing eviction warnings.
+In sbt 1.5.0, eviction warnings will be replaced with [eviction errors][8]. Since it can now reliably detect whether two dependencies with different versions are compatible, or if they conflict, the build will fail if an incompatibility is detected in your dependencies. This is of course possible only if the libraries provide their `versionScheme`; otherwise, sbt will keep issuing eviction warnings.
It might take a few years for the `versionScheme` information to become prevalent in the ecosystem. In the meantime, as a user of libraries you can manually configure the versioning scheme used by your libraries by using a new setting, `libraryDependencySchemes`. For instance, here is how you can tell sbt that the `circe-core` artifact follows the Early SemVer scheme:
diff --git a/blog/_posts/2021-07-21-scala-3.0.2RC1-is-here.md b/blog/_posts/2021-07-21-scala-3.0.2RC1-is-here.md
index 7f35d40f5..caec8332e 100644
--- a/blog/_posts/2021-07-21-scala-3.0.2RC1-is-here.md
+++ b/blog/_posts/2021-07-21-scala-3.0.2RC1-is-here.md
@@ -11,7 +11,7 @@ As no critical bugs have been found in the previously released Scala 3.0.1-RC2,
Scala 3.0.2-RC1, in turn, incorporates new language improvements and bug fixes described below.
-You can expect the release of stable 3.0.2 and a release candidate for a the next version in 6 weeks from now (1st September).
+You can expect the release of stable 3.0.2 and a release candidate for the next version in 6 weeks from now (1st September).
## Improved insertion of semicolons in logical conditions
@@ -69,7 +69,7 @@ To find methods with the desired signature simply write in scaladoc's searchbar
## Typing escape hatch for structural types
-Structural types may come in handy in many situations, e.g. when one wants to achieve a compromise between safety of static typing and ease of use when dealing with dynamically changing schemas of domain data structures. They have however some limitations. Among others structural typing doesn't normally play well with method overloading because some types of reflective dispatch algorithms (inlcuding JVM reflection) might not be able to choose the overloaded method alternative with the right signature without knowing upfront the exact types of the parameters after erasure. Consider the following snippet.
+Structural types may come in handy in many situations, e.g. when one wants to achieve a compromise between safety of static typing and ease of use when dealing with dynamically changing schemas of domain data structures. They have however some limitations. Among others structural typing doesn't normally play well with method overloading because some types of reflective dispatch algorithms (including JVM reflection) might not be able to choose the overloaded method alternative with the right signature without knowing upfront the exact types of the parameters after erasure. Consider the following snippet.
```scala
class Sink[A] { def put(x: A): Unit = {} }
diff --git a/blog/_posts/2021-09-07-scala-3.0.2-released.md b/blog/_posts/2021-09-07-scala-3.0.2-released.md
index 944bb8bc0..95cc69015 100644
--- a/blog/_posts/2021-09-07-scala-3.0.2-released.md
+++ b/blog/_posts/2021-09-07-scala-3.0.2-released.md
@@ -66,7 +66,7 @@ To find methods with the desired signature simply write in scaladoc's searchbar
### Typing escape hatch for structural types
-Structural types may come in handy in many situations, e.g. when one wants to achieve a compromise between safety of static typing and ease of use when dealing with dynamically changing schemas of domain data structures. They have however some limitations. Among others structural typing doesn't normally play well with method overloading because some types of reflective dispatch algorithms (inlcuding JVM reflection) might not be able to choose the overloaded method alternative with the right signature without knowing upfront the exact types of the parameters after erasure. Consider the following snippet.
+Structural types may come in handy in many situations, e.g. when one wants to achieve a compromise between safety of static typing and ease of use when dealing with dynamically changing schemas of domain data structures. They have however some limitations. Among others structural typing doesn't normally play well with method overloading because some types of reflective dispatch algorithms (including JVM reflection) might not be able to choose the overloaded method alternative with the right signature without knowing upfront the exact types of the parameters after erasure. Consider the following snippet.
```scala
class Sink[A] { def put(x: A): Unit = {} }
diff --git a/blog/_posts/2021-10-21-scala-3.1.0-released.md b/blog/_posts/2021-10-21-scala-3.1.0-released.md
index a4b8b7577..3cef018b5 100644
--- a/blog/_posts/2021-10-21-scala-3.1.0-released.md
+++ b/blog/_posts/2021-10-21-scala-3.1.0-released.md
@@ -94,8 +94,8 @@ The only change necessary for users is that they should now consider that one of
- Now `TastyInspector.{inspectTastyFiles, inspectTastyFilesInJar, inspectAllTastyFiles}` return a boolean value indicating whether the process succeeded
- A `Wildcard` was made a subtype of `Ident` in the reflection API
- `TypedOrTest` was added as a supertype of `Typed` in the reflection API
-- `Unapply.apply` was added to allow contruction of `Unapply` trees from macros
-- Unreductible match types now raise type errors
+- `Unapply.apply` was added to allow construction of `Unapply` trees from macros
+- Unreducible match types now raise type errors
- Scala 3.1 targets Scala.js 1.7.x+. This means that users must upgrade to Scala.js 1.7.0 or later to use Scala 3.1.
Beside that Scala 3.1.0 introduced multiple small improvements and fixed a handful of bugs. You can see [the detailed changelog](https://github.com/scala/scala3/releases/tag/3.1.0) on GitHub.
diff --git a/blog/_posts/2021-12-14-sustainable-scala.md b/blog/_posts/2021-12-14-sustainable-scala.md
index 24b856ad1..bb412c311 100644
--- a/blog/_posts/2021-12-14-sustainable-scala.md
+++ b/blog/_posts/2021-12-14-sustainable-scala.md
@@ -62,7 +62,7 @@ programming languages**. On average, C and Rust programs are the most energy
efficient. Java programs consume about 2 times more energy than C programs.
JavaScript/TypeScript programs consume between 4 to 20 times more energy
than C programs. Finally, Python programs are black sheeps, with an energy
-consumption 75 times higher than C programs.
+consumption 75 times greater than C programs.
Where does Scala stand in this picture? Unfortunately, Scala was not
included in this study.
@@ -234,7 +234,7 @@ within high-level programming languages.
Also, we see that in Scala, two implementations of the same benchmark can
easily show different performances, depending on your code style. For
instance, the energy consumption of the `k-nucleotide` benchmark was between
-2 to 13 times higher than the C implementation. The differences between both
+2 to 13 times greater than the C implementation. The differences between both
versions are mainly the usage of immutable Scala collections and `for` loops in
the idiomatic version, as opposed to `Array`s and `while` loops in the
optimized version (this observation is consistent with the results of
diff --git a/blog/_posts/2022-02-01-scala-3.1.1-released.md b/blog/_posts/2022-02-01-scala-3.1.1-released.md
index 95a424380..b2e1d4cbd 100644
--- a/blog/_posts/2022-02-01-scala-3.1.1-released.md
+++ b/blog/_posts/2022-02-01-scala-3.1.1-released.md
@@ -32,13 +32,13 @@ For a comprehensive list of fixes, take a look at [the full changelog on GitHub]
Alongside 3.1.1 we have released the first RC version of the next patch release of the compiler. 3.1.2-RC1 contains further fixes, but most importantly it is our first step in improving forward compatibility in Scala.
-Scala 3 has excellent backward compatibility guarantees between the minor versions. Right now, that means that code compiled with Scala 3.1 can depend on libraries published with 3.0 without any problems. The opposite, hovewer, is not true. Code compiled with 3.0 is not able to read dependencies compiled with 3.1. After the recent release of Scala 3.1.0, we can see that libraries should be really cautious with updating the compiler version, as it forces a bump on every user of that library. We do not want library authors to be stuck on old versions of the compiler as that would mean that they are locked out of many bugfixes, or we would need to spend enormous effort on backporting every bugfix to all past versioning lines.
+Scala 3 has excellent backward compatibility guarantees between the minor versions. Right now, that means that code compiled with Scala 3.1 can depend on libraries published with 3.0 without any problems. The opposite, however, is not true. Code compiled with 3.0 is not able to read dependencies compiled with 3.1. After the recent release of Scala 3.1.0, we can see that libraries should be really cautious with updating the compiler version, as it forces a bump on every user of that library. We do not want library authors to be stuck on old versions of the compiler as that would mean that they are locked out of many bugfixes, or we would need to spend enormous effort on backporting every bugfix to all past versioning lines.
Our current plan to mitigate those difficulties is described in [the contributors discussion](https://contributors.scala-lang.org/t/improving-scala-3-forward-compatibility/5298), where you are free to leave your feedback. We already have implemented the first and most important part of the solution and have it ready for public testing. Beginning with Scala 3.1.2-RC1 the compiler is able to generate outputs that can be consumed by its older versions. To enable that, you need to specify the minimal targeted minor language version by using the experimental `-Yscala-release` flag.
We expect that in the future authors will use the newest available version of the compiler with `-Yscala-release` set to the lowest language version that support all features they need. This way they will be able to benefit from all the bugfixes without restricting their potential audience.
-So, for example, compiling your library using Scala 3.1.2-RC2 with `-Yscala-release:3.0` flag, you make it possible for people still using Scala 3.0 to depend on your library. This has some limitations, especially your library cannot have any dependencies compiled with `-Yscala-release` version higher than 3.0. You also won't be able to use any symbol added to the standard library after 3.0. They are marked in the code and in the documentation by the `@since` annotation that was also added in this version.
+So, for example, compiling your library using Scala 3.1.2-RC2 with `-Yscala-release:3.0` flag, you make it possible for people still using Scala 3.0 to depend on your library. This has some limitations, especially your library cannot have any dependencies compiled with `-Yscala-release` version greater than 3.0. You also won't be able to use any symbol added to the standard library after 3.0. They are marked in the code and in the documentation by the `@since` annotation that was also added in this version.
One important note is that the `-Yscala-release` flag is experimental and not yet available in any stable release of the compiler. It means the build tools, such as SBT or Mill, are not yet aware of its existence. Of course, you can declare usage of the flag in your build file, and the compiler will respect it. However, there may still be some hiccups, like generated artifacts depending on the incorrect version of the stdlib. We will do our best to help fix those minor issues before the stable release of 3.1.2.
diff --git a/blog/_posts/2022-03-08-finding-awesome-libraries.md b/blog/_posts/2022-03-08-finding-awesome-libraries.md
index c846597b9..a32471814 100644
--- a/blog/_posts/2022-03-08-finding-awesome-libraries.md
+++ b/blog/_posts/2022-03-08-finding-awesome-libraries.md
@@ -41,7 +41,7 @@ How can we help experienced Scala programmers find new libraries that solve thei
Open source software, similarly to commercial ones, will not thrive unless it reaches new users, sponsors and contributors.
Aware of this issue, open source communities started to compile “awesome” lists of open source projects organized by topics.
-Some examples are [vinta/awesome-python](https://github.com/vinta/awesome-python), [akullp/awesome-java](https://github.com/akullpp/awesome-java), [veggiemonk/awesome-docker](https://github.com/veggiemonk/awesome-docker) and many many more (see [bayandin/awesome-awesomeness](http://bayandin/awesome-awesomeness)).
+Some examples are [vinta/awesome-python](https://github.com/vinta/awesome-python), [akullp/awesome-java](https://github.com/akullpp/awesome-java), [veggiemonk/awesome-docker](https://github.com/veggiemonk/awesome-docker) and many, many, more (see [bayandin/awesome-awesomeness](http://bayandin/awesome-awesomeness)).
The high number of stars of these GitHub repositories show how popular they are in the world of open source software.
diff --git a/blog/_posts/2022-12-14-scala-developer-survey-results-2022.md b/blog/_posts/2022-12-14-scala-developer-survey-results-2022.md
index 01271aceb..e05a6b113 100644
--- a/blog/_posts/2022-12-14-scala-developer-survey-results-2022.md
+++ b/blog/_posts/2022-12-14-scala-developer-survey-results-2022.md
@@ -132,7 +132,7 @@ We asked respondents “*Which types of resources did you use to learn Scala?*
We see that **78.1%** of respondents chose “books”; **77.5%** chose the [official documentation](https://docs.scala-lang.org); **77.21%** chose “online courses”; **8.43%** chose “university courses”; **3.72%** chose “bootcamps”.
**16.7%** of respondents chose “other” which is significantly more compared to the rest of the questions in the survey with the same field. Here’s what came up, in no particular order:
-Work experience, hackathons, local user groups, youtube tutorials, internal company training, blogs, Stackoverflow, and more.
+Work experience, hackathons, local user groups, YouTube tutorials, internal company training, blogs, Stackoverflow, and more.
Going forward it would be useful to reinclude some of the “other” options in the main questions, and further determine which books/docs/courses were useful.
diff --git a/blog/_posts/2023-04-11-march-2023-scala-tooling-summit.md b/blog/_posts/2023-04-11-march-2023-scala-tooling-summit.md
index dd2b6a165..9a65920f2 100644
--- a/blog/_posts/2023-04-11-march-2023-scala-tooling-summit.md
+++ b/blog/_posts/2023-04-11-march-2023-scala-tooling-summit.md
@@ -340,7 +340,7 @@ inline. You can follow a thread on this effort
## What comes next?
-Overall, we consider the summit a success. With positive feedback from
+Overall, we consider the summit to be a success. With positive feedback from
participants and movement already visible on the topics above, we feel confident
that these efforts will result in a more stable, feature-rich, and unified
tooling ecosystem. The Scala Center will be continuing to facilitate and plan
diff --git a/blog/_posts/2023-04-20-sbt-plugins-community-repository.md b/blog/_posts/2023-04-20-sbt-plugins-community-repository.md
index fc5b3d038..993459e9d 100644
--- a/blog/_posts/2023-04-20-sbt-plugins-community-repository.md
+++ b/blog/_posts/2023-04-20-sbt-plugins-community-repository.md
@@ -25,7 +25,7 @@ sbt plugins from the community repository `repo.scala-sbt.org` anymore (examples
To understand what happened, here is some background information. sbt plugins are packaged
as modules published to Ivy or Maven repositories. Historically, sbt plugins used to be
published primarily to the sbt community repository hosted on Bintray. However, in 2021,
-JFrog [sunsetted the Bintray
+JFrog [sunset the Bintray
service](https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/).
Since then, JFrog has provided the Scala Center a cloud-hosted Artifactory instance for free.
As explained in the [release notes of sbt
diff --git a/blog/_posts/2023-06-20-toolkit.md b/blog/_posts/2023-06-20-toolkit.md
index 5fd8cd2bf..c8b8f5bc1 100644
--- a/blog/_posts/2023-06-20-toolkit.md
+++ b/blog/_posts/2023-06-20-toolkit.md
@@ -45,7 +45,7 @@ The Toolkit aims to offer default choices for coders who aren’t in a position
## What is the Toolkit?
-The Toolkit gathers a number of pre-existing libraries of the ecosystem that focus on concrete, recurring software engineering problems, such as working with files and processes, parsing JSON, and sending HTTP requests.
+The Toolkit gathers a number of preexisting libraries of the ecosystem that focus on concrete, recurring software engineering problems, such as working with files and processes, parsing JSON, and sending HTTP requests.
Its documentation can be found at [docs.scala-lang.org/toolkit](https://docs.scala-lang.org/toolkit/introduction.html).
It comprises a collection of concise tutorials, including short code examples, that aim at being self-contained.
@@ -84,7 +84,7 @@ println(response.code)
// prints: 200
```
-This short program sends an HTTP request to the [Github REST API](https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28#update-the-authenticated-user), to update the profile of the authenticated users.
+This short program sends an HTTP request to the [GitHub REST API](https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28#update-the-authenticated-user), to update the profile of the authenticated users.
In a few lines, it shows:
- how to construct a JSON object, with `ujson.Obj`
- how to read an environment variable, with `sys.env`
@@ -209,7 +209,7 @@ To select the libraries of the Toolkit we used the following criterion:
### Who owns the Toolkit libraries?
-The Toolkit is composed of pre-existing libraries from the ecosystem, created by different organizations and individuals.
+The Toolkit is composed of preexisting libraries from the ecosystem, created by different organizations and individuals.
Those libraries are owned by their respective authors and maintainers.
The Scala organization takes on the responsibility of curating the libraries, releasing the Toolkit artifacts and regularly updating the tutorials in [docs.scala-lang.org/toolkit](https://docs.scala-lang.org/toolkit/introduction.html).
diff --git a/blog/_posts/2023-09-11-scala-center-fundraising.md b/blog/_posts/2023-09-11-scala-center-fundraising.md
index a088d950b..e0e2a78eb 100644
--- a/blog/_posts/2023-09-11-scala-center-fundraising.md
+++ b/blog/_posts/2023-09-11-scala-center-fundraising.md
@@ -25,4 +25,4 @@ Inspired to join forces for a sustainable Scala open source ecosystem? [Get in t
And if you're not a company but an individual Scala programmer, you can still contribute to the Scala Center by becoming a [supporter](https://scala.epfl.ch/records/first-five-years/support)!
-To learn more about our activities, we invite you to check out our [Five Year Report](https://scala.epfl.ch/records/first-five-years/), [team](https://scala.epfl.ch/team.html) behind the the work, and the [2023 Roadmap](https://www.scala-lang.org/blog/2023/01/31/scala-center-2023-roadmap.html).
+To learn more about our activities, we invite you to check out our [Five Year Report](https://scala.epfl.ch/records/first-five-years/), [team](https://scala.epfl.ch/team.html) behind the work, and the [2023 Roadmap](https://www.scala-lang.org/blog/2023/01/31/scala-center-2023-roadmap.html).
diff --git a/blog/_posts/2023-10-17-feedback-wanted-error-messages.md b/blog/_posts/2023-10-17-feedback-wanted-error-messages.md
index 7b645d485..d491c7b54 100644
--- a/blog/_posts/2023-10-17-feedback-wanted-error-messages.md
+++ b/blog/_posts/2023-10-17-feedback-wanted-error-messages.md
@@ -16,7 +16,7 @@ description: "Feedback is wanted on confusing or unhelpful error messages"
From [suggesting to import missing extension methods](https://docs.scala-lang.org/scala3/book/ca-extension-methods.html#import-extension-method) and more, Scala 3 tries to improve the ways that warnings and errors are reported to the user.
The idea being that when the user engages with reported problems, it should feel like having a conversation with a helpful tutor. By helping users to get back on track, we can make Scala easier to learn, friendlier to newcomers, and also keep experienced users more productive.
-We know there is much more that can be done to continually improve the situation. As well as working to [expose diagnostics programatically](https://github.com/scala/scala3/issues/14904), we are starting a new campaign to seek out confusing, annoying or unhelpful error/warning messages.
+We know there is much more that can be done to continually improve the situation. As well as working to [expose diagnostics programmatically](https://github.com/scala/scala3/issues/14904), we are starting a new campaign to seek out confusing, annoying or unhelpful error/warning messages.
As compiler authors, we do try to provide good messages, but it is possible for there to be shortcomings.
For example, the message may correctly report a problem, but not provide enough information to actually help the user.
diff --git a/blog/_posts/2023-11-03-spotify-oss.md b/blog/_posts/2023-11-03-spotify-oss.md
index 583f4c6ed..07ecedc9f 100644
--- a/blog/_posts/2023-11-03-spotify-oss.md
+++ b/blog/_posts/2023-11-03-spotify-oss.md
@@ -22,7 +22,7 @@ As an organization, Spotify's dedication to open source has been clear since its
Our interviewee, Michel, was attracted to Spotify precisely because of its fervent open source culture. In recent times, the company has professionalized its open source initiatives by creating the Free and Open Source Software board (FOSS board). It aims to promote good practices and citizenship within the open source community, assist in legal/business issues and ensure the delivery of high-quality software. This step is part of Spotify's shift towards prioritizing quality over quantity in its open source contributions. The company's dedication to supporting the open source ecosystem extends beyond its walls with the launch of the [FOSS Fund](https://engineering.atspotify.com/2023/10/announcing-the-recipients-of-the-2023-spotify-foss-fund/). This fund is dedicated to financially support the maintainers of independent projects. This ambitious initiative is aimed at nurturing a more sustainable open source ecosystem for everyone to benefit from.
-In addition, Spotify has a dedicated page showcasing all its [open source projects](https://spotify.github.io/). They also actively share updates and progress through blog posts and have established mechanisms to gauge the quality of their projects, such as tracking the repository activity, known vulnerabilities and the community interest with star ratings on Github.
+In addition, Spotify has a dedicated page showcasing all its [open source projects](https://spotify.github.io/). They also actively share updates and progress through blog posts and have established mechanisms to gauge the quality of their projects, such as tracking the repository activity, known vulnerabilities and the community interest with star ratings on GitHub.
Join us as we explore deeper into Spotify's journey and its symbiotic relationship with the open source world. We'd like to share some of Spotify's own experiences - the highs and the lows - of contributing to the Scala ecosystem.
diff --git a/blog/_posts/2024-02-29-scala-3.4.0-and-3.3.3-released.md b/blog/_posts/2024-02-29-scala-3.4.0-and-3.3.3-released.md
index 42dde75c5..38a800904 100644
--- a/blog/_posts/2024-02-29-scala-3.4.0-and-3.3.3-released.md
+++ b/blog/_posts/2024-02-29-scala-3.4.0-and-3.3.3-released.md
@@ -105,7 +105,7 @@ Release notes of [3.4.0](https://github.com/scala/scala3/releases/tag/3.4.0) con
### Experimental changes
-- An experimental `@publicInBinary` annotation can mark definitions that should be treated as a part of binary API. It is useful where some protected or private-in-package definitions are used in the inlined code. When they are marked, it is harder to accidentally break the binary compatibility by doing seemingly harmless refactoring. If the accompanying `-WunstableInlineAccessors` linting option is enabled. There will be a warning about using things not marked as binary API in inlined code. Originaly it was presented in [SIP-52](https://docs.scala-lang.org/sips/binary-api.html).
+- An experimental `@publicInBinary` annotation can mark definitions that should be treated as a part of binary API. It is useful where some protected or private-in-package definitions are used in the inlined code. When they are marked, it is harder to accidentally break the binary compatibility by doing seemingly harmless refactoring. If the accompanying `-WunstableInlineAccessors` linting option is enabled. There will be a warning about using things not marked as binary API in inlined code. Originally it was presented in [SIP-52](https://docs.scala-lang.org/sips/binary-api.html).
- `-experimental` compiler flags will mark all top-level definitions as `@experimental`. This means that the experimental language features and definitions can be used in the project. Note that this does not change the strong guarantees of the stability of the non-experimental code. The experimental features can only be used in an experimental scope (transitively). In 3.5, we plan to allow using this flag also in the stable releases of the compiler.
### Legacy syntax deprecation
diff --git a/blog/_posts/2024-03-06-scala-3.3.2-post-mortem.md b/blog/_posts/2024-03-06-scala-3.3.2-post-mortem.md
index aba11c8f9..ee1997b61 100644
--- a/blog/_posts/2024-03-06-scala-3.3.2-post-mortem.md
+++ b/blog/_posts/2024-03-06-scala-3.3.2-post-mortem.md
@@ -46,7 +46,7 @@ Names in TASTy and in the compiler are not simple Strings.
They have some amount of structure.
For example, the name of the class behind an `object Foo` definition has a structured name `ModuleClass("Foo")`, instead of the string `"Foo$"`.
-Likewise, generated names for anonymous entites, such as `implicit` parameters, have the structured name `UniqueName("evidence$", 1)`.
+Likewise, generated names for anonymous entities, such as `implicit` parameters, have the structured name `UniqueName("evidence$", 1)`.
The string `"evidence$"` is used in the equality definition of names, so that `UniqueName("evidence$", 1)` is not the same name as `UniqueName("foo$", 1)`, but it does not otherwise have any semantic meaning in TASTy.
However, for code readability and performance reasons, the compiler maintains a fixed list of the prefixes it generates, and uses a single instance of the associated `NameKind`, one of its internal data structures.
diff --git a/blog/_posts/2024-03-18-scam-response.md b/blog/_posts/2024-03-18-scam-response.md
index 9926e79bd..2dd96a4d4 100644
--- a/blog/_posts/2024-03-18-scam-response.md
+++ b/blog/_posts/2024-03-18-scam-response.md
@@ -40,8 +40,8 @@ The Scala Center has been carefully documenting all the cases brought to our att
If you see a fraudulent domain, the following are the things you can do:
- Report them at the DNS level proved helpful - they get blocked fairly quickly. You can use [who.is](https://who.is/) to find the DNS provider of a domain by looking at its NS record. Then, you can complain to that provider. For example, we reported several domains to [Dynadot](https://www.dynadot.com/report-abuse) via their abuse report system.
-- Report the fraud to your local law enforcement. The more such reports they get, the more likely they are to prioritise the issue. If you are a victim and have revealed your identity documents to the scammers, it is especially important that you seek help from your law enforcement, as the leaked documents may be used by the scammers to impersonate you.
-- Report the fraud to the companies the scammers impersonate.
+- Report the fraud to your local law enforcement. The more such reports they get, the more likely they are to prioritize the issue. If you are a victim and have revealed your identity documents to the scammers, it is especially important that you seek help from your law enforcement, as the leaked documents may be used by the scammers to impersonate you.
+- Report the fraud to the companies that the scammers are impersonating.
- Stay informed via the Scala Center's official channels. Also, coordinate with your local community, e.g., the Scala's Indian community made a [thread](https://www.reddit.com/r/developersIndia/comments/1axvs2p/new_scam_alert_guys_it_is_a_massive_elaborate/) on Reddit where they discuss the issue.
As this is an ongoing incident, please stay vigilant. You can read the previous article on the matter, which contains some useful tips on how to detect the scam [here](https://scala-lang.org/blog/2024/03/01/fake-scala-courses.html).
diff --git a/blog/_posts/2024-03-28-ambassadors-initiative.md b/blog/_posts/2024-03-28-ambassadors-initiative.md
index 51ac25918..1077c7098 100644
--- a/blog/_posts/2024-03-28-ambassadors-initiative.md
+++ b/blog/_posts/2024-03-28-ambassadors-initiative.md
@@ -58,7 +58,7 @@ Currently, we are in the process of selecting and onboarding the first group of
* [Scala Ambassadors page](https://scala-lang.org/ambassadors)
-At the moment the list is short, but we aim to make it much longer in the coming weeks and months.
+At the moment, the list is short, but we aim to make it much longer in the coming weeks and months.
Stay tuned for more information about the Scala Ambassadors initiative and the Ambassadors themselves! This is only our first blog post on the subject.
diff --git a/blog/_posts/2025-03-24-evolving-scala.md b/blog/_posts/2025-03-24-evolving-scala.md
index d030d2fd0..9063ac930 100644
--- a/blog/_posts/2025-03-24-evolving-scala.md
+++ b/blog/_posts/2025-03-24-evolving-scala.md
@@ -227,7 +227,7 @@ However, we think there is light at the end of the tunnel:
[Bleep](https://github.com/oyvindberg/bleep), while still young, offers a different take in the build tool space that also shows a lot of promise.
3. **sbt itself has improved greatly over time**.
The last few years have seen improvements like the [Unified Slash Syntax](https://github.com/sbt/sbt/pull/3434), [sbt Project-Matrix](https://github.com/sbt/sbt-projectmatrix), and the upcoming [sbt 2.0](https://www.scala-sbt.org/2.x/docs/en/changes/sbt-2.0-change-summary.html) release is bringing [build queries](https://eed3si9n.com/sudori-part6/), [remote caching](https://eed3si9n.com/sbt-remote-cache/), and other improvements.
- While still not perfect, the experience using sbt in 2025 is greatly improved from the experience a decade ago.
+ While still not perfect, the experience using sbt in 2025 is greatly improved from the experience of a decade ago.
4. [**Maven**](https://github.com/davidB/scala-maven-plugin) and [**Gradle**](https://docs.gradle.org/current/userguide/scala_plugin.html) can also be used.
These build tools have long been popular and familiar in Java shops.
While not as popular in the open source community, we see them being used in many commercial Scala codebases.
diff --git a/gsoc/2014.md b/gsoc/2014.md
index bb803fce7..dfad51707 100644
--- a/gsoc/2014.md
+++ b/gsoc/2014.md
@@ -57,13 +57,13 @@ optimality.
In the context of the Java Virtual Machine, [miniboxing][mb1] is a new
translation that sidesteps the shortcomings of previous approaches,
-while maintaing the optimality of the low level non-uniform code. It
+while maintaining the optimality of the low level non-uniform code. It
builds on the specialization transformation, which is already included
in the [Scala compiler][mb2], but produces too much bytecode to be
useful in practical applications. Although miniboxing is developed for
the Scala language, the same transformation could also be implemented
in [Java][mb3] and in other JVM languages, such as [IBM's X10][mb4],
-[JetBrains' Kotlin][mb5] and [RedHat's Ceylon][mb6].
+[JetBrains' Kotlin][mb5] and [Red Hat's Ceylon][mb6].
The miniboxing transformation matches optimal performance in
microbenchmarks, but in order to make a significant impact in the
diff --git a/gsoc/2015.md b/gsoc/2015.md
index f9fd55300..d2dafbf5e 100644
--- a/gsoc/2015.md
+++ b/gsoc/2015.md
@@ -62,10 +62,10 @@ More info at gsoc2015.nsp@cvogt.org
[Slick](https://scala-slick.org/) is a modern database query and access library for Scala. It allows you to work with stored data almost as if you were using Scala collections while at the same time giving you full control over when a database access happens and which data is transferred. You can write your database queries in Scala instead of SQL, thus profiting from the static checking, compile-time safety, and compositionality of Scala.
Slick's interface, uses the type-based deep embedding that imposes some limitations on the interface:
-* Native language constructs can not be used (e.g., `==` must be replaced with `===`).
+* Native language constructs cannot be used (e.g., `==` must be replaced with `===`).
* Reported type errors can get nasty.
-We propose an new front-end for Slick based on libraries [scala-yinyang](https://github.com/scala-yinyang/scala-yinyang) and [direct-embedding](https://github.com/directembedding/directembedding) that will make Slick queries identical to regular Scala.
+We propose a new front-end for Slick based on libraries [scala-yinyang](https://github.com/scala-yinyang/scala-yinyang) and [direct-embedding](https://github.com/directembedding/directembedding) that will make Slick queries identical to regular Scala.
By doing this project you will vastly improve the user experience for many Scala users!
@@ -121,7 +121,7 @@ More info at gsoc2015.nsp@cvogt.org
### Data migration tool
-The goal of this project is creating a tool for managing data migration scripts based on Slick. We have a rough proof of concept implementation you can base work on at https://github.com/cvogt/migrations . The idea is roughly similar to migrations/evolutions in Ruby on Rails or Scala Play 2. You will need to significantly improve (or re-write) the code of the proof of concept implementation to make it production ready, extend it by futher features and explore some exciting ideas like reliable migrations in a development scenario with branches (like git branches). Your ideas are important to this project. Here is how we see it right now:
+The goal of this project is creating a tool for managing data migration scripts based on Slick. We have a rough proof of concept implementation you can base work on at https://github.com/cvogt/migrations . The idea is roughly similar to migrations/evolutions in Ruby on Rails or Scala Play 2. You will need to significantly improve (or re-write) the code of the proof of concept implementation to make it production ready, extend it by further features and explore some exciting ideas like reliable migrations in a development scenario with branches (like git branches). Your ideas are important to this project. Here is how we see it right now:
#### Existing features (which all require revision)
diff --git a/gsoc/2016.md b/gsoc/2016.md
index 4a5257571..0a7cfb8be 100644
--- a/gsoc/2016.md
+++ b/gsoc/2016.md
@@ -66,7 +66,7 @@ Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://githu
### Super-charged for-comprehensions
-Super-charged for-comprehensions are an effort to implement an alternative direct-style dyntax for monadic comprehensions in Scala.
+Super-charged for-comprehensions are an effort to implement an alternative direct-style syntax for monadic comprehensions in Scala.
The goals are reduction in syntax, enabling more control flow expressions, inline Monad value extraction and transformer operations on the Monad context (as in Comprehensive Comprehensions). At the time of writing the project is in heavy flux. Depending on its status there will likely be interesting idea how to take the project further. One likely topic would be exploring type changing comprehensive comprehension transformers, such as groupBy or aggregations. The implementation heavily relies on macros and will require learning how to work with Scala's compiler ASTs and make changes to the AST transformation stages.
Work in progress: [https://github.com/cvogt/flow-comprehensions](https://github.com/cvogt/flow-comprehensions)
@@ -191,7 +191,7 @@ This project consists in writing a compiler from Java source code to the
Intermediate Representation (IR) of Scala.js. The later phases of the existing
pipeline would then be reused to compile that IR to JavaScript.
-The Java-to-IR compiler should probably reuse an existing an existing Java
+The Java-to-IR compiler should probably reuse an existing Java
parser and typechecker. From typechecked Java ASTs, it should be relatively
straightforward to compile them down to the Scala.js IR (except some corner
cases, but not *everything* needs to be supported).
diff --git a/gsoc/2017.md b/gsoc/2017.md
index 900a51074..a2ce87d26 100644
--- a/gsoc/2017.md
+++ b/gsoc/2017.md
@@ -69,7 +69,7 @@ existing infrastructure for xml literals. It would probably be a good
idea to re-package the existing XML parser in the Scala compiler, and
to map interpolated strings to constructors from the existing
`scala.xml` library. Some other aspects need to be re-thought. In
-particular name-space management should be handled by implicts
+particular name-space management should be handled by implicits
instead of being hard-coded in the Scala typer.
The project is a success if it can support essentially all legal XML
@@ -179,7 +179,7 @@ from *[Eugene Burmako](https://github.com/xeno-by)*.
### Dotty Documentation Compiler ###
[Dotty](https://dotty.epfl.ch) is the future Scala compiler developed at EPFL.
-Getting in to compiler development is usually a very difficult especially when
+Getting into compiler development is usually a very difficult especially when
it comes to compilers for advanced languages like Scala.
Luckily, there are two compilers in the Dotty project. One for the language and
@@ -227,7 +227,7 @@ Supervised by [@MasseGuillaume](https://github.com/MasseGuillaume) and/or
Scala-Native is a new target for Scala. Instead of compiling to bytecode and running on the JVM, we
use llvm to generate native assembly code. We currently do not compile Java to llvm. Therefore we need
to reimplement some parts of JDK such as `java.net.*`, `java.io.*`, `java.nio.*` and `java.util.*`. We are already
-reimplementing the JDK and we need your help to increase our coverage. It'a unique chance to learn
+reimplementing the JDK and we need your help to increase our coverage. It's a unique chance to learn
how to implement the java api and write low level Scala code.
Supervised by [@MasseGuillaume](https://github.com/MasseGuillaume)
@@ -338,7 +338,7 @@ Supervised by [@olafurpg](https://github.com/olafurpg)
### Implementing a Benchmark Suite for Big Data and Machine Learning Applications
-In this project, the aim is to design and implement several larger Big Data and Machine Learning applications, which will be used to regularly test the performance of the Scala compiler releases, and to test the performance of JVMs running these applications. By the time the project is completed, you are expected to implement one larger data-intensive application at least for these frameworks: [Spark](https://spark.apache.org/), [Flink](https://flink.apache.org/), [Storm](https://storm.apache.org/), [Kafka](https://kafka.apache.org/) and [DeepLearning4j](https://github.com/deeplearning4j). Each of the applications will have to be accompanied with a dataset used to run the application.
+In this project, the aim is to design and implement several larger Big Data and Machine Learning applications, which will be used to regularly test the performance of the Scala compiler releases, and to test the performance of JVMs running these applications. By the time that the project is completed, you are expected to implement one larger data-intensive application at least for these frameworks: [Spark](https://spark.apache.org/), [Flink](https://flink.apache.org/), [Storm](https://storm.apache.org/), [Kafka](https://kafka.apache.org/) and [DeepLearning4j](https://github.com/deeplearning4j). Each of the applications will have to be accompanied with a dataset used to run the application.
This project is an excellent opportunity to familiarize yourself with these modern cutting-edge frameworks for distributed computing and machine learning!
diff --git a/gsoc/2018.md b/gsoc/2018.md
index f8308a6a0..74e93d024 100644
--- a/gsoc/2018.md
+++ b/gsoc/2018.md
@@ -155,7 +155,7 @@ Supervised by [@jonas](https://github.com/jonas)
workflows. In this project, you'll be working on a web-based client controlling test execution with
the goal of providing instant and interactive feedback. You'll have to extend the protocols that
allow Bloop to communicate with other tools and develop the new client.
-[Majestic](https://github.com/Raathigesh/majestic) is a similar project for Javascript tooling.
+[Majestic](https://github.com/Raathigesh/majestic) is a similar project for JavaScript tooling.
Supervised by [@Duhemm](https://github.com/Duhemm).
diff --git a/resources/js/tweetMachine-update.js b/resources/js/tweetMachine-update.js
index 0addd1b95..1221b8cf4 100755
--- a/resources/js/tweetMachine-update.js
+++ b/resources/js/tweetMachine-update.js
@@ -37,7 +37,7 @@
user_name: 'scala_lang', // Set your username
include_retweets: true, // Set to true or false if you want to include retweets
exclude_replies: false, // Set to true or false if you want to exclude replies
- rate: 5000, // Rate in ms to refresh the tweets. Any higher than 5000 for search/tweets will get you rate limited
+ rate: 5000, // Rate in ms to refresh the tweets. Any rate greater than 5000 for search/tweets will get you rate limited
limit: 5, // Number of tweets to display at a time
autoRefresh: true, // CURRENTLY REQUIRED. Auto-refresh the tweets
animateOut: false, // NOT YET SUPPORTED. Animate out old tweets.
@@ -124,7 +124,7 @@
},
/*
- * Function to parse the text of a tweet and and add links to links, hashtags, and usernames
+ * Function to parse the text of a tweet and add links to links, hashtags, and usernames
*/
parseText: function (text) {
// Links
@@ -317,7 +317,7 @@
// });
//}
- // Increment the tweets diplayed
+ // Increment the tweets displayed
tweetsDisplayed++;
// Increase page number and wrap tweets if pagination is enabled and we're finishing a page: