emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <ndokos@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: babel header arguments tutorial?
Date: Sun, 27 Sep 2015 15:51:01 -0400	[thread overview]
Message-ID: <87mvw7zlne.fsf@pierrot.dokosmarshall.org> (raw)
In-Reply-To: CAFAhFSXd0F-X1Lj-i+sfwoNvpF9gnbbdbznmFaCekYL32_36nw@mail.gmail.com

Lawrence Bottorff <borgauf@gmail.com> writes:

> I guess from a purely elisp perspective I'm baffled. How is
>
> #+begin_src emacs-lisp
>   org-babel-default-header-args:Python
> #+end_src
>
> supposed to produce
>
> #+RESULTS:
> | (:session . foo) |
>
> as it supposedly does in the doc? It doesn't for me. (Where, e.g., would "foo" be coming from?) If it had worked, does it make an addition to some hash table, or an alist somewhere?
> But then running this as an elisp code block is cool from a declarative programming standpoint (see this) . So this
>
> # Local Variables:
> # eval: (setq-local org-babel-default-header-args:Python '((:session . "foo")))
> # End:
>
> is called when you eval-buffer or open the file? 
>

When you open the file. But see some caveats in my reply. Charles
Berry's reply shows the preferred method today, using only what's
available in org, but does not shed any light on the local file
variables question (which is a more general mechanism, available
throughout emacs, not just with org files).

Assuming that you want to learn about file variables, we will forget
temporarily about Charles's reply.

So when you open the file, the local variables section is found and
evaluated. Any variable settings are automatically buffer-local.
That's what sets the org-babel-default-header-args:python variable
to '((:session . "foo")) - in that buffer only.

Then when you go evaluate the code block

#+begin_src emacs-lisp
org-babel-default-header-args:python
#+end_src

the variable has the give value and produces a result

#+RESULTS:
: ((:session . foo))

But if you evaluate the same code block in some other buffer, the
result will be nil (unless you have initialized in some other way
of course, e.g. by adding the initialization to your .emacs).

> Ancillary questions:
> 1. can babel elisp (or CL) blocks be assigned/associated to a
> specifically named session?
> That would enable various elisp code blocks to have separate "session
> spaces" (as does the geiser/scheme babel). If so, I'm guessing the
> block-session communication could also be remote? Again, with babel
> geiser/scheme sessions, can they call "cached" things from each
> other's different sessions?
>

Theoretically, maybe (how's that for exactness?), but there are babel
implementations that don't support sessions at all and (depending on the
underlying interpreter), there may be subtle (or perhaps not so subtle)
differences in evaluation semantics. Some experimentation should provide
answers, but N.B. that the answers may be accidents of implementation
(which some might call "bugs"). I don't think there is a strictly
defined session model that applies to all languages: the implementations
do the best they can under these circumstances.

Now this is more a hunch than anything else: I *think* that's the way
things are but I may be wrong, out-of-date, or both. A set of
well-designed experiments in as many languages as possible would clarify
the situation, and perhaps lead to improvements (they could also be
turned into unit tests, which would be very desirable) - I won't
volunteer, but maybe you would?

> 2. . . . which makes me wonder how code blocks in a buffer can be run besides manually C-c C-c ing them. For example,
>
> #+name: myexptdouble
> #+begin_src emacs-lisp :session
> (defun myexptdouble (x y)
>   (* (myexpt x y) (myexpt x y)))
> #+end_src
>
> #+RESULTS: myexptdouble
> : myexptdouble
>
> #+name: myexpt
> #+begin_src emacs-lisp :session
> (defun myexpt (x y)
>   (expt x y))
> #+end_src
>
> #+BEGIN_SRC emacs-lisp :results output raw
> (myexptdouble 2 3)
> #+END_SRC
>
> Even if I manually evaluate myexptdouble, running the last block gives an error about not knowing what myexpt is. Is there something in the last block that can be told to evaluate all
> the dependent functions? Perhaps if my blocks are named the same as the function name? How tangling and preserving sessions is also an interesting question, IHMO.
>

That's not answering any of your deeper questions, but the problem here
is that the last code block evaluates a function that produces no
output: it produces a return value though, so try

#+BEGIN_SRC emacs-lisp :results value raw
 (myexptdouble 2 3)
#+END_SRC

-- 
Nick

  reply	other threads:[~2015-09-27 19:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-26 18:39 babel header arguments tutorial? Lawrence Bottorff
2015-09-26 21:39 ` Charles C. Berry
2015-09-27  8:22   ` Modification dates in Worg (was: babel header arguments tutorial?) Michael Strey
2015-09-28 15:04     ` Ista Zahn
2015-09-29  8:06       ` Modification dates in Worg Michael Strey
2015-09-29 14:38         ` Ista Zahn
2015-09-26 22:09 ` babel header arguments tutorial? Nick Dokos
2015-09-26 22:43   ` Thomas S. Dye
2015-09-27  2:41     ` Nick Dokos
2015-09-27 16:28       ` Lawrence Bottorff
2015-09-27 19:51         ` Nick Dokos [this message]
2015-09-27 16:47       ` Thomas S. Dye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvw7zlne.fsf@pierrot.dokosmarshall.org \
    --to=ndokos@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).