fwiw re: shell, this is just scala being incredibly useful. If anything,
spark is following scala. So is for example BIDMat/BIDMach (and, sigh*
mahout). I don't think differentiation means throwing away common baseline
tools, there's gotta be more than that. (I'm of course advocating using
shell in
Thanks Stephan, Kostas, sounds good to me
On Wed, Feb 4, 2015 at 2:57 AM, Kostas Tzoumas wrote:
> Yeah, this is something that nobody is working on AFAIK and not a major
> focus of the project. I moved it to the interesting projects page (and
> cleaned up the page a bit removing streaming, tez, a
Yeah, this is something that nobody is working on AFAIK and not a major
focus of the project. I moved it to the interesting projects page (and
cleaned up the page a bit removing streaming, tez, and mahout as these are
ongoing efforts).
On Wed, Feb 4, 2015 at 9:34 AM, Stephan Ewen wrote:
> I agre
I agree, Henry. To me, this is a low priority feature and not one in the
main line of what I see as the core Flink direction.
I included it in there, because it is actually a fairly low hanging
fruit. Once the stuff for the Zeppelin Integration is in place, it is a
neat project for someone (extern
Hi All,
I am not sure about "Interactive Scala shell". I just feel like adding
feature like this may look like following Spark.
We could probably focus more on CLI and client libraries toward better
and scale backend execution engine compare to Spark.
- Henry
On Thu, Jan 8, 2015 at 1:57 AM, Rob
Hi Kostas,
Thanks for putting this into the wiki. I added the JIRA link for the
off-heap memory. Now the wiki displays:
> Error rendering macro 'jira' :
> com.atlassian.confluence.macro.MacroExecutionException:
> java.lang.RuntimeException: Not Found
If persistent, we should report this.
Is t
Hi everyone,
I started a wiki page about this:
https://cwiki.apache.org/confluence/display/FLINK/Flink+Roadmap
If you are working on one of these features, could you insert the
corresponding JIRA ticket and expand the description if you think it's not
informative enough?
I saw that there is a st
+1 for indicating the person currently working on the issue, we can just
open a JIRA issue for each of these. And we can clearly indicate that other
features are not being currently worked on.
How about indicating rough time goals (quarters) for issues that are
currently being worked on (of course
