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 c
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 f
Github user Leemoonsoo commented on the issue:
https://github.com/apache/zeppelin/pull/980
@rnirmal Vote for 0.6.0-rc1 is about to start. We'll need 0.6.1 release
immediately after we have scala 2.11 and spark 2.0 support.
Currently, @lresende and me are trying to make [Scala
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 th
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 Oh, #908 is the one I was looking for
---
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 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 ZEPPELIN-
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) an
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 echarles commented on the issue:
https://github.com/apache/zeppelin/pull/980
Agree with your agurment. If we push a bit further the discussion, we can
not have a single binary which fits all users needs. What if I want
spark-2-scala-2.11 with flink-0.9-scala-2.12 ? You sin
Github user Leemoonsoo commented on the issue:
https://github.com/apache/zeppelin/pull/980
When @minahlee contributed dependency loading through interpreter setting,
we also thought DepInterpreter can be deprecated and removed. That's why
current documentation of spark interpreter mar
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.
https://github.com/lresende/incubator-z
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 y
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
16 matches
Mail list logo