Re: [O] org-babel order of evaluation

2012-01-23 Thread Eric Schulte
Leo Alekseyev dnqu...@gmail.com writes:

 On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel r...@rickster.com wrote:
 On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
 Rick Frankel r...@rickster.com writes:

 Turns out it was not that difficult to change this behavior.  You and
 Leo are both correct that in-buffer-order evaluation is more natural and
 expected than the previous behavior.  I've just pushed up a fix after
 which evaluating the following

 Eric,
 The fix doesn't seem to be working for me when I export the buffer to
 HTML.

My previous fix only set the order of evaluation for interactive buffer
evaluation.  I've just pushed up another fix which sets the order of
evaluation during export.

Best,

 The ordering of call and source blocks once again becomes randomized,
 and in general, exported file is missing a bunch of stuff unless I run
 org-babel-execute-buffer prior to export.  Since the export engine
 does its own evaluation, it doesn't seem like org-babel-execute-buffer
 should be a necessity.  But I can't run org-babel-execute-buffer on
 anything with a src_language inline block as it gives me an error.

 I'm attaching two files which do not export correctly, at least when
 one doesn't run org-babel-execute-buffer; just do C-c C-e h and look
 at the output.

 --Leo



-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



Re: [O] org-babel order of evaluation

2012-01-20 Thread Leo Alekseyev
On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel r...@rickster.com wrote:
 On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
 Rick Frankel r...@rickster.com writes:

 Turns out it was not that difficult to change this behavior.  You and
 Leo are both correct that in-buffer-order evaluation is more natural and
 expected than the previous behavior.  I've just pushed up a fix after
 which evaluating the following

Eric,
The fix doesn't seem to be working for me when I export the buffer to
HTML.  The ordering of call and source blocks once again becomes
randomized, and in general, exported file is missing a bunch of stuff
unless I run org-babel-execute-buffer prior to export.  Since the
export engine does its own evaluation, it doesn't seem like
org-babel-execute-buffer should be a necessity.  But I can't run
org-babel-execute-buffer on anything with a src_language inline
block as it gives me an error.

I'm attaching two files which do not export correctly, at least when
one doesn't run org-babel-execute-buffer; just do C-c C-e h and look
at the output.

--Leo


test-export4.org
Description: Binary data


test-export6.org
Description: Binary data


Re: [O] org-babel order of evaluation

2012-01-12 Thread Leo Alekseyev
 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 code
 block.  For example;
[snip]

 There is (at least currently) no guarantee that evaluation order will be
 buffer order.

I've been extremely confused by this in the past; this should be
prominently documented.  In the long run, I would like to see this
behavior changed.  One would intuitively expect all the source code in
the file to be evaluated in order.  This is how it works in pretty
much any other interpreter, why should org-babel be different?

(I'm a big fan of the principle of least surprise, and this behavior
violates it with vengeance :)  )

This is particularly nasty because many users start by treating an
org-babel file as a fancier version of the original source code with
nice annotations and outline levels; typically in a single language.
Thus, operationally, there isn't a distinction between tangling the
blocks into a single source file and feeding that to the interpreter
and running execute on the whole buffer.  But then, of course, one
might start using named blocks, variables, and #+call directives.  It
achieves the same effect as writing wrapper functions (or issuing
statements like source(somefile)) in the original language.  So,
when it results in a completely different execution order, it's a huge
surprise.

Even if this can be fixed by putting dummy dependencies in by hand,
this fix  seems inelegant and hacky.

Is there some deep rationale for the current behavior that I'm not
seeing?  Are there big obstacles to enforcing ligeral execution order?

--Leo



Re: [O] org-babel order of evaluation

2012-01-12 Thread Rick Frankel
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 code
  block.  For 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.
 
 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



Re: [O] org-babel order of evaluation

2012-01-12 Thread Eric Schulte
Rick Frankel r...@rickster.com writes:

 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 code
  block.  For 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.
 
 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 :).


Turns out it was not that difficult to change this behavior.  You and
Leo are both correct that in-buffer-order evaluation is more natural and
expected than the previous behavior.  I've just pushed up a fix after
which evaluating the following

#+Title: Execute all executables in Order
#+Property: results silent

#+name: foo
#+BEGIN_SRC sh :var it=one
  echo $it  debug
#+END_SRC

#+call: foo(two)

#+BEGIN_SRC sh
  echo three  debug
#+END_SRC

results in the creation of a debug file in the same directory reading;

,
| one
| two
| three
`

Thanks for bringing this up,


 rick


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/


Re: [O] org-babel order of evaluation

2012-01-12 Thread Rick Frankel
On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
 Rick Frankel r...@rickster.com writes:
 
 Turns out it was not that difficult to change this behavior.  You and
 Leo are both correct that in-buffer-order evaluation is more natural and
 expected than the previous behavior.  I've just pushed up a fix after
 which evaluating the following
 

Brillant! thank you Eric. This saves me much pain.

rick



[O] org-babel order of evaluation

2012-01-11 Thread Rick Frankel
There is a problem with the order of execution of interspersed source
and call blocks will not be executed in order because of the way
org-babel-execute-buffer is written (first all the source blocks, then
all the call blocks). 

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.

Given the following:

#+name: one(v=one)
#+begin_src elisp
v
#+end_src

#+call: one(two)

#+name: three(v=three)
#+begin_src elisp
v
#+end_src

The message buffer shows:

executing Elisp code block (one)...

(v (quote one))

Code block evaluation complete.
executing Elisp code block (three)...

(v (quote three))

Code block evaluation complete.
executing Elisp code block (one)...

(v (quote two))

two
executing Emacs-Lisp code block...

(results (quote two))