You should be able to enable logging for the interpreter group. It's the log
properties file under conf. There are instructions around, but let me know if
you aren't able to get it working.
> On May 11, 2016, at 12:06 AM, Samuel Alexander
> wrote:t
>
> Hi Amos,
>
> It doesn't contain any ot
Ethan - can you clarify what you mean when you say you couldn't find it? What
specifically fails to happen? Are there any log messages?
You're attempting to build two separate interpreters, -Pr and -Psparkr both of
which want to bind to the same interpreter name, and I don't believe the
behavi
Ankur - I haven't tried this, but if you have R installed, installing with -Pr
may actually pull in knitr and evaluate.
Either way, one package that definitely will have to be installed manually, is
'repr'. There are instructions for doing this on the manual page.
> On Apr 8, 2016, at 7:23 AM,
Thanks @bzz. I'm a little bit confused about where we are now - will one or
both interpreters work for people who download this now?
> On Apr 6, 2016, at 5:39 AM, b...@apache.org wrote:
>
> Repository: incubator-zeppelin
> Updated Branches:
> refs/heads/master fb8e77bfd -> 9cc7e4f40
>
>
> Re-
If the interpreters get moved out of the spark interpretergroup, they won't be
able to access spark.
> On Apr 6, 2016, at 2:49 AM, Eric Charles wrote:
>
> C) sounds also logical to me. It follows closer the implementation.
>
>> On 05/04/16 20:58, Jeff Steinmetz wrote:
>> I actually was thinkin
Build-distr wasn't resolved but I don't get what you mean about it can't be
used - the source code is our release. Build-distr is just the "convenience"
binary, no?
> On Apr 5, 2016, at 4:11 PM, Jeff Steinmetz
> wrote:
>
> Did the -Pr profile get set up to work with distribution via -Pbuild-
When I force push, I insert white space into a file where it will be ignored to
trick git.
> On Apr 1, 2016, at 12:26 PM, Eric Charles wrote:
>
> On 30/03/16 23:04, DuyHai Doan wrote:
>
> (snip...)
>
>> --> Same problem here, some times some of my PRs are just red because of
>> random failur
There is a community consensus against this PR, which has not been around in
its current form for a fraction of the time that would be necessary to evaluate
it.
> On Mar 30, 2016, at 10:42 AM, Leemoonsoo wrote:
>
> Github user Leemoonsoo commented on the pull request:
>
>
> https://github
wrote:
>>>>
>>>>> No Moon - You've got it backwards. No-one supports *your* position.
>>>>>
>>>>> *You* are ignoring the community and attempting to impose your will on
>>>>> everyone else.
>>>>>
>>
t; improving
>>>> the
>>>>>>>> quality
>>>>>>>>> of the contributions made, rather than knowing that
>> willingness
>>>> of
>>>>>>> other
>>>>>>>>> people to help comes from the personal
gt; feature can be added.
>>
>> Regards,
>> Sourav
>>
>>
>>> On Mon, Mar 28, 2016 at 12:37 AM, Eran Witkon wrote:
>>>
>>> @Elberg, If I were you I would ask myself why isn't the community taking
>>> part in this debate?
&g
gt; feature can be added.
>>
>> Regards,
>> Sourav
>>
>>
>>> On Mon, Mar 28, 2016 at 12:37 AM, Eran Witkon wrote:
>>>
>>> @Elberg, If I were you I would ask myself why isn't the community taking
>>> part in this debate?
&g
;
>>> Thanks,
>>> moon
>>>
>>>
>>> On Tue, Mar 29, 2016 at 9:31 AM Konstantin Boudnik
>> wrote:
>>>
>>>> hmm that's getting weird again. So, far I failed to see:
>>>> - CI issues being addressed. If the co
nity taking
> part in this debate?
> Personally I prefer a team player as a contributor over the best developer.
> just my 2c
> Eran
>
>> On Mon, 28 Mar 2016 at 09:52 Amos B. Elberg wrote:
>>
>> Moon - I opened this discussion so it could take place with the communit
Jeff
>>>
>>>
>>>> On 3/28/16, 4:13 PM, "Sourav Mazumder"
>>> wrote:
>>>
>>>> All said and done we had enough discussion on this point for many months
>>>> now. As far as I know, 208 is the PR which community/people hav
Moon - I opened this discussion so it could take place with the community as a
whole, not just you.
Suffice it to say, I disagree with every one of the technical claims you've
just made, and I don't trust your intent.
Let the community process happen.
> On Mar 28, 2016, at 2:47 AM, moon soo
Moon - is there really such an urgency with this PR that it can't wait 12-24
hours for a discussion over whether we should do it before we have an interface
to support it?
> On Mar 27, 2016, at 7:10 PM, Leemoonsoo wrote:
>
> Github user Leemoonsoo commented on the pull request:
>
>
> htt
t;
> You're not trying to interrupt PPMC reviewing contribution, right?
>
> Thanks,
> moon
>
> On Wed, Mar 16, 2016 at 10:58 PM Amos B. Elberg
> wrote:
>
>> Moon - you committed to stay out of these issues. If you're going to be
>> involved at a
way of spending your precious time.
>
> Thanks,
> moom
>
> [1] http://theapacheway.com/
>
>
> On Thu, Mar 17, 2016 at 2:09 PM Amos B. Elberg
> wrote:
>
>> Moon - No-one in the community supported your refusal to fix CI. No-one
>> supported your lic
This links to 703, which creates per-notebook interpreters and I'm now starting
to see problems with.
> On Mar 16, 2016, at 1:29 PM, sourav-mazumder wrote:
>
> Github user sourav-mazumder commented on the pull request:
>
>
> https://github.com/apache/incubator-zeppelin/pull/703#issuecomme
upport you if you decided to change your
> strategy to 'Apache way'. Let me know if you need any help.
>
> Thanks,
> moon
>
> On Thu, Mar 17, 2016 at 12:42 PM Amos B. Elberg
> wrote:
>
>> Moon, youve been impeding 208 since Felix asked you to. Your su
nk, not accusing someone.
>
> Thanks,
> moon
>
> [1] http://www.apache.org/foundation/how-it-works.html#philosophy
>
>
> On Thu, Mar 17, 2016 at 8:22 PM Amos B. Elberg
> wrote:
>
>> Moon - 208 has been ready for merge for six months.
>>
>> The
Moon - you committed to stay out of these issues. If you're going to be
involved at all, you should start by honoring the commitments you made in the
past.
> On Mar 17, 2016, at 1:45 AM, Leemoonsoo wrote:
>
> Github user Leemoonsoo commented on the pull request:
>
>
> https://github.com/
e.org/foundation/policies/conduct.html
>
> Hope those links helps change your point of view to Apache project,
> especially for concept of collaborative, open and respectful.
>
> Thanks,
> moon
>
> On Thu, Mar 17, 2016 at 10:07 AM Amos B. Elberg
> wrote:
>
>> Mo
This PR needs to be a broader discussion.
If Zeppelin is going to support windows, that means making a commitment to
support windows. That's means supporting a wider variety of configurations, and
varying levels of user ability, orders of magnitude beyond what we do now. How
are we going to CI
>> suggestions I raised, which I wouldn’t consider to be a show stoppers for
>> getting an R interpreter off the ground as a first step.
>> Although, if we came up with an awesome solution to help buckle down R
>> package management in Zeppelin, there is no reason not
Sadly with inexplicable delays etc. I am left with the
>> impression that he got a rough deal.
>>
>> But the community needs to move on: let’s bygones be bygones and let's
>> integrate these PRs (fast, please?).
>>
>> Enzo
>> e...@smartinsightsfromdat
ystem.
Why are you still defending this? It was a poor design decision. Move on.
> On Mar 9, 2016, at 1:05 AM, Eric Charles wrote:
>
>
>> On 09/03/16 06:41, Amos B. Elberg wrote:
>> That's not true eric. When rscala was updated to 1.0.8, your interpreter
>> b
p with obscure error messages that
have to be diagnosed.
> On Mar 9, 2016, at 12:22 AM, Eric Charles wrote:
>
>
>
>> On 09/03/16 06:05, Amos B. Elberg wrote:
>> Jeff you're correct that when Zeppelin is being professionally
>> administered, the administrator
llet proof way to locking “everything" down is a tough challenge.
>
>
> Jeff Steinmetz
> Principal Architect
> Akili Interactive
> www.akiliinteractive.com <http://www.akiliinteractive.com/>
>
>
>
>
>
>
>> On 3/8/16, 12:16 PM, "Amos B. Elberg"
Jeff - one of the problems with the rscala approach in 702 is it doesn't take
into account the R library. If rscala gets updated, the user will likely
download and update it automatically when they call update.packages(). The
result will be that the version of the rscala R package doesn't match
Those are not the options people were voting on before, and they frankly don't
make sense. What was plan "a" before, was to merge 208 without further delay.
That's what people were voting for.
The three new "options" leave out the one I had proposed, and which people had
voted for: merge 208
That's not the current vote. The vote for C is 1, which is alex.
> On Mar 8, 2016, at 1:15 AM, Alexander Bezzubov wrote:
>
> Ok, thank you all for participating in this public discussion - there is no
> reason for anybody to stay out of it, community opinions are very welcome.
>
> To summarize
else? Please share them if you have.
Thanks,
moon
On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg
wrote:
> Moon, I thought you were staying out of this?
>
> It sure sounds like we're back on the same path we were on before, where
> there's just a series of
Moon, I thought you were staying out of this?
It sure sounds like we're back on the same path we were on before, where
there's just a series of excuses for not merging 208, none of which have any
technical justification.
> On Mar 7, 2016, at 1:11 PM, moon soo Lee wrote:
>
> Hi,
>
> I agree
Moon - people asking when the next version is coming out, I don't think that's
a request to shift from a feature-based to a date-based release people policy.
It's just asking when the next release is.
The logic that even without date-based releases there will be releases every
2-4 months becau
Guys - I'm forwarding this because he raises an issue that I've raised several
times in different contexts: what should we do about spark-under-Zeppelin? I
had thought it would have been fully deprecated by now. Part of the issue he
raises is that currently the Zeppelin configuration system is n
Jeff makes a good point - the project still needs to get to a 1.0 release.
The definition of a 1.0 release would seem to be feature/testing-based.
Perhaps the priority should be defining, and then completing, 1.0. Then if
there's still demand, the project could switch to calendar-based for peri
question about any of this, I'll address it.
> On Feb 23, 2016, at 2:06 PM, Eric Charles wrote:
>
>
>> On 23/02/16 19:52, Amos B. Elberg wrote:
>> Eric, they're not equivalent. 208 continues to have functionality 702
>> doesn't, including the display s
2/16 19:09, Jeff Steinmetz wrote:
>> Thank you Amos Elberg & Eric Charles:
>> Is the goal of the community to merge both 208 and 702 at some point as two
>> “different” R interpreters?
>>
>> One that is
>> %r
>> And another that is
>> %spark.r
>
community to merge both 208 and 702 at some point as two
> “different” R interpreters?
>
> One that is
> %r
> And another that is
> %spark.r
>
> Still trying to wrap my head around the difference.
>
>
>
>
>> On 2/23/16, 9:34 AM, "Amos B. Elber
Jeff - 702 isn't a fork, it's an alternative based on 208 that has a subset of
208's features. 208 is the superset. 208 is also what the community is now
attempting to integrate.
R does support serialization of functions.
208 does support passing a spark table back and forth between R and sca
> Please don't be ridiculous.
> You also emailed me privately at that time and I said i can not judge who
> is laying, because of i'm not a judge and not capable of. Instead I made
> you and Felix say sorry and thanks each other and move forward.
Actually no, that isn't what happened.
I did agre
PR for a long time. (Especially Jongyoul
>> and
>>> Felix helped a lot)
>>>
>>> So, let's move discussions like 'which feature should be included' to the
>>> release / roadmap discussion.
>>> In the graduation discussion, i'
why you taking me to want turn personal debate to you.
> I'm sure i don't want to have personal debate to you.
>
> I just wanted you share you reason why you think specific features are
> prerequisites. Can you share the reason why?
>
> Thanks,
> moon
>
>> On
#x27;s off-topic. Also alternative discussion thread that can be handled.
>
> Amos, if you think specific features are prerequisites of graduation,
> please share the reason why.
>
> Thanks,
> moon
>
> On Thu, Feb 4, 2016 at 11:01 AM Amos B. Elberg
> wrote:
>
&
#x27; to the
> release / roadmap discussion.
> In the graduation discussion, i'd like to have an discussions, such as
> evaluating
> http://community.apache.org/apache-way/apache-project-maturity-model.html,
> etc.
>
> Does this make sense for you guys? Amos, Eran, Sourav?
No Eran is right. The last vote for graduation passed-it was not withdrawn in
favor of releasing 0.5.6. It passed and there was some feedback from the
mentors concerning graduation, R, and some other issues. And that's the last
public discussion about graduation until today.
Alex if you disagr
Jeff - I agree with you.
> On Jan 14, 2016, at 2:09 PM, Jeff Steinmetz
> wrote:
>
> Curious how others feel.
>
> Would it make sense for somebody that knows the maven build structure very
> well (I acknowledge this is not me) to move all interpreters into a
> subdirectory instead of sitting
clude REASON WHY you think in
that way otherwise it's hard to understand what you're thinking.
Thanks,
moon
On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg
wrote:
> Do you want me to explain the commits after 0.5.5 in details?
> I want you to provide an exampl
moon
>
> [1]
> https://issues.apache.org/jira/browse/ZEPPELIN-476?jql=labels%20%3D%20flaky-test%20and%20project%20%3D%20zeppelin
>
> [2] https://github.com/apache/incubator-zeppelin/pull/527
>
> On Tue, Dec 29, 2015 at 10:08 PM Amos B. Elberg
> wrote
r not?
From: Jongyoul Lee
Reply: Jongyoul Lee
Date: December 30, 2015 at 1:05:55 AM
To: Amos B. Elberg
CC: dev@zeppelin.incubator.apache.org
Subject: Re: [DISCUSS] Release 0.5.6-incubating
Do you want me to explain the commits after 0.5.5 in details? And what is your
answer that why
ommit/986b0adba3a7986a387c0633d15279b6b2f45c95
On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg
wrote:
> A codebase that often changes in ways that break other code is an unstable
> codebase, by definition.
>
> I don’t think it will be more stable at runtime, especially since CI isn’t
>
? What feature other than
1.6 and Ignite does anyone feel justifies a 0.5.6 release?
From: Jongyoul Lee
Reply: Jongyoul Lee
Date: December 30, 2015 at 12:32:01 AM
To: Amos B. Elberg
CC: dev@zeppelin.incubator.apache.org
Subject: Re: [DISCUSS] Release 0.5.6-incubating
Amos,
I don't thi
table.
Is there any merged PR that is so important it can’t wait for 0.6?
From: Jongyoul Lee
Reply: Jongyoul Lee
Date: December 29, 2015 at 11:54:35 PM
To: Amos B. Elberg
CC: dev@zeppelin.incubator.apache.org
Subject: Re: [DISCUSS] Release 0.5.6-incubating
Okay, Amos,
Do you pr
issues are I think we need to fix CI in general, and I’m loathe to have more
releases with that dammed spark-under-zeppelin code, which is the root of many
other issues.
From: Jongyoul Lee
Reply: Jongyoul Lee
Date: December 29, 2015 at 11:21:00 PM
To: Amos B. Elberg , dev
describe a reason why do you think CI is potential blocker for 0.5.6.
On Tue, Dec 29, 2015 at 8:14 PM Amos B. Elberg
wrote:
> I don’t think R interpreter is a blocker for 0.5.6.
>
> I think *CI* is a potential blocker for 0.5.6.
>
>
> From: moon soo L
8:00 PM Chae-Sung Lim wrote:
> Oh, I'm sorry.
> Thank you. Good point.
>
> I am in favor for the release of the 0.5.6-incubating.
>
> 2015-12-29 19:56 GMT-08:00 Amos B. Elberg :
>
> > Chae-Sung — What Moon has proposed is a 0.5.6 release *without* S
. And concerning rebasing and
committing, I think there is no big pain because whole changes to be merged
into 0.5.6 will be also merged into 0.6.0.
JL
On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg
wrote:
> I don’t want to come off as the naysayer here, but I think the effort t
that security is an enhanced version of the release is required by
the current Zeppelin.
(Shiro)
2015-12-29 19:32 GMT-08:00 Amos B. Elberg :
> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the t
I don’t want to come off as the naysayer here, but I think the effort that
would go into a release would be better spent on the testing infrastructure and
outstanding PRs.
If we feel we need a release for 1.6 and Ignite, I suggest we make a release
that *only* includes the absolute minimal ch
Yeah that kind of error is basically what I was seeing.
I copied that line of travis.yml from something I found online as an example of
how to add R to a java-based travis build.
How can I help?
From: moon soo Lee
Reply: moon soo Lee
Date: December 26, 2015 at 10:28:34 PM
To: Amos B. Elberg
I think I know a PR you could use to test it out. :)
From: Hyung Sung Shim
Reply: dev@zeppelin.incubator.apache.org
Date: December 20, 2015 at 9:56:31 PM
To: dev@zeppelin.incubator.apache.org
Subject: [DISCUSS] CI system for zeppelin
Dear devs.
I'd like to propose new CI system for the
If you want stable R support now, then you definitely want to be using the new
branch: https://github.com/elbamos/Zeppelin-With-R
It’s built on top of 0.5.5 release so its stable. So far I’ve had one report
of trouble installing on Windows with docker, but other than that it seems to
be stabl
branch.
That would conflict to master since your new branch is based on 0.5.5 but
fixing those conflict shouldn't be too hard.
Will this steps works for you Amos?
Thanks,
moon
On Fri, Dec 11, 2015 at 12:10 PM Amos B. Elberg
wrote:
> I’m sorry for the delay in respondi
I’m sorry for the delay in responding, I’m just seeing this now.
Moon and I exchanged some productive e-mails.
I think we’ve begun a process that I’m optimistic about.
My intention is to push a new branch to my repo tonight that is the PR against
0.5.5, as a kind of release. This is essent
esult here.
> > Hope i can narrow down the cause and that helps involvement of more
> people.
> >
> > Thanks,
> > moon
> >
> > On Tue, Dec 8, 2015 at 3:08 PM Amos B. Elberg
> > wrote:
> >
> > > Is there anyone who
parated from the tree,
> > and easily pluggable with a release instead of forcing users to build the
> > project to use them.
> >
> >
> > On Thu, Dec 3, 2015 at 9:26 AM, Konstantin Boudnik
> wrote:
> >
> > > On Wed, Dec 02, 2015 at 04:2
e responding to this.
From: moon soo Lee
Reply: moon soo Lee
Date: December 3, 2015 at 12:15:41 AM
To: Amos B. Elberg , dev@zeppelin.incubator.apache.org
Subject: Re: contributions impasse. Was: [GitHub] incubator-zeppelin pull
request: R Interpreter for Zeppelin
On Thu, Dec 3, 2
ase to have some interpreters separated from the tree,
> and easily pluggable with a release instead of forcing users to build the
> project to use them.
>
>
> On Thu, Dec 3, 2015 at 9:26 AM, Konstantin Boudnik wrote:
>
> > On Wed, Dec 02, 2015 at 04:28PM, Amo
tone that can happen in our e-mail exchange.
The invitation stands.
I will continue to look for ways to move forward in the spirit of cooperation
and teamwork.
From: moon soo Lee
Reply: moon soo Lee
Date: December 2, 2015 at 10:24:52 PM
To: Amos B. Elberg , dev@zeppelin.incubator.
er for Zeppelin
On Thu, Dec 3, 2015 at 7:34 AM Amos B. Elberg wrote:
> Moon, thank you for your reply.
>
> Of course, I can claim CI, license, etc and any other issue. Especially
> when CI is not passing, I can not sure about the license. To me, these
> claims are sign
os for replying.
On Thu, Dec 3, 2015 at 3:17 AM Amos B. Elberg wrote:
> Moon — I think there is a misunderstanding about the topic of the
> discussion.
>
> The PR has its own userbase. It has been and is being presented at user
> groups. Its been blogged and tweeted about
; > Moon's interpretation.
> >
> > KnitRInterpreter is not optionally required. so it does not matter KnitR is
> >
> > optionally required or not.
> > R dependency in SparkR is exception of GPL. KnitR is not applied that
> > exception.
> &g
included in binary release
>
> So in the case of licensing issues, it would need to be fully optional
> (user bring the interpreter in his directory and build Zeppelin with it)
>
>
> On Wed, Dec 2, 2015 at 6:33 PM, Amos B. Elberg
> wrote:
>
>> Moon l
d, Dec 2, 2015 at 5:44 PM Alexander Bezzubov wrote:
> Just pushing discussion back on the list
>
> On Wed, Dec 2, 2015, 01:14 Amos B. Elberg wrote:
>
> > Alex — if you genuinely do not know the history of this, then I will fill
> > you in.
> >
> &
ect?
If it is not could you clarify it?
Thanks,
moon
On Wed, Dec 2, 2015 at 10:34 AM Amos B. Elberg
wrote:
> Just to put the final nail in this, I looked it up.
>
> I see no evidence of any “compiler exception.”
>
> There is an exception in the license for
ot of this type of work around IP at my $DAYJOB
On Tue, Dec 1, 2015 at 5:25 PM, Amos B. Elberg wrote:
> Moon - If there were seriously a licensing issue, then you or someone else
> would be able to say clearly and specifically what it is.
>
> There plainly is not. This idea
believe this is part of the reason why LLVM was created.
From: moon soo Lee
Reply: moon soo Lee
Date: December 1, 2015 at 8:16:36 PM
To: Amos B. Elberg , dev@zeppelin.incubator.apache.org
Subject: Re: contributions impasse. Was: [GitHub] incubator-zeppelin pull
request: R Interpreter for
ld
scare people off.
If someone really believed there was a licensing issue, they would be able to
say clearly what that issue is.
I am not going to respond to the rest of Moon’s e-mail.
From: moon soo Lee
Reply: moon soo Lee
Date: December 1, 2015 at 8:16:36 PM
To:
@zeppelin.incubator.apache.org
Date: December 1, 2015 at 6:48:47 PM
To: dev@zeppelin.incubator.apache.org
Subject: Re: contributions impasse. Was: [GitHub] incubator-zeppelin pull
request: R Interpreter for Zeppelin
On Wed, Dec 2, 2015 at 1:09 AM Amos B. Elberg wrote:
> I am going to try to minimize
ginning” cannot be a problem if you never actually
started the first time...
From: moon soo Lee
Reply: moon soo Lee
Date: December 1, 2015 at 4:42:06 AM
To: Amos B. Elberg , dev@zeppelin.incubator.apache.org
Subject: Re: contributions impasse. Was: [GitHub] incubator-zeppelin pull
request: R
Thank you, Cos.
I’d like to briefly address the issues raised by Moon:
1. This PR does not passes CI
The CI fails on core Zeppelin, *not* code in this PR.
I’ve been seeking assistance on this since August.
The most common reason is that SparkInterpreter is unable to launch Spark and
open
on” was me being polite.
From: Konstantin Boudnik
Reply: dev@zeppelin.incubator.apache.org
Date: November 27, 2015 at 9:16:37 PM
To: dev@zeppelin.incubator.apache.org
Subject: Re: Trying CTR for the project
On Fri, Nov 27, 2015 at 09:02PM, Amos B. Elberg wrote:
> I think CTR may be a good
I think CTR may be a good idea.
Considering all the excellent efforts to build community by Moon and others, I
can understand why he has experienced the community in the way he describes.
My experience, however, has been different. I’m not sure that community
involvement is either as broad,
+1
> On Nov 5, 2015, at 10:03 AM, DuyHai Doan wrote:
>
> +1 for the second relase
>
>> On Thu, Nov 5, 2015 at 4:02 PM, Mina Lee wrote:
>>
>> +1
>> 2015. 11. 6. 오전 12:01에 "moon soo Lee" 님이 작성:
>>
>>> Hi folks,
>>>
>>> I propose the following RC to be released for the Apache Zeppelin
>>> (inc
And could you run mvn test from the r subdirectory and send the result?
I just checked and it looks like in the revision currently up, repr is getting
called to handle some warnings/errors. It should really only be called to
process some images. It isn't supposed to be a dependency. That's my ba
an awesome plan to me, thank you Moon for
> outlining it!
>
> --
> Kind regards,
> Alexander
>
> On Tue, Sep 8, 2015 at 6:18 AM, Amos B. Elberg
> wrote:
>
>> Can we get the rinterpreter in?
>>
>>> On Sep 7, 2015, at 1:17 PM, moon soo Lee wrot
getting the same error.
>
> This is the files I have in the interpreter/spark/dep directory:
>
> datanucleus-api-jdo-3.2.6.jar
>
> datanucleus-rdbms-3.2.9.jar
>
> datanucleus-core-3.2.10.jar
>
> zeppelin-spark-dependencies-0.6.0-incubating-SNAPSHOT.jar
>
&g
lease!
>>> Great job has been done by the whole community indeed.
>>> Then we can release 0.6.0 as soon as the scope is there.
>>>
>>> On Fri, Aug 28, 2015 at 11:40 PM, Amos B. Elberg
>>> wrote:
>>>
>>>> +1 on interim release. There h
Guys this is very similar to the issues I was having since we changed to the
"spark dependencies" module configuration.
To solve it, I had to switch to the spark-submit system. I also had to
recompile spark, since apparently some build configurations (and those with
Hadoop provided) don't put
Has anyone gotten it working behind nginx not at the root path, like at
/zeppelin ?
> On Sep 2, 2015, at 8:46 AM, Albert Yoon wrote:
>
> In nginx, you have to setup reverse proxy config for zeppelin websocket port
> in addtion to normal zeppelin http port. you can find instruction on nginx
>
Seems like we have two separate components. One is to allow interpreters to
update interpreter results. The other is interpreters that do that.
> On Aug 28, 2015, at 11:02 AM, IT CTO wrote:
>
> +1 for streaming support.
>
> בתאריך יום ו׳, 28 באוג׳ 2015, 17:53 מאת Christian Tzolov > :
>
>> I'v
+1 on interim release. There have been so many changes it would be helpful to
have a more stable code base to develop against. Any way R could get into that
as an experimental feature?
> On Aug 28, 2015, at 3:03 AM, moon soo Lee wrote:
>
> About tracking number downloads
>
> Currently downloa
All:
I have a pending PR, #208, to add an R interpreter to Zeppelin. Last night I
pushed a bunch of new code to the PR. In particular, the R interpreter shares a
spark context with the Spark interpreter and joins the Spark interpreter group.
It also starts to add unit tests, with more to come a
t; registeredInterpreters.add(ri);
>}
> }
>
> return registeredInterpreters;
> }
>
> I will create a fix for this.
>
>
> On Fri, Aug 21, 2015 at 10:18 PM Amos B. Elberg
> wrote:
>
>> Have you checked whether the additional objects can be ca
Have you checked whether the additional objects can be cast to
wrappedinterpreter or classloaderinterpreter?
I suspect I'm hitting a similar issue. For the r interpreter, I need to parse
the list of interpreters in the group to find the SparkInterpreter. I find a
class with that name, but it c
@djoelz - can you clarify the standard you're using to decide when tests are
required? I'm putting together tests for the R interpreter PR, and it seems
like you have a logical method for determining what has to be testable. If
there's documentation on a testing standard for submissions, I'd app
> On Aug 5, 2015 4:44 PM, "Amos B. Elberg" wrote:
>>
>> I'm returning a string bracketed in tags. is this not what I
>> should be doing?
>>
>>>> On Aug 5, 2015, at 9:57 AM, Felix Cheung
>>> wrote:
>>>
>>> Are
I'm returning a string bracketed in tags. is this not what I should
be doing?
> On Aug 5, 2015, at 9:57 AM, Felix Cheung wrote:
>
> Are you wrapping SVG in HTML?
>
>
>
>
>
>
> On Wed, Aug 5, 2015 at 6:53 AM -0700, "Amos B. Elberg"
> w
1 - 100 of 107 matches
Mail list logo
