I too was able to use R via PR 208 with success. I have it running as expected within the Virtual Machine outlined in this updated PR https://github.com/apache/incubator-zeppelin/pull/751/
With the `repl` package (also installed via the VM script), plotting such as native R histograms worked within the notebook display system as well. So - this looks good to me. Not to oversimplify things, it “seems” this PR (or this PR and a future PR for packaging) just needs: - the packaging worked out (get the R scripts included in the distribution) - a few license additions to the rscala files (if they are not generated but part of the base requirements) - a profile addition such as -P r to only build with R binaries if desired. Unless I am missing something, it could be merged with one final focused effort. Somebody could tweak the documentation a bit to match the tone of the other interpreter docs post merge. Regards, Jeff Steinmetz Principal Architect Akili Interactive On 2/29/16, 6:45 AM, "Sourav Mazumder" <sourav.mazumde...@gmail.com> wrote: >Very similar is my experience too. > >Could run PR 208 with least effort. And so far I am very successful to use >it to create demonstrations covering end to end machine learning use cases >in Zeppelin (showcasing how data can be shared across scala, SparkR, R >easily where data preparation/model creation done in SparkR/Scala where as >visualization in R) using PR 208 in different meetups and other forums. > >Regards, >Sourav > >On Mon, Feb 29, 2016 at 5:04 AM, enzo <e...@smartinsightsfromdata.com> >wrote: > >> As a keen R user I tried both branches, but I couldn’t make work Charles' >> version (maybe my mistake). I found some issue on Amos' version (mainly >> about charting), reported on his github page (he has suggested to test more >> extensively and report after merge - fair enough). >> >> In conclusion I do not have sound enough elements to judge on which one is >> better. As I’m in favour of competition as a general principle, taking into >> account that they seem to be close to the finishing line I would suggest to >> merge each one and let users decide: I concur with Eran. >> >> It would be useful (just to avoid similar occurrences in the future) to >> understand why we arrived here though. How is it possible that a >> fundamental pr as R interpreter takes so long to be integrated? I would >> humbly suggest for the future to give better treatment to the big hitting >> functionalities. Clearly the more a ‘big’ functionality is delayed, the >> more will be deemed attractive to develop alternative versions (some time >> better versions, some time equally useful). >> >> Another consideration is the over present issue of graphics. From an R >> standpoint, due to the extreme richness of its graphic offering, so far I >> found that no notebook is entirely satisfactory: for example the growing >> family of htmlwidgets are badly (or not) displayed in many cases. It would >> certainly benefit the community to invest time and activities on perfecting >> these issues, but so be it. >> >> >> Enzo >> e...@smartinsightsfromdata.com >> >> >> >> > On 29 Feb 2016, at 12:36, Eran Witkon <eranwit...@gmail.com> wrote: >> > >> > I think we should ask ourselves what is the guiding principle here, for >> > example, if in the future I want to create yet another JDBC interpreter >> or >> > Flink interpreter, should I only extend the one that already exist or >> can I >> > create my own and let the user community decide? realistically I don't >> > think we can control where people invest their time and contribution and >> as >> > long as it has no licencing issues and align with other project guidance >> it >> > should be up to the users to decide. >> > >> > Eran W >> > >> > On Mon, Feb 29, 2016 at 2:13 PM DuyHai Doan <doanduy...@gmail.com> >> wrote: >> > >> >> Hello Alexander >> >> >> >> My opinion is no one, unless being an expert with R, is able to judge >> the >> >> quality of both contributions apart from the authors themselves. So >> let's >> >> make them work together to merge 2 PR into a good one. Those PR, >> >> especially the #208 has been there for a while and it's high time they >> get >> >> merged so the community can move on. >> >> >> >> Unless there are R experts in the Zeppelin community and so they should >> >> speak to give their own opinions. >> >> >> >> My 2 cents >> >> >> >> Duy Hai DOAN >> >> >> >> On Mon, Feb 29, 2016 at 1:04 PM, Alexander Bezzubov <b...@apache.org> >> >> wrote: >> >> >> >>> Hi fellow Zeppelin community members, >> >>> >> >>> as you know, we have 2 contributions for ZEPPELIN-156 >> >>> <https://issues.apache.org/jira/browse/ZEPPELIN-156> AKA R >> >>> <https://github.com/apache/incubator-zeppelin/pull/208> interpreter >> >>> <https://github.com/apache/incubator-zeppelin/pull/702>. >> >>> Both have merit, so wearing my PPMC hat, I'd like to suggest us to >> make a >> >>> decision, how we move forward with it avoiding user confusion. >> >>> >> >>> Here is what we can do: >> >>> - a. pick only one of those and merge it >> >>> - b. ask authors of both of them to collaborate together and come up >> >> with >> >>> one >> >>> - c. merge each, as soon as it's ready and let users\maintainers decide >> >>> which one is best at the end >> >>> >> >>> This is not an official VOTE (which is possible to arrange, but is >> rather >> >>> bad way to build a consensus). >> >>> >> >>> It is a discussion, aimed to see if we all, as community, can build a >> >>> consensus together cooperatively - meaning, *everyone compromises >> >>> something *and* there are no really strong opinions against the final >> >>> plan*. >> >>> >> >>> I specifically DO NOT ask which one is better, have more features, etc, >> >>> etc, etc. >> >>> What I ask for are opinions on a community way of reconciling this >> >>> situation and moving project forward together. >> >>> >> >>> What do you think? >> >>> >> >>> -- >> >>> Kind regards, >> >>> Alexander. >> >>> >> >> >> >>
