Github user echarles commented on the issue:
https://github.com/apache/zeppelin/pull/980
Closing this. Spark 2.0 is implemented with #1195
Optionally, a new PR can be opened to port the Spark interpreter from Java
to Scala if interest.
---
If your project is set up for it, you
Github user rnirmal commented on the issue:
https://github.com/apache/zeppelin/pull/980
Sounds good, I'll keep a lookout for it to land.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this
Github user rnirmal commented on the issue:
https://github.com/apache/zeppelin/pull/980
@echarles @Leemoonsoo do you know where the direction lies for Spark 2.0
with scala 2.11 support.. i.e as separate items or continued effort on this PR?
Since Spark 2.0 is going to be release in
Github user echarles commented on the issue:
https://github.com/apache/zeppelin/pull/980
- If you ship in the same folder scala libs from different versions, it
will at runtime - You don't have to rebuilt, but you have to arrange classpath
is built with scala libs of the same version
Github user Leemoonsoo commented on the issue:
https://github.com/apache/zeppelin/pull/980
@echarles
> I was just saying that a single binary will not fit all various users
need (multiple combination of interpeters and versions).
If single SparkInterpreter binary is
Github user echarles commented on the issue:
https://github.com/apache/zeppelin/pull/980
@Leemoonsoo
- I was just saying that a single binary will not fit all various users
need (multiple combination of interpeters and versions).
- #629 is merged. What remains to get
Github user felixcheung commented on the issue:
https://github.com/apache/zeppelin/pull/980
+1 on all of that. I think we could work together on a proposal to see what
is the best way to go forward.
I think we are way overdue on separating "programming languages" (and
versions)
Github user Leemoonsoo commented on the issue:
https://github.com/apache/zeppelin/pull/980
Why not single binary works for spark-2-scala-2.11 and
flink-0.9-scala-2.12?
I'm also not a fan of reflection. But if i have to choose either complexity
of code or complexity usage, then i
Github user Leemoonsoo commented on the issue:
https://github.com/apache/zeppelin/pull/980
Thanks for elaborate on idea about 2 lines approach.
I think there're always pros and cons.
If we go to 2 lines approach, code will be cleaner, simpler and more easier
to read.
Github user echarles commented on the issue:
https://github.com/apache/zeppelin/pull/980
Dealing with mixed scala 2.10/2.11 and spark 1.x/2.x with a same
implementation is always possible but drives to code plenty of method
invocation (see e.g.
Github user felixcheung commented on the issue:
https://github.com/apache/zeppelin/pull/980
From what I see, we should still be able to use most of the existing code.
Could you elaborate more on how bad it would be to support Spark 1.x and 2.x in
the same interpreter code?
---
If
Github user Leemoonsoo commented on the issue:
https://github.com/apache/zeppelin/pull/980
I'm trying to combine 2.10 and 2.11 into one implementation in lresende#1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
12 matches
Mail list logo