From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` Date: Fri, 21 Aug 2015 16:13:13 -0400 Message-ID: <87oai0v1ra.fsf@gmail.com> References: <874mjsq2r7.fsf@nicolasgoaziou.fr> <8737zcoh9r.fsf@nicolasgoaziou.fr> <87y4h4n0nj.fsf@nicolasgoaziou.fr> 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]:56386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSsgi-0005AL-Vw for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 16:13:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSsge-00034D-NE for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 16:13:20 -0400 Received: from mail-qk0-x231.google.com ([2607:f8b0:400d:c09::231]:35506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSsge-000348-Hq for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 16:13:16 -0400 Received: by qkbm65 with SMTP id m65so37449245qkb.2 for ; Fri, 21 Aug 2015 13:13:16 -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: Ista Zahn Ista Zahn , Andreas Leha , emacs-orgmode Mailinglist Hi Ista, 2015ko abuztuak 21an, Ista Zahn-ek idatzi zuen: >=20 > On Fri, Aug 21, 2015 at 11:04 AM, Nicolas Goaziou > wrote: >> Ista Zahn writes: >>=20 >>> I agree that it is safer. In my case its safer like a 10 MPH speed >>> limit. Safe yes, but too slow! >>=20 >> Doesn't Babel :cache property help here? >=20 > It does actually, to my surprise. I have not been using :cache because > the documentation says >=20 > "Note that the :cache header argument will not attempt to cache > results when the :session header argument is used" >=20 > and since I almost always use :session I didn't expect this to work. > To my surprise it does (at least with R source blocks, I haven't > tested yet with others). Can I now rely on this to work even with > :session? I think it depends on what you mean by =E2=80=9Cwork.=E2=80=9D Specificall= y, :cache doesn=E2=80=99t understand dependencies across source blocks when run in a session. So in the following document, if you edit the definition of myvar, the subsequent usage will retain the old value on subsequent exports: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #+begin_src R :session *foo* :cache yes myvar <- 1 myvar #+end_src #+RESULTS[8310fa64b89f36a383660d14779e88d9aa90834a]: : 1 #+begin_src R :session *foo* :cache yes myvar #+end_src #+RESULTS[5c241816868f6400ccfb54ceb6ef15dbeea16de1]: : 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are also subtle issues related to the fact that in order to export a document, org: 1) makes a copy of the buffer 2) executes the babel blocks in this copy, destructively modifying the buffer as it goes 3) exports the result In my experience, sometimes the header arguments, and thus the hash that the cache depends on, can change. So in addition to the cache not re-evaluating when it should as above, it might needlessly re-evaluate a computationally expensive block in the middle of export. I tried to fix this about 2 years ago by getting the relevant code to not do any buffer modifications as it goes but rather first evaluate all the blocks then do all the needed modifications. However, the resultant patch was too big, and I ran out of time to work on it. Since I made that attempt, a second, unmodified copy of the buffer has been introduced to the process to help with some (nominally different but related) aspects of babel processing. This might have solved the problem, but I=E2=80=99m not sure. When the cache has not worked as I expected it to in the past, it=E2=80=99s= been in the middle of actually trying to do something with org, usually under deadline pressure. Thus, I=E2=80=99ve adopted the conservative approach of evaluating blocks manually in all circumstances, and not trying to get caching to work. So, you might find that these problems have all gone away as a consequence of other changes. For purely R-based work, Charles Berry=E2=80=99s ox-ravel package is a very interesting approach, since it relies on the cache feature of knitr, which is capable of automatically detecting cross-block dependencies like the example above under some circumstances . It would be interesting to see if that approach could be used to override :cache handling for ob-R, while falling back on org-babel=E2=80=99s less intelligent features for oth= er languages (or in R environments that don=E2=80=99t have knitr available). = But that=E2=80=99s a(nother) big project. (I=E2=80=99ve also never used ox-rav= el in a serious project, so my impressions are just based on reading the code and documentation =E2=80=93 which is a really excellent example of literate elisp programming). TLDR: If the standard of reliance is working as well as other cache-capable literate programming libraries for R like knitr, in my (possibly out of date) experience :cache + :session is not up to scratch. --=20 Aaron Ecay