From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Frankel Subject: Re: org-babel order of evaluation Date: Thu, 12 Jan 2012 17:51:29 -0500 Message-ID: <20120112225129.GA26670@BigDog.local> References: <20120112002506.GA26183@BigDog.local> <87y5td7z2t.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:44559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlTUc-0002JB-DB for emacs-orgmode@gnu.org; Thu, 12 Jan 2012 17:51:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlTUb-0002BK-Bf for emacs-orgmode@gnu.org; Thu, 12 Jan 2012 17:51:34 -0500 Received: from [204.62.15.78] (port=46927 helo=mail.rickster.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlTUb-0002BG-8m for emacs-orgmode@gnu.org; Thu, 12 Jan 2012 17:51:33 -0500 Received: from BigDog.local (pool-173-68-170-125.nycmny.fios.verizon.net [173.68.170.125]) by mail.rickster.com (Postfix) with ESMTPS id 579C322293 for ; Thu, 12 Jan 2012 17:51:32 -0500 (EST) Content-Disposition: inline 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: emacs-orgmode@gnu.org On Thu, Jan 12, 2012 at 04:35:31PM -0600, Leo Alekseyev wrote: > >> Therefore, when executing an entire buffer, there is no way to have > >> the execution of a call block dependent on the prior execution of a > >> source block. > >> > > > > It would be better to make the dependency explicit by passing the > > results of the call line as a (potentially unused) variable to the co= de > > block. =A0For example; > [snip] The problem w/ this is that the (potentially time consuming) dependent will be executed twice when doing a buffer eval. > > There is (at least currently) no guarantee that evaluation order will= be > > buffer order. >=20 > Is there some deep rationale for the current behavior that I'm not > seeing? Are there big obstacles to enforcing ligeral execution order? It's because prior to 7.8, call blocks were not executed during a buffer execute. The solution was to execute all the call blocks after executing the src block. (Eric would have to comment on how hard it would be to merge the two functions :). rick