Sounds good.
Kind Regards,
Corey Stubbs
On Thu, Feb 2, 2017 at 9:50 AM Luciano Resende wrote:
> I am not suggesting doing "everything" via SBT, just the basic compile,
> test, build and package so that contributors used to other sbt based
> projects fill comfortable
I have uploaded the report to the wiki and signed off as a mentor, and will
take the blame if anyone complains about it :)
On Thu, Feb 2, 2017 at 4:28 AM, Chip Senkbeil
wrote:
> Guess we missed this one since it was due yesterday. Considering they
> really didn't like
I am not suggesting doing "everything" via SBT, just the basic compile,
test, build and package so that contributors used to other sbt based
projects fill comfortable getting started with the project. For all the
other more optional/complex tasks, I am all for using a set of fully
documented
Let's start by identifying some scenarios that the client is used:
- Users trying to build an application which needs to interactively
integrate with Spark, where the client is used to submit a piece of code
and expects an indication that the full results are back to continue doing
what it needs
So the client programming model is meant to reflect the Jupyter Protocol,
which has taken into account issues like streaming. However, the client
could still be cleaned up. Maybe something along the lines of:
val exRes: DeferredExecution = client.execute(code)
.onError(executeReplyError =>{
...
My typical development flow is to write code, run pip-release , and then
install the pip release locally on my machine (pip install
dist/toree-pip/pip-release; jupyter toree install), and test changes with
the install.
+1 on working on documenting the make targets.
In terms of getting everything
Guess we missed this one since it was due yesterday. Considering they
really didn't like when we edited after the deadline earlier, we should
just be listed as missing the report.
On Wed, Feb 1, 2017, 11:12 PM Marius van Niekerk
wrote:
> Pretty sure the following is