From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: R code block produces only partial output Date: Thu, 07 Aug 2014 14:06:36 -0400 Message-ID: <87lhr0qimr.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFS5Q-0002if-CG for emacs-orgmode@gnu.org; Thu, 07 Aug 2014 14:06:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFS5H-0000yk-Aq for emacs-orgmode@gnu.org; Thu, 07 Aug 2014 14:06:48 -0400 Received: from mail-qg0-x236.google.com ([2607:f8b0:400d:c04::236]:36454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFS5H-0000yg-6e for emacs-orgmode@gnu.org; Thu, 07 Aug 2014 14:06:39 -0400 Received: by mail-qg0-f54.google.com with SMTP id z60so4932528qgd.27 for ; Thu, 07 Aug 2014 11:06:38 -0700 (PDT) In-Reply-To: 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: "Charles C. Berry" Cc: emacs-orgmode@gnu.org, Eric Schulte Hi Chuck, Thanks for your feedback. 2014ko abuztuak 7an, "Charles C. Berry"-ek idatzi zuen: > Hi Aaron, >=20 > I like what you are trying to do, but ... >=20 > 1) The change has at least one bug: Remote sessions are broken by this=20 > change. >=20 > 2) The behavior of :results output is modified in ways that might not be= =20 > desired. i.e. warnings and errors will not show up in the output. >=20 > Can you revert this change until the bugs are sorted out and consensus=20 > about the proper handling of cases like '2' is reached? OK. >=20 > Can I also suggest that in the future before a change is pushed, that the= =20 > patch is announced so we can try it out or at least eyeball it and discuss > issues/bugs? Good idea. >=20 > Details: >=20 > Issue 1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > If I open a *.org file on a remote machine and C-c C-c on a src block tha= t=20 > has `:session :results output', after the usual session startup the src=20 > block fails. The session buffer shows this >=20 > =3D=3D=3D=3D > Error in file(file, if (append) "a" else "w") : > cannot open the connection > In addition: Warning message: > In file(file, if (append) "a" else "w") : > cannot open file '/scpc:berry@:/tmp/R-1155xWV':=20 > No such file or directory >>=20 > =3D=3D=3D >=20 > The file '/tmp/R-1155xWV' was created. >=20 > I think if the tramp file localname is used. it might work. I do not know= =20 > tramp, but maybe something like >=20 > (let output-file-localname > (if (tramp-tramp-file-p output-file) > (tramp-file-name-localname > (tramp-dissect-file-name output-file)) > output-file)) >=20 > is good enough. This looks promising =E2=80=93 I=E2=80=99ll work on it. >=20 >=20 > Issue 2) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ECM: >=20 > #+NAME: aa > #+BEGIN_SRC R :session R2 :results output > warning("this is a warning") > 1+1 > #+END_SRC >=20 > #+RESULTS: aa > : [1] 2 >=20 > For some purposes having the warnings in the #+RESULTS: block is helpful. >=20 > And when revising code, having the errors in the #+RESULTS helps -=20 > especially if I have to put aside work in progress. Hmm. Certainly, the previous behavior should be retained for now. In the longer term, I=E2=80=99d like to see a system whereby R errors trigger = elisp errors. This is so that the execution of a whole document (subtree, etc.) will be halted by the first error, rather than continuing what may be a long series of commands that will not give valid output. What do you think? Thanks, --=20 Aaron Ecay