From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: R code block produces only partial output Date: Thu, 7 Aug 2014 10:42:24 -0700 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> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-447851418-1407433346=:348" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFRhz-00075K-RG for emacs-orgmode@gnu.org; Thu, 07 Aug 2014 13:42:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFRht-0001rN-0L for emacs-orgmode@gnu.org; Thu, 07 Aug 2014 13:42:35 -0400 Received: from iport-acv2-out.ucsd.edu ([132.239.0.174]:47522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFRhs-0001r7-JF for emacs-orgmode@gnu.org; Thu, 07 Aug 2014 13:42:28 -0400 In-Reply-To: <87ppgcrg8n.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: Aaron Ecay Cc: emacs-orgmode@gnu.org, Eric Schulte This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-447851418-1407433346=:348 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 6 Aug 2014, Aaron Ecay wrote: > Hi Eric, > > 2014ko abuztuak 6an, Eric Schulte-ek idatzi zuen: > > [...] > >> Perhaps you could begin with a patch for the regexp issue in this >> thread? > > I have pushed a patch which allows us to avoid the regex issue > entirely by using a native R method to capture the session output to a > file. > > This introduces the change that the output no longer appears in the > session buffer, but I think that’s actually an improvement: we were not > previously echoing the commands to the buffer, such that the output > would show up “out of the blue” without any indication of how it got > there. Hi Aaron, I like what you are trying to do, but ... 1) The change has at least one bug: Remote sessions are broken by this change. 2) The behavior of :results output is modified in ways that might not be desired. i.e. warnings and errors will not show up in the output. Can you revert this change until the bugs are sorted out and consensus about the proper handling of cases like '2' is reached? Can I also suggest that in the future before a change is pushed, that the patch is announced so we can try it out or at least eyeball it and discuss issues/bugs? Details: Issue 1) =========== If I open a *.org file on a remote machine and C-c C-c on a src block that has `:session :results output', after the usual session startup the src block fails. The session buffer shows this ==== 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': No such file or directory > === The file '/tmp/R-1155xWV' was created. I think if the tramp file localname is used. it might work. I do not know tramp, but maybe something like (let output-file-localname (if (tramp-tramp-file-p output-file) (tramp-file-name-localname (tramp-dissect-file-name output-file)) output-file)) is good enough. Issue 2) =========== ECM: #+NAME: aa #+BEGIN_SRC R :session R2 :results output warning("this is a warning") 1+1 #+END_SRC #+RESULTS: aa : [1] 2 For some purposes having the warnings in the #+RESULTS: block is helpful. And when revising code, having the errors in the #+RESULTS helps - especially if I have to put aside work in progress. HTH, Chuck --0-447851418-1407433346=:348--