From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Kiermeier Subject: Re: R code block produces only partial output Date: Sat, 23 Aug 2014 18:54:02 +0930 Message-ID: References: <87iom8zd24.fsf@gmail.com> <877g2oz9gv.fsf@gmail.com> <87lhr27oap.fsf@gmail.com> <87r40uwavs.fsf@gmail.com> <8761i5kg8f.fsf@gmail.com> <87ppgcrg8n.fsf@gmail.com> <87lhr0qimr.fsf@gmail.com> <87wqa9owhv.fsf@gmail.com> <87oavkp2xa.fsf@gmail.com> <87r40f8xfo.fsf@Rainer.invalid> <87a9718hg7.fsf@gmail.com> <877g2511mx.fsf@Rainer.invalid> <871ts7r4ho.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ac58a1738a60501488632 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL7Yy-0002Fp-SJ for emacs-orgmode@gnu.org; Sat, 23 Aug 2014 05:24:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XL7Yx-0003Aq-Bb for emacs-orgmode@gnu.org; Sat, 23 Aug 2014 05:24:44 -0400 Received: from mail-qc0-x22d.google.com ([2607:f8b0:400d:c01::22d]:53537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL7Yx-0003Am-4y for emacs-orgmode@gnu.org; Sat, 23 Aug 2014 05:24:43 -0400 Received: by mail-qc0-f173.google.com with SMTP id w7so11874058qcr.18 for ; Sat, 23 Aug 2014 02:24:42 -0700 (PDT) In-Reply-To: <871ts7r4ho.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org, aaronecay@gmail.com --001a113ac58a1738a60501488632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Aaron, thanks for keeping on this. I personally don't have a problem with requiring an R package. In fact, users will have a rather limited experience with R if they cannot install add-on packages (for whatever reason) - this is one of the things that makes R such an attractive option for data analysis. While there might be some IT departments that are very restrictive, I also think (no data behind this) that the majority of our users are not in that situation. Anyway, that's my two cents worth. =E2=80=8BCheers, Andreas On 23 August 2014 18:02, Aaron Ecay wrote: > 2014ko abuztuak 19an, Achim Gratz-ek idatzi zuen: > > > > Aaron Ecay writes: > >> R is capable of installing packages to a user-specified directory, > >> without requiring root or any other special privileges. So IT cannot > >> literally prevent R users from installing their own packages; > > > > They can, all they have to do is to take away the ability to connect to > > the outside network and that's what is increasingly being done (for > > other reasons, mind you). > > > >> the requirement must rather come as a statement of policy. > > > > That is another common thing, if only to shift the responsibility if th= e > > other measures don't actually prevent that. > > > >> I=E2=80=99d like to > >> understand more about how such regimes work and how org could work > >> with them, ideally from people who have direct experience with them. > > > > Ideally, don't require the use of a non-core package. The beef with > > things like CTAN, CRAN or CPAN is that they require extra maintenance > > beyond the pure installation of some software and some specific > > knowledge of the software in question and that's just not going to > > happen in some places. > > > >> Otherwise, it would be disappointing if the fear that an unidentifiabl= e > >> somebody somewhere might not be able to install R packages derailed th= e > >> improvement of babel=E2=80=99s R support. > > > > The request was to keep a fallback to core. I have no comment at this > > time if it would be possible or not. Since ultimately it's the session > > support of Emacs that is clunky (and that affects most other languages > > as well), maybe an effort to improve that would be more generally > > helpful than working around it in different ways in each language. > > Well, I think that it=E2=80=99s going to be difficult to make babel a bet= ter > literate programming solution for R if we restrict ourselves not to > use the state-of-the-art R package for low-level literate programming > support. Org is full of features which one needs to install other > software to use, and I=E2=80=99m comfortable with the idea that babel=E2= =80=99s R > support should require the evaluate package. However, it=E2=80=99s diffi= cult > to argue this point of view when no one has spoken up about their own > requirements, and a spirit of conservatism in the face of vague > imagined difficulties persists. > > The attached patch fixes the problem that touched off this thread. > It=E2=80=99s only debatably nicer than the present approach, but it has t= he > independently desirable property of segregating babel-driven output > from the session buffer. It incorporates what I think is a fix for > the tramp bug Charles pointed out. > > It=E2=80=99s as yet only lightly tested, and as always comments are welco= me. > > -- > Aaron Ecay > > --001a113ac58a1738a60501488632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Aaron,
thanks for = keeping on this.
I personally don't have a problem with requiring an R p= ackage.
In fact, users will have a rather limited experience with R if they cannot = install add-on packages (for whatever reason) - this is one of the things t= hat makes R such an attractive option for data analysis.
While there might be some IT departments that are very restrictive, I also = think (no data behind this) that the majority of our users are not in that = situation.
Anyway, that's my two cents worth.
=E2=80=8BCheers,
Andreas


On 23 August 2014 18:02, Aaron Ecay <aaronecay@gmail.com><= /span> wrote:
2014ko abuztuak 19an, Achim Gratz-ek idatzi = zuen:
>
> Aaron Ecay writes:
>> R is capable of installing packages to a user-specified directory,=
>> without requiring root or any other special privileges.=C2=A0 So I= T cannot
>> literally prevent R users from installing their own packages;
>
> They can, all they have to do is to take away the ability to connect t= o
> the outside network and that's what is increasingly being done (fo= r
> other reasons, mind you).
>
>> the requirement must rather come as a statement of policy.
>
> That is another common thing, if only to shift the responsibility if t= he
> other measures don't actually prevent that.
>
>> I=E2=80=99d like to
>> understand more about how such regimes work and how org could work=
>> with them, ideally from people who have direct experience with the= m.
>
> Ideally, don't require the use of a non-core package.=C2=A0 The be= ef with
> things like CTAN, CRAN or CPAN is that they require extra maintenance<= br> > beyond the pure installation of some software and some specific
> knowledge of the software in question and that's just not going to=
> happen in some places.
>
>> Otherwise, it would be disappointing if the fear that an unidentif= iable
>> somebody somewhere might not be able to install R packages deraile= d the
>> improvement of babel=E2=80=99s R support.
>
> The request was to keep a fallback to core.=C2=A0 I have no comment at= this
> time if it would be possible or not.=C2=A0 Since ultimately it's t= he session
> support of Emacs that is clunky (and that affects most other languages=
> as well), maybe an effort to improve that would be more generally
> helpful than working around it in different ways in each language.

Well, I think that it=E2=80=99s going to be difficult to make b= abel a better
literate programming solution for R if we restrict ourselves not to
use the state-of-the-art R package for low-level literate programming
support.=C2=A0 Org is full of features which one needs to install other
software to use, and I=E2=80=99m comfortable with the idea that babel=E2=80= =99s R
support should require the evaluate package.=C2=A0 However, it=E2=80=99s di= fficult
to argue this point of view when no one has spoken up about their own
requirements, and a spirit of conservatism in the face of vague
imagined difficulties persists.

The attached patch fixes the problem that touched off this thread.
It=E2=80=99s only debatably nicer than the present approach, but it has the=
independently desirable property of segregating babel-driven output
from the session buffer.=C2=A0 It incorporates what I think is a fix for the tramp bug Charles pointed out.

It=E2=80=99s as yet only lightly tested, and as always comments are welcome= .

--
Aaron Ecay


--001a113ac58a1738a60501488632--