Uh oh!
There was an error while loading. Please reload this page.
[SPARK-1997] update breeze to version 0.8.1 - #940
Conversation
AmplabJenkins
commented
Jun 2, 2014
Merged build triggered. |
AmplabJenkins
commented
Jun 2, 2014
Merged build started. |
AmplabJenkins
commented
Jun 2, 2014
Merged build finished. All automated tests passed. |
AmplabJenkins
commented
Jun 2, 2014
All automated tests passed. |
AmplabJenkins
commented
Jun 2, 2014
Merged build triggered. |
AmplabJenkins
commented
Jun 2, 2014
Merged build started. |
markhamstra
commented
Jun 2, 2014
What is the reason for this change, and how does it affect our intention to maintain binary compatibility? |
AmplabJenkins
commented
Jun 2, 2014
Merged build finished. All automated tests passed. |
AmplabJenkins
commented
Jun 2, 2014
All automated tests passed. |
rxin
commented
Jun 2, 2014
I don't think we ever expose Breeze in public facing API, do we? |
markhamstra
commented
Jun 2, 2014
We shouldn't, so I think we maintain source compatibility without any trouble. Are the MIMA checks good enough to catch binary incompatibility when we make significant changes to library dependencies? Not that I am asserting that this Breeze change is particularly significant, since I haven't look at the diff from 0.7. I'm more interested in the general case of what needs to be checked or done when we want to update dependencies while staying within the bounds of 1.x. |
witgo
commented
Jun 3, 2014
@markhamstra , |
markhamstra
commented
Jun 3, 2014
Neither does spark 1.0.0. We've offered no guarantee that any spark 1.x will work with scala 2.11. If it turns out that we can't cross-compile for scala 2.10 and 2.11 with essentially the same source code and dependencies and preserving our intention to preserve binary compatibility, then that may be the occasion that forces the beginning of spark 2.0 development. In any event, the breaking of our intent to preserve binary compatibility is no small matter and shouldn't slip into a PR without considerable discussion. I'm not certain that that is what is happening with this PR, but I do think that it is critical that we understand how strong our checks for binary compatibility are and what are the bounds on dependency upgrades that we can make while preserving that compatibility. |
witgo
commented
Jun 3, 2014
Speaking on spark, |
mengxr
commented
Jun 4, 2014
Let's put this PR on hold until Spark moves to Scala 2.11. Good to see that the breeze functions we used did not change in breeze-0.8.1. |
ktham
commented
Jun 4, 2014
Just looked at the release notes for Breeze 0.8 and initial glance at the commits... is there any particular reason why we are holding back this PR? If we want to cross compile with Scala 2.11, then we have to upgrade to breeze 0.8 because there does not exist a 2.11 build of breeze 0.7 We'll need to upgrade eventually. |
mengxr
commented
Jun 5, 2014
@ktham I think @markhamstra 's comments addressed the concerns very well. Unless there are critical bugs in breeze 0.7, we should wait until Spark core starts to move. Breeze has a fast release cycle. So we don't need to rush to 0.8.1. |
nevillelyh
commented
Jun 19, 2014
We just hit a bug when DenseVector in 0.7 triggers StackOverflowError in KryoSerializer. |
mengxr
commented
Jun 19, 2014
@nevillelyh Is there a JIRA for it? Is it fixed in 0.8.1? |
nevillelyh
commented
Jun 19, 2014
SparkQA
commented
Jul 11, 2014
QA tests have started for PR 940. This patch merges cleanly. |
SparkQA
commented
Jul 11, 2014
QA results for PR 940: |
SparkQA
commented
Jul 19, 2014
QA tests have started for PR 940. This patch merges cleanly. |
mengxr
commented
Jul 21, 2014
Jenkins, retest this please. |
1 similar comment
mengxr
commented
Jul 28, 2014
Jenkins, retest this please. |
SparkQA
commented
Jul 28, 2014
QA tests have started for PR 940. This patch DID NOT merge cleanly! |
srowen
commented
Aug 1, 2014
mengxr
commented
Aug 1, 2014
Ah, I see. Tests were against individual build instead of the assembly jar. We should have integration tests in the future. |
avati
commented
Aug 1, 2014
Yes, either #1701 or #1369. We are already broken till they are committed. On Fri, Aug 1, 2014 at 8:19 AM, Xiangrui Meng notifications@github.com
|
mengxr
commented
Aug 1, 2014
I think Jenkins should be fine but the assembly jar is broken. Is it right? |
avati
commented
Aug 1, 2014
I think so, just like commons-math3 |
witgo
commented
Aug 1, 2014
How do we resolve this issue? |
mengxr
commented
Aug 1, 2014
srowen
commented
Aug 1, 2014
I think @witgo's PR strongly suggests it's OK to upgrade to 2.1.2? |
avati
commented
Aug 1, 2014
The other option could have been to keep #940 merged and merge also #1701 |
marmbrus
commented
Aug 1, 2014
I'm okay with upgrading the version of scala logging that we use as @avati suggests. |
`breeze 0.8.1` dependent on `scala-logging-slf4j 2.1.1` The relevant code on apache#1369 Author: witgo <witgo@qq.com> Closesapache#940 from witgo/breeze-8.0.1 and squashes the following commits: 65cc65e [witgo] update breeze to version 0.8.1
breeze-0.8.1 causes dependency issues, as discussed in apache#940 . Author: Xiangrui Meng <meng@databricks.com> Closesapache#1718 from mengxr/revert-breeze and squashes the following commits: 99c4681 [Xiangrui Meng] downgrade breeze version to 0.7
…he#940) Co-authored-by: Egor Krivokon <>
…& Sum which handle by themself internally (#940) * Fix Number of partitions (0) must be positive * [SPARK-34037][SQL] Remove unnecessary upcasting for Avg & Sum which handle by themself internally ### What changes were proposed in this pull request? The type-coercion for numeric types of average and sum is not necessary at all, as the resultType and sumType can prevent the overflow. ### Why are the changes needed? rm unnecessary logic which may cause potential performance regressions ### Does this PR introduce _any_ user-facing change? no ### How was this patch tested? tpcds tests for plan Closes#31079 from yaooqinn/SPARK-34037. Authored-by: Kent Yao <yao@apache.org> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit a235c3b) * [SPARK-34037][SQL] Remove unnecessary upcasting for Avg & Sum which handle by themself internally ### What changes were proposed in this pull request? The type-coercion for numeric types of average and sum is not necessary at all, as the resultType and sumType can prevent the overflow. ### Why are the changes needed? rm unnecessary logic which may cause potential performance regressions ### Does this PR introduce _any_ user-facing change? no ### How was this patch tested? tpcds tests for plan Closes#31079 from yaooqinn/SPARK-34037. Authored-by: Kent Yao <yao@apache.org> Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com> (cherry picked from commit a235c3b) * fix Co-authored-by: Kent Yao <yao@apache.org>
…he#940) Co-authored-by: Egor Krivokon <>
…he#940) Co-authored-by: Egor Krivokon <>
breeze 0.8.1dependent onscala-logging-slf4j 2.1.1The relevant code on #1369